一、大規(guī)模數(shù)據報表生產的挑戰(zhàn)與訴求

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

1、百度商業(yè)數(shù)據產品矩陣介紹

以上百度商業(yè)矩陣主要體現(xiàn)其核心商業(yè)產品和數(shù)據形式：

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

2、百度商業(yè)數(shù)據產品背后的大數(shù)據體系演進歷史

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

3、大規(guī)模報表生產背后的數(shù)據挑戰(zhàn)

經過分析總結，百度商業(yè)數(shù)據產品在集團內部主要面臨以下三類挑戰(zhàn)：

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

4、大規(guī)模報表生產對數(shù)據平臺的訴求

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

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

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

二、全流程 DataOps 的設計思考

1、面向大規(guī)模數(shù)據報表生產的分層架構

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

2、如何選型

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

3、面向大規(guī)模數(shù)據報表生產的DataOps平臺設計思考

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

4、面向大規(guī)模數(shù)據報表生產的 DataOps 流水

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

5、商業(yè)數(shù)據產品 DataOps 平臺- DataBoot 整體介紹

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

三、全流程 DataOps 平臺化實踐

1、開發(fā)環(huán)節(jié)-大數(shù)據任務開發(fā)一站式 WebIDE 套件

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

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

2、部署環(huán)節(jié)

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

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

• 服務層 Serverless 部署設計。

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

• 計算層 Serverless 部署設計。

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

• 數(shù)據血緣探針織入式部署。

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

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

3、發(fā)布環(huán)節(jié)-數(shù)據進退場風險管控

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

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

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

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

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

4、運維環(huán)節(jié)-全鏈路數(shù)據回溯能力

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

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

5、優(yōu)化環(huán)節(jié)

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

• 問題分析與技術思考。

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

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

• 全局數(shù)據報表時效性優(yōu)化實驗。

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

• 單點聲明式動態(tài)調優(yōu)。

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

四、總結與展望

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