美團酒旅數據治理實踐

一、背景

1. 爲什麼要做數據治理

隨着移動互聯網的興起，線下商業活動逐漸開始向線上化發展，數據的產生速度有了極大的提升。越來越多的公司開始認識到數據的重要性，並將其打造成爲公司的核心資產，從而驅動業務的發展。在數據相關的領域中，“數據治理” 這個話題近兩年尤爲火熱，很多公司特別是大型互聯網公司都在做一些數據治理的規劃和動作。

爲什麼要做數據治理？因爲在數據產生、採集、加工、存儲、應用到銷燬的全過程中，每個環節都可能會引入各種質量、效率或安全相關的問題。在公司早期的發展階段，這些數據問題對公司發展的影響並不是很大，公司對問題的容忍度相對也比較高。但是，隨着業務的發展，公司在利用數據資產創造價值的同時，對數據質量和穩定性要求也有所提升。此外，當數據積累得越來越多，公司對數據精細化運營程度的要求也隨之提高，會逐漸發現有很多問題需要治理。

2. 需要治理哪些問題

數據治理是一項需要長期被關注的複雜工程，這項工程通過建立一個滿足企業需求的數據決策體系，在數據資產管理過程中行使權力、管控和決策等活動，並涉及到組織、流程、管理制度和技術體系等多個方面。一般而言，數據治理的治理內容主要包括下面幾個部分：

• 質量問題：這是最重要的問題，很多公司的數據部門啓動數據治理的大背景就是數據質量存在問題，比如數倉的及時性、準確性、規範性，以及數據應用指標的邏輯一致性問題等。

• 成本問題：互聯網行業數據膨脹速度非常快，大型互聯網公司在大數據基礎設施上的成本投入佔比非常高，而且隨着數據量的增加，成本也將繼續攀升。

• 效率問題：在數據開發和數據管理過程中都會遇到一些影響效率的問題，很多時候是靠 “盲目” 地堆人力在做。

• 安全問題：業務部門特別關注用戶數據，一旦泄露，對業務的影響非常之大，甚至能左右整個業務的生死。

• 標準問題：當公司業務部門比較多的時候，各業務部門、開發團隊的數據標準不一致，數據打通和整合過程中都會出現很多問題。

3. 美團酒旅數據現狀

2014 年，美團酒旅業務成爲獨立的業務部門，到 2018 年，酒旅平臺已經成爲國內酒旅業務重要的在線預訂平臺之一。業務發展速度較快，數據增長速度也很快。在 2017 到 2018 兩年裏，生產任務數以每年超過一倍的速度在增長，數據量以每年兩倍多的速度在增長。如果不做治理的話，根據這種接近指數級的數據增長趨勢來預測，未來數據生產任務的複雜性及成本負擔都會變得非常之高。在 2019 年初，我們面臨着下面五種問題：

• 數據質量問題嚴重：一是數據冗餘嚴重，從數據任務增長的速度來看，新上線任務多，下線任務少，對數據表生命週期的控制較少；二是在數據建設過程中，很多應用層數據都屬於 “煙囪式” 建設，很多指標口徑沒有統一的管理規範，數據一致性無法進行保證，同名不同義、同義不同名的現象頻發。

• 數據成本增長過快：某些業務線大數據存儲和計算資源的機器費用佔比已經超過了 35%，如果不加以控制，大數據成本費用只會變得越來越高。

• 數據運營效率低下：數據使用和諮詢多，數據開發工程師需要花費大量時間一對一解答業務用戶的各種問題。但是這種方式對於用戶來說，並沒有提升數據的易用性，無法有效地積累和沉澱數據知識，還降低了研發人員的工作效率。

• 數據安全缺乏控制：各業務線之間可以共用的數據比較多，而且每個業務線沒有統一的數據權限管控標準。

• 開發標準規範缺失：早期爲快速響應業務需求，研發人員通常採用 “煙囪式” 的開發模式，由於缺乏相應的開發規範約束，且數據工程師的工作思路和方式差異性都非常大，導致數據倉庫內的重複數據多，規範性較差。當發生數據問題時，問題的排查難度也非常大，且耗時較長。

4. 治理目標

