大数据架构演进之路

01 前言

1998 年，一篇名为《大数据科学的可视化》的文章在美国《自然》杂志上发表，大数据作为一个专用名词正式出现在公共刊物之中，至今已经发展了二十余年。根据维基百科的定义，大数据是指无法在可承受的时间范围内用常规软件工具进行处理的数据集合，具有规模性（Volume）、多样性（Varity）、高速性（Velocity）和价值性（Value）等四个方面的典型特征，即所谓的 “4V”。

为了有效解决大规模数据存储、计算、分析的诸多难点，诞生了以 Hadoop 为代表的一系列产品，整个大数据生态系统庞大而复杂，而大数据架构则是连接、组织这一庞大生态的核心。在大数据的下一个十年即将来临之际，本文将对这二十年中具有代表性的大数据架构进行一个阶段性总结，回顾历史，拥抱未来。

02 大数据架构的早期发展

在上世纪 90 年代，随着互联网浪潮带动的数据持续增长，传统的数据库技术遇到了瓶颈。美国的 Teradata 天睿公司推出了可以储存 TB 级数据的关系型数据库管理系统，这是对 MPP（大规模并行处理）架构的最初雏形使用。这一时期，大数据系统主要以存储结构化数据为主，处在一个缓慢发展的阶段。

1990 年，Bill Inmon 提出了数据仓库这一概念：面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策。很多大型企业开始着手搭建自己的数据仓库。但是受限于技术，这一时期只能将业务数据库的数据通过 ETL 管道抽取到基于关系型数据库搭建的数据仓库中，分析手段十分有限。

真正给大数据体系带来变革的，是 Hadoop 的出现。

2.1 Haoop 的发展史

Hadoop 的发展可以追溯到 2001 年，当时 Lucene 框架被创建，这是一个用 Java 写的开源软件，提供了全文搜索功能。

2003 年，Nutch 项目启动，它的目标是创建一个开源的搜索引擎，包括网页抓取、索引、查询等功能。然而，随着网页数量的增加，Nutch 遇到了可扩展性的问题。

同年，Google 发表了关于 GFS 的论文，这是一种分布式文件系统，可用于处理海量网页的存储。

2004 年，Google 又发表了关于 MapReduce 的论文，这是一种分布式计算框架，可用于处理海量网页的索引计算问题。这为解决 Nutch 的可扩展性问题提供了可能。

2005 年，Lucene 的子项目 Nutch 的一部分正式引入 Apache 基金会。同年，Hadoop 成为 Lucene 的子项目。

2006 年，Google 发表了关于 Bigtable 的论文，这是一种分布式数据库，可以在局部几台服务器崩溃的情况下继续提供高性能的服务。

2008 年 1 月，Hadoop 成为 Apache 顶级项目，迎来了它的快速发展期。

在这里，推荐花点时间阅读一下被称为 “大数据三驾马车” 的三篇论文。它们是分布式文件系统，分布式计算，分布式数据库的思想雏形，Hadoop 之父 Doug Cutting 基于前两篇论文完成了 Hadoop 项目早期的工程实现。

• The Google File System（https://static.googleusercontent.com/media/research.google.com/zh-CN//archive/gfs-sosp2003.pdf）
• MapReduce: Simplified Data Processing on Large Clusters（https://static.googleusercontent.com/media/research.google.com/zh-CN//archive/bigtable-osdi06.pdf）
• Bigtable: A Distributed Storage System for Structured Data（https://static.googleusercontent.com/media/research.google.com/zh-CN//archive/mapreduce-osdi04.pdf）

现在，Hadoop 已经发展成为一个包括 HDFS、MapReduce、HBase 等众多项目的庞大生态系统。有趣的是，Hadoop 这一名字的来源是作者 Doug Cutting 的儿子的玩具大象，因此 Hadoop 生态的很多组件的 logo 上都出现了黄色大象这一元素。

2.2 Hadoop 生态下的离线数仓架构

下面我们来具体介绍一下基于 Hadoop 体系的传统大数据架构。

在 Hadoop 生态发展初期，一个主流的解决方案是通过 Flume、Sqoop 等工具，将数据以 ETL 的形式抽取到 HDFS 中，并通过 MapReduce 完成数据计算。MapReduce 虽然解决了大规模数据场景下的分布式计算这一问题，但是存在很多缺陷：

