Hudi通過一種索引機制架专，將給定的Hoodie key（record key + partition path）一致地映射到file ID，從而提供了高效的upserts操作旬痹。一旦記錄的第一個版本被寫入文件中附井，record key和file group/file ID之間的映射關系就不會再改變。簡而言之两残，映射的file group包含了一組記錄的所有版本永毅。
對于Copy-On-Write表，這種設計可以通過避免對整個數(shù)據(jù)集進行join操作來實現(xiàn)快速的upsert和delete操作人弓。對于Merge-On-Read表卷雕，這種設計允許Hudi限制任何給定base files需要與之合并的記錄數(shù)量。具體而言票从，給定的base file只需要與屬于該base file的記錄的更新進行合并漫雕。相比之下，沒有索引組件的設計（例如：Apache Hive ACID）可能需要將所有base file與所有的更新/刪除記錄進行合并峰鄙。
Hudi Index Type
Hudi支持以下幾種索引類型：
- Bloom Filter index（default）：Bloom Filter是一種快速的數(shù)據(jù)結構浸间，用于判斷某個元素是否存在于集合中。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中存儲映射關系雪侥。
- 自定義實現(xiàn)：可以通過實現(xiàn)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
另一個值得了解的關鍵點是全局索引和非全局索引之間的區(qū)別速缨。Bloom和simple索引都有全局選項hoodie.index.type=GLOBAL_BLOOM 和 hoodie.index.type=GLOBAL_SIMPLE。HBase索引本質上是一個全局索引代乃。
- Global Index：全局索引在表的所有分區(qū)中強制確保鍵的唯一性旬牲，即確保表中存在一個且僅有一個與給定記錄鍵相對應的記錄。全局索引提供了更強的保證搁吓，但是更新/刪除的成本隨著表的大小增長（O(表的大小)）引谜，這對于較小的表可能仍然可以接受。
- Non-Global Index：非全局索引的實現(xiàn)僅在特定分區(qū)內強制執(zhí)行此約束擎浴≡毖剩可以想象，非全局索引依賴于寫入者在更新/刪除期間為給定的記錄鍵提供相同一致的分區(qū)路徑贮预，但由于索引查找操作變?yōu)镺(更新/刪除的記錄數(shù))贝室，因此可以提供更好的性能，并且與寫入量的增加成比例仿吞。
由于數(shù)據(jù)以不同的數(shù)據(jù)量滑频、速度和具有不同的訪問模式進入，不同的索引可以用于不同的工作負載類型唤冈。讓我們逐步了解一些典型的工作負載類型峡迷，并看看如何為這些用例充分利用正確的Hudi索引。這基于我們的經驗你虹，您應該認真決定是否相同的策略最適合您的工作負載绘搞。
索引選擇策略
場景一：事實表的延遲到達更新
許多公司將大量的事務數(shù)據(jù)存儲在NoSQL數(shù)據(jù)存儲中。例如傅物，在拼車服務中的行程表夯辖，股票的買賣，電子商務網站中的訂單等董饰。這些表通常是不斷增長的蒿褂，最新數(shù)據(jù)上有隨機更新，而長尾更新則涉及較舊的數(shù)據(jù)卒暂，這可能是由于交易在較晚的日期結算或數(shù)據(jù)更正所致啄栓。換句話說，大多數(shù)更新進入最新的分區(qū)也祠，而較舊的分區(qū)只有少量更新昙楚。
對于這種工作負載，BLOOM索引表現(xiàn)良好齿坷，因為索引查找將根據(jù)合適大小的布隆過濾器剪枝掉很多數(shù)據(jù)文件桂肌。此外，如果可以構建鍵以具有一定的排序永淌，那么通過范圍剪枝崎场，需要比較的文件數(shù)量進一步減少。Hudi使用所有文件鍵范圍構建了一個區(qū)間樹遂蛀，并有效地過濾掉在更新/刪除的記錄中不匹配任何鍵范圍的文件谭跨。
為了以最小的布隆過濾器讀取次數(shù)和在執(zhí)行器之間均勻分布工作的方式，有效地將傳入的記錄鍵與布隆過濾器進行比較李滴，Hudi利用輸入記錄的緩存螃宙，并使用自定義分區(qū)器來消除數(shù)據(jù)傾斜。有時所坯，如果布隆過濾器的誤報率很高谆扎，可能會增加執(zhí)行查找所需的shuffle數(shù)據(jù)量。Hudi支持動態(tài)布隆過濾器（使用hoodie.bloom.index.filter.type=DYNAMIC_V0啟用）芹助，它根據(jù)給定文件中存儲的記錄數(shù)量來調整其大小堂湖，以提供配置的誤報率。
場景二：事件表中的去重
事件流正在無處不在状土。來自Apache Kafka或類似消息總線的事件通常是事實表的10-100倍大小无蜂，并且通常將"時間"（事件到達時間/處理時間）視為重要因素。例如蒙谓，物聯(lián)網事件流斥季、點擊流數(shù)據(jù)、廣告展示等累驮。插入和更新僅跨越最后幾個分區(qū)酣倾，因為這些數(shù)據(jù)大多是追加方式。由于重復事件可能在端到端的流程中的任何位置引入谤专，所以在存儲到數(shù)據(jù)湖之前進行去重是常見需求灶挟。
一般來說，這是一個非常具有挑戰(zhàn)性且需要低成本解決的問題毒租。盡管我們可以使用鍵值存儲來執(zhí)行此去重操作稚铣，并結合HBASE索引，但索引存儲成本將隨事件數(shù)量線性增長墅垮，因此可能變得過于昂貴惕医。事實上，帶有范圍剪枝的BLOOM索引是在這種情況下的最佳解決方案算色√牛可以利用時間通常是一個重要因素的事實，并構建一個鍵灾梦，例如event_ts + event_id峡钓，以便插入的記錄具有單調遞增的鍵妓笙。這樣可以通過在最新的表分區(qū)中剪枝大量的文件，從而獲得很大的性能提升能岩。
場景三：對于維度表的隨機更新/刪除
這些類型的表通常包含高維數(shù)據(jù)寞宫，并包含參考數(shù)據(jù)，例如用戶配置文件拉鹃、商家信息等辈赋。這些是高保真度的表，更新通常很小膏燕，但分布在許多分區(qū)和數(shù)據(jù)文件中钥屈，涵蓋了從舊到新的整個數(shù)據(jù)集。通常坝辫，這些表也是未分區(qū)的篷就，因為沒有一個很好的方法來對這些表進行分區(qū)。
如前所討論近忙，如果無法通過比較范圍/過濾器剪枝掉很多文件腻脏，那么BLOOM索引可能不會帶來好處。在這種隨機寫入的工作負載中银锻，更新操作會涉及到表中的大多數(shù)文件永品，因此根據(jù)某些傳入的更新，布隆過濾器通常會對所有文件表示為真陽性击纬。因此鼎姐，我們最終需要比較范圍/過濾器，并將傳入的更新與所有文件進行對比更振。在這種情況下炕桨，SIMPLE索引會更適合，因為它不會基于先前的剪枝操作，而是直接與每個數(shù)據(jù)文件中的record key字段進行連接。如果操作開銷可接受择膝，HBASE索引也可以使用修肠，它可以為這些表提供更好的查找時間敛滋。
注意
在使用全局索引時，用戶還應考慮設置hoodie.bloom.index.update.partition.path=true或hoodie.simple.index.update.partition.path=true，以處理分區(qū)路徑值可能由于更新而發(fā)生變化的情況，例如按家庭城市分區(qū)的用戶表捷兰；用戶搬到了另一個城市。這些表也是適合使用Merge-On-Read表類型的優(yōu)秀候選表负敏。
