1. 概述

如今數(shù)據(jù)湖上的事務(wù)被認為是 Lakehouse 的一個關(guān)鍵特征。 但到目前為止，實際完成了什么？ 目前有哪些方法？ 它們在現(xiàn)實世界中的表現(xiàn)如何？ 這些問題是本博客的重點。

有幸從事過各種數(shù)據(jù)庫項目——RDBMS (Oracle)、NoSQL 鍵值存儲 (Voldemort)、流數(shù)據(jù)庫 (ksqlDB)、閉源實時數(shù)據(jù)存儲，當然還有 Apache Hudi， 我可以肯定地說，工作負載的不同深刻地影響了不同數(shù)據(jù)庫中采用的并發(fā)控制機制。本博客還將介紹我們?nèi)绾沃匦滤伎?Apache Hudi 數(shù)據(jù)湖的并發(fā)控制機制。

首先，我們直截了當點，RDBMS 數(shù)據(jù)庫提供了最豐富的事務(wù)功能集和最廣泛的并發(fā)控制機制，不同的隔離級別、細粒度鎖、死鎖檢測/避免等其他更多機制，因為它們必須支持行級變更和跨多個表的讀取，同時強制執(zhí)行鍵約束并維護索引。而NoSQL 存儲提供了非常弱的保證，例如僅僅提供最終一致性和簡單的行級原子性，以換取更簡單的工作負載的更好的擴展性。傳統(tǒng)數(shù)據(jù)倉庫基于列存或多或少提供了您在 RDBMS 中可以找到的全套功能，強制執(zhí)行鎖定和鍵約束，而云數(shù)據(jù)倉庫似乎更多地關(guān)注存算分離架構(gòu)，同時提供更少的隔離級別。作為一個令人驚訝的例子，沒有強制執(zhí)行鍵約束。

2. 數(shù)據(jù)湖并發(fā)控制中的陷阱

從歷史看來，數(shù)據(jù)湖一直被視為在云存儲上讀取/寫入文件的批處理作業(yè)，有趣的是看到大多數(shù)新工作如何擴展此視圖并使用某種形式的“樂觀并發(fā)控制”（OCC）來實現(xiàn)文件版本控制。 OCC 作業(yè)采用表級鎖來檢查它們是否影響了重疊文件，如果存在沖突則中止操作，鎖有時甚至只是在單個 Apache Spark Driver節(jié)點上持有的 JVM 級鎖，這對于主要將文件附加到表的舊式批處理作業(yè)的輕量級協(xié)調(diào)來說可能沒問題，但不能廣泛應(yīng)用于現(xiàn)代數(shù)據(jù)湖工作負載。此類方法是在考慮不可變/僅附加數(shù)據(jù)模型的情況下構(gòu)建的，這些模型不適用于增量數(shù)據(jù)處理或鍵控更新/刪除。 OCC 非常樂觀地認為真正的沖突永遠不會發(fā)生。將 OCC 與 RDBMS 或傳統(tǒng)數(shù)據(jù)倉庫的完全成熟的事務(wù)功能進行比較的開發(fā)人員布道是完全錯誤的，直接引用維基百科——“如果頻繁地爭用數(shù)據(jù)資源，重復重啟事務(wù)的成本會顯著損害性能，在這種情況下，其他并發(fā)控制方法可能更適合。” 當沖突確實發(fā)生時，它們會導致大量資源浪費，因為你有每次嘗試運行幾個小時后都失敗的批處理作業(yè)！

想象一下兩個寫入進程的真實場景：一個每 30 分鐘生成一次新數(shù)據(jù)的攝取寫入作業(yè)和一個執(zhí)行 GDPR 的刪除作業(yè)，需要 2 小時才能完成刪除。這些很可能與隨機刪除重疊文件，并且刪除作業(yè)幾乎可以保證每次都餓死并且無法提交。 在數(shù)據(jù)庫方面，將長期運行的事務(wù)與樂觀混合會導致失望，因為事務(wù)越長，它們重疊的可能性就越高。

那么有什么替代方案呢？鎖？維基百科還說 - “但是，基于鎖（“悲觀”）的方法也可能提供較差的性能，因為即使避免了死鎖，鎖也會極大地限制有效的并發(fā)性。”。這就是 Hudi 采用不同方法的地方，我們認為這種方法更適合現(xiàn)代數(shù)據(jù)湖事務(wù)，這些事務(wù)通常是長期運行的，甚至是連續(xù)的。與數(shù)據(jù)庫的標準讀/寫相比，數(shù)據(jù)湖工作負載與高吞吐量流處理作業(yè)共享更多特征，這就是我們借鑒的地方。在流處理中，事件被序列化為單個有序日志，避免任何鎖/并發(fā)瓶頸，用戶可以每秒連續(xù)處理數(shù)百萬個事件。Hudi 在 Hudi 時間線上實現(xiàn)了一個文件級、基于日志的并發(fā)控制協(xié)議，而該協(xié)議又依賴于對云存儲的最低限度的原子寫入。通過將事件日志構(gòu)建為進程間協(xié)調(diào)的核心部分，Hudi 能夠提供一些靈活的部署模型，與僅跟蹤表快照的純 OCC 方法相比，這些模型提供更高的并發(fā)性。

3. 模型 1：單寫入，內(nèi)聯(lián)表服務(wù)