• 数据计算过程中产生的数据大量落盘，磁盘 IO 严重，性能不佳
• 基于 Map 和 Reduce 接口的编程模型过于简单，很多复杂的业务逻辑难以实现，开发者无法专注于业务逻辑的编写
• MapReduce 作业需要使用 Java 语言进行开发并打包部署，存在很高的技术门槛，整体的开发效率非常低下
• 无法迭代式计算，不能够很好的支持机器学习场景的任务

2007 年，Facebook 研发了数据仓库工具 Hive，在一定程度上解决了 MapReduce 的一些问题。Hive 是建立在 HDFS 之上的，支持标准化 SQL，并自动转换为 MapReduce 任务，屏蔽了底层框架细节，而且在存储层、计算层都做了不少的优化。

2008 年，Hive 正式开源，很快成为大数据领域构建离线数仓的统一标准。

通常，我们以 T+1 的周期调度 Hive SQL 脚本，在 Hive 数仓中进行分层处理，并最终产出离线指标和数据集市表供业务使用。

Hive 虽然对计算层做了很多优化，但是并没有改变 MapReduce 基于磁盘进行数据计算这一本质，因此还是存在严重的性能问题。在这种情况下，一个新的离线计算框架出现了，它就是 Spark。

2009 年，Spark 诞生于伯克利大学 AMP Lab 的一个研究性项目。

2010 年，Spark 正式开源，并于 2014 年成为 Aparch 基金会的顶级项目，整个过程不到五年时间。

和 MapReduce 相比，Spark 具有很多优势：

• 实现了高效的 DAG 执行引擎，引入了对内存的使用。和 MapReduce 相比，Spark 基于内存的运算要快 100 倍以上，而基于硬盘的运算也要快 10 倍以上。
• 支持 Java、Python 和 Scala 的 API，支持 Spark SQL，给不同语言的开发者提供了更多选择。
• 丰富的生态，支持几十种上下游存储系统，支持近百种机器学习算法。
• 抽象出了 RDD（弹性分布式数据集）这一概念，支持迭代式计算，大幅提升了机器学习模型的训练速度。

在之后的几年时间里，Spark + Hive 的离线数仓架构逐渐成熟，时至今日仍然是构建离线数仓的一种主流解决方案。

03 实时架构的兴起

3.1 Flink 实时计算引擎

Hadoop 体系的离线批处理架构天然具有数据延迟的问题，无论是 MapReduce、Hive 还是 Spark，都无法满足互联网时代快速获取最新数据的需求，比如电商双 11 大屏的实时销售额展示。因此，相继出现了 Storm、Spark Streaming、Flink 这三个实时计算引擎，它们的对比如下：

Spark 本身是一个离线计算引擎，通过微批处理（Micro batch）实现对实时计算的支持。和 Storm、Flink 这两个专为实时计算而生的引擎相比，Spark 的延迟较高。在早期，大部分实时任务都是基于 Storm 开发的。Flink 开源后，它先进的设计理念和一些关键能力，比如状态管理、容错机制、精确一次处理、毫秒级延迟等，加上 Flink SQL、Flink CDC、Flink ML 等生态的建设以及背后商业化公司阿里巴巴的大量资源支持，在短短几年的时间内就成为了实时计算领域的事实标准。有了 Flink，建设端到端秒级延迟的实时数仓成为了可能。

3.2 早期的实时数仓架构

Flink 解决了计算层的延迟问题，但是实际上用户需要的是端到端的时效性。在存储层，我们需要选择一种低延迟的存储介质替换掉 Hive。实践中，Kafka 作为主流的分布式流平台，无论是吞吐量还是延迟都非常优秀，因此基于 Flink + Kafka 的实时数仓架构很快流行起来。

在这个架构中，我们通过 ETL 工具将原始数据传输到 Kafka 中，形成 ODS 层，并使用 Flink 进行分层处理。为了加快处理速度，DIM 层的维度数据通常是存在 Redis、HBase 等高性能 KV 库中的，基于 Flink 的多流 Join 能力进行打宽。为了提升查询的速度，最终的指标数据存储到基于 OLAP 引擎的 ADS 层，供用户使用。

