数据湖：下一代大数据技术的发展趋势与演进

xinxi1368

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

1.数据湖技术背景

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

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

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

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

为了减少数据处理过程中中间结果的文件写入操作，Spark等计算引擎尝试利用计算节点的内存来缓存数据，从而提高整个数据处理的效率和系统吞吐量。

1.2 架构

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

然而，随着越来越多的应用上线，大家发现批处理和流计算其实可以满足大部分应用的需求。在实时性要求较高的场景中，会采用Flink+Kafka来构建实时流。处理平台满足用户的实时需求。于是提出了架构，如下图所示。

该架构的核心概念是流批分离。如上图所示，整个数据流从左到右流入平台。进入平台后分为两部分，一部分是批处理模式，另一部分是流计算模式。无论何种计算模式，最终的处理结果都通过服务层提供给应用程序，保证访问一致性。

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

1.3 架构痛点

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

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

1.4 Kappa架构

该架构的“流批分离”处理环节增加了研发的复杂度。因此，有人问是否可以用一个系统来解决所有问题。目前比较流行的做法是基于流计算来做。接下来我们介绍Kappa架构，通过Flink + Kafka串联整个链路。 Kappa架构解决了架构中离线处理层和实时处理层计算引擎不一致、开发和运维成本高、计算结果不一致的问题。

Kappa架构方案也称为流批一体化方案。我们借用Flink + Kafka构建流批融合场景。但如果我们需要进一步分析ODS层的数据，就必须接入Flink计算引擎将数据写入到DWD层的Kafka中，同时存储部分结果数据。在DWS层写入Kafka。 Kappa架构并不完美，也存在很多痛点。

1.5 Kappa架构的痛点

1.6 大数据架构痛点总结

从传统架构到架构，从架构到Kappa架构，大数据平台基础设施的演进已经逐渐包含了应用所需的各种数据处理能力，但这些平台仍然存在很多痛点。

有没有一种存储技术，既能支持高效的数据追溯和更新，又能实现数据的批量、流式读写，还能实现分钟级到秒级的数据访问？

1.7 实时数据仓库建设需求

这也是实时数据仓库建设的迫切需求。其实Kappa架构可以通过升级来解决Kappa架构遇到的一些问题。接下来我们主要分享一下目前流行的数据湖技术。

那么是否有这样一种架构，既能满足实时和离线计算需求，降低开发和运营成本，又能解决通过消息队列构建的Kappa架构遇到的痛点呢？答案是肯定的，这将在本文后面详细讨论。

2. 数据湖帮助解决数据仓库的痛点 2.1 不断完善数据湖理念

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

2.1.1 存储原始数据 2.1.2 灵活的底层存储功能

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

2.1.3 丰富的计算引擎

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

2.1.4 完善的数据管理 2.2 开源数据湖架构

建筑已经成为当下建筑进化最热门的趋势。数据管理系统可以直接访问存储的数据，它结合了数据仓库的主要优点。它是基于存储与计算分离的架构构建的。存储与计算分离最大的问题就是网络。尤其对于频繁访问的数据仓库数据，网络性能至关重要。有很多实现选项，例如 Delta 和 Hudi。三者虽然侧重点不同，但都具备数据湖的通用功能，比如统一元数据管理、支持多种计算分析引擎、支持高阶分析以及计算与存储分离等。

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

2.2.1 分布式文件系统

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

2.2.2 数据加速层

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

2.2.3 表格层

第三层是Table层，将数据文件封装成具有业务意义的表格。数据本身提供表级语义，例如 ACID、 等等。对于这一层，可以选择开源数据湖三剑客Delta和Hudi之一。 Delta和Hudi是构建数据湖的技术，但它们本身并不是数据湖。

2.2.4 计算引擎

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

3. 数据湖和数据仓库概念比较 3.1 数据湖和数据仓库比较

我跟大家讲一下我所理解的数据湖的本质。如果你不了解一个新事物的本质，你就很难驾驭它。下图说明了一切。

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

每个公司都需要数据仓库和数据湖，因为它们各自满足不同的需求和用例：

特征 数据仓库 数据湖

数据

来自事务系统、运营数据库和业务线应用程序的关系数据

来自物联网设备、网站、移动应用程序、社交媒体和企业应用程序的非关系和关系数据

数据仓库实施前的设计（基于写入）

解析时写入（读取类型）

成本效益

更快的查询结果伴随着更高的存储成本