2019 年，美團酒旅數據團隊開始主動啓動數據治理工作，對數據生命週期全鏈路進行體系化數據治理，期望保障數據的長期向好，解決數據各個鏈路的問題，並保持數據體系的長期穩定。具體的目標包含以下幾個方面：

1. 建立數據開發全鏈路的標準規範，提高數據質量，通過系統化手段管理指標口徑，保障數據一致性。

2. 控制大數據成本，避免大數據機器成本膨脹對業務營收帶來的影響，合理控制數據的生命週期，避免數據重複建設，減少數據冗餘，及時歸檔和清理冷數據。

3. 管理數據的使用安全，建立完善的數據安全審批流程和使用規範，確保數據被合理地使用，避免因用戶數據泄露帶來的安全風險和商業損失。

4. 提高數據工程師的開發和運維效率，減少他們數據運營時間的投入，提高數據運營的自動化和系統化程度。

二、數據治理實踐

其實早在 2018 年以前，酒旅數據組就做過數據治理，當時只是從數倉建模、指標管理和應用上單點做了優化和流程規範。之後，基於上面提到的五個問題，我們又做了一個體系化的數據治理工作。下面將介紹一下美團酒旅數據團隊在數據治理各個方向上的具體實踐。

1. 數據治理策略

數據治理方案需要覆蓋數據生命週期的全鏈路，我們把數據治理的內容劃分爲幾大部分：組織、標準規範、技術、衡量指標。整體數據治理的實現路徑是以標準化的規範和組織保障爲前提，通過做技術體系整體保證數據治理策略的實現。同時，搭建數據治理的衡量體系，隨時觀測和監控數據治理的效果，保障數據治理長期向好的方向發展。

2. 標準化和組織保障

我們制定了一個全鏈路的數據標準，從數據採集、數倉開發、指標管理到數據生命週期管理，全鏈路建立標準，在標準化建立過程中聯合組建了業務部門的數據管理委員會。

2.1 標準化

數據標準化包括三個方面：一是標準制定；二是標準執行；三是在標準制定和執行過程中的組織保障，比如怎麼讓標準能在數據技術部門、業務部門和相關商業分析部門達成統一。

從標準制定上，我們制定了一套覆蓋數據生產到使用全鏈路的數據標準方法，從數據採集、數倉開發、指標管理到數據生命週期管理都建立了相應環節的標準化的研發規範，數據從接入到消亡整個生命週期全部實現了標準化。

2.2 組織保障

根據美團數據管理分散的現狀，專門建立一個職能全面的治理組織去監督執行數據治理工作的成本有點太高，在推動和執行上，阻力也會比較大。所以，在組織保障上，我們建立了委員會機制，通過聯合業務部門和技術部門中與數據最相關的團隊成立了數據管理委員會，再通過委員會去推動相關各方去協同數據治理的相關工作。

業務部門的數據接口團隊是數據產品組，數據技術體系是由數據開發組負責建設，所以我們以這兩個團隊作爲核心建立了業務數據管理委員會，並由這兩個團隊負責聯合業務部門和技術部門的相關團隊，一起完成數據治理各個環節工作和流程的保障。組織中各個團隊的職責分工如下：

數據管理委員會：負責數據治理策略、目標、流程和標準的制定，並推動所有相關團隊達成認知一致。業務數據產品組：負責數據標準、需求對接流程、指標統一管理、數據安全控制以及業務方各部門的協調推動工作。技術數據開發組：負責數據倉庫、數據產品、數據質量、數據安全和數據工具的技術實現，以及技術團隊各個部門的協調推動工作。

3. 技術系統

數據治理涉及的範圍非常廣，需要協作的團隊也很多，除了需要通過組織和流程來保障治理行動正常開展，我們也考慮通過技術系統化和自動化的方式進一步提效，讓系統代替人工。下面我們將從數據質量、數據成本、數據安全和運營效率等幾個方向，來逐一介紹技術實現方案。

3.1 數據質量

數據質量是影響數據價值最重要的因素，高質量的數據給帶來準確的數據分析，錯誤的數據會把業務引導到錯誤的方向。數據質量涉及範圍較廣，在數據鏈路的每一個環節都有可能出現數據質量問題，酒旅業務現階段的主要質量問題包括：

• 數倉規範性差，數倉架構無統一的強制規範執行約束，數倉歷史冗餘數據嚴重。