Flink + Kafka 的实时数仓架构，只能提供非常短时间内的数据。通常来说，ODS 层 Topic 的存储周期可能是七天或者是更短。因此更长时间跨度的指标，还是基于离线数仓的数据产出。这种离线数仓和实时数仓割裂的架构很快就遇到了结果不一致的问题：如果一个用户日活量指标，实时数仓产出的是 1 亿，离线数仓产出的是 1 亿 5 千万，业务该采用哪个呢？实际情况中，实时数仓可能只统计了主站的日活，而离线数仓把一些生态的日活也统计进去了，这就是口径不一致的问题。考虑到实时数仓和离线数仓通常是两个独立的团队，这一问题很难避免。

同时，实时计算的资源消耗显著大于离线计算，这种离线 + 实时数仓共存的架构，会导致大数据相关的成本倍数级增长，中小型公司很难接受。

为了解决实时和离线不一致、资源消耗大的问题，业界分别设计出了 Lamdba 和 Kappa 两种架构，以及基于这两种架构的一些变种。今天，我们在市面上所能看到的数仓架构，大部分都是在 Lamdba 和 Kappa 两种架构的基础上，根据业务诉求改良而来的。

3.3 Lamdba 架构

Lambda 架构由 Twitter 工程师 Nathan Marz 提出，是一种经典的、实施广泛的技术架构。它打通了原先割裂的实时和离线体系，通过提供给用户一个统一的视图，解决了实时和离线结果不一致的问题。

Lambda 架构由批处理层（Batch Layer）、速度处理层（Speed Layer）和用于响应查询的服务层（Serving Layer）组成。

1. 批处理层（Batch Layer）：负责存储和管理主数据集以及预先批处理计算好的视图。它使用可处理大量数据的分布式处理系统预先计算结果。通过处理所有的历史数据，这一层能够确保数据的准确性，并修复历史错误，然后更新现有的数据视图。
2. 速度处理层（Speed Layer）：负责实时处理新来的大数据。它通过提供最新数据的实时视图来最小化延迟。当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。这一层弥补了批处理层所导致的数据视图滞后。
3. 服务层（Serving Layer）：负责响应查询。它从批处理层和速度处理层获取预先计算好的结果或者实时计算的数据视图，然后返回给用户。

Lambda 架构的优缺点如下：

• 优点：
  • 极高的稳定性，发生问题时可以直接通过离线链路补回数据，实时链路消费最新的数据即可。
  • 保留了实时和离线两条链路，可以支持复杂的数据处理和分析。
• 缺点：
  • 通过引入服务层来统一实时和离线结果不一致的问题，只是对用户来说统一了查询，没有从根本上解决问题。对于开发人员来说，还是要维护两条链路，并且还要额外维护一个服务层，增加了系统复杂度。
  • 资源开销大，成本问题仍然存在。

3.4 Kappa 架构

为了解决 Lamdba 架构过于复杂的问题，LinkedIn 公司的 Jay Kreps 结合实际经验与个人思考提出了 Kappa 架构。

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

具体改进的地方包括：

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

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

• 优点：
  • 只需维护一套代码，开发、维护成本低。
• 缺点：
  • 无法支持长时间跨度的数据处理。
  • 一旦发生故障，重新计算的效率低。
  • 流处理作业难以调试，出问题的概率高，对研发人员、运维人员的技术水平要求高。

Lambda 和 Kappa 都属于实时架构，因此都可以满足业务对实时性的要求，同时在资源成本、重计算成本、运维成本方面各有一些 trade-off。为了优化这两种架构的缺陷部分对业务的影响，诞生了一些改良后的版本，例如 Lambda+、Kappa+。同时，各大互联网公司也都有更贴合自家业务的魔改版。

但是，无论在 Lambda 和 Kappa 的基础上怎么改，实时和离线无法统一的根本问题始终没有得到解决。而在可预见的时间内，实时计算在大规模数据处理、机器学习等场景下无法完全取代离线计算，只能是互补的关系。在这种背景下，能够统一实时和离线的流批一体架构被寄予希望。

从上面的讲述中我们知道，Lambda 架构实现了流批一体的服务层，使得用户的体验是统一的，但是计算层和存储层仍然是割裂的。而 Kappa 架构下的批处理局限性很大。如果说我们能够吸收 Lambda 架构的理念，并且做到计算层和存储层的流批一体，那么问题是不是就得到解决了呢？

