Hudi默认采用的HoodieBloomIndex索引，其依赖布隆过滤器来判断记录存在与否，当记录存在时，会读取实际文件进行二次判断，以便修正布隆过滤器带来的误差。

Hudi Bucket Index 在字节跳动的设计与实践]

1.1 索引的作用
在传统 Hive 数仓的场景下，如果需要对一个分区数据做更新，整个更新过程会涉及三个很重的操作。举一个更直观的例子。假设一个 Hive 分区存在 100,000 条记录，分布在 400 个文件中，我们需要更新其中的 100 条数据。这三个很重的操作分别是:

1. 从 400 个文件中读出 100,000 条数据

2. 与 100 条更新的数据做分布式关联，取最新值

3. 将更新后的 100,000 条数据写入临时目录，最后覆盖原先的数据

由此可以引出三个问题:

1. 读那么多文件是必要的吗？

2. 更新那么多文件是必要的吗？

3. 分布式关联是必要的吗？

假设在数据分布最糟糕的情况下，需要被更新的 100 条数据分布在 100 个文件中。那我们实际需要读和更新的文件是多少个？答案是 100 个，只占总量的 1/4。 因此，Hudi 为了消除不必要的读写，引入了索引的实现。在有了索引之后，更新的数据可以快速被定位到对应的 File Group，以下面的官方的示意图为例，

• 避免读取不需要的文件
• 避免更新不必要的文件
• 无需将更新数据与历史数据做分布式关联，只需要在 File Group 内做合并’