• 應用層數據屬於 “煙囪式” 建設，指標在多個任務中生產，無法保證數據的一致性。

• 數據下游應用的數據使用無法把控，數據準確較差，接口穩定性無法得到保障。

• 業務方對多個數據產品的指標邏輯無統一的定義，各個產品中數據不能直接對標。

數據組的治理數據質量方案覆蓋了數據生命週期的各個環節，下面將介紹一下整體的技術架構。

• 統一數倉規範建模（One Model）：通過統一數倉規範建模系統化保障數倉規範執行，做到業務數倉規範標準化，並及時監控和刪除重複和過期的數據。

• 統一指標邏輯管理（One Logic）：通過業務內統一的指標定義和使用，並系統化管理指標邏輯，數據應用層的數據指標邏輯都從指標管理系統中獲取，保障所有產品中的指標邏輯一致。

• 統一數據服務（One Service）：通過建設統一的數據服務接口層，解耦數據邏輯和接口服務，當數據邏輯發生變化後不影響接口數據準確性，同時監控接口的調用，掌握數據的使用情況。

• 統一用戶產品入口（One Portal）：分用戶整合數據產品入口，使同一場景下數據邏輯和使用方式相同，用戶沒有數據不一致的困惑。

3.1.1 統一數倉規範建模（One Model）

在業務發展初期，數據團隊集中精力在快速建設數倉來支持業務，數倉建模規範疏於管理。隨着業務的發展，數倉中的數據急劇增多，數據產品和下游應用快速增加，數據工程師和數據使用方也變得越來越多，數倉的問題日益突顯。業務數據倉庫從初期發展到現在主要暴露了 3 方面的問題：

• 數據規範性較差，不同時間的數倉規範不同，數倉規範的執行審覈需要較多的人力。

• 數據不一致問題多，同一指標在多個 ETL 中生產，數據更新同步也不及時。

• 歷史數據冗餘嚴重，數據存儲方式較多，業務方查詢不知道該用哪個數據。

數據團隊主要通過數倉規範化制定、數倉分層架構和數倉規範化系統來解決上述問題，下面是我們的具體解決方案。

制定標準 - 數倉規範

做好數倉規範化最基本的前提是要制定一系列標準化的規範，並推動組內同學執行。標準化的適用性、全面性和可執行性直接影響到規範的執行效果。數倉規範主要從 3 個方面制定數據標準化：

• 數倉建模規範，數倉建設最基礎的規範，包括分層、命名、碼值、指標定義、分層依賴等維度。

• 主數據管理規範，數倉各個主題的數據只有一份，團隊共建複用，不能重複開發。

• 數據使用規範，在查詢數據時優先查詢主題層，不再提供明細層和 ODS 層的查詢訪問入口。

工具保障 - 數倉規範化開發系統 - Dataman

在執行數據規範化的過程中，我們發現團隊中每個人對規範的理解不一致，很可能造成數據規範不統一，審覈人在審覈上線任務時需要考慮規範的全部規則，審批需要投入的人力較多。在這樣的流程下，數據規範性無法從根源上進行控制，因此需要建設數據規範化的工具，通過系統保障規範的一致性。數據組使用的數據層規範化工具 - Dataman，主要包括 3 個功能模塊：標準化規範、配置化開發和規則化驗證。

• 標準化規範：制定業務數據倉庫的標準規範並配置在系統中，包括架構分層、字段管理、詞根管理、公共維度和碼值管理等，在 ETL 開發時通過統一的數倉規範開發，通過配置化實現數倉的命名、分層和碼值，保障數倉長期的規範性。

• 配置化開發：系統化保障工程師在開發 ETL 過程中遵守數倉規範，Dataman 可以用配置化的方式生成 XT 任務模板，模板中包含數據模型的基礎信息，研發同學只需要在任務模板中開發數據生產邏輯。

• 規則化驗證：跟進數據倉庫底層元數據和標準化配置信息，定期掃描數倉的規範性情況，判斷出不符合數倉規範的任務和高相似度的數據表。

3.1.2 統一指標邏輯管理（One Logic）

