2萬字揭秘阿里巴巴資料治理平臺建設經驗

《DataFun·5週年系列技術文章》專欄·第08篇

作者 | 阿里雲DataWorks團隊 策劃 | Hoh

00

前言 

阿里巴巴一直將資料作為自己的核心資產與能力之一，透過多年的實踐探索建設資料應用，支撐業務發展。在不斷升級和重構的過程中，我們經歷了從分散的資料分析到平臺化能力整合，再到全域性資料智慧化的時代。如今，大資料平臺面臨全新的挑戰，特別是降本等資料治理需求的不斷出現，今天阿里雲 DataWorks 團隊將其中一些建設經驗與大家進行一些分享。 

01

資料繁榮的紅利與挑戰

大資料平臺的建設，到底可以為企業帶來什麼樣的價值？

對於技術同學來說，往往會用一些技術指標來衡量，例如資料量，機器數量，任務數量等等。根據我們往年已經對外公開的資料，我們可以看到大資料計算引擎MaxCompute的單日資料處理量在不斷增長，在2021年雙11的時候，MaxCompute單日資料處理量已經達到了2.79EB。有趣的是，雙11不僅僅意味著當年的波峰，同時也是來年的起點，成為了2022年日常每天的資料處理量，去年的峰值成為了來年的日常。在大資料開發治理平臺DataWorks上，單日任務排程例項數也超過了1000萬，其中也包含著業務之間50多種各類複雜的資料處理關係，保障資料正常、有序產出，如果將整個阿里巴巴集團的資料任務依賴全部展開，將會是一副非常廣闊的資料畫卷。

規模當然可以一定程度上反饋我們為業務帶來的支援，特別像雙11這種世界級的場景，對很多技術都是全新的挑戰。但是從大資料平臺到創造價值之間，還有一個很重要的環節是“人”，是大資料平臺的使用者。

對於DataWorks來說，作為大資料平臺最貼近使用者的工具層，可以看到DataWorks集團內的使用者數正在以每年5位數的量級不斷快速增長，當前每月在DataWorks上進行各類資料操作的活躍使用者數超過5萬人，除了資料工程師、演算法、開發等技術人員在上面進行資料同步、開發、治理等工作，同時也服務運營小二、分析師、財務、HR等各類業務人員，進行個性化的找數、取數、用數等分析工作。所以，大資料平臺不僅僅應該停留在資料團隊，我們要有更多的使用者進來，更多地走向業務團隊，提升資料使用的效率，讓平臺、使用者、業務達成正向迴圈，推動企業資料價值不斷釋放。

從最早的淘寶、天貓等電商業務，到後續的優酷、高德、菜鳥等板塊，DataWorks與MaxCompute等產品用一套技術體系來支援不同業務的發展與創新。因此我們認為大資料平臺的價值體現，不僅僅是資料量的增長，同時也是使用者數的增長，資料應用（業務）的增長，人人參與資料建設，為企業帶來整體的“資料繁榮”。

資料繁榮為我們帶來了紅利，同時也帶動了各類資料治理需求的井噴。從2009年算起，我們做DataWorks已經15年了，對於一款發展瞭如此之久的產品，我們走過了阿里巴巴集團幾乎所有外部知名的資料架構進化的時代，同時在當前也面臨眾多全新挑戰。在大資料平臺的建設過程中，我們經常遇到一些資料治理的問題，例如：

• 資料穩定性不足

任務排程隨著規模增大經常掛掉，不穩定，叢集計算資源不足；員工經常起夜處理告警，故障無法快速恢復；突發大流量導致資料服務當機或不可用

• 資料應用效率低

表數量越來越多，找不到需要的資料；缺少資料規範與標準，每次使用都要溝通；資料需求經常變更，數倉人員壓力巨大

• 資料管理風險大

資料使用人員多，管理與易用難以平衡；資料出口多，人為洩露行為管控難；法規不斷更新，敏感資料發現難，資料分類分級難度高

• 資料成本壓力大

降本成為大趨勢，技術挑戰大；不知道成本問題在哪，在哪個部門/人；資料不敢刪、任務不敢下

不管是阿里巴巴集團內部，還是我們服務的眾多阿里雲上客戶，和我們溝通的時候都希望聊聊資料治理相關的主題。他們面對眾多資料治理需求，往往感覺無從下手，就像“按下葫蘆浮起瓢”，每天都會冒出新的問題。我們其實沒法一次性解決所有問題，但是可以逐步解決主要問題。基於DataWorks的建設經驗，我們將企業的資料治理需求整理成四個大的階段，每個階段都有不同典型的資料治理問題，應該投入更多的精力來處理這個階段的主要矛盾，並且從這些實踐中，逐步形成企業資料治理各類方法論與規範的沉澱。

一、起步階段-資料量與穩定性的矛盾

起步階段我們最重要的是得保障“有”資料，資料不斷產生，資料量不斷增長，我們需要保證資料產出的時效性，穩定性、資料質量的準確性，這些也是數倉同學最常面對的問題型別之一。在這個時候遇到的資料治理問題主要集中在叢集上，例如任務長時間等待，計算、儲存、排程等各種資源不足，資料無法產出，或者產出髒資料，叢集掛了，運維無法定位問題，問題處理時間長，補資料止血難度大，人肉運維無自動化等等。這個時候，業務將會明顯感受波動，有些故障甚至會造成業務資損。

二、應用階段-資料普惠與使用效率的矛盾

當我們“有”資料的時候，接下來面臨的就是“用”資料，我們想要更多人來使用資料，實現資料普惠，但是用的人越多，需求也會越多，效率反而會受阻。我們的產品滿足50人使用還是5萬人使用，可以說是天差地別。這時遇到的更多資料治理需求主要集中在效率上，例如：各個部門人員找數、查數、用數需求不斷增加，使用資料人員開始增多，數倉人員疲於取數；資料開始賦能業務，各類資料應用需求井噴，資料團隊壓力增大等等。這個時候，數倉建設可能逐步變得有點混亂，甚至有走向失控的節奏。

三、規模階段-靈活便攜與風險管控的矛盾

隨著用資料的人越來越多，前臺也會建設越來越多的資料應用，帶來的各類資料風險就會增大，我們要開始“管資料”，但是各類資料安全的管理動作往往會和效率背道而馳。在這個階段我們解決的資料治理主要問題主要集中在各類安全管控能力上，例如：各類法律法規直指內部各類資料安全風險；不知道誰在什麼時候怎麼使用資料，出現一些資料洩露事件。

四、成熟階段-業務變化與成本治理的矛盾

成熟階段意味著我們能實現資料業務化，但是面對當前的環境，經常會提出“降成本”的需求。

如果業務增長、成本線性增長，我們需要成本治理

如果業務受限，成本冗餘大，我們也需要成本治理

那應該怎麼降、降哪些，對於多企業也是一個難以回答的問題。而且對於一個成熟階段來說，成本治理不應該是一個“運動式”“專案式”的工作，而應該將之前提到的各類公司資料治理的理念深入人心，形成常態化的工作。

可以看到，降本往往是在數字化建設偏後期的需求。很多人一來和我們聊資料治理就說降本，其實在我們看來，對於絕大部分企業來說，降本的需求本身並沒有問題，後面我們也會重點講解下，但不妨可以回顧下前面幾個階段，我們是否做的足夠充分，例如當前的成本高企，或許是因為第一階段堆疊了過多的人肉，又或許是因為第二階段各種人員無序使用資源。

在經歷這麼多資料治理場景和需求之後，阿里巴巴在內部逐漸形成資料模型規範、資料開發規範、資料質量規範、資料安全規範等多種方法論，並且這些實踐經驗我們也會逐步沉澱到DataWorks平臺上，讓規範落地，逐步形成全鏈路資料開發治理平臺。包含資料建模、資料整合、資料開發、資料運維、資料資產、資料治理、資料質量、資料安全、資料分析、資料服務等資料處理全鏈路流程，以一站式的大資料開發治理平臺能力，滿足資料治理中關於規範、穩定、質量、管理、安全、分析、服務等各個方面的訴求，我們在後面的各類實踐場景中還會為大家詳細講解。

