数据湖与湖仓一体架构实践

一、什么是数据湖?

数据湖是保存大量原始格式数据的中心位置。与以文件或文件夹形式存储数据的分层数据仓库相比，数据湖采用扁平化架构和对象存储方式来存储数据。‍对象存储具有元数据标签和唯一标识符，便于跨区域定位和检索数据，提高性能。通过利用廉价的对象存储和开放格式，数据湖使许多应用程序能够利用数据。

数据湖是为了应对数据仓库的局限性而开发的。虽然数据仓库为企业提供高性能和可扩展的分析，但它们昂贵、专有，不能处理大多数公司正在寻求解决的现代用例场景。

数据湖通常用于将企业的所有数据合并到一个单一的中心位置，在那里数据可以“原样”保存，而不需要像数据仓库那样预先强加一个模式(即数据组织方式的正式结构)。细化过程中所有阶段的数据都可以存储在数据湖中：原始数据可以与组织的结构化、表格式数据源(如数据库表)以及在细化原始数据过程中生成的中间数据表一起被接入和存储。

与大多数数据库和数据仓库不同，数据湖可以处理所有数据类型——包括非结构化和半结构化数据，如图像、视频、音频和文档——这对今天的机器学习和高级分析用例至关重要。

二、为什么要使用数据湖?

首先，数据湖是开放格式的，因此用户可以避免被锁定在数据仓库这样的专有系统中，而数据仓库在现代数据体系结构中已经变得越来越重要。数据湖还具有高度的持久性和低成本，因为它们具有扩展和利用对象存储的能力。

此外，对非结构化数据的高级分析和机器学习是当今企业最重要的战略重点之一。以各种格式(结构化、非结构化、半结构化)摄取原始数据的独特能力，以及前面提到的其他优点，使数据湖成为数据存储的明确选择。

当架构正确时，数据湖能够:

• 为数据科学和机器学习提供支持：数据湖允许将原始数据转换为结构化数据，以便在低延迟的情况下进行SQL分析、数据科学和机器学习。原始数据可以以较低的成本无限期地保留，以便将来在机器学习和分析中使用。
• 对数据进行集中、合并和分类：集中式数据湖消除了数据烟囱的问题(如数据重复、多个安全策略和协作困难)，为下游用户提供了一个查找所有数据源的单一位置。
• 快速无缝地集成各种数据源和格式：任何和所有数据类型都可以收集并无限期地保留在数据湖中，包括批处理和流数据、视频、图像、二进制文件等。由于数据湖为新数据提供了一个着陆区域，它总是最新的。
• 通过向用户提供自助服务工具使数据大众化：数据湖非常灵活，让拥有完全不同技能、工具和语言的用户能够同时执行不同的分析任务。

三、数据湖的挑战

尽管数据湖有很多优点，但数据湖带来的各种挑战会减缓创新和生产力。数据湖缺乏保证数据质量和可靠性所需的特性。看似简单的任务可能会大幅降低数据湖的性能，而且由于安全性和治理特性较差，数据湖无法满足业务和监管需求。

（1）可靠性的问题

如果没有适当的工具，数据湖可能会出现数据可靠性问题，使数据科学家和分析师难以对数据进行推理。这些问题可能源于难以组合批量数据和流数据、数据损坏和其他因素。

（2）缓慢的性能

随着数据湖中数据规模的增加，传统查询引擎的性能通常会变慢。一些瓶颈包括元数据管理、不正确的数据分区等。

（3）缺乏安全特性

由于缺乏可见性和删除或更新数据的能力，数据湖很难得到妥善的保护和治理。这些限制使其很难满足监管机构的要求。

解决数据湖挑战的方法是lakehouse，它通过在上面添加事务存储层来解决数据湖的挑战。一个lakehouse，使用类似于数据仓库的数据结构和数据管理功能，但直接在云数据湖上运行。最终，lakehouse允许传统的分析、数据科学和机器学习以一种开放的格式共存于同一个系统中。

lakehouse为企业数据分析、BI和机器学习项目提供了广泛的新用例，这些项目可以释放巨大的商业价值。通过使用SQL查询数据湖中的数据，数据分析师能获得丰富的见解，数据科学家可以加入和丰富的数据集生成ML模型与更高的精度，数据工程师可以构建自动化ETL管道，BI人员可以创建视觉仪表盘和报表工具，比以前更快和更容易。这些用例都可以在数据湖上同时执行，无需提升和移动数据，即使有新数据流入。

