一、滴滴大數(shù)據(jù)資產(chǎn)管理平臺

首先讓我們來了解一下滴滴數(shù)據(jù)體系，以及資產(chǎn)管理平臺在這個體系中的定位。

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

從下往上，最底層是數(shù)據(jù)底座，包括數(shù)據(jù)存儲、數(shù)據(jù)計算、實時查詢、消息中間件、調度等部分。其上是中間層，數(shù)據(jù)夢工廠，是數(shù)據(jù)一站式開發(fā)平臺，提供數(shù)據(jù)導入、數(shù)據(jù)加工、任務調度、數(shù)據(jù)質量校驗等一系列工具。最上層是基于數(shù)據(jù)底座和數(shù)據(jù)中間層構建的數(shù)據(jù)服務與數(shù)據(jù)應用，并衍生出各種數(shù)據(jù)產(chǎn)品。資產(chǎn)管理平臺便是其中之一。

2. 資產(chǎn)管理平臺產(chǎn)品架構

資產(chǎn)管理平臺是對整個滴滴大數(shù)據(jù)中的數(shù)據(jù)資產(chǎn)進行統(tǒng)一管理的一個平臺，底層管理包括存儲資源（如 Hive、HDFS）與計算資源（如 Spark）。

從功能上分為成本管理、資產(chǎn)管理和資產(chǎn)治理三大部分。資產(chǎn)治理又包括存儲治理、計算治理、質量治理、安全治理。并提供治理提效工具，如治理工作臺、自動化治理、權限批回收等。

二、Hadoop 治理實踐

1. Hadoop 治理的對象

數(shù)據(jù)夢工廠是構建在 Hadoop 體系之上的一個開發(fā)平臺。用戶在平臺上進行開發(fā)，包括任務的創(chuàng)建、調度，就會用到 Hadoop 底層的存儲資源和計算資源。這些均為 Hadoop 體系中數(shù)據(jù)治理的對象。

• 存儲治理包括：Hive 表、HDFS 路徑。
• 計算治理包括：Spark 任務、MR 任務。

2. Hadoop 治理架構

Hadoop 治理架構自底向上分為：元數(shù)據(jù)層、數(shù)據(jù)模型層和治理應用層。

• 元數(shù)據(jù)層包括計算元信息和存儲元信息。計算元信息有：Hadoop 執(zhí)行日志、Spark 執(zhí)行日志、數(shù)夢任務元信息。存儲元信息有：HDFS 路徑訪問審計、Metastore 信息、fsimage。Metastore 信息維護表的元信息和分區(qū)元信息。fsimage 為路徑存儲計算。
• 數(shù)據(jù)模型層基于底層元數(shù)據(jù)進行建模?；A信息包括：表血緣、任務血緣、路徑訪問、表訪問等。并基于這些基礎信息加工出計算與存儲治理項目表、計算健康分、存儲健康分、治理空間預估、主動治理收益等信息。
• 治理應用層會為用戶提供治理相關工具。計算治理方面包括：任務停用、任務刪除、任務代碼優(yōu)化、參數(shù)修改。存儲治理方面包括：表生命周期調整、表下線、表刪除、小文件合并等?；诖诉€衍生出了一些治理提效工具，如治理工作臺，以及一些自動化治理工具。

整個架構中的核心是健康分和治理項。接下來將重點介紹這兩部分。

3. Hadoop 治理項設計

治理項反映了用戶資源存在的問題，通過分析計算和存儲資源，找出治理項，進而指導相關操作。

計算治理項包括：數(shù)據(jù)傾斜、暴力掃描、參數(shù)不合理、高耗任務、無效計算、存在空表、相似加工、同源導入。存儲治理項包括：不合理生命周期、空表、無訪問表、不規(guī)范表、空路徑。

在后文中將重點介紹計算治理項中的數(shù)據(jù)傾斜和暴力掃描，以及存儲治理項中的不合理生命周期。

治理項的工作是基于元數(shù)據(jù)開展的，其中 Spark 執(zhí)行日志、MR 執(zhí)行日志是重要的信息源。通過分析執(zhí)行日志，從中提取關鍵信息存儲到 ODS 層。

