一、滴滴大數據成本治理總體框架

1、滴滴數據體系

在介紹滴滴成本治理之前，首先來簡單介紹一下滴滴的數據體系。

最底層是以數據引擎為基礎的數據存儲，分為離線計算、實時計算、OLAP、no SQL、日志檢索和數據通道六個部分。

在數據計算層，滴滴自研了一站式數據開發平臺——“數據夢工廠”，主要包含離線開發、實時開發、任務調度、同步中心等一系列開發組件。數倉的同學和數據分析同學利用數據夢工廠進行數據的清洗與加工，構建其各自業務線的數據倉庫。

在數據服務層，滴滴自研了一站式數據應用消費平臺——“數易”，用來滿足各類看數、取數、用數的場景。

最上層，數據科學的同學利用已加工好的數據進行決策支持、業務分析和數據挖掘等算法類場景的工作。

管理整套的數據體系，是通過以“元數據”為中心建設的兩個產品，“數據地圖”和“資產管理平臺”。

治理工作，圍繞五個核心方向展開，分別是成本、安全、質量、模型和價值。去年整個團隊的工作重心，主要圍繞數據安全方面。今年的重心則是成本治理。接下來，對成本治理方面的工作實踐進行介紹。

2、滴滴大數據資產管理平臺

滴滴大數據資產管理平臺主要以六個分數來衡量使用數據的“好”與“壞”，分別為計算健康分、存儲健康分、安全健康分、質量健康分、模型健康分和價值健康分。根據這六個維度分數的幾何平均，算出一個總分 DataRank 分，來衡量總體使用數據“好”與“壞”的程度。成本治理主要是提升計算健康分和存儲健康分。

使用大數據資產管理平臺進行成本管理，主要是對引擎（Hadoop、ES、Flink、Click House、Kafka、Hbase），和以“數據夢工廠”和“數易“為核心的兩個數據中臺產品，提供成本計費、賬單分析和成本治理相關能力。

3、滴滴大數據成本治理總體框架

滴滴的“資產管理平臺”于 2019 年初上線，當時只提供了 Hadoop 計算和存儲的兩種治理能力。在上線之前，整個集團的 Hadoop 存儲量，以一條緩慢上漲的曲線，逐漸增長。平臺上線之后，這條曲線逐漸拉平，說明通過治理的動作，抵消了業務增長帶來的用量上漲。這個階段稱為治理 1.0 階段。隨著平臺的發展，我們遇到兩個問題，第一個問題是越來越難找出相對容易的治理項；第二個問題是治理工作的成果和價值，很難被說清楚。所以常被業務質疑，也影響了同學們治理的積極性。所以我們在 2022 年投入精力做定價，再做成本看清，再進行成本治理能力的建設，這就是成本治理 2.0 階段。

一個產品的硬件成本主要來自于三大方面：服務器、網絡和該產品所使用的中間件資源（比如 MySQL、MQ 等）。此外，還有維護該產品，所消耗的人力維護成本，這四大塊構成了產品的總成本。有了產品的總成本，要看這個產品今年需要達到的利潤目標，是達到收支平衡即可，還是要有要留有一定的利潤空間。將成本乘以（1+ 利潤率），就可以預估出產品的預計總收入。隨后要對產品收入進行拆分，確定通過哪些定價項來收費。拆分定價項的難點是，需要預估該產品今年的總用量。預估過大會造成成本損失，預估過小則會造成利潤損失。

有了產品定價，便可開展成本看清的能力建設。底層來源于元數據，主要分為存儲元數據和計算元數據兩塊。存儲元數據基本為各個引擎的 Metastore。計算元數據基本來源于各個引擎運行時的日志。將拿到的元數據同步至離線數倉，進行清洗加工處理。

最終在 app 層，形成計算、存儲、安全、質量、模型、價值 6 個數據域。其中與成本相關的是計算和存儲兩部分。將所消耗的計算和存儲的明細按個人、項目、組織、賬戶四個維度進行匯總，可看到這四個維度下具體的用量情況。對這些數據進行匯總，可得到財務結算的賬單，對賬單進行下鉆分析可發現異動點。

用戶的成本等于單價*用量。單價是引擎測算得出的，用量是用戶實際使用的。對單價治理，需要引擎層進行技術優化。對用量治理，需要用戶開展治理工作。

