http://www.raincent.com/content-85-5840-1.html
非互联网时代
我是从2000年开始接触数据仓库，大约08年开始进入互联网行业，那时在互联网接触到数据平台与传统第三代数据架构还是有很大的类似之处，随着互联网的突飞猛进，每一次的技术变革都带来一场从技术、架构、业务的渐进式变革，到今天互联网、非互联网的数据平台架构已经差异非常大。
回顾早期的企业环境，企业的生产与服务是一个很长周期，导致业务数据呈现一种粗粒度模式。随着互联网的快速渗透从早期的PC终端到“裆下“的 移动终端，对用户的需求与服务周期将逐渐的缩短，业务量级、数据类型多样化与存储的暴增，对应着技术、架构、业务呈现出迅猛发展，相应的数据沉淀与积累也成指数暴涨。
从”数据仓库“ 词开始到现在的“大数据”，中间经历了太多的知识、架构模式的演进与变革，比如说“数据仓库、海量数据、大数据”等。(备注：数据仓库一般指的是：在相当长的时间内堆积数据，仅仅需要处理大量数据请求中的少部分的系统。数据仓库不等同于“海量数据” 。恰恰相反，而是其子集。海量数据也包含：通过大量的连接提供每秒百万次服务请求的系统。大数据是海量数据+复杂类型数据基础上的大分析、高宽带、大内容)。
数据仓库在国外的发展史多年，大约在98-99年左右进入中国，到现在历了大约十多年发展。到了今天尤其是在非互联网、互联网企业两个领域数据平台有显著的区别。 本文将以非互联网时代、互联网时代数据平台发展角度来讲述。
很多从传统企业数据平台转到互联网同学是否有感觉，非互联网企业、互联网企业的数据平台所面向用户群体是不同的?这两类的数据平台的建设、使用用户又有变化?数据模型设计又有什么不同呢?
我们先来看用户群体的区别，下边整理了2个图来讲述用户群体相关区别。
一、用户群体
非互联网数据平台用户：
企业的boss、运营的需求主要是依赖于报表、商业智能团队的数据分析师去各种分析与挖掘探索;
支撑这些人是ETL开发工程师、数据模型建模、数据架构师、报表设计人员 ，同时这些角色又是数据平台数据建设与使用方。
数据平台的技术框架与工具实现主要有技术架构师、JAVA 开发等。
用户面对是结构化生产系统数据源。
互联网数据平台用户：
‣ 互联网企业中员工年龄比非互联网企业的要年轻、受教育程度、对计算机的焦虑程度明显比传统企业要低、还偶遇其它各方面的缘故，导致了数据平台所面对用户群体与非互联网数据平台有所差异化;
‣ 互联网数据平台的使用与建设方是来自各方面的人，数据平台又是技术、数据产品推进建设的。
‣ 分析师参与数据平台直接建设比重增加。
‣ 原有的数据仓库开发与模型架构师的职能也从建设平台转为服务与咨询.
‣ 用户面对是数据源多样化，比如日志、生产数据库的数据、视频、音频等非结构化数据 。
从这用户群体角度来说这非互联网、互联网的数据平台用户差异性是非常明显，互联网数据平台中很多理论与名词都是从传统数据平台传递过来的，本文将会分别阐述非互联网、互联网数据平台区别。
非互联网时代
自从数据仓库发展起来到现在，基本上可以分为五个时代、四种架构(大家可以详细翻一下数据仓库的发展历史，在这里仅作科普性介绍)
‣ 约在1991年前的全企业集成
‣ 1991年后的企业数据集成EDW时代
‣ 1994年-1996年的数据集市
‣ 1996-1997年左右的两个架构吵架
‣ 1998年-2001年左右的合并年代
五个时代划分是以重要事件或代表人物为标志，比如说在企业数据集成EDW时代其重要代表人物是Bill Inmon 代表作数据仓库一书，更重要是他提出了如何建设数据仓库的指导性意见与原则。他遵循的是自上而下的建设原则，这个导致后来数据仓库在千禧年传到中国后的几年内，几个大实施厂商都是遵守该原则的实施方法，后来的数据仓库之路等各种专业论坛上针对数据仓库ODS-EDW的结构讨论(备注：坛子里有个叫吴君，他发表了不少这方面的文章)。
在国内项目实施中IBM、Terdata、埃森哲、菲奈特(被东南收购，东南后来某些原因而倒闭)等很多专业厂商在实施中对ODS层、EDW层都赋予了各种不同的功能与含义(备注：在后边的架构案例解)。
在数据集市年代其代表人物是Ralph kilmball，他的代表作是”The Data Warehouse Toolkit“，在数据仓库的建设上Ralph kilmball 提出的是自下而上的建设方法，刚好与Bill Innmon的建设方法相反，这两种架构方式各有千秋，所以就进入了争吵时代。
我整理了一个表格是这两位大师优缺点：
随着数据仓库的不断实践与迭代发展，从争吵期进入到了合并的时代，其实争吵的结果要麽一方妥协，要麽新的结论出现，果然Bill inmon与 Ralph kilmball的争吵没有结论，干脆提出一种新的架构包含对方，也就是后来Bill Inmon 提出的CIF(corporation information factory) 架构模式、这也算是数据仓库的第三代架构，其架构特点是把整个架构划分为不同层次，把每一层次的定义与功能都详细的描述下来，从04年后国内的很多数据仓库架构、甚至互联网刚开始搞数据平台数据仓库架构模式也是这一种。
数据仓库第一代架构
(开发时间2001-2002年)
海尔集团的一个BI项目，架构的ETL 使用的是 微软的数据抽取加工工具 DTS，老人使用过微软的DTS 知道有哪些弊端，后便给出了几个DTS的截图。
功能：进销存分析、闭环控制分析、工贸分析等
硬件环境：
‣ 业务系统数据库：DB2 for Windows,SQL SERVER2000,ORACLE8I
‣ 中央数据库服务器：4*EXON,2G,4*80GSCSI
‣ OLAP 服务器：2*PIV1GHZ,2G,2*40GSCSI
‣ 开发环境：VISUAL BASIC,ASP,SQL SERVER 2000
数据仓库第二代架构
这是上海通用汽车的一个数据平台，别看复杂，严格意义上来讲这是一套EDW的架构、在EDS数据仓库中采用的是准三范式的建模方式去构建的、大约涉及到十几种数据源，建模中按照某一条主线把数据都集成起来
这个数据仓库平台计划三年的时间构建完毕，第一阶段计划构建统统一生性周期视图、客户统一视图的数据，完成对数据质量的摸底与部分实施为业务分析与信息共享提供基础平台。第二阶段是完成主要业务数据集成与视图统一，初步实现企业绩效管理。第三阶段全面完善企业级数据仓库，实现核心业务的数据统一。
在第一阶段数据仓库中的数据再次通过阶梯型高度聚合进入到数据集市DM(非挖掘集市)中，完成对业务的支撑。
数据的ETL 采用datastage 工具开发(备注 大约06年我写了国内最早的版本datastage 指南 大约190页叫“datastage 学习版文档”。后来没再坚持下来)。
数据集市架构
这个是国内某银行的一套数据集市，这是一个典型数据集市的架构模式、面向客户经理部门的考虑分析。
数据仓库混合性架构(Cif)
这是太平洋保险的数据平台，目前为止我认识的很多人都在该项目中呆过，当然是保险类的项目。
回过头来看该平台架构显然是一个混合型的数据仓库架构。它有混合数据仓库的经典结构，每一个层次功能定义的非常明确。
ODS层 支撑单一的客户视图，是一个偏操作行的做唯一客户识别的，同时提供高可用户性客户主信息查询。
EDW层基于IIW(IBM的通用模型去整理与实施)最细粒度、原子、含历史的数据，也支持查询。
各业务数据集市(DM) 面向详细业务，采用雪花/星型模型去做设计的支撑OLAP、Report、仪表盘等数据展现方式。
新一代架构OPDM 操作型数据集市(仓库)
OPDM大约是在2011年提出来的，严格上来说，OPDM 操作型数据集市(仓库)是实时数据仓库的一种，他更多的是面向操作型数据而非历史数据查询与分析。
在这里很多人会问到什么是操作型数据?首先来看操作型数据支持的企业日常运作的比如财务系统、Crm系统、营销系统生产系统，通过某一种机制实时的把这些数据在各孤岛数据按照业务的某个层次有机的自动化整合在一起，提供业务监控与指导。在2016年的今天看来OPDM在互联网很多企业已经实现了，但是在当时的技术上还是稍微困难点的。
前言，”数据模型“ 这个词只要是跟数据沾边就会出现的一个词，在数据库设计、数据仓库、数据挖掘上、业务里都存在，聚焦一下，这里提到的是数据平台中的”数据模型“。 这是一个非常的抽象词，个人也很难用简单语言把他描述出来，这一章也是整个系列中较为抽象的一章节，同时这个章节将会回答非互联网数据平台数据模型是什么?如何需要数据模型?如何简单的建设?
在“我所经历的大数据平台发展史：非互联网时代（上）”曾经提到Bill inmon与 Ralph kilmball两位大师的设计理念，对业务的数据按照某种规则进行有效组织并满足业务需求。
在构建过程中，有一个角色理解业务并探索分散在各系统间的数据，并通过某条业务主线把这些分散在各角落的数据串联并存储同时让业务使用，在设计时苦逼的地方除了考虑业务数据结构要素外，还得考虑可操作性、约束性(备注 约束性是完成数据质量提升的一个关键要素，未来新话题主题会讨论这些)，这个既要顾业务、数据源、合理的整合的角色是数据模型设计师，又叫数据模型师。
非互联网时代的数据模型是一个高度智慧业务抽象结晶，数据模型是整个系统建设过程的导航图。
平台中模型设计所关注的是企业分散在各角落数据、未知的商业模式与未知的分析报表，通过模型的步骤，理解业务并结合数据整合分析，建立数据模型为Data cleaning 指定清洗规则、为源数据与目标提供ETL mapping (备注：ETL 代指数据从不同源到数据平台的整个过程，ETL Mapping 可理解为 数据加工算法，给数码看的，互联网与非互联网此处差异性也较为明显，非互联网数据平台对ETL定义与架构较为复杂)支持、 理清数据与数据之间的关系。(备注：Data cleaning 是指的数据清洗 数据质量相关不管是在哪个行业，是最令人头痛的问题，分业务域、技术域的数据质量问题，需要通过事前盘点、事中监控、事后调养，有机会在阐述)。
大家来看一张较为严谨的数据模型关系图：
数据模型是整个数据平台的数据建设过程的导航图。
有利于数据的整合。数据模型是整合各种数据源指导图，对现有业务与数据从逻辑层角度进行了全面描述，通过数据模型，可以建立业务系统与数据之间的映射与转换关系。排除数据描述的不一致性。如：同名异义、同物异名..。
减少多余冗余数据，因为了解数据之间的关系，以及数据的作用。在数据平台中根据需求采集那些用于分析的数据，而不需要那些纯粹用于操作的数据。
在面对企业复杂业务与成千上万的数据项进行设计时，没有哪个牛逼的人都记得住的，所以出现了按照某种层次规则去有组织并抽象与管理易用，由此诞生了概念模型、逻辑模型、物理模型 (备注 数据平台数据模型，而非数据挖掘的模型)。
数据模型在数据平台的数据仓库中是一个统称，严格上来讲分为概念模型、逻辑模型、物理模型。(备注：四类模型如何去详细构建文本不深讲，关于非互联网企业的数据模型网上非常多)
在“我所经历的大数据平台发展史：非互联网时代（上）”提到两位大师的架构与争论，进一步聚焦来说，争论点我的认为其实是在数据模型的支持上，Bill Inmon的EDW的原则是准三范式的设计、Ralph kilmbal是星型结构。
Bill Inmon对EDW 的定义是面向事物处理、面向数据管理，从数据的特征上需要坚持维护最细粒度的数据、维护最微观层次的数据关系、保存数据历史。所以在构建完毕的数据平台中可以从中映射并检查业务信息的完整性(同时也是养数据过程中的重要反馈点)，这种方式还可以找出多个系统相关和重合的信息，减少多个系统之间数据的重复定义和不一致性，减小了应用集成的难度。
该建设方式的要点是首先建立各个数据源业务的实体关系、然后再根据保存的主子实体关系、存储性能做优化。
Ralph kilmball 对DM(备注：数据集市，非挖掘模型)的定义是面向分析过程的(Analytical Process oriented)，因为这个模型对业务用户非常容易理解，同时为了查询也是做了专门的性能优化。所以星型、雪花模型很直观比较高性能为用户提供查询分析。
该方式的建模首先确定用户需求问题与业务需求数据粒度，构建分析所需要的维度、与度量值形成星型模型;(备注 涉及的复杂维度、退化维度等不在这个讨论范围)。
数据模型的业务建模阶段、领域概念模型阶段、逻辑模型阶段、物理模型阶段是超级学术与复杂的话题，而且在模型领域根据特点又分主数据(MDM)、CIF(企业级统一视图) 、通用模型(IBM 的金融、保险行业通用模型、 Teradata的 金融通用模型、 电信移动通用模型等)，锁涉及到术语”扩展“、”扁平化“、”裁剪“等眼花缭乱的建模手法，数据模型不同层次ODS、DWD
DWD、DW、ST的分层目的不同导致模型设计方法又不同。相信业界有很多大牛能讲的清楚的，以后有机会再交流。
本文带大家回忆了历史非互联网的数据平台发展与核心模型特点，当然数据平台的发展不是一步到位的，是经过无数人的智慧、努力反复迭代而逐渐演进的。
非互联网企业的数据平台发展，每一代的平台架构中的结构都是及其复杂的，比如ETL架构、数据模型架构、BD的架构、前端展现、元数据、数据质量等各方面，每一部分展开都是一个很深的话题，有机会再分享给大家。
互联网时代
前言，本篇幅将进入大家熟知的互联网时代，数据平台发展史仅是自己经历过由传统数据平台到互联网数据平台发展一些简单回忆，在这一篇章中将引用部分互联网数据平台架构，在这里仅作案例。
相信很多从传统行业转到互联网时是各种不适应，适应短则几个月，长则一年以上。进入到互联网有种感觉，它是一个擅长制造流行新概念的行业，“数据平台“，”数据产品“也不幸免。数据平台这词Data PlatForm 也无从考究是从什么时间点被提出的，仅知道自己刚进互联网时”数据平台“ 这个词狭义代指数据仓库了。
08年左右的Data Platform还泛指数据仓库，那时互联网企业的数据仓库刚兴起没几年，在建设思路上还是以传统数据平台的第二、三代架构为参照物实施建设的。自己猜测那时很多互联网企业也是使用Oracle、IBM、EMC 的软硬件区做的各类系统的实施，自然数据平台建设者都是来给电信、移动、制造业等各大数据仓库实施的甲方、乙方各类牛人。
行业的差异性导致业务不同，影响到数据平台源(数据源)的差异性、随着信息化共享与服务的这个“神奇”互联网行业快速发展，互联网业务逐渐的重视数据，所以互联网的从业者在看数据、使用数据的方式每一年也不同、大数据的各种技术也在快速更新中，各方面因素导致了互联网数据平台的建设、服务用户特点、数据模型与非互联网数据平台有较为显著差异。
数据源：
做数据的人，从非互联网进入到互联网最显著的特点是面对的数据源类型忽然多了起来，在传统企业数据人员面对的是结构化存储数据，基本来自excel、表格、DB系统等，在数据的处理技术上与架构上是非常容易总结的，但是在互联网因为业务独特性导致了所接触到的数据源特性多样化，网站点击日志、视频、音频、图片数据等很多非结构化快速产生与保存，在这样的数据源的多样化与容量下采用传统数据平台技术来处理当然是有些力不从心了(备注：IBM的科学家分析员道格.莱尼的一份数据增长报告基础上提出了大数据的4V特性 大数据4v特性网上概念很多大家可以问度娘)。
目前最火热的移动互联网,大家都在通过自己的手机、平板去访问网站、购物等所以每个人都是数据的生产者，移动用户在使用习惯上呈现移动化、碎片化，以至于业务特性、商业模式比传统互联网又有显著差别, 用户在不同位置需求是不同的、使用APP 也是不同的、手机终端类型也是多样化。这些差异性也导致移动互联网的数据与传统的互联网数据有一定的区别性。
例如买家通过Pc购物从浏览物品到支付可能在很短时间内完成，但是通过手购物碎片化就显得多一些，可能在某个空余时间浏览物品，保存或放入购物车，等有时间在去做支付。大约在2009年到2012年之间做用户行为分析感觉很多原有网页端拍下物品去支付，逐渐转为PC端下单通过移动端支付。
我在这里整理一个表格不同时代数据源的差异性(备注可能整理的有点不全)：
该图引用2013年“中国数据库大会大数据的实践与应用”
数据平台的用户：
总结下来互联网的数据平台“服务”方式迭代演进大约可以分为三个阶段。
阶段一 ：
约在2008年-2011年初的互联网数据平台，那时建设与使用上与非互联网数据平台有这蛮大的相似性，主要相似点在数据平台的建设角色、与使用到的技术上。
● 老板们、运营的需求主要是依赖于报表、分析报告、临时需求、商业智能团队的数据分析师去各种分析、临时需求、挖掘，这些角色是数据平台的适用方。
● ETL开发工程师、数据模型建模、数据架构师、报表设计人员 ，同时这些角色又是数据平台数据建设与使用方。
● 数据平台的技术框架与工具实现主要有技术架构师、JAVA开发等。
● 用户面对是结构化的生产数据、PC端非结构化log等 数据。
● ELT的数据处理方式(备注在数据处理的方式上，由传统企业的ETL 基本进化为ELT)。
现在的淘宝是从2004年开始构建自己的数据仓库，2004年是采用DELL 的6650单节点、到2005年更换为 IBM 的P550 再到2008年的12节点 Rac 环境。在这段时间的在IBM、EMC、Oracle 身上的投入巨大(备注：对这段历史有兴趣可以去度娘：“【深度】解密阿里巴巴的技术发展路径“)，同时淘宝的数据集群也变为国内最大的数据仓库集群。
我当时用Oracle 搭建的数据仓库做临时需求时，一个经过反复优化的SQL语句在晚上9点放入能够Running凌晨4点多而被电话中狂吼的DBA给kill掉，痛不欲生。
因为快速膨胀的数据量，在2010年开始考虑引进Greenplum 最为主平台提供强大的计算能力，但没想到快速爆炸的数据量让我们在POC测试阶段就把Greenplum的适合业务场景定位清楚了。
随着2010年引入了hadoop&hive平台进行新一代的数据平台的构建，此时的Greenplum 因为优秀的IO吞吐量以及有限的任务并发安排到了网站日志的处理以及给分析师提供的数据分析服务。
该阶段的数据模型是根据业务的特性采用退化、扁平化的模型设计方式去构建的(备注：将会在模型篇章详细讲解)。
阶段二：
互联网的数据平台除了受到技术、数据量的驱动外，同时还来自数据产品经理梳理用户的需求按照产品的思维去构建并部署在了数据的平台上。互联网是一个擅长制造流程新概念的行业。约在2011年到2014 年左右，随着数据平台的建设逐渐的进入快速迭代期，数据产品、数据产品经理这两个词逐渐的升温以及被广泛得到认可(备注：数据产品相关内容个人会在数据产品系列中做深入分享)，同时数据产品也随着需求、平台特性分为面向用户级数据产品、面向平台工具型产品两个维度分别去建设数据平台。
● 企业各个主要角色都是数据平台用户。
● 各类数据产品经理(偏业务数据产品、偏工具平台数据产品)推进数据平台的建设。
● 分析师参与数据平台直接建设比重增加。
● 数据开发、数据模型角色都是数据平台的建设者与使用者(备注：相对与传统数据平台的数据开发来说，逐渐忽略了数据质量的关注度，数据模型设计角色逐渐被弱化)。
● 用户面对是数据源多样化，比如日志、生产数据库的数据、视频、音频等非结构化数据 。
● 原有ETL中部分数据转换功能逐渐前置化，放到业务系统端进行(备注：部分原有在ETL阶段需要数据标准化一些过程前置在业务系统数据产生阶段进行，比如Log 日志。移动互联网的日志标准化。
互联网企业随着数据更加逐渐被重视，分析师、数据开发在面对大量的数据需求、海量的临时需求疲惫不堪，变成了资源的瓶颈，在当时的状态传统的各类的Report、Olap 工具都无法满足互联网行业个性化的数据需求。开始考虑把需求固定化变为一个面向最终用户自助式、半自助的产品来满足快速获取数据&分析的结果，当总结出的指标、分析方法(模型)、使用流程与工具有机的结合在一起时数据产品就诞生了(备注：当时为了设计一个数据产品曾经阅读了某个部门的2000多个临时需求与相关SQL)。
数据产品按照面向的功能与业务可以划分为面向平台级别的工具型产品、面向用户端的业务级数据产品。按照用户分类可以分为面向内部用户数据产品，面向外部用户个人数据产品、商户(企业)数据产品。
面向平台级别有数据质量、元数据、调度、资管配置、数据同步分发等等。(备注：关于数据产品的发展与数据产品体系更多内容，请关注个人写作“数据产品系列”)。
约2010-2012年的平台结构：
约2012-2013年的平台结构：
阶段三：
互联网业务的快速发展、大家已经从经营、分析的诉求重点转为数据化的精细运营上，随之而来的面临创新压力、如何做好精细化运营，数据平台的用户其聚焦在无法快速的响应日常需求其表现为做数据的已经无法满足当前业务日益增长的数据需求、运营上精细化已经对数据的粒度要求由高汇总逐渐转为过程化细粒度明细数据。
随着数据应用的深入，用数据往往不知道数据的口径与来源，加工数据的不知道业务含义，不同部门口径又是不一样，有的从交易来、有的从账务来。这里数据使用与数据加工上就出现了”断层”。有时在层级与功能部门前边也可能存在一个断层，对数据价值的内在衡量是不一样的，角色不一样，对于数据价值的的看法也就不同。
由于以上的种种问题，用数据的一些角色(分析师、运营或产品)会自己参与到从数据整理、加工、分析阶段。当数据平台变为自由全开放，使用数据的人也参与到数据的体系建设时，基本会因为不专业型，导致数据质量问题、重复对分数据浪费存储与资源、口径多样化等等原因。此时原有建设数据平台的多个角色可能转为对其它非专业做数据人员的培训、咨询与落地写更加适合当前企业数据应用的一些方案等。例如原有的数据产品会加入更多的在原有的数据建设中才有的一些流程让用户来遵守(统一的数据搜集、数据标准化的前置)。举例Log 埋点产品化、自动Report 的过程规范化(举例说明：原有一些运营自己建立的一些报表可能sql有问题就直接放入报表生成器中了。更改流程第一步现在MQ中验证完毕口径后，通过元数据解析进入到报表生成器中)、基于元数据驱动的ETL流程化等等，因为偏自助式、服务化的一些数据产品建立也将会导致数据平台迭代的演进。
● 给用户提供的各类丰富的分析、取数的产品，简单上手的可以使用。
● 原有ETL、数据模型角色转为给用户提供平台、产品、数据培训与使用咨询。
● 数据分析师直接参与到数据平台过程、数据产品的建设中去。
● 用户面对是数据源多样化，比如日志、生产数据库的数据、视频、音频等非结构化数据 。
在互联网这个大数据浪潮下，2016年以后数据平台是如何去建设?如何服务业务?
企业的不同发展阶段数据平台该如何去建设的?这个大家是可以思考的。但是我相信互联网企业是非常务实的，基本不会采用传统企业的自上而下的建设方式，互联网企业的业务快速变与迭代要求快速分析到数据，必须新业务数据迭代，老业务数据快速去杂。敏捷数据平台或许是种不错的选择方法之一吧!
互联网数据模型
在互联网时代被弱化的数据模型：
谈起数据模型就不得不提传统数据平台架构发展，我相信很多朋友都晓得传统数据平台的知识，其架构演进简单一句话说“基本上可以分为五个时代、四种架构”，但是到了互联网时代因为大数据快速膨胀与数据源类型多样化特点，从高阶架构上来看大约从传统数据平台第三代架构开始延续的，但是往后的发展从我自己的这一点知识上很难对互联网的数据平台做架构归类。
但是从数据平台建设与服务角色上还是有章可循的。就像上篇分享到那样，类比两个行业，互联网企业中员工年龄比非互联网企业的要年轻、受教育程度、对计算机的焦虑程度明显比传统企业要低、还偶遇其它各方面的缘故，导致了数据平台所面对用户群体与非互联网数据平台有所差异化。
传统行业与互联网行业数据平台用户特性我只选择前文章的两张图来表示
在传统数据平台要背后有一个完整数据仓库团队去服务业务方，业务方嗷嗷待哺的等待被动方式去满足。中低层数据基本不会对业务方开放，所以不管数据模型采用何种建模方式，主要满足当时数据架构规划即可。
互联网业务的快速发展使得大家已经从经营、分析的诉求重点转为数据化的精细运营上，如何做好精细化运营问题上来，当资源不够时用户就叫喊， 甚至有的业务方会挽起袖子来自己参与到从数据整理、加工、分析阶段。
此时呢，原有建设数据平台的多个角色(数据开发、模型设计)可能转为对其它非专业使用数据方，做培训、咨询与落地，写更加适合当前企业数据应用的一些方案与开发些数据产品等。
在互联网数据平台由于数据平台变为自由开放，大家使用数据的人也参与到数据的体系建设时，基本会因为不专业性，导致数据质量问题、重复对分数据浪费存储与资源、口径多样化、编码不统一、命名问题等等原因。数据质量逐渐变成一个特别突出的问题。
传统企业的数据源基本来自excel、表格、DB系统等，但在互联网有网站点击流日志、视频、音频、图片数据等很多非结构化快速产生与保存。移动互联网除了互联网那些外还含有大量定位数据、自动化传感器、嵌入式设备、自动化设备等，传统行业原有的数据平台技术对处理如此复杂而多样化的数据有些力不从心。
当数据模型逐渐被弱化后，数据架构导航图少了、难以建立业务系统与数据之间的映射与转换关系。数据描述经常不一致性。如：同名异义、同物异名。大量冗余的存在。数据模型被弱化(数据仓库模型)是传统企业与互联网企业一个蛮大的差异。但是呢，互联网企业也有自己特点，传统行业所涉及数据模型这个领域涉及的很多内容在互联网变成以其他的曲线救国的方式存在了。
在互联网曲线救国新解决
回顾在传统行业数据平台中，不管两位大师争论点数据模型的设计采用那种范式(Bill Inmon的EDW的原则是准三范式的设计、Ralph kilmbal是星型结构)但是都要非常重视数据源的质量问题。所以传统行业的数据模型会全盘考虑数据质量问题，并通过数据抽样分析给出合适的清洗口径。
上图来自2009年搞数据质量平台工具数据产品内容之一。
但是在互联网呢，数据质量在互联网数据平台变成了一种心病。(ps：我了解过一个公司，能让数据平台+数据分析师+业务多人“对数”对一年的还是不准的)。在应对数据的质量问题，目前互联网有些做法是把数据标准化前置到业务数据产生就做，从根源上去杜绝数据质量，但是这种场景比较实用在Log 日志的数据源中，比如移动互联网最近流行的基于事件模型“Event”模型，在日志产生时就规定好存储格式(备注：大家度娘搜索，“学习笔记：The Log(我所读过的最好的一篇分布式技术文章)” 对这个讲解很详细)。
在传统行业，目前还是以混合模型设计方式为主。在互联网的我所接触的一些业务，在参照传统数据模型方法论基础上逐步演进适合互联网数据的数据模型方法。
比如互联网金融等一些业务会参考传统金融行业对主题域的划分、OMG数据仓库元数据管理CWM模型、FSDM金融模型，再进一步考虑大数据处理特性去进行设计，所有从Hight Level 数据架构图看到主题层次划分与传统第三代数据仓库还是很多相似之处，当然模型架构也有分三层、四层、五层的。
不同的地方模型细节处理上已经完全不一样，比如数据的多样性、拉宽事实表、度量值单独存储、满足数据快速重生、维度的二次降维处理等、增加大量冗余列、增加大量派生列，结合自动化元数据来耦合、合并等相关管理。
上图是支付宝非常早期数据模型
上图是支付宝非常早期数据模型
我们常提到的多维模型在大数据处理下进行了退化维度处理。大家知道Olap多维模型，随着维度的增加事实表的数据量会成几何指数暴增，即使在现有的大数据技术、新的Olap 引擎对一个Cube的数据量要求也要在时间与数据量上需要做到用户使用容忍度的平衡。
类似Olap的应用在互联网这个奇特思维土壤中我经历过一个曲线救国方式(2011-2012年时设计多维挖掘分析数据产品背后的技术就是搜索引擎实现的)，现在应该也有新技术出现了来解决类似的问题。
上图为2012年产品UI之一。
上图是2011-2012年该产品系列背后当时使用的技术
互联网业务特点业务垂直拆分非常细，比如一个用户注册、密码找回的流程有可能存在好几个产品负责同一个业务流程不同环节，相关的一个策略、产品feature快速迭代上线等等都要数据评估。数据从前端埋点到采集然后再由各个环节到数据平台，再有数据分析师或各业 务部门去使用，基本拉长了时间周期。需求部门与实施部门能力和经验有千差万别的需求，造成了懂技术部门没有没有足够的精力完全理解业务部门奇形怪状需求，可能在各环节放缓与变的低效。
或许适合“敏捷”维度建模在当前是个不错的选择，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。互联网企业业务特点是变化非常迅速的，能稳定的业务达到65%算对数据平台是个福音了(根据对某宝宝的印象)剩余的业务变化迅速，必然导致数据模型快速上下线。
Kimball老人家提出的维度建模(备注，在本系列发展史得第一篇有介绍)围绕业务模型能够非常直观的表达出业务的数据关系， 但是在互联网NOSQL牺牲掉了关系型数据库的一致性、完整性等等很多东西。维度数据模型又基于这些大数据技术的，所以进化的更加轻量级与基于细节数据的维度退化建模(原有的缓慢变化维、快速变化维、大维、迷你维、父子维、雪花维为了适应互联网的大数据Nosql处理技术进行反规范化、化&数据冗余设计。
退化维度的反规范化设计一方面可以把一条查询语句所需要的所有数据组合起来放到一个地方存储 Key values 的方式(比如说商品有不同类型，每一种类型商品又有自己的不同属性，可以采用一对多、多对多的方式存储，例如把一个多维映射为一个Key value)。
讲到互联网数据平台就要提数据模型，提了数据模型就要提Nosql技术，
上图来自Nosql文档系列的一幅图
Nosql 是大数据处理的特征之一。互联网数据平台数据模型与NoSql技术还是蛮紧密的。这里有外文讲解Nosql Data modeling technigues 从技术角度讲解非常详(https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/)。
因为前边提到的大数据平台技术特性决定了传统edw模型、维度模型直接在互联网数据大数据平台部署或许还有“好些未知”障碍等待大家去克服。同时在传统数据建模用到的一些方法经过互联网熏陶或许演进成一种新的数据产品或方案吧。