Spark 事件監(jiān)聽中的重要信息包括：環(huán)境參數(shù)內存、vcore、輸入輸出路徑、執(zhí)行SQL 內容、gc 信息、數(shù)據(jù)條數(shù)、字節(jié)數(shù)等。MR 事件監(jiān)聽中的重要信息包括：gc 信息、數(shù)據(jù)條數(shù)、字節(jié)數(shù)、job 統(tǒng)計信息、Map 結束時間、Reduce 結束時間等。

利用這些信息就可以開展治理項工作。

數(shù)據(jù)傾斜是大數(shù)據(jù)工作中經(jīng)常遇到的問題，是重要的治理項。數(shù)據(jù)傾斜是在并行進行數(shù)據(jù)處理的時候，由于數(shù)據(jù)分布不均勻，導致大量數(shù)據(jù)集中分布到一臺或者某幾臺計算節(jié)點上，使得該部分的處理速度遠低于平均計算速度，成為處理瓶頸，影響整體計算性能。以 Spark 為例，Spark 為多 task 執(zhí)行，多數(shù) task 會在一定時間內完成，有少部分 task 會執(zhí)行時間較長，形成長尾效應。這就是數(shù)據(jù)傾斜現(xiàn)象，發(fā)生的核心原因是數(shù)據(jù)分布不均。

工作中通過引擎日志分析、傾斜率計算、判斷傾斜三步來識別數(shù)據(jù)傾斜?；?Spark執(zhí)行日志和 MR 執(zhí)行日志，可以獲取執(zhí)行時間、任務處理條數(shù)、任務處理字節(jié)數(shù)。獲取這些指標信息后，進而計算各項傾斜率。以執(zhí)行時間傾斜率為例，計算方法為：執(zhí)行時間傾斜率 = task 執(zhí)行時間最大值/task 運行時間中位數(shù)。最后利用判別規(guī)則識別是否發(fā)生數(shù)據(jù)傾斜，如 max(task 運行時間)>15min && 執(zhí)行時間傾斜率 > 5 && 近 33 天批次平均執(zhí)行時間 > 30min。

當系統(tǒng)判斷發(fā)生數(shù)據(jù)傾斜時，會根據(jù)數(shù)據(jù)傾斜的常規(guī)原因進行分類，并給出優(yōu)化方案。我們以兩個典型場景為例來討論：熱點 key 場景、大表 join 小表場景。

熱點 key 場景中，首先在生產(chǎn)任務中識別到數(shù)據(jù)傾斜，進一步在代碼中定位到存在數(shù)據(jù)傾斜的關鍵代碼段。關鍵代碼段中以 path_normal 這個字段進行聚合。接下來進一步分析 path_normal 這個字段在值上的分布，發(fā)現(xiàn)空值在數(shù)據(jù)規(guī)模上遠大于其它值。根據(jù)分析，給出指導意見，當 path_normal 為空值時使用 path 正常值進行替換。通過這樣的指導意見可以解決空值熱點 key 帶來的數(shù)據(jù)傾斜問題。

大表 join 小表也是生產(chǎn)中常見的問題。診斷發(fā)生這種場景的數(shù)據(jù)傾斜時，通過mapjoin 方式對小表進行廣播，來解決數(shù)據(jù)傾斜。

暴力掃描也是一個常見治理項。暴力掃描在這里的定義為：當前批次掃描分區(qū)多于365 個，并且掃描數(shù)據(jù)量大于 1G。暴力掃描識別中，解析引擎日志元信息對輸入輸出進行分析獲取掃描數(shù)量。同時，關聯(lián) Metastore與 FSImage 中的信息，Metastore 中維護了表和分區(qū)信息，F(xiàn)SImage 中維護了數(shù)據(jù)文件路徑對應的存儲量。結合這些信息可以得出本批次掃描分區(qū)數(shù)與掃描總數(shù)據(jù)量。利用這些信息可以判定是否發(fā)生暴力掃描。

