在“关于数字化转型的几个见解”、“唯一性定理中的数据中台”两篇文章中，提到了数据中台发展问题。比如概念发展太快，信息量过载，以及存在广义、狭义的数据中台定义的差别等，涉及到的这些知识都离不开数据架构的范畴，所以这一篇我会通过大数据架构发展的视角来总结与分享。（一些知识继承自己在2015年写的《从数据仓库到大数据，数据平台这25年是怎样进化的？》，又名我所经历的大数据平台发展史系列），主要涉及三个方面：

从现在的企业发展来看，大家的诉求重点已经从经营与分析转为数据化的精细运营。在如何做好精细化运营过程中，企业也面临着来自创新、发展、内卷等的各方面压力。随着业务量、数据量增长，大家对数据粒度需求从之前的高汇总逐渐转为过程化的细粒度明细数据，以及从T+1的数据转为近乎实时的数据诉求。

大量的数据需求、海量的临时需求，让分析师、数据开发疲惫不堪。这些职位也变成了企业资源的瓶颈，传统BI中的 Report、OLAP 等工具也都无法满足互联网行业个性化的数据需求。

大家开始考虑如何把需求固定为一个面向最终用户自助式、半自助的产品，来快速获取数据并分析得到结果，数据通过各类数据产品对外更有针对性的数据价值传递。

在这十几年中，影响数据仓库、数据平台、数据中台、数据湖的演进变革的因素也很多，比如：

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

其中有两个承前启后的地方：

如下图所示：

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

我自己对传统数据仓库的发展，简单抽象为为五个时代、四种架构（或许也不是那么严谨）。 

五个时代大概，按照两位数据仓库大师 Ralph kilmball、Bill Innmon 在数据仓库建设理念上碰撞阶段来作为小的分界线：

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

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

两位大师对于建设方法争论要点：

其中Bill Inmon的方法论：认为仅仅有数据集市是不够的，提倡先必须得从企业级的数据模型角度入手来构建。企业级模型就有较为完善的业务主题域划分、逻辑模型划分，在解决某个业务单元问题时可以很容易的选择不同数据路径来组成数据集市。

后来数据仓库在千禧年传到中国后，几个大实施厂商都是遵守该原则的实施方法，也逐渐的演进成了现在大家熟悉的数据架构中关于数据层次的划分 ：

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

现在大家熟知的数据模型层次划分，基本上也是传承原有的Bill Inmon的方法论。

数据集市年代的代表人物为 Ralph kilmball，他的代表作是 《The Data Warehouse Toolkit》。这本书就是大名鼎鼎的《数据仓库工具箱》。企业级数据的建设方法主张自下而上建立数据仓库，极力推崇创建数据集市，认为数据仓库是数据集市的集合，信息总是被存储在多维模型中。

这种思想从业务或部门入手，设计面向业务或部门主题数据集市。随着更多的不同业务或部门数据集市实施落地，此时企业可以根据需要来合并不同的数据集市，并逐步形成企业级的数据仓库，这种方式被称为自下而上(Botton-up)方法。这个方法在当时刚好与 Bill Innmon 的自上而下建设方法相反。 

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

1）第一代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。

2）第二代大集市架构

第二代就是 Ralph kilmball 的大集市的架构。第二代架构基本可以成为总线型架构，从业务或部门入手，设计面向业务或部门主题数据集市。Kilmball 的这种构建方式可以不用考虑其它正在进行的数据类项目实施，只要快速满足当前部门的需求即可，这种实施的好处是阻力较小且路径很短。

但是考虑到在实施中可能会存在多个并行的项目，是需要在数据标准化、模型阶段是需要进行维度归一化处理，需要有一套标准来定义公共维度，让不同的数据集市项目都遵守相同的标准，在后面的多个数据集市做合并时可以平滑处理。比如业务中相似的名词、不同系统的枚举值、相似的业务规则都需要做统一命名，这里在现在的中台就是全域统一 ID 之类的东西。

主要核心：

3）第三代汇总维度集市&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 年进入到这个领域的从业者，乃至现在有些互联网企业的数据平台架构也是相似的。

4）第四代 OPDM操作实时数仓

OPDM 大约是在 2011 年提出来的，严格上来说，Opdm  操作型数据集市（仓库）是实时数据仓库的一种，他更多的是面向操作型数据而非历史数据查询与分析。

在这里很多人会问到什么是操作型数据？比如财务系统、CRM 系统、营销系统生产系统，通过某一种机制实时的把这些数据从各数据孤岛按照业务的某个层次有机的自动化整合在一起，提供业务监控与指导。

在文章的开头有提过，传统行业第三代架构与大数据第一代架构在架构形式上基本相似，只不过是通过大数据的处理技术尝试对传统第三架构进行落地的。

比如说在Hadoop&Hive 刚兴起的阶段，有用SyaseIQ、Greenplum等技术来作为大数据处理技术，后来Hadoop&hive以及Facebook Scribe、Linkedin kafka等逐步开源后又产生了新的适应互联网大数据的架构模式。

