1. 摘要

Hudi 支持在寫入時(shí)自動(dòng)清理未成功提交的數(shù)據(jù)。Apache Hudi 在寫入時(shí)引入標(biāo)記機(jī)制來有效跟蹤寫入存儲(chǔ)的數(shù)據(jù)文件。 在本博客中，我們將深入探討現(xiàn)有直接標(biāo)記文件機(jī)制的設(shè)計(jì)，并解釋了其在云存儲(chǔ)（如 AWS S3、Aliyun OSS）上針對(duì)非常大批量寫入的性能問題。 并且演示如何通過引入基于時(shí)間軸服務(wù)器的標(biāo)記來提高寫入性能。

2. 為何引入Markers機(jī)制

Hudi中的marker是一個(gè)表示存儲(chǔ)中存在對(duì)應(yīng)的數(shù)據(jù)文件的標(biāo)簽，Hudi使用它在故障和回滾場(chǎng)景中自動(dòng)清理未提交的數(shù)據(jù)。

每個(gè)標(biāo)記條目由三部分組成

• 數(shù)據(jù)文件名
• 標(biāo)記擴(kuò)展名 (.marker)
• 創(chuàng)建文件的 I/O 操作（CREATE - 插入、MERGE - 更新/刪除或 APPEND - 兩者之一）。

例如標(biāo)記91245ce3-bb82-4f9f-969e-343364159174-0_140-579-0_20210820173605.parquet.marker.CREATE指示相應(yīng)的數(shù)據(jù)文件是91245ce3-bb82-4f9f-969e-343364159174-0_140-579-0_20210820173605.parquet
并且 I/O 類型是 CREATE。

在寫入每個(gè)數(shù)據(jù)文件之前，Hudi 寫入客戶端首先在存儲(chǔ)中創(chuàng)建一個(gè)標(biāo)記，該標(biāo)記會(huì)被持久化，在提交成功后會(huì)被寫入客戶端顯式刪除。

標(biāo)記對(duì)于寫客戶端有效地執(zhí)行不同的操作很有用，標(biāo)記主要有如下兩個(gè)作用

刪除重復(fù)/部分?jǐn)?shù)據(jù)文件：通過 Spark 寫入 Hudi 時(shí)會(huì)有多個(gè) Executor 進(jìn)行并發(fā)寫入。一個(gè) Executor 可能失敗，留下部分?jǐn)?shù)據(jù)文件寫入，在這種情況下 Spark 會(huì)重試 Task ，當(dāng)啟用speculative execution時(shí)，可以有多次attempts成功將相同的數(shù)據(jù)寫入不同的文件，但最終只有一次attempt會(huì)交給 Spark Driver程序進(jìn)程進(jìn)行提交。標(biāo)記有助于有效識(shí)別寫入的部分?jǐn)?shù)據(jù)文件，其中包含與后來成功寫入的數(shù)據(jù)文件相比的重復(fù)數(shù)據(jù)，并在寫入和提交完成之前清理這些重復(fù)的數(shù)據(jù)文件。

回滾失敗的提交：寫入時(shí)可能在中間失敗，留下部分寫入的數(shù)據(jù)文件。在這種情況下，標(biāo)記條目會(huì)在提交失敗時(shí)保留在存儲(chǔ)中。在接下來的寫操作中，寫客戶端首先回滾失敗的提交，通過標(biāo)記識(shí)別這些提交中寫入的數(shù)據(jù)文件并刪除它們。

接下來我們將深入研究現(xiàn)有的標(biāo)記機(jī)制，闡述其性能問題，并演示新的基于時(shí)間軸服務(wù)器的標(biāo)記機(jī)制來解決該問題。

3. 現(xiàn)有的直接標(biāo)記機(jī)制及其局限性

現(xiàn)有的標(biāo)記機(jī)制簡(jiǎn)單地創(chuàng)建與每個(gè)數(shù)據(jù)文件相對(duì)應(yīng)的新標(biāo)記文件，標(biāo)記文件名如前面所述。 每個(gè) marker 文件被寫入在相同的目錄層次結(jié)構(gòu)中，即提交即時(shí)和分區(qū)路徑，在Hudi表的基本路徑下的臨時(shí)文件夾.hoodie/.temp下。 例如，下圖顯示了向 Hudi 表寫入數(shù)據(jù)時(shí)創(chuàng)建的標(biāo)記文件和相應(yīng)數(shù)據(jù)文件的示例。 在獲取或刪除所有marker文件路徑時(shí)，該機(jī)制首先列出臨時(shí)文件夾.hoodie/.temp/<commit_instant>下的所有路徑，然后進(jìn)行操作。

