? ? 原文大佬的這篇本文主要介紹滴滴大數(shù)據(jù)在成本治理方面的實踐。有些內(nèi)容是有借鑒意義的，這些摘抄下來用作沉淀學(xué)習(xí)。如有侵權(quán)，請告知~

一、滴滴大數(shù)據(jù)成本治理總體框架

1.1 數(shù)據(jù)體系

? 從上圖所示：最底層是以數(shù)據(jù)引擎為基礎(chǔ)的數(shù)據(jù)存儲，分為離線計算、實時計算、OLAP、NoSQL、日志檢索和數(shù)據(jù)通道六個部分。

?在數(shù)據(jù)計算層，滴滴自研了一站式數(shù)據(jù)開發(fā)平臺——“數(shù)據(jù)夢工廠”，主要包含離線開發(fā)、實時開發(fā)、任務(wù)調(diào)度、同步中心等一系列開發(fā)組件。數(shù)倉的同學(xué)和數(shù)據(jù)分析同學(xué)利用數(shù)據(jù)夢工廠進行數(shù)據(jù)的清洗與加工、構(gòu)建其各自業(yè)務(wù)線的數(shù)據(jù)倉庫。

?在數(shù)據(jù)服務(wù)層，滴滴自研了一站式數(shù)據(jù)應(yīng)用消費平臺——“數(shù)易”，用來滿足各類看數(shù)、取數(shù)、用數(shù)的場景。

? 最上層，數(shù)據(jù)科學(xué)的同學(xué)利用已加工好的數(shù)據(jù)進行決策支持、業(yè)務(wù)分析和數(shù)據(jù)挖掘等算法類場景的工作。?

? 管理整套的數(shù)據(jù)體系、是通過以“元數(shù)據(jù)”為中心建設(shè)的兩個產(chǎn)品，“數(shù)據(jù)地圖”和“資產(chǎn)管理平臺”。

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

1.2?大數(shù)據(jù)資產(chǎn)管理平臺

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

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

1.3?大數(shù)據(jù)成本治理總體框架

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

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

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

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

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

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

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

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

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

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

? 用戶根據(jù)今年的預(yù)算目標(biāo)和治理目標(biāo)，對治理工單確定治理節(jié)奏，并可查看治理的收益。

二、Hadoop 成本治理實踐

? ? Hadoop 的定價主要參考四個維度，第一個是 Hadoop 的歷史單價，第二個是服務(wù)器效率優(yōu)化目標(biāo)，第三個是預(yù)估當(dāng)年 Hadoop 所需用量，第四個是期望利潤?；谶@四個維度，將定價項拆分為計算和存儲兩塊。存儲定價項，分為常規(guī)存儲、冷存儲和文件數(shù)；計算定價項，為任務(wù)運行時消耗的核數(shù)*運行時長。確定 Hadoop 定價項之后，開展看清成本的能力建設(shè)。

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

? ? 滴滴內(nèi)部將 Hadoop 可被治理的資產(chǎn)，分為“無效資產(chǎn)”和“有效資產(chǎn)”?！盁o效資產(chǎn)”是指這些數(shù)據(jù)資產(chǎn)確定不會被使用，但可能由于沒有被關(guān)注，仍然存放在那里，占用額外的存儲與計算資源?！坝行зY產(chǎn)”是指這些資源還在被用戶使用，只是使用的效率較低，需要對其進行優(yōu)化。

? ?對“無效資產(chǎn)”進行治理，底層接入四類日志，Hadoop 審計日志，Spark 審計日志，任務(wù) GC 日志，HDFS 審計日志。將這些日志同步到 ODS 層進行清洗、加工和解析，可得到“存儲待治理推薦項”和“計算待治理推薦項”?！按鎯Υ卫硗扑]項”主要有生命周期調(diào)整、空表空路徑和無效訪問等?！坝嬎愦卫硗扑]項”主要有數(shù)據(jù)傾斜、暴力掃描，參數(shù)不合理、高耗任務(wù)和無效計算等。

? ?有效資產(chǎn)治理主要包括兩方面，第一方面是重復(fù)模型的治理，主要依賴于字段血源的能力。第二方面是全量小時分區(qū)表的改造。由于歷史原因，當(dāng)時業(yè)務(wù)需要按小時來建立分區(qū)，可隨著業(yè)務(wù)的發(fā)展，原先的需求已經(jīng)不存在。將其改造成按天調(diào)度的表，可節(jié)省 23 倍的資源，收益非常大?！盁o效資產(chǎn)”的治理需要依賴用戶的配合，將計算出的待治理資源形成治理工單，通過『治理工作臺』分發(fā)給治理用戶，通過工單流轉(zhuǎn)方式來完成治理動作。

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