▌小結

面對大資料平臺眾多資料治理問題的挑戰，我們用1套組織架構，1部資料治理方法論，1套全鏈路治理平臺來滿足各類資料治理的需求。在大資料的“起步、應用、規模、成熟”階段，對應“穩定、提效、管控、降本”等不同的目標，將精力投入到主要矛盾上，讓資料治理平臺需要緊密結合各類經驗、場景與方法論。

02

阿里巴巴資料治理平臺建設實踐

剛才我們提到了各個階段的主要矛盾與問題，接下來我們將會為大家介紹DataWorks在各個資料治理場景下的主要實踐，包含資料生產規範性治理、資料生產穩定性治理、資料生產質量治理、資料應用提效治理、資料安全管控治理、資料成本治理、資料治理組織架構及文化建設等方面。需要提一點的是，資料治理平臺的開放性也非常重要，很多場景的實踐也是DataWorks平臺與集團內各個業務部門共創和緊密合作實現的。

一、資料生產規範性治理

我們將資料規範性放在第一個講，這是很多資料治理問題的源頭，不管是第一階段的生產穩定，還是第二階段的應用提效，都和資料規範性緊密相關，我們舉幾個簡單的例子：

1. 數倉架構混亂

跨bu、跨團隊依賴較多，數倉架構逐漸混亂，逐步有失控趨勢，面臨重建危機。

2. 資料開發效率低

業務含義不清、資料模型設計與物理表開發斷鏈，有了模型開發效率也沒提高。

3. 資料指標構建難

業務需要的資料指標開發較慢，類似指標沒有批次構建的方式，缺乏指標的統一管理。

4. 找數用數難

業務資料含義口口相傳，人工問口徑耗費大量時間，交接人員也不清楚資料情況。

5. 資料穩定性差

資料混亂，導致資料產出時效受影響，資料質量穩定性不高。

6. 資料成本不斷增長

資料隨意開發、大量任務重複計算、找不到也治不了，導致成本不斷增加。

所以，我們希望在第一部分就和大家強調下資料規範的重要性，有些企業由於業務的發展，往往會忽視規範的建設，經常採用“先汙染，後治理”的方式，然後陷入各類業務需求，而良好的資料規範建設往往可以起到“事半功倍”的效果。DataWorks的智慧資料建模同天貓、淘寶、盒馬、本地生活、菜鳥等多個事業部進行共創，我們以某個事業部為例為大家講解下數倉規範性的建設思路，該業務數倉團隊從2020年開始與DataWorks團隊不斷共建智慧資料建模產品，從最初版簡單的錄入系統，到整合逆向建模、多表克隆、多種引擎的程式碼模式、excel互動等功能，最終讓整個數倉團隊的開發效率提升30%，並且下線15%不規範的冗餘的資料表。同時在整個數倉公共層團隊與業務資料開發團隊進行推廣，全員使用，成為事業部落地數倉規範的統一平臺。

數倉規範性治理的方案主要圍繞穩定性、擴充套件性、時效性、易用性、成本五大目標展開，整體方案主要包含兩部分，分別是模型線上化與模型管理&評估。模型線上化部分，首先設計了“資料架構委員會”這樣的組織保障團隊，即搭建架構師團隊，並將模型管理責任到資料負責人；接著擬定事業部數倉的規範制度，例如資料模型規範、數倉公共開發規範、數倉命名規範等；最後將規範制度和模型負責人透過產品工具 DataWorks 智慧資料建模產品進行落地。完成模型線上化只是第一步，接下來模型管理&評估是重點，透過事前模型評審、事中模型評估打分、事後模型治理推送，實現模型管理的閉環，促進模型不斷最佳化和完善。

方案設計完成後，透過對所需功能進行梳理，總結出從規範定義、便捷開發、釋出評審、業務管理四個模組來建設智慧資料建模平臺：

1. 規範定義

在前期，數倉團隊是沒有這個資料建模平臺的，大家都是以線下的建模方式，比如資料開發對 Excel 梳理後，先進行資料探查瞭解資料基本情況，之後進行模型的設計，然後再線下進行模型評審。整個模型設計和評審都線上下，最終導致大家資料建模的時候沒有形成一個規範，資料開發的過程不嚴謹，下游有了大量的引用之後，切換的成本也非常高。並且從維護角度來說，用Excel建模的方式，當數倉開發人員變動後，Excel中模型交接不便，難以持續維護，容易造成企業寶貴的資料業務知識流失。所以數倉團隊希望將規範的定義搬到線上，下圖中列出了線上規範定義的主要內容。

2. 釋出評審

之前數倉團隊的評審也是線上下進行，在架構師和工程師比較忙的時候，評審流程就不夠嚴謹，甚至沒有走評審的過程就直接釋出了，所以希望將這個功能也搬到線上去。釋出前我們會對錶命名、欄位命名進行強校驗，同時支援多引擎釋出，比如離線資料存在 MaxCompute 或者 Hive 上面，還有一部分資料存在 MySQL 或者 Oracle 上面等等。影響性檢查是模型釋出之後，對於下游的引用這個模型的 ETL 指令碼是不是有一些影響，比如有的時候新增了一個欄位，下游同學使用的時候是 Select * 的方式，而表沒有新增的這個欄位，就會導致下游任務報錯。

3. 便捷開發

這是核心重要的一點。數倉團隊希望將建模方式從線下搬到線上之後，不要影響數倉同學的開發效率，所以設計了各種提高效率的便捷開發功能。

4. 業務管理

這是從使用的角度上來說的。對於研發人員來說，有業務分類和資料域的視角，對於業務人員來說，提供數倉大圖和資料字典的視角。從成本治理的角度來說，比如一些歷史上的模型可以做歸併或下線。

這些功能落地成智慧資料建模平臺產品，從實踐來說，主要分為兩部分，首先是正向建模，相對比較清楚，基於維度建模的理論基礎，以及我們在資料中臺的眾多實踐，從數倉規劃、業務域定義、資料域&業務域過程定義、資料標準定義、維度建模、原子&派生指標定義、模型釋出七個步驟。

針對存量的歷史模型，透過DataWorks逆向建模的能力，對存量模型進行了全面分析和盤點，下線了若干歷史、低價值的模型，並完成存量模型100%的線上化管理。

以資料中臺方法論為指導，DataWorks智慧資料建模形成了數倉規劃、資料標準、資料建模、資料指標四大產品模組，成為各部門統一使用的資料建模平臺，累計形成資料模型表超過1萬張，有效提升阿里巴巴集團整體資料的規範性。

▌小結

資料生產規範性是很多問題的源頭，建議要最先考慮起來，往往能起到事半功倍的效果。資料模型是企業特別重要的資料知識，建模平臺需要透過平臺化的工具來做，而不是原先線下Excel之類的方式，一時方便，長期成本反而很高。這樣不僅能提高對內交流、應用的效率，還能防止由於員工的變更，造成企業資料知識的流失。

二、資料生產穩定性治理

資料生產的穩定性是企業在建設大資料平臺時會遇到的第一個問題，對於數倉同學來說，值班是工作的一部分，值班同學的一晚大概是這樣的：

• 凌晨1:30，收到電話告警，機器人自動播報“XX任務已延遲XX分鐘，請儘快處理！”
• 凌晨1:31，起床開啟電腦，處理告警問題，1:40、1:50、2:00，電話告警不斷轟炸，手機不斷震動，前往客廳辦公
• 凌晨2:00，對於上下游任務邏輯不太清楚，拉起一批同學起夜
• 凌晨3:00，老闆被Call醒，打來電話詢問情況，溝通後續處理方案
• 凌晨5:00，所有任務處理完成，等待叢集資源計算資料
• 上午7:00，睡眼朦朧，起床前往公司上班
• 上午9:00，剛出電梯口，被業務小二圍住追問資料產出時間，並開啟一天的工作

