海量存儲的批量計算框架詳情 - 百度,海量數據百度Geek説博客

導讀

本文介紹了百度針對海量存儲數據計算需求研發的HTAP表格存儲系統及計算調度架構。項目背景源於原有存儲系統難以滿足日益增長的OLAP業務需求，因此構建了集OLTP與OLAP於一體的HTAP系統，通過存算分離、Serverless設計等創新點提升IO訪問能力和資源利用率。同時，自研的計算與調度系統實現了任務開發的SQL化和數據處理的FaaS化，簡化了業務使用成本，提高了開發效率。整體方案在存儲成本、IO能力、IO放大率等方面取得顯著成果，為海量存儲數據的計算提供了高效、靈活的解決方案。

01 項目背景及目標

1.1 項目背景

搜索內容存儲團隊主要負責各類數據，如網頁、圖片、網頁關係等，的在線存儲讀寫(OLTP)、離線高吞吐計算(OLAP)等工作。

原有架構底層存儲系統普通採用百度自研表格存儲（Table）來完成數據的讀、寫、存工作，此存儲系統更偏向於OLTP業務場景。隨着近幾年大數據計算、AI模型訓練的演進，對存儲系統OLAP業務場景的依賴越來越重，如數據關係分析、全網數據分析、AI樣本數據管理篩選。在OLTP存儲場景的架構下，支持OLAP存儲需求對資源成本、系統吞吐、業務時效帶來了巨大挑戰。為此我們在百度自研表格存儲之外，結合業務實際workflow針對性優化，增加構建了一套符合業務需求的HTAP表格存儲系統以及相應的計算框架，共同組成面向海量存儲數據的大批量計算架構系統。

1.2 項目目標

提供海量存儲數據計算的超高IO訪問能力。當前內容存儲數據達幾十P+，訪問頻率按照每週一輪估算，平均IO能力需要達到34G/s，峯值IO能力需要達到200G/s。面對如此龐大的IO訪問能力，需要從文件系統、存儲引擎、分佈式存儲系統、訪問模型等全方位進行深度優化來滿足需求；
提供海量存儲數據計算的快速開發&部署能力。在提供海量訪問能力的同時，也需要為業務提供訪問配套的基礎設施，來滿足業務開發&部署計算任務的需求。

02 現有研發條件和工作基礎

搜索內容架構存儲團負責各類數據，如網頁、圖片、網頁關係等，的在線存儲讀寫(OLTP)、離線高吞吐計算(OLAP)等工作。面對當前海量存儲數據的計算需求有清晰的技術和業務認知，第一視角明確清楚地知道系統瓶頸、技術難點、業務需求。

系統瓶頸——當前存儲系統能提供的IO能力與業務計算需求之間的矛盾。隨着大數據、機器學習、大語言模型等新技術的興起，業務對數據的計算訪問需求越來越強烈，然而存儲系統的IO能力卻一直止步不前。為此，迫切需要一款面向數據計算的存儲系統；
技術難點——數據表格存儲系統的數據訪問模型與計算模型之間的矛盾。當前架構底層存儲普遍採用百度自研表格存儲(Table)來完成數據的讀寫存工作，此存儲系統更偏向於OLTP業務場景。但隨着近幾年大數據計算、AI模型訓練的演進，對存儲系統OLAP業務場景的依賴越來越重，如數據關係分析、全網數據分析、AI樣本數據管理篩選。在OLTP存儲場景的架構下，支持OLAP存儲需求對資源成本、系統吞吐、業務時效帶來了巨大技術挑戰；
業務需求——方便高效快速的任務開發&部署能力的需要。在大量搜索內容OLAP workflow中，從表格存儲系統中提取篩選數據只佔全部任務的一小部分，大量任務需要對數據進行加工處理得到需要的結果。常規的做法是多任務串聯，這樣做的缺陷是大量中間臨時數據存儲開銷。為此我們為HTAP表格存儲系統構建了一套計算與調度系統。

03 整體方案

3.1 概覽

本項目擬研發面向海量存儲數據的大批量計算架構，主要分為兩大系統，HTAP表格存儲系統、計算&調度架構。

3.1.1 HTAP表格存儲系統

△圖2.3

架構採用業界HTAP主流設計思想，將OLTP和OLAP workflow拆分到兩套存儲系統中，如F1 Lightning、ByteHTAP，在SDK層根據任務類型分發到不同的存儲系統中；
OLTP存儲系統——Neptune，採用Multi-Raft分佈式協議組建存儲集羣，採用本地磁盤(SSD/HDD等) + 百度分佈式文件系統AFS組成存儲介質；
OLAP存儲系統——Saturn，Serverless設計模式，無常駐Server，即用即加載，貼合OLAP workflow的不確定性和間歇性；
OLTP與OLAP存儲系統間，採用數據文件硬鏈的方式進行數據同步，全版本替換，成本低、速度快，充分貼合Saturn Serverless設計模式。