? ?解決數(shù)據(jù)傾斜一般有三種方案。第一種，造成數(shù)據(jù)傾斜的原因是數(shù)據(jù)分布不均勻，比如存在熱點 k，空值比較多的情況。解決的方法就是將熱點k，尤其是空值提前進行處理，比如排除，或者用隨機k代替空值。第二種，發(fā)生數(shù)據(jù)傾斜的原因是大表join小表，造成 k的分布不均。解決方案之一是用 map join將小表廣播；另外，也可以適當(dāng)增加并發(fā)度，比如通過 repartition進行重新分區(qū)。還有其他一些數(shù)據(jù)傾斜的方案，主要是參數(shù)調(diào)整，針對的是數(shù)據(jù)傾斜不太嚴(yán)重的情況，比如調(diào)整廣播的大小，或者是對內(nèi)存進行調(diào)適。

? 針對參數(shù)不合理這一治理項，如運行的 Spark 或者 Hadoop 任務(wù)，用戶需要設(shè)置相關(guān)參數(shù)，如何判斷用戶設(shè)置的參數(shù)是否合理，我們總結(jié)出一套參數(shù)推薦的規(guī)則。首先拉取該任務(wù)運行時 GC 日志，對 GC 日志進行解析，解析后對特征進行匹配，特征主要是 GC 率和所消耗的內(nèi)存。有了特征之后，會調(diào)用一個參數(shù)規(guī)則表，根據(jù)調(diào)參表對參數(shù)進行優(yōu)化。將優(yōu)化后的參數(shù)值推送給用戶，用戶判斷是否進行參數(shù)調(diào)整。調(diào)參表是我們內(nèi)部總結(jié)得出的，我們認(rèn)為GC率大于 20%，說明當(dāng)前運行的任務(wù)，內(nèi)存是不足的，需要對內(nèi)存進行適當(dāng)?shù)恼{(diào)整。如果內(nèi)存在 4G 到 22 之間，認(rèn)為當(dāng)前內(nèi)存是偏小的，需要調(diào)大當(dāng)前的內(nèi)存值；如果內(nèi)存值已經(jīng)比較大了，比如在 24G 到 30G，這時再增大內(nèi)存的收益也許不大了，需要適當(dāng)?shù)亟档筒l(fā)數(shù)，讓每一個運行的線程盡可能分配到更多的內(nèi)存。

? ?對于降內(nèi)存的操作，若GC率小于 0.08，說明當(dāng)前設(shè)置的內(nèi)存過大，因為任務(wù)幾乎不發(fā)生 GC，需要對內(nèi)存進行適當(dāng)?shù)目s小。我們希望整個 task 運行的平均 GC 率在 0.08-0.2 之間，這是一個相對健康的區(qū)間，且要確保任務(wù)運行時沒有發(fā)生抖動。該項治理上線后，每天節(jié)省內(nèi)存約 1TB。

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

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

第二是路徑解析。若任務(wù)跑在 Yarn 上，會有 HDFS 輸入路徑與輸出路徑的映射關(guān)系，再結(jié)合元數(shù)據(jù)信息，便能拿到輸入路徑與輸入表、輸出路徑與輸出表的對應(yīng)關(guān)系。這樣就可以得到表 A 到表 B 的血緣關(guān)系。

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

第四是任務(wù)調(diào)度間的 tag 依賴。任務(wù)之間的調(diào)度會有依賴關(guān)系，比如，表 A 產(chǎn)出后，生成 tag 標(biāo)記，表示表 A 已產(chǎn)出。表B的執(zhí)行依賴表 A 的產(chǎn)出，當(dāng)表 B 獲取到表 A 生產(chǎn) tag，便可開始執(zhí)行。通過解析該 tag，可得到表 A 到表 B 的血緣關(guān)系。

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

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

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

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

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

三、實踐經(jīng)驗

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

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

參考文章：

滴滴大數(shù)據(jù)成本治理實踐文章來源地址http://www.zghlxwxcb.cn/news/detail-839464.html

到了這里，關(guān)于數(shù)據(jù)治理——滴滴大數(shù)據(jù)成本治理實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！