图灵汇官网

Apache Hudi在处理数据方面填补了在分布式文件系统（DFS）上的空白，并能很好地与多种大数据技术协同工作。不过，了解Hudi如何融入当前的大数据生态系统，并知晓其与相关系统的不同之处仍然很有意义。

Kudu

Apache Kudu是一个类似于Hudi的存储系统，旨在支持PB级数据的实时分析，尤其是通过upsert操作。关键的区别在于Kudu不仅支持实时分析，还致力于成为在线交易处理（OLTP）工作负载的数据存储，而Hudi并不具备这种功能。因此，Kudu不支持增量拉取，而Hudi则支持增量处理。

Kudu与分布式文件系统如HDFS不同，它依赖于一组存储服务器，这些服务器通过RAFT协议相互通信。相比之下，Hudi旨在与Hadoop兼容的文件系统（如HDFS、S3或Ceph）一起使用，而不依赖自己的存储服务器群。相反，Hudi利用Apache Spark来执行繁重的工作，这使得Hudi可以像其他Spark作业一样轻松扩展。Kudu则需要专门的硬件和运维支持，尤其是在与HBase或Vertica等数据存储系统配合使用时。目前，我们尚未进行过直接的基准测试来比较Kudu和Hudi。然而，如果我们考虑在CERN环境中使用，预计Hudi在处理Parquet文件方面会有更好的性能表现。

Hive事务

Hive事务/ACID功能是另一个类似的工作，它旨在通过读取时合并的方式实现存储层。这项功能与Hive及LLAP等其他功能紧密相关。Hive事务不提供Hudi所支持的读取优化存储选项或增量拉取功能。在实现方面，Hudi充分利用了类似Spark的处理框架的优势，而Hive事务特性则主要在用户或Hive Metastore启动的Hive任务/查询中实现。根据我们的实际经验，将Hudi作为库嵌入到现有的Spark管道中比其他方法更容易实现，且操作相对简单。Hudi还设计用于与Presto/Spark等非Hive引擎合作，并计划引入除Parquet之外的文件格式。

HBase

尽管HBase本质上是一个键值存储层，适用于在线交易处理（OLTP）工作负载，但由于其与Hadoop的相似性，用户往往将其与数据分析关联起来。HBase经过严格的写优化，支持亚秒级的更新，这使得Hive-on-HBase成为可能，用户可以查询这些数据。然而，在分析工作负载的实际性能方面，诸如Parquet/ORC等混合列式存储格式通常优于HBase，因为这些工作负载主要是读取密集型的。Hudi通过缩短数据与分析存储格式之间的差距，提高了效率。从运维角度来看，为用户提供一个可以更快获取数据的库比管理分析应用的HBase Region服务器集群更具可扩展性。最终，HBase不像Hudi那样专注于支持提交时间、增量拉取等增量处理原语。

流式处理

一个常见的问题是：“Hudi与流处理系统有何关联？”简单来说，Hudi可以与当前的批处理（写时复制存储）和流处理（读时合并存储）作业集成，以便将计算结果存储在Hadoop中。对于Spark应用程序，可以通过直接将Hudi库集成到Spark/Spark流式DAG中来实现这一点。在非Spark处理系统（如Flink、Hive）的情况下，可以在相应的系统中进行处理，然后通过Kafka主题/DFS中间文件将数据发送到Hudi表中。从概念上讲，数据处理管道仅由三个部分组成：输入、处理、输出。用户最终针对输入运行查询以使用管道的结果。Hudi可以作为DFS上的输入或输出组件。Hudi在流处理管道中的适用性最终取决于用户查询在Presto/SparkSQL/Hive中的适用性。

更高级的用例围绕增量处理的概念展开，即使在处理引擎外部也利用Hudi来加速典型的批处理管道。例如，Hudi可以作为类似Flink应用中RocksDB的形状存储：

https://ci.apache.org/projects/flink/flink-docs-release-1.2/ops/state_backends.html#the-rocksdbstatebackend

这是一个路线图上的项目，并最终将以Beam Runner的形式呈现。

Iceberg & Delta

关于与Iceberg和Delta的对比，可以参考如下对比图（2019年9月之前由Qubole技术博客提供）： [中心对齐]

Hudi社区并不希望通过官方文档来比较与同为数据湖开源框架的Iceberg和Delta的区别，以免让开发者感到Hudi立场不中立。为了保持中立的立场，社区更愿意让开发者自行比较并选择适合自己的框架。