百度基于云原生的推薦系統設計與實踐
一、云原生技術棧
下圖是 CNCF 公布的云原生基礎架構的抽象圖。
典型的云原生技術棧可分為四層:供給層(Provisioning)、運行時層(Runtime)、策劃和管理層(Orchestration & Management)以及App定義和開發層(App Definition & Development)。還包括一些可觀測性和分析的基礎設施,比如監控、日志、調用追蹤、混沌工程。
我們要做的,就是在推薦系統上,利用好 cloud native 的這幾層架構,來實現基礎技術能力。早期 cloud native 有些基礎設施還沒有完善,因此部分公司在搭建推薦系統時,部分基礎設施是自建的。后期,在 cloud native 技術完善之后,在設計推薦系統時,就會基于 cloud native 的技術棧來進行模塊設計。無論是哪一種形式,都要對云原生的技術棧和推薦系統的基礎架構有比較深入的了解,才能做到較好的融合。
二、推薦系統架構
推薦系統的技術架構,可以分為在線和離線部分。
離線部分通常做內容建模,數據引入時,通常做內容建模,例如內容生態和合作數據引入。我們對這些數據進行內容處理,如標簽化、標簽特征抽取、向量化(即根據一些模型把 Doc 數據轉化為向量)。對于用戶數據,例如用戶點展、共享和分享這些用戶行為,我們會對其進行數據挖掘和用戶畫像、Attention 抽取等,并且對用戶的屬性也進行向量化。在此基礎上,將用戶的推送或相關性、關聯性等 doc 維度的屬性進行召回和排序,最終進行展現。
流量方面,在天級范圍內體現出明顯的潮汐現象。比如在晚高峰流量高,低谷期流量低。
三、基于云原生的推薦系統設計重點
針對推薦系統的特點,在設計時需要從三個層次建設基礎能力和業務架構。第一層,需要構建好云原生的基礎設施,包括 PaaS、事件機制、服務編排、服務畫像、指標采集等;在此基礎上,是第二層,云原生能力的建設,包括構建 ALM 的全生命周期管理、容量管理,SaaS 方面的資源管理、調度機制,以及流量管理、混沌工程穩定性等等;最終體現在第三層業務價值上,包括降低成本、提升研發效率、保證穩定性、提升業務效果和提升性能。
接下來重點介紹四個方面:虛擬化和微服務化改造,服務治理和彈性建設,基于云原生能力的推薦業務應用以及穩定性建設。
1. 虛擬化和微服務改造
虛擬化技術是云原生系統中最基礎的部分,本質上是軟硬件的技術棧。硬件輔助虛擬化方案(Hardware virtualization,HVM),主要利用 CPU 等硬件輔助處理敏感指令,以實現完全虛擬化功能,無需修改客戶端操作系統。
VMware Workstation,Xen,KVM 產品或架構都是應用了該技術,當前市場中幾乎所有主流硬件都是支持硬件輔助虛擬化技術的。
最常見的虛擬化落地方式是 KVM 技術,通過處理敏感指令,實現 CPU、內存和 IO 的虛擬化技術。
另一個趨勢是 GPU,在推薦系統中日益盛行,主要用于模型訓練、在線推理等一系列高密度復雜計算。GPU 顯存大、計算能力強,需要對其進一步虛擬化切分,使業務能夠以更低的成本使用,獲得高效的運算效果。
虛擬化構建之后,必不可少的步驟是微服務的改造。微服務化改造是精細化調度和服務資源運營的基礎。以百度為例,早期業務流量增長迅猛,對研發迭代的效率要求極高,早期實現方式為巨型服務,每個業務模塊功能變復雜后,功能依然在模塊內部實現,導致開發迭代變得越來越困難。隨著模塊逐步龐大,會發現一臺機器上的部分資源被占滿,而部分資源空閑,因此需要進行微服務化改造。比如預估層,抽出 CTR 預估、時長預估等,將服務拆解。
微服務化拆分的目標是無巨型服務和可遷移服務。無巨型服務,即約束服務的資源顆粒度。同時做到可遷移,即各服務實現實例自動化遷移。可遷移除了常見的擴容外,還有服務實例自愈。比如當整機出現熱點,或當服務模塊出現異常時,能快速探測,并實現自愈。
拆分的原則包括:按策略、業務流程拆分,按組織團隊拆分,以及通用服務平臺化。
一個典型的推薦系統服務改造方式為,將一些巨型服務,如用戶模型、內容數據、索引排序等,進行額外的抽象,進行獨立的平臺化處理,即通過 RPC 訪問外部服務,使其從原本的推薦服務中抽離出來。
構建通用服務框架,通過組件式的開發構建可組裝的策略組件。包括業務模塊、架構模塊。其中架構模塊即一些可復用的基礎模塊,比如 Filter 或一些基礎函數,還包括一些策略算子,如 CTR、Rank 等,以算子庫的形式提供給業務,進行拼裝式的使用。
常用的一種拼裝方式是 DAG 引擎。通過一些配置文件,即可將整個代碼邏輯組裝起來。
2. 服務治理和彈性建設
應用生命周期管理(ALM)的目標是通過服務治理,讓所有的服務都保持在合理的運行狀態下,確保資源利用健康度,可檢測、可干預。服務治理的能力和效率,是架構可持續發展的關鍵因素,其基礎依賴就是容器編排、虛擬化的支持,在此基礎上通過對基礎參數和性能參數的采集,進行服務編排。同時,還要做到可觀測性。
通過 ALM 采集的數據,可以對服務進行統一、標準化地治理,實現對資源的合理利用。但有些服務,其資源利用率并不是隨 QPS 增長而線性增長的,不同服務對利用率的容忍率也不同。因此,我們構建了以服務畫像為中心的云原生技術。
根據每個服務的極限負載個性化地設置合理容量,實現系統成本全局最優。基于服務的機型偏好的調度策略,實現資源最優配置,提升系統性能。摒棄傳統固定容量模式,動態調整服務容量,實現資源按需分配。
針對負載波動差異大,彈性等級差異大和負載容忍度差異大等問題,通過不同類型的畫像來構建彈性能力。比如在線場景中晚高峰流量大,push 場景中新熱點流量會明顯上升,對于不同的服務構建個性化流量畫像來描繪其波動特性。另外,從存儲和計算兩個維度對各個服務的彈性進行打分,以此作為彈性伸縮的依據。
通過 Metric agent、Data Polling 等數據采集,離群值處理、缺失值填充以及數據聚合等預處理方法,構建多維度服務畫像。
基于畫像構建個性化的 ALM quota resize 架構,通過預縮容、反饋和熔斷機制、步進式調整控制流程等方法保障穩定性。
基于畫像的 serverless,是一種基于流量預測的彈性伸縮策略,可以進行提前預判 & 負載反饋兜底。依托 STL、LSTM 等時序算法模型進行流量預測。通過主動預測、提前預判、監控負載、主被動結合的方式,構建兼顧穩定性和成本的安全彈性機制。
上圖中展示了預測效果。可以看到預估誤差為 4%,相較于簡單規則的 18%,具有明顯優勢。
3. 基于云原生能力的推薦業務應用
釋放出來的資源可以用于額外的計算,以獲得更多收益。
推薦產品不依賴用戶的主動輸入,多數用戶的“興趣”長期穩定。Nearline 召回機制是介于在線離線之間的一類全新召回方式,容忍秒級延遲,有更大的計算規模和復雜度,可以使用碎片資源和閑置資源,降低機制成本。
通過異步計算的方式,與在線計算解耦,根據系統負載主動計算,可以提前計算獲得預估結果,提升效果。根據資源情況,動態調整計算參數,實現資源平穩與充分利用。
4. 穩定性建設 - 混沌工程
混沌工程在 2018 年由 CNCF 提出,是??新興的技術學科,通過實驗性的?法,讓?們建?對于復雜分布式系統在?產中抵御突發事件能力的信心。
傳統的穩定性工作,建立在歷史 case 和工程師經驗基礎上,是一個(發生故障->解決問題->下次發生故障)的循環。系統經過重構升級后,穩定性能力可能無法持續。
混沌工程的整體目標是通過實驗主動驅動代替過去的 case 被動驅動,在可控范圍內周期性注入故障,主動發現系統隱患,驗證穩定性能力,推動架構迭代優化。
混沌工程的主要機制是通過紅藍對抗機制進行故障的隨機預演練。通過對故障場景編排和自動化巡檢,利用韌性指數把穩定性進行量化。
基于歷史問題抽象故障庫,建立可量化的穩定性評價體系,引入韌性信心指數規范,混沌實驗周期性巡檢,更新韌性指數,驅動架構優化。