業務使用數據的第一步是搭建業務指標體系，業務的目標和策略的執行情況需要通過指標來分析，指標體系的合理性和指標數據的質量直接影響到業務決策，指標的重要性不言而喻。我們通過系統化地管理數據指標，從根源上解決指標口徑一致性問題，主要從以下 3 個方向入手：

• 指標定義規範化

• 指標管理系統化

• 數據查詢智能化

指標定義規範化

此處主要從指標的生成和管理上做好規範，確保業務同學和研發人員對指標體系管理的認知一致，確保指標的新建、更改和使用都按照規範執行。我們通過下面 2 個方向來實現指標定義的規範統一。

• 業務指標體系的規範化：我們在業務線內統一了指標體系規範，指標分爲原子指標、計算指標和複合指標，通過使用這 3 類指標支持業務的數據分析需求，業務未來新增指標也要按照這個標準分類。

• 指標的管理規範化：我們與商業分析團隊一起梳理業務指標邏輯標準和錄入流程，通過制定指標的新增和變更規範 SOP，解決由指標管理流程引起的質量問題，使得指標定義、系統錄入、指標認證和使用各個環節都有嚴格的流程管控，經由業務側數據產品經理、業務側數據治理數據管理員和數據工程師共同審批，確保標準規範的落地執行。

指標管理系統化

物理數據表管理：數據表管理的信息主要包括表的基礎元數據信息、表類型（維表或事實表）、表的推薦度、描述信息和樣例數據等。數據表管理主要是面向數據開發同學，通過維護數據表信息，爲數據模型和指標管理提供數據基礎支持。

數據模型管理：是對物理數據表的模型構建，通過一個物理模型可以查詢到指標和相關的維度數據。數據模型可以是星型模型或寬表，星型模型中維護多個數據表的關聯方式、關聯字段、維度表包含字段和模型的 ER 圖等信息。

指標管理：主要包括 2 部分的內容，指標的業務信息和技術信息。

• 業務信息：爲了保障業務的指標信息準確且統一，指標的業務信息需要數據產品經理與商業分析團隊討論確定後錄入，錄入後需要指標所屬數據主題的負責人審批後才能上線。

• 技術信息：技術信息主要包括指標對應的物理模型以及指標的計算邏輯，技術信息的填寫需要數據工程師配置。技術信息配置後會在系統裏生成技術元數據，指標管理系統通過技術元數據生成數據查詢語句，提供給下游應用。

指標查詢智能化

在指標管理系統中創建指標時，我們系統化管理了指標與數倉物理模型的關聯關係和取數邏輯，通過數據物理模型獲得指標對應的字段和可以關聯的維度，以此把指標解析爲數據查詢 SQL 語句，通過數據查詢引擎執行生產的 SQL，智能化獲得指標數據。

在查詢解析過程中，經常出現指標綁定了多個底層數據表的情況，此時需要我們手動的選一個物理模型作爲指標生產的底層數據。但問題是，如果一個指標對應的模型太多，每次解析都需要手動指定，研發人員不確定選擇哪個模型的性能最好。另外，隨着物理模型的增多，大量舊的指標配置的關聯模型不是最優解，就需要手動優化更改。爲了解決這個問題，指標管理系統增加了智能解析模塊，在選擇智能模式查詢時，系統會根據指標管理模型的數據量、存儲性能和查詢次數等信息自動選取最優的物理模型。

3.1.3 統一數據服務（One Service）

數據倉庫對外提供數據的需求越來越多，除了管理層、分析師和產品運營同學使用數據產品和報表外，數據還需要提供到各個業務系統中使用。常用的提供數據的方式主要包括同步數據表、提供 SQL 和爲下游服務開發定製化 API 接口等方式，但存在以下幾個方面的問題：

• 數據一致性無法保障，當數據指標邏輯更改時，業務系統不能及時調整，導致不同業務系統的數據不一致。

• 數據同步到業務系統後，我們就無法管控數據的使用方式，也不能監控到數據是否被其他下游使用的情況。

• 數據開發效率比較低，數據服務穩定性比較差，數據工程師開發一個定製化 API 接口需要幾天時間，各個接口服務單獨維護，服務穩定性也比較差。

從 2018 年開始，數據 BP 中心與分析系統中心合作建設了統一數據 API 服務平臺（Buffalo），通過開發可配置的數據接口服務平臺實現數據對外的靈活提供，並實現對數據服務的下游使用及性能的可監控。統一的數據服務平臺解決了幾個比較關鍵的問題：