雖然掃描整個(gè)表以查找未提交的數(shù)據(jù)文件效率更高，但隨著要寫入的數(shù)據(jù)文件數(shù)量的增加，要?jiǎng)?chuàng)建的標(biāo)記文件的數(shù)量也會(huì)增加。 這可能會(huì)為 AWS S3 等云存儲(chǔ)帶來性能瓶頸。 在 AWS S3 中，每個(gè)文件創(chuàng)建和刪除調(diào)用都會(huì)觸發(fā)一個(gè) HTTP 請(qǐng)求，并且對(duì)存儲(chǔ)桶中每個(gè)前綴每秒可以處理的請(qǐng)求數(shù)有速率限制。 當(dāng)并發(fā)寫入的數(shù)據(jù)文件數(shù)量和 marker 文件數(shù)量巨大時(shí)，marker 文件的操作會(huì)成為寫入性能的顯著性能瓶頸。而在像 HDFS 這樣的存儲(chǔ)上，用戶可能幾乎不會(huì)注意到這一點(diǎn)，其中文件系統(tǒng)元數(shù)據(jù)被有效地緩存在內(nèi)存中。

4. 基于時(shí)間線服務(wù)器的標(biāo)記機(jī)制提高寫入性能

為解決上述 AWS S3 速率限制導(dǎo)致的性能瓶頸，我們引入了一種利用時(shí)間線服務(wù)器的新標(biāo)記機(jī)制，該機(jī)制優(yōu)化了存儲(chǔ)標(biāo)記的相關(guān)延遲。 Hudi 中的時(shí)間線服務(wù)器用作提供文件系統(tǒng)和時(shí)間線視圖。 如下圖所示，新的基于時(shí)間線服務(wù)器的標(biāo)記機(jī)制將標(biāo)記創(chuàng)建和其他標(biāo)記相關(guān)操作從各個(gè)執(zhí)行器委托給時(shí)間線服務(wù)器進(jìn)行集中處理。 時(shí)間線服務(wù)器在內(nèi)存中為相應(yīng)的標(biāo)記請(qǐng)求維護(hù)創(chuàng)建的標(biāo)記，時(shí)間線服務(wù)器通過定期將內(nèi)存標(biāo)記刷新到存儲(chǔ)中有限數(shù)量的底層文件來實(shí)現(xiàn)一致性。 通過這種方式，即使數(shù)據(jù)文件數(shù)量龐大，也可以顯著減少與標(biāo)記相關(guān)的實(shí)際文件操作次數(shù)和延遲，從而提高寫入性能。

為了提高處理標(biāo)記創(chuàng)建請(qǐng)求的效率，我們?cè)O(shè)計(jì)了在時(shí)間線服務(wù)器上批量處理標(biāo)記請(qǐng)求。 每個(gè)標(biāo)記創(chuàng)建請(qǐng)求在 Javalin 時(shí)間線服務(wù)器中異步處理，并在處理前排隊(duì)。 對(duì)于每個(gè)批處理間隔，例如 20 毫秒，調(diào)度線程從隊(duì)列中拉出待處理的請(qǐng)求并將它們發(fā)送到工作線程進(jìn)行處理。 每個(gè)工作線程處理標(biāo)記創(chuàng)建請(qǐng)求，并通過重寫存儲(chǔ)標(biāo)記的底層文件。有多個(gè)工作線程并發(fā)運(yùn)行，考慮到文件覆蓋的時(shí)間比批處理時(shí)間長，每個(gè)工作線程寫入一個(gè)不被其他線程觸及的獨(dú)占文件以保證一致性和正確性。 批處理間隔和工作線程數(shù)都可以通過寫入選項(xiàng)進(jìn)行配置。

