【大数据】数据湖：下一代大数据的发展趋势

1.数据湖技术产生的背景

国内的大型互联网公司，每天都会生成几十、几百 TB，甚至几 PB 的原始数据。这些公司通常采用开源的大数据组件来搭建大数据平台。大数据平台经历过 以 Hadoop 为代表的离线数据平台、Lambda 架构平台、Kappa 架构平台 三个阶段。

可以把数据湖认为是最新一代大数据技术平台，为了更好地理解数据湖的基本架构，我们先来看看大数据平台的演进过程，从而理解为什么要学习数据湖技术。

1.1 离线大数据平台（第一代）

第一阶段：以 Hadoop 为代表的离线数据处理组件。Hadoop 是以 HDFS 为核心存储，以 MapReduce 为基本计算模型的批量数据处理基础组件。围绕 HDFS 和 MR，为不断完善大数据平台的数据处理能力，先后诞生了一系列大数据组件，例如面向实时 KV 操作的 HBase、面向 SQL 的 Hive、面向工作流的 Pig 等。同时，随着大家对于批处理的性能要求越来越高，新的计算模型不断被提出，产生了 Tez、Spark、Presto 等计算引擎，MR 模型也逐渐进化成 DAG 模型。

为减少数据处理过程中的中间结果写文件操作，Spark、Presto 等计算引擎尽量使用计算节点的内存对数据进行缓存，从而提高整个数据过程的效率和系统吞吐能力。

1.2 Lambda 架构

随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足实时性要求高的处理场景，流式计算引擎应运而生，例如 Storm、Spark Streaming、Flink 等。

然而，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求，对实时性要求高的场景，就会使用 Flink + Kafka 的方式构建实时流处理平台，来满足用户的实时需求。于是 Lambda 架构被提出，如下图所示。

Lambda 架构的核心理念是 流批分离，如上图所示，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过服务层对应用提供，确保访问的一致性。

这种数据架构包含非常多的大数据组件，很大程度上增强了整体架构的复杂性和维护成本。

1.3 Lambda 架构的痛点

经过多年的发展，Lambda 架构比较稳定，能满足过去的应用场景。但是它有很多致命的弱点：

• 数据治理成本高：实时计算流程无法复用离线数仓的数据血缘、数据质量管理体系。需要重新实现一套针对实时计算的数据血缘、数据质量管理体系。
• 开发维护成本高：需要同时维护离线和实时两套数据仓库系统，同一套计算逻辑要存储两份数据。例如，某一条或几条原式数据的更新，就需要重新跑一遍离线数据仓库，数据更新成本非常大。
• 数据口径不一致：因为离线和实时计算走的是两个完全不同的代码，由于数据的延迟到达和两类代码运行的时间不一样，导致计算结果不一致。

那么有没有一种架构能解决 Lambda 架构的问题呢？

1.4 Kappa 架构

Lambda 架构的 “流批分离” 处理链路增大了研发的复杂性。因此，有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。接下来我们介绍一下 Kappa 架构，通过 Flink + Kafka 将整个链路串联起来。Kappa 架构解决了 Lambda 架构中离线处理层和实时处理层之间计算引擎不一致，开发、运维成本成本高，计算结果不一致等问题。

Kappa 架构的方案也被称为 流批一体化 方案。我们借用 Flink + Kafka 来构建流批一体化场景，但是如果需要对 ODS 层数据做进一步的分析时，就要接入 Flink 计算引擎把数据写入到 DWD 层的 Kafka，同样也会将一部分结果数据写入到 DWS 层的 Kafka。Kappa 架构也不是完美的，它也有很多痛点。

1.5 Kappa 架构的痛点

• 数据回溯能力弱：Kafka 对复杂的需求分析支持能力弱，在面对更复杂的数据分析时，又要将 DWD 和 DWS 层的数据写入到 ClickHouse、ES、MySQL 或者是 Hive 里做进一步分析，这无疑带来了链路的复杂性。更大的问题是在做数据回溯时，由于链路的复杂性导致数据回溯能力非常弱。
• OLAP分析能力弱：由于 Kafka 是一个顺序存储的系统，顺序存储系统是没有办法直接在其上进行 OLAP 分析的，例如谓词下推这类的优化策略，在顺序存储平台（Kafka）上实现是比较困难的事情。
• 数据时序性受到挑战：Kappa 架构是严重依赖于消息队列的，我们知道消息队列本身的准确性严格依赖它上游数据的顺序，但是，消息队列的数据分层越多，发生乱序的可能性越大。通常情况下，ODS 层的数据是绝对准确的，把 ODS 层数据经过计算之后写入到 DWD 层时就会产生乱序，DWD 到 DWS 更容易产生乱序，这样的数据不一致性问题非常大。