• 數據邏輯統一收口：數據服務接口和數據邏輯解耦，當數倉更改和數據指標邏輯變更後下遊無感知。

• 數據服務的更好管控：研發同學能夠了解到數據被哪些下游使用、調用了多少次和數據服務是否穩定等信息。

• 開發效率大幅提升，服務穩定性大幅提高：通過統一服務平臺可以在 1 小時內完成一個接口的配置化開發，與此同時，接口穩定性統一運維，服務穩定性有了很好的保障。

3.1.4 統一用戶產品入口（One Portal）

如果不加控制，數據產品就會建設得越來越多。酒旅業務在 2018 年有超過 10 個數據相關產品的入口，用戶很難快速地找到自己想要查的數據產品和報表。不同產品面對的用戶不一樣，數據的使用場景和展示方式也各不相同，業務方在使用數據時不知道從哪裏能看到最全面的數據產品。

此外，也存在因爲適用場景不一樣，導致面向不同用戶的數據邏輯不同的情況，比如某些業務同學查看的 GMV 不包含民宿數據，但是商業分析團隊要看的 GMV 是包含民宿數據的。爲了能夠讓業務方能夠在一個數據產品門戶中找到更全面的數據，且這個產品門戶中多個產品的數據邏輯是一致的，我們將數據門戶按照使用用戶和應用場景劃分爲 3 類：

• 決策分析使用 “大聖”（美團內部的數據平臺），面向管理者和商業分析團隊，所有業務管理者和商業分析團隊成員需要的數據都可以從大聖數據產品裏查看。

• 業務數據查詢使用 “天狼” （美團內部的數據平臺），用戶主要是銷售，在天狼裏能查看銷售所需的各種數據。

• 數據資產信息查詢使用 “大禹”（美團內部的數據平臺），用戶是研發人員和檢索數據信息的業務方，在大禹數據門戶裏可以找到數據資產的信息，能更快地找到想要的數據，更全面地瞭解相關的元數據。

3.1.5 整體系統架構

整體的技術架構分爲三層，從統一數據建模到統一指標邏輯、統一數據服務和統一產品入口，整體保障了數據的質量，同時配合數據管理的組織保障體系和流程規範，將整體數據質量相關的架構搭建起來。

3.2 數據運營效率

數據工程師在日常工作中的主要工作包括兩大部分：數據開發和數據運營。我們在前面介紹了通過數據開發和指標管理相關的工具系統建設，開發效率得到了大幅提升。而數據運營是另一大類工作，他們的主要時間投入在數據使用諮詢和數據問題答疑，大概佔數據工程師日常工作 5%～10% 的時間。

數據工程師日常投入到運營的人力多的主要原因是信息不對稱和信息檢索能力弱，數據團隊建設了很多數據模型和數據產品，但是用戶不知道怎麼快速地找到和使用這些數據，問題主要體現在下面 3 個方面：

• 找數難：所需要的數據有沒有？在哪裏能找到？

• 看不懂：數據倉庫是以數據表和報表等方式提供，數據的邏輯和含義不夠清晰易懂。

• 不會用：數據指標的查詢邏輯是什麼？多個表怎麼關聯使用？

3.2.1 方案思路

數據團隊通過數據資產信息的系統化的方式建設易用的數據檢索產品，幫助用戶更快捷、更方便地找到數據，並指導用戶正確地使用數據，提高數據信息的易用性，以此減少數據工程師的數據答疑和運維時間。實現策略是通過用戶的問題分類，通過數據信息系統化的方式分類解答 80% 的問題，最後少量的問題透傳到研發人員再進行人工答疑。系統化方式主要分兩層，數據使用智能和數據答疑機器人。

3.2.2 數據使用指南系統

數據使用指南的定位是業務數據信息的知識白皮書，提供最新、最全、最準確的指標口徑、項目指標體系、數據表用法等信息，以簡潔、流暢的操作支持數據指南中的內容及時更新，降低業務方的數據答疑和數據使用成本。

數據使用指南通過把業務場景和數據使用場景打通，從業務場景分析到使用到的數據表、指標和數據產品打通，在系統中能夠快速找到數據表、指標定義、數據查詢 SQL、指標所在數據產品等信息，一站式解決數據查找、使用和分析的全部場景。主要功能包括指標信息和數據表信息及使用。