請(qǐng)注意工作線程始終通過將請(qǐng)求中的標(biāo)記名稱與時(shí)間線服務(wù)器上維護(hù)的所有標(biāo)記的內(nèi)存副本進(jìn)行比較來檢查標(biāo)記是否已經(jīng)創(chuàng)建。 存儲(chǔ)標(biāo)記的底層文件僅在第一個(gè)標(biāo)記請(qǐng)求（延遲加載）時(shí)讀取。 請(qǐng)求的響應(yīng)只有在新標(biāo)記刷新到文件后才會(huì)返回，以便在時(shí)間線服務(wù)器故障的情況下，時(shí)間線服務(wù)器可以恢復(fù)已經(jīng)創(chuàng)建的標(biāo)記。 這些確保存儲(chǔ)和內(nèi)存中副本之間的一致性，并提高處理標(biāo)記請(qǐng)求的性能。

5. 標(biāo)記相關(guān)的寫入選項(xiàng)

我們?cè)?0.9.0 版本中引入了以下與標(biāo)記相關(guān)的新寫入選項(xiàng)，以配置標(biāo)記機(jī)制。

• hoodie.write.markers.type，要使用的標(biāo)記類型。支持兩種模式：direct，每個(gè)數(shù)據(jù)文件對(duì)應(yīng)的單獨(dú)標(biāo)記文件由編寫器直接創(chuàng)建；timeline_server_based，標(biāo)記操作全部在時(shí)間線服務(wù)中處理作為代理。 為了提高效率新的標(biāo)記條目被批處理并存儲(chǔ)在有限數(shù)量的基礎(chǔ)文件中。默認(rèn)值為direct。
• hoodie.markers.timeline_server_based.batch.num_threads，用于在時(shí)間軸服務(wù)器上批處理標(biāo)記創(chuàng)建請(qǐng)求的線程數(shù)。默認(rèn)值為20。
• hoodie.markers.timeline_server_based.batch.interval_ms，標(biāo)記創(chuàng)建批處理的批處理間隔（以毫秒為單位）。默認(rèn)值為50。

6. 性能

我們通過使用 Amazon EMR 和 Spark 和 S3 批量插入大規(guī)模數(shù)據(jù)集來評(píng)估direct和timeline_server_based的標(biāo)記機(jī)制的寫入性能。 輸入數(shù)據(jù)大約為 100GB。 我們通過設(shè)置最大 parquet 文件大小為 1MB 和并行度為 240 來配置寫入操作以并發(fā)生成大量數(shù)據(jù)文件。 正如我們之前提到的，而直接標(biāo)記機(jī)制的延遲對(duì)于較小數(shù)量的增量寫入是可以接受的，對(duì)于產(chǎn)生更多數(shù)據(jù)文件的大批量插入/寫入，開銷會(huì)急劇增加。

如下圖所示，由于是批處理，基于時(shí)間線服務(wù)器的標(biāo)記機(jī)制生成的存儲(chǔ)標(biāo)記的文件要少得多，從而導(dǎo)致標(biāo)記相關(guān)的 I/O 操作的時(shí)間要少得多，因此與直接相比，寫入完成時(shí)間減少了 31%。 標(biāo)記文件機(jī)制。

7. 總結(jié)

我們發(fā)現(xiàn)由于 AWS S3 等云存儲(chǔ)上文件創(chuàng)建和刪除調(diào)用的速率限制，現(xiàn)有的直接標(biāo)記文件機(jī)制會(huì)導(dǎo)致性能瓶頸。 為了解決這個(gè)問題我們引入了一種利用時(shí)間線服務(wù)器的新標(biāo)記機(jī)制，它將標(biāo)記創(chuàng)建和其他與標(biāo)記相關(guān)的操作從各個(gè) Executor 委托給時(shí)間線服務(wù)器，并使用批處理來提高性能。使用 Spark 和 S3 在 Amazon EMR 上進(jìn)行的性能評(píng)估表明，與標(biāo)記相關(guān)的 I/O 延遲和整體寫入時(shí)間有所減少。

以上就是深入解析Apache Hudi內(nèi)核文件標(biāo)記機(jī)制的詳細(xì)內(nèi)容，更多關(guān)于Apache Hudi內(nèi)核文件標(biāo)記的資料請(qǐng)關(guān)注本站其它相關(guān)文章！

海外服務(wù)器租用

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請(qǐng)保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場(chǎng)，如有內(nèi)容涉嫌侵權(quán)，請(qǐng)聯(lián)系alex-e#qq.com處理。