数据湖架构（数据湖架构设计）

本篇文章给大家谈谈数据湖架构，以及数据湖架构设计对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、「数据湖篇」一文带你深入理解数据湖
• 2、滴普科技的云原生数据湖仓架构在存算分离方面靠谱吗？
• 3、Zoom 在数据湖上的流批一体架构实践！
• 4、“数据湖三剑客”Hudi、Delta Lake和Iceberg 深度对比

「数据湖篇」一文带你深入理解数据湖

数据湖相当于一个汇集着来自各个异构数据源的 原生态数据，不经过加工清洗数据 ，数据的格式也五花八门， 结构化和半结构化和非结构化的数据 都能够被数据湖管理起来。

那么就引申出 数据湖的特点 ：

数据湖和数据仓库可以用来互补，数据湖可以在非结构化数据处理方面扩展业务能力。对于许多公司来说，通过数据湖来增强现有的数据仓库，已经被证明是一种高效的方式

数据湖的本质 ，是由 数据存储架构+数据处理工具 组成的解决方案。

数据架构存储 ：要求要有足够强大的扩展性和可靠性，才能存得下和存得久要入湖的数据，比如AmazonWebServices亚马逊云科技的S3云对象存储。

数据处理工具 ：主要解决2类问题，一类是把数据移动到湖里，一类是管理湖里的数据。

总结：数据湖不只是个“囤积”数据的“大水坑”，除了用存储技术构建的湖底座以外，还包含一系列的数据入湖、数据出湖、数据管理、数据应用工具集，共同组成了数据湖解决方案。

数据沼慎旦泽 ：各式各样的数据都往"湖里倾倒"，缺乏元数据管理，最终会把好好的数据湖变成了数据沼泽，导致数据湖中的数据使用困难。

数据重力 ：指的是随着数据积累越来越多，则要移动它们就越来越难，这便是所谓的数据重力。

Lake House，即所谓的 湖仓一体架构 ， 数据湖和数据仓库相结合发挥作用，实现“湖简虚里”和“仓里”的数据/元数据能够无缝打通，并且“自由”流动 。比如湖里的“新鲜”数据可以流到仓里，甚至可以直接被数仓使用，而仓里的“不新鲜”数据，也可以流到湖里，低成本长久保存，供未来的数据挖掘使用。

Lake House不仅要把湖、仓打通，还要克服“数据重力”，让数据在这些服务之间按需来回移动：入湖、出湖、环湖……

智能湖仓的设计， 采用各下游组件都“环湖而造”的理念 ，既可以直接操纵湖内数据，也可以从湖中摄取数据，还可以向湖中回注数据，同时环湖的服务彼此之间也可以轻宽咐扰松交换数据。

上面这个六层架构，从数据源定义、数据摄取和入湖入仓，到湖仓打通与集成，再到数据出湖、数据处理和数据消费，一气呵成，各种云上数据服务无缝集成在一起，创新了未来一个新的大数据解决方案。

滴普科技的云原生数据湖仓架构在存算分离方面靠谱吗？

॒靠谱是肯定靠谱的，他们家的FastData实时湖仓平台基于存算分离架构的实时晌袜岁湖仓引擎，好虚就实践了缓存（文件缓存、结果集缓存、语义缓宴睁存等）、索引（基于 Apache Iceberg 的Z-order、Bloom Filter索引）、统一元数据架构等创新技术。

Zoom 在数据湖上的流批一体架构实践！

1. 背景

OnZoom是Zoom新产品，是基于Zoom Meeting的一个独一无二的在线活动平台和市场。作为Zoom统一通信平台的延伸，OnZoom是一个综合性解决方案，为付费的Zoom用户提供创建、主持和盈利的活动，如健身课、音乐会、站立表演或即兴表演，以及Zoom会议平台上的音乐课程。

在OnZoom data platform中，source数据主要分为MySQL DB数据和Log数据。其中Kafka数据通过Spark Streaming job实时消费,MySQL数据通过Spark Batch job定时同步, 将source数据Sink到AWS S3。之后定时调度Spark Batch Job进行数仓开发。最终按照实际业务需求或使用场景将数据Sink到合适的存储。

