本文主要介紹百度搜索內容存儲團隊應對海量互聯(lián)網數(shù)據(jù)分析計算需求時，在構建HTAP表格存儲系統(tǒng)方向上的一些技術思考。

GEEK TALK

01

業(yè)務背景

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

原有架構底層存儲系統(tǒng)普通采用百度自研表格存儲（Table）來完成數(shù)據(jù)的讀、寫、存工作，此存儲系統(tǒng)更偏向于OLTP業(yè)務場景。隨著近幾年大數(shù)據(jù)計算、AI模型訓練的演進，對存儲系統(tǒng)OLAP業(yè)務場景的依賴越來越重，如數(shù)據(jù)關系分析、全網數(shù)據(jù)分析、AI樣本數(shù)據(jù)管理篩選。在OLTP存儲場景的架構下，支持OLAP存儲需求對資源成本、系統(tǒng)吞吐、業(yè)務時效帶來了巨大挑戰(zhàn)。為此我們在百度自研表格存儲之外，結合業(yè)務實際workflow針對性優(yōu)化，增加構建了一套符合業(yè)務需求的HTAP表格存儲系統(tǒng)。

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

GEEK TALK

02

存儲設計

2.0 需求分析

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

嚴重的IO放大率。IO放大率主要來自兩方面，如下圖，數(shù)據(jù)行篩選、數(shù)據(jù)列篩選。

數(shù)據(jù)行篩選。在表格存儲中，數(shù)據(jù)按照主鍵從小到大排列，OLAP workflow根據(jù)條件篩選過濾出符合條件的數(shù)據(jù)行，會帶來嚴重的IO放大。

數(shù)據(jù)列篩選。表格存儲是寬表結構，業(yè)務在一次查詢中只會獲取部分列，但數(shù)據(jù)是以行結構保存，需要獲取整行再提取出需要的字段，依舊會帶來嚴重的IO放大。

△圖2.1

存算耦合。存算耦合主要來自兩方面，如下圖，存儲節(jié)點資源冗余、存儲空間放大。

存儲節(jié)點資源冗余。在一個存儲節(jié)點中，OLTP vs OLAP占用的計算資源占比是3:7，為滿足OLAP需要，就需要對存儲節(jié)點進行擴容，然而存儲節(jié)點的擴容又不僅僅是計算資源。同時，OLAP任務是間歇性的，就會造成忙時供給不足，閑時資源冗余等情況。

存儲空間放大。為支持每一個OLAP任務的數(shù)據(jù)訪問，存儲引擎需要為每一個workflow創(chuàng)建對應的Snapshot，保證workflow完成前所依賴的所有數(shù)據(jù)文件均有效。當OLAP workflow耗時過長時，會導致Compaction后數(shù)據(jù)文件無法及時清理的情況，造成存儲空間放大。

△圖2.2 Node

2.1 架構設計

△圖2.3

1.架構采用業(yè)界HTAP主流設計思想，將OLTP和OLAP workflow拆分到兩套存儲系統(tǒng)中，如F1 Lightning、ByteHTAP，在SDK層根據(jù)任務類型分發(fā)到不同的存儲系統(tǒng)中。

2.OLTP存儲系統(tǒng)——Neptune，采用Multi-Raft分布式協(xié)議組建存儲集群，采用本地磁盤（SSD/HDD等） + 百度分布式文件系統(tǒng)?AFS組成存儲介質。

3.OLAP存儲系統(tǒng)——Saturn，Serverless?設計模式，無常駐Server，即用即加載，貼合OLAP workflow的不確定性和間歇性。

4.OLTP與OLAP存儲系統(tǒng)間，采用數(shù)據(jù)文件硬鏈的方式進行數(shù)據(jù)同步，全版本替換，成本低、速度快，充分貼合Saturn Serverless設計模式。

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