可以說，天下數倉同學苦值班久矣！在阿里巴巴內部，當我們在做資料穩定性治理的時候，往往會圍繞兩個核心指標進行最佳化，分別是起夜率與基線破線率。

• 起夜率

指在日常工作中，數倉值班同學需要起來處理問題的天數佔比全年天數，如果一個晚上無事發生，數倉同學不需要起夜，我們也引用了遊戲中的一個概念，稱為平安夜，起夜率相對越低越好。

• 基線破線率

基線是DataWorks獨創的理念，在基線上我們可以為任務設定最晚產出時間。例如當天營收資料，最晚產生時間設定為凌晨2：00，如果這個任務最終產出超過2：00，那麼這條基線就破線了，基線破線率同樣也是越低越好。

在治理實踐中，通常是以下流程：

1. 基線配置

梳理團隊核心資料產出任務與鏈路，確定基線任務分級，將不同的任務配置1/3/5/7不同的基線等級，同時配置基線產出時間與告警餘量。告警餘量是一個非常重要的概念，類似搶救時間。例如剛才我們提到的任務產出時間設定為凌晨2：00，如果告警餘量設定成1小時，基線會預測任務產出時間，如果時間超過凌晨1：00便會進行告警，方便我們提前知曉核心任務的產出風險。

2. 基線治理

基於基線功能以及一些後設資料，數倉團隊針對基線告警進行治理，包括告警的認領、評估、處理等，同時會針對基線告警進行根因分析，看下是由於什麼原因導致的資料穩定性問題，常見的有據質量報錯、SQL語法報錯、系統環境報錯、許可權報錯、同步任務報錯等，進行生產穩定性的根治治理

3. 穩定性評估

最終，團隊產出穩定性週報，每週報告基線破線率及平安夜數，在值班手冊中，也會形成常見問題排查寶典，治理問題清單，將穩定性治理的經驗沉澱成團隊共同的知識資產，並且進行責任公示，設計獎懲制度、達到穩定性治理正向迴圈。

智慧基線可以說是DataWorks中守護資料安全生產的核心功能，裡面結合了DataWorks多項運維診斷和MaxCompute引擎能力。

1. 智慧分級排程與資源分配

當1個任務被設定1/3/5/7不同的基線等級後，整個平臺執行的時候會按照優先順序為核心資料產出進行重要性分級，高優先順序任務及其上游，將獲得更多的任務排程與MaxCompute的計算資源，以保障高優先順序任務的執行資源。DataWorks也將其中涉及眾多排程與資源分配的核心技術申請了國家專利。

2. 智慧預測與告警

1個核心任務可能會前置依賴多個任務，當我們在最終產出的任務節點配置基線後，前置的依賴任務就不需要再逐個配置運維告警了，將會極大提升運維效率。任務開始執行時，DataWorks會回溯依賴鏈路上所有任務的歷史執行記錄，同時結合平臺當前執行及叢集資源情況，每30秒重新整理智慧預測資料產出時間。例如設定核心任務期望產出時間基線在2：00，在核心鏈路中間，有個平時20：00產出的任務20：30仍未產生，結合當前叢集水位情況，判斷將會導致希望在2：00產出的最終核心任務延時，那麼數倉同學將會在20：30就收到告警，提前干預處理延遲任務，而不是等到最終2：00任務已經延時了，才開始處理。

3. 全鏈路智慧診斷與排障 

提前收到告警後，運維同學也會在DataWorks的運維中心處理告警任務， 在DAG圖上檢視上下游及每個週期例項的執行情況，透過執行診斷排查全鏈路上的告警問題，例如上游依賴告警、當前任務定時檢查，排程資源檢查、MaxCompute資源檢查等等，可以快速定位並排障。

智慧基線的配置及故障處理參考下方，針對任務責任人和值班人不同的情況，DataWorks還設定了值班表的功能，可以將不同責任人的告警訊息統一推送給當前值班表對應人員。

以內部某個數倉團隊為例，在穩定性治理之前，團隊每週需要2.5人日進行值班，其中每年損失的不僅僅是135天的值班人日，凌晨起夜的同學135天日間的工作效率也會收到極大的影響，嚴重喪失工作的幸福感。穩定性治理之後，團隊7級基線的破線率從每月的4次降低到了0次，值班同學起夜率從97%降低到了33%，同時極大地提升了員工的工作倖福感，這也是穩定性治理的重要意義。

▌小結

資料生產穩定性核心會用起夜率和基線破線率來衡量，透過圍繞智慧基線構建的全鏈路運維診斷能力來支援穩定性建設。智慧基線可以基於叢集當前水位，歷史執行情況，智慧分配計算與排程資源，讓核心資料優先產出，並提供智慧告警的能力方便提前干預處理。另外，穩定性的治理對於員工的工作倖福感也是非常大的提升。

三、資料生產質量治理

在我們針對資料生產穩定性進行保障過程後，往往同步會關注到的，就是資料生產的質量問題治理。資料質量的好壞，往往對業務側所要執行的決策和流程有著直接關聯，各種場景不但需要能“成功獲取資料”，還需要能“成功獲取正確的資料”，這樣才能實現業務側的成功。

以阿里集團最常見的電商包裹場景舉例，我們能看到，當一件包裹上出現了資料質量問題後，能引發不同維度上的業務問題。

通常在實際生活中，我們針對包裹會有重點關注的基礎數值屬性，比如包裹的重量、體積，因為會和包裹的價格、包裹的運輸安排都有關係。當出現這些屬性不符合預期的情況時，就會出現針對這件包裹的各種業務問題的追查。

例如，當重量值為空值時，或者等於0的時候，按資料規則反應現實過程，則是出現了沒有重量的空包裹，這是不符合對物流和計價的業務要求的。而當重量、體積值超過了正常定義的閾值時，例如1個小包重量很大，按實際情況也是不合理的情況。

所以，當出現這種資料質量問題時，我們就會關注，到底是業務上出現了真實問題，還是實際資料加工過程出現了汙染。如果真實業務沒問題，而是資料出現了問題，則會影響到後續針對包裹的結費計算、運輸網路的規劃、供應鏈最佳化等等。平臺與消費者、平臺與商家、平臺與供應商之間的互動，都會被資料質量問題所影響。

而這些資料質量問題，如果沒有治理管控，則會在資料生產過程非常普遍地出現，如資料殘缺不全、資料不一致、資料重複等等，導致資料不能有效地被利用，影響資料可靠性保障和有效的業務產出。所以資料質量管理，需要如同產品質量管理一樣，貫穿於資料生命週期的各個階段。當生產環境中產生了與現有規則不符的持久化資料，或資料延遲的問題，則定義為「資料質量問題」。其中引發故障的，則定義為「資料質量故障」。而資料生產質量治理的過程，也就是我們為了避免「資料質量問題」所要建設的重要體系。

我們從業務出發，從對業務側最核心關鍵的業務實體，進行資料質量需求的梳理，來明確資料質量問題。如針對電商交易，最關心的就是商品、使用者、計費、營收方面資料的質量情況。那什麼是影響這些業務實體生產穩定性的關鍵質量要求呢？在阿里巴巴內部，面向這類商業產品的資料服務支撐流程中，重點會關注以下兩大方面：

（1）面向商業級服務的資料質量高保障要求：由於在阿里巴巴中臺裡，資料大量以服務的形態，提供給各個商業化的業務應用，因此，這意味著不只是資料本身產出的保障，也直接影響著最終業務側承諾質量的保障。

