# 背景

LSM-Tree（ Log Structured-Merge Tree）是資料庫中最為常見的儲存結構之一，其核心思想在於充分發揮磁碟連續讀寫的效能優勢、以短時間的記憶體與 IO 的開銷換取最大的寫入效能，資料以 Append-only 的方式寫入 Memtable、達到閾值後凍結 Memtable 並 Flush 為磁碟檔案、再結合 Compaction 機制將多個小檔案進行多路歸併排序形成新的檔案，最終實現資料的高效寫入。

[Apache Doris](https://github.com/apache/doris) 的儲存模型也是採用類似的 LSM-Tree 資料模型。使用者不同批次匯入的資料會先寫入記憶體結構，隨後在磁碟上形成一個個的 Rowset 檔案，每個 Rowset 檔案對應一次資料匯入版本。而 Doris 的 Compaction 則是負責將這些 Rowset 檔案進行合併，將多個 Rowset 小檔案合併成一個 Rowset 大檔案。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7a24355be7ac41c69180df9d6133a48c~tplv-k3u1fbpfcp-zoom-1.image)

在此過程中 Compaction 發揮著以下作用：

-   每個 Rowset 內的資料是按主鍵有序的，但 Rowset 與 Rowset 之間資料是無序的，Compaction 會將多個 Rowset 的資料從無序變為有序，提升資料在讀取時的效率；
-   資料以 Append-only 的方式進行寫入，因此 Delete、Update 等操作都是標記寫入，Compaction 會將標記的資料進行真正刪除或更新，避免資料在讀取時進行額外的掃描及過濾；
-   在 Aggregate 模型上，Compaction 還可以將不同 Rowset 中相同 Key 的資料進行預聚合，減少資料讀取時的聚合計算，進一步提升讀取效率。

# 問題與思考

儘管 Compaction 在寫入和查詢效能方面發揮著十分關鍵的作用，但 Compaction 任務執行期間的寫放大問題以及隨之而來的磁碟 I/O 和 CPU 資源開銷，也為系統穩定性和效能的充分發揮帶來了新的挑戰。

在使用者真實場景中，往往面臨著各式各樣的資料寫入需求，並行寫入任務的多少、單次提交資料量的大小、提交頻次的高低等，各種場景可能需要搭配不同的 Compaction 策略。而不合理的 Compaction 策略則會帶來一系列問題：

-   Compaction 任務排程不及時導致大量版本堆積、Compaction Score 過高，最終導致寫入失敗（-235/-238）；
-   Compaction 任務執行速度慢，CPU 消耗高；
-   Compaction 任務記憶體佔用高，影響查詢效能甚至導致 BE OOM；

與此同時，儘管 Apache Doris 提供了多個引數供使用者進行調整，但相關引數眾多且語義複雜，使用者理解成本過高，也為人工調優增加了難度。

基於以上問題，從 Apache Doris 1.1.0 版本開始，我們增加了主動觸發式 QuickCompaction、引入了 Cumulative Compaction 任務的隔離排程並增加了小檔案合併的梯度合併策略，對高併發寫入和資料實時可見等場景都進行了針對性最佳化。

而在 Apache Doris 最新的 1.2.2 版本和即將釋出的 2.0.0 版本中，我們對系統 Compaction 能力進行了全方位增強，**在觸發策略、執行** **方式** **、** **工程實現** **以及引數配置上都進行了大幅最佳化，** **在實時性、易用性與穩定性得到提升的同時更是徹底解決了查詢效率問題**。

# Compaction 最佳化與實現

在設計和評估 Compaction 策略之時，我們需要綜合權衡 Compaction 的任務模型和使用者真實使用場景，核心最佳化思路包含以下幾點：

-   **實時性和高效性**。Compaction 任務觸發策略的實時性和任務執行方式的高效性直接影響到了查詢執行的速度，版本堆積將導致 Compaction Score 過高且觸發自我保護機制，導致後續資料寫入失敗。
-   **穩定性**。Compaction 任務對系統資源的消耗可控，不會因 Compaction 任務帶來過多的記憶體與 CPU 開銷造成系統不穩定。
-   **易用性**。由於 Compaction 任務涉及排程、策略、執行多個邏輯單元，部分特殊場景需要對 Compaction 進行調優，因此需要 Compaction 涉及的引數能夠精簡明瞭，指導使用者快速進行場景化的調優。

具體在實現過程中，包含了觸發策略、執行方式、工程實現以及引數配置這四個方面的最佳化。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dc5722db63a14698ab732a2c5123cc14~tplv-k3u1fbpfcp-zoom-1.image)

