一文遍历大数据架构变迁史

从现在的企业发展来看，大家的诉求重点已经从经营与分析转为数据化的精细运营。在如何做好精细化运营过程中，企业也面临着来自创新、发展、内卷等的各方面压力。随着业务量、数据量增长，大家对数据粒度需求从之前的高汇总逐渐转为过程化的细粒度明细数据，以及从T+1的数据转为近乎实时的数据诉求。大量的数据需求、海量的临时需求，让分析师、数据开发疲惫不堪。这些职位也变成了企业资源的瓶颈，传统BI中的Report、OLAP等工具也都无法满足互联网行业个性化的数据需求。大家开始考虑如何把需求固定为一个面向最终用户自助式、半自助的产品，来快速获取数据并分析得到结果，数据通过各类数据产品对外更有针对性的数据价值传递。

在这十几年中，影响数据仓库、数据平台、数据中台、数据湖的演进变革的因素也很多，比如不断快速迭代的业务模式与膨胀的群体规模所带来的数据量的冲击，新的大数据处理技术的驱动。还有落地在数据中台上各种数据产品的建设，比如工具化数据产品体系、各种自助式的数据产品、平台化各种数据产品的建设。这些数据建设能力的泛化，也让更多的大众参与数据中台的建设中 ，比如一些懂SQL的用户以及分析师参与数据平台直接建设比重增加 。还有一些原本数据中台具备的能力也有一些逐步地被前置到业务系统进行处理。

数据仓库在国外发展多年，于大约在1998-1999年传入中国。进入中国以后，发展出了很多专有名词，比如数据仓库、数据中心、数据平台、数据中台、数据湖等，从大数据架构角度来看可用三个时代九种架构来做总结，其中前四代是传统数据仓库时代的架构，后面五代是大数据架构模式。其中有两个承前启后的地方：

• 一个特殊地方是，传统行业第三代架构与大数据第一代架构在架构形式上基本相似。传统行业的第三代架构可以算是用大数据处理技术重新实现了一遍。
• 传统行业第四代的架构中实时部分在现代用大数据实时方式做了新的落地。

三个时代：非互联网、互联网、移动互联网时代，每一种时代的业务特点、数据量、数据类型各不相同，自然数据架构也是有显著差异的。

行业域	非互联网	互联网	移动互联网
数据来源(相对于数据平台来讲)	结构化各类数据库(DB系统)、结构化文本、Excel表格等，少量word	Web、自定义、系统的日志，各类结构化DB数据、长文本、视频 主要是来自网页	除了互联网那些外还含有大量定位数据、自动化传感器、嵌入式设备、自动化设备等
数据包含信息	CRM客户信息、事务性ERP/MRPII数据、资金账务数据 等。	除了传统企业数据信息外，还含有用户各类点击日志、社交数据、多媒体、搜索、电邮数据等等	除了传统互联网的数据外，还含有Gps、穿戴设备、传感器各类采集数据、自动化传感器采集数据等等
数据结构特性	几乎都是结构化数据	非结构化数据居多	非结构化数据居多
数据存储/数据量	主要以DB结构化存储为主，从几百兆到 百G级别	文件形式、DB形式，流方式、 从TB到PB	文件形式、流方式、DB范式，非结构化 从TB到PB
产生周期	慢，几天甚至周为单位	秒或更小为单位	秒或更小为单位
对消费者行为采集与还原	粒度粗	粒度较细	粒度非常细
数据价值	长期有效	随着时间衰减	随着时间快速衰减

从数据到大数据的数据架构总结

我自己对传统数据仓库的发展，简单抽象为为五个时代、四种架构（或许也不是那么严谨）。五个时代大概，按照两位数据仓库大师Ralph kilmball、Bill Innmon在数据仓库建设理念上碰撞阶段来作为小的分界线：

