與許多其他事務(wù)數(shù)據(jù)系統(tǒng)一樣，索引一直是 Apache Hudi 不可或缺的一部分，并且與普通表格式抽象不同。在這篇博客中，我們討論了我們?nèi)绾沃匦聵?gòu)想索引并在 Apache Hudi 0.11.0 版本中構(gòu)建新的多模式索引，這是用于 Lakehouse 架構(gòu)的首創(chuàng)高性能索引子系統(tǒng)，以優(yōu)化查詢和寫入事務(wù)，尤其是對于大寬表而言。

1. 為什么在 Hudi 中使用多模索引

索引^[1]被廣泛應(yīng)用于數(shù)據(jù)庫系統(tǒng)中，例如關(guān)系數(shù)據(jù)庫和數(shù)據(jù)倉庫，以降低 I/O 成本并提高查詢效率。類似于書末的索引頁如何幫助您快速定位信息，數(shù)據(jù)庫索引包含輔助數(shù)據(jù)結(jié)構(gòu)，可以快速定位所需的記錄，而無需從存儲(chǔ)中讀取不必要的數(shù)據(jù)。鑒于 Hudi 的設(shè)計(jì)已經(jīng)針對處理可變更改流進(jìn)行了高度優(yōu)化，具有不同的寫入模式，Hudi 從一開始就獨(dú)特地支持索引能力^[2]以加快 Lakehouse 的 upserts。事實(shí)上，文獻(xiàn)中存在數(shù)十種索引技術(shù)^[3]，并且大多數(shù)流行的數(shù)據(jù)庫系統(tǒng)，例如 RDBMS、PostgreSQL、MySQL、Spanner、CockroachDB 等，都提供了一個(gè)強(qiáng)大的工具箱來支持其中的許多技術(shù)。雖然 Hudi 的索引現(xiàn)在已經(jīng)被行業(yè)證明可以快速更新插入，但這些優(yōu)勢還沒有被用于查詢。鑒于數(shù)據(jù)湖的數(shù)據(jù)規(guī)模是傳統(tǒng)數(shù)據(jù)庫/倉庫的 10-100 倍，通用索引子系統(tǒng)可以為數(shù)據(jù)湖帶來改變游戲規(guī)則的性能提升。在?Hudi 0.11.0 版本中^[4]，我們重新構(gòu)想了用于數(shù)據(jù)湖的通用多模索引應(yīng)該是什么樣子。Hudi 的多模態(tài)索引是通過增強(qiáng)元數(shù)據(jù)表^[5]來實(shí)現(xiàn)的，可以靈活地?cái)U(kuò)展到新的索引類型，以及異步索引構(gòu)建機(jī)制^[6]。該博客涉及核心設(shè)計(jì)原則以及多模式索引如何服務(wù)于所有現(xiàn)有的索引機(jī)制，而隨后的其他博客則更詳細(xì)地介紹了其余方面。

2. 設(shè)計(jì)以及實(shí)現(xiàn)

多模索引需要滿足以下要求：

• ??可擴(kuò)展的元數(shù)據(jù)：表元數(shù)據(jù)，即有關(guān)表的輔助數(shù)據(jù)，必須可擴(kuò)展至非常大的大小，例如，Terabytes (TB)。應(yīng)該輕松集成不同類型的索引以支持各種用例，而不必?fù)?dān)心管理相同的用例。

• ? ACID 事務(wù)更新：索引和表元數(shù)據(jù)必須始終保持最新并與數(shù)據(jù)表同步，并且部分寫入數(shù)據(jù)不應(yīng)該對下游暴露。

• ??快速查找：大海撈針類型的查找必須快速高效，無需掃描整個(gè)索引，因?yàn)榇笮蛿?shù)據(jù)集的索引大小可能是 TB。

基于這些需求，我們設(shè)計(jì)并實(shí)現(xiàn)了多模索引，實(shí)現(xiàn)了Hudi的通用索引子系統(tǒng)。

2.1 可擴(kuò)展的元數(shù)據(jù)

