一、背景和方案

在當今的數據驅動時代，數據作為關鍵生產要素之一，其在商業活動中的戰略價值愈加凸顯，京東也不例外。

作為國內領先的電商平臺，京東在數據基礎設施上的投入極為巨大，涵蓋數萬臺服務器、數 EB 級存儲、數百萬個數據模型及數以百萬計的任務執行。每年成本上的投入高達兩位數個小目標，而且還在持續增長，成本壓力比較大。

面對這樣的成本壓力，治理是一個必然的選擇，并且不能是運動式、救火式的，而應該是持續的，需要一個規模化、常態化的治理體系。為了實現這一目標，就要應對治理中的諸多挑戰。首先，場景復雜，平臺建設是個長期過程，管控規則在不斷迭代，歷史原因導致平臺有部分作業的訪問方式跳過數據表直接訪問底層 HDFS 文件，或者繞過平臺的推數工具，直接在 MapReduce 或 Spark 里面寫入數據，導致審計和血緣追蹤困難，給治理帶來了很大風險。此外，平臺用戶較多，成本意識很難拉齊，且大家工作繁忙，主動治理的意愿較低。而且人工治理不僅成本高，風險也高，如果人工判斷不準，就會造成生產事故。

為了解決這些問題，我們首先設計了健康分和貨幣化賬單，用來量化治理的收益，幫助用戶直觀感受治理的變化。再就是打造自動化治理平臺，自動發現問題，及時通知用戶，一鍵執行，并通過量化指標來判斷收益，提高治理人效。

具體治理從以下幾個角度一起考慮：

• 多種數據源相互印證。聯合 HDFS 和 Hive 的審計日志、HDFS 的元數據以及數據血緣等數據一起校驗，避免因單一數據源引發的誤判。
• 設置多環節校驗。判斷會綜合連續多日的診斷結果，避免特殊異常波動導致誤診。
• 作業提交會進行實時校驗。當前數據作業是通過 t+1 離線模型進行計算，存在時間差，為避免時間差導致誤診，在執行時針對選擇的治理做二次校驗。
• 操作可逆。對于治理數據做自動備份，即使有誤操作，也可以一鍵回滾。
• 數據治理落地的機制保障。增加數據管理專員小組、組織機構治理負責人等角色，并明確各自職責。
• 明確目標。每年采購前，會達成年度治理目標的共識及預計的治理量。將目標拆解到每個事業部、每個部門，以及每個季度、每個月的指標，并通過周期性例行會議不斷跟進和校準。
• 完善獎懲機制，做得好會有激勵，做得不好，會在其他產品上限制其使用。

當前整個治理系統已經涵蓋了成本、穩定性、安全、質量等四個方向一共幾十個治理項。例如成本治理中表的生命周期，不僅僅按照人工設定時間定期刪除數據，還可以根據數據實際被訪問的周期推薦更合理的生命周期數值。在穩定性中的“依賴缺失”治理，防止任務執行時，上游數據還未產出，導致任務失敗。在安全方面，平臺能及時發現對安全等級打標不準，質量方向的元數據缺失，元數據標注不準以及數據質量異常等治理項，及時發現，及時處理。

二、關鍵技術

接下來介紹一下治理平臺使用的關鍵技術。

1. 審計日志

審計日志記錄了用戶在何時何地因何原因訪問了哪些數據及訪問方式，這是安全治理的基礎。

以無效任務為例（有產出，但是產出的數據沒有下游訪問），自身作業還在運行，一定有日志產生，那如何來判斷有沒有下游呢，就需要排除掉自身任務的訪問，審計當中就必須要有“任務 ID”這個屬性。另外，治理需要明確的責任人，單單靠大家主動去維護表的負責人，一定會存在錯漏的問題，所以審計一定要能識別到具體哪個人在操作，再加上數據的反算策略，來補充和校準負責人信息，確保數據一定有人負責。

原生的大數據系統，并沒有這么豐富的信息，所以需要定制化改造：

• 改造 API 協議。通過對底層 HDFS，以及上層計算引擎的適配性改造，附加了任務來源以及任務 ID 等上下文信息。
• 內容反算。原始 metastore 日志記錄存儲的是原子 API 的使用記錄（如 get_table ，get_partition），但具體操作（讀、寫、改表）沒辦法區分。平臺通過對命令的訪問序列，總結規律，生成自動識別規則進行反算。
• 數據聯合使用。Hive 審計日志只記錄表級，具體訪問的分區是看不到的。而結合 HDFS 審計來反推分區訪問的活躍程度，從而推薦合理的生命周期，避免生命周期設置的偏大或偏小。

2. 全鏈路血緣

首先介紹一下圖中的一些術語，JDQ：是京東基于 kafka 進行二開的消息隊列；JRC：京東實時數據加工平臺，主要是用的 FLink 技術；DTS：數據集成工具；Plumber in、out：數據的導入導出。

上圖展示的是正常的數據流轉過程。從生產到數倉，再到數據應用或服務的全過程來看，已經不單單在大數據平臺，要進行數據治理，如果不能掌握上下游關系，很容易出現問題。比如數倉將數據推到了應用系統，后續訪問都在大數據平臺外，如果把表的加工任務當成無效任務禁用后，就會影響業務正常運行。

除治理外，還可以利用血緣對全鏈路進行影響分析，鏈路優化等（比如一個表在任務加工鏈路上屬于第 10 層，而他所依賴的所有數據都在第 3 層，那中間的幾層依賴即為無效的，直接依賴第 3 層的加工任務來縮短鏈路，就可以更快完成數據加工）。