• 大概在1991年之前，数据仓库的实施基本采用全企业集成的模式。
• 大概在1992年企业在数据仓库实施基本采用EDW的方式，Bill Innmon博士出版了《如何构建数据仓库》，里面清晰的阐述了EDW架构与实施方式。
• 1994-1996年是数据集市时代，这个时代另外一种维度建模、数据集市的方式较为盛行起来，其主要代表之一Ralph Kimball博士出版了他的第一本书“The DataWarehouse Toolkit”（《数据仓库工具箱》），里面非常清晰的定义了数据集市、维度建模。
• 大概在1996-1997年左右的两个架构竞争时代。
• 1998-2001年左右的合并年代。

在主要历史事件中提到了两位经典代表人物：Bill Innmon、Ralph kilmball。这两位在数据界可以算是元祖级别的人物。现在数据中台/平台的很多设计理念依然受到他俩90年代所提出方法论为依据。

经典的BIll Inmon和Ralph kilmball争论

Bill Inmon提出的遵循的是自上而下的建设原则，Ralph kilmball提出自下而上的建设原则，两种方法拥护者会在不同场合争论哪一种方法论更有优势。两位大师对于建设方法争论要点：

1. 其中Bill Inmon的方法论：认为仅仅有数据集市是不够的，提倡先必须得从企业级的数据模型角度入手来构建。企业级模型就有较为完善的业务主题域划分、逻辑模型划分，在解决某个业务单元问题时可以很容易的选择不同数据路径来组成数据集市。后来数据仓库在千禧年传到中国后，几个大实施厂商都是遵守该原则的实施方法，也逐渐的演进成了现在大家熟悉的数据架构中关于数据层次的划分：

• Ods-> DW-> ST->应用
• Ods->DWD->DW->DM ->应用
• Ods->DWD->DWB->DWS ->应用
• Ods->DWD->DW->ST（ADM）->应用

上个10年的国内实施数据仓库以及数据平台企业，有几家专业的厂商：IBM、Teradata、埃森哲、菲奈特(被东南收购)、亚信等。这些厂商针对自己领域服务的客户，从方案特点等一系列角度出发，在实施中对ODS层、EDW、DM等不同数据层逐步地赋予了各种不同的功能与含义。现在大家熟知的数据模型层次划分，基本上也是传承原有的Bill Inmon的方法论。

2. 数据集市年代的代表人物为Ralph kilmball，他的代表作是 《The Data Warehouse Toolkit》。这本书就是大名鼎鼎的《数据仓库工具箱》。企业级数据的建设方法主张自下而上建立数据仓库，极力推崇创建数据集市，认为数据仓库是数据集市的集合，信息总是被存储在多维模型中。这种思想从业务或部门入手，设计面向业务或部门主题数据集市。随着更多的不同业务或部门数据集市实施落地，此时企业可以根据需要来合并不同的数据集市，并逐步形成企业级的数据仓库，这种方式被称为自下而上(Botton-up)方法。这个方法在当时刚好与Bill Innmon的自上而下建设方法相反。

类比	BIll Inmon提出的方法论	Ralph kilmball提出的方法论
建设周期	需要花费大量时间	建设周期短、花费较少时间
维护难易度	容易维护	维护成本高
建设成本	前期投入大，后期建设成本低	前期投入较少，后续迭代成本与之前投入差不多
建设周期	周期长，见效慢	短、平、快
需要的团队类型	专业团队搭建	比较专业团队搭建，少量人参与
数据集成需求	全企业生命周期数据集成	企业垂直业务领域数据集成
面向用户群体	潜在的全企业用户	业务需求部门
专业术语	面向主题、随时间而变化、保留历史、数据集成	面向具体业务部门的一份比较窄的数据快照，维度建模、雪花模型、星型模型
数据模型	准三范式设计原则	星型结构、雪花结构

随着数据仓库的不断实践与迭代发展，从争吵期进入到了合并的时代，其实争吵的结果要么一方妥协，要么新的结论出现。Bill inmon与Ralph kilmball的争吵没有结论，干脆提出一种新的架构包含对方，也就是后来Bill Inmon提出的CIF（corporation information factory）信息工厂的架构模式，这个架构模式将Ralph kilmball的数据集市包含了进来，有关两种数据仓库实施方法论的争吵才逐步地平息下来。

