Hudi通過一種索引機制，將給定的Hoodie key（record key + partition path）一致地映射到file ID，從而提供了高效的upserts操作。一旦記錄的第一個版本被寫入文件中，record key和file group/file ID之間的映射關系就不會再改變。簡而言之，映射的file group包含了一組記錄的所有版本。
對于Copy-On-Write表，這種設計可以通過避免對整個數據集進行join操作來實現快速的upsert和delete操作。對于Merge-On-Read表，這種設計允許Hudi限制任何給定base files需要與之合并的記錄數量。具體而言，給定的base file只需要與屬于該base file的記錄的更新進行合并。相比之下，沒有索引組件的設計（例如：Apache Hive ACID）可能需要將所有base file與所有的更新/刪除記錄進行合并。
Hudi Index Type
Hudi支持以下幾種索引類型：
- Bloom Filter index（default）：Bloom Filter是一種快速的數據結構，用于判斷某個元素是否存在于集合中。Hudi使用使用由record key構建的布隆過濾器，還可以選擇使用record key range修剪候選文件。
- Simple Index：Simple index是基于record key構建的索引，用于快速定位特定記錄。它將record key與對應的file ID進行映射，從而可以快速定位到包含特定記錄的文件。具體到code層面，Hudi對incoming的update/delete記錄，與存儲中提取的record key -> file location的映射，進行join操作，從而找到該記錄應該位于的文件。
- HBase Index：在外部的Hbase table中存儲映射關系。
- 自定義實現：可以通過實現HoodieIndex interface，定義自己的索引方式。
相關配置：
1.hoodie.index.type
Type of index to use. Default is SIMPLE on Spark engine, and INMEMORY on Flink and Java engines. Possible options are [BLOOM | GLOBAL_BLOOM |SIMPLE | GLOBAL_SIMPLE | INMEMORY | HBASE | BUCKET]. Bloom filters removes the dependency on a external system and is stored in the footer of the Parquet Data Files
2.hoodie.index.class
Full path of user-defined index class and must be a subclass of HoodieIndex class. It will take precedence over the hoodie.index.type configuration if specified
另一個值得了解的關鍵點是全局索引和非全局索引之間的區別。Bloom和simple索引都有全局選項hoodie.index.type=GLOBAL_BLOOM 和 hoodie.index.type=GLOBAL_SIMPLE。HBase索引本質上是一個全局索引。
- Global Index：全局索引在表的所有分區中強制確保鍵的唯一性，即確保表中存在一個且僅有一個與給定記錄鍵相對應的記錄。全局索引提供了更強的保證，但是更新/刪除的成本隨著表的大小增長（O(表的大小)），這對于較小的表可能仍然可以接受。
- Non-Global Index：非全局索引的實現僅在特定分區內強制執行此約束。可以想象，非全局索引依賴于寫入者在更新/刪除期間為給定的記錄鍵提供相同一致的分區路徑，但由于索引查找操作變為O(更新/刪除的記錄數)，因此可以提供更好的性能，并且與寫入量的增加成比例。
由于數據以不同的數據量、速度和具有不同的訪問模式進入，不同的索引可以用于不同的工作負載類型。讓我們逐步了解一些典型的工作負載類型，并看看如何為這些用例充分利用正確的Hudi索引。這基于我們的經驗，您應該認真決定是否相同的策略最適合您的工作負載。
索引選擇策略
場景一：事實表的延遲到達更新
許多公司將大量的事務數據存儲在NoSQL數據存儲中。例如，在拼車服務中的行程表，股票的買賣，電子商務網站中的訂單等。這些表通常是不斷增長的，最新數據上有隨機更新，而長尾更新則涉及較舊的數據，這可能是由于交易在較晚的日期結算或數據更正所致。換句話說，大多數更新進入最新的分區，而較舊的分區只有少量更新。
對于這種工作負載，BLOOM索引表現良好，因為索引查找將根據合適大小的布隆過濾器剪枝掉很多數據文件。此外，如果可以構建鍵以具有一定的排序，那么通過范圍剪枝，需要比較的文件數量進一步減少。Hudi使用所有文件鍵范圍構建了一個區間樹，并有效地過濾掉在更新/刪除的記錄中不匹配任何鍵范圍的文件。
為了以最小的布隆過濾器讀取次數和在執行器之間均勻分布工作的方式，有效地將傳入的記錄鍵與布隆過濾器進行比較，Hudi利用輸入記錄的緩存，并使用自定義分區器來消除數據傾斜。有時，如果布隆過濾器的誤報率很高，可能會增加執行查找所需的shuffle數據量。Hudi支持動態布隆過濾器（使用hoodie.bloom.index.filter.type=DYNAMIC_V0啟用），它根據給定文件中存儲的記錄數量來調整其大小，以提供配置的誤報率。
場景二：事件表中的去重
事件流正在無處不在。來自Apache Kafka或類似消息總線的事件通常是事實表的10-100倍大小，并且通常將"時間"（事件到達時間/處理時間）視為重要因素。例如，物聯網事件流、點擊流數據、廣告展示等。插入和更新僅跨越最后幾個分區，因為這些數據大多是追加方式。由于重復事件可能在端到端的流程中的任何位置引入，所以在存儲到數據湖之前進行去重是常見需求。
一般來說，這是一個非常具有挑戰性且需要低成本解決的問題。盡管我們可以使用鍵值存儲來執行此去重操作，并結合HBASE索引，但索引存儲成本將隨事件數量線性增長，因此可能變得過于昂貴。事實上，帶有范圍剪枝的BLOOM索引是在這種情況下的最佳解決方案。可以利用時間通常是一個重要因素的事實，并構建一個鍵，例如event_ts + event_id，以便插入的記錄具有單調遞增的鍵。這樣可以通過在最新的表分區中剪枝大量的文件，從而獲得很大的性能提升。
場景三：對于維度表的隨機更新/刪除
這些類型的表通常包含高維數據，并包含參考數據，例如用戶配置文件、商家信息等。這些是高保真度的表，更新通常很小，但分布在許多分區和數據文件中，涵蓋了從舊到新的整個數據集。通常，這些表也是未分區的，因為沒有一個很好的方法來對這些表進行分區。
如前所討論，如果無法通過比較范圍/過濾器剪枝掉很多文件，那么BLOOM索引可能不會帶來好處。在這種隨機寫入的工作負載中，更新操作會涉及到表中的大多數文件，因此根據某些傳入的更新，布隆過濾器通常會對所有文件表示為真陽性。因此，我們最終需要比較范圍/過濾器，并將傳入的更新與所有文件進行對比。在這種情況下，SIMPLE索引會更適合，因為它不會基于先前的剪枝操作，而是直接與每個數據文件中的record key字段進行連接。如果操作開銷可接受，HBASE索引也可以使用，它可以為這些表提供更好的查找時間。
注意
在使用全局索引時，用戶還應考慮設置hoodie.bloom.index.update.partition.path=true或hoodie.simple.index.update.partition.path=true，以處理分區路徑值可能由于更新而發生變化的情況，例如按家庭城市分區的用戶表；用戶搬到了另一個城市。這些表也是適合使用Merge-On-Read表類型的優秀候選表。