在不同階段會用到不同的技術，比如生產側主要用到的是調用鏈，在大數據側主要使用審計和執行計劃的解析，在數據應用與服務側主要是運用審計的能力。將各階段的數據進行整合，就可以得到全鏈路的血緣。

血緣的粒度如果只到表一級，還是存在一些局限性，在分析的時候，影響容易被放大。比如下游的表僅僅使用上游表做關聯查詢條件，他的結果當中就不會保存上游表的數據內容，在前面提到的影響分析場景，就應該排除掉。要做到這一點，就需要實現算子級血緣。

算子級血緣描述的是字段間存在的具體關系，比如是直接引用的原字段，還是做了加減乘除等轉換，是結果存儲還是僅作為關聯條件，為精細化數據治理提供支撐。比如相似表計算和重復存儲識別就需要算子級血緣來幫助判斷。我們的算子血緣實現的方案集成在了邏輯執行計劃優化的階段，和優化之后的 Hive Hook 的方式相比，可以拿到更原汁原味的血緣關系，對用戶來說更容易理解。下面就是利用血緣關系，進行主動元數據治理的一個案例。

用戶開發時，經常要去找依賴的數據在哪里，有的是直接找表，而更多的時候是找字段，比如我想要知道訂單優惠后的金額在哪，他的加工口徑是什么，這樣單純的按表來檢索就非常低效。所以我們設計了標準字段的概念，他是字段的抽象，在標準字段上可以維護更多的元數據信息，比如加工口徑，使用說明等。當標準字段和表的實體字段關聯上之后，就可以通過它來尋找字段和表。

但是如果需要大家一個個的維護關聯關系，也是個巨大的成本，在這里就可以通過算子血緣來進行提效，用戶僅需要將字段的源頭做好關聯，那么根據算子血緣關系，就可以直接算出有哪些直接引用的下游。

當然，我們這個標準字段也不僅僅是用于找數的提效，在字段元數據上維護好枚舉值、取值范圍、格式規范等信息，我們在后臺會自動檢測真實數據是否和定義匹配，異常及時觸達用戶，讓用戶做治理。這個檢測不需要提前配置，完全是系統自動行為。

三、從“節流”到“開源”

前面介紹的內容更多是如何推動業務主動治理，其目的主要是“節流”，減少不必要的占用。另一方面，我們也在尋求“開源”的手段，在不增加成本的情況下，使資源得到更充分的利用。這里主要列舉三種手段：資源混部、任務錯峰，以及跨機房的任務編排。

京東有兩大消耗大戶，分別是大數據和在線服務，基數大，而且資源缺口也大。拿在線服務來說，在雙十一、618 等促銷節點，資源非常緊缺。而離線是常年高負荷運行，利用率都達百分之七八十。當在線服務在大促峰值過后，需求就會降得很低，就可以借給離線使用。離線雖然常年是高負載的情況，但每天晚上八點后相對比較空，在大促時就可以進行在線的支援。因此資源混部的價值是很大的。

資源池化，可以根據業務特點和等級進行資源分配，進行統一調度。此外也可以進行按需分配，當大促時，離線只需要借用幾個小時不會對整體造成影響，離線可借用的空間就會很大。

資源池化落地有幾個關鍵點。

• 存算分離是基礎，計算需要做到無狀態才行。
• 容器化技術，尤其是離線計算服務的容器化。
• 資源隔離，包括各種層面的隔離（比如 CPU 網絡）。

前面講的是空間的挪移，而任務錯峰則是時間上的挪移。平臺上跑的上百萬的作業，涉及很多開發人員，靠人工設定的運行規則，不是很合理。從數據表現來看，在凌晨 3-5 點集中了 30% 的任務，導致資源搶占和高峰擁堵。還有就是父任務的結束時間和當前任務的開始時間存在大量的 gap，如果父任務結束之后的空檔期，資源負載較低的話，可以把任務做提前的編排，不光可以提高資源的利用率，也可以提升運行的時效。對整個過程中每個隊列的資源使用情況，以及任務的運行時長進行預測，并根據這個預測結果結合任務的重要度來去動態調整任務的可執行時間，即可實現削峰填谷。

第三個手段就是跨機房的任務搬遷。對于大公司來說，單個機房很難完全滿足需求，因為很少有機房能放數十萬臺服務器。另外也很難做到高可用，從安全角度來講，一般是要做到兩地三中心的架構，不同機房間的系統負載就很難相同，一定有的機房相對繁忙，另外一邊相對空閑。如果能對任務進行動態調整，把任務盡量分在空閑的一邊，就一定能跑得更快。這里比前面兩個手段要多出一項對存儲的考量，因為計算和存儲是跨機房的訪問，勢必就會帶來兩機房之間專線的額外占用。如果調度不當，就會導致專線堵塞。而且跨機房的存儲調撥，也會帶來一些更高的存儲需求。這個過程需要平衡存儲和計算的成本。

以上三個方面如果能夠做到極致，利用率就會接近一條直線，僅在均線上下小幅波動，采購就會大幅減少，甚至零采購，從而降低成本。

四、未來展望

未來的治理將在以下幾個方向繼續推進：

• 實時發現和治理。當前的數據治理主要是依托于離線模型測算，后面會做更實時的診斷與治理，盡量是在業務上線之前就做到攔截，減少事后治理的場景。
• 智能化。系統從規則化向智能化演變，讓問題的識別變得更精準、更智能。
• 自動化。現在治理需要人工參與一小部分，未來的目標是落地托管模式，實現無人化的治理。