后续阿里巴巴淘系的TImeTunnel等更多的近百种大数据处理的开源技术，进一步促进了整个大数据处理架构与技术框架的发展，我在后面会给出一个比较完善截止到目前所有技术的数据处理框架。

按照大数据的使用场景、数据量、数据的类型，在架构上也基本上分为流式处理技术框架、批处理技术框架等， 所以互联网这五代的大数据处理框架基本上是围绕着批处理、流式处理以及混合型架构这三种来做演进。

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

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

这代架构定位是为了解决传统BI的问题，简单来说，数据分析的业务没有发生任何变化，但是因为数据量、性能等问题导致系统无法正常使用，需要进行升级改造，此类架构便是为了解决这个问题。

2）第二代流式架构

流式的应用场景非常广泛， 比如搜索、推荐、信息流等都是在线化的，对数据实时性的要求变更高，自然计算与使用是同步进行的。

随着业务的复杂化，数据的处理逻辑更加复杂，比如各种维度交叉、关联、聚类，以及需要更多算法或机器学习。这些应用场景可以完全地分为两类：事件流、持续计算。

流式计算处理框架与第一代的大数据处理框架相比，去掉了原有的ETL过程，数据流过数据通道时得到处理，处理结果通过消息的方式推送数据消费者。

流式计算框架舍弃了大数据离线批量处理模式，只有很少的数据存储，所以数据保存周期非常短。如果有历史数据场景或很复杂历史数据参与计算的场景，实现起来难度就比较大。

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

3）第三代 Lambda 大数据架构

Lambda架构是由Twitter工程师南森·马茨（Nathan Marz）提出的，是一种经典的、实施广泛的技术架构。后来出现的其他大数据处理架构也是Lambda 架构的优化或升级版。

Lambda 架构有两条数据链路，一条兼顾处理批量、离线数据结构，一条是实时流式处理技术。

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

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

4）Kappa 大数据架构

在Lamadba 架构下需要维护两套的代码，为了解决这个问题，LinkedIn公司的Jay Kreps 结合实际经验与个人思考提出了Kappa 架构。

Kappa 架构核心是通过改进流式计算架构的计算、存储部分来解决全量的问题，使得实时计算、批处理可以共用一套代码。Kappa 架构认为对于历史数据的重复计算几率是很小的，即使需要，可以通过启用不同的实例的方式来做重复计算。

其中Kappa的核心思想是：

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

Kappa 架构与Lamabda 架构相比，其优缺点是：

5）Unified 大数据架构

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

6）IOTA架构

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

主要有几个特点：

可能是由于我接触到的范围有限，暂时还没有遇到一家企业完整按照IOTA这个架构模式来实施的，暂时没有更多的个人经验来分享这块。

7）小结

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

架构讲完了，落地肯定是离不开技术的，我之前花了不少时间整理了一下目前大数据方向的技术栈的内容。

分享完了架构，再从大数据技术栈的角度来看看对应的数据采集、数据传输、数据存储、计算、ide管理、分析可视化微服务都有哪些技术，下图的技术栈我花了蛮多的时间梳理的。

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

Data Mesh  是在2019年左右，由 ThoughtWorks的首席技术顾问Zhamak Dehghani提出的（《How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh》https://martinfowler.com/articles/data-monolith-to-mesh.html）。她将对客户进行企业数据平台实施过程出现的问题和面向领域设计中的微服务结合了起来，思考出来了一种新式面向域的数据架构。

企业面向数据平台的实施中，不管是数据BI系统，还是基于大数据(数据湖)架构模式，或者是基于云数据平台，无一例外地延续着一个架构（Monolithic Architecture）的核心模式，只是这个架构的表现形式从一个严格规范化的数据仓库，到更加专业的大数据（数据湖），最终转化成一个多种实践模式的混合。

现在这些大数据平台实施与解决方案难以通过简单复制来达到规模化、商业化，企业数据平台项目实施要三到五年的时间，巨大的投入使得投入产出比不够高，很难获取预期的收益。原文提到Zhamak Dehghani基于对基于对企业数据平台架构现状和弊端以及微服务的视角提出了Data Meth 面向域的分布式架构模式。这个架构模式有四个特点：

讲一下自己的理解(可能理解还是比较浅)：

自己也在思考未来给企业提供的数据服务能力是什么样子，以及基于元数据驱动数据中台/平台是什么样子的。

自己在2015年时曾经写过一篇从数据团队组织变化角度来分享大数据的架构进化的文章，这次从大数据处理架构做了一个发展总结，两个角度基本上涵盖了数据中台/平台建设比较重点两个问题。

曾提到一个话题：数据中台是有组织结构的保障，很多地方都有提到数据中台必须得有强力的组织上的保障！确实需要吗？我的观点是什么呢？将在该系列的下一篇给大家讲解数据中台的组织结构。

欢迎各位在评论区留言讨论~