所有包含表元數(shù)據(jù)的索引都存儲(chǔ)在一個(gè) Hudi?Merge-On-Read^[7]?(MOR) 類型的表，即元數(shù)據(jù)表^[8]。這是一種常見的做法，其中數(shù)據(jù)庫將元數(shù)據(jù)存儲(chǔ)為內(nèi)部視圖，將 Apache Kafka 存儲(chǔ)為內(nèi)部主題。元數(shù)據(jù)表是無服務(wù)器的，獨(dú)立于計(jì)算和查詢引擎。MOR 表布局通過避免數(shù)據(jù)同步合并和減少寫入放大來提供極快的寫入速度。這對于大型數(shù)據(jù)集非常重要，因?yàn)樵獢?shù)據(jù)表的更新大小可能會(huì)增長到無法管理。這有助于 Hudi 將元數(shù)據(jù)擴(kuò)展到 TB 大小，就像?BigQuery^[9]?等其他數(shù)據(jù)系統(tǒng)一樣。我們已經(jīng)有了文件、column_stats 和bloom_filter 索引來提高多個(gè)方面的性能，如本博客后面所述。基礎(chǔ)框架的構(gòu)建可擴(kuò)展和可擴(kuò)展至任何新索引，如位圖、基于 R-tree 的索引、記錄級索引等等。任何此類索引都可以根據(jù)需要啟用和禁用，而無需與其他索引協(xié)調(diào)。此外，Hudi 很自豪能夠提供異步索引^[10]，這是同類中的第一個(gè)，支持與常規(guī)寫入器一起構(gòu)建索引，而不會(huì)影響寫入延遲（即將發(fā)布的博客詳細(xì)討論異步索引）。

2.2 ACID事務(wù)更新

元數(shù)據(jù)表保證 ACID 事務(wù)更新。對數(shù)據(jù)表的所有更改都將轉(zhuǎn)換為提交到元數(shù)據(jù)表的元數(shù)據(jù)記錄，我們將其設(shè)計(jì)為多表事務(wù)，這樣每次對 Hudi 表的寫入只有在數(shù)據(jù)表和元數(shù)據(jù)表都提交時(shí)才能成功。多表事務(wù)確保原子性并且對故障具有彈性，因此對數(shù)據(jù)或元數(shù)據(jù)表的部分寫入永遠(yuǎn)不會(huì)暴露給其他讀取或?qū)懭胧聞?wù)。元數(shù)據(jù)表是為自我管理而構(gòu)建的，因此用戶不需要在任何表服務(wù)上花費(fèi)操作周期，包括壓縮和清理。未來我們計(jì)劃通過日志壓縮服務(wù)^[11]來增加 MOR 表的更新，這可以進(jìn)一步減少寫入放大。

2.3 快速查找

為了提高讀寫性能，處理層需要點(diǎn)查找以從元數(shù)據(jù)表中的文件中找到必要的條目。由于 Parquet 是列式的，而 Avro 是基于行的，因此它們不適合點(diǎn)查找。另一方面，來自 HBase 的 HFile 格式專為高效的點(diǎn)查找而設(shè)計(jì)。

我們進(jìn)行了實(shí)驗(yàn)，以測量在一個(gè)文件中針對不同文件格式的 1000 萬 (10M) 個(gè)條目中的 N 個(gè)條目的點(diǎn)查找延遲。與 Parquet 或 Avro 相比，HFile 顯示了 10 到 100 倍的改進(jìn)，Parquet 或 Avro 仍用于其他格式，如 Delta 和 Iceberg 用于表元數(shù)據(jù)。

由于對元數(shù)據(jù)表的大多數(shù)訪問都是點(diǎn)和范圍查找，因此選擇 HFile 格式作為內(nèi)部元數(shù)據(jù)表的基本文件格式。由于元數(shù)據(jù)表在分區(qū)級別（文件索引）或文件級別（column_stats 索引）存儲(chǔ)輔助數(shù)據(jù)，因此基于單個(gè)分區(qū)路徑和文件組的查找對于 HFile 格式將非常有效。Hudi 元數(shù)據(jù)表中的基本文件和日志文件都使用 HFile 格式。每個(gè)日志文件可以包含多個(gè)日志塊。如下圖所示，Hudi 采用了一種新穎的思路，即利用 Inline File System 將實(shí)際數(shù)據(jù)塊的內(nèi)容讀取為 HFile，從而利用 HFile 格式更快的查找。這種設(shè)計(jì)經(jīng)過精心挑選，以減少云存儲(chǔ)方案中的遠(yuǎn)程 GET 調(diào)用，因?yàn)辄c(diǎn)查找可能不需要下載整個(gè)文件。

此外，這些元數(shù)據(jù)表索引通過緩存元數(shù)據(jù)的集中時(shí)間線服務(wù)器提供服務(wù)，進(jìn)一步減少了執(zhí)行程序查找的延遲。

3. 多模索引如何提升性能？

元數(shù)據(jù)表對于提高 Hudi 用戶的性能有幾個(gè)好處。讓我們看看 Hudi 的文件列表如何提高 10 倍，數(shù)據(jù)跳過如何通過多模式索引將讀取延遲降低 10 倍至 30 倍或更多。

3.1 文件Listing

