大数据架构变迁史

科技之歌

于 2024-08-19 16:45:55 发布

阅读量1.1k

点赞数 22

分类专栏：数字化转型文章标签：大数据 spark 分布式

本文链接：https://blog.csdn.net/kunpengtingting/article/details/141326060

版权

数字化转型专栏收录该内容

18 篇文章 0 订阅

订阅专栏

引言

当前企业界的发展态势表明，企业的核心关注点已从传统的经营分析与策略，转向了基于数据的精细化运营管理。在追求精细化运营的征途上，企业正遭遇来自创新挑战、发展加速及内部竞争加剧等多重压力。随着业务规模的扩大和数据量的激增，数据需求从高度汇总型向深入过程的细粒度明细数据转变，同时，数据时效性要求也从T+1的滞后性提升至近乎即时的需求。

这一转变带来了前所未有的数据需求量和频繁的临时查询任务，使得数据分析师和数据开发人员承受巨大压力，成为企业资源调配的瓶颈。传统商业智能（BI）工具如报表（Report）和在线分析处理（OLAP）等，已难以满足互联网行业对个性化数据洞察的迫切需求。因此，业界开始探索将数据需求封装为面向终端用户的自助或半自助式数据产品，旨在加速数据获取与分析过程，并通过多样化的数据产品实现数据价值的精准传递。数据产品的诞生是指标体系、分析方法（模型）、使用流程与工具深度融合的产物。随着数据中台与数据平台建设的加速，数据产品及其产品经理的角色日益受到重视，相关方法论也逐步体系化、具体化，成为各大企业竞相争夺的宝贵资源。

回顾过去十余年，数据仓库、数据平台、数据中台、数据湖等架构的演进，深受快速变化的业务模式、庞大的用户群体所带来的数据洪流影响，同时也得益于大数据处理技术的不断创新与推动。数据中台上各类数据产品的构建，如工具化、自助式及平台化的数据产品体系，不仅丰富了数据应用生态，还促进了数据建设能力的普及化，使得更多具备SQL基础的用户和分析师能够直接参与到数据平台的建设中来。此外，部分原本由数据中台承担的功能正逐步前移至业务系统层面，进一步提升了数据处理的灵活性和效率。

大数据架构发展

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

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

如下图所示

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

表格源自：《我所经历的大数据平台发展史》

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

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

五个时代大概，按照两位数据仓库大师 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强调，单纯依赖数据集市是不足以支撑复杂的企业级数据需求的，因此主张从构建企业级数据模型作为起点。这种企业级模型通过精细的业务主题域划分和逻辑模型设计，为解决特定业务问题提供了灵活多样的数据路径组合，从而轻松构建出所需的数据集市。

当数据仓库的概念在21世纪初引入中国后，多家领先的实施厂商迅速采纳了Bill Inmon的这一原则，并在实践中不断演进，最终形成了当前广泛认可的数据架构层次划分体系。这些层次通常包括：

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

在过去的十年里，中国市场上涌现出了一批专业的数据仓库与数据平台实施厂商，如IBM、Teradata、埃森哲、菲奈特（后并入东南集团）、亚信等。这些厂商根据各自服务领域的特性和客户需求，对ODS层、EDW（Enterprise Data Warehouse）、DM等数据层次进行了深度定制与功能拓展，赋予了它们更加丰富和具体的含义。时至今日，我们所熟知的数据模型层次划分体系，在很大程度上仍然是对Bill Inmon方法论精髓的传承与发展。

2. 在数据集市兴起的时代，Ralph Kimball标志性著作《The Data Warehouse Toolkit》深刻影响了企业级数据建设的路径。Kimball倡导的是一种自下而上的数据仓库构建策略，特别强调从数据集市作为起点，认为数据仓库本质上是由多个数据集市汇聚而成，而这些数据集市则基于多维模型存储信息，紧密围绕业务或部门的需求设计。

该策略倡导从具体的业务场景或部门需求出发，首先构建服务于这些特定主题的数据集市。随着越来越多针对不同业务或部门的数据集市被成功实施并投入应用，企业便拥有了灵活的选择权，可以根据实际需求将这些分散的数据集市进行整合，逐步构建起一个覆盖全企业的数据仓库。这一过程便是典型的自下而上（Bottom-up）方法，它与Bill Inmon所倡导的、从企业级数据模型出发的自上而下（Top-down）建设方法形成了鲜明对比。