1.6 大数据架构痛点总结

从传统的 Hadoop 架构往 Lambda 架构，从 Lambda 架构往 Kappa 架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力，但是这些平台仍然存在很多痛点。

是否存在一种存储技术，既能够支持数据高效的回溯能力，支持数据的更新，又能够实现数据的批流读写，并且还能够实现分钟级到秒级的数据接入？

1.7 实时数仓建设需求

这也是实时数仓建设的迫切需求。实际上是可以通过对 Kappa 架构进行升级，以解决 Kappa 架构中遇到的一些问题，接下来主要分享当前比较火的数据湖技术。

那么有没有这样一个架构，既能够满足实时性的需求，又能够满足离线计算的要求，而且还能够减轻开发运维的成本，解决通过消息队列方式构建的 Kappa 架构中遇到的痛点？答案是肯定的，在文章的后面会详细论述。

2.数据湖助力于解决数据仓库痛点问题

2.1 不断完善的数据湖理念

数据湖是一个集中式存储库，可以存储结构化和非结构化数据。可以按业务数据的原样存储（无需先对数据进行结构化处理），并运行不同类型的分析，从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。

2.1.1 存储原式数据

• 数据湖需要有足够的存储能力，能够存储公司的全部数据。
• 数据湖可以存储各种类型的数据，包括结构化、半结构化（XML、Json 等）和非结构化数据（图片、视频、音频）。
• 数据湖中的数据是原始业务数据的完整副本，这些数据保持了他们在业务系统中原来的样子。

2.1.2 灵活的底层存储功能

在实际的使用过程中，数据湖中的数据通常并不会被高频访问，为了达到可接受的性价比，数据湖建设通常会选择性价比高的存储引擎。

• 对大数据提供超大规模存储，以及可扩展的大规模数据处理能力。
• 可以采用 S3 / OSS / HDFS 等分布式存储平台作为存储引擎。
• 支持 Parquet、Avro、ORC 等数据结构格式。
• 能够提供数据缓存加速功能。

2.1.3 丰富的计算引擎

从数据的批量计算、流式计算，交互式查询分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。随着大数据与人工智能技术的结合，各类机器学习 / 深度学习算法也被不断引入进来，例如 TensorFlow / PyTorch 框架已经支持从 S3 / OSS / HDFS 上读取样本数据进行机器学习训练。因此，对于一个合格的数据湖项目而言，计算存储引擎的可插拔性，是数据湖必须具备的基础能力。

2.1.4 完善的数据管理

• 数据湖需要具备完善的元数据管理能力。包括对数据源、数据格式、连接信息、数据 Schema、权限管理等能力。
• 数据湖需要具备完善的数据生命周期管理能力。不仅能够存储原始数据，还需要能够保存各类分析处理的中间结果数据，并完整的记录数据的分析处理过程，帮助用户能够完整追溯任意一条数据的产生过程。
• 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量 / 增量数据，然后规范存储。数据湖能将数据推送到合适的存储引擎中，以满足不同的应用访问需求。

2.2 开源数据湖的架构

LakeHouse 架构成为当下架构演进最热的趋势，可直接访问存储的数据管理系统，它结合了数据仓库的主要优势。LakeHouse 是基于 存算分离 的架构来构建的。存算分离最大的问题在于网络，特别是对于高频访问的数仓数据，网络性能至关重要。实现 Lakehouse 的可选方案很多，比如 Delta，Hudi，Iceberg。虽然三者侧重点有所不同，但都具备数据湖的一般功能，比如：统一元数据管理、支持多种计算分析引擎、支持高阶分析和计算存储分离。

那么开源数据湖架构一般是啥样的呢？这里我画了一个架构图，主要分为四层：

2.2.1 分布式文件系统

第一层是分布式文件系统，对于选择云上技术的用户，通常会选择 S3 和阿里云存储数据；喜欢开源技术的用户一般采用自己维护的 HDFS 存储数据。

2.2.2 数据加速层

第二层是数据加速层。数据湖架构是一个典型的存储计算分离架构，远程读写的性能损耗非常大。我们常见的做法是，把经常访问的数据（热点数据）缓存在计算节点本地，从而实现数据的 冷热分离。这样做的好处是，提高数据的读写性能，节省网络带宽。我们可以选择开源的 Alluxio，或者阿里云的 Jindofs。

2.2.3 Table format 层

第三层是 Table format 层，把数据文件封装成具有业务含义的表，数据本身提供 ACID、Snapshot、schema、partition 等表级别的语义。这一层可以选择开源数据湖三剑客 Delta，Hudi，Iceberg 之一。Delta，Hudi，Iceberg 是 构建数据湖的一种技术，它们本身并不是数据湖。