比如，由於更多客戶業務根據資料進行決策，資料高準確性要求也因此出現，對資料準確性的不再只是滿足一定的資料分佈即可，需要結合更多的業務知識對資料準確性進行更準確地評估。再如，由於部分TOB業務對資料產出的時效性有一定要求，單一架構的資料庫可能不能完全滿足業務的產出速度需要，需要異構資料庫合作進行資料鏈路建設，因此如何保證異構資料的一致性也是需要解決的問題。

（2）對資料質量協作保證過程的高效率要求：多角色流水線作業下，如果要保證資料質量，除了需要制定資料質量規範外，還需要在各環節完成對應事宜，比如研發環節、測試環節、監控環節都有面向各環節要完成工作的人員，分別需要到各模組各自操作，往往還會出現重複性工作，比如質量測試的用例，和質量監控的設定邏輯，通常是類似的，需要能有平臺工具，幫助多角色使用者，針對資料鏈路中所產出的所有線上資料質量問題，進行彙總，分析；能幫助質量小組，把紙面要求、規章制度中定義的資料問題，能定期覆盤，轉化為資料度量落在系統中；能反推研發各階段，共同高效地提升資料質量。

在這些關注點的牽引上，阿里巴巴資料質量的全流程體系，相應地在如下領域完成重點增強。

針對多角色協作式的資料流程，基於DataWorks了提供統一的資料質量平臺工具，能在一個平臺上流水線式地完成所有協作過程。圍繞開發、部署、運維和監控環節的工具能力提升，極大簡化了資料團隊各角色的日常工作流程。在持續監控的資料質量監控的基礎上，加強事中防控質量問題，事前預防校正問題維度，讓資料質量在每個環節起作用，各個角色側都能高效落地。  

1.事前：在研發過程中保障程式碼質量，提前規避質量問題，透過程式碼檢測、質量自測的能力讓研發可以提前消滅問題；

2.事前：讓測試更有效地進行質量測試，提供上線前的冒煙測試、對比測試，從之前僅完成基礎功能驗證的測試，完善擴充其測試維度，不斷積累圍繞業務承諾要求的規則，從而讓研發和運維都能夠進行快速地自動化測試，持續進行資料鏈路的部署更新

3.事中：資料質量檢測任務直接關聯排程任務產出。做到資料即產出即檢查，當高保障資料任務執行時，上游資料出現髒資料時，能及時阻斷任務，規避質量問題資料對下游的影響，並透過告警機制及時提醒使用者進行任務處理。

針對需要高保障的大批次資料表的質量管理需求，也能讓質量責任人以低成本方式，提升規則覆蓋率，減少人工配置負擔，降低閾值設定難度和規則誤報率。而在海量資料、多種資料種類情況下，由系統保障平臺效能，做到大資料量下質量監控仍能高效執行，並且儘可能減少對業務資料鏈路產出的資源消耗影響，做到以最小成本執行。面向複雜資料架構的場景時，也能針對多種引擎下的資料，持續地保障資料的一致性及質量管理的延續性。

資料質量規則作為承載保障體系的重要載體，從人肉防控梳理，做到平臺規則沉澱的自動檢測，最終走向質量高效化的智慧管理。這裡面有大量的基礎性工作：

• 透過管理機制和平臺體系，讓每一張資料表都有負責人
• 平臺能自動追溯表與表之間的血緣關係
• 末端表標註業務重要性，向上追溯鏈路中的表，以業務作為抓手來治理質量問題
• ETL作業統一排程，質量監控與排程系統整合，做到事中即時智慧管控

平臺整個完成面向不同業務實體的質量治理過程，由平臺側和質量保障小組，不斷沉澱通用平臺側和業務維度側的質量規則模板。整個過程中，針對不斷產生的新的資料表及相似業務，提供快速模板化規則配置、規則推薦，並根據歷史的業務執行結果進行動態閾值的智慧判定，減少新資料和新使用者的配置成本，減少對需要關注指標及資料的質量治理的遺漏，全面提升資料可信度與價值密度。

最終沉澱為針對資料生產過程的質量穩定性全流程保障方案，從平臺、規範、組織三方面完成了相應建設和沉澱，根據實際的業務流程和資料流程完成。

1.質量治理策略：建立線上資料質量問題管理處置機制

2.質量問題監控：建立全流程資料質量問題的監控和預防體系

3.質量協同處理：建立上下游協同的工作流程

4.質量度量評估：建立可複用的資料標準和統一的質量評估體系

最後，我們還是要從業務關注我們的治理效果，以開頭舉例的包裹質量問題為例，透過資料質量治理的建設，以及圍繞業務物件的協作規則沉澱。

不僅從資料端，能夠完成對資料的異常監控、推送和分析，使得可以及時對資料質量異常問題進行修復。

同時，從業務端，也針對測試的資料，透過規則進行了前置校驗，在資料流入時就進行了限制和告警，也能讓業務端小二也能進行異常情況的責任判定，透過標準質量資料修復動作進行資料修復。

整體包裹引數的資料準確率提升至99%以上，透過資料質量治理也推動了業務流程在質量保障環節的最佳化，最終為我們的業務高價值服務進行了更好地保障。

▌小結

資料生產端的治理除了規範性、穩定性，還包含了資料質量。資料質量問題往往能直接產生業務問題，所以資料質量管理，需要如同產品質量管理一樣，貫穿於資料生命週期的各個階段。在持續監控的資料質量監控的基礎上，資料質量平臺加強事前預防校正問題、事中防控質量問題的能力，以及各類使用者智慧配置、智慧閾值判定等能力，讓資料質量在每個環節起作用，各個角色側都能高效落地。

四、資料應用提效治理

剛才的資料生產穩定性與質量穩定性，更多解決第一階段“有”資料的治理問題，接下來進入第二階段，進行資料應用的時候，一線的業務同學在使用資料時也會碰到眾多難點。例如：

• 找數難

想找的資料，不知道去哪找，特別是用業務術語去找的時候

相似表太多，不知道用哪個

搜尋的結果太多，需要逐一點選檢視

搜尋的結果不準，很多和自己的業務不相關

• 用數難

表命名奇怪，欄位沒有註釋，缺少文件

表註釋太簡略，沒有有效資訊

人工問口徑耗費大量時間

很多表的owner是被交接的，也不清楚業務邏輯

如何快速開放資料或者構建個性化資料應用

面對這些問題，使用者找數/用數等應用場景的提效需要多管其下，比如最開始提到的資料規範，如果資料模型做好了，就可以在源頭上提升資料的可讀性，避免針對資料釋義的多次頻繁溝通，並消除資料指標的二義性。

基於元數管理的能力，DataWorks提供資料地圖功能。在資料地圖裡，可以實現後設資料的自動採集與資料目錄能力，針對找數常用的檢索功能，提供表/欄位/模型/指標等多種檢索能力，並提供資料血緣能力，例如業務同學檢索到一張北京地區商品營收表時，想檢視全國的營收資料，就可以透過血緣檢視這張表的上游或者下游表，快速獲取對應資料。部分新來的同學對企業內部資料情況不是很熟悉，資料地圖還支援將各類常用表作為官方資料專輯給到所有使用者，並且在搜尋時會推薦資訊更加完善的表。

資料建模與資料地圖解決了大部分的找數問題，在用數階段，DataWorks提供了統一的SQL查詢分析工具，找到表後透過SQL的方式就可以直接進行快速查詢，裡面在今年更新了眾多的體驗最佳化能力。

• 頁面佈局可以切換上下佈局和左右佈局，左右佈局可以更好利用一些外接顯示器場景，顯示資訊更多
• SQL編輯器提供自動的程式碼補全，程式碼格式化、程式碼高亮等能力
• 查詢結果展示可以分為明細資料模式和圖表模式，支援拖拉拽進行快速地圖表編輯
• 針對資料的上傳和下載開通了快捷入口，也支援針對資料下載條數進行管控

