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

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

1. 滴滴數據體系

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

2. 資產管理平臺產品架構

資產管理平臺是對整個滴滴大數據中的數據資產進行統一管理的一個平臺，底層管理包括存儲資源（如 Hive、HDFS）與計算資源（如 Spark）。

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

二、Hadoop 治理實踐

1. Hadoop 治理的對象

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

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

2. Hadoop 治理架構

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

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

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

3. Hadoop 治理項設計

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

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

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

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

Spark 事件監聽中的重要信息包括：環境參數內存、vcore、輸入輸出路徑、執行SQL 內容、gc 信息、數據條數、字節數等。MR 事件監聽中的重要信息包括：gc 信息、數據條數、字節數、job 統計信息、Map 結束時間、Reduce 結束時間等。

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

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

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

當系統判斷發生數據傾斜時，會根據數據傾斜的常規原因進行分類，并給出優化方案。我們以兩個典型場景為例來討論：熱點 key 場景、大表 join 小表場景。

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

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

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

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

暴力掃描問題出現的常見原因有：

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

以生產上的兩個例子來說明。

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

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

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

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

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

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

• 分區訪問跨度：分區訪問時間 減去 分區創建時間
• 表訪問跨度：分區訪問跨度的最大值
• 93 天訪問跨度：93 天內表訪問跨度最大值

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

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

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

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

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

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

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

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

直接得分規則有：

• 非可再生數據：100 分
• 非分區表近一個月有使用過：100 分
• 白名單：100 分
• 一個月內創建的新表：99 分
• 視圖表最近一個月有訪問：100 分
• 視圖最近一個月未使用過，直接 20 分

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

治理項扣分規則為：

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

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

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

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

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

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

三、ES 治理實踐

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

下圖展示了 ES 治理數據架構。

自底向上分別為：數據源層、數據建模層和在線層。

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

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

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

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

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

下面重點介紹不合理生命周期和字段優化。

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

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

接下來，我們介紹索引優化。

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

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

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

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

四、未來規劃

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

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

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

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

五、問答環節

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

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

Q2：生命周期推薦天數的設置依據是什么？

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

Q3：如何入門數據治理？

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

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

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

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

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

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

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

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

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

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

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