本文主要是介绍【Hudi】索引，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Hudi默认采用的HoodieBloomIndex索引，其依赖布隆过滤器来判断记录存在与否，当记录存在时，会读取实际文件进行二次判断，以便修正布隆过滤器带来的误差。
Hudi Bucket Index 在字节跳动的设计与实践]
1.1 索引的作用
在传统 Hive 数仓的场景下，如果需要对一个分区数据做更新，整个更新过程会涉及三个很重的操作。举一个更直观的例子。假设一个 Hive 分区存在 100,000 条记录，分布在 400 个文件中，我们需要更新其中的 100 条数据。这三个很重的操作分别是:
-
从 400 个文件中读出 100,000 条数据
-
与 100 条更新的数据做分布式关联，取最新值
-
将更新后的 100,000 条数据写入临时目录，最后覆盖原先的数据
由此可以引出三个问题:
-
读那么多文件是必要的吗？
-
更新那么多文件是必要的吗？
-
分布式关联是必要的吗？
假设在数据分布最糟糕的情况下，需要被更新的 100 条数据分布在 100 个文件中。那我们实际需要读和更新的文件是多少个？答案是 100 个，只占总量的 1/4。 因此，Hudi 为了消除不必要的读写，引入了索引的实现。在有了索引之后，更新的数据可以快速被定位到对应的 File Group，以下面的官方的示意图为例，
- 避免读取不需要的文件
- 避免更新不必要的文件
- 无需将更新数据与历史数据做分布式关联，只需要在 File Group 内做合并’
这篇关于【Hudi】索引的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