初版架构问题

2. 架构优化升级

基于以上问题，我们在进行大量技术调研选型及POC之后，我们主要做了如下2部分大的架构优化升级。

MySQL Binlog即二脊做进制日志,它记录了MySQL所有表结构和表数据变更。

Cannal基于MySQL Binlog日志解析，提供增量数据订阅和消费,将数据Sink到Kafka实现CDC。

后续使用Spark Streaming job实时消费Binlog就能解决上述问题1的时效性以及物理删除等问题。

我们需要有一种能够兼容S3存储之后，既支持大量数据的批处理又支持增加数据的流处理的数据湖解决方案。最终我们选择Hudi作为我们数据湖架构方案，主要原因如下:

•Hudi通过维护索引支持高效的记录级别的增删改•Hudi维护了一条包含在不同的即时时间（instant time）对数据集做的所有instant操作的timeline,可以获取给定时间内的CDC数据(增量查询)。也提供了基于最新文件的Raw Parquet 读优化查询。从而实现流批一体架构而不是典型的Lambda架构。•Hudi智能自动管理文件大小，而不用用户干预就能解决小文件问题•支持S3存储，支持Spark、Hive、Presto查询引擎，入门成本较低只需引入对应Hudi package

3. Hudi 实践经验分享

1.Hudi upsert 时默认PAYLOAD_CLASS_OPT_KEY为OverwriteWithLatestAvroPayload，该方式upsert时会将所有字段都更新为当前传入的DataFrame。但很多场景下可能只想更新其中某几个字段，其他字段跟已有数据保持一致，此时需要将PAYLOAD_CLASS_OPT_KEY传为OverwriteNonDefaultsWithLatestAvroPayload，将不需要更新的字段设为null。但该upsert方式也有一定限制，比如不能将某个值更新为null。2.我们现在有实时同步数据，离线rerun数据的场景，但当前使用的是Hudi 0.7.0版本，该版本还不支持多个job并发写Hudi表。临时方案是每次需要rerun数据的时候暂停实时任务，因为0.8.0版本已经支持并发写，后续考虑升级。3.一开始我们任务变更Hudi表数据时每次都默认同步hive元数据。但对于实时任务每次连接Hive Metastore更新元数据很浪费资源，因为大部分操作只涉及到数据变更而不涉及表结构或者分区变动。所以我们后来将实时任务关闭同步hive元数据，在需要更新元数据时另外再执行hudi-hive-sync-bundle-*.jar来同步。

4.Hudi增量查询语义是返回给定时间内所有的变更数据，所以会在timeline在里查找历史所有commits文件。但历史commits文件会根据retainCommits参数被清理，所以如果给定时间跨度较大时可能会获取不到完整的变更数据。如果只关心数据的最滚野旦终状态，可以根据_hoodie_commit_time来过滤获取增量数据。5.Hudi默认spark分区并行度大扰withParallelism为1500，需要根据实际的输入数据大小调整合适的shuffle并行度。(对应参数为 hoodie.[insert|upsert|bulkinsert].shuffle.parallelism)6.Hudi基于parquet列式存储，支持向后兼容的schema evolution,但只支持新的DataFrame增加字段的schema变更，预计在在 0.10 版本实现 full schema evolution。如果有删除或重命名字段的需求，只能overwrite。另外增加字段也可能导致hive sync metadata失败，需要先在hive执行drop table。

7.Hudi Insert 对 recordKey 相同的数据，根据不同的参数有不同的处理情况，决定性的参数包括以下三个:   

  其中：hoodie.combine.before.insert 决定是否对同一批次的数据按 recordKey 进行合并，默认为 false；hoodie.parquet.small.file.limit 和hoodie.merge.allow.duplicate.on.inserts 控制小文件合并阈值和如何进行小文件合并。如果 hoodie.parquet.small.file.limit 0 并且 hoodie.merge.allow.duplicate.on.inserts 为 false，那么在小文件合并的时候，会对相同 recordKey 的数据进行合并。此时有概率发生去重的情况 （如果相同 recordKey 的数据写入同一文件中）；如果 hoodie.parquet.small.file.limit 0 并且 hoodie.merge.allow.duplicate.on.inserts 为 true，那么在小文件合并的时候，不会处理相同 recordKey 的数据

