導讀

本文概述了在業務高速發展和降本增效的背景下百度MEG（移動生態事業羣組）大數據成本治理實踐方案，主要包含當前業務面臨的主要問題、計算數據成本治理優化方案、存儲數據成本治理優化方案、數據成本治理成果以及未來治理方向的一個思路探討，為業界提供可參考的治理經驗。

01 背景

隨着百度各業務及產品的快速發展，海量的離線數據成本在持續地增長。在此背景下，通過大數據治理技術來幫助業務降本增效，實現業務的可持續增長變得至關重要。我們通過對當前資源現狀、管理現狀以及成本現狀三個角度進行分析：

• 資源現狀：各個產品線下業務類型繁多，涉及的離線AFS（百度公司分佈式文件存儲：Appendonly File Storage）存儲賬號和EMR（百度公司全託管計算集羣：E-MapReduce EMR+）隊列數量非常多，成百上千，什麼時候啓動治理，採用什麼手段治理，並沒有明確規劃，且各業務間缺少統一的治理標準。
• 管理現狀：針對離線資源的使用參差不齊，存儲賬號和計算隊列資源的管理和使用較為混亂，有的使用率高，有的使用率低；此外，業務間的離線作業管理並不統一且不完全規範，沒有完善的流程機制以及規範來對離線資源以及作業進行管理管控，並且計算任務的執行效率較低，整體運維難度較大。
• 成本現狀：MEG各個產品線離線計算資源達數千萬核，存儲資源達數千PB，各產品線的離線計算和存儲資源成本每年可達數億元，隨着業務的增長，如果不進行成本治理和優化，離線資源成本還會持續增加。

整體來説，目前主要面臨數據散亂、資源浪費、成本增加等問題。基於以上存在的問題，我們通過構建統一的治理標準，並利用大數據資源管理平台搭建各產品線下的的離線存儲資源視圖、計算資源視圖、任務視圖以及成本視圖，基於引擎能力對存儲和計算進一步優化，幫助MEG下各產品線下的業務持續進行數據成本治理，接下來將具體闡述我們在大數據成本治理過程的實踐方案。

△ 數據成本治理現狀

02 數據成本治理實踐方案

2.1 數據成本治理總體框架

針對目前存在的問題，我們主要圍繞數據資產度量、平台化能力以及引擎賦能三個方面構建數據成本治理總體框架，實現對計算和存儲兩大方向的治理，來達到降本增效的目的，具體如下圖所示，接下來將進行具體地介紹。

△ 數據成本治理總體框架

2.1.1 數據資產健康度量

為了對當前各個業務的計算和存儲資源進行合理的評估和治理，我們採用統一的標準：健康分來進行衡量，而健康分計算的數據指標來源依賴於離線數據採集服務，該服務通過對當前計算隊列，計算任務，存儲賬號，數據表等元數據信息進行例行採集，然後再進一步對於採集的數據進行分析和挖掘，形成一個個計算治理項和存儲治理項，比如計算治理項可包含：使用率不均衡的計算隊列個數、長耗時高資源消耗的計算任務、數據傾斜的任務以及無效任務等；存儲治理項可包含1年/2年/N年未訪問的冷數據目錄、存儲目錄生命週期異常、inode佔比過低以及未認領目錄等。通過產生的數據治理項信息匯聚形成計算健康分和存儲健康分兩大類，如下：

• 計算健康分：基於隊列使用平均水位+隊列使用均衡程度+計算治理項進行加權計算獲取。
• 存儲健康分：基於存儲賬號使用平均水位+存儲賬號使用峯值+冷數據佔比+治理項進行加權計算獲取。

最終，通過統一規範的健康分來對當前各產品線下業務所屬的數據資產進行度量，指導業務進行規範化治理。

2.1.2 平台化能力

此外，為了完成對當前產品線下離線計算和存儲資源的全生命週期管理，我們通過搭建大數據資源管理平台，完成對各個產品線的離線計算資源和存儲資源的接入，並基於平台能力為業務構建統一的計算視圖、存儲視圖以及離線成本視圖，整合離線計算任務需要的存儲和計算資源，並將各類工具平台化，幫助業務快速發現和解決各類數據成本治理問題，具體如下：