如上架構設計圖，可將OLTP與OLAP workflow拆分到兩套獨立的系統中，解決上述提到的存算耦合問題。

解決存儲空間放大問題。空間放大主要帶來的問題是存儲節點成本，Workflow分離的架構將OLAP需要的數據文件採用AFS低成本存儲，減少了對存儲節點存儲空間的壓力。

△圖2.4

OLAP存儲系統的數據寫入並沒有使用常見的log redo或raft learner模式，最主要還是在保證OLAP存儲系統的Serverless特性的同時，又能實時感知到OLTP系統的最新寫入結果。

解決存儲節點資源冗餘問題。拆分後，分佈式存儲節點將大量重型OLAP workflow轉移到OLAP存儲——Saturn中，將極大減少存儲節點的計算壓力。同時，OLAP存儲的Serverless設計模式又可貼合workflow的不確定性和間歇性。

△圖2.5 Saturn Serverless模型

計算節點可以部署在任意計算集羣中，如Map-Reduce、自研計算節點Pioneer等，在SDK中直接初始化存儲引擎，從AFS中訪問對應分片的數據文件。計算節點可充分利用雲原生系統（PaaS）的彈性資源，解決資源常駐冗餘問題。

3.1.2 一次開發，多端部署

任務生成。自研KQL數據查詢語言。在任務生成階段將KQL語句解析優化成相關的調度任務，一個Job包含多個Task。
任務調度。
任務調度的計算節點可以是Map-Reduce，也可以是自研計算集羣Pioneer，負責不同計算場景。
任務運行容器負責數據依賴部署和運行計算框架。
計算框架採用插件化設計思想，依託KQL語言進行差異化描述。計算框架的最大特點是，可在數據處理節點執行用户自定義FaaS函數。

3.2 詳細介紹

3.2.1 HTAP表格存儲系統

3.2.1.1 OLTP存儲系統——Neptune

Neptune引擎主要支持四類操作：寫、刪、讀、Scan。每一類操作都通過RegionMapper進行映射，對外隔離分區概念。

Neptune存在兩類分區：索引分區、數據分區。

索引分區。索引分區用於減少因為數據分區導致Key所在數據分區不明確導致的隨機訪問IO放大問題，提升隨機查性能。
數據分區。Neptune可配置多個數據分區，每個數據分區內包含多個Locality-Group。分區間的數據理論上是互斥的。

Neptune各類操作的流程：

寫操作：
根據RowWriter中設置的Region信息找到需要寫入的Region的Handle，按照列語義將數據序列化成RawData。
同時根據Region信息生成當前Key的Region索引信息。
將RawData與RegionIndex作為一條操作記錄Commit到引擎中，整個操作為原子操作。
刪操作：
由於存在Region的概念，刪除某個Key是需要明確當前Key所在的分區。目前的做法是查詢一遍分區索引獲取分區信息，再準確刪除對應分區的數據。這樣帶來一個問題，刪除操作會增加一次分區查詢操作，我們可以考慮將分區信息全部加載到內存提升性能。
讀操作：
讀操作類似刪除操作，會首先查詢分區索引表，如果在分區索引中查詢不到則表明當前Key不存在，直接返回NotFound。否則，根據分區索引查詢對應的分區即可。
Scan操作：
Scan時業務可以指定對應的分區以及CF信息，RegionMapper根據這些信息Select出合適的物理存儲Handle，然後對這些物理存儲進行Scan。

3.2.1.2 OLAP存儲系統——Saturn

Saturn主要分三層：文件系統（File-System）、Table（表級別的抽象，非TG的Table）、訪問層（SDK），Meta-Server為每一層提供全局Meta信息支持。

文件系統。Saturn既可以支持AFS，也支持本地文件系統，同時後續可以支持其他類型的文件系統。文件系統的類型對於Saturn來説是插件化可插拔的。使用AFS作為文件系統相比於Table在成本層面有巨大優勢。
Table。一個抽象的Table包含多個Slice，理論上每個Slice間的數據是互斥的，這裏引入數據模型的概念。當前支持兩種數據模型：哈希序(hash order)、全局序(global order)，兩種模型與Table完全對等。
SDK。SDK目前支持Seek和Scan功能，使用方式跟通用的列存儲系統保持一致，SDK直接與文件系統（AFS）連接，對外提供存儲Serverless的訪問能力。

同時，Table數據的更新和構建包含兩種模式：全量構建、增量合併。