資料分析是方便業務同學直接使用，但是面對更多複雜的業務需求，必須採用定製化的開發形式，在這個時候，資料治理平臺也需要提供更多的開放性，來滿足不同的需求。DataWorks除了0程式碼生成資料服務API的能力，還提供了整套開放平臺能力，包含OpenAPI、開放事件以及擴充套件程式（外掛），允許使用者自有系統與DataWorks進行深度對接，以及對DataWorks的處理流程進行自定義，業務部門可以自定義資料治理需求與應用能力。

DataWorks與阿里巴巴集團內部多個部門合作，目前各個事業部累計模型表數超過1萬張，核心表使用人數提升64%，開放平臺API日均呼叫次數超過1500萬次，平臺月活躍小二超過萬人，取得了一定的效果。

▌小結

資料應用提效治理從資料建模、資料地圖、資料分析、資料服務、開放平臺等方面進行多管齊下的治理，展開講的話內容非常多，涉及了我們大資料平臺使用者可能使用到的各個角落，可以說是一個注重體驗的系統性工程。另外面嚮應用，DataWorks還在構建一個資料資產平臺的產品，從使用的維度對資料進行更好地整合，方便使用者更高效地使用資料。

五、資料安全管控治理

當有越來越多的人來使用資料，那安全管控就會成為一個比較頭疼的問題，絕大部分的管控行為就是“反便捷”的，用的人越多，影響越大。不論是阿里巴巴自身還是其他企業組織的大資料體系，在安全管控方面有以下幾個痛點：

• 儲存量大、使用者種類多：由於資料倉儲/資料中臺是整合的、反映歷史變化的，因此註定了企業的資料倉儲集中儲存了各部門、各業務系統的資料，阿里巴巴內部的一張寬表動輒達到TB級別的儲存量、每日新增上百張表與數百GB是不可避免的事，這些資料不僅包含結構化資料，也包含非結構化、半結構化資料。如果我們希望將這些資料進行精細化的管理加密，會導致資料分級分類成本過高、耗時較長及遺漏的問題。
• 使用者基數大、使用者種類多：資料中臺是用於服務企業決策、日常分析的基礎設施，在資料採集階段，通常由開發人員配置任務將資料匯入至數倉，加工階段由資料工程師進行程式碼開發與側，使用階段則由各類運營、分析師透過各類Client來進行即席查詢，也包括某些業務系統的直接呼叫。之前我們提到了，阿里巴巴，每天有數萬名員工（包括：開發、運營、分析師、銷售、HR等崗位）以各類方式接入使用資料倉儲。如此多的人員授權就成為了難題，特別是在人員入職、離職、轉崗場景，管理員需要花費大力氣維護人員許可權，非常容易出現過度授權、許可權蠕變等問題。
• 客戶端操作介面多樣性：在使用資料倉儲的人員中，部分開發人員會透過命令列直連，大多數人員則是透過視覺化介面與自己的認證資訊連線使用。由於不同資料應用所提供的服務、所服務的群體不一樣，因此某些業務團隊會自行開發適合自己的客戶端介面以達到業務所需效果。而實際上授權過後的操作行為就是不可控的，各介面上的人員操作是否合理、是否符合工作所必需的原則是難以管控的。
• 資料流轉鏈路複雜：資料在採集&傳輸、生產&開發、分發&使用階段都涉及不同的流轉鏈路。在採集&傳輸階段，工程師可能透過離線、實時鏈路在內網、公網進行資料傳輸；在生產&開發階段，少量資料會被從開發環境載入到生產環境用於測試，大量資料則會設計跨專案、跨DB讀取與寫入；在分發&使用階段，由於不同業務系統處於不同網路環境，因此存在大量資料迴流（出數倉）行為，這些行為可能透過資料服務API、離線同步鏈路來實現，同樣可能涉及公網、內網。如此複雜的流轉鏈路對加大了管控某些不合規資料流轉行為的難度。
• 結果資料交付：數倉中最終可用於支撐分析決策的資料絕不是透過簡單邏輯就能加工得出的，通常會涉及多團隊、跨系統、多處理邏輯的交付，常見的資料產出邏輯可能涉及透過多個業務團隊的資料，需構建十多個層級、總共上百個加工任務的工作流程（DAG）來使用。對不同團隊的資料可用性、完整性管理，成為了企業安全管理員一項艱鉅的挑戰。

之前，阿里巴巴就聯合中國電子技術標準化研究院、國家資訊保安工程技術研究中心、中國資訊保安測評中心等20家業內權威機構聯合編寫國家標準DSMM（資料安全能力成熟度模型），可讓企業更清楚自身資料安全水位，並採取有效措施提升資料安全防護能力，從而有效保護消費者的資料安全。目前，以DSMM為抓手，在阿里生態內進行資料安全治理實踐，對生態企業根據其資料安全能力進行分層管理，實現業務與安全掛鉤，促進生態企業主動提升資料安全能力，接下來我們將會介紹一下在DataWorks平臺層面一些安全管控經驗。

• 梳理敏感資料資產清單並分級分類

資料安全治理的第一要務是梳理資產並對其進行分級分類，這已經成了資料安全行業的共識。面對PB級別龐大、每日新增的資料，人肉梳理是不現實的，因此我們會在“資料保護傘“上基於名稱匹配、正則匹配、行業AI分級分類别範本來配置資料識別規則，透過這種智慧化的方式，可以快速發現敏感資料並進行打標。另外，除了一些表資料，資料安全還包含了一些類似資料來源、任務、規則等非資料類的敏感資料，也是需要在梳理的範圍之類，很多資料安全事件往往來源於這些非資料類資產的違規操作。

• 建設安全能力並選定安全控制

基於各類法律法規的合規要求，我們建設了“識別->防護->檢測->響應”各階段的資料安全技術工具能力，這些能力也會同時覆蓋資料安全防護全生命週期，接下來我們會介紹幾種典型的資料安全治理場景。

1. 角色劃分與許可權控制

為了方便使用，DataWorks提供了多種方式，例如平臺內建了分析師、資料開發、運維等角色，基於角色的常見職責，分配角色後會直接賦予一些該角色的常見許可權，不需要再逐個勾選。那基於一些特殊的定製化許可權，我們也提供了OpenAPI的形式進行自動化地授權，實現人員自動新增/自動授權/按需申請許可權，讓團隊內分權管理、各司其職，規範化開展資料生產開發流程。同時，針對一些敏感資料，還可以自定義審批流，進行訪問控制，例如L1資料僅審批到表Owner、L2資料審批到部門安全負責人，L3資料審批到CIO等管理層。

2. 資料脫敏

雖然有些人已經申請了表的許可權，但是針對一些敏感資料，我們還需要開啟更高階別的保護。例如資料脫敏功能可以針對已經識別的敏感資料，進行格式加密、掩蓋、HASH加密、字元替換區間變換、取整、置空等多種方式，這樣我們就可以實現敏感資料的去標識化（脫敏），達到保護的目的。

3. AI風險識別模型

風險行為肯定不止查資料這種行為，DataWorks內建了AI資料風險行為治理，基於智慧UEBA引擎配置各類風險規則，採集分析使用者行為並智慧判斷各類諸如惡意資料訪問、惡意資料匯出、高危變更行為是否需以告警、阻斷、審批等操作進行響應。在此階段，我們會配置諸如資料大規模查詢展示/複製/下載、資料DROP/DELETE/UPDATE、單位時間資料操作偏離、匯出大量敏感資料、高敏感查詢條件、事件發生時間異常、資料服務API釋出、資料跨域同步等阻斷或審批規則，以此來防範人員因蓄意或安全意識缺乏、誤判而導致的不合理行為、風險、損失。

4. 資料安全治理成效

 在上述相關治理動作落地後，我們在合規、攻防、降本提效方面都取得了明顯成效。