数据湖与数据仓库一般特征

四、数据仓库VS数据湖

企业正在从各种来源收集海量数据，这些数据远远超出传统关系数据库可处理的范畴。这导致数据仓库与数据湖问题：何时使用哪一个以及它们与数据集市、操作数据存储和关系数据库的对比。

所有这些数据存储库都具有相似的核心功能：存储数据用于业务报告和分析。但是它们的目的、结构、它们存储的数据类型、来自哪里以及谁有权访问都各有不同。

通常情况下，这些存储库中的数据来自生成数据的系统：CRM、ERP、HR、财务应用程序和其他来源。这些系统创建的数据记录将应用业务规则，然后发送到数据仓库、数据湖或其他数据存储区域。

当来自不同业务应用程序的所有数据整理到单个数据平台后，我们就可以使用数据分析工具，以识别趋势或提供见解以帮助制定业务决策。

数据仓库vs.数据湖

当企业从运营系统获得大量数据，并需要随时分析数据时，企业通常会选择数据仓库与数据湖。数据仓库通常作为单一事实来源，因为这些平台会存储历史数据，包括已经过清理和分类的数据。

数据仓库主要存储来自运营系统的大量数据，而数据湖则存储来自更多来源的数据，包括来自企业的运营系统和其他来源的各种原始数据资产集。

由于数据湖中的数据可能不准确，并且可能来自企业运营系统之外的来源，因此不是很适合普通的业务分析用户；数据湖更适合数据科学家和其他数据分析专家。

对于数据仓库与数据湖的不同之处，你可以想象一下仓库和湖泊的区别：仓库存储着来自特定来源的货物，而湖泊的水来自河流、溪流和其他来源，并且是原始数据。

数据仓库供应商包括AWS、Cloudera、IBM、谷歌、微软、甲骨文、Teradata、SAP、SnapLogic和Snowflake等。数据湖提供商包括AWS、谷歌、Informatica、微软、Teradata等。

数据仓库vs.数据集市

数据集市和数据仓库经常会被混淆，但两者的用途明显不同。

数据集市通常是数据仓库的子集；它等数据通常来自数据仓库 – 尽管还可以来自其他来源。数据集市的数据专门针对特定的用户社区（例如销售团队），以便他们能够快速找到所需的数据。通常，数据保存在那里用于特定用途，例如财务分析。

数据集市也比数据仓库小得多 – 它们可以容纳数十千兆字节，相比之下，数据仓库可以存储数百千兆字节到PB级数据，并可用于数据处理。

数据集市可从现有数据仓库或其他数据源系统构建，你只需设计和构建数据库表，使用相关数据填充数据库表并决定谁可以访问数据集即可。

数据仓库vs.ODS

操作数据存储（ODS）是一种数据库，用作所有数据的临时存储区域，这些数据即将进入数据仓库进行数据处理。我们可以将其想象成仓库装卸码头，货物在此处交付、检查和验证。

在ODS中，数据在进入仓库前可以被清理、检查（因为冗余目的），也可检查是否符合业务规则。 在ODS中，我们可以对数据进行查询，但是数据是临时的，因此它仅提供简单信息查询，例如正在进行的客户订单状态。

ODS通常运行在关系数据库管理系统（RDBMS）或Hadoop平台。ODS中的数据通常通过数据集成和数据提取工具（例如Attunity Replicate或Hortonworks DataFlow）提供。

关系型数据库vs.数据仓库和数据湖

数据仓库、数据湖与关系数据库系统之间的主要区别在于，关系数据库用于存储和整理来自单个来源（例如事务系统）的结构化数据，而数据仓库则用于存储来自多个来源的结构化数据。数据湖的不同之处在于它可存储非结构化、半结构化和结构化数据。

关系数据库创建起来相对简单，可用于存储和整理实时数据，例如交易数据等。关系数据库的缺点是它们不支持非结构化数据库数据或现在不断生成的大量数据。这使得我们只能在数据仓库与数据湖间做出选择。尽管如此，很多企业仍然继续依赖关系数据库来完成运营数据分析或趋势分析等任务。

