百度搜尋萬億規模特徵計算系統實踐

02

1.『開源』：儘可能擴大計算資源池，透過採購來滿足ROI低，挖潛現有資源是關鍵。從公司整體看，資源使用並不充分，線上資源存在波峰波谷，庫存空閒資源也不少，而我們大多為離線計算，對資源穩定性要求不高，可以結合兩者，建設一套彈性計算排程系統來解決資源問題。

2.『節流』：儘可能最佳化服務效能，降低單位計算成本，模型推理計算量大，但本身有較大的最佳化空間，結合模型結構和GPU硬體特點進行最佳化，可以大幅提升模型服務單卡吞吐。此外，最佳化CPU處理、使用百度自研崑崙晶片等多種方式也能降低單位成本。

1.模型服務框架&平臺：模型工程化是透過統一的模型服務框架和配套的模型服務平臺來實現，模型服務框架和平臺支援並涵蓋從構建、測試、上線等模型服務全生命週期的各個環節。

2.特徵批次計算平臺：為了離線特徵計算效率問題，建設了統一的批次計算平臺，分析並深度最佳化從離線任務開發到計算過程中各環節的效率和效能瓶頸，儘可能地提升效率。

3.1 整體架構

1.模型服務框架：演算法同學使用統一的模型服務框架進行服務封裝，基於研發效率考慮，選擇Python作為框架語言，但Python效能問題也很明顯，因此需要做很多針對性最佳化。此外，我們也在框架持續整合多種推理最佳化手段，儘可能地降低服務單位計算成本 。

2.模型服務平臺：模型服務平臺支援模型服務DevOps和能力輸出，平臺以『運算元』作為管理粒度，『運算元』代表一種完整功能，如影片分類等，它通常需要多個模型服務組合使用。演算法同學在平臺註冊運算元，提供服務拓撲等元資訊，也透過自動效能調參、自動化壓測等生成效能報告，服務拓撲和效能報告是後續排程的重要輸入。平臺也提供運算元檢索、調研試用等功能，以中臺化方式支援其他業務需求。

3.計算排程系統：計算排程系統做流量和資源的統一排程，所有對模型服務的請求都會經過計算排程系統的閘道器，執行流控和路由等流量策略，計算排程系統也會排程百度多個PaaS的多種空閒異構資源，自動化部署合適的運算元，給離線計算提供更大吞吐。

4.批次計算平臺：批次計算平臺支援離線作業的任務生成、任務排程、DevOps等功能，建設基於HTAP的儲存方案，解決Scan吞吐瓶頸問題，並聯動計算排程系統，支援大規模離線計算。

3.2 技術關鍵點

• 將業務邏輯描述成DAG（有向無環圖），DAG上的節點稱為Op，DAG有多個Op組成，Op之間存在串聯和並聯關係，一個OP可以是模型推理或者一段處理邏輯，Op之間透過資料白板進行上下文傳遞。透過DAG能清晰地呈現整體處理流程，提升程式碼可讀性和可維護性。

• 建設通用Op庫，像模型推理、影片抽幀、影片轉換等通用邏輯被整合成通用Op庫，支援業務複用。業務也可根據需要，定製擴充套件Op，並註冊到框架使用。

• 採用多程式+非同步協程+CPU/GPU計算分離的併發方案，服務包含三類程式：RPC程式、DAG程式、模型程式，它們之間透過共享記憶體/視訊記憶體進行資料互動。

• PRC程式負責網路通訊，基於BRPC開發（開源版本：），我們最佳化了BRPC的Python實現，使其支援Python多程式和協程的併發模式，在實際業務場景測試下，最佳化後效能提升5倍+。

• DAG程式負責DAG執行（CPU處理），透過多DAG程式和Op執行非同步協程化來充分利用CPU多核。另一個比較重要的是ModelOp，它實際是推理代理（類似RPC），真正推理是在本地模型程式或者遠端服務執行，ModelOp遮蔽了呼叫細節，支援使用者方便地使用模型。

• 模型程式負責模型推理（GPU處理），考慮視訊記憶體有限等原因，模型程式和DAG程式分離獨立，模型程式支援Pytorch、Paddle等多種推理引擎，並做了很多推理最佳化工作。由於Tensor資料通常較大，DAG和模型程式傳輸Tensor直接使用共享視訊記憶體，避免不必要的記憶體複製。

1.推理排程：動態批次處理（DynamicBatching）和多Stream執行。GPU批次計算效率更高，由於服務也接受實時單條請求，沒法請求時拼Batch，因此採用服務內快取拼Batch，犧牲時延換吞吐。Stream可看做GPU任務佇列，預設全域性單條，任務序列執行，會出現GPU IO操作（記憶體視訊記憶體互拷）時，計算單元閒置，透過建立多Stream，不同推理請求走不同Stream讓IO和計算能充分並行。

2.推理最佳化：業界主流方案是使用TensorRT，但是實際應用會有動態圖靜態化失敗、TensorRT Op覆蓋不全等問題。為解決這些問題，團隊自研Poros（開源版本：https://github.com/PaddlePaddle/FastDeploy/tree/develop/poros），結合TorchScript、圖最佳化、TensorRT、vLLM等技術，實現無需複雜模型轉化，新增幾行程式碼即可大幅提升推理效能，效率和效能雙贏，同時Poros也支援崑崙等異構硬體。