• 滿足國內包括但不限於等保2.0的所有安全測評。
• 每日自動化發現敏感記錄值、核心表訪問流轉風險。
• 100%釋放用於資料梳理、分級分類、風險發現的巨大人力。

▌小結

資料安全治理的需求多數來源於由於法律法規的要求，以及大資料平臺使用者增加帶來的安全風險，而管控和效率絕大部分時候又是相背的。所以在安全治理的時候，我們不僅僅在平臺基礎能力上要滿足各類安全合規的要求，同時需要提供類似敏感資料智慧識別與分類分級、智慧風險行為識別、自定義安全審批等一系列平臺能力，儘量減少使用者的使用成本，提高管控效率。

六、資料成本治理

最後終於講到了成本治理，其實如果有仔細看前面幾個場景的實踐的話，會發現多多少少也有很多成本治理的事情或者效果在裡面。就像我們在前面梳理企業大資料發展階段的時候說過，降本的需求往往在成熟階段產生，並且同時包含了前面幾個階段需要做的事情，企業在有降本需求的時候，不妨可以先回顧下前面幾個階段，我們是否做的足夠充分，例如當前的成本高企，或許是因為第一階段堆疊了過多的人肉，又或許是因為第二階段各種人員無序使用資源。

從我們的觀點來看，成本治理的方案核心主要包含了以下三個部分。

• 治技合一

這裡的“技”包含了技術平臺與技術人員，成本治理的目標絕不僅僅是下線幾臺機器，通用技術平臺的構建至關重要。例如DataWorks這種工具型產品，主要是服務技術人員，提升工作效率。這裡的“降本”，可以把它等同於“提效”，讓1個人能做更多的工作，也是降本的一種方式。關於成本治理的理念、方法、流程，我們都透過產品技術平臺的方式內建，將使用者關注的各項維度的治理方法流程化提供，在研發同學完成資料開發的過程時，就完成了資料治理，並且能提升各個環節參與治理的研發同學的治理技能與治理效率。所以，我們的治理一定要沉澱成企業通用的技術資產，從而提升技術人員的治理能力與效率，達到治技合一。

• 全鏈路資料治理

基於平臺之上，我們構建全鏈路的資料治理能力，從資料生產到資料消費的每個環節，我們都會針對每個環節的具體問題進行相應維度、相應問題項的定義，完成針對性的成本治理最佳化。每個鏈路上微小的最佳化，才能實現整體成本的不斷降低。

• 組織設計與常態運營

最後我們需要各類組織架構、規章制度、運營活動來不斷推動資料治理工作在內部落地。在阿里巴巴內部，我們常用儲存健康分、計算健康分等指標，發起集團各團隊資料治理戰役，圍繞健康分為核心指標，推動人做資料治理和管理。大家在各類培訓、比武中，不斷展示、學習各類不同的資料治理場景，讓我們的資料治理工作可量化，持續化進行。

成本治理策略分析

成本治理大的目的都是推動以“更低成本”換取“更高”的最終業務價值。這裡的成本同時包含了人與機器，這也是我們一直在強調的成本治理不要僅僅關注機器的成本，例如我們用3個人，能完成原本5個人的工作，這種提效也是一種降本的形態。回到技術人員關心的具體要做的事情上，成本治理的策略主要可以關注三個層面，

• 基礎設施

主要指傳統的機房形式，涉及硬體的採購、選型、最佳化等等，這裡大部分工作一般由阿里雲負責，不需要我們投入太多精力。

• 引擎能力

主要涉及儲存與計算能力的最佳化，例如提高儲存的效率，壓縮比，提高單位計算的能力，提高分散式排程的能力等等。

• 平臺能力

主要涉及工具平臺，例如高效地進行資料開發，將各類治理策略平臺化，快速發現、解決、量化各類資料治理的問題。

這些動作最終是為了實現我們成本治理的業務價值，例如整體集團節省了多少成本，某個事業部達成了多少的降本目標，某個業務板塊的ROI等等，接下來，我們將重點針對引擎能力和平臺能力做詳細的介紹。

引擎降本-MaxCompute&Hologres

首先我們提到對於引擎側的降本，是要向核心技術要紅利。DataWorks在阿里巴巴集團結合阿里雲ODPS一體化大資料智慧計算平臺能力，不斷突破價效比世界記錄，滿足多元化資料計算需求。阿里雲ODPS（OpenData Platform and Service）自2009年開始建設至今，提供規模化批次計算、實時互動式計算、流式計算等可擴充套件的智慧計算引擎，是目前中國最早自研，應用範圍最大，能同時支援超過10萬臺伺服器平行計算的大資料智慧計算平臺。其中大規模計算批次引擎MaxCompute在TPCx-BigBench-100TB測試中，連續6年穩定全球冠軍，2022年，MaxCompute評測結果效能較2021年提升40%，同時成本下降近30%。實時互動式計算引擎Hologres在2022年TPC-H 30000GB效能評測中，獲得世界第一，超過原世界記錄23%。

這些記錄背後是ODPS持續13年深耕自研技術的成果，ODPS-MaxCompute基於盤古儲存，提供高效能的儲存引擎，儲存成本比Apache ORC和Parquet節約20%和33%儲存空間，計算效率對比Apache ORC和Parquet分別有30%和40%的效能提升。伏羲大規模分散式排程系統在全區域資料排布、去中心化排程、線上離線混合部署、動態計算等方面全方位滿足新業務場景下的排程需求，在單日任務量千萬級、單日計算量EB級的壓力下，保障了基線全部按時產出。強大的高效能SQL計算引擎完整支援標準SQL(TPC-DS 100%相容)且支援Hive/Spark相容，一套SQL引擎支援離線、近實時分析、互動式分析場景，TPC-H指標上領先Spark 3X以上。ODPS-MaxCompute連續六次突破效能/成本世界記錄，也是釋放雲上技術紅利的最佳詮釋之一。 

ODPS-MaxCompute在2022年全新發布了彈性CU能力，在過去預留 CU 的基礎上，可以設定不同的彈性策略，選擇指定時間段的彈性規格。一方面降低使用成本，避免過去為了高峰期的執行效率，預留較多 CU，在低峰期浪費資源的情況，透過彈性實現削峰填谷。例如原先為了保障資源穩定性，購買100CU包年包月資源，但是這100CU使用效率是不一樣的，凌晨高峰期使用率高，白天使用率低，資源有一定浪費。彈性CU的方式可以購買更多的分時彈性CU資源，例如高峰期300CU，低峰期50CU，實現資源的彈性分配。基於原先按量付費以及包年包月形式，ODPS-MaxCompute彈性CU可以讓整體成本再降低25%，多種靈活的資源使用方式帶來TCO的最低。

在傳統的資料架構中，分為離線、實時、線上三種鏈路。

• 透過如Hive，Spark，MaxCompute等離線加工引擎處理大規模資料
• 透過如Flink、Spark Streaming等流式加工技術來實現計算前置，並將計算結果儲存在HBase、Redis等系統提供快速訪問
• 透過Clickhouse、Druid等實時系統，計算規模不如離線，但互動式分析能力比離線統計更靈活，支援資料的實時寫入，以資料接近源時的狀態直接靈活分析。這種紛繁蕪雜的複雜架構帶來的是極高的維護成本與技術成本。

這三種鏈路對應不同的技術架構及儲存引擎，資料產生了割裂，割裂之後還需要補充聯邦查詢技術，對外提供一個統一的查詢入口，但是資料散佈在不同的系統裡面，也許可以解決統一資料介面的問題，但效能和一致性很難保證，效能上聯邦查詢是和最慢的執行過程對齊，一致性上一個源頭多條鏈路，加工邏輯很難保證處處一致，日常資料偏差和核對工作量很大。

ODPS-Hologres提供高效能的實時互動式計算引擎，基於一站式實時數倉的HSAP（Hybrid Serving & Analytical Processing，分析服務一體化）理念，同時滿足OLAP分析、點查、互動式查詢等多種實時需求。

