導讀：本文将分享網易數帆資料治理的發展過程，以及對現代資料治理的概念和理念的了解，提出現代資料治理應該與資料開發和消費很好地銜接，具備開發治理一體化、形成治理的閉環、倉内倉外統一治理和建立資料資産門戶等核心特點。
文章将從以下四個方面展開：
- 網易數帆大資料簡介
- 統建中台：先設計後開發
- 見招拆招：運動式治理
- 治理體系：現代資料治理
分享嘉賓｜餘利華 網易數帆 大資料産品線總經理
編輯整理｜許友昌 每日互動
出品社群｜DataFun
01
網易數帆大資料簡介
首先簡單介紹一下網易數帆大資料産品體系的發展過程。
網易大資料團隊最早緻力于分布式資料庫、分布式檔案系統和分布式搜尋引擎。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 萬個模型。通過這樣的中台建設，我們的模型更加優化，使得我們的傳遞速度和查詢的性能也得到了顯著提升。這就是第一階段，建設了資料中台，先設計後開發，把模型的問題解決了。但是并沒有解決所有的問題，後面又出現了各種各樣其他的問題，下一階段我們主要是針對出現的問題見招拆招。
--
03
見招拆招：運動式治理
1. 成本問題
在見招拆招的過程中，首先是成本問題，表現在三個方面：
- 投入産出低：每個業務部門都有很着急的需求，一方面是需求做不完，另一方面是做出來的很多資料沒有人用，我們有時發現有超過一半的表都是 30 天内沒有人通路過，不得不懷疑這樣的需求是否正确；
- 資源使用不合理：資料開發天天抱怨資料分析師的 SQL 寫得太爛太占資源，分析師天天埋怨 SQL 跑得太慢，每周都有因為資源使用不當導緻造成的事故；
- 成本指數增長：不停地加機器，已經非線性增長，老闆也要問，這些機器到底用在了哪些業務？産生了什麼價值？哪些可以做哪些可以省略不做？
針對這些問題，我們需要更精細的成本管理。
我們的解決方案是建設一個資料資産中心。
- 首先，核算每個查詢任務和表存儲資源，然後折算到錢。網易是做内部結算的，是以我們能夠把所有的任務折算到錢，而且可以把這些錢分攤到每個資料表、報表， 分攤到每個資料的應用，這樣就特别清楚了。
- 第二，采用“剝洋蔥”式資料下線。從下遊不再被使用的資料應用開始，逐層向上遊任務和上遊資料去下線。這裡的下線不是馬上下線，而是把它先暫存起來，讓其不可通路，如果需要可以馬上恢複。
- 第三，預估任務和查詢成本，對高消耗的任務和查詢進行審批和管控。
整體效果比較理想，當年累計下線資料達到 69P，雲音樂、嚴選分别優化了 47.6% 和 61.0% 的表，也節省了 38% 的計算資源。
2. 品質問題
第二個嚴重的問題是品質問題，平均每周會有 10 個資料品質問題在群裡被回報，更糟糕的是其中 90% 的問題是由業務方發現的。還有一些非常嚴重的缺陷甚至會導緻資損，比如曾有一次事故就是因為某個任務節點配置的問題，導緻把老客戶當成了新客戶，造成了 30W 的營銷資源損失，造成了 P1 的事故。
我們對于資料品質問題的解決方案是早發現、早恢複。
- 首先，建全鍊路的資料品質跟蹤體系，從資料源到資料中台模型再到資料應用建立全鍊路監控。那半年裡做了 1000 多個任務的監控，基本覆寫了所有重要資料源，特别是涉及資損的重要資料，保證資料正确性。
- 第二，建構智能基線運維體系，最早我們是基于單個任務去管，報警特别多特别繁瑣難以管控，是以我們做了基于基線的運維體系，把任務劃分了一些基線，把任務都挂到基線上去。為基線規定了産出時間，并且做了一個特别有用的功能——基線預警，可以提前預知到基線的問題，使得問題可以早發現早挽救，避免事故。
- 第三，任務影響分析，在真正出現了事故和延遲的時候，就需要做任務的影響分析，根據全面的血緣精準評估資料影響了哪些下遊的 API、報表、應用，根據應用反推應該如何去修複高優先級的資料。
一個典型的案例，有個資料研發收到了報警說基線要破線了，在群裡問是不是有人改了依賴？另外一個人就去看，确認問題，馬上就把問題解決了，避免了事故。這就是基線預警的效果。
3. 安全問題
我們也曾經踩了很多安全方面的坑。比如曾經某資料開發建一個資料庫，把資料庫的根目錄指定在了整個數倉的根目錄上，然後他把整個數倉都給幹掉了，更糟糕的是 HDFS 的資源回收筒是有缺陷的，删除檔案過多的話，就不會進到資源回收筒。即使調用 HDFS delete API 直接删除，系統也會繞開資源回收筒，這就導緻了當年一次很大的删庫事故，幸好我們當時馬上把 NameNode 上面的鏡像 Download 下來，把 NameNode 給停掉，把資料恢複出來。
其他的安全問題，還有權限粒度不夠精細、權限審批不友善等，有時不知道如何給予授權，不知道由誰來審批，不知道是否應該授權。
針對以上問題我們也做了各種的應對能力，比如設定了公共的資源回收筒，改造 HDFS 資源回收筒，使得删掉資料一定能進資源回收筒；實作了目錄當機，比如數倉的根目錄不能删除；備份恢複，資料備份到其他叢集，即使整個叢集出問題，也不會造成資料丢失；實作了行級的權限、隊列的權限，實作了标簽的權限控制，也實作了自定義的審批流程， 比如每個部門每種級别的資料可以制定自定義的審批流程。
以上就是我們在成本、品質、安全方面的工作，遇到問題解決問題。雖然我們總能見招拆招，但是總覺得有填不完的坑，那怎麼辦呢？為什麼會這樣？我們也一直在思考這個問題。
--
04
治理體系：現代資料治理
傳統的大資料治理分為三個過程，首先是開發，産生資料資産；然後消費資料資産，産生價值；治理在中間，想方設法讓我們的資料資産品質更好、更安全，更容易被使用。這是資料治理的目标，但是這樣的模式存在一些問題：
- 第一，先污染再治理，開發環節無法保證資料的出廠品質，出來的資料就不是很合格，過多依賴事後去治理資料，效率不高。
- 第二，運動式治理，缺少統一的資料治理的衡量标準，不确定效果，也缺乏持續優化的機制，這是存在于治理環節的問題。
- 第三，存在于資料消費的環節的問題是，消費者找不到、看不懂也信不過這些資料，導緻資料很難被利用起來産生價值。
- 第四，隻能治理大資料平台内的資料，無法管理其他系統的資料。通常網際網路公司都把資料集中在大資料平台，但是我們在服務客戶的過程中也發現了在很多行業不可能如此，因為他們有建設了不同系統來滿足不同的場景需求， 是以我們的治理平台能不能治理大資料平台以外的資料也是一個問題。
從根本上來講，資料治理之是以會産生源源不斷的問題，是由于我們的資料治理是個旁路的系統，在開發和消費的邊上，它既不深入到上遊資料開發的環節，和下遊資料消費的環節也是脫節的。是以我認為資料治理應該拓展它的範圍，要與資料開發和消費很好地銜接在一起，這就是現代資料治理，特點總結如下：
- 第一，開發治理一體化，從源頭開始控制，實作新産出的資料都能得到治理，未來産生的資料也得到保障。
- 第二，形成治理的閉環，這點主要是針對存量的資料。
- 第三，倉内倉外統一治理，不僅僅是針對大資料平台内的資料，還可以治理資料庫、MPP 等現存的一些非平台内的資料，非中台内的資料。
- 第四，建立資料資産門戶，我們通過資料資産門戶或者資料目錄這樣的方式，能夠讓資料更好地被消費。
要符合這四個特點才能把資料治理真正落地，下面展開介紹。
資料開發治理一體化，核心是在事前解決品質和安全的問題，将資料治理融入到資料開發的體系中，整個開發的過程就會變成：
- 第一是要先定義資料标準，資料标準的核心是資料元，比如身份證就是一個資料元類型， 資料元就會規定它是一個字元串的類型，它的取值範圍是什麼樣的，長度是多少，校驗品質、校驗規則是什麼樣的，還有設定身份證的隐私條件，比如是保密的，所有的品質安全規則都會綁定在身份證這個資料元上。
- 有了這樣的資料元之後，第二步，是定義名額口徑，明确名額的業務含義。
- 然後有了标準和名額規範之後，才是建設模型。名額規定了模型業務方面的需求，而标準規定了模型上的品質、安全規則，規定了類型和命名。
- 定義好模型之後，再進入到資料研發環節。
如何真正的使得開發治理一體化落地呢？我們建設了資料标準産品，并與其他子産品做關聯、關聯，才能確定資料治理能落在資料研發的全生命周期裡面，能夠緊密結合起來。比如資料标準要和資料品質結合，資料品質就會自動的去開啟關于某個字段或者關于某個表的稽核規則；标準要與資料傳輸去做很好的關聯，從資料源到目的地會做自動的表的映射、字段的映射、表資料字典、枚舉值的映射。然後資料标準也需要跟模型設計去做關聯，這樣字段和表的命名就能标準，并且資料目錄分類也會标準。标準還要跟資料安全中心去關聯，安全中心就會自動得到安全等級是什麼，其加密和脫敏的規則是什麼，安全審批的流程是什麼樣，更高等級的資料通常需要更高、更複雜的審批流程。資料标準還可以跟離線開發結合，利用一些 SQL 模闆自動做一些 ETL 任務的生成。通過這樣一個緊密的關聯才能實作研發和治理的一體化。
第二是治理要形成閉環。形成閉環主要包含三個方面的内容，首先是發現問題，也就是我們希望通過多元度健康度的評估，去發現資料中的問題。第二是有了問題之後還得有解決方案，我們通常配了一些專題的優化工具，比如推薦下線、生命周期管理、任務優化等。有了解決方案之後，還得有營運的手段， 比如我們有治理的紅黑榜，甚至跟考核或是資源申請挂鈎。
量化衡量資料資産的分數，我們通常從安全、成本、價值、品質、标準等次元去給資産評分，使用者登入到我們的系統，就可以看到某個資産的評分、自己的評分、組織的評分。我們會給評分打一些排行榜，如果使用者發現評分有點低，可以具體點進去看到哪裡做得不好，比如可能發現自己有一張表，30 天内都沒有人通路，那這個時候他可以使用我們産品提供的自助灰階下線的功能，去做一個優化。由此我們能夠對資料資産進行全局的衡量。
持續營運還需要有流程，很多公司裡面有資料治理的部門，治理部門會給每個資料設上正确的 Owner，一旦資料消費者發現資料有問題，就會依據這個在我們的産品裡發起一個資料治理申請的工單，資料治理部門收到工單之後就會在一定的時間内響應，當然他不一定要親自動手來幹這個事情，他會依據公司的相關政策，把工單派給各個業務部門資料治理的專員，讓他們去解決問題。通過這樣的流程能保證我們的資料品質一直在提升，不會一直腐化下去，資料有問題能得到很好的修正，讓使用者擁有比較好的體驗。
持續營運還包括文化的建設，我們在網易内部每年都要組織資料分析大賽、資料治理大賽。資料治理大賽看起來比較抽象，但每年都有超過 20 個團隊來參加，我們選擇其中比較優秀的評獎，并在公司發全員郵件進行表彰，也會做可視化的大賽等等。我們也提供了一些教育訓練，資料開發工程師、資料分析工程師的資格認證教育訓練。我們有些業務部門要求我們給他的員工先出個證，要是沒有這個證是不允許去線上操作的。在組織方面也可以建設資料治理部門，也可以在業務部門配置資料治理專員，這樣才能更好地把資料治理落地。
在倉裡倉外資料統一治理方面，我們自己實作了一個邏輯資料湖統一治理的方案，通過中繼資料注冊、掃描、采集、中繼資料釋出，把一些倉外的表，比如 Oracle 的表，MySQL 的表能夠映射為我們平台内的一個模型，然後把這個模型關聯到不同資料源的實體表。在此之上我們建立了統一開發和統一治理的流程，使得倉裡倉外能夠統一治理。
在資料資産消費方面我們提供了一站式的資料消費平台。通過這樣的消費平台，業務人員可以在資料資産門戶上看到企業到底有哪些資料、哪些報表、哪些資産，很友善地去申請權限，無縫的在上面跳轉到 BI、自助取數，或是其它各種消費資料的地方。管理者也可以根據資産的通路情況進行營運。管理資料就像管理商品一樣，如果是不好的資料就應該給予下線，好的則應該給予更好的展示位。
最後總結一下，我了解中的現代資料治理的主要思想：
首先是研發治理一體化， 防患于未然，保證資料出廠品質。
第二點是成果可以衡量，形成治理改進的閉環。
第三是關注資料的消費，畢竟資料治理的目标是為了資料的消費，發揮資料的價值，是以必須關注資料的消費。
--
05
問答環節
Q1：在網易内部是什麼團隊統一制定資料标準、名額标準是業務還是資料治理團隊？
A1：網易是事業部制，内部每個業務之間相對比較獨立，事業部各自負責各自的标準制定，通常事業部也會有自己的資料部門和他内部的業務部門。我們的外部客戶裡面，比如說我們接觸到很多金融行業的客戶，是有專門的資料治理部門，資料治理部門的來制定、牽頭制定相關的标準、資料釋出稽核，需要每個業務部門出資料治理的專員負責治理的落地， 資料團隊則負責提供資料，修複資料和中繼資料問題。
Q2：治理基線可以大緻介紹一下嗎？是通過試運作實作治理任務基礎基準的嗎？
A2：基線可以了解為一組互相依賴的，需要統一管理的任務，這組任務有一定的 SLA。基線可以友善管理， 我們可以為基線設定一個預期産出時間，并配置一個值班表， 每天預測基線預期産出時間， 一旦預測要破線風險，可及時告警到當天的值班人員。基線是很多任務組成，任務互相依賴形成一個複雜的圖狀結構，那根據任務的運作曆史以及當次的運作情況，是可以預測到基線未來的産出時間是不是破線， 如果是破線的話就可以提前來進行告警，使得我們能夠有充足的時間能夠處理，避免事故發生。
Q3：目前可以實作落标對标的功能嗎？
A3：我不知道是不是指一些行業的标準或者企業的标準如何去落地，傳統上我們做資料标準其實是一件很難的事情，比如證券行業，我們了解原來就有很多資料标準了，但是些标準通常是落在紙面上， 就是說有規定這個标準是什麼樣子的。我覺得落标的核心，還是把标準以産品化的形式來承載，把這個标準貫穿到我們事前事後的整個過程，在資料研發過程中確定産出的資料就是符合标準的，事後我們也可以拿到這個标準， 拿原資料掃描的結果去比對，看看是不是符合标準，然後根據治理的閉環再去治理。是以我認為第一個是落在産品上，第二個是跟其他研發環節做關聯，跟治理環節全鍊路做關聯，這樣才能很好地落地。
今天的分享就到這裡，謝謝大家。
｜分享嘉賓｜
餘利華
網易數帆 大資料産品線總經理
專注資料方向十多年， 完整經曆了網易大資料整個發展過程，目前負責網易有數業務。
｜DataFun新媒體矩陣｜
｜關于DataFun｜
專注于大資料、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章800+，百萬+閱讀，15萬+精準粉絲。