• 指標信息：包括業務分類指標和指標的詳細信息，在指標詳細信息頁面可以查看指標定義、指標使用場景、指標統計維度、指標對應數據表、指標所在數據產品和指標的 SQL 查詢示例等信息，把指標信息與數據表和數據產品關聯，方便用戶快速根據指標信息查找到數據。

• 數據表信息及使用方式：包括數據表的基礎信息、表的使用推薦度、SQL 查詢樣例、數據更新時間和數據就緒時間等信息，幫助使用者快速定位需要的數據表和數據 SQL 的查詢使用。

3.2.3 數據答疑機器人

用戶在使用數據時，經常諮詢數據工程師一些問題，比如想找的數據在哪個表？指標怎麼取？業務系統的一個字段怎麼在數倉裏面取到？很多問題會被重複問到，每次解答都需要研發人員花費一定的時間，而通過 Wiki 的方式維護效果較差，於是我們考慮用自動化答疑的方式，把數據工程師在日常答疑過程中積累問題和答案，通過一定的規則匹配，當再次被問到時系統可以自動地給出解答。

使用日常答疑中積累的諮詢問題和答案作爲基礎答疑知識庫，數據答疑機器人使用美團 AI 平臺的摩西機器人搭建，配合問題答疑的策略，實現對歷史已有問題和答案通過搜索匹配後發送給用戶，具體實現方式如下：

3.3 數據成本

大數據的主要成本構成有 3 大部分，計算資源、存儲資源和日誌採集資源，其中計算資源和存儲佔總成本超過 90%，我們的數據成本治理主要是針對大數據計算和存儲這兩個部分。

大數據成本優化方案

• 計算資源

• 無效任務清理，通過任務生產出來數據的使用情況判斷是否爲無效任務，通過下線無效任務，減少任務執行使用的計算資源。

• 超長任務優化，經過任務的計算資源使用數據可以發現，某幾個大任務在執行時會佔用大部分的計算資源，導致其他任務執行時間變長，或者佔用配置外的彈性計算資源，導致計算成本增加。數據組會統計和監控每天任務的執行情況，發現執行時間長（超過 2 個小時）或者佔用資源多的任務會及時進行優化。

• 分散利用計算資源，數倉的夜間批處理任務使用計算資源的實際一般都集中在早晨 2 點到上午 10 點前，這就導致在一天中只有三分之一的資源被充分利用，而且這段時間內通常資源都是不夠用的，需要使用平臺提供的配置外彈性資源。而其他時間段的計算資源閒置，對資源有較大的浪費。爲了把全天的資源都有效地利用起來，我們會把一些對就緒時間不敏感的任務（比如算法挖掘、用戶標籤、數據回刷等）放到 10 點之後，把配置的計算資源充分利用起來。

• 租戶拆分和整合統一管理，提高資源池總量和資源總體的使用率。

• 存儲資源

• 數倉架構優化和重構：通過統一數倉建模規範，把相似或相同模型進行整合和去重，確保每個主題數據只保留一份。

• 數據存儲壓縮：在數據倉庫建設初期，很多 Hive 表的存儲格式是 txt，通過壓縮爲 ORC 格式可以減少大量的存儲空間。

• 冷數據處理：把數據分爲冷、熱兩大類數據，通過每天對全部數倉表掃描識別出冷數據，發給數據負責人及時處理。

• 數據生命週期控制：按照數倉分層的應用場景配置數據的生命週期，明細數倉層保留的全部歷史數據，主題層保留 5 年數據，應用層保留 1～3 年數據。通過數據生命週期控制，極大地減少了數據存儲成本。

• 日誌採集資源

• 下線冷數據的上游日誌數據收集任務，數據收集費用主要來自兩類數據，業務系統數據庫的 Log 同步和後臺日誌數據收集，通過對收集數據的使用情況監控，及時下線下游無應用的數據收集任務。

3.4 數據安全