2.2.4 计算引擎

第四层是各种数据计算引擎。包括 Spark、Flink、Hive、Presto 等，这些计算引擎都可以访问数据湖中的同一张表。

3.数据湖和数据仓库理念的对比

3.1 数据湖和数据仓库对比

下面跟大家聊聊我所理解的数据湖的本质，对于一种新事物不了解本质，你就很难驾驭它，下面这张图道尽了一切。

对数据湖的概念有了基本的认知之后，我们需要进一步明确数据湖需要具备哪些基本特征，特别是与数据仓库相比，数据湖具有哪些特点。我们引用一下 AWS 数据仓库和数据湖对比官方对比表格。

每个公司需要数据仓库和数据湖，因为它们分别满足不同的需要和使用案例：

• 数据仓库是一个优化后的数据库，用于分析来自事务系统和业务线应用系统的关系型数据。事先定义好数据结构和 Schema，以便提供快速的 SQL 查询。原始数据经过一些列的 ETL 转换，为用户提供可信任的 “单一数据结果”。
• 数据湖有所不同，因为它不但存储来自业务线应用系统的关系型数据，还要存储来自移动应用程序、IoT 设备和社交媒体的非关系型数据。捕获数据时，不用预先定义好数据结构或 Schema。这意味着数据湖可以存储所有类型的数据，而不需要精心设计数据结构。可以对数据使用不同类型的分析方式（如 SQL 查询、大数据分析、全文搜索、实时分析和机器学习）。

特性	数据仓库	数据湖
数据	来自事务系统、运营数据库和业务线应用程序的关系数据	来自 loT 设备、网站、移动应用程序、社交媒体和企业应用程序的非关系和关系数据
Schema	设计在数据仓库实施之前（写入型 Schema）	写入在分析时（读取型 Schema）
性价比	更快查询结果会带来较高存储成本	更快查询结果只需较低存储成本
数据质量	可作为重要事实依据的高度监管数据	任何可以或无法进行监管的数据（例如原始数据）
用户	业务分析师	数据科学家、数据开发人员和业务分析师（使用监管数据）
分析	批处理报告、BI 和可视化	机器学习、预测分析、数据发现和分析

上表介绍了数据湖与传统数据仓库的区别，下面我们将从数据存储和计算两个层面进一步分析数据湖应该具备哪些特征。

3.2 写时模式和读时模式

3.2.1 写时模式

数据仓库的 “写入型 Schema” 背后隐藏的逻辑就是在数据写入之前，必须确认好数据的 Schema，然后进行数据导入，这样做的好处是：可以把业务和数据很好的结合在一起；不足就是在业务模式不清晰，还处于探索阶段时，数仓的灵活性不够。

3.2.2 读时模式

数据湖强调的是 “读取型 Schema”，背后潜在的逻辑是，认为业务的不确定性是常态：既然我们无法预测业务的发展变化，那么我们就保持一定的灵活性。将结构化设计延后，让整个基础设施具备使数据 “按需” 贴合业务的能力。因此，数据湖更适合发展、创新型企业。

3.3 数据仓库开发流程

数据湖采用的是灵活，快速的 “读时模式” ，在数字化转型的浪潮下真正帮助企业完成技术转型，完成数据沉淀，应对企业快速发展下层出不穷的数据需求问题。

3.4 数据湖的架构方案

数据湖可以认为是新一代的大数据基础设施。在这套架构中，无论是数据的流式处理，还是批处理，数据存储都统一到数据湖 Iceberg 上。很明显，这套架构可以解决 Lambda 架构和 Kappa 架构的痛点问题：

3.4.1 解决 Kafka 存储数据量少的问题

目前所有数据湖基本思路都是基于 HDFS 之上实现的一个文件管理系统，所以数据体量可以很大。

3.4.2 支持 OLAP 查询

同样数据湖基于 HDFS 之上实现，只需要当前的 OLAP 查询引擎做一些适配，就可以对中间层数据进行 OLAP 查询。

3.4.3 数据治理一体化

批流的数据在 HDFS、S3 等介质上存储之后，就完全可以复用一套相同的数据血缘、数据质量管理体系。

3.4.4 流批架构统一

数据湖架构相比 Lambda 架构来说， Schema 统一，数据处理逻辑统一，用户不再需要维护两份数据。

3.4.5 数据统计口径一致

由于采用统一的流批一体化计算和存储方案，因此数据一致性得到了保证。

3.5 孰优孰劣

数据湖和数据仓库，不能说谁更好谁更差，大家都有可取之处，可以实现双方的优势互补，我这里画一张图，方便你的理解：

