導讀：本文將分享網易數帆資料治理的發展過程，以及對現代資料治理的概念和理念的理解，提出現代資料治理應該與資料開發和消費很好地銜接，具備開發治理一體化、形成治理的閉環、倉內倉外統一治理和建立資料資產門戶等核心特點。
首先簡單介紹一下網易數帆大資料產品體系的發展過程。網易大資料團隊最早致力於分散式資料庫、分散式檔案系統和分散式搜尋引擎。2009年開始基於 Hadoop 做資料分析和運維。2014 年大資料平臺上線，並開始BI的產品化。2017 年正式對外做商業化的探索。在2018 年的時候，隨著業務的發展，網易使用資料面臨了很多的問題，所以開始建設資料中臺， 釋出了資料中臺的解決方案。2020 年透過網易數帆品牌正式提出了資料生產力的概念，提出不僅僅要建設資料中臺，還要建設資料中臺上的資料產品，提倡“人人用資料”的理念。2022 年資料治理 2.0 產品正式釋出。
到目前網易數帆形成了一個相對全棧的大資料產品體系，分為四層：- 最下面是基礎設施，這裡有網易數帆自己的 NDH 發行版，也可以對接 CDH 或者 CDP，基礎設施主要是提供儲存計算能力，NDH 在回收站等方面也有加強，還做了一些存算分離、混合部署的工作。
- 在資料基礎設施之上是資料研發，覆蓋了從資料設計、開發、一直到測試、上線、運維的整個過程，希望能做成一個符合 DataOps 的資料研發產品。
- 在資料中臺部分，我們提供了指標系統、模型設計、資料地圖等產品，目的是幫助業務去建設資料中臺。
- 在資料產品層，我們提供了很多工具，比如 BI 工具、資料門戶，我們的理念是要利用低程式碼和無程式碼的方式，幫助使用者、客戶去打造面向場景化的資料產品，從而真正達成“人人用資料”的理念，實現資料生產力在企業落地。
02
網易數帆資料治理髮展過程的第一個階段為統建中臺，先設計後開發。當時的背景是網易的網際網路業務在 2018 年的時候發展比較快，面臨了很多的資料問題。以網易考拉海購為例，當時交易和主站供應鏈以及各個團隊分別建設了自己的資料倉儲，這樣就造成煙囪式的開發，帶來了很多的問題。
- 第一個問題是指標口徑不一致，很多指標同名不同義、同義又不同名，不同部門之間的溝通存在很大困難。
- 第二個問題是缺乏資料建模規範，當時我們的資料團隊非常辛苦，但還是不能滿足業務上的需求，交付的速度還是非常慢，平均需要一週的時間， 並且查詢的效率又特別低，一個月範圍內的查詢要將近一分鐘， 一年內的查詢要 300 多秒，找資料也特別困難，業務產生了幾萬張表，不知道哪裡有資料，不知道怎麼去找、怎麼去用。
- 第三個問題是資料重複建設，有超過一半的資料是冗餘的，資料量超線性增長。
在這種情況下，我們分析了原因，為什麼資料研發的速度會慢？查詢的效率會低？我們做了一些資料的分析，結果發現有超過 50% 的任務，是在直接讀取原始資料， 也就是 ODS 層的資料，並且有 30% 的 Ad-hoc 查詢命中原始資料，原始資料加明細資料的查詢比例高達 60%，另外超過 40% 的表都沒有分層，這些其實都是煙囪式建設帶來的問題。各個業務線都是從 ODS 層開始拉資料來建設，沒有形成很好的資料公共層，資料複用程度不足。結果導致需求響應非常慢，查詢效率特別低下，規範也特別不好，整體就是資料不好用。
我們提出的解決方案是先設計後開發，其實就是建中臺。主要分為指標定義、模型定義、資料開發三個步驟。
指標代表的是資料中臺的需求層面，所以要從指標開始抓起，就是從源頭開始抓起，只有源頭的需求明確，設計才能清晰，產出的資料才能好用。所以我們引入了資料中臺指標定義的方法論，建設了指標系統產品，系統地梳理了我們的指標，包括原子指標、派生指標，並且給這些指標劃分了資料域和業務過程。完成指標梳理之後，當年考拉電商的指標數目下降了一半左右。這裡原子指標與派生指標的區別在於，原子指標是帶口徑的，派生指標不帶口徑。所以資料團隊的核心，就是要管控好原子指標，這樣就會避免指標口徑不一致的問題。有了指標定義之後，就進入到模型設計的層面。我們引入了維度建模的方法。並且打造了自己的一個模型設計中心的產品， 把維度建模的理論落地進去。當時為了推進模型的規範化、標準化，我們甚至把 ODS 層的資料都給收回了， 這樣強制大家要去用公共資料，發現公共資料不足的時候給我們提需求，以這樣的方式來推動資料建設。
建好指標、建好模型之後，就是資料開發過程。在建設資料中臺或者說在重構我們的數倉之前，我們首先要思考，如何衡量模型建得好不好？資料中臺建設得完不完善？我們提出了模型設計的度量標準，主要從三個方面來考慮：- 第一是完善度，可以分為兩類，首先是查詢的覆蓋度，就是 ADS 層的表能滿足多少比例的查詢，這個比例越高說明建設得越完善，越能滿足客戶的需求；另外就是跨層的引用率，DWS 層直接引用 ODS 層，就叫跨層引用，跨層引用率越低越好，我們希望一層層往上疊加，不要產生跨層引用的情況。
- 第二是複用度，一個模型被下游模型引用的次數越多越好。
- 第三是規範度，是否存在不規範的表，沒有分層的表，沒有主題域的表等等。
透過模型的重構，資料中臺的建設，取得了顯著成果，跨層引用率從 30% 下降到了10% 以下，模型的複用度從 2.4% 提升到了 9.6%，在這個過程中下線了 3.4 萬個模型。透過這樣的中臺建設，我們的模型更加最佳化，使得我們的交付速度和查詢的效能也得到了顯著提升。這就是第一階段，建設了資料中臺，先設計後開發，把模型的問題解決了。但是並沒有解決所有的問題，後面又出現了各種各樣其他的問題，下一階段我們主要是針對出現的問題見招拆招。
在見招拆招的過程中，首先是成本問題，表現在三個方面：- 投入產出低：每個業務部門都有很著急的需求，一方面是需求做不完，另一方面是做出來的很多資料沒有人用，我們有時發現有超過一半的表都是 30 天內沒有人訪問過，不得不懷疑這樣的需求是否正確；
- 資源使用不合理：資料開發天天抱怨資料分析師的 SQL 寫得太爛太佔資源，分析師天天埋怨 SQL 跑得太慢，每週都有因為資源使用不當導致造成的事故；
- 成本指數增長：不停地加機器，已經非線性增長，老闆也要問，這些機器到底用在了哪些業務？產生了什麼價值？哪些可以做哪些可以省略不做？
- 首先，核算每個查詢任務和表儲存資源，然後折算到錢。網易是做內部結算的，所以我們能夠把所有的任務折算到錢，而且可以把這些錢分攤到每個資料表、報表， 分攤到每個資料的應用，這樣就特別清楚了。
- 第二，採用“剝洋蔥”式資料下線。從下游不再被使用的資料應用開始，逐層向上遊任務和上游資料去下線。這裡的下線不是馬上下線，而是把它先暫存起來，讓其不可訪問，如果需要可以馬上恢復。
- 第三，預估任務和查詢成本，對高消耗的任務和查詢進行審批和管控。
整體效果比較理想，當年累計下線資料達到 69P，雲音樂、嚴選分別最佳化了 47.6% 和 61.0% 的表，也節省了 38% 的計算資源。
第二個嚴重的問題是質量問題，平均每週會有 10 個資料質量問題在群裡被反饋，更糟糕的是其中 90% 的問題是由業務方發現的。還有一些非常嚴重的缺陷甚至會導致資損，比如曾有一次事故就是因為某個任務節點配置的問題，導致把老客戶當成了新客戶，造成了 30W 的營銷資源損失，造成了 P1 的事故。
一個典型的案例，有個資料研發收到了報警說基線要破線了，在群裡問是不是有人改了依賴？另外一個人就去看，確認問題，馬上就把問題解決了，避免了事故。這就是基線預警的效果。
我們也曾經踩了很多安全方面的坑。比如曾經某資料開發建一個資料庫，把資料庫的根目錄指定在了整個數倉的根目錄上，然後他把整個數倉都給幹掉了，更糟糕的是 HDFS 的回收站是有缺陷的，刪除檔案過多的話，就不會進到回收站。即使呼叫 HDFS delete API 直接刪除，系統也會繞開回收站，這就導致了當年一次很大的刪庫事故，幸好我們當時馬上把 NameNode 上面的映象 Download 下來，把 NameNode 給停掉，把資料恢復出來。其他的安全問題，還有許可權粒度不夠精細、許可權審批不方便等，有時不知道如何給予授權，不知道由誰來審批，不知道是否應該授權。
針對以上問題我們也做了各種的應對能力，比如設定了公共的回收站，改造 HDFS 回收站，使得刪掉資料一定能進回收站；實現了目錄凍結，比如數倉的根目錄不能刪除；備份恢復，資料備份到其他叢集，即使整個叢集出問題，也不會造成資料丟失；實現了行級的許可權、佇列的許可權，實現了標籤的許可權控制，也實現了自定義的審批流程， 比如每個部門每種級別的資料可以制定自定義的審批流程。 以上就是我們在成本、質量、安全方面的工作，遇到問題解決問題。雖然我們總能見招拆招，但是總覺得有填不完的坑，那怎麼辦呢？為什麼會這樣？我們也一直在思考這個問題。
傳統的大資料治理分為三個過程，首先是開發，產生資料資產；然後消費資料資產，產生價值；治理在中間，想方設法讓我們的資料資產質量更好、更安全，更容易被使用。這是資料治理的目標，但是這樣的模式存在一些問題：- 第一，先汙染再治理，開發環節無法保證資料的出廠質量，出來的資料就不是很合格，過多依賴事後去治理資料，效率不高。
- 第二，運動式治理，缺少統一的資料治理的衡量標準，不確定效果，也缺乏持續最佳化的機制，這是存在於治理環節的問題。
- 第三，存在於資料消費的環節的問題是，消費者找不到、看不懂也信不過這些資料，導致資料很難被利用起來產生價值。
- 第四，只能治理大資料平臺內的資料，無法管理其他系統的資料。通常網際網路公司都把資料集中在大資料平臺，但是我們在服務客戶的過程中也發現了在很多行業不可能如此，因為他們有建設了不同系統來滿足不同的場景需求， 所以我們的治理平臺能不能治理大資料平臺以外的資料也是一個問題。
從根本上來講，資料治理之所以會產生源源不斷的問題，是由於我們的資料治理是個旁路的系統，在開發和消費的邊上，它既不深入到上游資料開發的環節，和下游資料消費的環節也是脫節的。所以我認為資料治理應該擴充它的範圍，要與資料開發和消費很好地銜接在一起，這就是現代資料治理，特點總結如下：- 第一，開發治理一體化，從源頭開始控制，實現新產出的資料都能得到治理，未來產生的資料也得到保障。
- 第三，倉內倉外統一治理，不僅僅是針對大資料平臺內的資料，還可以治理資料庫、MPP 等現存的一些非平臺內的資料，非中臺內的資料。
- 第四，建立資料資產門戶，我們透過資料資產門戶或者資料目錄這樣的方式，能夠讓資料更好地被消費。
要符合這四個特點才能把資料治理真正落地，下面展開介紹。
資料開發治理一體化，核心是在事前解決質量和安全的問題，將資料治理融入到資料開發的體系中，整個開發的過程就會變成：- 第一是要先定義資料標準，資料標準的核心是資料元，比如身份證就是一個資料元型別， 資料元就會規定它是一個字串的型別，它的取值範圍是什麼樣的，長度是多少，校驗質量、校驗規則是什麼樣的，還有設定身份證的隱私條件，比如是保密的，所有的質量安全規則都會繫結在身份證這個資料元上。
- 有了這樣的資料元之後，第二步，是定義指標口徑，明確指標的業務含義。
- 然後有了標準和指標規範之後，才是建設模型。指標規定了模型業務方面的需求，而標準規定了模型上的質量、安全規則，規定了型別和命名。
如何真正的使得開發治理一體化落地呢？我們建設了資料標準產品，並與其他子產品做聯動、關聯，才能確保資料治理能落在資料研發的全生命週期裡面，能夠緊密結合起來。比如資料標準要和資料質量結合，資料質量就會自動的去開啟關於某個欄位或者關於某個表的稽核規則；標準要與資料傳輸去做很好的聯動，從資料來源到目的地會做自動的表的對映、欄位的對映、表資料字典、列舉值的對映。然後資料標準也需要跟模型設計去做關聯，這樣欄位和表的命名就能標準，並且資料目錄分類也會標準。標準還要跟資料安全中心去關聯，安全中心就會自動得到安全等級是什麼，其加密和脫敏的規則是什麼，安全審批的流程是什麼樣，更高等級的資料通常需要更高、更復雜的審批流程。資料標準還可以跟離線開發結合，利用一些 SQL 模板自動做一些 ETL 任務的生成。透過這樣一個緊密的關聯才能實現研發和治理的一體化。
第二是治理要形成閉環。形成閉環主要包含三個方面的內容，首先是發現問題，也就是我們希望透過多維度健康度的評估，去發現資料中的問題。第二是有了問題之後還得有解決方案，我們通常配了一些專題的最佳化工具，比如推薦下線、生命週期管理、任務最佳化等。有了解決方案之後，還得有運營的手段， 比如我們有治理的紅黑榜，甚至跟考核或是資源申請掛鉤。
量化衡量資料資產的分數，我們通常從安全、成本、價值、質量、標準等維度去給資產評分，使用者登入到我們的系統，就可以看到某個資產的評分、自己的評分、組織的評分。我們會給評分打一些排行榜，如果使用者發現評分有點低，可以具體點進去看到哪裡做得不好，比如可能發現自己有一張表，30 天內都沒有人訪問，那這個時候他可以使用我們產品提供的自助灰度下線的功能，去做一個最佳化。由此我們能夠對資料資產進行全域性的衡量。
持續運營還需要有流程，很多公司裡面有資料治理的部門，治理部門會給每個資料設上正確的 Owner，一旦資料消費者發現資料有問題，就會依據這個在我們的產品裡發起一個資料治理申請的工單，資料治理部門收到工單之後就會在一定的時間內響應，當然他不一定要親自動手來幹這個事情，他會依據公司的相關政策，把工單派給各個業務部門資料治理的專員，讓他們去解決問題。透過這樣的流程能保證我們的資料質量一直在提升，不會一直腐化下去，資料有問題能得到很好的修正，讓使用者擁有比較好的體驗。
持續運營還包括文化的建設，我們在網易內部每年都要組織資料分析大賽、資料治理大賽。資料治理大賽看起來比較抽象，但每年都有超過 20 個團隊來參加，我們選擇其中比較優秀的評獎，並在公司發全員郵件進行表彰，也會做視覺化的大賽等等。我們也提供了一些培訓，資料開發工程師、資料分析工程師的資格認證培訓。我們有些業務部門要求我們給他的員工先出個證，要是沒有這個證是不允許去線上操作的。在組織方面也可以建設資料治理部門，也可以在業務部門配置資料治理專員，這樣才能更好地把資料治理落地。
在倉裡倉外資料統一治理方面，我們自己實現了一個邏輯資料湖統一治理的方案，透過後設資料註冊、掃描、採集、後設資料釋出，把一些倉外的表，比如 Oracle 的表，MySQL 的表能夠對映為我們平臺內的一個模型，然後把這個模型關聯到不同資料來源的物理表。在此之上我們建立了統一開發和統一治理的流程，使得倉裡倉外能夠統一治理。
在資料資產消費方面我們提供了一站式的資料消費平臺。透過這樣的消費平臺，業務人員可以在資料資產門戶上看到企業到底有哪些資料、哪些報表、哪些資產，很方便地去申請許可權，無縫的在上面跳轉到 BI、自助取數，或是其它各種消費資料的地方。管理員也可以根據資產的訪問情況進行運營。管理資料就像管理商品一樣，如果是不好的資料就應該給予下線，好的則應該給予更好的展示位。
首先是研發治理一體化， 防患於未然，保證資料出廠質量。第三是關注資料的消費，畢竟資料治理的目標是為了資料的消費，發揮資料的價值，所以必須關注資料的消費。問答環節
Q1：在網易內部是什麼團隊統一制定資料標準、指標標準是業務還是資料治理團隊？A1：網易是事業部制，內部每個業務之間相對比較獨立，事業部各自負責各自的標準制定，通常事業部也會有自己的資料部門和他內部的業務部門。我們的外部客戶裡面，比如說我們接觸到很多金融行業的客戶，是有專門的資料治理部門，資料治理部門的來制定、牽頭制定相關的標準、資料釋出稽核，需要每個業務部門出資料治理的專員負責治理的落地， 資料團隊則負責提供資料，修復資料和後設資料問題。Q2：治理基線可以大致介紹一下嗎？是透過試執行實現治理任務基礎基準的嗎？A2：基線可以理解為一組相互依賴的，需要統一管理的任務，這組任務有一定的 SLA。基線可以方便管理， 我們可以為基線設定一個預期產出時間，並配置一個值班表， 每天預測基線預期產出時間， 一旦預測要破線風險，可及時告警到當天的值班人員。基線是很多工組成，任務相互依賴形成一個複雜的圖狀結構，那根據任務的執行歷史以及當次的執行情況，是可以預測到基線未來的產出時間是不是破線， 如果是破線的話就可以提前來進行告警，使得我們能夠有充足的時間能夠處理，避免事故發生。A3：我不知道是不是指一些行業的標準或者企業的標準如何去落地，傳統上我們做資料標準其實是一件很難的事情，比如證券行業，我們理解原來就有很多資料標準了，但是些標準通常是落在紙面上， 就是說有規定這個標準是什麼樣子的。我覺得落標的核心，還是把標準以產品化的形式來承載，把這個標準貫穿到我們事前事後的整個過程，在資料研發過程中確保產出的資料就是符合標準的，事後我們也可以拿到這個標準， 拿原資料掃描的結果去比對，看看是不是符合標準，然後根據治理的閉環再去治理。所以我認為第一個是落在產品上，第二個是跟其他研發環節做關聯，跟治理環節全鏈路做關聯，這樣才能很好地落地。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2924961/，如需轉載，請註明出處，否則將追究法律責任。