更快的查询结果和更低的存储成本

数据质量

作为重要事实基础的高度监管的数据

任何可以或不能整理的数据（例如原始数据）

用户

商业分析师

数据科学家、数据开发人员和业务分析师（处理监管数据）

分析

批量报告、BI 和可视化

机器学习、预测分析、数据发现和分析

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

3.2 写入模式和读取模式 3.2.1 写入模式

“写入式”数据仓库背后隐藏的逻辑是，在写入数据之前，必须先确认数据，然后再导入。这样做的好处是可以很好的将业务和数据结合起来；缺点是当业务模式不明确，还处于探索阶段时，数据仓库不够灵活。

3.2.2 阅读模式

数据湖强调“读”，其背后的底层逻辑是业务不确定性是常态：既然我们无法预测业务的发展和变化，就必须保持一定的灵活性。推迟结构化设计，让整个基础设施具备“按需”调整数据以适应业务的能力。因此，数据湖更适合开发型、创新型企业。

3.3 数据仓库开发流程

数据湖采用灵活、快速的“读时模式”，能够真正帮助企业完成数字化转型浪潮下的技术改造和数据沉淀，应对企业快速发展所产生的无穷无尽的数据需求问题。

3.4 数据湖架构方案

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

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

目前所有数据湖的基本思想都是基于HDFS实现文件管理系统，因此数据量可以非常大。

3.4.2 支持OLAP查询

数据湖也是基于HDFS实现的。只需要对当前的OLAP查询引擎进行一些改造即可对中间层数据执行OLAP查询。

3.4.3 数据治理整合

批量流数据存储在HDFS、S3等介质上后，可以重复使用相同的数据沿袭和数据质量管理系统。

3.4.4 统一流批架构

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

3.4.5 数据统计一致

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

3.5 哪一种更好，哪一种更差？

数据湖和数据仓库之间，我们不能说谁更好，谁更差。两者各有千秋，可以优势互补。我这里画一张图方便大家理解：

4. 数据湖助力数据仓库架构升级 4.1 构建数据湖的目标

数据湖技术目前支持三种文件格式：Avro、ORC。如下图所示，其拥有的能力总结如下。这些能力对于构建湖库一体化至关重要。

4.2 准实时数据访问

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

如下图所示，每个操作都会改变数据的可见性，例如将数据从不可见变为可见。在此过程中，可以实现近实时的数据记录。

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

在构建离线数据仓库时，首先要进行数据访问操作，比如使用离线调度系统定期提取数据，然后经过一系列的ETL操作，最后将数据写入Hive表中。这个过程有比较大的延迟。因此，借助表结构，您可以使用Flink或Spark实现近实时的数据访问，以减少数据延迟。

基于以上功能，我们来回顾一下前面讨论的Kappa架构。我们已经知道Kappa架构的痛点。由于它可以作为一种优秀的表格格式，因此它也可以支持Sink。那么，是否可以考虑取代Kafka呢？

底层存储是HDFS或S3等廉价存储，支持ORC、Avro等存储结构。可以对中间层的结果数据进行OLAP分析。基于该功能，可以将离线任务的延迟从日级大幅降低到小时级，转变为近实时的数据湖分析系统。

在中间处理层，可以执行一些简单的SQL查询。因为支持Read，所以也可以直接访问系统中间层的Flink。可以直接在中间层使用Flink来做一些批处理或者流计算任务。结果进一步计算并输出到下游。

4.4 替代Kafka的优缺点

总的来说，替代Kafka的优点主要包括：

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

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

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

将数据连同CDC标志一起直接放入其中。合并时，这些增量数据按照一定的组织格式和一定的高效计算方法，与之前的全量数据进行合并。这样做的好处是支持近实时导入和实时数据读取；该计算方案的Flink SQL原生支持CDC摄取，不需要额外的业务领域设计。

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

数据湖可能是下一次大数据技术革命的亮点。我们要抓住机遇，抓住机会，一起了解数据湖。但我的建议仍然是“学而不用”。我为什么这么说呢？举个例子：2年初，我们仓促推出了Flink，然后每个月升级一个版本。真是太多了。所以，我们会等各大互联网公司把坑填完，然后直接快速上线数据湖，但是我们一定要学习。

六、总结

通过这篇文章，我们对什么是数据湖、为什么要学习数据湖、它能解决哪些实际问题有了一个基本的了解。稍后我们将继续重点解释为什么要选择数据湖解决方案。