### Compaction 觸發策略

排程策略決定著 Compaction 任務的實時性。在 Apache Doris 2.0.0 版本中，我們在主動觸發和被動掃描這兩種方式的基礎之上引入了 Tablet 休眠機制，力求在各類場景均能以最低的消耗保障最高的實時性。

#### 主動觸發

主動觸發是一種最為實時的方式，在資料匯入的階段就檢查 Tablet 是否有待觸發的 Compaction 任務，這樣的方式保證了 Compaction 任務與資料匯入任務同步進行，在新版本產生的同時就能夠立即觸發資料合併，能夠讓 Tablet 版本數維持在一個非常穩定的狀態。主動觸發主要針對增量資料的 Compaction (Cumulative Compaction)，存量資料則依賴被動掃描完成。

#### 被動掃描

與主動觸發不同，被動掃描主要負責觸發大資料量的 Base Compaction 任務。Doris 透過啟動一個後臺執行緒，對該節點上所有的 Tablet 後設資料進行掃描，根據 Tablet Compaction 任務的緊迫程度進行打分，選擇得分最高的 Tablet 觸發 Compaction 任務。這樣的全域性掃描模式能夠選出最緊急的 Tablet 進行 Compaction，但一般其執行週期較長，所以需要配合主動觸發策略實施。

#### 休眠機制

頻繁的元資訊掃描會導致大量的 CPU 資源浪費。因此在 Doris 2.0.0 版本中我們引入了 Tablet 休眠機制，來降低後設資料掃描帶來的 CPU 開銷。透過對長時間沒有 Compaction 任務的 Tablet 設定休眠時間，一段時間內不再對該 Tablet 進行掃描，能夠大幅降低任務掃描的壓力。同時如果休眠的 Tablet 有突發的匯入，透過主動觸發的方式也能顧喚醒 Compaction 任務，不會對任務的實時性有任何影響。

透過上述的主動掃描+被動觸發+休眠機制，使用最小的資源消耗，保證了 Compaction 任務觸發的實時性。

### Compaction 執行方式

在 Doris 1.2.2 版本中中，我們引入了兩種全新的 Compaction 執行方式：

-   Vertical Compaction，用以徹底解決 Compaction 的記憶體問題以及大寬表場景下的資料合併；
-   Segment Compaction，用以徹底解決上傳過程中的 Segment 檔案過多問題；

而在即將釋出的 Doris 2.0.0 版本，我們引入了 Ordered Data Compaction 以提升時序資料場景的資料合併能力。

#### Vertical Compaction

在之前的版本中，Compaction 通常採用行的方式進行，每次合併的基本單元為整行資料。由於儲存引擎採用列式儲存，行 Compaction 的方式對資料讀取極其不友好，每次 Compaction 都需要載入所有列的資料，記憶體消耗極大，而這樣的方式在寬表場景下也將帶來記憶體的極大消耗。

針對上述問題，我們在 Doris 1.2.2 版本中實現了對列式儲存更加友好的 Vertical Compaction，具體執行流程如下圖：

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6c5c0cf8ab72486abdde9f8106755ab7~tplv-k3u1fbpfcp-zoom-1.image)

整體分為如下幾個步驟：

1.  切分列組。將輸入 Rowset 按照列進行切分，所有的 Key 列一組、Value 列按 N 個一組，切分成多個 Column Group；
1.  Key 列合併。Key 列的順序就是最終資料的順序，多個 Rowset 的 Key 列採用堆排序進行合併，產生最終有序的 Key 列資料。在產生 Key 列資料的同時，會同時產生用於標記全域性序 RowSources。
1.  Value 列的合併。逐一合併 Column Group 中的 Value 列，以 Key 列合併時產生的 RowSources 為依據對資料進行排序。
1.  資料寫入。資料按列寫入，形成最終的 Rowset 檔案。

