一、大規模數據報表生產的挑戰與訴求

首先和大家分享百度商業數據產品及其對數據平臺的訴求。

1、百度商業數據產品矩陣介紹

以上百度商業矩陣主要體現其核心商業產品和數據形式：

• 百度核心商業數據產品，主要包括用于網站埋點統計和全流程托管分析的百度統計，反映詞匯趨勢熱度及分析洞察的百度指數，支撐廣告主追蹤熱點并完成投放決策的觀星盤，以及其他面向產品、銷售、運營等人員的數據產品；
• 成體系化的數據流轉，一是 B 端廣告主投放廣告的物料數據和投放行為日志，二是 C 端用戶訪問、搜索及消費相關的行為日志。兩端數據經過用商一體的加工分析流轉到各個數據產品后以豐富多樣的形式呈現。

2、百度商業數據產品背后的大數據體系演進歷史

從 08 年到現在的 15 年時間內，百度商業數據產品背后的大數據體系已經經過了四個階段的演進。第一個階段為單一業務時代，主要基于 MR 和 Linux 的定時任務，支撐小規模的產品孵化，技術相對老舊。第二個階段進入多元業務時代，面向不同角色的產品矩陣逐漸出現，逐漸開始封裝研發框架、調度系統等，進入小規模的 DevOps 迭代。第三階段開始平臺化試水，為解決數據一致性和產品割裂問題，嘗試數據產品一盤棋，將數據任務開發運維全面托管并建立標準化的 DataOps。第四階段在確定 DataOps 體系有效后，將百度商業數據產品全面托管，幫助業務實現架構現代化。

3、大規模報表生產背后的數據挑戰

經過分析總結，百度商業數據產品在集團內部主要面臨以下三類挑戰：

• 海量數據：百度具有數萬份的數據集、數十萬條數據血緣關系、每天數萬次例行計算，海量數據形成復雜的拓撲網絡在管理上帶來挑戰，一體化的數據平臺統一納管便于數據及血緣的查找和追蹤。
• 數百名數據開發工程師：開發豐富的數據產品需要大量的高成本數據開發工程師，企業會產生高昂的用人成本，便捷高效的輔助開發產品或平臺能為生產提效，節省人力成本達到降本增效的目的。
• 數萬個核心報表指標和數十個商業產品出口：大量的指標和出口產品一旦發生故障都需要能快速解決修復，清晰的血緣管理能高效輔助問題定位和排查分析，提高數據及產品的交付質量和用戶滿意度。

4、大規模報表生產對數據平臺的訴求

面對數據挑戰，百度數據平臺通過建設大規模穩定可靠的流水線數據報表生產鏈路，解決相關訴求，其核心建設思路和目標主要包括以下兩點：

• 提升研發效率：通過統一流程、統一技術棧、統一研發套件形成生產級的流程規范，解決各個產品線數據源的基礎設施割裂帶來的效率問題和規范問題；
• 優化產出穩定性：通過建設監控能力、運維能力、治理能力等一系列開箱即用的套件，解決面對大規模數據和任務手工無法解決的延遲多、恢復慢、優化難等穩定性隱患。

下面，重點分享全流程 DataOps 的設計思考。

二、全流程 DataOps 的設計思考

1、面向大規模數據報表生產的分層架構

一般來說，在做數據產品交付時，我們會采用分層設計的方式，百度的數據分層架構主要分為：原始數據層、數倉層、指標層、報表層，各層之間通過統一制品的技術中間件銜接。如果將數據生產類比為一般的工業生產，那么分層架構可以看作統一操作規范的生產流水線，統一制品的技術中間件可以看作統一標準規格的生產工具，兩者結合保證了數據報表生產的質量和效率。

2、如何選型

面向統一的分層架構，如何選型以實現流水線的生產和高效運維呢？不同于傳統的完全割裂的開發運維方案，DevOps 通過任務調度平臺和一些數據功能的拼湊實現統一業務框架，DataOPs 則以數據為視角，重塑全流程，實現數據生產流水線，因此DataOps理念更符合我們對統一平臺的設想和預期。

3、面向大規模數據報表生產的DataOps平臺設計思考

DataOps 以數據為視角，不僅要實現數據研發流程托管，還需要考慮數據治理、任務監控與運維，保證數據生產的全流程在一個平臺內完成，平臺也貫穿數據和報表的全生命周期。

4、面向大規模數據報表生產的 DataOps 流水