引擎的優化主要分為計算和存儲。計算方面，主要為通過各種技術手段提升 CPU 的利用率，包括峰值和均值，或通過混部的技術來更多地壓榨機器資源。存儲治理，一般是將冷熱數據分區存儲，因為冷數據的單價比熱數據更低。同時可以引入一些壓縮技術，將數據進行壓縮存儲。

用戶做治理的前提是要有一套完善的用量管控的邏輯。滴滴內部有兩套邏輯，第一個是按賬戶進行拆分，該拆分邏輯主要用于財務結算。另一個是按組織架構進行拆分，該拆分邏輯主要用于追蹤和跟進成本治理的進度與目標，其優勢是便于找到相關的接口人。同時，由于組織架構存在上下級的匯報關系，可使得成本治理工作的推動更加順暢。

按賬戶拆分，一個成本賬戶會有多個項目，需要做一個換算，把真正使用的預算金額換算成每個項目具體可以用的總體用量，再對每個項目的用量進行管控，如果項目用量超出規劃用量，則需先治理再申請額外用量。遇到特殊情況，比如某一業務非常重要，沒有時間做治理，那么走較高層級的審批，審批通過之后才可以放開繼續用量申請。

用戶治理具體分為兩塊，一是“資產管理平臺”要做的事，二是用戶要做的事。

“資產管理平臺”需要找出更多可被用戶治理的資源。首先需要接入各類元數據，主要包括運行時的信息、資源的基礎信息、血緣信息和訪問信息。運行時的信息，主要為各個引擎的運行時日志、審計日志和 GC 日志等。資源的基礎信息，為該資源的創建人、創建時間、所屬項目等。血緣信息和訪問信息，是判斷下游是否有訪問，可以被刪除的重要依據。平臺在離線層計算出可以被治理的資源，主要分為“存儲待治理資源”和“計算待治理資源”，將這些待治理的資源進行打包，形成治理工單，推送給用戶。

用戶根據今年的預算目標和治理目標，對治理工單確定治理節奏，并可查看治理的收益。

二、Hadoop 成本治理實踐

Hadoop 的定價主要參考四個維度，第一個是 Hadoop 的歷史單價，第二個是服務器效率優化目標，第三個是預估當年 Hadoop 所需用量，第四個是期望利潤。基于這四個維度，將定價項拆分為計算和存儲兩塊。存儲定價項，分為常規存儲、冷存儲和文件數；計算定價項，為任務運行時消耗的核數*運行時長。確定 Hadoop 定價項之后，開展看清成本的能力建設。

最底層也是需要接入 Hadoop 的元數據。存儲元數據主要來自于 Metastore 和 FSimage，兩者記錄了表及路徑的詳細信息。計算元數據主要來源于各類日志，詳細記錄了任務運行時的各類狀態。將存儲和計算元數據同步到 ODS 層，進行清洗加工，形成計算和存儲兩個數據域。再對其按個人、項目、組織、賬戶四個維度進行匯總。匯總后的數據，形成財務結算的賬單，對其進行下鉆分析，可知曉 Hadoop 的費用具體消耗在哪些計算任務與存儲上。同時可看清所消耗的費用和用量的具體值及環比，以及待節省的空間。

滴滴內部將 Hadoop 可被治理的資產，分為“無效資產”和“有效資產”。“無效資產”是指這些數據資產確定不會被使用，但可能由于沒有被關注，仍然存放在那里，占用額外的存儲與計算資源。“有效資產”是指這些資源還在被用戶使用，只是使用的效率較低，需要對其進行優化。

對“無效資產”進行治理，底層接入四類日志，Hadoop 審計日志，Spark 審計日志，任務 GC 日志，HDFS 審計日志。將這些日志同步到 ODS 層進行清洗、加工和解析，可得到“存儲待治理推薦項”和“計算待治理推薦項”。“存儲待治理推薦項”主要有生命周期調整、空表空路徑和無效訪問等。“計算待治理推薦項”主要有數據傾斜、暴力掃描，參數不合理、高耗任務和無效計算等。

有效資產治理主要包括兩方面，第一方面是重復模型的治理，主要依賴于字段血源的能力。第二方面是全量小時分區表的改造。由于歷史原因，當時業務需要按小時來建立分區，可隨著業務的發展，原先的需求已經不存在。將其改造成按天調度的表，可節省 23 倍的資源，收益非常大。“無效資產”的治理需要依賴用戶的配合，將計算出的待治理資源形成治理工單，通過『治理工作臺』分發給治理用戶，通過工單流轉方式來完成治理動作。