下面讲一讲如何实现流批一体的计算和存储。

3.5 流批一体计算

流批一体计算是指在大数据处理领域中，将流处理（Streaming）和批处理（Batch）结合在一起，使得同一套计算逻辑能够同时应用于两种处理模式，使得计算过程更加简洁和高效，并在最终结果上保持一致。

在 3.1 章节，我们已经讲过，Flink 是一个开源的实时计算引擎。虽然在 Flink 的早期版本中，对批处理也有一定程度的支持，但是总的来说，和 Spark 对比起来，Spark 批强流弱，Flink 流强批弱，二者无法独占分布式计算市场。

为了支持流批一体，Flink 做了以下几点改造：

• 2015 年，阿里巴巴对 Spark 和 Flink 做了大量调研，认为 Flink Streaming 的概念优于 Spark Micro Batch 的概念。之后，阿里巴巴重投入大量人力开发基于 Flink 的内部版本 Blink，在 Flink DataStream、DataSet 底层 API 的基础上，强化了对 SQL 和 Table API 的支持，并在 2019 年将 Blink 的实现捐献给 到 Flink 社区。经过社区几个大版本的迭代，DataStream API 可以同时支持流和批，DataSet API 退出了历史舞台，Flink 终于能够提供统一的流批一体语义。

• 推出子项目 Flink CDC，借助于 Flink SQL 和 DataStream API 强大的流批一体语义，在数据集成环节实现流批一体。
• 推出 Flink Batch 模式，用户只需要配置一个 Mode 即可自由实现批和流的切换。在性能上，实现了自适应批处理调度器、动态分区裁剪、推测执行、混合 Shuffle 等，能够提供不弱于 Spark 的批处理能力。
• 推出 Flink Catalog，强化对离线数仓生态的支持。

在计算层，Flink 实现了流和批的统一，我们还需要让存储层支持流批一体，而无论是离线的 Hive 还是实时的 Kafka，都难以做到，因此需要新的存储系统来解决这个问题。目前，主要有两种主流存储架构可以提供流批一体：流式数据湖和统一实时数仓，下面我们分别讲一讲。

3.6 流批一体存储

3.6.1 流式数据湖架构

数据湖这个概念出现于2010年，旨在解决传统数据仓库和数据集市所面临的两大难题。首先，它希望通过统一的元数据存储来解决数据集市之间的数据孤岛问题，让所有数据都能够相互连接和共享。其次，数据湖还希望存储原始数据，包括结构化、半结构化和非结构化数据，而不是存储经过裁剪后的数据集市，以确保不会丢失数据的原始信息。

数据湖主要经历了四个发展阶段：

1. 早期，数据湖直接构建于 HDFS 之上，主要应用于机器学习所需要的大规模数据存储。由于缺乏有效的元数据管理，人们很难从中提取出有价值的信息。缺乏维护、管理的数据湖，随着大量低价值密度数据的涌入，会很快退化为数据沼泽，难以支持 BI（商业智能）业务。
2. 随着云计算的发展， 2015 年，各个云厂商推出了基于对象存储（OSS）的云产品。对象存储具有大规模、高可用和低成本的优势，逐步替代了 HDFS 成为云上统一存储的主流选择。
3. 2019 年前后，随着 Databricks、Uber 等公司陆续推出被称为数据湖三剑客的 Delta Lake、Hudi 和 Iceberg 湖格式，数据湖得到了广泛的应用。通过在数据湖的原始数据之上再构建一层元数据层、索引层的方式，解决了数据湖上数据的可靠性、一致性和性能等问题。
4. 2020 年，以数据湖三剑客为代表的湖格式，生态建立在 Hadoop 和 Spark 的基础上，对批处理的支持较好。2022 年，随着 Paimon、Hudi 等湖格式支持 Changelog，并加强 Flink 的生态建设，数据湖内的数据可以实时流动起来，流式数据湖的概念推广起来。

数据湖的特性包括：

