Hudi 索引的选择策略

场景一：事实表更新

许多公司把大量的交易型数据存储在 NoSQL 的表中，例如，股票交易，电商订单数据等。这些表近期的数据（热数据）通常都会有大量的更新，而旧的数据（冷数据）只有很少量的更新。换句话说，大多数的更新都会落到最新的分区，而只有少量的数据会落到旧的分区。

这种场景，BLOOM 索引可以很好的适配，因为采用它可以裁剪掉大量的分区。存储数据时如果能够对 key 进行排序，通过区间裁剪，查找时也可以较少数据文件的扫描。Hudi 通过key的区间构造区间树，使得在update/delete 的数据时能更高效的过滤掉不匹配的文件。

场景2: 事件数据去重

事件流数据随处可见，来自 Kafka 或者类似消息系统的数据通常都比事实表要大10-100倍，而“时间”对于事件数据来说是一等公民，如，IoT 事件流，点击流，广告流等。由于这些数据大多是追加型的，插入和更新只会落入到最新的几个分区。在端到端的管道中，重复的事件数据是常见的，在存储到数据湖前进行去重是一个常见的需求。

想要以非常低的代价解决这类问题是非常具有挑战性的。例如，我们可以采用 HBase 索引来去重，但是随着数据量的的增加，索引的存储成本也会线性的增加，甚至达到令人望而却步的昂贵开销。相反，带有区间裁剪的 BLOOM 索引 是更优的方案。因为“时间”是事件数据的一等公民，采用 event_timestamp + event_id 来作为 key, 随着数据的插入，得到的是一连串单调递增的 key 。对于一个event_id，即使在最新的分区也能过滤掉大量的文件，而只取出 event_timestamp 是最大的数据。

场景3: 维度表的随机 update/delete

这种类型的表通过保存高维度的数据，如用户资料表、商户信息表。这些表的更新通常都不算很多的，但是会分布在各种不同的新旧分区上。甚至有可能还没有分区。

再这种情况，BLOOM 索引通过比较区间来裁剪数据并不能减少文件的扫描，因此不太合适。在这种随机写的场景下，更新操作会遍布所有的文件。这种情况，SIMPLE 索引会更加适用，在运营开销可以接受的情况下，也可以考虑 HBase 索引，以提高更快的查找效率。