針對數據傾斜這一治理項，需要兩類引擎日志：Spark 執行日志和 Hadoop 執行日志。對這兩類日志進行解析，得到三個指標，task 運行時的時長，task 處理的數據條數，task 處理的數據字節大小。對三個指標進行計算，計算公式：所有 task 運行的最大值除以所有 task 運行的中位數，可分別得到三個傾斜率。這三個傾斜率，賦予不同的權重就可以得到該任務的傾斜率。根據傾斜率可以判斷任務是否發生了數據傾斜。判斷條件是所有 task 運行的最大時間大于 15 分鐘，且計算出的執行時間傾斜率大于 5。同時滿足這兩個條件，認為任務發生了數據傾斜。

解決數據傾斜一般有三種方案。第一種，造成數據傾斜的原因是數據分布不均勻，比如存在熱點 k，空值比較多的情況。解決的方法就是將熱點 k，尤其是空值提前進行處理，比如排除，或者用隨機k代替空值。第二種，發生數據傾斜的原因是大表 join 小表，造成k的分布不均。解決方案之一是用 MAPJOIN 將小表廣播；另外，也可以適當增加并發度，比如通過 REPARTITION 進行重新分區。還有其它一些解決數據傾斜的方案，主要是參數調整，針對的是數據傾斜不太嚴重的情況，比如調整廣播的大小，或者是對內存進行調適。

針對參數不合理這一治理項，如運行的 Spark 或者 Hadoop 任務，用戶需要設置相關參數，如何判斷用戶設置的參數是否合理，我們總結出一套參數推薦的規則。首先拉取該任務運行時 GC 日志，對 GC 日志進行解析，解析后對特征進行匹配，特征主要是 GC 率和所消耗的內存。有了特征之后，會調用一個參數規則表，根據調參表對參數進行優化。將優化后的參數值推送給用戶，用戶判斷是否進行參數調整。調參表是我們內部總結得出的，我們認為GC率大于 20%，說明當前運行的任務，內存是不足的，需要對內存進行適當的調整。如果內存在 4G 到 22 之間，認為當前內存是偏小的，需要調大當前的內存值；如果內存值已經比較大了，比如在 24G 到 30G，這時再增大內存的收益也許不大了，需要適當地降低并發數，讓每一個運行的線程盡可能分配到更多的內存。

對于降內存的操作，若GC率小于 0.08，說明當前設置的內存過大，因為任務幾乎不發生 GC，需要對內存進行適當的縮小。我們希望整個 task 運行的平均 GC 率在 0.08-0.2 之間，這是一個相對健康的區間，且要確保任務運行時沒有發生抖動。

該項治理上線后，每天節省內存約 1TB。

進行治理操作，最終的落腳點都是對一個資源進行下線、停用或者刪除。這三類操作，最容易引發線上故障，從而造成穩定性問題。判斷這三類操作是否可以進行，主要判斷該資源是否在被使用。這時需要用到“血緣信息“和”訪問信息“。接下來介紹如何構建表級血緣。

構建表級血緣主要來源于四部分：

首先是 SQL 解析。我們使用的是開源的 Antlr，將 SQL 轉化成一個抽象語法樹，隨后對這個語法樹進行解析，可得到表 A 到表 B 的血緣關系。

第二是路徑解析。若任務跑在 Yarn 上，會有 HDFS 輸入路徑與輸出路徑的映射關系，再結合元數據信息，便能拿到輸入路徑與輸入表、輸出路徑與輸出表的對應關系。這樣就可以得到表 A 到表 B 的血緣關系。

第三是運行時 LogicalPlan 的解析。SQL 任務跑在 Spark 上，Spark 會將輸入的 SQL 轉化成一棵抽象語法樹，隨后再轉化成邏輯計劃，這些都是在內存里面完成的。將內存里面的邏輯計劃，以 Json 格式輸出，隨后對該 Json 進行解析，便得到表 A 到表 B 的血緣關系。

第四是任務調度間的 tag 依賴。任務之間的調度會有依賴關系，比如，表 A 產出后，生成 tag 標記，表示表 A 已產出。表B的執行依賴表 A 的產出，當表 B 獲取到表 A 生產 tag，便可開始執行。通過解析該 tag，可得到表 A 到表 B 的血緣關系。

最后對這四種方式獲得的血緣信息求并集，得到最全面的血緣關系。之所以要取并集，是因為每種解析方式，都存在自身的局限性。

