簡介：阿里巴巴一直將數據作為自己的核心資產與能力之一，從最早的淘寶、天貓等電商業務，到后續的優酷、高德、菜鳥等板塊，DataWorks、MaxCompute、Hologres等產品用一套技術體系來支持不同業務的發展與創新，為企業帶來整體的“數據繁榮”。 數據繁榮為我們帶來了紅利，同時也帶動了各類數據治理需求的井噴，特別是降本等需求的不斷出現，阿里云DataWorks團隊將13年的產品建設經驗整理成最佳實踐，從數據生產規范性治理、數據生產穩定性治理、數據生產質量治理、數據應用提效治理、數據安全管控治理、數據成本治理、數據治理組織架構及文化建設等7個方面為大家揭秘數據治理平臺建設實踐

作者：阿里云DataWorks團隊

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

一、數據繁榮的紅利與挑戰

大數據平臺的建設，到底可以為企業帶來什么樣的價值?

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

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

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

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

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

● 數據穩定性不足

任務調度隨著規模增大經常掛掉，不穩定，集群計算資源不足;員工經常起夜處理告警，故障無法快速恢復;突發大流量導致數據服務宕機或不可用

● 數據應用效率低

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

● 數據管理風險大

數據使用人員多，管理與易用難以平衡;數據出口多，人為泄露行為管控難;法規不斷更新，敏感數據發現難，數據分類分級難度

● 數據成本壓力大

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

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

一、起步階段-數據量與穩定性的矛盾

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

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

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

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

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

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

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

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

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

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

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

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

小結

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

二、阿里巴巴數據治理平臺建設實踐

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

01-數據生產規范性治理

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

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之類的方式，一時方便，長期成本反而很高。這樣不僅能提高對內交流、應用的效率，還能防止由于員工的變更，造成企業數據知識的流失。

02-數據生產穩定性治理

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

● 凌晨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%，同時極大地提升了員工的工作幸福感，這也是穩定性治理的重要意義。

小結

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

03-數據生產質量治理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 事中：數據質量檢測任務直接關聯調度任務產出。做到數據即產出即檢查，當高保障數據任務運行時，上游數據出現臟數據時，能及時阻斷任務，規避質量問題數據對下游的影響，并通過告警機制及時提醒用戶進行任務處理。

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

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

•通過管理機制和平臺體系，讓每一張數據表都有負責人

•平臺能自動追溯表與表之間的血緣關系

•末端表標注業務重要性，向上追溯鏈路中的表，以業務作為抓手來治理質量問題

• ETL作業統一調度，質量監控與調度系統集成，做到事中即時智能管控

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

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

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

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

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

4. 質量度量評估：建立可復用的數據標準和統一的質量評估體系

最后，我們還是要從業務關注我們的治理效果，以開頭舉例的包裹質量問題為例，通過數據質量治理的建設，以及圍繞業務對象的協作規則沉淀，

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

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

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

小結

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

04-數據應用提效治理

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

● 找數難

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

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

搜索的結果太多，需要逐一點擊查看

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

● 用數難

表命名奇怪，字段沒有注釋，缺少文檔

表注釋太簡略，沒有有效信息

人工問口徑耗費大量時間

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

如何快速開放數據或者構建個性化數據應用

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

基于元數管理的能力，DataWorks提供數據地圖功能。在數據地圖里，可以實現元數據的自動采集與數據目錄能力，針對找數常用的檢索功能，提供表/字段/模型/指標等多種檢索能力，并提供數據血緣能力，例如業務同學檢索到一張北京地區商品營收表時，想查看全國的營收數據，就可以通過血緣查看這張表的上游或者下游表，快速獲取對應數據。部分新來的同學對企業內部數據情況不是很熟悉，數據地圖還支持將各類常用表作為官方數據專輯給到所有用戶，并且在搜索時會推薦信息更加完善的表。

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

● 頁面布局可以切換上下布局和左右布局，左右布局可以更好利用一些外接顯示器場景，顯示信息更多

● SQL編輯器提供自動的代碼補全，代碼格式化、代碼高亮等能力

● 查詢結果展示可以分為明細數據模式和圖表模式，支持拖拉拽進行快速地圖表編輯

● 針對數據的上傳和下載開通了快捷入口，也支持針對數據下載條數進行管控

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

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

小結

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

05-數據安全管控治理

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

● 存儲量大、用戶種類多：由于數據倉庫/數據中臺是集成的、反映歷史變化的，因此注定了企業的數據倉庫集中存儲了各部門、各業務系統的數據，阿里巴巴內部的一張寬表動輒達到TB級別的存儲量、每日新增上百張表與數百GB是不可避免的事，這些數據不僅包含結構化數據，也包含非結構化、半結構化數據。如果我們希望將這些數據進行精細化的管理加密，會導致數據分級分類成本過高、耗時較長及遺漏的問題。