• 計算視圖：包含各個計算隊列資源使用概覽和計算治理項詳情信息，並提供計算任務註冊、管控、調度執行以及算力優化全生命週期管理的能力。
• 存儲視圖：匯聚了當前所有存儲賬號資源使用詳情以及各類存儲治理項信息，並提供給用户關於存儲目錄清理、遷移以及冷數據挖掘相關的存儲管理以及治理能力。
• 成本視圖：構建各個產品線下關於離線存儲和計算資源總成本使用視圖，通過總成本使用情況，更直觀地展示治理成果。

2.1.3 引擎賦能

在實際離線大數據業務場景中，很多業務接口人對於大數據計算或者存儲引擎的原理和特性不是非常熟悉，缺乏或者沒有調優意識，通常在任務提交時沒有根據任務的實際數據規模、計算複雜度以及集羣資源狀況進行針對性的參數調整，這種情況就會使得任務執行效率無法達到最優，且計算和存儲資源不能得到充分的應用，進而影響業務迭代效率。針對上述計算和存儲資源浪費的問題，我們結合大數據引擎能力，來實現對於計算和存儲進一步地優化，助力業務提效，為業務的持續發展提供有力的支持。主要包含以下兩個場景：

• 計算場景：結合任務運行歷史信息以及機器學習算法模型能力，建立一套完善的智能調參機制，對於提交的任務參數進行動態調整，最大程度保障任務在較優的參數下執行，進一步提升任務執行效率，並高效利用當前計算資源。
• 存儲場景：針對海量的存儲數據，我們通過不同類型數據進行深入的分析和特徵挖掘，實現了對存儲數據智能壓縮的能力，從而在不影響業務數據寫入和查詢的前提下，完成對現有數據存儲文件的壓縮，幫助業務節約存儲資源和成本。

03 計算&存儲數據成本治理優化

3.1 計算成本治理

在計算成本治理方向，我們主要基於平台和引擎能力，通過管理管控，混合調度以及智能調參三大方面對現有的計算資源和計算任務進行治理和優化。

3.1.1 管理管控

在MEG離線大數據場景下，主要涉及對上千EMR計算隊列、以及上萬Hadoop和Spark兩大類型的計算任務管理。

• 一方面，我們針對各個業務的計算隊列和計算任務的管理，通過平台能力實現了從計算資源的註冊接入，到計算隊列和任務數據的採集，再到離線數據分析和挖掘，最終形成如使用率不均衡的計算隊列、長耗時高資源消耗的計算任務、數據傾斜的任務、無效任務以及相似任務等多個計算治理項，並基於統一規範的健康分機制來對業務計算資產進行度量，指導業務對計算進行治理。
• 另一方面，在離線混部場景，可能會存在部分用户對於任務使用不規範，影響離線例行任務或者造成資源浪費，我們針對Hadoop和Spark不同任務類型，分別建立了任務提交時和運行時管控機制，並結合業務實際場景，實現了併發限制、基本參數調優，隊列資源限制以及殭屍任務等30+管控策略，對於天級上萬的任務進行合理的管理管控，並及時挖掘和治理相關異常任務。目前運行的管控策略已經覆蓋多個產品線下離線EMR計算隊列上千萬核，每天任務觸發各種管控次數20萬+。

通過對計算資源全生命週期的管理和管控，我們可以及時有效地發現可治理的隊列或者任務，並推進業務進行治理。

△ 任務管理管控流程

3.1.2 混合調度

通過對於平台接入的隊列資源使用情況以及任務執行情況的深度分析，我們發現當前各個業務使用的計算資源存在以下幾個問題：

1. 不同產品線業務特點不同，存在Hadoop和Spark兩種類型計算任務，並且Hadoop任務CPU使用較多、內存使用較低，而Spark任務CPU使用較低，內存使用較高。

2. 有些隊列整體資源使用率不高，但是存在部分時間段資源使用很滿，不同隊列資源使用波峯不完全一致，有的高峯在夜間，有的高峯在白天。

3. 存在隊列碎片化問題，一些小隊列不適合提交大作業且部分使用率不高。

為解決上述問題，我們建設Hadoop和Spark混合調度機制。針對公司不同業務來源的任務，基於Hadoop調度引擎以及Spark調度引擎完成各自任務的智能化調度，並通過調度策略鏈在多個候選隊列中選擇最優隊列，最終實現任務提交到EMR計算集羣上進行執行。具體流程如下：