4. 总结

基于Hudi实现流批一体数据湖架构上线生产环境已有半年多时间，在引入Hudi之后我们在以下各个方面都带来了一定收益:

• 成本: 引入Hudi数据湖方案之后，实现了S3数据增量查询和增量更新删除，之前更新删除方案只能全表overwrite。Hudi实现智能小文件合并，之前需要单独任务去处理。在数据处理和存储方面都节约了相应成本，预估节省 1/4 费用。

• 时效性: 所有ODS表已从T+1改造为Near Real Time 。后续会建设更多实时表。

• 效率: 

(1)  在插入及更新数据时,默认情况下，Hudi使用Bloom Index，该索引更适合单调递增record key，相比于原始Spark Join，其速度最高可提高 10倍 。

(2) 查询数据时，借助Hudi提供的Clustering(将文件按照某些列进行聚簇，以重新布局，达到优化查询性能的效果)，Compaction(将基础文件和增量日志文件进行合并，生成新版本列存文件)等服务，可将 查询性能提升50%+ 。

[img]

“数据湖三剑客”Hudi、Delta Lake和Iceberg 深度对比

一个热爱生活又放荡不羁的程序猿

本文主要讲解如下内容：

一、数据湖的优点

二、目前有哪些开源数据湖组件

三、三大数据湖组件对比

数据湖相比传统数仓而言，最明显的便是优秀的T+0能力，这个解决了Hadoop时代数据分析的顽疾。传统的数据处理流程从数据入库到数据处理通常需要一个较长的环节、涉及许多复杂的逻辑来保证数据的一致性，由于架构的复杂性使得整个流水线具有明显的延迟。

目前开源的数据湖有江湖人称“数据湖三剑客”的 Hudi、Delta Lake和Iceberg

Iceberg官网定义：Iceberg是一个通用的表格式（数据组织格式），提供高性能的读写和元数据管理功能。

Iceberg 的 ACID 能力可以简化整个流水线的设计，传统 Hive/Spark 在修正数据时需要将数据读取出来，修改后再写入，有极大的修正成本。

[玫瑰]ACID能力，无缝贴合流批一体数据存储

随着flink等技术的不断发展，流批一体生态不断完善，但在流批一体数据存储方面一直是个空白，直到Iceberg等数据湖技术的出现，这片空白被慢慢填补。

Iceberg 提供 ACID 事务能力，上游数据写入即可见，不影响当前数据处理任务，这大大简化了 ETL；

Iceberg 提供了 upsert、merge into 能力，可以极大地缩小数据入库延迟；

[玫瑰]统一数据存储，无缝衔接计算引擎和数据存储

Iceberg提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流任务可以使用相同的存储模型，数据不再孤立；

Iceberg 支持隐藏分区和分区进化，方便业务进行数据分区策略更新。

Iceberg屏蔽了底层数据存枣罩储格式的差异，提供对于Parquet，ORC和Avro格式的支持。将上层引擎的能力传导到下层的存储格式。

[玫瑰]开放架构设计，开发维护成本相对可控

Iceberg 的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎对接，目前 Iceberg 支持的计算引擎有 Spark、Flink、Presto 以及 Hive。

相比于 Hudi、Delta Lake，Iceberg 的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计；

面向对象存储的优化。Iceberg 在数据组织方式上充分考虑了对象存储的特性，避免耗时的 listing 和 rename 操作，使其在基于对象存储的数据湖架构适配上更有优势。

[玫瑰]增量数据读取，实时计算的一把利剑

Iceberg 支持通过流式方式读取增量数据，支持 Structed Streaming 以及 Flink table Source。

Apache Hudi是一种数据湖的存储格式，在Hadoop文件系统之上提供了更新数据和删除数据的能力以及消费变化数据的能力。