非互联网四代架构

第一代edw架构

现在数据建设中使用到的“商业智能” 、“信息仓库”等很多专业术语、方法论，基本上是在上世纪60年代至90年代出现的。比如“维度模型”这个词是上世纪60年代GM与Darmouth College大学第一次提出， “DatawareHouse”、“事实” 是在上个世纪70年代BIll Inmon明确定义出来的，后来90年代BIll Inmon出版《如何构建数据仓库》一书更加体系化的与明确定义了如何构建数据仓库，这套方法在落地上形成了第一代数据仓库架构。

在第一代的数据仓库中，清晰地定义了数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented) 、集成的( Integrate ) 、相对稳定的(Non -Volatile ) 、反映历史变化( Time Variant)的数据集合，用于支持管理决策（Decision Marking Support）。首先，数据仓库(Data Warehouse)是用来支持决策的、面向主题的用来支撑分析型数据处理的，这里有别于企业使用的数据库。数据库、数据仓库小的区别：

• 数据库系统的设计目标是事务处理。数据库系统是为记录更新和事务处理而设计，数据的访问的特点是基于主键，大量原子，隔离的小事务，并发和可恢复是关键属性，最大事务吞吐量是关键指标，因此数据库的设计都反映了这些需求。
• 数据仓库的设计目标是决策支持。历史的、摘要的、聚合的数据比原始的记录重要的多。查询负载主要集中在即席查询和包含连接，聚合等复杂查询操作上。
• 其次，数据仓库(Data Warehouse)是对多种异构数据源进行有效集成与处理，是按照主题的方式对数据进行重新整合，且包一般不怎么修改的历史数据，一句话总结面向主题、集成性、稳定性和时变性。

数据仓库(Data Warehouse)从特点上来看：

• 数据仓库是面向主题的。
• 数据仓库是集成的，数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库。
• 数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及的操作主要是数据的查询。
• 数据仓库是随时间而变化的，传统的关系数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求，它在商业领域取得了巨大的成功。

数据仓库和数据库系统的区别，一言蔽之：OLAP和OLTP的区别。数据库支持是OLTP，数据仓库支持的是OLAP。

第二代大集市架构

第二代就是Ralph kilmball的大集市的架构。第二代架构基本可以成为总线型架构，从业务或部门入手，设计面向业务或部门主题数据集市。Kilmball的这种构建方式可以不用考虑其它正在进行的数据类项目实施，只要快速满足当前部门的需求即可，这种实施的好处是阻力较小且路径很短。但是考虑到在实施中可能会存在多个并行的项目，是需要在数据标准化、模型阶段是需要进行维度归一化处理，需要有一套标准来定义公共维度，让不同的数据集市项目都遵守相同的标准，在后面的多个数据集市做合并时可以平滑处理。比如业务中相似的名词、不同系统的枚举值、相似的业务规则都需要做统一命名，这里在现在的中台就是全域统一ID之类的东西。

主要核心：

• 一致的维度，以进行集成和全面支持。一致的维度具有一致的描述性属性名称、值和含义。
• 一致的事实是一致定义的；如果不是一致的业务规则，那么将为其指定一个独特的名称。业务中相似的名词、不同系统的枚举值、相似的业务规则都需要做统一命名。
• 建模方式：星型模型、雪花模型。

第三代汇总维度集市&CIF2.0数仓结构

CIF（corporation information factor）信息工厂（作者备注，关于Cif的英文版文章名字Corporate Information Factory (CIF) Overview），Bill Inmon认为企业的发展会随着信息资源重要性会逐步的提升，会出现一种信息处理架构，类似工厂一样能满足所有信息的需求与请求。这个信息工厂的功能包含了数据存储与处理（活跃数据、沉默数据），支持跨部门甚至跨企业的数据访问与整合，同时也要保证数据安全性等。刚好CIF架构模式也逐步的变成了数据仓库第三代架构。为什么把这个CIF架构定义成一个经典架构呢，因为CIF的这种架构总结了前面提到的两种架构的同时，又把架构的不同层次定义得非常明确。