五、汽车之家湖仓一体架构实践案例分享

以下文字来源DataFunTalk，介绍了如何基于Apache Iceberg构建湖仓一体架构，将数据可见性提升至分钟级；从多维分析的角度来探讨引入Apache Iceberg带来的收益，以及未来还有哪些收益可以期待。

01

数据仓库架构升级的背景

1. 基于 Hive 的数据仓库的痛点

原有的数据仓库完全基于 Hive 建造而成，主要存在上述三大痛点。

2. Iceberg 关键特性

Iceberg 主要有四大关键特性：支持 ACID 语义、增量快照机制、开放的表格式和流批接口支持。

02

基于 Iceberg 的湖仓一体架构实践

湖仓一体的意义就是说我不需要看见湖和仓，数据有着打通的元数据的格式，它可以自由的流动，也可以对接上层多样化的计算生态。

——贾扬清

1. Append 流入湖的链路

上图为日志类数据入湖的链路，日志类数据包含客户端日志、用户端日志以及服务端日志。这些日志数据会实时录入到 Kafka，然后通过 Flink 任务写到 Iceberg 里面，最终存储到 HDFS。

2. Flink SQL 入湖链路打通

我们的 Flink SQL 入湖链路打通是基于 “Flink 1.11 + Iceberg 0.11” 完成的，对接 Iceberg Catalog 我们主要做了以下内容：

• Meta Server 增加对 Iceberg Catalog 的支持；
• SQL SDK 增加 Iceberg Catalog 支持。

然后在这基础上，平台开放 Iceberg 表的管理功能，使得用户可以自己在平台上建 SQL 的表。

3. 入湖 - 支持代理用户

第二步是内部的实践，对接现有预算体系、权限体系。

因为之前平台做实时作业的时候，平台都是默认为 Flink 用户去运行的，之前存储不涉及 HDFS 存储，因此可能没有什么问题，也就没有思考预算划分方面的问题。

但是现在写 Iceberg 的话，可能就会涉及一些问题。比如数仓团队有自己的集市，数据就应该写到他们的目录下面，预算也是划到他们的预算下，同时权限和离线团队账号的体系打通。

如上所示，这块主要是在平台上做了代理用户的功能，用户可以去指定用哪个账号去把这个数据写到 Iceberg 里面，实现过程主要有以下三个。

① 增加 Table 级别配置：'iceberg.user.proxy' = 'targetUser’

• 启用 Superuser
• 团队账号鉴权

② 访问 HDFS 时启用代理用户：

③ 访问 Hive Metastore 时指定代理用户

• 参考 Spark 的相关实现：

org.apache.spark.deploy.security.HiveDelegationTokenProvider

• 动态代理 HiveMetaStoreClient，使用代理用户访问 Hive metastore

4. Flink SQL 入湖示例

DDL + DML

5. CDC 数据入湖链路

如上所示，我们有一个 AutoDTS 平台，负责业务库数据的实时接入。我们会把这些业务库的数据接入到 Kafka 里面，同时它还支持在平台上配置分发任务，相当于把进 Kafka 的数据分发到不同的存储引擎里，在这个场景下是分发到 Iceberg 里。

6. Flink SQL CDC 入湖链路打通

下面是我们基于 “Flink1.11 + Iceberg 0.11” 支持 CDC 入湖所做的改动：

改进 Iceberg Sink：

Flink 1.11 版本为 AppendStreamTableSink，无法处理 CDC 流，修改并适配。

表管理

• 支持 Primary key（PR1978）
• 开启 V2 版本：'iceberg.format.version' = '2'

7. CDC 数据入湖

① 支持 Bucket

Upsert 场景下，需要确保同一条数据写入到同一 Bucket 下，这又如何实现？

目前 Flink SQL 语法不支持声明 bucket 分区，通过配置的方式声明 Bucket：

'partition.bucket.source'='id', // 指定 bucket 字段

'partition.bucket.num'='10', // 指定 bucket 数量

② Copy-on-write sink

做 Copy-on-Write 的原因是原本社区的 Merge-on-Read 不支持合并小文件，所以我们临时去做了 Copy-on-write sink 的实现。目前业务一直在测试使用，效果良好。

