hudi概念

近实时摄取

对于 RDBMS 关系型的摄入，Hudi提供了更快的 Upset 操作。例如，你可以通过 MySql binlog 的形式或者 Sqoop 导入到 hdfs上的对应的 Hudi表中，这样操作比 Sqoop 批量合并 job（Sqoop merge）和复杂合并工作流更加快速高效。

对于NoSql的数据库，比如Cassandra，Voldemort，Hbase，这种可以存储数十亿行的数据库。采用完全批量加载是根本不可行的，并且如果摄取数据要跟上通常较高的更新量，则需要更有效的方法。

即使对于像 Kafka 这样不可变数据库源，Hudi也会在 HDFS上强制执行最小文件大小，从而通过整体解决 Hadoop 领域中小文件过多问题，改善 NameNode 的运行状况。

对于事件流尤为重要，因为事件流通常较大（例如∶ 点击流），并且如果管理不善，可能会严重损害 Hadoop 集群。

在所有来源中，Hudi 都增加了急需的功能，即通过提交概念将新数据原子推送给消费者，避免摄入数据失败。

近实时分析

Hadoop上交互式的 SQL解决方案有 Presto 和 Spark sql，将数据的更新时间缩短至几分钟。

Hudi可以提供多种高效的替代方案，并可以对存储在 DFS 中的多个大小表进行实时分析，此外 Hudi 没有外部依赖，例如专用实时分析的专用HBase 集群，因此可以在不增加操作开销的情况下，进行更快更新鲜的分析。

增量处理管道

Hudi 通过提供一种以记录粒度（而不是文件夹/分区）消耗上游 Hudi表 HU 的新数据（包括最新数据），应用处理逻辑并有效地更新协调最新数据的方式再次进行救援。下游护桌HD。在这里，HU 和 HD可以以更频繁的时间表（例如 15 分钟）连续进行调度，并在HD 上提供30分钟的终端延迟。

DFS的数据分散

Hudi可以像Kafka 一样，用于数据分散，将每个管道的数据输出到Hudi表中，然后将其递增尾部以获取新数据并写入服务存储中。

和其他组件对比

和kudu对比

Kudu与分布式文件系统抽象和HDFS完全不同，它自己的一组存储服务器通过RAFT相互通信。另一方面，Hudi旨在与底层Hadoop兼容文件系统（HDFS，S3或 Ceph）一起使用，并且没有自己的存储服务器，而是依靠 Apache Spark来完成繁重的工作。因此，就像其他 Spark 作业一样，Hudi可以轻松扩展，而 Kudu 则需要硬件和操作支持，这对于HBase或 Vertica 这样的数据存储来说是典型的。

和Hbase对比

HBase 是 OLTP 工作负载的关键值存储，但鉴于与 Hadoop 的相似性，用户通常倾向于将 HBase 与分析相关联。鉴于HBase 经过严格的写优化，它支持开箱即用的亚秒级更新， Hive-on-HBase 允许用户查询该数据。 但是，就分析工作负载的实际性能而言，混合列式存储格式（例如 Parquet/ ORC）可以轻松击败 HBase，因为这些工作负载主要是读取繁重的工作。 Hudi弥补了更快的数据与具有分析性存储格式之间的差距。 从操作的角度来看，与仅管理分析用的大型 HBase 区域服务器场相比，为用户提供可提供更快数据的库更具可扩展性。 最终，HBase 不像 Hudi这样的一流公民来支持诸如提交时间，增量拉动之类的增量处理原语。

和streaming对比

Hudi 可以与当今的批处理（写时复制表）和流式（读时合并表）作业集成，以将计算
结果存储在 Hadoop中。对于Spark应用程序，这可以通过将 Hudi库与 Spark/Spark流式DAG直接集成来实现。在非 Spark处理系统（例如 Flink，Hive）的情况下，可以在各个系统中进行处理，然后通过 Kafka 主题/DFS中间文件将其发送到 Hudi 表中。从概念上讲，数据处理管道仅由三个部分组成 源，处理，接收器，用户最终针对接收器运行查询以使用管道的结果。 Hudi 可以充当将数据存储在 DFS上的源或接收器。 Hudi 在给定流处理管道上的适用性最终归结为 Presto / SparkSQL/ Hive 对您的查询的适用性。

基础知识

Timeline

Hudi 的核心是维护不同时间对表执行的所有操作的事件表，这有助于提供表的即时视图，同时还有效地支持按到达顺序进行数据检索。

Hudi 包含以下组件∶

（1）Instant action∶在表上的操作类型

（2）Instant time∶ 操作开始的一个时间戳，该时间戳会按照开始时间顺序单调递增

（3）state∶即时状态

Hudi 保证在时间轴上执行的操作都是原先性的，所有执行的操作包括∶

（1）commits∶原子的写入一张表的操作

（2）cleans∶后台消除了表中的旧版本数据，即表中不在需要的数据

（3）delta_commit增量提交，将一批数据原子写入到 MergeOnRead表中，并且只记录到增量日志中

（4）compaction∶后台协调 Hudi 中的差异数据

（5）rollback∶回滚，删除在写入过程中的数据

（6）savepoint∶将某些文件标记"已保存"，以便清理数据时不会删除它们，一般用于表的还原，可以将数据还原到某个时间点

任何操作都可以处于以下状态

（1）Requested∶表示已安排操作行为，但是尚未开始

（2）Inflight∶表示正在执行当前操作

（3）Completed∶表示已完成操作

File management

Hudi将表组织成 DFS上基本路径下的目录结构。表分位几个分区，与hive类似，每个分区均有唯一标示。

在每个分区内，有多个数据组，每个数据组包含几个文件片，其中文件片包含基本文件和日志文件。Hudi采用 MVCC设计，其中压缩操作将日志文件和基本数据文件合并成新的文件片，而清楚操作则将未使用的文件片去除。

索引

Hudi通过使用索引机制，生成 hoodie密钥映射对应文件ID，从而提供高效 upsert 操作。

表类型

（1）Copy on Write∶仅使用列式存储，例如 parquet。仅更新版本号，通过写入过程中执行同步合并来重写文件

（2）Merge on Read∶基于列式存储（parquet）和行式存储（arvo）结合的文件更始进行存储。更新记录到增量文件，压缩同步和异步生成新版本的文件

查询类型

（1）快照查询（Snapshot Queries）∶查询操作将查询最新快照的表数据。如果是 Merge on Read类型的表，它将动态合并最新文件版本的基本数据和增量数据用于显示查询。如果是 Copy On Write 类型的表，它直接查询 parquet 表，同时提供upsert/delete 操作.

（2）增量查询（Incremental Queries）∶查询只能看到写入表的新数据。这有效的提供了 change streams 来启用增量数据管道。

（3）优化读查询（Read Optimized Queries）∶ 查询将查看给定提交/压缩操作表的最新快
照