Hudi支持如下两种表类型：

使用Parquet格式存储数据。Copy On Write表的更新操作需要通过重写实现。

使用列式文件格式（Parquet）和行式文件格式（Avro）混合的方式来存储数据。Merge On Read使用列式格式存放Base数据，同时使用行式格式存放增量数据。最新写入的增量数据存放至行式文件中，根据可配置的策略执行COMPACTION操作合并增量数据至列式文件中。

应用场景

Hudi支持插入、更新和删除数据。可以实时消费消息队列（Kafka）和日志服务SLS等日志数据至Hudi中，同时也支持实时同步数游岩梁据库Binlog产生的变更数据。

Hudi优化了数据写入过程中产生的小文件。因此，相比其神运他传统的文件格式，Hudi对HDFS文件系统更加的友好。

Hudi支持多种数据分析引擎，包括Hive、Spark、Presto和Impala。Hudi作为一种文件格式，不需要依赖额外的服务进程，在使用上也更加的轻量化。

Hudi支持Incremental Query查询类型，可以通过Spark Streaming查询给定COMMIT后发生变更的数据。Hudi提供了一种消费HDFS变化数据的能力，可以用来优化现有的系统架构。

Delta Lake是Spark计算框架和存储系统之间带有Schema信息数据的存储中间层。它给Spark带来了三个最主要的功能：

第一，Delta Lake使得Spark能支持数据更新和删除功能；

第二，Delta Lake使得Spark能支持事务；

第三，支持数据版本管理，运行用户查询 历史 数据快照。

核心特性

Delta lake

由于Apache Spark在商业化上取得巨 成功，所以由其背后商业公司Databricks推出的Delta lake也显得格外亮眼。在没有delta数据湖之前，Databricks的客户 般会采 经典的lambda架构来构建他们的流批处理场景。

Hudi

Apache Hudi是由Uber的 程师为满 其内部数据分析的需求 设计的数据湖项 ，它提供的fast upsert/delete以及compaction等功能可以说是精准命中 民群众的痛点，加上项 各成员积极地社区建设，包括技术细节分享、国内社区推 等等，也在逐步地吸引潜在 户的 光。

Iceberg

Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷之后，开始转为 研Iceberg，并最终演化成Apache下 个 度抽象通 的开源数据湖 案。

三者均为Data Lake的数据存储中间层，其数据管理的功能均是基于 系列的meta 件。Meta 件的 类似于数据库的catalog，起到schema管理、事务管理和数据管理的功能。与数据库不同的是，这些meta 件是与数据 件 起存放在存储引擎中的， 户可以直接看到。这个做法直接继承了 数据分析中数据对 户可见的传统，但是 形中也增加了数据被不 破坏的风险。 旦删了meta 录，表就被破坏了，恢复难度很 。

Meta包含有表的schema信息。因此系统可以 掌握schema的变动，提供schema演化的 持。Meta 件也有transaction log的功能（需要 件系统有原 性和 致性的 持）。所有对表的变更都会 成 份新的meta 件，于是系统就有了ACID和多版本的 持，同时可以提供访问 历史 的功能。在这些 ，三者是相同的。

Hudi 的设计 标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），强调了其主要 持Upserts、Deletes 和 Incremental 数据处理，其主要提供的写 具是 Spark HudiDataSource API 和 提供的 HoodieDeltaStreamer，均 持三种数据写 式：UPSERT，INSERT 和 BULK_INSERT。其对 Delete 的 持也是通过写 时指定 定的选项 持的，并不 持纯粹的 delete 接 。

在查询 ，Hudi 持 Hive、Spark、Presto。

在性能 ，Hudi 设计了 HoodieKey ， 个类似于主键的东西。对于查询性能， 般需求是根据查询谓词 成过滤条件下推 datasource。Hudi 这 没怎么做 作，其性能完全基于引擎 带的谓词下推和 partition prune 功能。