并發(fā)控制的最簡單形式就是完全沒有并發(fā)。 數(shù)據(jù)湖表通常在其上運行公共服務(wù)以確保效率，從舊版本和日志中回收存儲空間、合并文件（Hudi 中的Clustering）、合并增量（Hudi 中的Compaction）等等。 Hudi 可以簡單地消除對并發(fā)控制的需求，并通過支持這些開箱即用的表服務(wù)并在每次寫入表后內(nèi)聯(lián)運行來最大化吞吐量。

執(zhí)行計劃是冪等的，持久化至時間線并從故障中自動恢復。對于大多數(shù)簡單的用例，這意味著只需寫入就足以獲得一個不需要并發(fā)控制的管理良好的表。

4. 模型2：單寫入，異步表服務(wù)

我們上面的刪除/攝取示例并不是那么簡單。雖然攝取/寫入可能只是更新表上的最后 N 個分區(qū)，但刪除甚至可能跨越整個表，將它們混合在同一個工作負載中可能會大大影響攝取延遲，因此Hudi 提供了以異步方式運行表服務(wù)的選項，其中大部分繁重的工作（例如通過壓縮服務(wù)實際重寫列數(shù)據(jù)）是異步完成的，消除了任何重復的浪費重試，同時還使用Clustering技術(shù)。因此單個寫入可以同時使用常規(guī)更新和 GDPR 刪除并將它們序列化到日志中。鑒于 Hudi 具有記錄級索引并且 avro 日志寫入要便宜得多（與寫入 parquet 相比，后者可能要貴 10 倍或更高），攝取延遲可以持續(xù)，同時享受出色的可回溯性。事實上我們能夠在 Uber 將這個模型擴展到 100 PB數(shù)據(jù)規(guī)模，通過將所有刪除和更新排序到同一個源 Apache Kafka 主題中，并發(fā)控制不僅僅是鎖，Hudi 無需任何外部鎖即可完成所有這一切。

5. 模型3：多寫入

但是并不總是可以將刪除序列化到相同的寫入流中，或者需要基于 sql 的刪除。 對于多個分布式進程，某種形式的鎖是不可避免的，但就像真正的數(shù)據(jù)庫一樣，Hudi 的并發(fā)模型足夠智能，可以將實際寫入表的內(nèi)容與管理或優(yōu)化表的表服務(wù)區(qū)分開來。 Hudi 提供了類似的跨多個寫入器的樂觀并發(fā)控制，但表服務(wù)仍然可以完全無鎖和異步地執(zhí)行。 這意味著刪除作業(yè)只能對刪除進行編碼，攝取作業(yè)可以記錄更新，而壓縮服務(wù)再次將更新/刪除應(yīng)用于基本文件。 盡管刪除作業(yè)和攝取作業(yè)可以像我們上面提到的那樣相互競爭和餓死，但它們的運行時間要低得多，浪費也大大降低，因為壓縮完成了parquet/列數(shù)據(jù)寫入的繁重工作。

綜上所述，在這個基礎(chǔ)上我們還有很多方法可以改進。

首先，Hudi 已經(jīng)實現(xiàn)了一種標記機制，可以跟蹤作為活動寫入事務(wù)一部分的所有文件，以及一種可以跟蹤表的活動寫入者的心跳機制。這可以由其他活動事務(wù)/寫入器直接使用來檢測其他寫入器正在做什么，如果檢測到?jīng)_突，則盡早中止，從而更快地將集群資源返回給其他作業(yè)。

雖然在需要可序列化快照隔離時樂觀并發(fā)控制很有吸引力，但它既不是最佳方法，也不是處理寫入者之間并發(fā)性的唯一方法。我們計劃使用 CRDT 和廣泛采用的流處理概念，通過我們的日志合并 API 實現(xiàn)完全無鎖的并發(fā)控制，這已經(jīng)被證明可以為數(shù)據(jù)湖維持巨大的連續(xù)寫入量。

談到鍵約束，Hudi 是當今唯一確保唯一鍵約束的湖事務(wù)層，但僅限于表的記錄鍵。我們將尋求以更通用的形式將此功能擴展到非主鍵字段，并使用上述較新的并發(fā)模型。

最后，要使數(shù)據(jù)湖成功轉(zhuǎn)型為Lakehouse，我們必須從“Hadoop 倉庫”愿景的失敗中吸取教訓，它與新的“Lakehouse”愿景有著相似的目標。 設(shè)計人員沒有密切關(guān)注與數(shù)據(jù)倉庫相關(guān)的缺失技術(shù)差距，并且對實際軟件產(chǎn)生了不切實際的期望。 隨著事務(wù)和數(shù)據(jù)庫功能最終成為數(shù)據(jù)湖的主流，我們必須應(yīng)用這些經(jīng)驗教訓并對當前的缺點保持坦率。 如果您正在構(gòu)建一個 Lakehouse，我希望這篇文章能鼓勵您仔細考慮圍繞并發(fā)控制的各種操作和效率方面。 

https://hudi.apache.org/blog/2021/12/16/lakehouse-concurrency-control-are-we-too-optimistic

以上就是Lakehouse數(shù)據(jù)湖并發(fā)控制陷阱分析的詳細內(nèi)容，更多關(guān)于Lakehouse數(shù)據(jù)湖并發(fā)控制的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論