全量構建。全量構建通過完整Dump Table數據的方式對錶中的每個分片進行逐步替換，替換過程中採用多版本機制保證訪問的穩定性。
增量合併。增量合併通過控制TG Table做Major Compaction的時機，保證每次獲取增量數據前不會發生Major Compaction。增量數據通過Snapshot的形式對外提供所有的操作記錄，這些記錄保存在Table SST文件中，Saturn把這些SST文件Transform成自身協議的SST，再發起Ingest操作即可。

3.2.1.3 存儲引擎優化——數據行分區

數據行分區思想在很多OLAP存儲系統中很常見，如當前比較流行的一些數據湖架構，ClickHouse、IceBerg等。在表格存儲中，數據行分區的好處是可以極大減少在數據行篩選過程中IO放大率。以下是我們在存儲引擎中支持數據行分區的設計思路：

△圖2.6

數據行分區的思想在OLTP和OLAP存儲引擎中都有使用，OLTP存儲引擎以數據行分區構建的數據文件可直接被OLAP存儲引擎加載，減少了OLAP存儲的數據構建工作。

數據行分區在Write、Read、Scan場景下的處理流程分別為：

Write操作。Write時會根據請求中的特殊Region描述，如分區鍵，找到需要寫入的Region-Index和Region上下文，前者保存Key的分區索引信息，後者中保存實際數據，操作記錄由WAL中保存。
Read操作。Read操作相比通常直接訪問數據，需要多進行一次分區索引訪問，為減少多一次訪問帶來的性能折損，我們將分區索引信息全內存化。由於索引數據非常小，因此全內存化是可接受的。
Scan操作。Scan操作相比之下沒有任何變更，但在Scan特殊分區場景下可大量減少IO放大。因為相比之前的行過濾模式，可直接跳過大量不需要的數據。

在業務存儲支持時，合理設置數據行分區，可極大減少數據行篩選過程中的IO放大率。

3.2.1.4 存儲引擎優化——增量數據篩選

在實際業務中，有很大一個場景是獲取近期（如近幾個小時、近一天）有值變化的數據，常規的做法是Scan全量數據，以時間區間作為過濾條件，篩選出符合條件的結果。但如此的篩選邏輯會帶來嚴重的IO放大，因為滿足條件的結果只佔全量結果的一小部分。為此，我們在引擎層調整優化Compaction時機以及調整篩選流程，減少增量數據篩選過程中需要訪問的數據文件集合，降低IO放大，業務提速。

△圖2.7 LSMT

3.2.1.5 存儲引擎優化——動態列結構

在OLAP存儲引擎中，還存在一類訪問場景會帶來IO放大問題，數據列篩選。在表格存儲系統中，一個Key可以包含多個列族（Column Family），一個列族中可以包含任何多個數據字段，這些字段以行結構存儲在同一物理存儲（Locality Group）中，當篩選特定數據列時，需要進行整行讀取，然後過濾出需要的字段，這也將帶來IO放大問題。

同時，OLAP workflow的訪問不確定性導致存儲層無法及時調整數據在物理存儲中的結構。為此，我們引入動態列結構的概念，在邏輯層對業務透明，在物理層根據近期OLAP workflow特性及時調整物理結構。

△圖2.8

如上圖，在邏輯存儲中，分為兩個LG，根據workflow特性，把業務常用的訪問字段在Compaction階段存放在同一物理存儲結構中，反之，這樣可以減少字段篩選階段的IO放大率。

動態列結構只在OLAP存儲引擎中生效，我們在原有OLAP存儲中引入workflow收集以及compaction任務，將從OLTP存儲中同步的數據構建成更適合OLAP場景的存儲結構。

3.2.2 計算與調度架構

在本節，我們將介紹在此HTAP表格存儲系統基礎上，如何設計實現任務計算和調度系統，簡化業務使用成本，提升業務效率。

在大量搜索內容OLAP workflow中，從表格存儲系統中提取篩選數據只佔全部任務的一小部分，大量任務需要對數據進行加工處理得到需要的結果。常規的做法是多任務串聯，這樣做的缺陷是大量中間臨時數據存儲開銷。

為此我們為HTAP表格存儲系統構建了一套計算與調度系統，系統兩大特點：任務開發SQL化、數據處理FaaS化。

3.2.2.1 SQL化與FaaS化

我們充分貼合上述存儲系統特性，自研了一套數據查詢語言——KQL，KQL類似於SQL Server語法。同時，又結合存儲系統特性以及計算框架，支持一些特殊語言能力，最主要的是能支持原生FaaS函數定義，當然也支持外部FaaS函數包依賴。

如下是一段KQL語句例子以及説明：

