美團酒旅數據治理實踐

時間 2021-04-17

原文原文鏈接

數據已成爲不少公司的核心資產，而在數據開發的過程當中會引入各類質量、效率、安全等方面的問題，而數據治理就是要不斷消除引入的這些問題，保障數據準確、全面和完整，爲業務創造價值，同時嚴格管理數據的權限，避免數據泄露帶來的業務風險。數據治理是數字時代不少公司一項很是重要的核心能力，本文介紹了美團酒旅平臺在數據治理方面的實踐。

1、背景

1. 爲何要作數據治理

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

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

同時，在數據開發的過程當中也會不斷引入一些問題，而數據治理就是要不斷消除引入的這些問題，保障數據準確、全面和完整，爲業務創造價值，同時嚴格管理數據的權限，避免數據泄露帶來的業務風險。所以，數據治理是數字時代不少公司一項很是重要的核心能力。數據庫

2. 須要治理哪些問題

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

質量問題：這是最重要的問題，不少公司的數據部門啓動數據治理的大背景就是數據質量存在問題，好比數倉的及時性、準確性、規範性，以及數據應用指標的邏輯一致性問題等。
成本問題：互聯網行業數據膨脹速度很是快，大型互聯網公司在大數據基礎設施上的成本投入佔比很是高，並且隨着數據量的增長，成本也將繼續攀升。
效率問題：在數據開發和數據管理過程當中都會遇到一些影響效率的問題，不少時候是靠「盲目」地堆人力在作。
安全問題：業務部門特別關注用戶數據，一旦泄露，對業務的影響很是之大，甚至能左右整個業務的生死。
標準問題：當公司業務部門比較多的時候，各業務部門、開發團隊的數據標準不一致，數據打通和整合過程當中都會出現不少問題。

3. 美團酒旅數據現狀

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

數據質量問題嚴重：一是數據冗餘嚴重，從數據任務增加的速度來看，新上線任務多，下線任務少，對數據表生命週期的控制較少；二是在數據建設過程當中，不少應用層數據都屬於「煙囪式」建設，不少指標口徑沒有統一的管理規範，數據一致性沒法進行保證，同名不一樣義、同義不一樣名的現象頻發。
數據成本增加過快：某些業務線大數據存儲和計算資源的機器費用佔比已經超過了35%，若是不加以控制，大數據成本費用只會變得愈來愈高。
數據運營效率低下：數據使用和諮詢多，數據開發工程師須要花費大量時間一對一解答業務用戶的各類問題。可是這種方式對於用戶來講，並無提高數據的易用性，沒法有效地積累和沉澱數據知識，還下降了研發人員的工做效率。
數據安全缺少控制：各業務線之間能夠共用的數據比較多，並且每一個業務線沒有統一的數據權限管控標準。
開發標準規範缺失：早期爲快速響應業務需求，研發人員一般採用「煙囪式」的開發模式，因爲缺少相應的開發規範約束，且數據工程師的工做思路和方式差別性都很是大，致使數據倉庫內的重複數據多，規範性較差。當發生數據問題時，問題的排查難度也很是大，且耗時較長。

4. 治理目標

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

創建數據開發全鏈路的標準規範，提升數據質量，經過系統化手段管理指標口徑，保障數據一致性。
控制大數據成本，避免大數據機器成本膨脹對業務營收帶來的影響，合理控制數據的生命週期，避免數據重複建設，減小數據冗餘，及時歸檔和清理冷數據。
管理數據的使用安全，創建完善的數據安全審批流程和使用規範，確保數據被合理地使用，避免因用戶數據泄露帶來的安全風險和商業損失。
提升數據工程師的開發和運維效率，減小他們數據運營時間的投入，提升數據運營的自動化和系統化程度。

2、數據治理實踐

其實早在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%的平常答疑時間，極大地減小了研發同窗工做被打擾的次數，提升了開發效率。

3、將來規劃

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

第一階段咱們作的是被動治理，也就是階段性治理，確少統籌考慮，主要是基於單個問題的治理，並且治理以後過一段時間可能還要作重複治理。這個階段更可能是人治，一個項目成立，協調幾我的按照項目制完成，沒有體系規劃，也沒有組織保障。
第二階段是主動治理，有長期的統籌規劃，能覆蓋到數據生命週期的各個鏈路，在治理過程當中把一些手段和經驗流程化、標準化、系統化，長期解決一些數據問題，讓數據治理長期可控。
第三階段是自動治理，也是智能治理，在長期規劃和數據生命週期各環節鏈路肯定好以後，把已經有的經驗、流程和標準作成策略。一旦出現問題，自動監控，經過一些系統化的方式解決。自動治理的第一步仍是治理方案的落地和策略化，這很是依賴於元數據，把數據治理各個過程當中的一些經驗技術都沉澱起來。作完策略沉澱以後作自動化，把策略用工具的方式實現，當系統發現數據有問題時，自動就去處理。

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