SQL 解析，由于用戶總會寫一些奇奇怪怪的 SQL，導致 SQL 解析無法做到 100% 正確。Yarn 路徑解析，該方式 100% 正確，但總有一些特殊的任務不是通過 yarn 提交的，因此這些特殊的任務也就不能被覆蓋到。對于運行時 LogicalPlan，主要解決臨時資源，比如臨時表和臨時 UDF 的血緣匹配。配置 tag 的方式，完全依賴于用戶的配置，如果用戶不配置 tag 依賴或者 tag 依賴配置錯誤，也會導致血緣信息的錯誤。

將這四個解析方式的結果求并集，最終正確率達到了 99. 97%。

相比血緣信息，訪問信息的獲取較為簡單，通過解析 HDFS 審計日志，即可得到每個資源被訪問的情況。

將血緣信息和訪問信息相結合，并在產品上給到用戶醒目的提示，確保用戶對資源進行下線、刪除等操作的安全。做到治理工作的長治久安。

三、ES 成本治理實踐

ES 的定價項，分為“共享集群”和“獨立集群”定價。共享集群的收費項為存儲費用，分為常規存儲和冷存儲。獨立集群的定價，為集群全部的硬件費用，加上維護集群的相關服務費用。

ES 成本看清，整體邏輯與 Hadoop 類似。接入相關的元數據，分為存儲快照、索引基礎信息與 Gateway 日志。將接入的元數據，同步到數倉層進行清洗、加工，得到按個人、項目、組織和賬戶四個維度的用量明細。對用量進行匯總，可用于財務結算。對其進行下鉆，便可分析具體的賬單。下圖中展示了產品示意圖，可以按照不同的視角，看清成本消耗在哪些索引上，對于每位用戶或賬戶，可以看清所消耗的費用和用量的具體值及環比，以及待節省的空間。

ES 成本治理基礎也是相關的元數據：存儲快照、Gateway 日志和索引基礎信息。存儲快照記錄了存儲量信息，Gateway 日志記錄了具體的訪問信息，索引基礎信息為訪問人、創建時間等等。滴滴內部可以對 ES 進行成本治理，一個很重要的原因是，ES 引擎自建了 Gateway，該網關封裝了所有對 ES 的查詢請求。

ES 的待治理項主要包括：空模板、未設置生命周期、不合理生命周期、33 天無訪問，以及字段優化。其中字段優化分為兩類，一是關閉倒排索引，二是關閉正排索引。ES 的收費項是對存儲進行收費，因此關閉倒排和正排可減少索引的存儲量，從而降低成本。關閉倒排索引的依據，該索引是不是長時間沒有被檢索。對于正排索引，如果長時間沒有聚合或者排序的操作，則可以關掉。

根據待治理項，拉出待治理的資源列表，形成治理工單，分發給相應的索引負責人。治理的相關接口人可通過治理工作臺，追蹤治理進展。

除了 ES 和 Hadoop，滴滴內部也對其它引擎，如 Flink、ClickHouse 等和一些中臺產品也開展了成本治理工作，整體邏輯與前文所述類似。首先對產品進行定價，定價之后可以做成本看清的工作，具體知曉哪些資源消耗了多少成本。接下來就可以開展成本治理的工作，基礎是元數據的接入，再對元數據進行清洗加工，得到待治理的資源列表，將其打包形成治理工單，通過治理工作臺跟蹤治理進展。

四、一些心得

做數據治理，需要有自上而下的成本目標與組織保障，否則難以推動。組織保障的最上層是集團的預算委員會，主要負責制定每個事業部，今年整體的預算目標，將目標派發給事業部的成本負責人。事業部的成本負責人，領到今年的預算目標，需對目標進行拆分，具體到今年要完成的治理優化數量，同時成本負責人向預算委員會，匯報治理工作的進展。事業部的負責人將拆分后的優化目標派發給各個團隊的成本治理接口人，治理接口人根據治理目標，拆分出治理任務，將治理任務分配給資源的歸屬人，由其完成治理動作。同時成本治理接口人需要向事業部的成本負責人匯報治理進展。

開展成本治理工作，最終的執行者都是一線具體的資源歸屬同學，他們每天的工作任務壓力已經是較大的。若還需抽出額外的精力，做成本治理工作，往往推動較難，這也是治理工作的難點之一。將“被迫治理”轉為“積極治理”，在滴滴每年會通過運營活動的方式，營造氛圍。如開展《數據治理大賽》，將個人或者團隊的治理完成率進行排名，對排名較高的個人或團隊進行獎勵。希望能為枯燥的治理工作帶來一點娛樂性，進而激發大家的治理積極性。