百度將流水線生產與開箱即用能力的 DataOps 理念落地到 DataBoot 平臺，實現了數據端到端開箱即用的監控運維與治理能力，覆蓋從數據的引入到使用過程數據接入層、加工層、網關層所有的處理套件與能力，見證了從原始數據到報表制品的轉化。

5、商業數據產品 DataOps 平臺- DataBoot 整體介紹

DataBoot 統一平臺基建基于百度的 IaaS 和 PaaS 平臺，構建相關的流程工具套件如集成、建模、開發、運維、監控等，結合計算框架、統一網關、血緣采集探針等中間件，并基于數據血緣建設包括全鏈路運維、全鏈路可觀測性、全局監控分析等進階治理能力。

三、全流程 DataOps 平臺化實踐

1、開發環節-大數據任務開發一站式 WebIDE 套件

在開發環節，我們基于 Monaco 搭建輕量級數據開發 WebIDE，通過代碼和配置并結合 jar 包支撐數據開發。在此基礎上，打通百度 Icode 代碼管理平臺保證代碼不丟不漏實現代碼提交，打通各種計算集群使用戶無需自己搭建環境在 Web 實現作業調試，最后通過調度平臺實現作業上線。

整個數據任務開發 WebIDE 套件將數據集成加工的各種資源和插件打包形成SaaS服務，其中插件即數據集成與加工場景的各種能力，如集成插件、開發框架插件等。

2、部署環節

• 彈性可擴展 Serverless 部署架構。

任務部署的目標是屏蔽與數據處理無關的流程與設施，使部署過程對用戶無感，百度Serverless 部署架構從上到下分為控制層、服務層、計算層三層。控制層采用微服務應用部署數據集成加工能力的各種插件，通過 Driver 模塊與服務層進行交互。服務層為異步和長作業的模式，通過函數托管平臺部署，例如質量檢查，數據計算等所有服務均通過函數封裝，基于 workflow 實現函數編排，支持 corn 調度和手動觸發執行。最后計算層通過獨立集群分池部署實現不同場景不同策略的優化和彈性擴縮容資源機制。

• 服務層 Serverless 部署設計。

服務層采用 FaaS 部署，主要是基于邏輯擴展性和極致資源彈性的考慮。其中邏輯擴展性主要體現在可以基于函數粒度完成邏輯拆分與組合編排，復用通用插件和控制流插件。而極致資源彈性主要是數據報表生產的潮汐特點和突發流量資源風險需要依賴彈性擴縮容機制以快速完成資源準備和故障恢復。

• 計算層 Serverless 部署設計。

計算層支持資源池化和多租戶。部署圖中的 PoolManager 負責資源擴縮容和回收，類似 JVM GC 的功能。SessionPool 可以自動擴縮容，并且可配置化的實現不同的資源分配規則以達到任務的分級保障目的。底層的每個 K8s Pod 是一個計算實例，每個 Pod 有多個container，主 container 負責和 Spark 集群進行交互產生計算。

• 數據血緣探針織入式部署。

DataOps 全流程數據治理需要依賴于高置信的數據血緣，而傳統數據血緣采集方案一是侵入強難以落地；二是粒度難以到達字段級和算子級，僅能到表級血緣，無法滿足精確控制場景；三是準度差，復雜場景無法識別；四是時效弱，T+1 的血緣無法滿足實時管控的生產要求。

因此百度設計織入式部署模式，無需業務修改代碼即可完成實時血緣采集。首先，通過 Spark 擴展探針和 Java Agent 探針在用戶提交命令時攔截實現無侵入探針織入，其次通過探針解析語法樹和實時通信的方式回寫到服務端的存儲模塊，最后在存儲模塊通過匹配策略識別高置信血緣。

3、發布環節-數據進退場風險管控

通常在數據發布到生產環境的過程中主要存在兩種類型的問題造成嚴重生產事故。一是發布的代碼邏輯存在問題造成發布節點及下游所有任務執行異常，引發全鏈路任務雪崩。二是發布的代碼性能下降造成發布節點及下游節點數據產出延遲的連鎖效應引發全鏈路時效性退化。

針對上述風險，如何實現數據進退場的安全可靠呢？目前主要通過規避單點風險和識別數據鏈路風險的方式保證。單點風險致力于解決單個任務的異常問題，主要通過標準化的 CI/CD Pipeline 實現冒煙測試和基于歷史數據的 Mock 測試發現是否存在數據問題。鏈路風險主要基于數據血緣、冒煙測試結果、設定的 SLA 期望值和周期性任務運行統計數據以及推測算法判斷是否存在時效退化等情況，輔助用戶決策是否上線相關任務。