• 任務提交：針對不同產品線下的業務提交的Hadoop或者Spark任務，服務端會通過不同任務類型基於優先級、提交時間以及輪數進行全局加權排序，排序後的每個任務會分發到各自的任務調度池中，等待任務調度引擎拉取提交。
• 任務調度：該階段，調度引擎中不同任務類型的消費線程，會定時拉取對應任務調度池中的任務，按照FIFO的策略，多線程進行消費調度。在調度過程中，每個任務會依次通過通用調度策略鏈和專有調度策略鏈來獲取該任務最優提交隊列，其中，通用和專有調度策略主要是計算隊列資源獲取、候選隊列過濾、隊列排序（數據輸入輸出地域，計算地域）、隊列資源空閒程度以及高優任務保障等20+策略。比如某任務調度過程中，請求提交的隊列是A，調度過程中存在三個候選隊列A、B、C，其中候選隊列A使用率很高，B使用率中等且存儲和計算地域相差較遠，C使用率低且距離近，最終通過智能調度可分配最優隊列C進行提交。
• 任務執行：通過調度引擎獲取到最優隊列的任務，最終會提交到對應的EMR計算集羣隊列上進行執行，進而實現各個隊列的使用率更加均衡，並提高低頻使用隊列的資源使用率。

△ 任務混合調度流程

3.1.3 智能調參

在數據中心業務場景，多以Spark任務為主，天級提交的Spark任務5萬+，但這些任務執行過程中，會存在計算資源浪費的情況，具有一定的優化空間，我們通過前期數據分析，發現主要存在以下兩類問題：

1. 用户沒有調優意識，或者是缺乏調優經驗，會造成大量任務資源配置不合理，資源浪費嚴重，比如併發和內存資源配置偏大，但實際可以繼續調低，如case示例1所示；

2. 在Spark計算引擎優化器中， 只有RBO(Rule-Based Optimizer)和CBO(Cost-Based Optimizer)優化器， 前者基於硬規則，後者基於執行成本來優化查詢計劃，但對於例行任務， 只有RBO和CBO會忽略一些能優化的輸入信息，任務性能存在一定的瓶頸，如case示例2所示。

△ 任務參數配置case示例

針對第一類問題，我們實現了對Spark任務基本參數智能調優的能力，在保證任務SLA的情況下，結合模型訓練的方式，來支持對例行任務長期調優並降低任務資源消耗。每輪任務例行會推薦一組參數並獲取其對應性能，通過推薦參數、運行並獲取性能、推薦參數的週期性迭代，在多輪訓練迭代後，提供一組滿足任務調優目標並且核時最少的近似最優參數，其中涉及的參數主要有spark.executor.instances, spark.executor.cores, spark.executor.memory這三類基本參數。具體實現流程如下：

1. 任務提交流：任務提交過程中，會從調優服務的Web Controller模塊獲取當前生成的調優參數並進行下發；

2. 結果上報流：通過任務狀態監控，在任務執行完成後，調優服務的Backend模塊會定時同步更新任務實際運行配置和執行耗時等執行歷史數據信息到數據庫中；

3. 模型訓練流：調優服務的Backend模塊定時拉取待訓練任務進行數據訓練，通過與模型交互，加載歷史調優模型checkpoint，基於最新樣本數據進行迭代訓練，生成新的訓練模型checkpoint以及下一輪調優參數，並保存到數據庫中。

4. 任務SLA保障：通過設置運行時間上限、超時兜底、限制模型調優範圍，以及任務失敗兜底等策略來保障任務運行時間以及任務執行的穩定性。

最終，通過任務提交流程、結果上報流程、訓練流程實現任務運行時需要的併發和內存基本參數的自動化調優，並基於運行時間保障和任務穩定性保障策略，確保任務的穩定性，整體流程框架如下圖。

△ 基本參數智能調優流程

針對第二類問題，我們構建HBO(History Based Optimization)智能調優模塊實現對複雜參數場景的任務自動調優能力。首先，通過性能數據收集器完成對運行完成的Spark任務History的詳情數據採集和AMP任務畫像，然後在任務執行計劃階段和提交階段，基於任務歷史執行的真實運行統計數據來優化未來即將執行的任務性能，從而彌補執行之前預估不精確的問題，具體如下：

