hudi的索引机制以及使用场景

Apache Hudi 使用索引来定位更新/删除所属的文件组。对于 Copy-On-Write 表，通过避免需要连接整个数据集来确定要重写哪些文件，这可以实现快速的 upsert/delete 操作。对于 Merge-On-Read 表，这种设计允许 Hudi 限制任何给定基本文件需要合并的记录数量。具体来说，给定的基本文件只需要针对属于该基本文件一部分的记录的更新进行合并。相比之下，没有索引组件的设计（例如：Apache Hive ACID）可能最终必须根据所有传入的更新/删除记录合并所有基本文件。

从高层次来说，索引将record key + 可选分区路径映射为一个文件组ID并进行存储。而在写操作的时候，我们使用这个映射来路由即将到来的update/delete操作到附加到基础文件（MOR）的日志文件，或者需要被合并的COW表的最新基础文件。该索引还使 Hudi 能够根据记录键强制执行唯一约束。

更新(黄色块)与基本文件(白色块)的合并成本比较

Hudi已经支持几种不同的索引技术，并且还在不断地改进/添加更多的工具，下文试图从我们的经验中解释不同类别的工作负载，并建议每种工作负载使用何种索引类型。我们还将穿插讲述现有的限制，即将进行的工作和优化/折衷的方式。

Hudi中的索引类型

Bloom Index (default) 使用根据记录键构建的bloom过滤器，也可以使用记录键范围修剪候选文件。（更多布隆过滤器的知识可参考文末列出的文章）
Simple Index根据从存储表中提取的键对传入的更新/删除记录执行精简连接
HBase Index 将索引映射存储在外部hbase表中

用户可以使用 hoodie.index.type 配置选项选择这些选项之一。此外，还可以使用 hoodie.index.class 并提供 SparkHoodieIndex 的子类（适用于 Apache Spark 编写者）来使用自定义索引实现

另一个值得理解的关键方面是全局索引和非全局索引之间的区别。布隆和简单索引都有全局选项 – hoodie.index.type=GLOBAL_BLOOM 和 hoodie.index.type=GLOBAL_SIMPLE。 HBase 索引本质上是一个全局索引。

全局索引：全局索引强制跨表的所有分区的键的唯一性，即保证表中对于给定的记录键恰好存在一条记录。全局索引提供了更强的保证，但更新/删除成本随着表 O（表大小）的大小而增长，这对于较小的表可能仍然是可以接受的。
非全局索引：另一方面，默认索引实现仅在特定分区内强制执行此约束。可以想象，非全局索引依赖于编写器在更新/删除期间为给定的记录键提供相同的一致分区路径，但可以提供更好的性能，因为索引查找操作变为 O（更新/删除的记录数）并且可以很好地扩展写入量。

由于数据以不同的量、速度和不同的访问模式进入，因此不同的索引可用于不同的工作负载。接下来，让我们浏览一些典型的工作负载，看看如何为此类用例利用正确的 Hudi 索引。

工作负载：对事实表的迟到更新场景

许多公司在 NoSQL 数据存储中存储大量事务数据。例如，拼车行程表、股票买卖、电子商务网站中的订单。这些表通常会随着最近数据的随机更新而增长，而长尾更新会转移到较旧的数据，这可能是由于交易在较晚的日期/数据更正后结算。换句话说，大多数更新进入最新分区，很少更新进入旧分区。

图中描述了事实表的更新方式

对于此类工作负载，BLOOM 索引表现良好，因为索引查找将基于大小合适的布隆过滤器修剪大量数据文件。此外，如果可以构造键以使其具有特定顺序，则通过范围修剪进一步减少要比较的文件数量。 Hudi 构建一个包含所有文件键范围的区间树，并有效过滤掉更新/删除记录中与任何键范围不匹配的文件。

为了有效地将传入的记录键与布隆过滤器进行比较，即以最少的布隆过滤器读取次数和跨执行器的工作均匀分布，Hudi 利用输入记录的缓存并采用自定义分区器，该分区器可以使用统计数据消除数据偏差。有时，如果布隆过滤器误报率很高，则可能会增加混洗以执行查找的数据量。 Hudi 支持动态布隆过滤器（使用 hoodie.bloom.index.filter.type=DYNAMIC_V0 启用），它根据存储在给定文件中的记录数调整其大小以提供配置的误报率。

在不久的将来，我们计划引入速度更快的 BLOOM 索引版本，该索引在内部 Hudi 元数据表中跟踪布隆过滤器/范围，为快速点查找建立索引。这将避免当前从基本文件本身读取布隆过滤器/范围以执行查找的任何限制。（一般设计见RFC-15）

工作负载:事件表中的重复数据删除场景

事件流无处不在。来自 Apache Kafka 或类似消息总线的事件通常是事实表大小的 10-100 倍，并且通常将“时间”（事件的到达时间/处理时间）视为一等公民。例如，物联网事件流、点击流数据、广告印象等。插入和更新仅跨越最后几个分区，因为这些大多只是附加数据。鉴于可以在端到端管道中的任何位置引入重复事件，在存储到数据湖之前进行重复数据删除是一个常见要求。

事件更新的传播方式

一般来说，这是一个以较低成本解决的非常具有挑战性的问题。尽管我们甚至可以使用像HBASE 索引这样的键值存储来执行这种重复数据删除，但索引存储成本会随事件数量线性增长，因此可能会非常昂贵。事实上，带范围修剪的 BLOOM 索引是这里的最佳解决方案。可以利用时间通常是一等公民这一事实，并构造一个键，例如 event_ts + event_id，这样插入的记录具有单调递增的键。即使在最新的表分区中，也可以通过修剪大量文件来产生巨大的回报。

工作负载：对维度表的随机更新/删除场景

这些类型的表格通常包含高维数据并保存参考数据，例如用户资料、商家信息。这些是高保真表，其中更新通常很小，但也分布在许多分区和数据文件中，从旧到新的数据集。很多时候，这些表也是未分区的，因为也没有很好的方法来对这些表进行分区。

维度表的更新范围

如前所述，如果无法通过比较范围/过滤器来修剪大量文件，则 BLOOM 索引可能不会产生好处。在这样的随机写入工作负载中，更新最终会触及表中的大多数文件，因此布隆过滤器通常会根据某些传入更新指示所有文件的真实阳性。因此，我们最终会比较范围/过滤器，只是为了最终检查所有文件的传入更新。 SIMPLE Index 将更适合，因为它不进行任何基于前期的修剪，而是直接与每个数据文件中的感兴趣字段连接。如果操作开销可以接受并且将为这些表提供更好的查找时间，则可以使用 HBASE 索引。

使用全局索引时，用户还应考虑设置 hoodie.bloom.index.update.partition.path=true 或 hoodie.simple.index.update.partition.path=true 来处理由于分区路径值可能发生变化的情况更新例如按家乡城市分区的用户表；用户搬迁到不同的城市。这些表也是 Merge-On-Read 表类型的绝佳候选者。

展望未来，我们计划在 Hudi 内部构建记录级索引，这将改善索引查找时间，并避免维护外部系统（如 hbase）的额外开销。