数据湖三剑客HudiDeltaLake和Iceberg深度对

　　一个热爱生活又放荡不羁的程序猿
　　本文主要讲解如下内容：
　　一、数据湖的优点
　　二、目前有哪些开源数据湖组件
　　三、三大数据湖组件对比1、数据湖的优点
　　数据湖相比传统数仓而言，最明显的便是优秀的T0能力，这个解决了Hadoop时代数据分析的顽疾。传统的数据处理流程从数据入库到数据处理通常需要一个较长的环节、涉及许多复杂的逻辑来保证数据的一致性，由于架构的复杂性使得整个流水线具有明显的延迟。2、目前有哪些开源数据湖组件
　　目前开源的数据湖有江湖人称数据湖三剑客的Hudi、DeltaLake和IcebergIceberg
　　Iceberg官网定义：Iceberg是一个通用的表格式（数据组织格式），提供高性能的读写和元数据管理功能。
　　Iceberg的ACID能力可以简化整个流水线的设计，传统HiveSpark在修正数据时需要将数据读取出来，修改后再写入，有极大的修正成本。
　　〔玫瑰〕ACID能力，无缝贴合流批一体数据存储
　　随着flink等技术的不断发展，流批一体生态不断完善，但在流批一体数据存储方面一直是个空白，直到Iceberg等数据湖技术的出现，这片空白被慢慢填补。
　　Iceberg提供ACID事务能力，上游数据写入即可见，不影响当前数据处理任务，这大大简化了ETL；
　　Iceberg提供了upsert、mergeinto能力，可以极大地缩小数据入库延迟；
　　〔玫瑰〕统一数据存储，无缝衔接计算引擎和数据存储
　　Iceberg提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流任务可以使用相同的存储模型，数据不再孤立；
　　Iceberg支持隐藏分区和分区进化，方便业务进行数据分区策略更新。
　　Iceberg屏蔽了底层数据存储格式的差异，提供对于Parquet，ORC和Avro格式的支持。将上层引擎的能力传导到下层的存储格式。
　　〔玫瑰〕开放架构设计，开发维护成本相对可控
　　Iceberg的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎对接，目前Iceberg支持的计算引擎有Spark、Flink、Presto以及Hive。
　　相比于Hudi、DeltaLake，Iceberg的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计；
　　面向对象存储的优化。Iceberg在数据组织方式上充分考虑了对象存储的特性，避免耗时的listing和rename操作，使其在基于对象存储的数据湖架构适配上更有优势。
　　〔玫瑰〕增量数据读取，实时计算的一把利剑
　　Iceberg支持通过流式方式读取增量数据，支持StructedStreaming以及FlinktableSource。Hudi
　　ApacheHudi是一种数据湖的存储格式，在Hadoop文件系统之上提供了更新数据和删除数据的能力以及消费变化数据的能力。
　　Hudi支持如下两种表类型：CopyOnWrite
　　使用Parquet格式存储数据。CopyOnWrite表的更新操作需要通过重写实现。MergeOnRead
　　使用列式文件格式（Parquet）和行式文件格式（Avro）混合的方式来存储数据。MergeOnRead使用列式格式存放Base数据，同时使用行式格式存放增量数据。最新写入的增量数据存放至行式文件中，根据可配置的策略执行COMPACTION操作合并增量数据至列式文件中。
　　应用场景近实时数据消费
　　Hudi支持插入、更新和删除数据。可以实时消费消息队列（Kafka）和日志服务SLS等日志数据至Hudi中，同时也支持实时同步数据库Binlog产生的变更数据。
　　Hudi优化了数据写入过程中产生的小文件。因此，相比其他传统的文件格式，Hudi对HDFS文件系统更加的友好。近实时数据分析
　　Hudi支持多种数据分析引擎，包括Hive、Spark、Presto和Impala。Hudi作为一种文件格式，不需要依赖额外的服务进程，在使用上也更加的轻量化。增量数据处理
　　Hudi支持IncrementalQuery查询类型，可以通过SparkStreaming查询给定COMMIT后发生变更的数据。Hudi提供了一种消费HDFS变化数据的能力，可以用来优化现有的系统架构。DeltaLake
　　DeltaLake是Spark计算框架和存储系统之间带有Schema信息数据的存储中间层。它给Spark带来了三个最主要的功能：
　　第一，DeltaLake使得Spark能支持数据更新和删除功能；
　　第二，DeltaLake使得Spark能支持事务；
　　第三，支持数据版本管理，运行用户查询历史数据快照。
　　核心特性ACID事务：为数据湖提供ACID事务，确保在多个数据管道并发读写数据时，数据能保持完整性。数据版本管理和时间旅行：提供了数据快照，使开发人员能够访问和还原早期版本的数据以进行审核、回滚或重现实验可伸缩的元数据管理：存储表或者文件的元数据信息，并且把元数据也作为数据处理，元数据与数据的对应关系存放在事务日志中；流和批统一处理：Delta中的表既有批量的，也有流式和sink的；数据操作审计：事务日志记录对数据所做的每个更改的详细信息，提供对更改的完整审计跟踪；Schema管理功能：提供自动验证写入数据的Schema与表的Schema是否兼容的能力，并提供显示增加列和自动更新Schema的能力；数据表操作（类似于传统数据库的SQL）：合并、更新和删除等，提供完全兼容Spark的JavascalaAPI；统一格式：Delta中所有的数据和元数据都存储为ApacheParquet。三、三大数据湖组件对比各组件起源故事
　　Deltalake
　　由于ApacheSpark在商业化上取得巨成功，所以由其背后商业公司Databricks推出的Deltalake也显得格外亮眼。在没有delta数据湖之前，Databricks的客户般会采经典的lambda架构来构建他们的流批处理场景。
　　Hudi
　　ApacheHudi是由Uber的程师为满其内部数据分析的需求设计的数据湖项，它提供的fastupsertdelete以及compaction等功能可以说是精准命中民群众的痛点，加上项各成员积极地社区建设，包括技术细节分享、国内社区推等等，也在逐步地吸引潜在户的光。
　　Iceberg
　　Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷之后，开始转为研Iceberg，并最终演化成Apache下个度抽象通的开源数据湖案。共同点
　　三者均为DataLake的数据存储中间层，其数据管理的功能均是基于系列的meta件。Meta件的类似于数据库的catalog，起到schema管理、事务管理和数据管理的功能。与数据库不同的是，这些meta件是与数据件起存放在存储引擎中的，户可以直接看到。这个做法直接继承了数据分析中数据对户可见的传统，但是形中也增加了数据被不破坏的风险。旦删了meta录，表就被破坏了，恢复难度很。
　　Meta包含有表的schema信息。因此系统可以掌握schema的变动，提供schema演化的持。Meta件也有transactionlog的功能（需要件系统有原性和致性的持）。所有对表的变更都会成份新的meta件，于是系统就有了ACID和多版本的持，同时可以提供访问历史的功能。在这些，三者是相同的。Hudi优点
　　Hudi的设计标正如其名，HadoopUpsertsDeletesandIncrementals（原为HadoopUpsertsanDIncrementals），强调了其主要持Upserts、Deletes和Incremental数据处理，其主要提供的写具是SparkHudiDataSourceAPI和提供的HoodieDeltaStreamer，均持三种数据写式：UPSERT，INSERT和BULKINSERT。其对Delete的持也是通过写时指定定的选项持的，并不持纯粹的delete接。
　　在查询，Hudi持Hive、Spark、Presto。
　　在性能，Hudi设计了HoodieKey，个类似于主键的东西。对于查询性能，般需求是根据查询谓词成过滤条件下推datasource。Hudi这没怎么做作，其性能完全基于引擎带的谓词下推和partitionprune功能。
　　Hudi的另特是持CopyOnWrite和MergeOnRead。前者在写时做数据的merge，写性能略差，但是读性能更些。后者读的时候做merge，读性能差，但是写数据会较及时，因后者可以提供近实时的数据分析能。最后，Hudi提供了个名为runsynctool的脚本同步数据的schema到Hive表。Hudi还提供了个命令具于管理Hudi表。Iceberg优点
　　Iceberg没有类似的HoodieKey设计，其不强调主键。没有主键，做updatedeletemerge等操作就要通过Join来实现，Join需要有个类似SQL的执引擎。
　　Iceberg在查询性能做了量的作。值得提的是它的hiddenpartition功能。Hiddenpartition意思是说，对于户输的数据，户可以选取其中某些列做适当的变换（Transform）形成个新的列作为partition列。这个partition列仅仅为了将数据进分区，并不直接体现在表的schema中。Delta优点
　　Delta的定位是流批体的，持updatedeletemerge，spark的所有数据写式，包括基于dataframe的批式、流式，以及SQL的Insert、InsertOverwrite等都是持的。
　　不强调主键，因此其updatedeletemerge的实现均是基于spark的join功能。在数据写，Delta与Spark是强绑定的，这点Hudi是不同的：Hudi的数据写不绑定Spark。
　　在查询，Delta前持Spark与Presto，但是，Spark是不可或缺的，因为deltalog的处理需要到Spark。这意味着如果要Presto查询Delta，查询时还要跑个Spark作业。更为难受的是，Presto查询是基于SymlinkTextInputFormat。在查询之前，要运Spark作业成这么个Symlink件。如果表数据是实时更新的，意味着每次在查询之前先要跑个SparkSQL，再跑Presto。为此，EMR在这做了改进可以不必事先启动个Spark任务。
　　在查询性能，开源的Delta乎没有任何优化。
　　Delta在数据merge性能不如Hudi，在查询性能不如Iceberg，是不是意味着Delta是处了呢？其实不然。Delta的优点就是与Spark的整合能，尤其是其流批体的设计，配合multihop的datapipeline，可以持分析、Machinelearning、CDC等多种场景。使灵活、场景持完善是它相Hudi和Iceberg的最优点。另外，Delta号称是Lambda架构、Kappa架构的改进版，需关流批，需关架构。这点上Hudi和Iceberg是所不及的。总结
　　三个引擎的初衷场景并不完全相同，Hudi为了incremental的upserts，Iceberg定位于性能的分析与可靠的数据管理，Delta定位于流批体的数据处理。这种场景的不同也造成了三者在设计上的差别。尤其是Hudi，其设计与另外两个相差别更为明显。
　　Delta、Hudi、Iceberg三个开源项中，Delta和Hudi跟Spark的代码深度绑定，尤其是写路径。这两个项设计之初，都基本上把Spark作为他们的默认计算引擎了。ApacheIceberg的向常坚定，宗旨就是要做个通化设计的TableFormat。
　　Iceberg完美的解耦了计算引擎和底下的存储系统，便于多样化计算引擎和件格式，很好的完成了数据湖架构中的TableFormat这层的实现，因此也更容易成为TableFormat层的开源事实标准。另，ApacheIceberg也在朝着流批体的数据存储层发展，manifest和snapshot的设计，有效地隔离不同transaction的变更，常便批处理和增量计算。并且，ApacheFlink已经是个流批体的计算引擎，者都可以完美匹配，合打造流批体的数据湖架构。
　　ApacheIceberg这个项背后的社区资源常丰富。在国外，Netflix、Apple、Linkedin、Adobe等公司都有PB级别的产数据运在ApacheIceberg上；在国内，腾讯这样的巨头也有常庞的数据跑在ApacheIceberg之上，最的业务每天有T的增量数据写。