深度对比Apache CarbonData、Hudi和Open Delta三大开源数据湖方案

背景

我们已经看到，人们更热衷于高效可靠的解决方案，拥有为数据湖提供应对突变和事务处理的能力。在数据湖中，用户基于一组数据生成报告是非常常见的。随着各种类型的数据汇入数据湖，数据的状态不会一层不变。需要改变各种数据的用例包括随时间变化的时序数据、延迟到达的时延数据、平衡实时可用性和回填、状态变化的数据（如CDC）、数据快照、数据清理等，在生成报告时，这些都将被写入/更新在同一组表。

由于Hadoop分布式文件系统（HDFS）和对象存储类似于文件系统，因此它们不是为提供事务支持而设计的。在分布式处理环境中实现事务是一个具有挑战性的问题。例如，日常考虑到锁定对存储系统的访问，这会以牺牲整体吞吐量性能为代价。像Apache CarbonData、OpenDelta Lake、Apache Hudi等存储解决方案，通过将这些事务语义和规则推送到文件格式本身或元数据和文件格式组合中，有效地解决了数据湖的ACID需求。

很多用户看到这三种主要解决方案时，将陷入两难的境地，在不同情况下不知怎么选择？今天我们对比了三大方案，帮助用户更好的根据自己的场景选择解决方案。

Apache Hudi

Apache Hudi是Uber为满足内部数据分析需求而设计的项目。快速upsert/delete和compaction功能可以解决许多实时用例。该项目在Apache社区非常活跃，2020年4月取得了最高项目地位。

从Hudi的名字就能看出他的设计目标， Hadoop Upserts Deletes and Incrementals，主要支持Upserts、Deletes和增量数据处理。其关键特性如下：

1.文件管理

Hudi在DFS上将表组织为basepath下的目录结构。表被划分为分区，这些分区是包含该分区的数据文件的文件夹，类似于Hive表。

2.索引

Hudi通过索引机制将给定的HoodieKey（记录键+分区路径）一致地映射到文件id，从而提供高效的upserts。

3.表类型

Hudi支持的表类型如下：

• 写入时复制：使用专有的列文件格式（如parquet）存储数据。在写入时执行同步合并，只需更新版本并重写文件。
• 读取时合并：使用列（如parquet） +行（如Avro）文件格式的组合存储数据。更新记录到增量文件，并随后压缩以同步或异步生成列文件的新版本。

4.查询类型

Hudi支持三种查询类型：

• 快照查询：查询是在给定的提交或压缩操作之后对表进行快照的请求。利用快照查询时，copy-on-write表类型仅公开最新文件切片中的基/列文件，并保证相同的列查询性能。
• 增量查询：对于写入时复制表，增量查询提供自给定提交或压缩后写入表的新数据，提供更改流以启用增量数据管道。
• 读取优化查询：查询查看指定提交/压缩操作后表的最新快照。只暴露最新文件版本的base/columnar文件，保证列查询性能与非Hudi列表相同。仅在读取表合并时支持

5.Hudi工具

Hudi由不同的工具组成，用于将不同数据源的数据快速采集到HDFS，作为Hudi建模表，并与Hive元存储进一步同步。工具包括：DeltaStreamer、Hoodie-Spark的Datasource API、HiveSyncTool、HiveIncremental puller。

Apache CarbonData

Apache CarbonData是三个产品中最早的，由华为贡献给社区，助力华为云产品的数据平台和数据湖解决方案应对PB级负载。这是一个雄心勃勃的项目，将许多能力都集中在一个项目中。除了支持更新、删除、合并操作、流式采集外，它还拥有大量高级功能，如时间序列、物化视图的数据映射、二级索引，并且还被集成到多个AI平台，如Tensorflow。

CarbonData没有 HoodieKey 设计，不强调主键。更新/删除/合并等操作通过优化的粒度连接实现。CarbonData与Spark紧密集成，在CarbonData层中有很多优化，比如数据跳跃、下推等。在查询方面，CarbonData支持Spark、Hive、Flink、TensorFlow、pyTorch和Presto。一些关键特性包括：

1.查询加速

诸如多级索引、压缩和编码技术等优化旨在提高分析查询的性能，这些查询可能包括过滤器、聚合和用户期望PB级数据的点查询响应时间亚秒级。高级下推优化与Spark深度集成，确保计算在靠近数据处执行，以最小化数据读取、处理、转换和传输的数量。

2.ACID：数据一致性