在產(chǎn)品中會盡量識別出暴力掃描對應的代碼行，以便于指導用戶進行相應的暴力掃描問題處理。

暴力掃描問題出現(xiàn)的常見原因有：

• 分區(qū)篩選條件未配置
• 篩選條件過于寬泛，尤其是多級分區(qū)
• 使用隱式 Join 帶來掃描問題

以生產(chǎn)上的兩個例子來說明。

第一個例子，多級分區(qū)篩選條件寬泛。示例中的表以contry_code/year/month/day/hour 字段為分區(qū)小時表，用戶在篩選條件中只有 country_code 和 current_stat_date 字段，掃描會設計 contry_code 下面所有的分區(qū)。經(jīng)過診斷，給出建議為：將 year/month/day 分區(qū)條件補全。補全后的 SQL 執(zhí)行會精準定位到具體的分區(qū)，避免過多掃描分區(qū)。

第二個例子，隱式 Join 帶來暴力掃描。代碼中用戶左表 left join 右表，并寫了分區(qū)篩選條件。一般會直觀認為這個代碼已經(jīng)有分區(qū)篩選條件，不存在全表掃描。但是通過 TableScan 發(fā)現(xiàn)，代碼執(zhí)行發(fā)現(xiàn)有全表掃描。針對這種情況，給出建議為：寫子查詢時需要將相應的查詢條件補充上。這樣就可以解決暴力掃描的問題。

討論完計算相關的治理項后，再來看一下存儲治理項。

首先是生命周期不合理。生命周期不合理會造成存儲資源的浪費。生命周期不合理有兩種情況：

• 生命周期未設置
• 當前生命周期大于推薦生命周期

這里的核心問題是，如何進行生命周期推薦。生命周期推薦依賴于以下信息：

• 分區(qū)訪問跨度：分區(qū)訪問時間 減去 分區(qū)創(chuàng)建時間
• 表訪問跨度：分區(qū)訪問跨度的最大值
• 93 天訪問跨度：93 天內表訪問跨度最大值

生命周期推薦根據(jù) 93 天訪問跨度進行階梯式推薦。

生命周期推薦中，數(shù)據(jù)元信息來自于 HDFS 訪問審計日志、分區(qū)元信息。將元信息匯總后得到表分區(qū)訪問，進而匯總出表訪問。利用表訪問可以計算出表訪問跨度推薦生命周期。

治理項反映數(shù)據(jù)資產(chǎn)存在的問題，而健康分是在治理項基礎上進一步抽象，用于反映資產(chǎn)健康情況。健康分可以作為治理抓手使用，健康分越低，說明資產(chǎn)健康情況越差，越需要介入治理。

健康分有存儲健康分和計算健康分兩類。存儲健康分又包括：HDFS 健康分、Hive表健康分。

下面介紹計算健康分。計算健康分根據(jù)每個治理項扣分來計算，例如：數(shù)據(jù)傾斜扣40 分。各個治理項的扣分數(shù)值是依據(jù)其對數(shù)據(jù)成本的影響來制定的。數(shù)據(jù)傾斜對成本影響較大，所以定為 40 分。計算健康分為 100 減去所有扣分項。

除此之外，也會從其他視角考慮計算健康分，例如個人、項目賬戶、項目。因此，引進影響因子作為權重項。影響因子為近 33 天的平均計算消耗。影響因子反映了該資源對于所有維度下計算健康分的影響。利用影響因子對所有資源計算健康分進行調和平均，得到各個視角下的計算健康分。

接下來介紹存儲健康分。存儲健康分包括表存儲健康分和路徑存儲健康分。

表存儲健康分由三部分組成：直接得分、最低得分和各個治理項扣分情況。

直接得分規(guī)則有：

• 非可再生數(shù)據(jù)：100 分
• 非分區(qū)表近一個月有使用過：100 分
• 白名單：100 分
• 一個月內創(chuàng)建的新表：99 分
• 視圖表最近一個月有訪問：100 分
• 視圖最近一個月未使用過，直接 20 分