由於採用了按列組的方式進行資料合併，Vertical Compaction 天然與列式儲存更加貼合，使用列組的方式進行資料合併，單次合併只需要載入部分列的資料，因此能夠極大減少合併過程中的記憶體佔用。在實際測試中，**Vertical** **C** **ompaction 使用記憶體僅為原有 Compaction 演算法的 1/10，同時 Compaction 速率提升 15%。**

Vertical Compaction 在 1.2.2 版本中預設關閉狀態，需要在 BE 配置項中設定 `enable_vertical_compaction=true` 開啟該功能。

相關PR：https://github.com/apache/doris/pull/14524

#### Segment Compaction

在資料匯入階段，Doris 會在記憶體中積攢資料，到達一定大小時 Flush 到磁碟形成一個個的 Segment 檔案。大批次資料匯入時會形成大量的 Segment 檔案進而影響後續查詢效能，基於此 Doris 對一次匯入的 Segment 檔案數量做了限制。當使用者匯入大量資料時，可能會觸發這個限制，此時系統將反饋 -238 (TOO_MANY_SEGMENTS) 同時終止對應的匯入任務。Segment compaction 允許我們在匯入資料的同時進行資料的實時合併，以有效控制 Segment 檔案的數量，增加系統所能承載的匯入資料量，同時最佳化後續查詢效率。具體流程如下所示：

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a7a56f1669cc4b69b65ed384b9a3e84c~tplv-k3u1fbpfcp-zoom-1.image)

在新增的 Segment 數量超過一定閾值（例如 10）時即觸發該任務執行，由專門的合併執行緒非同步執行。透過將每組 10個 Segment 合併成一個新的 Segment 並刪除舊 Segment，匯入完成後的實際 Segment 檔案數量將下降 10 倍。Segment Compaction 會伴隨匯入的過程並行執行，在大資料量匯入的場景下，能夠在不顯著增加匯入時間的前提下大幅降低檔案個數，提升查詢效率。

Segment Compaction 在 1.2.2 版本中預設關閉狀態，需要在 BE 配置項中設定 ` enable_segcompaction = true  `開啟該功能。

相關 PR : https://github.com/apache/doris/pull/12866

#### Ordered Data Compaction

隨著越來越多使用者在時序資料分析場景應用 Apache Doris，我們在 Apache Doris 2.0.0 版本實現了全新的 Ordered Data Compaction。

時序資料分析場景一般具備如下特點：資料整體有序、寫入速率恆定、單次匯入檔案大小相對平均。針對如上特點，Ordered Data Compaction 無需遍歷資料，跳過了傳統 Compaction 複雜的讀資料、排序、聚合、輸出的流程，透過檔案 Link 的方式直接操作底層檔案生成 Compaction 的目標檔案。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8790744023b4402a812bedeb80c4ba16~tplv-k3u1fbpfcp-zoom-1.image)

Ordered Data Compaction 執行流程包含如下幾個關鍵階段：

1.  資料上傳階段。記錄 Rowset 檔案的 Min/Max Key，用於後續合併 Rowset 資料交叉性的判斷；
1.  資料檢查階段。檢查參與 Compaction 的 Rowset 檔案的有序性與整齊度，主要透過資料上傳階段的 Min /Max Key 以及檔案大小進行判斷。
1.  資料合併階段。將輸入 Rowset 的檔案硬連結到新 Rowset，然後構建新 Rowset 的後設資料(包括行數，Size，Min/Max Key 等)。

可以看到上述階段與傳統的 Compaction 流程完全不一樣，只需要檔案的 Link 以及記憶體元資訊的構建，極其簡潔、輕量。**針對時序場景設計的 Ordered Data Compaction 能夠在毫秒級別完成大規模的 Compaction 任務，其記憶體消耗幾乎為** ******0，對使用者極其友好。**

Ordered Data Compaction 在 2.0.0 版本中預設開啟狀態，如需調整在 BE 配置項中修改 ` enable_segcompaction  `即可。

使用方式：BE 配置 `enable_ordered_data_compaction=true`