3.模型量化：GPU、崑崙等硬體對低精度都有更強的算力，量化雖有少量效果損失，但帶來大幅吞吐提升，因此，上線都會採用FP16乃至INT8/INT4量化，這部分也是透過Poros支援。

4.模型壓縮：透過模型蒸餾、模型裁剪等方法精簡模型引數，減少計算量，但是需要訓練，且效果有損，通常和演算法同學一起合作最佳化。

1.CRD擴充套件：利用K8S CRD來自定義ServiceBundle（運算元部署包）等物件，透過controller機制讓在PaaS等外部系統執行部署等操作。ServiceBundle包含了運算元需要的所有子服務部署資訊，以及其拓撲關係。排程建立運算元服務時，會從最底層開始逐層建立子服務，上層子服務可以透過通訊託管機制獲得下游子服務地址。

2.通訊託管：通訊託管機制是基於配置中心和模型服務框架實現，服務啟動命令會帶有遠端配置地址和AppID，透過載入遠端配置可以實現下游服務地址啟動時變更。其實更理想方案是使用ServiceMesh等技術將架構能力和業務策略解耦，但考慮我們要在多PaaS部署，而在各個PaaS都部署ServiceMesh SideCar等元件成本較高，整合到框架又過於重，因此，先建設基於配置中心的方案，後續時機成熟再考慮遷移。

1.運算元排程：運算元（複合服務）可承載流量取決於其最短板的子服務容量，排程時需要整體考慮，避免長板服務資源浪費。

2.流量分佈變化：部分運算元的效能會受輸入資料分佈影響，如影片OCR會受影片時長、畫面文字比例影響，排程時需要自適應調整。

3.多異構硬體：運算元有些能支援多種異構硬體（崑崙/GPU/CPU等），有些只能繫結一種，怎麼分配才能保證全域性資源最有效利用。

4.其他因素：作業優先順序、資源優先順序、資源波動等因素也都會影響排程，實際排程要考慮的因素非常多元化。

1.兩階段排程：分流量排程和資源排程兩階段，各自獨立排程。流量排程負責對當前運算元服務容量分配到各個作業，並結果同步到閘道器，調整流量策略；資源排程負責根據資源空閒情況和運算元容量缺口等進行排程，最終對運算元服務例項進行擴縮容。

2.流量排程：流量排程Adjust階段會根據任務執行指標等調整歸一化係數，再用係數將任務所需Qps對映成NormalizedQps，NormalizedQps是後續所有排程的依據，從而解決流量分佈變化影響問題。在Sort階段會根據作業優先順序等排序，在Assign階段會根據Sort結果，按優先順序將現有運算元容量分配到各個作業。Bind階段會將結果執行，同步路由等到閘道器。

3.資源排程：資源排程Prepare階段會先將作業的容量缺口轉換成對應服務例項數缺口；接著進行HardwareFit，將要擴容的服務分配到合適的硬體資源佇列，並根據資源稀缺性、計算價效比等進行Sort；然後進行PreAssign，對各子服務進行資源預分配，最後GroupAssign階段考慮複合服務的各子服務排程滿足度，對複合服務的各子服務容量進行細調，避免資源浪費。

1.讀寫混合：OLTP（抓取更新等）和OLAP（特徵批次計算等）需求都訪問Table，多種讀寫方式混合，而底層採用HDD儲存，大量讀寫混合使磁碟IO吞吐嚴重下滑

2.Scan放大：Table採用寬表結構儲存，不同任務Scan時通常只需要其中的某幾列，但Table Scan時需要讀取整行資料再過濾，IO放大嚴重。

3.擴容成本高：由於OLTP和OLAP混合讀寫，要為Scan單獨擴容成本高，同時因讀寫比例難以固定，也很難預估擴容資源。

1.OLAP/OLTP儲存分離：針對批次計算等OLAP場景建設高效OLAP儲存，減少因OLAP/OLTP混合使用Table帶來的讀寫混合問題，也可根據需求單獨擴容。

2.高效OLAP儲存設計：自研OLAP儲存基於Rocksdb、AFS（百度類HDFS）構建，採用增量同步、行資料分割槽、列資料動態合併儲存的設計，將Table全量資料劃分成N個資料物理分割槽，利用Table的增量Snapshot定期高效同步更新OLAP儲存資料（由於Table底層採用LSM儲存，增量Snapshot效率遠高於全量Scan）。列儲存根據欄位訪問熱點重新組織，將熱點列在物理層一起儲存，降低IO放大，也支援動態調整。方案會存在資料同步延時問題，但在我們場景，時效性要求不高，問題可以忽略。

3.HTAP SDK：提供統一的SDK同時支援對Table和OLAP儲存訪問，使用者基於SDK可以同時執行自己的OLAP和OLTP任務。

• 配置化：針對通用並頻繁使用的任務型別，平臺對這些任務進行高度封裝，只需要在Web介面上配置即可生成任務。

• KQL：KQL是自研的類SQL語言，提供多種通用函式，並支援自定義函式（類似Spark UDF），使用者可以透過KQL查詢和處理資料。

• 離線框架：框架提供包括資料讀寫、通用轉換等功能，使用者按照框架規範自定義邏輯並生成離線任務部署包提交平臺，平臺進行任務排程。