最低得分規(guī)則為：只要設置了生命周期，最低分 20 分。

治理項扣分規(guī)則為：

• 生命周期扣分：根據(jù)用戶設置生命周期與推薦生命周期差值，進行階梯扣分。
• 不規(guī)范表扣分：存在不規(guī)范直接扣 10 分。
• 孤立數(shù)據(jù)扣分：表路徑不存在，扣 100 分。分區(qū)路徑不存在，扣 10 分。元數(shù)據(jù)不存在，扣 30 分。
• 無訪問扣分：扣 30 分。
• 空表扣分：扣 10 分。

存儲健康得分為：直接得分不為空，則為直接得分；否則，100 減去所有扣分項后，與最低得分比較，取兩者之中的較大值。

路徑存儲健康分與表存儲健康分類似。

基于多維度存儲健康分考慮，引入存儲健康分影響因子。存儲影響因子與存儲大小相關，影響因子等于開立方（存儲大小 + 1）。

最后，來介紹一下健康分模型在日常治理工作中的應用。用戶有著不同的角色，以項目負責人為例，進入平臺后，首先使用視角切換查看健康分，包括有哪些治理項，扣了哪些分。如圖所示，生命周期是一大扣分項。點擊進入列表查看，可以使用健康分影響因子進行倒排。通過健康分影響因子可以獲取到治理收益最大的待治理任務。

平臺中與治理相關的頁面包括：健康分頁面、Hive 表治理頁面、計算治理頁面、治理工作臺頁面等。

三、ES 治理實踐

接下來介紹 ES 治理實踐。ES 治理的主要治理對象是 ES 索引模板。

下圖展示了 ES 治理數(shù)據(jù)架構。

自底向上分別為：數(shù)據(jù)源層、數(shù)據(jù)建模層和在線層。

數(shù)據(jù)源層主要包括兩部分信息：索引模板相關的基礎信息、索引相關的訪問血緣信息?；A信息包括：索引管控平臺維護的 ES 模板信息、ES-mapping、es-metric。ES-mapping 維護索引字段、類型、分詞等等，這些信息通過 ES 提供的 API 獲取。ES-metric 指標信息包括：索引的 doc 數(shù)、shard 數(shù)、shard 存儲分片、shard 存儲大小。這些信息通過運維側采集，落入 Kafka，之后使用 Flink 進行相關轉變并落入 ODS 層。

數(shù)據(jù)建模層使用接入的元信息進行 ODS、DWD、APP 各層建模。明細層包括：訪問明細、分區(qū)明細、血緣明細、訪問跨度、治理收益空間預估、治理收益核算。上層 APP 層也有對應治理表。

在線層，將治理項、治理動作透出給用戶。用戶可以進行日常治理操作，達到降本增效的目的。

從架構圖中可以看出治理項的設計是整個架構的核心。接下來就來討論 ES 治理項。

ES 治理項包括：空模板、不合理生命周期、字段優(yōu)化、未設置生命周期、33 天無訪問。

下面重點介紹不合理生命周期和字段優(yōu)化。

ES 的不合理生命周期與 Hadoop 的不合理生命周期判別邏輯一致。主要問題是如何給用戶提供推薦生命周期，讓用戶進行生命周期調整。

首先，獲取到 ES 訪問日志，基于訪問日志進行分區(qū)訪問跨度識別。然后利用分區(qū)訪問跨度匯總成索引模板 33 天訪問跨度。最后，根據(jù) 33 天訪問跨度，進行生命周期階梯推薦。

接下來，我們介紹索引優(yōu)化。

ES 對于每個 doc 字段進行正排索引和倒排索引的創(chuàng)建。正排主要用于排序和聚合。倒排主要用于搜索查詢。兩種索引都會占用存儲空間。