function classify = { #定義一個Python FaaS函數
def classify(cbytes, ids):
    unique_ids=set(ids)
    classify=int.from_bytes(cbytes, byteorder='little', signed=False)
    while classify != 0:
        tmp = classify & 0xFF
        if tmp in unique_ids:
            return True
        classify = classify >> 8
    return False
}

declare ids = [2, 8];
declare ts_end = function@gettimeofday_us();      # 調用Native Function獲取時間
declare ts_beg = @ts_end - 24 * 3600 * 1000000;   # 四則運算

select * from my_table region in timeliness       # 利用存儲分區特性，從my_table中的timeliness分區獲取數據
where timestamp between @ts_beg and @ts_end       # 利用存儲增量區間特性，篩選增量數據
    filter by function@classify(@cf0:types, @ids) # 在Filter階段調用自定義FaaS函數
    convert by json outlet by row;
desc:                                             # 對計算框架進行特殊描述
    --multi_output=true;

3.2.2.2 任務生成與調度

任務生成與調度主要分為三層，任務解析層、任務調度執行層、任務執行容器。

任務解析層。負責將KQL表達式解析成實際的任務執行計劃，並保存在任務存儲容器中。
任務調度執行層。負責將任務計劃分發到任務執行容器，並輪訓檢測任務狀態，執行探活、重試等操作。
任務執行容器。提供兩種任務執行容器，Pioneer、EMR。前者為自研任務執行容器，後者為公司Map-Reduce執行平台。

3.3 技術經濟指標

通過上述的架構設計以及優化手段，我們在IO能力、訪問成本、開發效率等方面取得顯著成果。

04 主要創新點

4.1 自研HTAP表格存儲系統

結合業務特性以及實際需求，構建符合業務場景的HTAP存儲系統。架構採用業界HTAP主流設計思想，將OLTP和OLAP workflow拆分到兩套存儲系統中，如F1 Lightning、ByteHTAP，在SDK層根據任務類型分發到不同的存儲系統中。系統創新點如下：

存算分離架構。解決OLTP存儲系統的空間放大問題，將OLAP Workflow從OLTP存儲中分離，分離的架構將OLAP需要的數據文件採用AFS低成本存儲，減少了對存儲節點存儲空間的壓力。
OLAP Serverless設計。分佈式存儲節點將大量重型OLAP workflow轉移到OLAP存儲——Saturn中，將極大減少存儲節點的計算壓力。同時，OLAP存儲的Serverless設計模式又可貼合workflow的不確定性和間歇性。計算節點可以部署在任意計算集羣中，如Map-Reduce、自研計算節點Pioneer等，在SDK中直接初始化存儲引擎，從AFS中訪問對應分片的數據文件。計算節點可充分利用雲原生系統（PaaS）的彈性資源，解決資源常駐冗餘問題。
表格數據行分區。數據行分區思想在很多OLAP存儲系統中很常見，如當前比較流行的一些數據湖架構，ClickHouse、IceBerg等。在表格存儲中，數據行分區的好處是可以極大減少在數據行篩選過程中IO放大率。
增量數據篩選支持。在實際業務中，有很大一個場景是獲取近期（如近幾個小時、近一天）有值變化的數據，常規的做法是Scan全量數據，以時間區間作為過濾條件，篩選出符合條件的結果。但如此的篩選邏輯會帶來嚴重的IO放大，因為滿足條件的結果只佔全量結果的一小部分。為此，我們在引擎層調整優化Compaction時機以及調整篩選流程，減少增量數據篩選過程中需要訪問的數據文件集合，降低IO放大，業務提速。
表格數據動態列結構。根據workflow特性，把業務常用的訪問字段在Compaction階段存放在同一物理存儲結構中，反之，這樣可以減少字段篩選階段的IO放大率。動態列結構只在OLAP存儲引擎中生效，我們在原有OLAP存儲中引入workflow收集以及compaction任務，將從OLTP存儲中同步的數據構建成更適合OLAP場景的存儲結構。

4.2 自研任務生成與調度系統

為此我們為HTAP表格存儲系統構建了一套計算與調度系統，系統兩大特點：任務開發SQL化、數據處理FaaS化。

SQL化。我們充分貼合上述存儲系統特性，自研了一套數據查詢語言——KQL，KQL類似於SQL Server語法。
FaaS化。在SQL化的基礎上，同時結合存儲系統特性以及計算框架，支持原生FaaS函數定義能力，當然也支持外部FaaS函數包依賴。

————END————

推薦閲讀

網頁多模態建模思考

百度垂搜一站式研發平台演進實踐

初探圖譜Embedding用於異常檢測（一）

AIAPI - 轉向AI原生檢索

學校新來了一位AI作文老師：能看、會評、還教改寫

百度Geek説博客

百度Geek説博客

博客 / 詳情