• 在離線方面，透過統一儲存，統一排程、統一後設資料、和MaxCompute無縫打通，資料無需匯出至Hologres，實現離線實時一體化架構。
• 在實時與線上部分，Hologres在儲存層，既支援批次資料的匯入，也支援線上的實時寫入與更新，不管是離線的資料還是實時的資料都可以儲存在一個系統，在服務層，支援多種負載，保證了高效能的線上點查應用，也支援靈活的多維分析，提供統一資料服務層，減少資料割裂。

透過這種全新的方式，Hologres將傳統的離線、實時、線上三種鏈路進行最大的簡化，透過1.3億TPS寫入，億級資料亞秒級查詢，打破TPC-H世界記錄的極致效能，實現成本與效能的平衡。

2022年，Hologres釋出一主多從的模式，透過共享儲存再次降低實時數倉的成本，共享儲存實時高可用，多Region部署資料自動複製，秒級災備，當指定一個例項是寫例項時，其他例項就是讀例項，當寫例項寫好之後，其他例項實時可見做到了資料一致性。並且彈性計算層的例項實現物理隔離，當寫入例項當機後，不會影響只讀例項。

▌小結

引擎降本核心是向技術要紅利，不斷突破技術的極限。阿里雲ODPS（OpenData Platform and Service）自2009年開始建設至今，提供規模化批次計算、實時互動式計算、流式計算等可擴充套件的智慧計算引擎，是目前中國最早自研，應用範圍最大，能同時支援超過10萬臺伺服器平行計算的大資料智慧計算平臺。

平臺降本-DataWorks資料治理中心

有了良好的基礎設施和引擎體系，再往研發平臺和研發過程走一層，就是面向我們的成本治理目標的治理策略的落地，其實就是圍繞著我們實際多角色、多業務、持續增長的資料需求帶來的資料治理工作了。

• 業務高速增長往往配套著計算儲存成本的增長，而當面對計算儲存的擴容需求時，資料治理組、業務資料治理組、財務等多個團隊，需要有一個通用的衡量標準，來判斷是否是滿足正常業務需求增長所需的資源消耗，還是存在大量資源使用不合理和浪費現象。
• 而對於技術團隊來說，如果要進行面向成本領域的資料治理工作，那到底是業務領域的研發團隊需要重點投入，哪些團隊來負責治理效果，具體落實治理動作的責任人是誰，透過哪些措施和動作真正最大程度地提升了治理效果，獲取了更高的業務ROI，這也需要有一個衡量標準來定義治理的效果。

DataWorks資料治理中心提供了資料治理的量化評估、資料治理問題自動發現和預防，資料治理問題快速處理等能力，將書面的資料治理規範落地成平臺化的產品能力，讓資料治理不再一個 “階段性專案”，而是一個“可持續的運營專案”。

在阿里巴巴內部，我們做資料治理的時候，經常會參考一個健康分的概念。對於某個BU來說，比如我們今年的目標之一，就是把健康分從60分幹到80分。健康分涉及的治理領域有計算、儲存、研發、質量、安全等各個方面，圍繞這些領域會形成具體的治理策略與方法，這些策略和方法有些事集團統一的規定，有些是部門基於自己的業務情況自己制定的，但基本也都是圍繞分析、診斷、定位、最佳化、評估、建議等流程來進行。

這裡面如果涉及產品化的需求就會提給DataWorks團隊，例如治理中心、治理工作臺、健康分等等。大家一起共同建設治理平臺，DataWorks上很多資料治理的能力，也離不開我們這麼多兄弟團隊給我們提供的建議。圍繞健康分這種考核指標，各個團隊就會有一個統一的衡量標準，大家可以往一個目標共同努力，從組織層面，這也是健康分非常重要的價值。

DataWorks資料治理中心的健康分是依據資料資產在資料生產、資料流通及資料管理中的使用者行為、資料特性、任務性質等後設資料，用資料處理及機器學習等技術，對各型別資料進行綜合處理和評估，在個人、工作空間的維度客觀呈現資料資產狀態的綜合分值。健康分體系，以後設資料建設為依託，建設集“儲存、計算、研發、質量和安全”的五大健康度領域，構建“儲存健康分、計算健康分、研發健康分、質量健康分和安全健康分”五大健康分指標。

健康分的分值範圍為0至100，分值越大代表資料資產的健康度越好，較高的健康度可以幫助使用者更放心、更高效、更穩定的使用資料，保障資料生產和業務運轉。

而資料治理專家梳理日常透過人肉治理的問題和邏輯，沉澱為DataWorks資料治理中心的資料治理項，並在資料治理中心定義對應治理領域，讓治理項落入對應領域進行綜合評分，同時還進行：

• 在治理的過程中，不斷豐富完善治理領域：比如在集團內部實踐時，治理過程也是逐步迭代和專項擴充的。首期成本治理階段，治理小組先選擇「儲存」治理維度進行攻堅，將基於目標治理業務中，關於「儲存」維度相關的高ROI的儲存治理項，進行規則定義和治理檢查。

比如，資料治理中心需要針對資料表要求使用者進行儲存生命週期管理，不使用和訪問的資料需要及時回收，釋放儲存空間。那首先定義儲存管理是否進行，最明顯的識別方式，即為是否為產出的資料表設定了生命週期，進而，在設定了生命週期的基礎上，則需要判斷設定的生命週期值是否合理，是否過度儲存了專案空間中的無用資料。針對這幾種情況，治理專家和平臺側，定義治理項及對應口徑，並沉澱最佳化治理規則，比如：

1.未管理資料表：未設定生命週期的分割槽表進行識別，當同時滿足以下條件，資料表是分割槽表，沒有設定生命週期，且近30天沒有訪問時，就命中該治理項，並判定該表為未管理的資料表。治理小組也根據提供對應的處理操作建議，優先建議使用者進行生命週期的快速設定。針對一些需要長期保留的資料，也可透過設定白名單或設定長生命週期的方式來處理。

2.無訪問資料表：該治理項則是針對進行了初步管理，但是實際是無用資料進行識別。佔用了大量儲存但是無下游訪問的資料表，通常情況下是殭屍資料或者冷資料，需要使用者進行處理識別，進行合理生命週期設定，或者進行刪除操作。

針對「儲存」維度進行專項治理，透過明確的「治理項」發現問題，讓資產負責人根據DataWorks資料治理中心提供的建議及治理手段完成治理，實現在儲存維度的健康分提升。

這樣在下個階段，治理小組可以再進行階段性工作的定義和該項領域的治理知識沉澱、深化，如在實際實踐中，在完成首期儲存治理後，治理小組：

1.重點開始攻堅「計算」維度，定義計算側重點關注的治理項，進行落地推動，如增加對「資料傾斜」、「暴力掃描」的計算任務識別，逐步分析完成每階段的成本最佳化工作的推進，以及最終成本節省效果的統計；

2.深化「儲存」維度，增加對「空表」「90天內無讀取使用表」等治理項，供下階段治理計劃識別，減少該類無效資料對於資料成本、資料使用的影響；

3.基於DataWorks資料全流程鏈路，平臺工具化治理能力，並針對於不同的治理項，提供不同的直接可用的治理手段，並且為了預防，提供基於各個過程的提前檢查項。做到從根本上進行提前規約。

當治理小組完成對治理項的制定後，實際的資料表及任務的責任人，則成為了最細粒度的資料成本治理的責任方。在長效機制上，DataWorks資料治理中心以個人治理的健康分提升，帶動全域性的持續治理最佳化，並面向管理員和普通成員提供不同層次的統計，簡化治理推進的難度。當前我們在阿里雲上已經為企業累計發現資料治理問題抄過100萬+，資料治理問題處理率達60%，事前治理問題攔截率達到36%。

▌小結