• ACID 事务：同一张表经常会同时有多个工作流来读写，事务保证了我们能够读、写到正确的数据。
• Schema Evolution：允许修改表的字段信息（如增删字段，修改字段类型和描述等）。
• 支持结构 / 非结构数据，支持多类 API：湖仓架构能够支持半 / 非结构化数据（如 JSON，图像，语音等）的存储，以及提供除了基本 SQL 之外丰富的 API 来处理数据，应用在如机器学习等场景。
• 流批一体：用数据湖架构替代 Lambda 架构，能够有效的简化流式和离线两条数据链路的开发和运维成本。
• 采用 ELT（提取 - 加载 - 转换）过程，而不是传统数仓的 ETL（提取 - 转换 - 加载）过程。
• 存算分离：存储和计算可以按需伸缩，并且使用廉价的 OSS、HDFS、MinIO 等存储介质，降低整体成本。

在国内，Hudi 和 Iceberg 的使用更多一点，Paimon 作为 Flink 的生态项目，对 Flink 的支持更完善，目前还处于追赶阶段。

下面是一个基于 Hudi 的流式数据湖架构。它与 Kappa 架构很像，区别只是在于用 Hudi 替换了 Kafka 作为存储介质，以提供流批一体的存储能力，同时支持流读流写、批读批写。

上面介绍的流式数据湖架构因为底层还是 HDFS，在分析能力和数据入湖速度上都是较慢的：

• 虽然号称是流式数据湖，但通常还是使用批的方式进行导入，以降低底层小文件合并的压力，整体延迟比实时数仓高。
• Hudi 分析能力差，需要额外引入 Trino、Spark 等查询引擎，加上数据湖本身就是建立在 Hadoop 之上的，还要维护一个 Hadoop 集群，架构上更加复杂了。Paimon 虽然可以提供高性能的单表查询能力，一旦多表关联查询性能就会大幅下降。

有没有更简单的架构可以支持存储、计算、分析的流批一体呢？

3.6.2 统一数仓架构

2016 年后，随着 Clickhouse 和 Doris 这两款性能极其强大的 MPP 数据库的开源，基于 Clickhouse 和 Doris 的实时数仓架构快速取代了基于 Kafka 的实时数仓架构。以 Doris 为例，主要有以下几大优势：

1. 高性能的数据存储和数据分析能力，多表关联查询能力突出。
2. 数据全量存储，可以基于任意时间节点进行数据回溯。
3. 数仓自身即可实现数据集成和数据分层，存储、计算、分析一体，极简架构，运维成本低。
4. 支持 Flink CDC 的流批一体写入，也支持 Kafka 流写入或 MySQL、HDFS 批写入。
5. 支持联邦查询和数据湖加速。

上图可以看到，基于 Doris 的数仓架构链路短、组件少，简单易用，因此又称这种架构为统一数仓架构。这么简单的架构，Doris 是怎么实现流批一体的呢？

首先，在流处理环节：

• 存储层：Doris 借助于 Flink Connector 可以实现毫秒级的数据更新和表结构变更。
• 计算层：Doris基于 Unique、Aggregate 和 Duplicate 数据模型，加上物化视图等能力，可以实现毫秒级数据分层，或者微批调度实现分钟级数据分层。
• 分析层：Doris 可以实现毫秒级多表关联查询。

在批处理环节：

• 存储层：Doris 通过 Broker 组件可以实现大批量的离线数据导入导出。
• 计算层：通过周期性调度实现数据处理和分层。
• 分析层：Doris 本身的分析能力可以支持离线场景下的分析，也可以导出到外部系统进行分析，产出离线指标。

因此在存储、计算、分析等环节，Doris 都是流批一体的。

那么基于 Doris 的统一实时数仓架构有没有什么问题呢？

主要还是实时数仓本身的一些固有问题：

1. 首先，是实时数仓分层困难、上层数据不准的问题。实时数仓能够支持的业务复杂度和数据模型的复杂度都是有限的，并且层数多了后，延迟和数据不准确也会增加。因此在实践中，不建议分太多层。
   
   • Doris 的存储主要使用 SSD，存储成本比较高。
   • Doris 不支持 Binlog 和 Changelog，因此不支持流读和时间旅行（数据多版本），数据一旦被更新，旧的数据就丢失了。
   • Doris 对非架构化数据、半结构化数据的支持不佳。