解決存儲空間放大問題?？臻g放大主要帶來的問題是存儲節(jié)點成本，Workflow分離的架構將OLAP需要的數(shù)據(jù)文件采用AFS低成本存儲，減少了對存儲節(jié)點存儲空間的壓力。

△圖2.4

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

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

△圖2.5 Saturn Serverless模型

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

2.2 存儲引擎優(yōu)化思路

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

2.2.1 數(shù)據(jù)行分區(qū)

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

△圖2.6

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

數(shù)據(jù)行分區(qū)在Write、Read、Scan場景下的處理流程分別為：

1.Write操作。Write時會根據(jù)請求中的特殊Region描述，如分區(qū)鍵，找到需要寫入的Region-Index和Region上下文，前者保存Key的分區(qū)索引信息，后者中保存實際數(shù)據(jù)，操作記錄由WAL中保存。

2.Read操作。Read操作相比通常直接訪問數(shù)據(jù)，需要多進行一次分區(qū)索引訪問，為減少多一次訪問帶來的性能折損，我們將分區(qū)索引信息全內存化。由于索引數(shù)據(jù)非常小，因此全內存化是可接受的。

3.Scan操作。Scan操作相比之下沒有任何變更，但在Scan特殊分區(qū)場景下可大量減少IO放大。因為相比之前的行過濾模式，可直接跳過大量不需要的數(shù)據(jù)。

在業(yè)務存儲支持時，合理設置數(shù)據(jù)行分區(qū)，可極大減少數(shù)據(jù)行篩選過程中的IO放大率。

2.2.2 增量數(shù)據(jù)篩選

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

△圖2.7 LSMT

2.2.3 動態(tài)列結構

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

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

△圖2.8

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

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

GEEK TALK

03

計算與調度

在本節(jié)，我們將介紹在此HTAP表格存儲系統(tǒng)基礎上，如何設計實現(xiàn)任務計算和調度系統(tǒng)，簡化業(yè)務使用成本，提升業(yè)務效率。

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

為此我們?yōu)镠TAP表格存儲系統(tǒng)構建了一套計算與調度系統(tǒng)，系統(tǒng)兩大特點：任務開發(fā)SQL化、數(shù)據(jù)處理FaaS化。

3.1 SQL化與FaaS化

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

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

function classify = { #定義一個Python FaaS函數(shù) 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 # 利用存儲分區(qū)特性，從my_table中的timeliness分區(qū)獲取數(shù)據(jù) where timestamp between @ts_beg and @ts_end # 利用存儲增量區(qū)間特性，篩選增量數(shù)據(jù) filter by function@classify（@cf0:types， @ids） # 在Filter階段調用自定義FaaS函數(shù) convert by json outlet by row; desc： # 對計算框架進行特殊描述 --multi_output=true;

3.2 任務生成與調度

1.任務生成。在任務生成階段將KQL語句解析優(yōu)化成相關的調度任務，一個Job包含多個Task。

2.任務調度。

任務調度的計算節(jié)點可以是Map-Reduce，也可以是自研計算集群Pioneer，負責不同計算場景。

任務運行容器負責數(shù)據(jù)依賴部署和運行計算框架。

計算框架采用插件化設計思想，依托KQL語言進行差異化描述。計算框架的最大特點是，可在數(shù)據(jù)處理節(jié)點執(zhí)行用戶自定義FaaS函數(shù)。

GEEK TALK

04

總結

當前HTAP表格存儲系統(tǒng)已在全網網頁數(shù)據(jù)離線加速、AI模型訓練數(shù)據(jù)管理、圖片存儲以及各類在線離線業(yè)務場景落地，數(shù)據(jù)存儲規(guī)模達》15P，業(yè)務提速》50%。

與此同時，隨著大模型時代的到來，對存儲系統(tǒng)帶來了更多的挑戰(zhàn)，我們也將繼續(xù)深度優(yōu)化，設計更高性能、高吞吐的HTAP表格存儲系統(tǒng)。