例如CIF 2.0主要包括集成转换层（Integrated and Transformation Layer）、操作数据存储（Operational Data Store）、数据仓库（Enterprise Data Warehouse）、数据集市（Data Mart）、探索仓库（Exploration Warehouse）等部件。Data Mart分为后台（Back Room）和前台（Front Room）两部分。后台主要负责数据准备工作，称为数据准备区（Staging Area），前台主要负责数据展示工作，称为数据集市（Data Mart）。

这个经典的架构在后来2006年~2012年进入到这个领域的从业者，乃至现在有些互联网企业的数据平台架构也是相似的。

第四代OPDM操作实时数仓

OPDM大约是在2011年提出来的，严格上来说，Opdm操作型数据集市（仓库）是实时数据仓库的一种，他更多的是面向操作型数据而非历史数据查询与分析。在这里很多人会问到什么是操作型数据？比如财务系统、CRM系统、营销系统生产系统，通过某一种机制实时的把这些数据在各数据孤岛按照业务的某个层次有机的自动化整合在一起，提供业务监控与指导。

互联网的五代大数据处理架构

在文章的开头有提过，传统行业第三代架构与大数据第一代架构在架构形式上基本相似，只不过是通过大数据的处理技术尝试对传统第三架构进行落地的。比如说在Hadoop&Hive刚兴起的阶段，有用SyaseIQ、Greenplum等技术来作为大数据处理技术，后来Hadoop&hive以及Facebook Scribe、Linkedin kafka等逐步开源后又产生了新的适应互联网大数据的架构模式。

后续阿里巴巴淘系的TimeTunnel等更多的近百种大数据处理的开源技术，进一步促进了整个大数据处理架构与技术框架的发展，我在后面会给出一个比较完善截止到目前所有技术的数据处理框架。按照大数据的使用场景、数据量、数据的类型，在架构上也基本上分为流式处理技术框架、批处理技术框架等， 所以互联网这五代的大数据处理框架基本上是围绕着批处理、流式处理以及混合型架构这三种来做演进。

第一代离线大数据统计分析技术架构

这个结构与第三代的数据处理架构非常相似，具体如下图所示：

数据阶段	传统行业第三代架构	第一代离线大数据统计架构
数据源	结构化数据为主(数据库数据、内部办公数据、财务数据等)、非结构化数据很少或者是没有	结构化数据为主(数据库数据、内部办公数据、财务数据等)、结构化数据开始多起来
数据处理	名词：ETL为主，在数据如中央仓库之前已经开始很多的数据转换、归一化的处理技术：Datastage、informa、Dts、C、脚本等等	名词：ELT为主，主要是数据采集传输与归集、很少做数据归一化以及转换处理 。主要是把数据先归集到中央库自作处理技术：kafka、Datax等
数据中央处理	技术：Oracle、DB2、SybaseIQ、Teradata数据模型：维度模型、准三范式	技术：hadoop、hive、spark数据模型：维度模型、大宽表等
数据应用	成型的解决方案产品：Report、OLAP、在线分析等	成型的软件产品变少、开源技术、自助研发产品变多起来

第二代流式架构

流式的应用场景非常广泛， 比如搜索、推荐、信息流等都是在线化的，对数据实时性的要求变更高，自然计算与使用是同步进行的。随着业务的复杂化，数据的处理逻辑更加复杂，比如各种维度交叉、关联、聚类，以及需要更多算法或机器学习。这些应用场景可以完全地分为两类：事件流、持续计算。

• 事件流，就是业务相对固定，只是数据在业务的规则下不断的变化。
• 持续计算，适合购物网站等场景。

流失处理架构比上一代离线处理框架相比省掉了原有的ETL/ELT过程，数据流留过数据处理通道并进行实时处理与计算，处理结果通过消息的方式推送数据消费者。流式计算框架舍弃了大数据离线批量处理模式，只有很少的数据存储，所以数据保存周期非常短。如果有历史数据场景或很复杂历史数据参与计算的场景，实现起来难度就比较大。

