apache hudi 通过使用索引来提高更新和删除操作的效率。对于 copy-on-write 表，索引避免了需要扫描整个数据集来确定需要重写的文件，从而实现了快速的 upsert 和 delete 操作。对于 merge-on-read 表，这种设计允许 hudi 限制任何给定基本文件需要合并的记录数量。具体来说，基本文件只需要合并属于该文件的记录更新。与没有索引组件的设计（如 apache hive acid）相比，后者可能需要根据所有传入的更新/删除记录来合并所有基本文件。
从高层次来看，索引将 record key 和可选的分区路径映射到文件组 ID，并存储这些映射。在写入操作时，我们使用这个映射来路由即将到来的更新/删除操作到附加到基础文件（MOR）的日志文件，或者需要被合并的 COW 表的最新基础文件。该索引还允许 Hudi 根据记录键强制执行唯一约束。
展示了更新（黄色块）与基本文件（白色块）的合并成本比较。
Hudi 支持多种索引技术，并且不断改进和添加新的工具。以下是从我们的经验中解释不同类型工作负载的建议，以及每种工作负载应使用哪种索引类型。我们还将讨论现有限制、即将进行的工作以及优化和折衷的方式。
Hudi 中的索引类型包括 Bloom Index（默认）、Simple Index 和 HBase Index。Bloom Index 使用基于记录键构建的布隆过滤器，还可以使用记录键范围来修剪候选文件。Simple Index 通过从存储表中提取的键对传入的更新/删除记录执行精简连接。HBase Index 将索引映射存储在外部 HBase 表中。用户可以使用 hoodie.index.type 配置选项选择这些选项之一。此外，还可以通过 hoodie.index.class 并提供 SparkHoodieIndex 的子类（适用于 Apache Spark 编写者）来使用自定义索引实现。
另一个关键方面是全局索引和非全局索引之间的区别。Bloom 和 Simple 索引都有全局选项，分别是 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 倍，并且通常将“时间”（事件的到达时间/处理时间）视为一等公民。例如，物联网事件流、点击流数据、广告印象等。插入和更新仅跨越最后几个分区，因为这些大多只是附加数据。鉴于可以在端到端管道中的任何位置引入重复事件，在存储到数据湖之前进行重复数据删除是一个常见要求。
Sudowrite
对用户最友好的AI写作工具
169 查看详情 
展示了事件更新的传播方式。
一般来说，这是一个以较低成本解决的非常具有挑战性的问题。尽管我们甚至可以使用像 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）的额外开销。
总结
如果没有 Hudi 中的索引功能，就不可能在非常大的范围内进行更新插入/删除。希望这篇文章为您提供了有关当今索引机制以及不同权衡如何发挥作用的足够好的背景信息。
这方面正在进行一些有趣的工作：
基于 Apache Flink 的写入使用 RocksDB 状态存储支持的索引机制，解锁数据湖上真正的流更新。一个全新的 MetadataIndex，它重新构想了今天在 Hudi 元数据表之上的布隆索引。记录级索引实现，作为二级索引使用另一个 Hudi 表。
展望未来，这仍将是该项目的积极投资领域。
本文为从大数据到人工智能博主「xiaozhch5」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://www.php.cn/link/a66b2ecb853ed5851a778f3e48ad59d5
以上就是hudi的索引机制以及使用场景的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/756996.html
微信扫一扫 
支付宝扫一扫 