没有关于故障的中间数据，按快照隔离工作，分离读取和写入。对数据（查询、IUD【插入更新删除】、索引、数据映射、流式处理）的每个操作均符合ACID标准。支持使用基于列和行的格式进行近实时分析，以平衡分析性能和流式采集以及自动切换。

3.一份数据

通过集成Spark、Hive、Presto、Flink、Tensorflow、Pytorch等多种引擎。数据湖解决方案现在可以保留一个数据副本。

4.各种优化指标

其他索引，如二级索引、Bloom、Lucene、Geo-Spatial、实体化视图，可以加速点、文本、聚合、时间序列和Geo空间查询。通过Polygon UDF，CarbonData支持地理空间数据模型。

5.更新和删除

支持合并、更新和删除操作，以启用诸如更改-数据-捕获、缓慢更改-维（SCD-2）操作等复杂用例。

6.高扩展性

Scale存储和处理分离，也适用于云架构。分布式索引服务器可以与查询引擎（如spark, presto）一起启动，以避免跨运行重新加载索引，并实现更快和可扩展的查找。

Delta【开源】

Delta Lake项目于2019年通过Apache License开放源码，是Databricks解决方案的重要组成部分。Delta定位为数据湖存储层，集成流式和批处理，支持更新/删除/合并。为Apache Spark和大数据工作负载提供ACID事务能力。一些关键特性包括：

1.ACID事务

Delta Lake将ACID事务带到您的数据湖中。Delta Lake存储一个事务日志，以跟踪对表目录所做的所有提交，以提供ACID事务。它提供可串行化的隔离级别，确保数据在多个用户之间的一致性。

2.方案管理与执行

Delta Lake利用Spark分布式处理能力处理所有元数据，通过提供指定模式和帮助实施模式的能力，避免不良数据进入数据湖。它通过提供合理的错误消息来防止不良数据进入系统，甚至在数据被集成到数据湖之前就进入系统，从而防止数据损坏。

3.数据版本控制和时间旅行

将对数据湖中的数据进行版本控制，并提供快照，以便您可以像该快照是系统当前状态一样查询它们。这有助于我们恢复到旧版本的数据湖中进行审计、回滚和类似的操作。

4.开放格式

Delta Lake 中的所有数据都以Apache Parquet格式存储，使得Delta Lake能够利用Parquet本地的高效压缩和编码方案。

5.统一的批量流式sink

近似实时分析。Delta Lake中的表既是一个批处理表，也是流源和sink，为Lambda架构提供了一个解决方案，但又向前迈进了一步，因为批处理和实时数据都下沉在同一个sink中。

与CarbonData类似，Delta不强调主键，因此更新/删除/合并都是基于spark的连接函数实现的。在数据写入方面，Delta和Spark是强绑定关系。与Spark的深度集成可能是最好的特性，事实上，它是唯一一个具有Spark SQL特定命令（例如：MERGE），它还引入了有用的DML，如直接在Spark中更新WHERE或DELETE WHERE。Delta Lake不支持真正的数据血缘关系（即跟踪数据何时以及如何在Delta Lake中复制数据的能力），但是有审计和版本控制（在元数据中存储旧模式）。

最后

Hudi在IUD性能和读取合并等功能方面具有竞争优势。例如，如果您想知道是否要与Flink流一起使用，那么它目前不是为这样的用例设计的。Hudi Delta Streamer支持流式数据采集。这里的“流式处理”实际上是一个连续的批处理周期。但从本质上讲，这仍不是一种存粹的流式的采集。该社区由Uber提供，并已开放其所有功能。

Delta的主要优势之一是它能够与Spark集成，特别是其流批一体化设计。Delta拥有良好的用户API和文档。该社区由Databricks提供，它拥有一个具有附加功能的商用版本。

CarbonData是市场上最早的产品，由于物化视图、二级索引等先进的索引，它具有一定的竞争优势，并被集成到各种流/AI引擎中，如Flink、TensorFlow，以及Spark、Presto和Hive。社区由华为提供，所有特性均已开源。

随着新版的发布，这三个都在不断填补他们缺失的能力，并可能在未来相互融合或竞争。当然，也可以把重点放在自己的情景上，构建自身优势的门槛。对这些解决方案进行性能比较有助于更好地了解它们的产品。因此，胜负仍是未知之数。

下表从多个维度总结了这三者。需要注意的是，本表所列能力仅突出2020年8月底的能力。

特性对比表

社区现状（截至2020年8月）