1、Hudi简介
Hudi是Hadoop Updates and Incrementals的缩写，用于管理HDFS上的大型分析数据集存储，主要目的是高效的减少入库延时。
Hudi是一个开源Spark三方库，支持在Hadoop上执行upserts/insert/delete操作。
Hudi数据集通过自定义的InputFormat与当前的Hadoop生态系统（Hive、parquet、spark）集成，使该框架对最终用户来说是无缝的。
2、Hudi逻辑视图
读优化视图：在列式存储上提供出色的查询性能，非常像parquet表
增量视图：在数据集上提供一个变更流并提供给下游的作业和etl任务
准实时表：使用列存储和行存储以提供对实时数据的查询
3、Hudi存储引擎
Hudi将数据集组织到basePath下的分区目录中，类似与传统的hive表。数据集被分成分区，分区时包含该分区的数据文件的目录。每个分区由其相对于basepath的partitionpath唯一标识。在每个分区中，记录被分布到多个数据文件中。每个数据文件都由唯一的field和生成该文件的commit标识。对于更新，多个数据文件可以共享同一个field，但对应于不同的commit。
每条记录都由一个记录键（record key）唯一标识，并映射到一个field。一旦记录的第一个版本被写入文件，记录键和field之间的映射关系就永久不变。简而言之，field标识一组文件，而这些文件包含所有记录的所有版本数据。
Hudi的存储引擎由三个不同的部分组成：
Metadata： Hudi以时间轴的形式将数据集上的各项操作对应的元数据维护起来，从而支持数据集的即时视图，这部分元数据存储于根目录下的元数据目录中。
Commits ：一个单独的 commit 包含对数据集之上一批数据的一次原子写入操作的相关信息。Commits 由单调递增的时间戳标识，表示写操作的开始；
Cleans：用于清除数据集中不再被查询所用到的旧版本文件的后台活动；
Compactions：协调 Hudi 中不同数据结构的后台活动，比如将基于行更新的文件转换成列式存储格式。
Index： Hudi维护了一个索引，以便在记录键已经存在的情况下快速地将传入的记录键映射到field，索引实现是可插拔的，以下是目前可用的选项：
BloomFilter：存储在每个数据文件的页脚中，默认就是用这个，因为不依赖任何外部系统。数据和索引始终保持一致。
HBase：可高效的查找一小批key，在索引标记期间，这个索引实现可能会快几秒
Data： Hudi以两种不同的存储格式存储所有摄入的数据。但实际使用的存储格式是可插拔的，但所选的存储格式需要以下特征：
扫描优化的列存储格式，默认是parquet
写优化的行格式，默认是avro
4、对比
Apache Hudi填补了在DFS上处理数据的巨大空白，并可以和这些技术很好地共存。然而， 通过将Hudi与一些相关系统进行对比，来了解Hudi如何适应当前的大数据生态系统，并知晓这些系统在设计中做的不同权衡仍将非常有用。
1、Kudu
Apache Kudu是一个与Hudi具有相似目标的存储系统，该系统通过对upserts支持来对PB级数据进行实时分析。 一个关键的区别是Kudu还试图充当OLTP工作负载的数据存储，而Hudi并不希望这样做。 因此，Kudu不支持增量拉取(截至2017年初)，而Hudi支持以便进行增量处理。
Kudu与分布式文件系统抽象和HDFS完全不同，它自己的一组存储服务器通过RAFT相互通信。 与之不同的是，Hudi旨在与底层Hadoop兼容的文件系统(HDFS，S3或Ceph)一起使用，并且没有自己的存储服务器群，而是依靠Apache Spark来完成繁重的工作。 因此，Hudi可以像其他Spark作业一样轻松扩展，而Kudu则需要硬件和运营支持，特别是HBase或Vertica等数据存储系统。 到目前为止，我们还没有做任何直接的基准测试来比较Kudu和Hudi(鉴于RTTable正在进行中)。 但是，如果我们要使用CERN， 我们预期Hudi在摄取parquet上有更卓越的性能。
2、Hive事务
Hive事务/ACID是另一项类似的工作，它试图实现在ORC文件格式之上的存储读取时合并。 可以理解，此功能与Hive以及LLAP之类的其他工作紧密相关。 Hive事务不提供Hudi提供的读取优化存储选项或增量拉取。 在实现选择方面，Hudi充分利用了类似Spark的处理框架的功能，而Hive事务特性则在用户或Hive Metastore启动的Hive任务/查询的下实现。 根据我们的生产经验，与其他方法相比，将Hudi作为库嵌入到现有的Spark管道中要容易得多，并且操作不会太繁琐。 Hudi还设计用于与Presto/Spark等非Hive引擎合作，并计划引入除parquet以外的文件格式。
3、HBase
尽管HBase最终是OLTP工作负载的键值存储层，但由于与Hadoop的相似性，用户通常倾向于将HBase与分析相关联。 鉴于HBase经过严格的写优化，它支持开箱即用的亚秒级更新，Hive-on-HBase允许用户查询该数据。 但是，就分析工作负载的实际性能而言，Parquet/ORC之类的混合列式存储格式可以轻松击败HBase，因为这些工作负载主要是读取繁重的工作。 Hudi弥补了更快的数据与分析存储格式之间的差距。从运营的角度来看，与管理分析使用的HBase region服务器集群相比，为用户提供可更快给出数据的库更具可扩展性。 最终，HBase不像Hudi这样重点支持提交时间、增量拉取之类的增量处理原语。
4、流式处理
一个普遍的问题：”Hudi与流处理系统有何关系？”，我们将在这里尝试回答。简而言之，Hudi可以与当今的批处理(写时复制存储)和流处理(读时合并存储)作业集成，以将计算结果存储在Hadoop中。 对于Spark应用程序，这可以通过将Hudi库与Spark/Spark流式DAG直接集成来实现。在非Spark处理系统(例如Flink、Hive)情况下，可以在相应的系统中进行处理，然后通过Kafka主题/DFS中间文件将其发送到Hudi表中。从概念上讲，数据处理 管道仅由三个部分组成：输入，处理，输出，用户最终针对输出运行查询以便使用管道的结果。Hudi可以充当将数据存储在DFS上的输入或输出。Hudi在给定流处理管道上的适用性最终归结为你的查询在Presto/SparkSQL/Hive的适用性。
更高级的用例围绕增量处理的概念展开， 甚至在处理引擎内部也使用Hudi来加速典型的批处理管道。例如：Hudi可用作DAG内的状态存储(类似Flink使用的[rocksDB(https://ci.apache.org/projects/flink/flink-docs-release-1.2/ops/state_backends.html#the-rocksdbstatebackend))。 这是路线图上的一个项目并将最终以Beam Runner的形式呈现。
参考文献：
https://www.iteblog.com/archives/9660.html
http://hudi.apache.org/cn/comparison.html