云存儲(chǔ)中分析管道的大型部署通常在 1000 多個(gè)分區(qū)中包含 100k 或更多文件。由于節(jié)流和高 I/O 操作，如此大規(guī)模的直接進(jìn)行文件Listing通常是瓶頸，從而導(dǎo)致可伸縮性問題。為了提高文件Listing性能，Hudi 將信息存儲(chǔ)在元數(shù)據(jù)表中名為 files 的分區(qū)中，以避免文件系統(tǒng)調(diào)用，例如 exists、listStatus 和 listFiles。文件分區(qū)存儲(chǔ)數(shù)據(jù)表中每個(gè)分區(qū)的文件名、大小和活動(dòng)狀態(tài)等文件信息。

我們展示了在 Amazon S3 上使用包含不同數(shù)量的文件和分區(qū)的各種規(guī)模的 Hudi 表對文件列表的性能改進(jìn)。通過使用元數(shù)據(jù)表中的文件索引，與在 S3 上直接列出相比，文件列出延遲大大降低，提供 2-10 倍的加速（包括 1M 文件的非分區(qū)表，圖中未顯示）。由于像 S3 這樣的云存儲(chǔ)對非常大的數(shù)據(jù)集上的文件系統(tǒng)調(diào)用進(jìn)行速率限制和節(jié)流，因此直接文件列表不能隨著分區(qū)中文件數(shù)量的增加而很好地?cái)U(kuò)展，并且在某些情況下，文件系統(tǒng)調(diào)用可能無法完成。相比之下，文件索引有助于消除此類瓶頸并提供對文件Listing的快速訪問。更好的是，通過重用元數(shù)據(jù)表讀取器并在時(shí)間線服務(wù)器緩存索引，文件列表延遲進(jìn)一步降低。

3.2 Data Skipping

元數(shù)據(jù)表的另一個(gè)主要好處是在服務(wù)讀取查詢時(shí)幫助跳過數(shù)據(jù)。column_stats 分區(qū)存儲(chǔ)所有數(shù)據(jù)文件的感興趣列的統(tǒng)計(jì)信息，例如最小值和最大值、總值、空計(jì)數(shù)、大小等。在使用匹配感興趣列的謂詞提供讀取查詢時(shí)使用統(tǒng)計(jì)信息。這可以大大提高查詢性能，因?yàn)椴黄ヅ涞奈募?huì)被過濾掉，而不會(huì)從文件系統(tǒng)中讀取，還可以減少文件系統(tǒng)的 I/O 負(fù)擔(dān)。此外，如果用戶配置了集群、Z 順序或任何其他布局優(yōu)化，這些可以將查詢延遲減少一個(gè)數(shù)量級，因?yàn)槲募鶕?jù)常見查詢列的訪問模式很好地布局。

在column_stats分區(qū)中，記錄鍵是由列名、分區(qū)名、數(shù)據(jù)文件名依次串聯(lián)而成的，這樣我們就可以進(jìn)行點(diǎn)查找和范圍讀取。這種記錄鍵設(shè)計(jì)也解鎖了在 column_stats 索引上執(zhí)行前綴查找的能力。例如，如上所示，Query1 指定了 col1 和分區(qū)，Query2 在謂詞中指定了 col2。謂詞用于構(gòu)造對 column_stats 索引的前綴查找，而無需提供完整的記錄鍵。這大大減少了對具有 100 甚至 1000 列的大型數(shù)據(jù)集的索引查找，因?yàn)橐檎业乃饕龡l目的數(shù)量大約為 O(num_query_columns)，通常很?。ɡ?，5 到 10），而不是 O (num_table_columns) 可能很大（例如，超過 100 或 1000）。

我們對一個(gè)包含 10M 條目的文件進(jìn)行了基于前綴查找的實(shí)驗(yàn)。每個(gè)列查找預(yù)計(jì)將匹配 10k 個(gè)條目。在所有情況下，與次優(yōu)（即 Parquet）相比，HFile 能夠顯示出至少 3 倍的延遲。這也極大地提高了云存儲(chǔ)的性能，因?yàn)檫@大大減少了遠(yuǎn)程 GET 調(diào)用的數(shù)量。通過這樣的設(shè)計(jì)，與沒有數(shù)據(jù)跳過相比，數(shù)據(jù)跳過帶來了 10 到 30 倍的查詢延遲增益。期待更多關(guān)于 Hudi 數(shù)據(jù)跳過的后續(xù)博客的詳細(xì)信息。

3.3 upsert性能