• 湖和仓的元数据无缝打通，互相补充，数据仓库的模型反哺到数据湖（成为原始数据一部分），湖的结构化应用沉淀到数据仓库。
• 统一开发湖和仓，存储在不同系统的数据，可以通过平台进行统一管理。
• 数据湖与数据仓库的数据，根据业务的发展需要决定哪些数据放在数仓，哪些放在数据湖，进而形成湖仓一体化。
• 数据在湖，模型在仓，反复演练转换。

4.数据湖助力数据仓库架构升级

4.1 构建数据湖的目标

数据湖技术 Iceberg 目前支持三种文件格式：Parquet，Avro，ORC。如下图所示，Iceberg 本身具备的能力总结如下，这些能力对于构建湖仓一体化是至关重要的。

• 数据存储层采用标准统一的数据存储模型。
• 构建准实时数据建设，去 T + 1，保证数据时效性。
• 数据追溯更加方便，运维成本更低。

4.2 准实时数据接入

数据湖技术 Iceberg 既支持读写分离，又支持并发读、增量读、小文件合并，还可以支持秒级到分钟级的延迟，基于这些优势我们尝试采用 Iceberg 这些功能来构建基于 Flink 的实时全链路批流一体化的实时数仓架构。

如下图所示，Iceberg 每次的 commit 操作，都是对数据的可见性的改变，比如说让数据从不可见变成可见，在这个过程中，就可以实现近实时的数据记录。

4.3 实时数仓 - 数据湖分析系统

在建设离线数据仓库时，首先要进行数据接入操作，比如用离线调度系统定时抽取数据，再经过一系列的 ETL 操作，最后将数据写入到 Hive 表里面，这个过程的延时比较大。因此，借助于 Iceberg 的表结构，可以使用 Flink，或者 Spark Streaming，实现近实时的数据接入，以降低数据延迟性。

基于上面的功能，我们回顾一下前面讨论的 Kappa 架构，我们已经知道 Kappa 架构的痛点，Iceberg 既然能够作为一个优秀的表格式，又可以支持 Streaming Reader 和 Streaming Sink。那么，是否可以考虑将 Kafka 替换成 Iceberg？

Iceberg 底层依赖的存储是像 HDFS 或 S3 这样的廉价存储，并且支持 Parquet、ORC、Avro 等存储结构。可以对中间层的结果数据进行 OLAP 分析。基于 Iceberg Snapshot 的 Streaming Reader 功能，可以把离线任务天级别到小时级别的延迟大大的降低，改造成一个近实时的数据湖分析系统。

在中间处理层，可以用 Presto 进行一些简单的 SQL 查询，因为 Iceberg 支持 Streaming Read，所以在系统的中间层也可以直接接入 Flink，直接在中间层用 Flink 做一些批处理或者流式计算的任务，把中间结果做进一步计算后输出到下游。

4.4 Iceberg 替换 Kafka 的优劣势

总的来说，Iceberg 替换 Kafka 的优势主要包括：

• 实现存储层的流批统一
• 中间层支持 OLAP 分析
• 完美支持高效回溯
• 存储成本降低

当然，也存在一定的缺陷，如：

• 数据延迟从实时变成近实时
• 对接其他数据系统需要额外的开发工作

4.5 通过 Flink CDC 解决 MySQL 数据同步问题

Iceberg 提供统一的数据湖存储表格式，支持多种计算引擎（包括 Spark、Presto、Hive）进行数据分析；可以产生纯列存的数据文件，而列式文件非常适合用来做 OLAP 操作；Iceberg 基于 Snapshot 的设计模式，支持增量读取数据；Iceberg 的接口抽象程度高，兼容性好，既独立于上层的计算引擎又独立于下层的存储引擎，这就方便用户自行定义业务逻辑。

将数据连同 CDC flag 直接 append 到 Iceberg 当中，在 merge 的时候，把这些增量的数据按照一定的组织格式、一定高效的计算方式与全量的上一次数据进行一次 merge。这样的好处是支持近实时的导入和实时数据读取；这套计算方案的 Flink SQL 原生支持 CDC 的摄入，不需要额外的业务字段设计。

5.数据湖技术的发展前景

数据湖可能是在下一场大数据技术变革中的亮点，我们需要抓住机遇、抢占先机，一起来学习数据湖。但是我的建议仍然是 “学而不用”，为什么这么说呢？例如：在 $2018$ 年开始的时候，我们一窝蜂的上线 Flink，然后一个月一个版本的升级。简直是吃尽了苦头。所以，我们就等互联网大厂把坑填完了，我们再直接短平快的上马数据湖，但是我们一定要学习。

6.总结

通过这篇文章，我们基本了解了什么是数据湖，以及为什么要学习数据湖，它能解决哪些实际问题。后面我们将继续重点讲解为什么要选择 Iceberg 作为数据湖的解决方案。