Hudi 的另 特 是 持 Copy On Write 和 Merge On Read。前者在写 时做数据的 merge，写 性能略差，但是读性能更 些。后者读的时候做 merge，读性能差，但是写 数据会 较及时，因 后者可以提供近实时的数据分析能 。最后，Hudi 提供了 个名为run_sync_tool 的脚本同步数据的 schema 到 Hive 表。Hudi 还提供了 个命令 具 于管理 Hudi 表。

Iceberg 没有类似的 HoodieKey 设计，其不强调主键。没有主键，做 update/delete/merge 等操作就要通过 Join 来实现， Join 需要有 个类似 SQL 的执 引擎。

Iceberg 在查询性能 做了 量的 作。值得 提的是它的 hidden partition 功能。Hidden partition 意思是说，对于 户输 的数据， 户可以选取其中某些列做适当的变换（Transform）形成 个新的列作为 partition 列。这个 partition 列仅仅为了将数据进 分区，并不直接体现在表的 schema中。

Delta 的定位是流批 体的， 持 update/delete/merge，spark 的所有数据写 式，包括基于dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是 持的。

不强调主键，因此其 update/delete/merge 的实现均是基于 spark 的 join 功能。在数据写 ，Delta 与 Spark 是强绑定的，这 点 Hudi 是不同的：Hudi 的数据写 不绑定 Spark。

在查询 ，Delta 前 持 Spark 与 Presto，但是，Spark 是不可或缺的，因为 delta log 的处理需要 到 Spark。这意味着如果要 Presto 查询 Delta，查询时还要跑 个 Spark 作业。更为难受的是，Presto 查询是基于 SymlinkTextInputFormat 。在查询之前，要运 Spark 作业 成这么个 Symlink 件。如果表数据是实时更新的，意味着每次在查询之前先要跑 个 SparkSQL，再跑 Presto。为此，EMR 在这 做了改进可以不必事先启动 个 Spark 任务。

在查询性能 ，开源的 Delta 乎没有任何优化。

Delta 在数据 merge 性能不如 Hudi，在查询 性能不如 Iceberg，是不是意味着 Delta 是处了呢？其实不然。Delta 的 优点就是与 Spark 的整合能 ，尤其是其流批 体的设计，配合 multi-hop 的 data pipeline，可以 持分析、Machine learning、CDC 等多种场景。使 灵活、场景 持完善是它相 Hudi 和 Iceberg 的最 优点。另外，Delta 号称是 Lambda 架构、Kappa 架构的改进版， 需关 流批， 需关 架构。这 点上 Hudi 和 Iceberg 是 所不及的。

三个引擎的初衷场景并不完全相同，Hudi 为了 incremental 的 upserts，Iceberg 定位于 性能的分析与可靠的数据管理，Delta 定位于流批 体的数据处理。这种场景的不同也造成了三者在设计上的差别。尤其是 Hudi，其设计与另外两个相 差别更为明显。

Delta、Hudi、Iceberg三个开源项 中，Delta和Hudi跟Spark的代码深度绑定，尤其是写 路径。这两个项 设计之初，都基本上把Spark作为他们的默认计算引擎了。 Apache Iceberg的 向 常坚定，宗旨就是要做 个通 化设计的Table Format。

Iceberg完美的解耦了计算引擎和底下的存储系统，便于多样化计算引擎和 件格式，很好的完成了数据湖架构中的Table Format这 层的实现，因此也更容易成为Table Format层的开源事实标准。另 ，Apache Iceberg也在朝着流批 体的数据存储层发展，manifest和snapshot的设计，有效地隔离不同transaction的变更， 常 便批处理和增量计算。并且，Apache Flink已经是 个流批 体的计算引擎， 者都可以完美匹配，合 打造流批 体的数据湖架构。

Apache Iceberg这个项 背后的社区资源 常丰富。在国外，Netflix、Apple、Linkedin、Adobe等公司都有PB级别的 产数据运 在Apache Iceberg上；在国内，腾讯这样的巨头也有 常庞 的数据跑在Apache Iceberg之上，最 的业务每天有 T的增量数据写 。

关于数据湖架构和数据湖架构设计的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。