Hudi 中使用最廣泛的索引之一是基于布隆過濾器的索引。該索引對記錄鍵的最小值和最大值采用基于范圍的修剪，并使用基于布隆過濾器的查找來標(biāo)記傳入記錄。對于大型表，這涉及讀取所有匹配數(shù)據(jù)文件的頁腳以進(jìn)行布隆過濾器，這在整個(gè)數(shù)據(jù)集隨機(jī)更新的情況下可能會(huì)很昂貴。引入元數(shù)據(jù)表中的bloom_filter分區(qū)來存儲(chǔ)所有數(shù)據(jù)文件的bloom過濾器，避免掃描所有數(shù)據(jù)文件的頁腳。該分區(qū)中的記錄鍵由分區(qū)名和數(shù)據(jù)文件名組成。與 column_stats 索引類似，它利用點(diǎn)和前綴查找。根據(jù)我們對包含 100k 個(gè)文件的 Hudi 表的分析，與從單個(gè)數(shù)據(jù)文件頁腳讀取相比，從元數(shù)據(jù)表中的 bloom_filter 分區(qū)讀取布隆過濾器的速度要快 3 倍。

3.4 未來的工作

如上所述，我們希望進(jìn)一步豐富 Hudi 的元數(shù)據(jù)。我們正在添加一個(gè)新的記錄級索引^[12]，領(lǐng)先于可擴(kuò)展元數(shù)據(jù)的 Lakehouse 技術(shù)，它將記錄鍵映射到存儲(chǔ)它們的實(shí)際數(shù)據(jù)文件。對于像 1000 億多條記錄這樣的超大規(guī)模數(shù)據(jù)集，現(xiàn)有索引可能無法滿足某些類型工作負(fù)載的 SLA。借助我們的多模式索引框架和更快的查找，我們應(yīng)該能夠比現(xiàn)有索引更快地定位記錄。這對于索引查找本身可以定義整個(gè)寫入延遲的大型部署非常強(qiáng)大。我們還希望為輔助列、位圖索引等添加布隆過濾器。我們歡迎來自社區(qū)的更多想法和貢獻(xiàn)，為我們的多模式索引潮流添加更多索引。

4. 結(jié)論

Hudi 為 Lakehouse 架構(gòu)帶來了一種新穎的多模式索引，一個(gè)無服務(wù)器和高性能的索引子系統(tǒng)，用于存儲(chǔ)各種類型的輔助數(shù)據(jù)，以提高讀寫性能。旨在以多種方式進(jìn)行可擴(kuò)展、自我管理，并支持高效、輕松地向 Hudi 添加更豐富的索引。我們計(jì)劃在即將發(fā)布的版本中使用新索引來增強(qiáng)多模式索引。

引用鏈接

[1]?索引:?[https://en.wikipedia.org/wiki/Database_index](https://en.wikipedia.org/wiki/Database_index)
[2]?索引能力:?[https://hudi.apache.org/blog/2020/11/11/hudi-indexing-mechanisms/](https://hudi.apache.org/blog/2020/11/11/hudi-indexing-mechanisms/)
[3]?索引技術(shù):?[https://en.wikipedia.org/wiki/Database_index#Types_of_indexes](https://en.wikipedia.org/wiki/Database_index#Types_of_indexes)
[4]?Hudi 0.11.0 版本中:?[https://hudi.apache.org/releases/release-0.11.0](https://hudi.apache.org/releases/release-0.11.0)
[5]?元數(shù)據(jù)表:?[https://hudi.apache.org/docs/metadata](https://hudi.apache.org/docs/metadata)
[6]?異步索引構(gòu)建機(jī)制:?[https://hudi.apache.org/docs/metadata_indexing/#setup-async-indexing](https://hudi.apache.org/docs/metadata_indexing/#setup-async-indexing)
[7]?Merge-On-Read:?[https://hudi.apache.org/docs/table_types#merge-on-read-table](https://hudi.apache.org/docs/table_types#merge-on-read-table)
[8]?元數(shù)據(jù)表:?[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=147427331](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=147427331)
[9]?BigQuery:?[http://vldb.org/pvldb/vol14/p3083-edara.pdf](http://vldb.org/pvldb/vol14/p3083-edara.pdf)
[10]?異步索引:?[https://github.com/apache/hudi/blob/master/rfc/rfc-45/rfc-45.md](https://github.com/apache/hudi/blob/master/rfc/rfc-45/rfc-45.md)
[11]?日志壓縮服務(wù):?[https://github.com/apache/hudi/pull/5041](https://github.com/apache/hudi/pull/5041)
[12]?記錄級索引:?[https://cwiki.apache.org/confluence/display/HUDI/RFC-08++Record+level+indexing+mechanisms+for+Hudi+datasets](https://cwiki.apache.org/confluence/display/HUDI/RFC-08++Record+level+indexing+mechanisms+for+Hudi+datasets)