除了單個任務的發布以外，平臺的框架和網關的升級也存在風險，因此將平臺所有中間件依賴包以組件形式封裝，并且通過先選舉重要程度相對低的任務灰度發布，如果驗證無誤后再將線上任務全部更新到組件的最新版本。最后結合平臺化的管理功能如組件管理、版本管理等實現一定程度的風險規避。

提供端到端一體化的監控分析能力，不僅僅針對一個任務或一個數據集，而是基于血緣拓撲的基礎能力監控報表全鏈路并度量，例如計算每份數據的就緒時間和資源的分位值，根據資源的到位時間和內存及 CPU 等資源的開銷，能夠對數據延遲進行歸因和分析。

數據任務一旦發布用戶無需自研監控設施即可開箱即用的達成數據報表的全鏈路可觀測。線上化的監控能實現平臺級、產品線級、報表級、任務級、子階段等通過多層級覆蓋，輔助快速識別風險的等級快速定位問題。另外，監控分析一體化能夠自動化計算出分階段耗時，自動故障自動歸因等在提高故障定位效率的同時節約了大規模的人力投入，通過 timeline 工具套件實現數據報表的全鏈路分析，示例如下：

4、運維環節-全鏈路數據回溯能力

然而，如果源頭數據存在臟數據污染下游所有指標或報表，報表數據異常需要回溯，在沒有 DataOps 時，所有的數據回溯都需要工程師手動完成，其運維復雜度和風險都非常高，如誤操作、資源負載突增搶占、手動恢復緩慢。目前平臺提供系統云控功能，用戶完成簡單觸發即可自動完成全流程的數據回溯，做到精確追蹤、有序運行、及時恢復。

百度云控系統在租戶級別實現自動化全鏈路數據回溯，跨租戶時需要規避安全和權限風險，主要通過事件通知由具有相應權限的管理或運維人員手動觸發完成回溯。數據回溯的血緣觸發通過 Execute Engine 實現時序控制、基于計算資源的并發控制、容錯機制和監控報警等功能自動生成回溯的執行計劃并將計算任務的有序分發到計算引擎。詳細實現如下：

5、優化環節

最后，分享一些關于大數據計算在優化過程中遇到的問題和解決方案。

• 問題分析與技術思考。

傳統大數據調優方法的局限主要在三個方面，一是性能和成本的平衡，在實際業務場景下，任務的重要程度和優先級是有區別的，要考慮如何在滿足性能和產出穩定性要求的情況下，平衡資源成本，提高投入產出比；二是調優效率，Spark 作業在性能調優時復雜程度很高，長作業多輪調參消耗掉大量的時間和人力成本；三是缺乏全局視角，研發工程師往往僅能基于一個任務或一份數據進行調優，單點調優做得再完美或許也無法解全局的難題。

面臨如上問題時，百度商業數據平臺在系統設計目標層面達成統一，首先通過聲明式設計，以終為始，錨定數據報表的預期產出時間為時效性目標進行優化，減少了用戶的心智負擔。其次，完成目標生成、單點自動化調優和效果試驗比對實現流程閉環。

• 全局數據報表時效性優化實驗。

百度時效性優化系統負責將該系統設計目標和優化思路落地。主要通過設新建優化目標并基于全局優化策略生成待優化項，然后匹配系統效果數據生成試驗評估效果，并自動完成優化前后的各類指標的可視化對比分析。

• 單點聲明式動態調優。

除了全鏈路調優，百度在基于單點的聲明式動態調優也具備實踐。主要通過探針采集作業的日常開銷和實效性等指標并回傳到 Receiver 模塊存儲，然后通過 Validator 判斷調優效果是否符合預期，如果符合預期則退出，不符合則再通過 Calculator 生成策略并由Processor 實現 Spark 的動態調參，如此反復經過多輪調整后達到調優效果。

四、總結與展望

當前企業內部逐漸重視數據價值，大家發現基于數據的視角 DataOps 的理念能符合大家的預期，但是隨著大模型的普及，AIOps 勢必能夠與 DataOps 良好結合，目前百度內部也在積極的探索和實踐，期待由機器自動化識別和調用已有套件進一步實現大數據工程師生產力的飛躍。