● 用戶基數大、用戶種類多：數據中臺是用于服務企業決策、日常分析的基礎設施，在數據采集階段，通常由開發人員配置任務將數據導入至數倉，加工階段由數據工程師進行代碼開發與側，使用階段則由各類運營、分析師通過各類Client來進行即席查詢，也包括某些業務系統的直接調用。之前我們提到了，阿里巴巴，每天有數萬名員工(包括：開發、運營、分析師、銷售、HR等崗位)以各類方式接入使用數據倉庫。如此多的人員授權就成為了難題，特別是在人員入職、離職、轉崗場景，管理員需要花費大力氣維護人員權限，非常容易出現過度授權、權限蠕變等問題。

● 客戶端操作界面多樣性：在使用數據倉庫的人員中，部分開發人員會通過命令行直連，大多數人員則是通過可視化界面與自己的認證信息連接使用。由于不同數據應用所提供的服務、所服務的群體不一樣，因此某些業務團隊會自行開發適合自己的客戶端界面以達到業務所需效果。而實際上授權過后的操作行為就是不可控的，各界面上的人員操作是否合理、是否符合工作所必需的原則是難以管控的。

● 數據流轉鏈路復雜如此復雜的流轉鏈路對加大了管控某些不合規數據流轉行為的難度。

● 結果數據交付：數倉中最終可用于支撐分析決策的數據絕不是通過簡單邏輯就能加工得出的，通常會涉及多團隊、跨系統、多處理邏輯的交付，常見的數據產出邏輯可能涉及通過多個業務團隊的數據，需構建十多個層級、總共上百個加工任務的工作流程(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發布、數據跨域同步等阻斷或審批規則，以此來防范人員因蓄意或安全意識缺乏、誤判而導致的不合理行為、風險、損失。

數據安全治理成效

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

● 滿足國內包括但不限于等保2.0的所有安全測評。

● 每日自動化發現敏感記錄值、核心表訪問流轉風險。

● 100%釋放用于數據梳理、分級分類、風險發現的巨大人力。

小結

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

06-數據成本治理

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

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

● 治技合一

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

● 全鏈路數據治理

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

● 組織設計與常態運營

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

成本治理策略分析

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

● 基礎設施

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

● 引擎能力

主要涉及存儲與計算能力的優化，例如提高存儲的效率，壓縮比，提高單位計算的能力，提高分布式調度的能力等等。

● 平臺能力

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

這些動作最終是為了實現我們成本治理的業務價值，例如整體集團節省了多少成本，某個事業部達成了多少的降本目標，某個業務板塊的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，實現資源的彈性分配?；谠劝戳扛顿M以及包年包月形式，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%.

小結

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

07-數據治理組織架構及文化建設

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

數據治理組織架構設計

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

● 數據專業委員會。屬于整個集團層面，主要是從宏觀層面上的職能確認。CDO為該組織的牽頭負責人，作為多個大部門共同執行落地的組織背書方。

● 數據治理專題小組。從屬于集團專業委員會下，更專注于數據治理本身命題的，則是數據治理專題組：制定數據治理規范，協調各團隊目標與進度，沉淀各類治理實踐，組織數據治理運營等各項工作。

● 數據治理團隊。各個功能部門下的領域數據治理部門，有專注于平臺工具建設的數據平臺團隊、有專注自身業務領域下的對口業務數據治理團隊、還有其他協同的財務、法務、安全團隊，這些團隊都有專人加入整個數據治理的工作中，以財年和季度為時間周期，確定各階段的治理工作目標。

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

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

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

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

數據治理文化的建設

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

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

● 治理培訓。數據治理專題小組通過數據大學，制定一套通用的數據治理課程，分享一些通用的體系、規范、工具的課程，參與培訓后還可以參加考試認證。

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

三、總結

通過以上的數據治理場景實踐，我們可以看到，數據治理平臺的建設不是一蹴而就的，是通過長時間的積累進行逐步演進的，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及文中相關產品信息，可以在阿里云官網找到我們。最后，我們也非常感謝集團內各個兄弟部門及阿里云上各個行業的客戶給我們提供了很多場景與建議，也歡迎與其他專家進行深度的交流探討。

DataWorks官網：https://www.aliyun.com/product/bigdata/ide



 

免責聲明：市場有風險，選擇需謹慎！此文僅供參考，不作買賣依據。

關鍵詞：