上方为 Copy-on-Write 的实现，其实跟原来的 Merge-on-Read 比较类似，也是有StreamWriter 多并行度写入和 FileCommitter 单并行度顺序提交。

在 Copy-on-Write 里面，需要根据表的数据量合理设置 Bucket 数，无需额外做小文件合并。

StreamWriter 在 snapshotState 阶段多并行度写入

• 增加 Buffer；
• 写入前需要判断上次 checkpoint 已经 commit 成功；
• 按 bucket 分组、合并，逐个 Bucket 写入。

FileCommitter 单并行度顺序提交

• table.newOverwrite()
• Flink.last.committed.checkpoint.id

8. 示例 - CDC 数据配置入湖

如上图所示，在实际使用中，业务方可以在 DTS 平台上创建或配置分发任务即可。

实例类型选择 Iceberg 表，然后选择目标库，表明要把哪个表的数据同步到 Iceberg 里，然后可以选原表和目标表的字段的映射关系是什么样的，配置之后就可以启动分发任务。启动之后，会在实时计算平台 Flink 里面提交一个实时任务，接着用 Copy-on-write sink 去实时地把数据写到 Iceberg 表里面。

9. 入湖其他实践

10. 小文件合并及数据清理

11. 计算引擎 – Flink

Flink 是实时平台的核心计算引擎，目前主要支持数据入湖场景，主要有以下几个方面的特点。

数据准实时入湖：

Flink 和 Iceberg 在数据入湖方面集成度最高，Flink 社区主动拥抱数据湖技术。

平台集成：

AutoStream 引入 IcebergCatalog，支持通过 SQL 建表、入湖 AutoDTS 支持将 MySQL、SQLServer、TiDB 表配置入湖。

流批一体：

在流批一体的理念下，Flink 的优势会逐渐体现出来。

12. 计算引擎 – Hive

Hive 在 SQL 批处理层面 Iceberg 和 Spark 3 集成度更高，主要提供以下三个方面的功能。 参考：Apache Spark 3.0.0重磅发布 —— 重要特性全面解析

定期小文件合并及 meta 信息查询：

SELECT * FROM prod.db.table.history 还可查看 snapshots, files, manifests。

离线数据写入：

• Insert into
• Insert overwrite
• Merge into

分析查询：

主要支持日常的准实时分析查询场景。

13. 计算引擎 – Trino/Presto

AutoBI 已经和 Presto 集成，用于报表、分析型查询场景。

Trino

• 直接将 Iceberg 作为报表数据源
• 需要增加元数据缓存机制：https://github.com/trinodb/trino/issues/7551

Presto

社区集成中：https://github.com/prestodb/presto/pull/15836 参考：Presto在字节跳动的内部实践与优化

14. 踩过的坑

03

收益与总结

1. 总结

通过对湖仓一体、流批融合的探索，我们分别做了总结。

湖仓一体

• Iceberg 支持 Hive Metastore；
• 总体使用上与 Hive 表类似：相同数据格式、相同的计算引擎。

流批融合

准实时场景下实现流批统一：同源、同计算、同存储。

2. 业务收益

3. 架构收益 - 准实时数仓

上方也提到了，我们支持准实时的入仓和分析，相当于是为后续的准实时数仓建设提供了基础的架构验证。准实时数仓的优势是一次开发、口径统一、统一存储，是真正的批流一体。劣势是实时性较差，原来可能是秒级、毫秒级的延迟，现在是分钟级的数据可见性。

但是在架构层面上，这个意义还是很大的，后续我们能看到一些希望，可以把整个原来 “T + 1” 的数仓，做成准实时的数仓，提升数仓整体的数据时效性，然后更好地支持上下游的业务。

04

后续规划

免责声明：本公众号所发布的文章为本公众号原创，或者是在网络搜索到的优秀文章进行的编辑整理，文章版权归原作者所有，仅供读者朋友们学习、参考。对于分享的非原创文章，有些因为无法找到真正来源，如果标错来源或者对于文章中所使用的图片、链接等所包含但不限于软件、资料等，如有侵权，请直接联系后台，说明具体的文章，后台会尽快删除。给您带来的不便，深表歉意。