平臺工具層以資料治理健康分為抓手，從儲存、計算、研發、質量、安全等五個維度給出評估與治理方案，幫助使用者更快地發現並處理各類資料治理問題，引導使用者逐步進行資料治理建設，將“書面化”的資料治理規範落地成“主動式、可量化、可持續”的全鏈路資料治理。

七、資料治理組織架構及文化建設

剛才說的大部分和技術相關一些，但是對於資料治理來說，人與技術同樣重要。相比與以前專注與技術本身，資料治理和其他團隊的協同關係更強，更需要一個緊密、完善的組織不斷去計劃、實施、最佳化資料治理的工作。

資料治理組織架構設計

阿里的資料治理組織架構分為三層，整個架構的整體好處，是保證工作總體目標和方法統一，各領域的子目標服從與所屬的業務部門，並且能夠貼近業務。包含

• 資料專業委員會。屬於整個集團層面，主要是從宏觀層面上的職能確認。CDO為該組織的牽頭負責人，作為多個大部門共同執行落地的組織背書方。
• 資料治理專題小組。從屬於集團專業委員會下，更專注於資料治理本身命題的，則是資料治理專題組：制定資料治理規範，協調各團隊目標與進度，沉澱各類治理實踐，組織資料治理運營等各項工作。
• 資料治理團隊。各個功能部門下的領域資料治理部門，有專注於平臺工具建設的資料平臺團隊、有專注自身業務領域下的對口業務資料治理團隊、還有其他協同的財務、法務、安全團隊，這些團隊都有專人加入整個資料治理的工作中，以財年和季度為時間週期，確定各階段的治理工作目標。

最終整個組織需要完成幾件事情：

1.不斷持續迭代企業級治理規範：如，阿里巴巴資料資產治理規範，隨著業務的訴求和實際積累經驗不斷修訂與迭代；

2.定期確定企業級和業務級的治理目標，確認年度/季度的總體目標和分拆目標，建立使用資產健康分作為集團統一普查衡量標準，進行短期和長期的標準評估方式，統一各方認知，降低溝通消耗。

3.不斷配合治理目標達成的同時，也需要降低資料治理的成本，配套確認長期性、常態化的策略、工具、文化的建設內容和配合方式。

資料治理文化的建設

網際網路公司本身是一個注重運營的企業。而成本治理過程本身，也是在幫助企業建立對資料資產的一種運營，透過對計算資源、儲存資源、計算過程、治理人員、治理過程、業務產出都作為運營內容的一種，來實現最終業務價值的最大化。資料治理的建設目標是期望建立是一個通用框架，主動式治理、各個業務方可擴充套件，不影響業務的情況下，同樣能推動業務方完成資料治理，真正各方實現獲益。

針對於我們本身的資料團隊人員的資料專業技能+職業素養能多階梯的上升，也是適應日新月異的治理需求，現代化的雲產品開發、財務管理、人才培養的的對應手段。所以治理文化的建設在我們內部實踐時，也是一個非常重要的環節。它是讓能夠持續進行資料治理運營，讓資料治理成為常態化工作的組成部分。例如治理大比武、治理培訓、月刊/季刊/考試、部門預算管理、治理評選與激勵。

• 治理培訓。資料治理專題小組透過資料大學，制定一套通用的資料治理課程，分享一些通用的體系、規範、工具的課程，參與培訓後還可以參加考試認證。

• 治理大比武。資料治理專題小組發起各事業部大比武評比活動，從數字結果、長期價值、團隊合作、個人成長等各個方面進行PK和評選。有些事業部可能關心計算成本，有些關心穩定性、有些關心規範，專案型別豐富，也是一個非常適合大家互相交流學習的場合。

03

總結

透過以上的資料治理場景實踐，我們可以看到，資料治理平臺的建設不是一蹴而就的，是透過長時間的積累進行逐步演進的，DataWorks在阿里巴巴十幾年大資料建設中沉澱了數百項核心能力，從全鏈路上，主要包含了智慧資料建模、全域資料整合、高效資料生產、主動資料治理、全面資料安全、快速分析服務等能力，其中還有眾多細節受限於篇幅無法一一講述，例如一般的運維只提供成功、失敗兩種狀態，DataWorks提供了執行慢、等資源等多種分析結果，甚至做到了孤立節點、成環節點這種非常精細的狀態治理，這些都是在每個場景逐步深入後的成果。

 對於未來的判斷，目前我們可以明顯看到的幾個資料治理趨勢有：

• 政策法規不斷完善

國家釋出了各類培育統一的資料要素市場指導建議與法律法規，我們相信未來資料產權制度、流動交易制度、收益分配製度、安全治理制度等將不斷完善，指導資料治理平臺在各個方面不斷補充平臺能力。

• 開發治理一體化

先開發後治理，這個肯定會逐步的邁出歷史的舞臺，所以後續所有治理工作應該事先融入開發的過程，而不是“先汙染後治理”，生產運維、生產治理要實現一體化管理。

• 自動化資料治理

剛才我們提到的資料治理涉及多個模組，多個操作，如果未來我們將模組與模組之間，功能與功能之間、操作與操作之間，實現流程的自動化，例如：後設資料自動發現、自動採集、自動打標、自動歸類等，同時對應匹配一些智慧化的資料治理策略或者模板，將會極大提高我們資料治理的效率。

DataWorks服務了阿里巴巴集團內部所有事業部，包含天貓、淘寶、1688、速賣通、優酷、高德、本地生活、盒馬、菜鳥、釘釘等等，成為各個事業部通用的資料開發治理平臺。同時還透過阿里雲將阿里巴巴資料治理的最佳實踐輸出給雲上客戶，目前已經服務的企業客戶數已經超過1萬家，覆蓋了工業製造、能源、汽車、金融、零售、政務、網際網路等等行業，既有大型央企、國企、世界500強企業，也有剛開始創業1-2年的中小企業，從平臺的通用性上，DataWorks可以滿足不同行業，不同企業發展階段的大資料開發治理需求。

• 國家電網大資料中心透過DataWorks實現總部+27家省（市）公司PB級資料的統一管理，透過全鏈路資料中臺的治理與監測運營體系，加快電網整體數字化轉型升級。
• 億滋中國作為世界500強零食企業，透過DataWorks智慧資料建模進行全鏈路的資料模型治理，極大提升資料中臺的自服務能⼒，讓企業資料決策實現下放，釋放新零售的數字化力量。
• 友邦人壽基於阿里雲搭建金融資料中臺，承接了10倍業務流量的高峰，讓資料處理效率提升20倍，企業整體算力成本節省達數百萬。
• “非洲之王”傳音互聯有力支撐集團網際網路業務，資料治理效率提升2-3倍，為集團95%以上的業務增長賦能，帶領更多中國企業品牌走向全球新興市場。
• 哪吒汽車逐步完善資料治理與資料湖能力，依靠穩定可靠、效能卓越、彈性擴充套件的大資料平臺，未來將支援超過60萬+量汽車，數PB級別的資料分析。
• 三七互娛以DataOps理念啟用資料價值，建設自動化、敏捷、價值導向的資料體系，解決資料獲取難、業務響應慢、資料場景單一等資料消費的痛點，利用資料驅動運營精細化。
• 創夢天地基於開源的EMR引擎，用DataWorks替換自研排程系統，企業內部的技術人員可以更加專注業務，助力遊戲行業的資料化運營。

資料治理是一個龐大的話題，涉及廣泛，DataWorks作為工具型的產品，不變的是圍繞使用者為中心，讓開發人員減少低效的重複勞動，全方位提升企業資料效率，為企業降本增效。如果想了解更多DataWorks及文中相關產品資訊，可以在阿里雲官網找到我們。最後，我們也非常感謝集團內各個兄弟部門及阿里雲上各個行業的客戶給我們提供了很多場景與建議，也歡迎與其他專家進行深度的交流探討。