百度搜尋內容HTAP表格儲存系統

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

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

以下我們將主要介紹在百度內容HTAP表格儲存系統設計落地中的一些技術思考，文中的優劣歡迎各位積極交流探討。

整套儲存設計需要解決的核心問題是——如何在OLTP儲存系統中支援OLAP workflow？OLAP workflow在OLTP儲存系統上帶來的兩個最主要的問題是：嚴重的IO放大率、存算耦合。

• 嚴重的IO放大率。IO放大率主要來自兩方面，如下圖，資料行篩選、資料列篩選。

△圖2.1

• 存算耦合。存算耦合主要來自兩方面，如下圖，儲存節點資源冗餘、儲存空間放大。

△圖2.2 Node

△圖2.3

如上架構設計圖，可將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）的彈性資源，解決資源常駐冗餘問題。

結合上面的分析以及設計思路，已有效地解決了存算耦合問題。在本節中，我們將重點介紹解決IO放大率問題的一些最佳化思路。

2.2.1 資料行分割槽

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

△圖2.6

資料行分割槽的思想在OLTP和OLAP儲存引擎中都有使用，OLTP儲存引擎以資料行分割槽構建的資料檔案可直接被OLAP儲存引擎載入，減少了OLAP儲存的資料構建工作。

資料行分割槽在Write、Read、Scan場景下的處理流程分別為：

在業務儲存支援時，合理設定資料行分割槽，可極大減少資料行篩選過程中的IO放大率。

2.2.2 增量資料篩選

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

△圖2.7 LSMT

2.2.3 動態列結構

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

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

△圖2.8

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

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

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

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

為此我們為HTAP表格儲存系統構建了一套計算與排程系統，系統兩大特點：任務開發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;

當前HTAP表格儲存系統已在全網網頁資料離線加速、AI模型訓練資料管理、圖片儲存以及各類線上離線業務場景落地，資料儲存規模達>15P，業務提速>50%。

與此同時，隨著大模型時代的到來，對儲存系統帶來了更多的挑戰，我們也將繼續深度最佳化，設計更高效能、高吞吐的HTAP表格儲存系統。