现在一些场景，会把流式计算的结果数据周期性地存到批处理的数据存储区域。如果有场景需要使用历史数据，流式计算框架会把保存的历史结果用更新的方式进行加载，再做进一步处理。

第三代Lambda大数据架构

Lambda架构是由Twitter工程师南森·马茨（Nathan Marz）提出的，是一种经典的、实施广泛的技术架构。后来出现的其他大数据处理架构也是Lambda架构的优化或升级版。Lambda架构有两条数据链路，一条兼顾处理批量、离线数据结构，一条是实时流式处理技术 。

• 批量离线处理流在构建时大部分还是采用一些经典的大数据统计分析方法论，在保证数据一致性、完整性的同时还会对数据按照不同应用场景进行分层。
• 实时流式处理主要是增量计算，也会跑一些机器学习模型等。为了保证数据的一致性， 实时流处理结果与批量处理结果会有一个合并动作。

Lambda架构主要的组成是批处理、流式处理、数据服务层这三部分。

• 批处理层(Bathchlayer)：Lambda架构核心层之一，批处理接收过来的数据，并保存到相应的数据模型中，这一层的数据主题、模型设计的方法论是继承面向统计分析离线大数据中的。而且一般都会按照比较经典的ODS、DWD、DWB、ST/ADM的层次结构来划分。
• 流式处理层(Speed Layer)：Lambda另一个核心层，为了解决比如各场景下数据需要一边计算一边应用以及各种维度交叉、关联的事件流与持续计算的问题，计算结果在最后与批处理层的结果做合并。
• 服务层(Serving layer)：这是Lambda架构的最后一层，服务层的职责是获取批处理和流处理的结果，向用户提供统一查询视图服务。

Lamabda架构理念从出现到发展这么多年，优缺点非常明显。比如稳定与性能上的优势，ETL处理计算利用晚上时间来做，能复用部分实时计算的资源。劣势，两套数据流因为结果要做合并，所有的算法要实现两次，一次是批处理、一次是实时计算，最终两个结果还得做合并显得会很复杂。

Kappa大数据架构

在Lamadba架构下需要维护两套的代码，为了解决这个问题，LinkedIn公司的Jay Kreps结合实际经验与个人思考提出了Kappa架构。Kappa架构核心是通过改进流式计算架构的计算、存储部分来解决全量的问题，使得实时计算、批处理可以共用一套代码。Kappa架构认为对于历史数据的重复计算几率是很小的，即使需要，可以通过启用不同的实例的方式来做重复计算。其中Kappa的核心思想是：

• 用Kafka或者类似MQ队列系统收集各种各样的数据，需要几天的数据量就保存几天。
• 当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
• 当新的实例做完后，停止老的流计算实例，并把一些老的结果删除。

Kappa架构的优点在于将实时和离线代码统一起来，方便维护而且统一了数据口径。Kappa架构与Lamabda架构相比，其优缺点是：

• Lambda架构需要维护两套跑在批处理和实时流上的代码，两个结果还需要做merge， Kappa架构下只维护一套代码，在需要时候才跑全量数据。
• Kappa架构下可以同时启动很多实例来做重复计算，有利于算法模型调整优化与结果对比，Lamabda架构下，代码调整比较复杂。所以kappa架构下，技术人员只需要维护一个框架就可以，成本很小。
• kappa每次接入新的数据类型格式是需要定制开发接入程序，接入周期会变长。
• Kappa这种架构过度依赖于Redis、Hbase服务，两种存储结构又不是满足全量数据存储的，用来做全量存储会显得浪费资源。

Unified大数据架构

“Unifield架构则更激进，将机器学习和数据处理整合为一体，Unifield在Lambda基础上进行升级，在流处理层新增了机器学习层。数据经过数据通道进入数据湖，新增了模型训练部分，并且将其在流式层进行使用。同时流式层不单使用模型，也包含着对模型的持续训练。”

IOTA架构