• 執行計劃調優階段：主要進行Join算法動態調整、Join數據傾斜調整、聚合算法動態調整以及Join順序重排等調優；
• 任務提交階段：基於任務運行特點智能添加或者改寫當前提交的Spark任務運行參數，比如Input輸入、合併小文件讀、Output輸出、拆分大文件寫、Shuffle分區數動態調整以及大shuffle開啓Kryo Serialization等參數，從而實現對運行參數的調優；

通過數據採集反饋和動態調參，不斷循環，進而完成對於複雜參數場景的智能調優能力，讓任務在執行資源有限的條件下，跑得更穩健，更快。整體實現流程圖如下：

△ HBO智能調優流程

3.2 存儲成本治理

在百度MEG大數據離線場景下，底層存儲主要是使用AFS，通過梳理我們發現目前針對離線使用的各個存儲賬號，缺乏統一管理和規範，主要存在以下幾個核心問題：

• AFS存儲賬號多且無歸屬：離散賬號繁多，涉及目錄數量多且大部分無Quota限制甚至找不到相關負責人，缺乏統一管理和規範；
• AFS存儲不斷增加：不少業務對於數據存儲缺少優化治理措施，且存在很多歷史的無用數據，長期存放，導致數據只增不減；
• 安全風險：各個賬號使用過程中，數據隨意讀寫甚至跨多個賬户讀寫，安全無保障，並且缺少監控報警。

3.2.1 存儲生命週期管理

針對上述問題，我們基於平台能力構建存儲一站式治理能力，將存儲資源的全生命週期管理分為五層：接入層、服務層、存儲層、執行層以及用户層，通過建立存儲資源使用規範，並基於採集的相關存儲元數據，深度分析業務的離線AFS存儲賬號使用現狀，將用户存儲相關的問題充分挖掘和暴露出來，針對各種問題提供簡單易用的通用化工具來幫助用户快速進行治理和解決，整體實現了各個集羣存儲賬號的存儲數據接入，採集，挖掘和分析，自動清理，監控預警全生命週期的管理。整體流程架構圖如下：

△ 存儲生命週期管理流程

• 接入層：通過建立規範的存儲資源管理機制，比如存儲的接入和申請規範、目錄的創建規範、使用規範、利用率考核規範（Quota回收規範）以及冷數據的處理規範等通用化的規範，進而來完成用户從存儲資源的接入-申請（擴容）、審核、交付、資源的例行審計的整體流程。
• 服務層：基於離線服務完成對各集羣存儲目錄&存儲冷數據Quota採集，然後進一步對數據進行深入分析和挖掘，包含但不限於冷數據、異常目錄使用、存儲變化趨勢以及成本數據等分析。
• 存儲層：建立賬號、產品線、目錄、任務、負責人以及賬號的基本使用信息的元數據存儲，通過Mysql進行存儲，確保每個集羣存儲賬號有對應歸屬；對於各個集羣目錄數據使用詳情信息，選擇Table（百度公司大規模分佈式表格系統）進行存儲。
• 執行層：基於存儲管理規範，對於各個集羣存儲賬號進行每天例行的存儲自動清理，數據轉儲和壓縮，並提供完善的存儲使用監控報警機制。
• 用户層：通過平台，為用户構建不同維度的AFS存儲現狀概覽視圖，以及整合現有數據，對於各個集羣的存儲賬號或目錄進行分析，提供優化建議、存儲工具以及API接口，幫助業務快速進行存儲相關治理和存儲相關問題的解決。

3.2.2 存儲基礎治理

在AFS存儲資源的生命週期管理過程中，我們主要基於服務層和執行層為用户提供一套基礎的存儲AFS賬號數據基礎治理能力。通過離線解析Quota數據和冷數據目錄相關的基礎數據，完成對其計算、分析、聚合等處理，實現存儲趨勢變化、成本計算、異常目錄分析、冷數據分析、數據治理項和治理建議等多方面能力支持。之後，用户便可結合存儲數據全景視圖分析和相關建議，進行存儲路徑配置、轉儲集羣目錄配置、壓縮目錄配置以及監控賬號配置等多維度配置。基於用户的配置，通過後台離線服務定時執行，完成對用户存儲的數據清理、空間釋放和監控預警，保障各個業務存儲賬號的合理使用以及治理優化。