數據資產對業務來說既是價值，也是風險。數據安全作爲業務部門 “事關生死” 的核心工作，在技術架構上會從數據產生到數據應用各個環節進行控制，保障數據應用事前有控制、事中有監控和事後有審計。數據安全控制從業務系統開始對用戶高敏感數據加密，在數倉進行分級和脫敏，在應用層做密文數據權限和密鑰權限的雙重保障，管控用戶相關的高敏感數據，按照三層系統控制加五個使用原則實現如下：

4. 衡量指標

業務部門在業務發展初級就會建立指標體系，並使用數據指標對各個業務過程做精細化的分析，衡量業務目標的達成情況和行動的執行程度。數據治理也需要一套成熟穩定的衡量指標體系，對數據體系做到長期、穩定和可量化的衡量。我們通過制定體系化的數據衡量指標體系，來及時監測數據治理過程中哪些部分做的好，哪些部分還有問題。

4.1 衡量指標建設

爲了能夠不重不漏地把指標都建立起來，我們從 2 個方面進行考慮：

• 技術分類，按照數據團隊關注的問題和目標，把數據治理的指標體系分成質量、成本、安全、易用性和效率這 5 大類。

• 數據流環節，分別從數據的採集、生產、存儲、指標管理、應用和銷燬等環節監控關注的指標。

4.2 衡量指標保障數據治理

根據 PDCA 原則，將數據治理作爲日常的運營項目做起來，底層依賴數據指標體系進行監控，之上從發現問題到提出優化方案，然後跟進處理，再到日常監控，構成一個完整的循環。

5. 治理效果總結

數據治理覆蓋了數據生命週期全鏈路，通過圍繞數據從產生到價值消亡全部生命週期，建立數據治理組織、制定治理衡量體系和建設治理技術系統來達到數據治理目標。經過體系化的數據治理，數據系統的治理、成本、安全和運營效率都有了比較大的改善。

• 數據質量：技術架構優化後，通過標準化規範和系統保障數據的準確性，並在治理過程中清除和整合了歷史冗餘數據，數據質量問題有很大的改善。2019 年數據生產任務的增長率比 2018 年減少了 60% 左右。

• 數據成本：經過數據成本優化後，在支持 2019 年酒旅業務高速增長的同時，大數據的單均成本費用降低了 40% 左右。

• 數據安全：通過業務系統數據加密和數據倉庫數據脫敏，雙重保障高敏感數據安全，避免數據泄露。通過數據安全規範和數據敏感性的宣導，加強業務同學的數據安全意識，業務沒有嚴重數據安全問題的發生。

• 運營效率：運營工具化減少了研發同學超過 60% 的日常答疑時間，極大地減少了研發同學工作被打擾的次數，提高了開發效率。

三、未來規劃

數據治理分爲三個大階段：被動治理、主動治理、自動治理。

• 第一階段我們做的是被動治理，也就是階段性治理，確少統籌考慮，主要是基於單個問題的治理，而且治理之後過一段時間可能還要做重複治理。這個階段更多是人治，一個項目成立，協調幾個人按照項目制完成，沒有體系規劃，也沒有組織保障。

• 第二階段是主動治理，有長期的統籌規劃，能覆蓋到數據生命週期的各個鏈路，在治理過程中把一些手段和經驗流程化、標準化、系統化，長期解決一些數據問題，讓數據治理長期可控。

• 第三階段是自動治理，也是智能治理，在長期規劃和數據生命週期各環節鏈路確定好之後，把已經有的經驗、流程和標準做成策略。一旦出現問題，自動監控，通過一些系統化的方式解決。自動治理的第一步還是治理方案的落地和策略化，這非常依賴於元數據，把數據治理各個過程中的一些經驗技術都沉澱起來。做完策略沉澱之後做自動化，把策略用工具的方式實現，當系統發現數據有問題時，自動就去處理。

目前，美團酒旅業務數據治理處在第二階段和第三階段之間，雖然有整體治理計劃、技術架構和組織保障，但仍需要投入一定的人力去做。未來，數據治理會繼續朝着智能化的方向進行探索，真正把自動化治理工作做得更好。

四、作者簡介

• 建舒，2015 年加入美團，數據科學與平臺部數據工程師。

• 王磊，2017 年加入美團，數據科學與平臺部數據工程師。

• 羅茜，2017 年加入美團，數據科學與平臺部數據產品經理。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/gp-g70P8qCvpi1LavXvOUw