我們會發(fā)現(xiàn)，一些字段建立了索引，但是長時間沒有使用到。這種情況下，會推薦對這些字段關閉正排索引和倒排索引，以減少存儲浪費。這里的核心是如何識別出長期未訪問字段。系統(tǒng)識別未訪問字段的流程為：先對 ES 訪問日志進行解析清洗，然后匯總出小時級別字段訪問信息，進而匯總天級字段訪問情況，最后匯總出一段時間內無訪問的字段。對于日志索引查看 33 天訪問情況，對于其它索引查看 14 天訪問情況。產(chǎn)品中會提供給用戶無訪問字段列表，并指導用戶關閉對應的正排索引和倒排索引。

產(chǎn)品界面中包括：治理項、治理項對應的治理資料。針對不同的治理項有相關的治理動作。

以上就是對 Hadoop 和 ES 的治理實踐。

四、未來規(guī)劃

最后，分享一下未來治理方向上的規(guī)劃。

目前，數(shù)據(jù)治理每年可以為公司節(jié)約千萬的成本，然而數(shù)據(jù)治理相關人力投入相當大。未來希望在技術方面進行治理提效，通過技術手段提高治理效率，如提升自動化治理能力，讓治理成為 Daily Run 的自動任務，減少人工投入。

另一方面，實現(xiàn)智能治理，提高治理項推薦準確率，多人多面，每個人看到不同的治理推薦。

最后，實現(xiàn)預算控制，針對頂層預算進行管控，業(yè)務線、成本賬號、項目一層層進行預算管控，將治理前移，減少后續(xù)治理壓力。

五、問答環(huán)節(jié)

Q1：傾斜率計算中的常量 0.5 和 0.25 是如何估算出來的？數(shù)據(jù)傾斜的優(yōu)化是平臺根據(jù)原因自動化治理，還是需要用戶去配置參數(shù)？

A1：權重系數(shù)是根據(jù)一些數(shù)據(jù)的測算得到的，不是人為猜測制定。數(shù)據(jù)傾斜的場景是通過任務血緣、SQL 血緣識別原因類型，推薦給用戶治理方法。

Q2：生命周期推薦天數(shù)的設置依據(jù)是什么？

A2：推薦是根據(jù)表在一段時間內訪問跨度進行階梯推薦。

Q3：如何入門數(shù)據(jù)治理？

A3：首先，需要對這個方向感興趣。然后，看業(yè)界常規(guī)治理方法進行入門學習。技術方面，需要了解大數(shù)據(jù)技術組件。

Q4：生命周期過期的表是進行物理刪除，還是人工處理？

A4：目前有 Daily Run 任務進行刪除，刪除后進入回收站。回收站中三天內的數(shù)據(jù)可以進行恢復。

Q5：治理項中的公式，針對不同的需求，不同的表對應的計算不同，可以使用相同的公式嗎？有些需求復雜數(shù)據(jù)量大，可能需要的計算時間長。

A5：抽象出的計算公式是比較通用的。有些任務場景本身數(shù)據(jù)傾斜會比較嚴重，數(shù)據(jù)量規(guī)模大。從集團層面需要是同一套指標。對此類情況，還是應該看下是否有提升空間。

Q6：從滴滴內部實踐看，用戶滿意程度如何？

A6：大數(shù)據(jù)用戶目前反饋比較好，整體是正向反饋。偶爾會有小的負向反饋，也會及時答復和跟蹤處理。

Q7：一個部門可能有非常多待治理任務，您提到的治理因子是如何計算的，以及如何和成本結合起來？

A7：治理因子算法見 ppt。以存儲治理因子為例，存儲大小與成本直接相關。

Q8：政府部門受限于技術人才限制，如何開展數(shù)據(jù)治理？從哪些地方會比較容易？如何設計數(shù)據(jù)治理策略？人員不足的情況下如何做數(shù)據(jù)治理。

A8：數(shù)據(jù)治理無法面面俱到，需要抓大放小。需要查看資源情況，是存儲成本比較高，還是計算成本比較高。具體到存儲，要分門別類地看是哪一方面影響成本。在團隊能力不足的情況下，抓幾個重點去做。健康分模型和影響因子也是基于抓大放小來設計。能看清成本分布，然后開展治理動作。資產(chǎn)管理平臺也有成本管理模塊，在成本管理基礎上進行資產(chǎn)治理。