△ AFS存儲數據基礎治理流程

3.2.3 智能壓縮

平台側管理的MEG相關AFS存儲數據上千PB，存在一部分數據，是沒有進行相應的壓縮或者壓縮格式設置的並不是非常合理，我們通過結合業務實際使用情況，針對業務存儲數據進行智能壓縮，同時不影響數據讀寫效率，進一步優化降低業務存儲成本，主要實現方案流程如下圖。由於業務場景不同，我們採用不同的壓縮方案。

• 針對數倉表存儲數據場景：首先是通過對採集的數倉表元數據信息進行數據畫像，完成表字段存儲佔比和數據分佈情況分析，之後基於自動存儲優化器，實現對數倉表分區數據讀取、壓縮規則應用以及分區數據重寫，最終完成對數倉表數據的自動壓縮，在保證數倉表讀寫效率的前提下，進一步提升數據壓縮效率，降低存儲數據成本。其中壓縮規則應用主要包含：可排序字段獲取、重排序優化、ZSTD壓縮格式、PageSize大小以及壓縮Leve調整等規則。
• 針對非數據倉表存儲數據場景：在該場景下的存儲數據，一般是通過任務直接寫入AFS，寫入方式各種各樣，因此，需要直接對AFS存儲數據進行分析和挖掘。我們首先對這部分數據進行冷熱分層，將其分為冷數據、温數據以及熱數據，並挖掘其中可進行壓縮和壓縮格式可進一步優化的數據，以及壓縮配置可進一步調整的任務；之後，通過自動存儲優化器，針對增量熱數據，基於例行寫入任務歷史畫像選擇合適的壓縮參數進行調優，並記錄壓縮效果；針對存量温冷數據，定期執行離線壓縮任務進行自動壓縮；最終我們對熱數據進行壓縮提醒，温冷數據進行自動壓縮，從而實現該類型存儲數據的壓縮智能優化。

△ 智能壓縮流程

04 治理成果

通過數據成本治理，我們取得了一些不錯的優化和實踐效果，主要包含數據開發和成本優化方面以及治理資產兩大方面：

1. 數據開發和成本優化

• 數據開發提效：基於離線資源的全生命週期管理，計算和存儲資源交付效率從月級或者周級縮短至天級，效率大幅提升，進而降低數據開發週期，此外基於混合調度和智能調參等能力，任務排隊情況大幅降低，數據產出時效性平均提升至少一倍，大幅提高數據開發效率。
• 計算成本優化：實現了MEG下上千個隊列使用更加均衡，並完成了千萬核EMR計算隊列資源平均使用率提升30%+，增量供給日常業務需求數百萬核資源的同時，優化退訂數百萬核計算資源，年化成本可降低數千萬元。
• 存儲運維提效：通過利用存儲數據基礎治理等能力，完成了對上千個AFS存儲賬號管理、無用數據挖掘和清理，以及監控預警等，使得存儲賬號的運維更加可控，效率大幅提升。
• 存儲成本優化：實現了對MEG下上千PB存儲資源整體使用率平均提升20%+，增量供給日常業務需求數百PB資源的同時，優化退訂數百PB存儲資源，年化成本同樣降低數千萬元。

2. 治理資產

• 數據開發規範：逐步完善了資源交付規範、計算任務開發規範、存儲和計算資源使用規範、以及數據質量和安全規範等多種規範流程。
• 計算&存儲資源成本：形成各個產品線下關於計算資源、存儲資源以及成本使用詳情的概覽視圖，對於資源使用和成本變化趨勢清晰可見。
• 數據任務資產：基於任務歷史畫像，構建任務從提交到運行再到完成的全生命週期的執行詳情數據概覽視圖，幫助業務高效進行任務管理。
• 數據治理項：通過數據挖掘和分析形成的計算任務，計算隊列和存儲賬號相關的治理項詳情數據看板，助力業務快速發現可治理的數據問題。

05 未來規劃

目前，通過標準化、平台化以及引擎化的技術能力，進一步完成了對MEG下離線存儲和計算資源管理和數據成本治理，並取得一定治理成果，但數據成本治理作為一個長期且持續的一項工作，我們將持續完善和挖掘數據成本治理技術方案，並結合治理過程中的經驗、流程和標準，實現更規範、更智能化的治理能力。