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

1、滴滴數(shù)據(jù)體系

在介紹滴滴成本治理之前，首先來(lái)簡(jiǎn)單介紹一下滴滴的數(shù)據(jù)體系。

最底層是以數(shù)據(jù)引擎為基礎(chǔ)的數(shù)據(jù)存儲(chǔ)，分為離線(xiàn)計(jì)算、實(shí)時(shí)計(jì)算、OLAP、no SQL、日志檢索和數(shù)據(jù)通道六個(gè)部分。

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

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

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

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

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

2、滴滴大數(shù)據(jù)資產(chǎn)管理平臺(tái)

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

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

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

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

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

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

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

用戶(hù)的成本等于單價(jià)*用量。單價(jià)是引擎測(cè)算得出的，用量是用戶(hù)實(shí)際使用的。對(duì)單價(jià)治理，需要引擎層進(jìn)行技術(shù)優(yōu)化。對(duì)用量治理，需要用戶(hù)開(kāi)展治理工作。

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

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

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

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

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

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

二、Hadoop 成本治理實(shí)踐

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

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

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

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

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

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

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

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

對(duì)于降內(nèi)存的操作，若GC率小于 0.08，說(shuō)明當(dāng)前設(shè)置的內(nèi)存過(guò)大，因?yàn)槿蝿?wù)幾乎不發(fā)生 GC，需要對(duì)內(nèi)存進(jìn)行適當(dāng)?shù)目s小。我們希望整個(gè) task 運(yùn)行的平均 GC 率在 0.08-0.2 之間，這是一個(gè)相對(duì)健康的區(qū)間，且要確保任務(wù)運(yùn)行時(shí)沒(méi)有發(fā)生抖動(dòng)。

該項(xiàng)治理上線(xiàn)后，每天節(jié)省內(nèi)存約 1TB。

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

構(gòu)建表級(jí)血緣主要來(lái)源于四部分：

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

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

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

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

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

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

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

相比血緣信息，訪(fǎng)問(wèn)信息的獲取較為簡(jiǎn)單，通過(guò)解析 HDFS 審計(jì)日志，即可得到每個(gè)資源被訪(fǎng)問(wèn)的情況。

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

三、ES 成本治理實(shí)踐

ES 的定價(jià)項(xiàng)，分為“共享集群”和“獨(dú)立集群”定價(jià)。共享集群的收費(fèi)項(xiàng)為存儲(chǔ)費(fèi)用，分為常規(guī)存儲(chǔ)和冷存儲(chǔ)。獨(dú)立集群的定價(jià)，為集群全部的硬件費(fèi)用，加上維護(hù)集群的相關(guān)服務(wù)費(fèi)用。

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

ES 成本治理基礎(chǔ)也是相關(guān)的元數(shù)據(jù)：存儲(chǔ)快照、Gateway 日志和索引基礎(chǔ)信息。存儲(chǔ)快照記錄了存儲(chǔ)量信息，Gateway 日志記錄了具體的訪(fǎng)問(wèn)信息，索引基礎(chǔ)信息為訪(fǎng)問(wèn)人、創(chuàng)建時(shí)間等等。滴滴內(nèi)部可以對(duì) ES 進(jìn)行成本治理，一個(gè)很重要的原因是，ES 引擎自建了 Gateway，該網(wǎng)關(guān)封裝了所有對(duì) ES 的查詢(xún)請(qǐng)求。

ES 的待治理項(xiàng)主要包括：空模板、未設(shè)置生命周期、不合理生命周期、33 天無(wú)訪(fǎng)問(wèn)，以及字段優(yōu)化。其中字段優(yōu)化分為兩類(lèi)，一是關(guān)閉倒排索引，二是關(guān)閉正排索引。ES 的收費(fèi)項(xiàng)是對(duì)存儲(chǔ)進(jìn)行收費(fèi)，因此關(guān)閉倒排和正排可減少索引的存儲(chǔ)量，從而降低成本。關(guān)閉倒排索引的依據(jù)，該索引是不是長(zhǎng)時(shí)間沒(méi)有被檢索。對(duì)于正排索引，如果長(zhǎng)時(shí)間沒(méi)有聚合或者排序的操作，則可以關(guān)掉。

根據(jù)待治理項(xiàng)，拉出待治理的資源列表，形成治理工單，分發(fā)給相應(yīng)的索引負(fù)責(zé)人。治理的相關(guān)接口人可通過(guò)治理工作臺(tái)，追蹤治理進(jìn)展。

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

四、一些心得

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

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