### Compaction 工程實現

除了上述在觸發策略和 Compaction 演算法上的最佳化之外，Apache Doris 2.0.0 版本還對 Compaction 的工程實現進行了大量細節上的最佳化，包括資料零複製、按需載入、Idle Schedule 等。

#### **資料零複製**

Doris 採用分層的資料儲存模型，資料在 BE 上可以分為如下幾層：Tablet -> Rowset -> Segment -> Column -> Page，資料需要經過逐層處理。由於 Compaction 每次參與的資料量大，資料在各層之間的流轉會帶來大量的 CPU 消耗，在新版本中我們設計並實現了全流程無複製的 Compaction 邏輯，Block 從檔案載入到記憶體中後，後續無序再進行複製，各個元件的使用都透過一個 BlockView 的資料結構完成，這樣徹底的解決了資料逐層複製的問題，將 Compaction 的效率再次提升了 5%。

#### **按需載入**

Compaction 的邏輯本質上是要將多個無序的 Rowset 合併成一個有序的 Rowset，在大部分場景中，Rowset 內或者 Rowset 間的資料並不是完全無序的，可以充分利用區域性有序性進行資料合併，在同一時間僅需載入有序檔案中的第一個，這樣隨著合併的進行再逐漸載入。利用資料的區域性有序性按需載入，能夠極大減少資料合併過程中的記憶體消耗。

#### **Idle schedule**

在實際執行過程中，由於部分 Compaction 任務佔用資源多、耗時長，經常出現因為 Compaction 任務影響查詢效能的 Case。這類 Compaction 任務一般存在於 Base compaction 中，具備資料量大、執行時間長、版本合併少的特點，對任務執行的實時性要求不高。在新版本中，針對此類任務開啟了執行緒 Idle Schedule 特性，降低此類任務的執行優先順序，避免 Compaction 任務造成線上查詢的效能波動。

### 易用性

在 Compaction 的易用性方面，Doris 2.0.0 版本進行了系統性最佳化。結合長期以來 Compaction 調優的一些經驗資料，預設配置了一套通用環境下表現最優的引數，同時大幅精簡了 Compaction 相關引數及語義，方便使用者在特殊場景下的 Compaction 調優。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d7fd8ece1d3e4913b5882ff7146df8c6~tplv-k3u1fbpfcp-zoom-1.image)

# 總結規劃

透過上述一系列的最佳化方式， 全新版本在 Compaction 過程中取得了極為顯著的改進效果。在 ClickBench 效能測試中，**新版本 Compaction 執行速度** **達到 30w row/s，相較於舊版本** **提升** **了** **50** **%** **；資源消耗降幅巨大，** **記憶體佔用僅為原先的 10%** 。高併發資料匯入場景下，Compaction Score 始終保持在 50 左右，且系統表現極為平穩。同時在時序資料場景中，Compaction 寫放大係數降低 90%，極大提升了可承載的寫入吞吐量。

後續我們仍將進一步探索迭代最佳化的空間，主要的工作方向將聚焦在自動化、可觀測性以及執行效率等方向上：

1.  自動化調優。針對不同的使用者場景，無需人工干預，系統支援進行自動化的 Compaction 調優；
1.  可觀測性增強。收集統計 Compaction 任務的各項指標，用於指導自動化以及手動調優；
1.  並行 Vertical Compaction。透過 Value 列併發執行，進一步提升 Vertical Compaction 效率。

以上方向的工作都已處於規劃或開發中，如果有小夥伴對以上方向感興趣，也歡迎參與到社群中的開發來。期待有更多人參與到 Apache Doris 社群的建設中 ，歡迎你的加入！

# 作者介紹：

一休，Apache Doris contributor，SelectDB 資深研發工程師

張正宇，Apache Doris contributor，SelectDB 資深研發工程師

**# 相關連結：**

**SelectDB 官網**：

https://selectdb.com

**Apache Doris 官網**：

http://doris.apache.org

**Apache Doris Github**：

https://github.com/apache/doris

資源消耗降低 90%，速度提升 50%，解讀 Apache Doris Compaction 最新最佳化與實現

相關文章