IOTA大数据架构是一种基于AI生态下的、全新的数据架构模式，这个概念由易观于2018年首次提出。IOTA的整体思路是设定标准数据模型，通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中，以统一的数据模型贯穿始终，从而提高整体的计算效率，同时满足计算的需要，可以使用各种Ad-hoc Query来查询底层数据。

主要有几个特点：

• 去ETL化：ETL和相关开发一直是大数据处理的痛点，IOTA架构通过Common Data Model的设计，专注在某一个具体领域的数据计算，从而可以从SDK端开始计算，中央端只做采集、建立索引和查询，提高整体数据分析的效率。
• Ad-hoc即时查询：鉴于整体的计算流程机制，在手机端、智能IOT事件发生之时，就可以直接传送到云端进入real time data区，可以被前端的Query Engine来查询。此时用户可以使用各种各样的查询，直接查到前几秒发生的事件，而不用在等待ETL或者Streaming的数据研发和处理。
• 边缘计算（Edge-Computing）：将过去统一到中央进行整体计算，分散到数据产生、存储和查询端，数据产生既符合Common Data Model。同时，也给与Realtime model feedback，让客户端传送数据的同时马上进行反馈，而不需要所有事件都要到中央端处理之后再进行下发。

总结

大数据架构的每一代的定义与出现是有必然性的， 当然没有一个严格上的时间区分点。直接给出一个每种架构比较：

架构	优点	缺点	适用场景
离线大数据统计分析技术架构	简单，易懂，对于BI系统来说，基本思想没有发生变化，变化的仅仅是技术选型，用大数据架构替换掉BI的组件。	对于大数据来说，没有BI下如此完备的Cube架构，虽然目前有kylin，但是kylin的局限性非常明显，远远没有BI下的Cube的灵活度和稳定度，因此对业务支撑的灵活度不够，所以对于存在大量报表，或者复杂的钻取的场景，需要太多的手工定制化，同时该架构依旧以批处理为主，缺乏实时的支撑。	数据分析需求依旧以BI场景为主，但是因为数据量、性能等问题无法满足日常使用。
流式架构	没有臃肿的ETL过程，数据的实效性非常高。	对于流式架构来说，不存在批处理，因此对于数据的重播和历史统计无法很好的支撑。对于离线分析仅仅支撑窗口之内的分析。	预警，监控，对数据有有实时性要求的场景。
Lambda架构	既有实时又有离线，对于数据分析场景涵盖的非常到位。	离线层和实时流虽然面临的场景不相同，但是其内部处理的逻辑却是相同，因此有大量荣誉和重复的模块存在。	同时存在实时和离线需求的情况。
Kappa架构	Kappa架构解决了Lambda架构里面的冗余部分，以数据可重播的超凡脱俗的思想进行了设计，整个架构非常简洁。	虽然Kappa架构看起来简洁，但是实施难度相对较高，尤其是对于数据重播部分。	和Lambda类似，改架构是针对Lambda的优化。
Unifield架构	Unifield架构提供了一套数据分析和机器学习结合的架构方案，非常好的解决了机器学习如何与数据平台进行结合的问题。	Unifield架构实施复杂度更高，对于机器学习架构来说，从软件包到硬件部署都和数据分析平台有着非常大的差别，因此在实施过程中的难度系数更高。	有着大量数据需要分析，同时对机器学习方便又有着非常大的需求或者有规划。
IOTA架构	去ETL化、支持Ad-hoc即时查询和边缘计算。	代码漏洞较多，通过收费方式向社区提供漏洞修复代码。	IOTA用于物联网设备，实现万物互联、系统自治。

大数据处理技术栈

• 按照数据采集-传输-落地到存储层，再通过调度调起计算数据处理任务把整合结果数据存到数据仓库以及相关存储区域中。
• 通过管理层/ide进行数据管理或数据开发。
• 通过OLAP 、分析、算法、可视化、微服务层对外提供数据服务与数据场景化应用。

这个技术栈暂时没有按照没有按照批处理、流式技术的分类的角度来分类，稍微有点遗憾。