随着数据仓库技术的持续实践与不断演进，其发展历程从初期的激烈争论转向了融合并蓄的新阶段。Bill Inmon与Ralph Kimball之间的理论交锋，并未直接决出胜负，而是催生了创新的火花。Bill Inmon提出了CIF（Corporate Information Factory，企业信息工厂）这一架构模式，该模式巧妙地融入了Ralph Kimball所倡导的数据集市概念。这一创举不仅展现了双方思想的融合，共同推动了数据仓库领域向更加成熟、包容的方向发展。

非互联网四代架构

第一代 edw 架构

现代数据建设所依托的“商业智能”、“信息仓库”等术语及方法论，其根源可追溯至上世纪60至90年代。其中，“维度模型”概念滥觞于60年代GM与Dartmouth College的合作研究；而“Data Warehouse”及“事实”术语则由Bill Inmon在70年代首次明确界定。至90年代，Inmon的《如何构建数据仓库》一书进一步系统化地阐述了构建方法，奠定了第一代数据仓库架构的基础。

该架构中，数据仓库被定义为一种面向特定主题、集成化、非易失性且随时间变化的数据集合，旨在为企业管理决策提供强有力的支持。

数据仓库 (Data Warehouse) 是用来支持决策的、面向主题的用来支撑分析型数据处理的，不同于企业使用的数据库。

数据库、数据仓库小的区别：

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

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

数据仓库是面向主题的。

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

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

第二代大集市架构

第二代架构，以Ralph Kimball提出的大集市架构为代表，实质上是一种总线型架构策略。它侧重于从具体业务或部门的角度出发，设计并构建面向这些业务或部门主题的数据集市。Kimball的这种方法强调快速响应，允许在构建过程中暂时忽略其他并行进行的数据类项目，专注于迅速满足当前部门的迫切需求，从而减少了实施阻力和缩短了实现路径。

然而，在实际操作中，鉴于可能存在的多个并行项目环境，数据标准化和模型设计阶段变得尤为重要。这要求进行维度归一化处理，即确立一套统一的标准来定义公共维度，确保所有不同的数据集市项目都能遵循这一标准。这样做的目的是在后续需要将多个数据集市进行整合时，能够顺利进行且减少冲突。具体来说，业务中相似的术语、跨系统的枚举值、以及相似的业务规则都需要进行统一命名和标准化处理，类似于现代中台架构中采用的全域统一ID等机制，以实现数据的无缝对接和整合。

主要核心：

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

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

CIF（企业信息因子）概念，源自“Corporate Information Factory (CIF) Overview”，由Bill Inmon提出，他认为随着企业对信息资源的依赖加深，将出现类似工厂的信息处理架构，全面响应信息需求。该架构涵盖数据存储与处理（活跃与静默数据），促进跨部门及企业间的数据访问与整合，并确保数据安全性。

CIF逐步演进为数据仓库的第三代架构，其经典地位源于对前两代架构的总结与升华，同时明确划分了架构的各个层次。CIF 2.0尤为显著，包含集成转换层、操作数据存储、企业数据仓库、数据集市（分后台数据准备区与前台展示区）及探索仓库等关键组件。

这一经典架构自2006至2012年间深刻影响了数据领域的从业者，至今仍是许多互联网企业数据平台架构的参考模型。

第四代 OPDM 操作实时数仓

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

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

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

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

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

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

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

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

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

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

第二代流式架构

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

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

相较于第一代的大数据处理框架，流式计算处理框架显著革新了数据处理流程，摒弃了传统的ETL（提取、转换、加载）步骤。在流式计算中，数据通过专门的数据通道实时流动并即时得到处理，处理结果则迅速以消息的形式推送给数据消费者，实现了数据的即时分析与响应。

此框架摒弃了大数据的离线批量处理模式，转而采用一种近乎实时的处理方式，伴随着这一过程的是对数据存储的极大精简，因此数据的保存周期被显著缩短。这意味着，在面对需要广泛历史数据支持或涉及复杂历史数据计算的场景时，流式计算框架的直接应用会面临较大挑战。

为了弥补这一局限，当前一些应用场景采取了折衷方案：它们会周期性地将流式计算的结果数据存入批处理专用的数据存储区域，以备不时之需。当后续分析或处理需要用到历史数据时，流式计算框架能够灵活地将这些保存的历史结果以更新的形式重新加载进来，从而继续支持更为深入的数据处理和分析工作。

第三代 Lambda 大数据架构

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

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

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

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

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

Lambda架构历经多年发展，其优缺点鲜明。优势在于稳定性和性能，夜间进行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，让客户端传送数据的同时马上进行反馈，而不需要所有事件都要到中央端处理之后再进行下发。