以上的一些问题，很多已经列入了 Doris 2023 年的 Roadmap，在未来发展规划上，Doris 将借鉴数据湖的优秀特性，同时继续强化已有的数仓能力。正在开发中的一些关键能力包括：

1. 在已有的冷热分层功能的基础上，推出存算分离架构，大幅降低 Doris 集群的成本，用户可以在成本和性能上自主权衡。
2. 实现 Changelog 和数据版本功能，在此基础上可以实现流读、消息订阅、时间旅行等，成为类似于 Paimon、Hudi 流式数据湖一样的流式数仓。
3. 实现多表物化视图，在此基础上，实时数仓分层又多了一个新的选择。之前，单表的物化视图大部分情况下只能提供DWD层的分层。多表物化视图可以实现更高级别的分层，不再依赖调度系统进行微批处理，架构上更加统一了。
4. 提升数据湖分析能力，增强对非结构化和半结构化数据的支持。
5. 增强对高并发数据服务的支持，在中小规模业务场景下，Doris 可以直接对外提供数据服务，不再需要通过 KV 存储。

未来，很期待 Doris 实现真正意义上的统一数仓，用 Doris 一个组件就可以实现实时数仓的搭建，成为中国的 Snowflake。

05 新一代湖仓架构

最后，让我们展望一下未来几年湖仓架构发展的趋势。

5.1 湖仓一体

数据湖和数据仓库技术发展了二十年，各有优劣，谁也难以统一谁。在大型公司，通常数据湖、离线数据仓库，实时数据仓库都是要共同建设的，以满足不同业务线的需求。因此，湖仓一体这种湖和仓互相补充，协同工作的架构，在这几年被广泛推广。

湖仓一体，简单来说，就是将数据湖的数据和数仓的数据从架构上互相打通，数据以低成本在湖和仓之间流动。

对于如何实现湖仓一体架构，有很多种实现，包括：

1. 湖上建仓：数据先全量存储到数据湖中，再将湖中的数据清洗后存储到数据仓库中，在数仓中进行数据建模、数据分层、元数据管理。
2. 湖内建仓：数据先全量存储到数据湖中，再将湖中的数据清洗后进行数据建模、数据分层、元数据管理。
3. 仓上建湖：数据先存储到数据仓库中，再将仓中的数据存储到数据湖中。数据湖存储全量数据，数仓周期性清理历史数据，只保留近期的数据。
4. 湖旁建仓：数据湖和数据仓库的数据来自不同数据源，但是可以互相访问和快速流通。MPP 类型的数据仓库可以对湖中的数据进行查询加速。

以 Hudi、Paimon 为代表的流式数据湖架构，和以 Doris、Clickhouse 为代表的统一数仓架构，在这几年经历了快速的发展。数据仓库和数据湖的边界正在慢慢模糊，数据湖自身的治理能力、数据仓库延伸到外部存储的能力都在加强。相信在不远的将来，湖和仓会实现真实的融合。

5.2 云原生湖仓

除了之前介绍的数据湖、数据仓库的开源产品之外，各大云厂商都在主推自己的云原生湖仓，例如 Snowflake、阿里的 Hologres、MaxCompute，字节的 LAS（基于 Hudi）等，这些云产品的典型特性包括免运维、弹性伸缩等，同时性能也非常强大，湖仓全面云原生化是一个大的趋势。

5.3 流式湖仓

基于 Streaming Lakehouse 理念，实现数仓不同层级之间的实时数据的高效流动，可以解决实时数仓分层问题。目前 Hudi、Paimon 先后提出了流式数据湖的概念，其他开源湖仓产品和云湖仓产品也在跟进。

06 总结

看到这里，相信你对大数据架构真的是非常感兴趣了！在本文最后，让我们回顾一下大数据架构整体的发展脉络：
传统数仓架构 -> 离线大数据架构（数仓 / 数据湖） -> Lambda 数仓架构 -> Kappa 数仓架构 -> 新一代实时数仓 / 流式数据湖 -> 湖仓一体 -> 湖仓融合 -> 云原生湖仓

最后我想说的是：架构从来没有优劣之分，不要盲目选择最先进的技术架构，而是应当综合考虑业务核心诉求、人力和资源预算、团队技术栈、维护成本等多方面因素，仔细权衡后再做决定，并且随着业务的发展不断调整我们的架构。