資料治理2 美團

今天我們來探討一下關於資料治理的靈魂三問：

1、資料治理治什麼，治的是資料嗎？

2、資料治理在哪裡治，中臺還是後臺？

3、資料治理到底怎麼治？

一、資料治理 治的是“資料”嗎？

資料是指對客觀事件進行記錄並可以鑑別的符號，是對客觀事物的性質、狀態以及相互關係等進行記載的物理符號或這些物理符號的組合。其實在我看來，資料可以分為兩個部分，一是數字，二是文字。數字是沒有意義的抽象符號，資料是有意義的數字。文字表意，數字表量，當兩者結合起來，資料就產生了。

在我們的生活和工作當中，資料無處不在。對企業來講，有很多資料是無關企業重大利益的資料，是沒有治理的必要的。資料治理的物件必須是重要的資料資源，是關乎企業重大商業利益的資料資源，這樣的資料資源可以稱其為“資料資產”。正如北大教授王漢生先生所說：“資料治理不是對“資料”的治理，而是對“資料資產”的治理，是對資料資產所有相關方利益的協調與規範。”

我們需要分開來理解這句話：

①什麼是資料資產？

②資料資產的相關利益方是誰？

③協調與規範什麼？

先說一說什麼是資料資產。我們說不是所有資料都是資料資產，那到底什麼才是資料資產呢？

《企業會計準則-基本準則》第20條規定：“資產是指企業過去的交易或者事項形成的、由企業擁有或者控制的、預期會給企業帶來經濟利益的資源。” 如果照貓畫虎修改一下，不難獲得一個關於資料資產的定義：“資料資產是指企業過去的交易或者事項形成的，由企業擁有或者控制的，預期會給企業帶來經濟利益的資料資源。”由此可見，資料要成為資料資產，至少要滿足3個核心必要條件：

①資料資產應該是企業的交易或者事項形成的；

②企業擁有或者控制；

③預期會給企業帶來經濟利益。

資料資產的利益相關方是誰？

根據資料資產的定義，資料資產的利益相關方，包括：

①資料的生產者，即透過業務交易或事項產生資料的人或組織。

②資料的擁有或控制者，生產資料的人不一定是擁有資料，就像我們天天上網的各種資料都不歸我們自己所有，而是落在了各個網際網路公司的資料庫中。

③資料價值和經濟利益的收益者。資料治理就是對資料生產者、擁有或控制者，資料價值獲益者的規範和協調。

都什麼是需要協調和規範？

首先是資料的標準化，定義統一的資料標準，“寫中國字、說普通話”讓資料資產的相關利益方在同一個“頻道”溝通。資料的標準化包含幾個層面：①資料模型標準化。②核心資料實體的標準化（主資料的標準化）。③關鍵指標的標準化。

其次是資料的確權。資料一旦成為資產，就一定有擁有方，或者實際控制人，可以把他們統稱產權人。與實物不同的是，實物的產權是比較明確的，資料則比較複雜。產品在生產製造過程中，並沒有與消費者交易之前，製造商擁有完全產權。產品生產出來後，消費者透過購買支付相應的貨幣，便擁有了產品的產權。而資料的生產過程就不一樣了，我們的各種上網行為每天都會產生大量的資料，例如：網上購物、瀏覽網頁、使用地圖、評論/評價……。這些資料到底歸誰所有？控制權該如何治理？這是擺在面前的一個難題！我們看到近幾年一些不良商家，利用我們的上網資料，導致安全隱私洩密的事件也層出不窮。希望隨著技術和商業的進步，儘快能夠找到解決方案！

第三是流程的最佳化。資料治理的兩個目標：一個是提質量，一個是控安全。網際網路資料的確權目前已經是一個世界級難題，做好企業業務流程的最佳化可能會對隱私保護起到一定的作用。透過業務流程最佳化，規範資料從產生、處理、使用到銷燬的整個生命週期，使得資料在各階段、各流程環節安全可控，合規使用。另外，透過一定的流程最佳化，透過對相關流程進行監管，按照資料的質量規則進行資料校驗，符合“垃圾進、垃圾出”的資料採集、處理、儲存原則，提升資料治理，賦能業務應用。

二、資料治理 到底在哪裡治？

資料治理到底應該放在中臺，還是後臺，我個人的理解是：小資料標準化治理靠人工、大資料預測性分析靠智慧，將兩者結合起來：“人工+智慧”形成了完整的資料治理技術體系。一個企業的資料治理既離不開小資料的標準化治理，也離不開大資料的預測性分析。

這裡的小資料，是在承載事物實體的資料，例如：人、財、物等，是企業所有業務開展的載體。其實說白了就是主資料管理。對於主資料的治理筆者認為是一個後臺行為，治理核心是“唯一資料來源、統一資料標準”，而要達到這一目標是需要從資料的源頭抓起的，並且需要大量的人為干預，比如：資料標準的制定和落實，資料質量的清洗，資料的申請審批，資料的分發和共享等。從這裡也能夠看出小資料的治理，追求的是標準化、精確化，應該是一個後臺行為。

而在大資料時代，得益於大資料技術的突破，大量的結構化、非結構化、異構化的資料能夠得到儲存、處理、計算和分析，這一方面提升了我們從海量資料中獲取知識和洞見的能力。對於大資料，傳統的一味追求精確的思維受到了挑戰。而對於大資料的治理，允許一定程度上的容錯，反而可以在宏觀層面擁有更好的知識和洞察力。對於大資料的治理更多的是採用AI技術，例如：知識圖譜、語音識別等，對大資料的採集、處理、使用過程加以控制，使其能夠合規使用。所以，大資料的治理放在中臺似乎更為合適。

三、資料治理 到底應該怎麼治？

1、找症狀，明確目標

任何企業實施資料治理都不是為了治理資料而治理資料，其背後都是管理和業務目標的驅動。企業中普遍存在的資料質量問題有：資料不一致、資料重複、資料不準確、資料不完整、資料關係混亂、資料不及時等。

由於這些資料問題的存在對業務的開展和業務部門之間的溝通造成了較大的困擾，產生了很大的成本；各異構的系統中資料不一致，導致業務系統之間的應用整合無法開展；資料質量差無法支撐資料分析，分析結果與實際偏差較大。然而要實現資料驅動管理、資料驅動業務的目標，沒有高質量的資料支撐是行不通的。

目標：企業實施資料治理的第一步，就是要明確資料治理的目標，理清資料治理的關鍵點。

技術工具：實地調研、高層訪談、組織架構圖。

輸入：企業資料戰略規劃，亟待解決的業務問題，經營發展需求，業務需求等；

輸出：資料治理的初步溝通方案，專案任務書，工作計劃表；

2、理資料，現狀分析

針對企業資料治理所處的內外部環境，從組織、人員、流程、資料四個方面入手，進行資料治理現狀的分析。

某企業資料治理痛點分析

組織方面：是否有專業的資料治理組織，是否明確崗位職責和分工。

人員方面：資料人才的資源配置情況，包括資料標準化人員、資料建模人員，資料分析人員，資料開發人員等，以及資料人才的佔比情況。

流程方面：資料管理的現狀，是否有歸口管理部門，是否有資料管理的流程、流程各環節的資料控制情況等；

資料方面：梳理資料質量問題列表，例如：資料不一致問題，資料不完整，資料不準確、資料不真實、資料不及時、資料關係混亂，以及資料的隱私與安全問題等。

目標：分析企業資料管理和資料質量的現狀，確定初步資料治理成熟度評估方案。

技術工具：實地訪談、調研表、資料質量問題評議表、關鍵資料識別方法論（例如：主資料特徵識別法）；

輸入：需求及現狀調研表、訪談記錄、資料樣本、資料架構、資料管理制度和流程檔案；

輸出：資料問題列表、資料U/C矩陣、資料治理現狀分析報告、資料治理評估方案；

3、資料治理成熟度評估

資料治理成熟度反映了組織進行資料治理所具備的條件和水平，包括後設資料管理、資料質量管理、業務流程整合、主資料管理和資訊生命週期管理。

CMMI DMM資料管理能力成熟度評估模型

資料治理成熟度評估是利用標準的成熟度評估工具結合行業最佳實踐，針對企業的資料治理現狀進行的客觀評價和打分，找到企業資料治理的短板，以便制定切實可行的行動方案。資料治理成熟度結束後形成初步的行動方案，一般包括資料治理戰略，資料治理指標，資料治理規則，資料治理權責。資料治理願景和使命是資料治理的整體目標；資料治理指標定義了資料治理目標的衡量方法；資料治理規則和定義包括與資料相關的政策、標準、合規要求、業務規則和資料定義等；權利和職責規定了由誰來負責制訂資料相關的決策、何時實施、如何實施，以及組織和個人在資料治理策略中該做什麼。

目標：結合業界標準的資料治理成熟度模型，根據企業管理和業務需求進行資料治理成熟的評估，形成初步的資料治理策略和行動路線。

技術工具：資料治理評估模型，例如：DCMM，CMMI DMM，IBM資料治理成熟度評估模型等；

輸入：第2步的輸入以及資料治理評估模型、資料治理評估工具（評估指標、打分表等）；

輸出：資料治理評估結果，資料治理策略，初步的行動方案；

4、資料質量問題根因分析

資料治理的目的是解決資料質量問題提升資料質量，從而為資料驅動的數字化企業提供源動力，而提到資料質量問題，做過BI、數倉的同學一定知道，這是一個技術和業務“經常打架”相互推諉的問題。

某企業資料問題根因分析魚骨圖

產生資料質量問題的原因有很多，有業務方面的、有管理方面的、也有技術方面的，按照80/20法則，80%的問題是由20%的原因造成起的。所以，如果能夠解決這20%的問題，就能得到80%的改進。

目標：分析並找到資料質量問題產生的根本原因，制定行之有效的解決方案；

技術工具：頭腦風暴、5W1H、SWOT、因果（魚刺）圖、帕拉圖等；

輸入：資料問題列表、資料U/C矩陣、資料治理現狀分析報告、資料治理評估結果；

輸出：資料質量評估結果、對業務的潛在影響和根本原因。

5、業務影響及實施優先順序評估

透過資料治理成熟度評估，從組織、流程、制度、人員、技術等方面找到企業在資料治理的待提升的領域和環節，再透過資料質量根因分析找到資料質量問題發生的根本原因，進一步明確了資料治理的目標和內容。再接下來，就需要確定資料治理策略，定義資料治理的實施優先順序。

某企業主資料治理實施優先順序評估

不同的資料治理領域解決的是不同的問題，而資料治理的每個領域都有它的實施難點，對企業來說，需要從業務的影響程度，問題的緊急程度、實施的難易程度等多個維度進行分析和權衡，從而找到符合企業需求並滿足企業發展的方案。

目標：確定資料治理核心領域和支撐體系的建設/實施優先順序；

技術工具：四象限法則（分別從業務影響程度/實施難以程度，問題重要程度/問題緊急程度繪製優先順序矩陣）、KANO模型

輸入：資料治理成熟度能力評估結果、資料質量問題根因分析結果；

輸出：資料治理實施優先順序策略

6、制定資料治理行動路線和計劃

路線圖是使用特定技術方案幫助達到短期或者長期目標的計劃，用於新產品、專案或技術領域的開發，是指應用簡潔的圖形、表格、文字等形式描述技術變化的步驟或技術相關環節之間的邏輯關係。路線圖是一種目標計劃，就是把未來計劃要做的事列出來，直至達到某一個目標，就好像沿著地圖路線一步一步找到終點一樣，故稱路線圖。

某企業資料治理實施路線圖

企業資料治理的實施路線圖的制定是以企業資料戰略——願景和使命為綱領，以急用優先為原則，以分步實施為策略進行了整體設計和規劃。實施路線圖主要包含的內容：分幾個階段實施，每個階段的目標、工作內容、時間節點要求、環境條件等。筆者觀點：任何一個企業的資料治理都不是一蹴而就，一步到位的，需要循序漸進、持續最佳化！實施路線圖就是基於此產生的，因此說資料治理實施路線圖也是說服利益相關者支援的一個重要手段。

目標：確定資料治理的階段以及每個階段的目標；

技術工具：路線圖法

輸入：資料治理成熟度能力評估結果、業務影響及實施優先順序評估結果；

輸出：資料治理實施路線圖或稱階段目標計劃

7、制定資料治理詳細實施方案

資料治理詳細實施方案是用於指導主資料的各項實施工作，一般包括：資料治理核心領域、資料治理支撐體系、資料治理專案管理三個方面。

資料治理總體框架圖

資料治理核心領域包括：資料架構、資料服務、後設資料管理、資料質量管理、資料標準管理、主資料管理、資料安全管理、資料生命週期管理。

資料治理支撐體系包括：組織（組織架構、組織層次、崗位職責）、制度（管控模式、規章制度、考核機制）、流程（歸口部門、管理流程、流程任務等）、技術（資料整合、資料清洗、資料開發、資料應用、資料運營、支撐平臺、實施方案等）。

資料治理專案管理方案包括：專案組隊、專案計劃、質量保證計劃、配置管理計劃、培訓和售後等。

關於資料治理的核心領域，詳見筆者之前分享的資料治理框架解讀系列文章。

關於資料治理的支撐體系，詳見筆者之前分享的資料治理成功關鍵要素系列文章。

目標：基於資料質量根因分析、業務影響和實施優先順序評估結果，制定詳細實施方案；

輸入：業務影響及實施優先順序評估結果，行動路線和計劃；

輸出：資料治理詳細實施方案。

8、資料治理實施過程控制

資料治理實施過程控制是對資料治理專案的範圍控制、進度控制、質量控制和成本控制，透過對企業的各項資源的合理協調與利用，而達成的資料治理目標的各種措施。從專案管理的角度來講也是專案管理的黃金三角：範圍、時間、質量、成本。

任何專案的質量和進度是需要良好的專案管理來保證的，資料治理也一樣。與傳統的軟體工程專案不同，資料治理專案有著範圍邊界模糊、影響範圍廣、短期難見效、實施週期長等特點：

①範圍邊界模糊，資料治理涉及到的關鍵領域如後設資料管理、資料質量管理、資料標準管理、主資料管理等很多是存在交叉的，邊界很難界定，例如：實施資料質量管理專案，會涉及後設資料管理、資料標準管理等，同樣一個後設資料管理專案也會涉及資料標準和資料質量。

②影響範圍廣，資料治理的實施不是一個部門能夠完成的，是需要從高階管理層、到各業務部門、資訊部門通力協作，共同完成的；

③短期難見效，資料治理專案實施完成後，其資料治理的效果被每個業務點滴操作所“稀釋”，並不像其他專案，例如BI，那樣明顯的體現出來，所以主導資料治理的部門會經常遭到質疑。

④實施週期長，在沒有清晰的資料治理目標和範圍約定的情況下，資料治理是一個“無底洞”。所以，在實施資料治理專案之前制定好實施路線圖和詳細的實施方案就顯得格外重要（第6、7步）。

目標：透過對資料治理專案實施過程的進度控制、質量控制和成本控制以實現資料治理的目標；

技術工具：PP（專案計劃）、PMC（專案控制）、IPM（整合專案管理）、RSKM（風險管理）——CMMI過程域；

輸入：6-7步的輸出：資料治理實施路線圖，資料治理詳細實施方案；

輸出：各項專案控制措施，例如：專案計劃、SOW、專案風險列表、專案報告、專案總結等；

9、監控評估資料治理實施效果

隨著大資料技術的不斷髮展，應當從企業的全域性資料治理環境的角度，明確資料治理關鍵技術運用及其標準規範，構建成效評估指標體系，進行治理效果評價；並運用資料治理能力成熟度模型再次評估，界定資料管理層次，從而使得跨系統、跨業務、跨部門的資料治理體系的建設與實施能夠透過各方協作順利進行，實現卓越資料治理，進而透過資料驅動業務、資料驅動管理和運營以實現企業的降本、增效、提質、創新。

某企業資料治理看板（資料已脫敏）

資料治理成效評估指標體系應根據企業及資料治理專案的實際情況制定，一般包括：時間性、數量性、完整性、準確性四個維度。

①時間性即資料的及時性。該維度主要透過源業務系統資料接入的上報及時性、接入及時性等方面進行核對。透過分析月指標、周指標、日指標的資料及時率，得出在規定時間和頻度週期內接入系統的比例，以此反映資料接入及時性。

②數量性。該維度是從資料存量，資料增量，資料訪問量，資料交換量、資料使用量等指標反映資料的使用情況，可以分為月度指標、周指標、日指標、時分指標等。

③準確性。這個維度主要由各類資料中邏輯的準確性、資料值的準確性、資料頻段和欄位之間的準確性以及資料的精度等內容組成。該準確率同樣包括：月度、每週、每日等準確率指標。

④完整性。此維度主要以單元維度完整性、資料業務維度組合完整性、索引值完整性等不同方面進行核對，是驗證資料質量完整性的主要組成部分，包括月度指標、周指標、日指標資料的完整性等內容。

目標：檢驗各項資料治理指標的落實情況，查漏補缺，夯實資料治理效果；

技術工具：資料治理效果的評價指標體系、各種資料圖表工具；

輸入：資料治理效果評估指標；

輸出：資料治理評估的月報、週報、日報等；

10、資料治理持續改進

資料治理模式應業務化、常態化，不應是一個專案、“一陣風”的模式。

資料治理工作應向企業生產、銷售業務一樣作為一項重點的業務工作來開展，構建專業的資料治理組織，設定合適的崗位權責，建立相應的管理流程和制度，讓資料標準貫徹到每個業務環節，形成一種常態的工作。在筆者看來，在資料來源頭加強企業資料的治理，讓常態化治理成為日常業務，才能從根本上徹底解決企業資料質量的各種問題，讓資料真正轉化為企業資產，以實現資料驅動流程最佳化、資料驅動業務創新、資料驅動管理決策的目標。

目標：資料治理常態化，持續提升資料質量，驅動流程最佳化和管理創新。

輸入：持續的、規範的、標準的各項業務操作；資料治理監控的各項指標和報告；

輸出：持續輸出的高質量的資料。

四、美團配送資料治理實戰

從大的階段來看，資料治理主要分為存量資料“由亂到治”的階段，以及增量資料嚴格按照規章制度實施確保“行不逾矩”的運營階段。在“由亂到治”的過程中，我們需要沉澱出規章制度、標準規範，以及輔以規章制度標準規範實施的工具和組織。在增量資料的運營階段，我們主要靠對應的組織確保規章制度的落實，透過審計定期考察實施效果，並在長期的運營中不斷完善規章制度。在實現存量資料“由亂到治”的階段，我們主要採取了“兩步走”策略，具體執行策略如下所示。

4.1 定標準，提質量

4.1.1 業務標準

業務標準主要是指標的管理和運營標準，我們主要解決三個問題：指標由誰來定義，指標該如何定義，指標該如何運營。基於這三個問題，我們同時提出了三條原則：

• 業務團隊負責指標的定義。
• 產研商分負責給出指標定義標準和輔助工具，輔助業務團隊完成指標的規範定義，達成指標認知一致性這一目標。
• 最後由指標管理委員會負責指標的管理與運營，保障指標從建立、稽核、上線以及到最後消亡的整個生命週期的運營。

為統一指標的定義，我們將指標分為原子指標、衍生指標和派生指標，原子指標透過限定條件和時間的限定生成衍生指標。衍生指標間的“四則混合運算”構成了派生指標。我們不但制定了指標的標準定義，還對其做了準確的資產歸屬，一個指標出自一個具體的業務過程，一個業務過程歸屬於不同的資料域，多個資料域構成了美團配送業務線下的分析場景，如下圖所示：

指標定義標準

4.1.2 技術標準

這裡所說的技術標準，主要是針對資料RD提出的建模標準和資料生產規範，透過建模標準來明確數倉分層架構，並清晰定義每一層的邊界與職責，採用維度建模的設計理念。我們的整個倉庫架構分為四層：操作層、基礎事實層、中間層和應用層，並在每一層同步制定對應的建模規範，如下圖所示：

數倉架構以及建模標準

除了建模標準外，我們還制定了涵蓋從生產到運維環節的生產規範以保障模型的質量，主要包括上線前的模型評審、生產過程中的完成後設資料配置、DQC、SLA和生命週期設定以及上線後的日常運維機制等等。尤其針對後設資料管理和生命週期管理，我們分別制定了倉庫每一層後設資料維護規範和生命週期管理規範，其中後設資料管理規範，是依據數倉各層級中各種型別表的建模標準來制定，需要做到規範命名，明確資料歸屬，並打通業務後設資料和技術後設資料之間的關係。而生命週期管理規範，是依據配送業務特點和數倉各層級現狀來制定的，如下表所示：

倉庫各層後設資料管理標準

倉庫各層生命週期管理策略

4.1.3 安全標準

圍繞資料安全標準，首先要有資料的分級、分類標準，確保資料在上線前有著準確的密級。第二，針對資料使用方，要有明確的角色授權標準，透過分級分類和角色授權，來保障重要資料拿不走。第三，針對敏感資料，要有隱私管理標準，保障敏感資料的安全儲存，即使未授權使用者繞過許可權管理拿到敏感資料，也要確保其看不懂。第四，透過制定審計標準，為後續的審計提供審計依據，確保資料走不脫。

安全標準建設

4.1.4 資源管理標準

在資源管理方面，配送技術工程部已經對資源管理涉及的內容進行了合理抽象和準確定義，抽象出租戶、資源和專案組等概念。不管是後續的資源預算還是資源管理，我們都需要基於租戶和專案組來進行運營，因此，對於業務團隊而言，我們只需要將租戶和專案組特定職能劃分清楚，然後根據不同的職能歸屬我們的資產，並分配生產該資產所需要的資源。為了方便後續的運營，我們對每個租戶和專案組分配確定了責任人，由責任人對運營結果負責。

對業務部門來說，資源管理的關鍵是對資料資產做清晰的分類，基於資料的分類劃分不同的租戶和專案組，將資料和租戶、專案組實現一一對映。由於租戶和專案組都有特定的責任人對其負責，因此，我們透過這種對映關係，不僅實現了資產的隔離，還實現了資產確權（專案組負責人同時對資產負責和運營）。我們整體將資料分為兩大類，一是原始資料，包括流到資料中心的資料和日誌中心的資料，針對流入資料中心的資料，根據其產生的方式不同，又進一步分為業務資料和流量資料。二是加工資料，對應著資料團隊的倉庫建設和其他團隊的集市建設。基於上述的描述，針對資源管理，我們做了如下劃分和確權：

資源劃分與管理

4.2 重實施，保落實

第二步，落實第一步的標準，完成資料治理第一階段的目標，實現存量資料“由亂到治”，並完成相應組織和工具的建設，為實現第二階段“行不逾矩”這一目標提供工具和組織能力。在此過程中，主要分成三個方面的治理工作：第一，架構模型“由亂到治”的治理，消除模型冗餘、跨層引用和鏈路過長等問題，在架構上保證模型的穩定性和資料一致性；第二，後設資料“由亂到治”的治理，實現指標的標準定義、技術後設資料的完整採集並建立指標與表、欄位的對映關係，徹底解決指標認知一致性，以及使用者在使用資料過程中的“找數難”等問題；第三，圍繞著隱私安全和共享安全加強資料的安全管控來實現資料走不脫、拿不走，以及隱私資料看不懂這一目標。

4.2.1 架構治理

總結起來，架構方面的治理主要是解決兩個問題：第一，模型的靈活性，避免需求變更和業務迭代對核心模型帶來的衝擊，讓RD深陷無休止的需求迭代中；第二，資料一致性，消除因模型冗餘、跨層引用等問題帶來的資料一致性問題。

模型靈活性

配送解決的是效率、成本和體驗三者之間的平衡問題，即在滿足一定使用者體驗的條件下，如何提升騎手配送效率，服務更多的商家，以及如何管控騎手，降低配送成本。抽象到資料層面，基本上反映為上游包裹來源的變化、配送對外提供服務的變化以及對內業務管控的變化。為遮蔽業務迭代給核心模型帶來的衝擊，我們透過對外封裝包裹屬性和對內封裝運單屬性，抽象出包裹來源、提供服務、業務架構等一致性維度，任何業務迭代在資料層面只涉及維度的調整，大大降低了對核心模型衝擊和“煙囪式”資料建設問題（新來一個業務，就拉起一個分支進行建設）。

包裹事實分配到運單明細構造單一運單模型

配送指標體系建設的一個重點就是要輸出各組織層級的規模、體驗和效率指標，實現對運力的有效管控，運力所屬組織的層級關係會隨業務的迭代而不斷變化。為了適應這種變化，避免僅僅因增加維度帶來中間層資料的重複建設，我們將組織層級維表由固定層級建模方式調整為橋接表的方式來自適配組織層級變化，從而實現了中間層模型可以自動適配組織層級的變化，能自動產生新維度的指標。如下圖所示：

橋接表自適配組織層級靈活變動

在精細化分析的場景下，業務會有分時段、分距離段以及分價格段的資料分析訴求。我們以分時段為例，有晚高峰、午高峰、下午茶等不同的分時段，不同的業務方對同一個時段的定義口徑不同，即不同的業務方會有不同的分時段策略。為解決該場景下的分析訴求，我們在事實表中消除退化維度，將原來封裝到事實表的時段邏輯遷移到維度表中，並將事實表中的時間進行按特定的間隔進行刻度化作為維表中的主鍵，將該主鍵作為事實表的外來鍵。這樣，針對業務不同的時間策略需要，我們就可以在維表中進行配置，避免了重複調整事實表和反覆刷數的問題。即透過將時間、價格、距離事實刻度化，實現靈活維度分析。如下圖所示：

透過將時間刻度化，實現靈活分析

資料一致性

資料一致性得不到保障的一個根本原因，是在建模的過程中沒有實現業務口徑標籤化，並將業務口徑下沉到主題層。很多同學在基於需求進行開發時，為實現方便，將新指標口徑透過“Case When”的方式在應用層和中間層進行封裝開發，主題層建設不能隨著業務的迭代不斷完善，RD在開發過程中會直接引用倉庫的快照表在中間層或應用層完成需求開發。久而久之，就會造成資料複用性低下，相同指標的口徑封裝在不同的應用表來滿足不同報表的需求，但隨著應用的增多，很難保障相同指標在不用應用表封裝邏輯的一致性，資料一致性難以得到保障，同時這種方式還帶來兩個嚴重後果：第一，跨層引用增多，資料複用性低下，造成計算和儲存成本的浪費；第二，一旦指標口徑發生變化，將是一個“災難”，不僅影響評估是一個問題，而且涉及該指標的應用層邏輯調整對RD來說也是一個巨大的挑戰。

治理前模型架構

因此，我們在“由亂到治”的治理過程中，以衍生事實的方式實現業務口徑標籤化，將業務邏輯下沉到主題層，消除跨層引用和模型冗餘等問題，從技術層面保障資料一致性是該階段架構治理的重點。我們在業務上，已經劃分了嚴格的資料域和業務過程，在主題建設層面，將業務劃分的資料域作為我們的主題，並基於業務過程進行維度建模，將屬於該業務過程的指標口徑封裝在對應業務過程下的衍生事實中。

治理後模型架構

4.2.2 後設資料治理

後設資料治理主要解決三個問題：首先，透過建立相應的組織、流程和工具，推動業務標準的落地實施，實現指標的規範定義，消除指標認知的歧義；其次，基於業務現狀和未來的演進方式，對業務模型進行抽象，制定清晰的主題、業務過程和分析方向，構建完備的技術後設資料，對物理模型進行準確完善的描述，並打通技術後設資料與業務後設資料的關係，對物理模型進行完備的刻畫；第三，透過後設資料建設，為使用資料提效，解決“找數、理解數、評估”難題以及“取數、資料視覺化”等難題。

首先，為保障業務標準的順利實施，實現業務對指標認知一致性這一目標。我們協同產研、商分、業務部門推動成立了度量衡委員會，並建立起指標運營機制，透過組織保障來實現指標運營按照規範的標準和流程實施。如下圖所示：

指標註冊流程

其次，基於配送業務的現狀和未來演進方式，我們進行了高度的業務抽象，完成了主題、業務過程和分析方向等後設資料內容的建設。配送即物流，透過線上系統和線下運營，我們將使用者的配送需求和美團的運力進行有效的資源配置，實現高服務體驗、低成本的配送服務。對外，我們將配送服務透過平臺化的方式，提供給使用者、商戶和電商平臺，以滿足不同使用者在不同業務場景下的配送需求。對內，我們透過不同的排程模式將運單池中的運單排程給合適的騎手來完成履約，平衡規模、成本和體驗之間的關係。如下圖所示：

配送業務模式抽象

基於以上的業務模式，我們劃分了運單主題（對履約資料域下的資料進行構建，支撐規模和體驗的資料分析需求）、排程主題（排程資料域下產生的資料，用於支撐排程策略的分析）、結算、評價、投訴、取消主題（用於支撐體驗、成本資料分析需求）和管控主題（用於支撐運力獎懲、違規和招募分析需求）等各種主題，並在每個主題下劃分對應的業務過程，在應用層制定分析方向的分析標籤，透過對後設資料內容的建設完成對業務的抽象，為物理模型的刻畫準備了基礎資料。

第三，後設資料服務建設，我們打通了後設資料從採集到構建再到應用的整條鏈路，為使用資料提效，解決“找數、理解數、評估”難題以及“取數、資料視覺化”難題。在整個建設過程中，我們圍繞著後設資料採集、元模型構建、後設資料服務以及最後的產品應用進行展開，整體架構如下圖所示：

後設資料建設架構圖

後設資料採集

後設資料採集分為人工錄入和自動抽取，透過人工錄入的方式實現物理表的準確歸屬（包括該表屬於倉庫哪一層、對應的主題、業務過程、星型模型關係等）以及指標的採集，從而完成技術後設資料和業務後設資料的採集，透過自動抽取的方式完成生產後設資料的採集和使用後設資料的採集，主要包括：物理模型的依賴關係、儲存佔用、熱度、等資訊。

元模型構建

分為以物理表為核心的基礎元模型構建，以及以血緣為中心的血緣元模型。基礎元模型構建以物理表為中心，打通其與技術後設資料（主題、業務過程、Schema）的關係，實現了物理表的清晰歸屬，打通其與生產後設資料的關係，為其加上了物理表查詢熱度、資源消耗、查詢密級等生產使用資訊，打通其與指標、維度和應用的對應關係，為上層的取數應用建立了完備的後設資料。血緣元模型以血緣為中心，不僅構建了從上游業務表到倉庫離線表的物理血緣，而且打通了倉庫離線表到下游對應報表的血緣，為後續的影響評估構建了完備的後設資料基礎。

後設資料服務

統一後設資料服務（OneService），主要提供兩類後設資料服務，提供查詢表、指標、維度基本資訊的基礎後設資料服務以及查詢表級血緣、欄位級血緣的血緣服務。

後設資料應用

主要孵化出了三個產品，以“找數、理解數、影響評估”為應用場景的資料地圖（Wherehows），以“取數、資料視覺化”為應用場景的資料視覺化（QuickSight），以及以管理審計為目的的管理審計報表。

4.2.3 安全治理

安全治理主要加強了敏感資料的安全治理和資料共享環節的安全治理。透過對隱私資料的安全治理，不僅要保證其在儲存環節的不可見性，而且還要保證在其使用環節對使用者進行雙重鑑權，欄位的密級鑑權和解密的金鑰鑑權；透過對資料共享環節的安全治理，我們在資料分級分類的基礎上，使資料的許可權控制從表級許可權控制擴充套件到行級許可權控制。

敏感資料安全治理

敏感資料的安全治理，主要是解決敏感資料的儲存安全和使用安全。離線場景下，敏感資料儲存安全要解決兩大挑戰：

• 確保倉庫側處理方案既要遮蔽上游業務系統變動帶來的影響，又要遮蔽自身策略對下游BI系統的影響。
• 要避免敏感資料在整個加工鏈路中的擴散。

因此，為解決倉庫處理方案與上游業務系統和下游BI系統的解耦問題，我們在上游敏感資料落到ODS環節，確保落到ODS層的敏感資料必須是明文，為保障其安全，對ODS層的所有資料進行檔案加密，但是在使用層面，對下游鏈路透明保障下游鏈路的正常生產，並限制ODS層資料許可權的開放。

ODS層資料只用於安全生產，透過此方案既遮蔽了上游處理方案對倉庫的影響，又解決了敏感資料的安全問題。當資料從離開倉庫時，在傳輸環節對敏感資料進行可逆操作，將敏感資料以明文的形式推入BI庫，實現與下游BI系統的解耦。為解決敏感資料在整個生產鏈路的擴散，我們在快照層對敏感資料進行脫敏處理，從快照層開始消除敏感資料，為保障敏感資料的可逆性，將ODS層的敏感資料抽取到安全庫中並進行加密儲存，實現安全獨立管理。具體執行如下圖所示：

針對敏感資料的使用安全，我們透過對敏感欄位的許可權控制和對解密金鑰的許可權控制，來實現敏感資料使用安全這一目標。針對單獨抽取的敏感資料，我們除了針對敏感資料設定其相應的密級確保敏感資料的許可權管控外，還基於"暗語"的加密方式為每個專案組分配一個相同的金鑰，並且將該金鑰存放到與Hadoop叢集整合的KMS進行管理（確保支撐離線計算的高併發），確保解密時實現金鑰的許可權管控。

共享環節安全治理

針對共享環節的安全治理，我們主要是在資料生產環節完成資料的分級分類和資料確權，在資料的使用環節完成資料的表級許可權控制和行級許可權控制。確保資料在使用環節規範的審批流轉，許可權開放以後的安全審計，保證資料走不脫。

首先，我們在生產環節B3、B2、B1層資料按照主題或實體C層資料按照應用方向進行邏輯劃分，並設定資源的密級和許可權負責人。特別地為實現B3層資料在查詢環節可按照業務線進行許可權管控這一目標（即行級鑑權），針對B3層資料，我們標記該資料需要在查詢環節進行行級許可權管控，標記使用行級鑑權所需的欄位和該欄位對應的列舉值。

其次，在使用環節，我們按照資產密級和使用人角色完成資料的審批流轉，實現資料的安全共享。

第三，針對B3層資料，審計是否設定了行級許可權管控。在資料開放時是否存在越權使用的情況，以及針對即將離職員工加強資料的使用審計，保證資料走不脫。

在資料“由亂到治”的治理過程中，我們不僅實現了存量資料的“由亂到治”，並且在此過程中沉澱出了一系列的建模方法論、工具，並建立了相應的安全小組和指標運營組織。同時，我們為後續增量資料治理確保資料建設“行不逾矩”，提供了強有力的組織保障、穩定的輔助工具和嚴格的執行標準。在資料治理的第二階段實現增量資料的“行不逾矩”的過程中，我們主要圍繞大資料架構審計、大資料安全與隱私管理審計、大資料質量管理審計和大資料生命週期管理審計這四方面的工作展開，保障治理工作的持續進行，不斷提高了組織的治理水平。

5. 工具簡介

5.1 資料地圖（Wherehows）

資料地圖作為後設資料應用的一個產品，聚焦於資料使用者的“找數”場景，實現檢索資料和理解資料的“找數”訴求。我們透過對離線資料集和線上資料集的後設資料刻畫，滿足了使用者找數和理解數的訴求，透過血緣圖譜，完成物理表到產品的血緣建設，消除使用者人肉評估的痛苦。

離線資料場景

1. 關鍵字檢索和嚮導查詢共同解決了“找資料”的問題：大部分的檢索資料場景下，資料使用者都可以透過關鍵字檢索來得到匹配結果。剩下的一小部分場景，例如，對於新人入職後如何瞭解整個數倉和指標的體系（數倉分幾層，每層解決什麼問題，都孵化出什麼模型；整個指標、維度體系都是怎麼分類，有哪些指標和維度），這部分場景可以使用嚮導查詢功能。嚮導查詢相當於分類查詢，將表和指標按照業務過程進行分類，使用者可以按照分類逐步找到想要的表或指標。

2. 我們打通了業務後設資料和技術後設資料之間的關係，提高了“找資料”的能力：透過“Wherehows”查詢到指標後，不僅不可檢視指標的業務定義，還能檢視指標的技術實現邏輯，指標在哪些維度或維度組合中已經實現，並且能夠在哪張表裡找到這些維度，或維度組合的指標資料。反之，也可以知道在某個維度下已經實現了哪些指標，對應的指標在哪些表裡。這些功能能讓使用者更加方便地找到想要的資料。

3. 我們提供了較為完善的資料資訊，幫助使用者更好理解資料：對於表的資訊，“Wherehows”除了提供表和欄位的中英文名稱、描述資訊等基礎資訊外，為了幫助使用者更好地理解表的建設思路，我們還提供了表的星型模型（可以關聯的一致性維度及對應的維度表）、表的血緣關係等資訊。

4. 我們透過評論問答功能，幫助使用者可以快速得到問題反饋：如果使用者看了資訊後還是感到有問題，“Wherehows”提供評論問答的功能，使用者透過這個功能可以進行提問，會有相應的負責人進行回覆。對於重複問反覆問的問題，使用者透過檢視其它人的提問和回覆就能找到答案。並且負責人還會定期的將問答資訊沉澱到對應的後設資料裡，不斷地對後設資料進行補充和完善。

業務資料場景

業務資料場景主要想解決的一個問題是，如何知道一個業務表（MySQL表）有沒有同步到數倉。如果沒有同步，能夠找誰進行同步。因為已經打通“業務表 -> 數倉表 -> 產品”三者之間的血緣關係，我們能夠輕鬆解決業務資料場景的問題。

生產評估場景

在日常資料生產工作中，我們經常需要對錶進行影響評估、故障排查、鏈路分析等工作，這些工作如果靠純人工去做，費時費力。但現在我們已經打通了“業務表/欄位 -> 數倉表/欄位 -> 產品”三者之間的血緣關係，就能夠在10分鐘內完成評估工作。對於不同的場景，血緣鏈路提供了兩個便捷的功能：過濾和剪枝。例如，某個表邏輯需要修改，需要看影響哪些下游表或產品？應該要通知哪些RD和PM？這種情況下，血緣工具直觀地顯示影響了哪些負責人和產品，以及這個表的下游鏈路。

有些表的鏈路很長，整個血緣關係圖很大，這樣會導致使用者定位資訊或問題。所以血緣工具提供了剪枝的功能，對於沒用的、不想看到的分支可以剪掉，從而讓整個鏈路變得更加直觀。

5.2 資料視覺化（QuickSight）

聚焦於資料使用者“取數”場景，使用QuickSight，使用者可以不再關心資料的來源，不再擔心資料的一致性，不再依賴RD的排期開發。透過所選即所得的方式，滿足了使用者對業務核心指標的二次加工、報表和取數訴求。首先，我們透過指標池、資料集等概念對離線生產的指標進行邏輯隔離，針對不同使用者開發不同的資料集以達到許可權控制的目的，如下圖所示：

使用者、指標池與資料集間的關係

其次，我們為使用者提供一系列的元件，幫助使用者基於為其開放的資料集實現指標的二次加工和資料視覺化功能，滿足其在不同業務場景下的取數和視覺化應用。如下圖所示：

指標加工元件

6. 總結與展望

經過三個階段的治理工作，我們在各個方面都取得了較好的效果：

• 在資料標準方面，我們制定了業務標準、技術標準、安全標準、資源管理標準，從而保障了資料生產、管理、使用合規。
• 在資料架構方面，我們透過橋接表、時間刻度化、業務口徑下沉等手段提升模型靈活性，並保障資料一致性，消除跨層引用和模型冗餘等問題。
• 在資料安全方面，我們加強了對敏感資料和資料共享環節的安全治理，保證資料拿不走、走不脫，隱私資料看不懂。
• 在後設資料建設方面，我們打通了從採集到構建再到應用的整條鏈路，併為資料使用人員提供資料地圖、資料視覺化等後設資料應用產品，幫助他們解決了“找數”、“取數”、“影響評估”等難題。

未來，我們還會繼續透過組織、規範、流程等手段持續對資料安全、資源利用、資料質量等各方面進行治理，並在資料易用性上下功夫，持續降低使用者的資料使用成本。

• 在資料架構方面，隨著資料庫技術的飛速進步，現在已經有很多資料庫能夠支援千萬級乃至億級資料的現算先用，我們也在嘗試使用這些資料庫幫助提升資料開發效率，改善數倉分層管理和應用支撐效率。
• 在資料產品方面，我們將持續完善資料地圖、資料視覺化等資料應用產品，幫助使用者快速探查、高效分析，真正發揮資料的業務價值。

-----------------

以下為分享實景全文：

主題彙報人：

劉晨：大家好，我是劉晨，來自於利為軟體。我們是專注於提供資料治理的諮詢和軟體產品的創業公司。我個人從08年開始從事資料治理，加入利為之前服務於埃森哲。感謝聯盟提供的機會，讓我能將資料治理領域的理論、近幾年個人的實踐和思考與大家分享。

我的分享主要包括如下幾個部分：

1. 基本概念；

2. 資料治理方法；

3. 資料治理實踐；

4. 大資料與資料治理；

5. 書籍推薦

大資料時代的到來，讓政府、企業看到了資料資產的價值，快速開始探索應用場景和商業模式、建設技術平臺。這無可厚非。但是，如果在大資料拼圖中遺忘了資料治理，那麼做再多的業務和技術投入也是徒勞的，因為很經典的一句話：Garbage in Garbage out，資料質量沒有保證。而保證資料質量，資料治理是必須的手段。

資料治理這個話題看似陽春白雪高大上，實際上是非常下里巴人接地氣，或者說必須要頂天立地才能見實效。頂天是指，與資訊化類似，資料治理也是一把手工程，沒有高層推動、在業務與業務間、業務與技術間協調，資料治理無法落地；立地是指：一般是IT人員對資料問題有深刻體會，也是IT人員最先意識到資料治理的重要性，而且資料治理最終是在IT層面落地的。因此我今天談的很多內容，有不少是與IT建設和運維相關，不一定能讓各位業務專家、商業領導完全理解、引起共鳴，還請各位見諒。但也正因為此話題重要卻又不易被理解，國外會將How to sell data governance to business作為一個專門話題來討論，甚至已經出書專門闡述。

1. 基本概念

1.1 資料分類

言歸正傳，首先是基本概念部分，既然談到資料，我們首先要看一下資料的分類。其實我有點擔心提到“分類”這個詞，因為每個人、每個角色分類的視角都是不同的，各有道理。我所提的資料分類，是指在企業資訊化領域做資料治理通常的分類方式。有其他方式也歡迎提出來大家一起探討。我們通常將資料分為：主資料、交易資料、參考資料、後設資料和統計分析資料（指標）。上一張圖來說明：

為什麼要談資料分類，因為對每類資料進行治理時，關注點、方法和效果都不同，需要區別對待。下面談一點我個人的理解：

主資料關注的是“人”和“物”，主資料管理（MDM）是資料治理領域一個專門的話題，其主要目的是對關鍵業務實體（如員工、客戶、產品、供應商等）建立統一檢視，讓客觀世界裡本是同一個人或物，在資料世界裡也能做到唯一識別，而不是在不同系統、不同業務中成為不同的人或物。主資料管理在各行業企業已經有大量的實踐，受限於時間，今天不單獨展開，其核心管理思想是和後面要談的資料治理方法一脈相承的；

交易資料關注的是“事”，交易資料沒有形成單獨的資料治理領域，由於交易資料是BI分析的基礎，因此往往在資料質量管理中重點關注；

參考資料是更細粒度的資料，是對“人”“事”“物”的某些屬性進行規範性描述的，對參考資料的管理一般會與主資料管理同時進行，或與BI資料質量管理同時進行，因為指標維度和維值直接影響到BI資料質量；

後設資料是一個包羅永珍的概念，其本質是為資料提供描述，所以任何資料都有後設資料。資料治理領域的後設資料，更多是指BI、資料倉儲這個範疇內的後設資料（國際上有Common Warehouse Meta-model規範），此外還有資訊資源管理的後設資料（如Dublin core協議）、地理資訊後設資料、氣象後設資料等等。正因為如此廣泛，也造成了從業者對其有極高的預期以及實踐後的極大失落。

多說兩句後設資料：我個人從事過4年左右後設資料管理的產品設計和方案規劃，但現在極少談“後設資料”，而是談“資料定義”，談資料必談定義，但卻又不將其作為專門一類資料來管理，在資料治理領域單獨做後設資料管理，收效甚微。

主要原因有兩點：1.資料生產與資料管理脫節，後設資料管理更多是在資料生產的事後進行後設資料收集和應用展現，對資料生產起到的管控作用極小；2.工具自身問題：雖然很多工具都號稱支援CWM規範，但後設資料自動獲取始終是技術難題，而且對於儲存過程、自定義指令碼很難自動解析和獲取，就無法準確、完整展現細節的資料處理過程。

統計分析資料（指標），無需多言，目前BI系統建設的主要作用就是做各種指標和報表的計算和展示。指標往往是資料治理的重點，指標的資料流分析、指標數值的波動性、平衡性監控，幾乎是各個企業做資料治理的必備應用。

1.2 資料治理

談完資料分類，再來談“什麼是資料治理”。資料治理的英文是DataGovernance，不同軟體廠商和諮詢公司給出的定義也會有所不同，但本質都是相似的。我這裡引用《DAMA 資料管理知識體系指南》一書給出的定義：資料治理是對資料資產管理行使權力和控制的活動集合（規劃、監控和執行）。資料治理職能指導其他資料管理職能如何執行。可能有些抽象，有圖有真相，下面這張圖說明了資料治理與其他幾個資料管理職能的關係：

可以看到資料治理貫穿在資料管理的整個過程中，重點關注的是有關資料的戰略、組織、制度等高層次的話題，並透過制定和推行戰略、組織、制度，將其他幾個資料管理職能貫穿、協同在一起，讓企業的資料工作能夠成為一個有機的整體而不是各自為政。

有關Data Governance的中文翻譯，國內最常見的翻法有兩種：資料治理、資料管控。國內客戶似乎更喜歡資料管控，因為這個詞有力度、體現權威。我個人從實踐層面的體會：治理與管控缺一不可，治理在前、管控在後，治理針對的是存量資料，是個由亂到治、建章立制的過程，而管控針對的是增量資料，實現的是執法必嚴、行不逾矩的約束。

為什麼要做資料治理？下面是一份國際資料質量協會的調研結果可以參考。

從理論上來講資料治理主要是三個目的：保證資料的可用性、資料質量和資料安全。而在實踐層面，國內外談到資料治理，其主要目的都是資料質量，對於資料安全，往往是有專門的團隊和管理舉措，從資料治理領域涉及的較少。我們下面的討論也繼承這種習慣，主要探討資料質量這個目標。

概念探討先告一段落，後面在探討方法和實踐的時候，會反過來對概念有更好的理解。

2. 資料治理的方法

在方法部分，我們主要講三個內容：誰負責資料治理？治理或者管控物件是什麼？技術工具有哪些？

2.1 組織架構

首先來談誰負責資料治理，也就是組織架構，先上一張圖。

從理論和國外實踐來看，大型企業會建立企業級資料治理委員會，有業務部門領導、IT部門領導共同參與，讓業務與業務之間、業務與技術之間能夠有更充分的討論溝通，從而對宏觀的資料戰略、制度達成共識。在企業級之下，還可以有部門級、專案級的委員會，負責某些區域性的資料治理，在最基層面向某一個業務領域應該有相應的資料管理專員（DataSteward）。Steward實際上是管家的意思，但翻譯成管家似乎不夠嚴肅，因此採用了“專員”。Steward一詞與Owner相對應，說的是雖然資產不是歸Steward所有，但是他們替Owner代管，由此也衍生出Stewardship一詞，表明代管、託管制度，這裡面蘊含了一種兢兢業業、克己奉公的管家精神，何其難得！資料治理委員會、資料管理專員會制定出一系列資料相關的標準和制度，由資料管理服務組織（DMSO）去執行。從圖中可以看到，DMSO實際上是資訊化建設團隊，他們負責資料倉儲、資料整合等技術平臺建設。

上面談的是理論和國外，在國內的情況剛好相反，DMSO是主力軍，因為大家普遍“重功能、輕資料，重技術、輕管理”，絕大部分企業是缺失左側的委員會等管理角色的。據我的經驗，國內大型銀行在這方面做得相對領先，企業級資料治理委員會或者專職的部門去推動資料治理；能源行業對資料治理的接觸和認同程度比較高，開展了不少資料治理專案，特別是在主資料管理方面。運營商更重視技術手段，資料治理體制機制有待建設、健全。整體而言，國內在企業層面成立資料治理委員會的不多，更多是將資料治理的工作放在“企業資訊化領導小組”推動，由資訊部門負責具體落實執行。而有些企業雖然資訊化水平很高，但資訊化建設未實現資訊部門的歸口管理，這對資料治理的推行帶來了極大挑戰，跨部門、跨系統的協同異常艱難。

陳新河：企業資料規劃非常象15年前企業資訊化的戰略規劃啊！15年前偏技術架構，目前偏業務架構吧！

2.2 治理/管控物件

這個部分主要是我個人實踐經驗的總結，可能和國外的一些理論不一樣。我個人總結為“內容管控”和“過程管控”。此處我用了管控一詞，體現一些管理的“力道”。

2.2.1 內容管控

先說內容管控，資料在資訊系統中是以不同形態體現的，需要將每種形態管理好，才有可能管好最終的資料質量。上一張圖來說明：

從宏觀到微觀，資料的形態體現為資料架構、資料標準和資料質量標準。

l 資料架構，包括了資料模型（概念模型、邏輯模型）以及資料的流轉關係，一般在企業級和系統級會談資料架構，主要對企業資料的分類、分佈和流轉進行規劃、設計，確保新建系統、新建應用能夠與現有系統保持一致和融合，避免產生資訊孤島，或者帶來重複不必要的資料整合、資料轉換。

l 資料標準，包括了資料項、參考資料、指標等不同形式的標準。舉例來說，“客戶型別”是一個資料項，應該有統一的業務含義，將客戶歸類為大客戶、一般客戶的規則是什麼，資料項的取值是幾位長度，有哪些有效值（如01，02，03）等。這方面有國際標準可以參考，如ISO11179，國內很多行業也制定了行業資料標準，如電子政務資料元、金融行業統計資料元等等。共同的問題是，標準定義出來之後，執行的情況怎麼樣？是否真正落實到IT系統了。

l 資料質量標準，包括資料質量規則以及稽核模型（即規則的組合應用）。資料質量規則一般會關注及時性、準確性、完整性、一致性、唯一性等，展開來談還有許多內容，有的專家整理出12個資料質量維度，有定性的也有定量的。

IT部門應該牽頭制定並且定期更新企業級的資料架構、資料標準和資料質量標準，作為新建系統和應用的指導約束。值得注意的是，在標準制定的過程中，要避免IT部門的閉門造車，一定要讓業務部門充分參與進來。舉一個例子，我個人作為技術人員參與一次資料架構的規劃，需要設計資料的流轉關係。我發現從技術角度看，資料從哪流向哪裡似乎都是合理的，也都可以有相應的工具去支撐，似乎沒有什麼可以決策的依據。其實，這時就應該有業務的參與，因為業務職能、業務流程和業務部門間的職能邊界劃分，直接決定了資料來源和去向，IT部門更多是從技術層面考慮具體實現方案。

2.2.2 過程管控

下面說過程管控。這裡談的過程，是指資訊系統建設過程。因為經過大量的實踐我們發現，資料質量不佳主要原因之一是在資訊系統建設的過程中忽視了對資料的管控，這就會造成資料的設計與需求不一致，開發與設計不一致，對資料質量要求考慮缺失，不同系統對資料的定義和技術實現不一致等等諸多問題。等待系統上線後再去解決這些問題，亡羊補牢，消耗資源。

其實，資料管理甚至IT行業都應該虛心向傳統行業學習管理理念。比如製造業的質量管理是在產品生產線各個環節進行質量管控，有些理念也很有啟發：QualityBy Design，質量是設計出來的，不是檢查出來的；Quality check is a cost not benefit，質量檢查是成本而非收益。我們公司最近完成了對工廠化的資料生產和管理模式的探索和初步實踐，執行效率、開發維護效率和資料質量都有顯著提升，找機會再分享，提供一張效果圖有些感性認識。

下面是過程管控的示意圖：

這張圖的內容比較豐富，其核心內容是將“內容管控”中形成的各項標準規範注入到透過資訊系統建設的生命週期中，透過對系統建設各個階段交付物的管控確保標準規範得到遵從，從而保障資料的標準化和規範化。過程管控一方面依靠開發管理中的評審機制去落實，另一方面就是靠工具去固化一些標準和規範，做到自動化檢查。在系統上線常態執行階段，注重新的資料需求和資料問題的收集和處理，對標準規範進行最佳化。在資訊化早期階段ERP、CRM等操作型系統的建設是以功能和流程為中心，而後期BI、資料倉儲、大資料平臺等資料分析平臺的建設是以資料為中心的，這就註定一些傳統方式需要改變，應該更加註重對資料架構、資料標準、資料質量的管控，更加關注資料的生命週期，否則資料分析平臺建設成功的機率不高。

2.2.3 技術工具

下面簡單談談技術工具。先上一張圖，這是國外對資料治理關鍵技術的調研結論。

可以看到後設資料、主資料、資料質量是主要的技術手段。具體的產品功能不是今天要探討的話題，我主要想談一談技術工具在資料治理工作中的定位。與ERP遇到的情況非常類似，國內的客戶往往寄望於上一套技術工具就能包治百病的解決資料問題、提升資料質量。

而實際情況是，如果前面所說的組織架構、內容管控、過程管控等管理機制、技術標準不到位，僅僅上一套軟體工具，起不到任何效果。以上軟體工具的作用又是什麼呢？核心作用在於知識的固化和提高資料治理人員的工作效率。比如：需要手工編寫程式收集的後設資料，工具幫你自動獲取；需要人工識別或編寫程式碼實現的資料質量檢查，工具幫你自動識別問題；用文件管理的資料字典，工具幫你線上管理；基於郵件和線下的流程，工具幫你線上自動化。除此之外，資料治理的軟體工具與其他軟體工具一樣，沒有什麼神奇之處，沒有資料治理人員的參與和資料治理工作的推進，軟體也只是看上去很美。這也是為什麼資料治理諮詢服務一直有其市場，以及為什麼國內大部分單純資料治理軟體專案未能達到預期目標。

3. 資料治理的實踐

今天分享的形式決定不能展開許多細節，以三個案例中的一些細節來幫助大家對資料治理的實操有些定性的認識。這個部分沒有圖片，需要辛苦大家從字裡行間去體會。

第一個案例是運營商客戶的系統級資料治理，主要的啟示在於：組織架構對於推動資料治理的重要性。

運營商資料倉儲建設已有多年，對後設資料管理和資料質量管理一直高度重視。資料質量問題往往是在資料倉儲發現的，而有很大比例問題是由於上游BOSS系統的升級或者資料錯誤傳遞到了資料倉儲。例如，推出了新產品但資料倉儲中尚未註冊、SIM卡號位數升級但未通知資料倉儲等等。這說明兩個問題：業務人員與分析系統技術人員協同不夠；業務系統與分析系統協同不夠。因此，資料倉儲的主管方嘗試從集團推動BOSS和資料倉儲的資料質量協同管理，透過幾省試點的方式建立了跨系統的後設資料血緣圖、資料質量聯動監控等一系列技術手段去解決問題。

但是，資料質量協同管理的工作終於試點、未能全國推廣實施，其原因主要有三點：1. 組織上，BOSS系統和資料倉儲沒有實現歸口IT管理、是由平級的兩個處室管理；2. BOSS系統業務關鍵性高於資料倉儲；3.此工作作為技術工作發起，沒有去爭取業務部門的支援、參與甚至牽頭。由此可見，組織架構和管理機制不順暢，會制約資料問題的解決，甚至會帶來資料問題。

第二個案例是一個能源行業客戶企業級的資料治理，主要的啟示在於：資料治理既要大處著眼，更要小處著手，而且要善於找時機切入。

該客戶透過資訊化規劃設計了企業級資料架構，透過主資料管理專案經過1年時間建立了企業級的主資料標準、實現了不同業務部門對不同領域資料認責（即承擔資料管理專員的角色），又透過資料管控專案理順了業務部門、資訊化部門在資料管控工作上的職責，在專案管理辦公室PMO設定了資料管控組對各專案資料統一管控，同時制定了制度、流程和技術標準。組織、制度和標準上都可謂是到位的，但是技術標準的落地工作一直不順利。

舉例來說，以ERP為首的套裝軟體實施團隊對組織機構主資料的標準一直很牴觸，不肯使用8位統一編碼而是使用本地4位編碼。這個問題的影響在只有ERP系統時並不明顯，資料管控組也無法推動8位編碼的應用。隨著專案後期非套裝軟體的建設，系統間的整合需求豐富起來，如果不能統一編碼標準，系統間無法整合。這時，非ERP系統都遵從標準使用統一8位編碼，ERP專案組不得不讓步，透過對映表的方式實現了4位與8位的編碼對映，確保順利整合。由此可見，組織架構、管理機制和技術標準建立好之後，其推行落地需要找時機，也需要資料治理人員的耐心和智慧，否則只能是紙上談兵。

第三個案例是美國的一個案例，主要的啟示在於：小處著手，可以非常非常小，這對國內客戶喜歡大而全的思路是非常有益的互補。

這個企業也是受困於資料質量問題，希望透過資料治理來解決。但開始時並不知道如何實際運算元據治理，所以他們啟動了一個“企業資料定義”的專案：用6個月的時間梳理現有系統的資料項，識別跨系統、跨業務的資料項作為資料治理的重點。資料項梳理完畢後，他們選擇了7個資料項去重點治理。注意，只有7個資料項哦！國內客戶一定會認為7個太少，不能當個事情來做。但美國這個企業就是圍繞這7個資料項去調研相關的業務使用者，發現他們的資料使用需求和問題，去分析與這些資料項相關的業務流程和資料流程。後來識別了40多項可以改進的內容，也為資料治理的全面開展積累經驗，在此基礎上制定了總體規劃和實施路線。

這個案例我最大的體會是，行動遠比規模重要，在非常小的區域性快速見效、積累經驗，再開展企業級的資料治理實施，可能比直接高舉高打來的更為有效。

4. 大資料與資料治理

終於談到了大資料。從前面的討論來看，資料治理大的脈絡並不複雜：對資料資產家底清晰、管理權責分明、建立配套標準規範、確保落地執行，由此去保障資料質量。雖然大資料的規模大、型別多、速度快，但資料治理的原則對於大資料也是同樣適用的。

那麼大資料的到來會給資料治理提出哪些新的要求呢？

我們首先來看《大資料時代》的作者的觀點之一，他認為在大資料時代資料質量不再重要，因為人們需要的是整體趨勢的分析而非精確結果。我個人不太同意此觀點，而是認為對大資料而言資料質量更加重要。作者提的整體趨勢分析僅僅是大資料的應用之一，而從精準營銷、風險識別等應用場景來看，因為資料與運營結合的更緊密、要求資料粒度更細，任何一點錯誤都可能直接帶來業務上的損失；而傳統的指標應用，反而對運營環節沒有如此直接的影響。因此，在大資料環境下對資料質量的需求是提升而非降低。

其次，Hadoop、Spark等大資料技術的應用，對資料治理的技術手段提出新的要求。傳統模式下基於RDBMS進行管理，SQL是通用的資料訪問方式。而在大資料環境中，Hadoop、MPP、RDBMS、Spark並存，如何在混搭的異構環境中實現對資料資產的視覺化統一管控，避免大資料系統成為不可管理的黑盒子，這是傳統行業應用大資料技術需要面對的關鍵問題之一。特別是大資料技術人才目前更多流向網際網路企業，進入傳統行業的少之又少，在人才可得性短期不能快速解決的情況下，需要依靠技術手段來確保傳統企業IT人員能夠對資料資產的可視、可控。

第三，資料安全，或者說資料隱私的重要性比以往有顯著提升，這也需要在資料治理中加強對資料安全的重視。在傳統應用場景中，資料由企業收集，在企業內部應用，資料所有權的問題並不突出。在大資料時代，資料要更多進行跨界整合、外部應用的商業模式創新，這其中就涉及到更多資料所有權、資料隱私的話題。使用者資訊究竟屬於企業還是使用者、在什麼條件下企業可以拿來用於商業應用？這些問題的答案還在探討當中，毋庸置疑的是，企業需要在資料治理過程中，需要更加註意資料安全、資料隱私相關的制度和政策。

先談以上三點，有關大資料與資料治理的話題，估計2-3年內還會是持續豐富的，現在剛剛開始，我個人也是最近逐漸關注針對大資料的資料治理，很願意與大家共同交流進步。

5. 書籍推薦

最後給大家推薦幾本資料治理相關的書，茶餘飯後可以換換思路。

中文版的目前有三本：

1. 《DAMA資料管理知識體系指南》，此書是國際資料管理協會（DAMA）出版，2012年我們中國分會的一些會員眾包翻譯完成，目前應該是資料管理領域最全面的一本專著了，非常適合提綱挈領的全面瞭解資料管理各項工作。

2. 《資料質量工程實踐：獲取高質量資料和可信資訊的十大步驟》，作者是美國一位專家，我聽過她的講座，很務實，實操性比較強。國內有可能會覺得此書太細，但其實資料工作就是個細緻的工作。剛才講的那個美國案例，也是這位專家負責的。

3. 高復先老師的《資訊資源規劃：資訊化建設基礎工程》，對資料元素、資料標準等基礎概念闡述很清晰，此書是在James Martin的資訊工程基礎上寫成的，因此與國外的資料管理理論有比較好的相容性。

再推薦幾本英文的：

4. “Information Quality Applied: BestPractices for Improving Business Information, Processes and Systems”

5. “Data Warehouse and BusinessInformation Quality”

4與5這兩本書作者都是Larry English，應該是美國最資深的資料質量專家之一，剛才那本書的作者也是他的弟子。Larry成功的將製造業質量管理理念引入資料質量管理。這兩本書非常有參考價值，內容稍有重複，可以選第1本，是2009年出版的。

6. “Big Data Governance: an Emerging Imperative”

7. “The IBM Data Governance Unified Process: Driving Business Value withIBM Software and Best Practices”。

6與7這兩本書的作者都是 Sunil Soares，原來是IBM負責資料治理的lead，前兩年離開自己創業做公司了。第1本我還沒看過，第2本主要是結合IBM的軟體產品一起講的，不夠中立，權當參考。

以上就是我今天要分享的內容了，如果有興趣可以加我微信保持溝通。謝謝大家！

何鴻凌：模型驅動很贊。資料工廠的實踐有進一步分享麼？

劉晨：既然問到資料工廠，我就多介紹一點。目前國內客戶做後設資料管理和資料質量管理的不少，思路也比較趨同，首先是希望單憑工具解決問題，其次是基本上是在資料生產的事後進行資料管理，兩者脫節。這會帶來一系列的問題，資料生產與資料管理脫節，更嚴重的是資料管理根本沒法影響資料生產，因為想著手做資料管理的時候，資料已經生成了！然後是，很多資料生產的處理邏輯使用儲存過程和指令碼去寫的，形成一個個任務，而將資料資產淹沒在任務當中。這就是資料資產、資料流淹沒在任務流中，本來你要管理的是資料，可看到的都是一個個程式和任務，管理失焦！所以，現在的模式下，在技術層面都很難將資料管理好，更不用提管理機制、組織架構不到位。

所以，我們是借鑑了製造業的工廠和流水生產線的思路：面向資料資產去構建模型，這樣保證了資料定義的規範性。而且資料定義（也就是後設資料），是在系統開發過程中定義的，也就避免了事後管理帶來的問題。模型定義完成後，再根據資料處理邏輯構建一條條資料流，也就是資料生產線。剛才有一張圖的效果。

這個資料生產線會遮蔽掉底層的異構環境，無論是hadoop，db2，oracle，從資料開發和管理的角度來看，都體現為統一的資料生產線。這樣就會給開發人員、運維人員、甲方的管理人員帶來極大好處：資料資產可視了，也就更可控了。

黃明峰：很精彩！請教一下，政務的資料治理有突破嗎？您怎麼看待後設資料？原來國信辦主導的資料共享和交換體系有實際的價值嗎？

劉晨：政務領域我接觸的不多，接觸過一些稅務的合作伙伴。從我的感覺，他們還是沿用老的資料治理思路去做事情，後設資料，資料質量。稅務也制定過資料元標準，開發商反映落地情況不太好。對遺留系統的梳理有難度。

Felix：劉總剛才講到：Hadoop、MPP、RDBMS、Spark並存，如何在混搭的異構環境中實現對資料資產的視覺化統一管控，避免大資料系統成為不可管理的黑盒子，有什麼解決方案？

劉晨：請您參考我剛才說的工廠化資料生產和管理的模式。

趙剛：Apache開源專案中對資料治理的工具還不多。你瞭解呢？

劉晨：有，確實不多。ApacheFalcon是一個，還在incubator階段。

Felix：hadoop和spark，mpp都支援ganglia監控，也能算一種方案？

劉晨：是對hadoop環境下的資料進行模型化和流程的管理。

黃明峰：想繼續聽一下您對稅務系統資料看法。

劉晨：稅務這塊我目前還沒有更深的接觸。但我認為梳理遺留系統的工作量是必須的。但如果不能在資訊系統開發過程中做好事前和事中的資料管控，還會重走老路。

趙剛：informatica產品你怎麼評價？

劉晨：informatica和ibm datastage，sap bo DI都是一個思路。從ETL衍生出獨立的後設資料管理，資料質量管理，業務術語管理。但問題都類似：後設資料管理是事後的；資料質量管理分為data profiling和data cleansing，都是與ETL離線來做。可國內的資料清洗，習慣在ETL過程中去做。業務術語管理更是看上去很美，本質上與EXCEL沒什麼差別，推行的難度在於業務術語是IT人員不懂、業務人員不願填。從ETL功能本身，那幾個產品還是不錯的。但目前也不能適應國內運營商的要求；一方面國內運營商資料量大，產品效能跟不上；另一方面開放性不夠，不能做二次開發。所以運營商的ETL更多是ELT的方式，用指令碼去處理資料，利用資料倉儲的處理能力去做資料轉換。從效能和資料處理角度，這樣的方案沒問題，但日積月累，指令碼淹沒了資料處理邏輯，資料管理就失控了。於是開始做後設資料管理、資料質量管理，使用剛才說的事後管控的思路，效果不佳。我們見有的客戶，一個指令碼15000行。這裡面處理了多少張表、有多少處理邏輯，沒人能說清。開發商技術人員更替又比較頻繁，最後那個指令碼就沒人敢動了。所以，現在我們特別建議在大資料平臺、資料倉儲建設之初，能夠系統的考慮資料治理的問題，少走彎路。在專案開發流程、開發文件中，一定要加強對資料的要求。包括對資料需求的定義、資料模型、介面定義、整合關係、質量要求等等。這個內容在很多企業的專案管理流程中都是缺失的。

------------------

資料倉儲的基本概念

資料倉儲概念

英文名稱為Data Warehouse，可簡寫為DW或DWH。資料倉儲的目的是構建面向分析的整合化資料環境，為企業提供決策支援（Decision Support）。它出於分析性報告和決策支援目的而建立。

資料倉儲本身並不“生產”任何資料，同時自身也不需要“消費”任何的資料，資料來源於外部，並且開放給外部應用，這也是為什麼叫“倉庫”，而不叫“工廠”的原因。

基本特徵:

資料倉儲是面向主題的、整合的、非易失的和時變的資料集合，用以支援管理決策。

面向主題:       
    傳統資料庫中，最大的特點是面向應用進行資料的組織，各個業務系統可能是相互分離的。而資料倉儲則是面向主題的。主題是一個抽象的概念，是較高層次上企業資訊系統中的資料綜合、歸類並進行分析利用的抽象。在邏輯意義上，它是對應企業中某一宏觀分析領域所涉及的分析物件。

整合性:        
    透過對分散、獨立、異構的資料庫資料進行抽取、清理、轉換和彙總便得到了資料倉儲的資料，這樣保證了資料倉儲內的資料關於整個企業的一致性。
    資料倉儲中的綜合資料不能從原有的資料庫系統直接得到。因此在資料進入資料倉儲之前，必然要經過統一與綜合，這一步是資料倉儲建設中最關鍵、最複雜的一步，所要完成的工作有：
    要統一源資料中所有矛盾之處，如欄位的同名異義、異名同義、單位不統一、字長不一致，等等。
    進行資料綜合和計算。資料倉儲中的資料綜合工作可以在從原有資料庫抽取資料時生成，但許多是在資料倉儲內部生成的，即進入資料倉儲以後進行綜合生成的。

下圖說明一個保險公司綜合資料的簡單處理過程，其中資料倉儲中與“保險” 主題有關的資料來自於多個不同的操作型系統。這些系統內部資料的命名可能不同，資料格式也可能不同。把不同來源的資料儲存到資料倉儲之前，需要去除這些不一致。

複製

非易失性（不可更新性）      
    資料倉儲的資料反映的是一段相當長的時間內歷史資料的內容，是不同時點的資料庫快照的集合，以及基於這些快照進行統計、綜合和重組的匯出資料。
    資料非易失性主要是針對應用而言。資料倉儲的使用者對資料的操作大多是資料查詢或比較複雜的挖掘，一旦資料進入資料倉儲以後，一般情況下被較長時間保留。資料倉儲中一般有大量的查詢操作，但修改和刪除操作很少。因此，資料經加工和整合進入資料倉儲後是極少更新的，通常只需要定期的載入和更新。

時變性        
    資料倉儲包含各種粒度的歷史資料。資料倉儲中的資料可能與某個特定日期、星期、月份、季度或者年份有關。資料倉儲的目的是透過分析企業過去一段時間業務的經營狀況，挖掘其中隱藏的模式。雖然資料倉儲的使用者不能修改資料，但並不是說資料倉儲的資料是永遠不變的。分析的結果只能反映過去的情況，當業務變化後，挖掘出的模式會失去時效性。因此資料倉儲的資料需要更新，以適應決策的需要。從這個角度講，資料倉儲建設是一個專案，更是一個過程。資料倉儲的資料隨時間的變化表現在以下幾個方面：
（1） 資料倉儲的資料時限一般要遠遠長於操作型資料的資料時限。
（2） 操作型系統儲存的是當前資料，而資料倉儲中的資料是歷史資料。
（3） 資料倉儲中的資料是按照時間順序追加的，它們都帶有時間屬性。

複製

資料倉儲與資料庫的區別

資料庫與資料倉儲的區別實際講的是 OLTP 與 OLAP 的區別。

操作型處理，叫聯機事務處理 OLTP（On-Line Transaction Processing，），也可以稱面向交易的處理系統，它是針對具體業務在資料庫聯機的日常操作，通常對少數記錄進行查詢、修改。使用者較為關心操作的響應時間、資料的安全性、完整性和併發支援的使用者數等問題。傳統的資料庫系統作為資料管理的主要手段，主要用於操作型處理，像Mysql，Oracle等關係型資料庫一般屬於OLTP。

分析型處理，叫聯機分析處理 OLAP（On-Line Analytical Processing）一般針對某些主題的歷史資料進行分析，支援管理決策。

首先要明白，資料倉儲的出現，並不是要取代資料庫。資料庫是面向事務的設計，資料倉儲是面向主題設計的。資料庫一般儲存業務資料，資料倉儲儲存的一般是歷史資料。

資料庫設計是儘量避免冗餘，一般針對某一業務應用進行設計，比如一張簡單的User表，記錄使用者名稱、密碼等簡單資料即可，符合業務應用，但是不符合分析。資料倉儲在設計是有意引入冗餘，依照分析需求，分析維度、分析指標進行設計。

資料庫是為捕獲資料而設計，資料倉儲是為分析資料而設計。

以銀行業務為例。資料庫是事務系統的資料平臺，客戶在銀行做的每筆交易都會寫入資料庫，被記錄下來，這裡，可以簡單地理解為用資料庫記賬。資料倉儲是分析系統的資料平臺，它從事務系統獲取資料，並做彙總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月發生多少交易，該分行當前存款餘額是多少。如果存款又多，消費交易又多，那麼該地區就有必要設立ATM了。

顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求資料庫只能儲存很短一段時間的資料。而分析系統是事後的，它要提供關注時間段內所有的有效資料。這些資料是海量的，彙總計算起來也要慢一些，但是，只要能夠提供有效的分析資料就達到目的了。

複製

資料倉儲，是在資料庫已經大量存在的情況下，為了進一步挖掘資料資源、為了決策需要而產生的，它決不是所謂的“大型資料庫”。

資料倉儲分層架構

按照資料流入流出的過程，資料倉儲架構可分為：源資料、資料倉儲、資料應用

資料倉儲

資料倉儲的資料來源於不同的源資料，並提供多樣的資料應用，資料自下而上流入資料倉儲後向上層開放應用，而資料倉儲只是中間整合化資料管理的一個平臺。

源資料：此層資料無任何更改，直接沿用外圍系統資料結構和資料，不對外開放；為臨時儲存層，是介面資料的臨時儲存區域，為後一步的資料處理做準備。

資料倉儲：也稱為細節層，DW層的資料應該是一致的、準確的、乾淨的資料，即對源系統資料進行了清洗（去除了雜質）後的資料。

資料應用：前端應用直接讀取的資料來源；根據報表、專題分析需求而計算生成的資料。

資料倉儲從各資料來源獲取資料及在資料倉儲內的資料轉換和流動都可以認為是ETL（抽取Extra, 轉化Transfer, 裝載Load）的過程，ETL是資料倉儲的流水線，也可以認為是資料倉儲的血液，它維繫著資料倉儲中資料的新陳代謝，而資料倉儲日常的管理和維護工作的大部分精力就是保持ETL的正常和穩定。

那麼為什麼要資料倉儲進行分層呢?

用空間換時間，透過大量的預處理來提升應用系統的使用者體驗（效率），因此資料倉儲會存在大量冗餘的資料；不分層的話，如果源業務系統的業務規則發生變化將會影響整個資料清洗過程，工作量巨大。

透過資料分層管理可以簡化資料清洗的過程，因為把原來一步的工作分到了多個步驟去完成，相當於把一個複雜的工作拆成了多個簡單的工作，把一個大的黑盒變成了一個白盒，每一層的處理邏輯都相對簡單和容易理解，這樣我們比較容易保證每一個步驟的正確性，當資料發生錯誤的時候，往往我們只需要區域性調整某個步驟即可。

複製

資料倉儲後設資料的管理

後設資料（Meta Date），主要記錄資料倉儲中模型的定義、各層級間的對映關係、監控資料倉儲的資料狀態及ETL的任務執行狀態。一般會透過後設資料資料庫（Metadata Repository）來統一地儲存和管理後設資料，其主要目的是使資料倉儲的設計、部署、操作和管理能達成協同和一致。

後設資料是資料倉儲管理系統的重要組成部分，後設資料管理是企業級資料倉儲中的關鍵元件，貫穿資料倉儲構建的整個過程，直接影響著資料倉儲的構建、使用和維護。

構建資料倉儲的主要步驟之一是ETL。這時後設資料將發揮重要的作用，它定義了源資料系統到資料倉儲的對映、資料轉換的規則、資料倉儲的邏輯結構、資料更新的規則、資料匯入歷史記錄以及裝載週期等相關內容。資料抽取和轉換的專家以及資料倉儲管理員正是透過後設資料高效地構建資料倉儲。

使用者在使用資料倉儲時，透過後設資料訪問資料，明確資料項的含義以及定製報表。

資料倉儲的規模及其複雜性離不開正確的後設資料管理，包括增加或移除外部資料來源，改變資料清洗方法，控制出錯的查詢以及安排備份等。

複製

後設資料可分為技術後設資料和業務後設資料。技術後設資料為開發和管理資料倉儲的IT 人員使用，它描述了與資料倉儲開發、管理和維護相關的資料，包括資料來源資訊、資料轉換描述、資料倉儲模型、資料清洗與更新規則、資料對映和訪問許可權等。而業務後設資料為管理層和業務分析人員服務，從業務角度描述資料，包括商務術語、資料倉儲中有什麼資料、資料的位置和資料的可用性等，幫助業務人員更好地理解資料倉儲中哪些資料是可用的以及如何使用。

由上可見，後設資料不僅定義了資料倉儲中資料的模式、來源、抽取和轉換規則等，而且是整個資料倉儲系統執行的基礎，後設資料把資料倉儲系統中各個鬆散的元件聯絡起來，組成了一個有機的整體。

數倉建模方法

資料倉儲的建模方法有很多種，每一種建模方法代表了哲學上的一個觀點，代表了一種歸納、概括世界的一種方法。常見的有正規化建模法、維度建模法、實體建模法等，每種方法從本質上將是從不同的角度看待業務中的問題。

1. 正規化建模法（Third Normal Form，3NF）

正規化建模法其實是我們在構建資料模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關係型資料庫的資料儲存，利用的一種技術層面上的方法。目前，我們在關係型資料庫中的建模方法，大部分採用的是三正規化建模法。

正規化 是符合某一種級別的關係模式的集合。構造資料庫必須遵循一定的規則，而在關係型資料庫中這種規則就是正規化，這一過程也被稱為規範化。目前關聯式資料庫有六種正規化：第一正規化（1NF）、第二正規化（2NF）、第三正規化（3NF）、Boyce-Codd正規化（BCNF）、第四正規化（4NF）和第五正規化（5NF）。

在資料倉儲的模型設計中，一般採用第三正規化。一個符合第三正規化的關係必須具有以下三個條件 :

每個屬性值唯一，不具有多義性 ;

每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分 ;

每個非主屬性不能依賴於其他關係中的屬性，因為這樣的話，這種屬性應該歸到其他關係中去。

複製

正規化建模

根據 Inmon 的觀點，資料倉儲模型的建設方法和業務系統的企業資料模型類似。在業務系統中，企業資料模型決定了資料的來源，而企業資料模型也分為兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關係型資料庫上的例項化。

複製

2. 維度建模法（Dimensional Modeling）

維度模型是資料倉儲領域另一位大師Ralph Kimall所倡導，他的《資料倉儲工具箱》是資料倉儲工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決使用者如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應效能。

維度建模

典型的代表是我們比較熟知的星形模型（Star-schema），以及在一些特殊場景下適用的雪花模型（Snow-schema）。

維度建模中比較重要的概念就是 事實表（Fact table）和維度表（Dimension table）。其最簡單的描述就是，按照事實表、維度表來構建資料倉儲、資料集市。

目前在網際網路公司最常用的建模方法就是維度建模，稍後將重點講解

3. 實體建模法（Entity Modeling）

實體建模法並不是資料倉儲建模中常見的一個方法，它來源於哲學的一個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關係組成。那麼我們在資料倉儲的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的關係，以及針對這些關係的說明就是我們資料建模需要做的工作。

雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何一個業務過程劃分成 3 個部分，實體，事件，說明，如下圖所示：

實體建模

上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學校”看成是一個實體，“上學”描述的是一個業務過程，我們在這裡可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。

複製

維度建模

維度建模是專門應用於分析型資料庫、資料倉儲、資料集市建模的方法。資料集市可以理解為是一種"小型資料倉儲"。

1. 維度建模中表的型別

事實表

事實表表示對分析主題的度量。比如一次購買行為我們就可以理解為是一個事實。

事實與維度

圖中的訂單表就是一個事實表，你可以理解他就是在現實中發生的一次操作型事件，我們每完成一個訂單，就會在訂單中增加一條記錄。事實表的特徵：表裡沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。事實表包含了與各維度表相關聯的外來鍵，可與維度表關聯。事實表的度量通常是數值型別，且記錄數會不斷增加，表資料規模迅速增長。

明細表（寬表）：

事實表的資料中，有些屬性共同組成了一個欄位（糅合在一起），比如年月日時分秒構成了時間,當需要根據某一屬性進行分組統計的時候，需要擷取拼接之類的操作，效率極低。如：

複製

為了分析方便，可以事實表中的一個欄位切割提取多個屬性出來構成新的欄位，因為欄位變多了，所以稱為寬表，原來的成為窄表。

將上述的local_time欄位擴充套件為如下6個欄位：

又因為寬表的資訊更加清晰明細，所以也可以稱之為明細表。

2．維度表

每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外來鍵，當然，維度錶行的描述環境應與事實錶行完全對應。維度表通常比較寬，是扁平型非規範表，包含大量的低粒度的文字屬性。

維度表示你要對資料進行分析時所用的一個量，比如你要分析產品銷售情況， 你可以選擇按類別來進行分析，或按區域來分析。每個類別就構成一個維度。上圖中的使用者表、商家表、時間表這些都屬於維度表，這些表都有一個唯一的主鍵，然後在表中存放了詳細的資料資訊。

總的說來，在資料倉儲中不需要嚴格遵守規範化設計原則。因為資料倉儲的主導功能就是面向分析，以查詢為主，不涉及資料更新操作。事實表的設計是以能夠正確記錄歷史資訊為準則，維度表的設計是以能夠以合適的角度來聚合主題內容為準則。

2. 維度建模三種模式

星型模式

雪花模式

3．星座模式

星座模式是星型模式延伸而來，星型模式是基於一張事實表的，而星座模式是基於多張事實表的，而且共享維度資訊。前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。

複製

3. 維度建模過程

我們知道維度建模的表型別有事實表，維度表；模式有星形模型，雪花模型，星座模型這些概念了，但是實際業務中，給了我們一堆資料，我們怎麼拿這些資料進行數倉建設呢，數倉工具箱作者根據自身60多年的實際業務經驗，給我們總結了如下四步，請務必記住！

數倉工具箱中的維度建模四步走：

維度建模四步走

請牢記以上四步，不管什麼業務，就按照這個步驟來，順序不要搞亂，因為這四步是環環相扣，步步相連。下面詳細拆解下每個步驟怎麼做

1、選擇業務過程

維度建模是緊貼業務的，所以必須以業務為根基進行建模，那麼選擇業務過程，顧名思義就是在整個業務流程中選取我們需要建模的業務，根據運營提供的需求及日後的易擴充套件性等進行選擇業務。比如商城，整個商城流程分為商家端，使用者端，平臺端，運營需求是總訂單量，訂單人數，及使用者的購買情況等，我們選擇業務過程就選擇使用者端的資料，商家及平臺端暫不考慮。業務選擇非常重要，因為後面所有的步驟都是基於此業務資料展開的。

複製

2、宣告粒度

先舉個例子：對於使用者來說，一個使用者有一個身份證號，一個戶籍地址，多個手機號，多張銀行卡，那麼與使用者粒度相同的粒度屬性有身份證粒度，戶籍地址粒度，比使用者粒度更細的粒度有手機號粒度，銀行卡粒度，存在一對一的關係就是相同粒度。為什麼要提相同粒度呢，因為維度建模中要求我們，在同一事實表中，必須具有相同的粒度，同一事實表中不要混用多種不同的粒度，不同的粒度資料建立不同的事實表。並且從給定的業務過程獲取資料時，強烈建議從關注原子粒度開始設計，也就是從最細粒度開始，因為原子粒度能夠承受無法預期的使用者查詢。但是上卷彙總粒度對查詢效能的提升很重要的，所以對於有明確需求的資料，我們建立針對需求的上卷彙總粒度，對需求不明朗的資料我們建立原子粒度。

複製

3、確認維度

維度表是作為業務分析的入口和描述性標識，所以也被稱為資料倉儲的“靈魂”。在一堆的資料中怎麼確認哪些是維度屬性呢，如果該列是對具體值的描述，是一個文字或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性，數倉工具箱中告訴我們牢牢掌握事實表的粒度，就能將所有可能存在的維度區分開，並且要確保維度表中不能出現重複資料，應使維度主鍵唯一

複製

4、確認事實

事實表是用來度量的，基本上都以數量值表示，事實表中的每行對應一個度量，每行中的資料是一個特定級別的細節資料，稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重複計算度量的問題。有時候往往不能確定該列資料是事實屬性還是維度屬性。記住最實用的事實就是數值型別和可加類事實。所以可以透過分析該列是否是一種包含多個值並作為計算的參與者的度量，這種情況下該列往往是事實。

複製

實際業務中數倉分層

數倉分層要結合公司業務進行，並且需要清晰明確各層職責，要保證資料層的穩定又要遮蔽對下游影響，一般採用如下分層結構：

資料分層架構

資料層具體實現

使用四張圖說明每層的具體實現

複製

資料來源層ODS

資料來源層 資料來源層主要將各個業務資料匯入到大資料平臺，作為業務資料的快照儲存。

資料明細層DW

資料明細層

事實表中的每行對應一個度量，每行中的資料是一個特定級別的細節資料，稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重複計算度量的問題。

維度表一般都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重複資料，否則和事實表關聯會出現資料發散問題。

有時候往往不能確定該列資料是事實屬性還是維度屬性。記住最實用的事實就是數值型別和可加類事實。所以可以透過分析該列是否是一種包含多個值並作為計算的參與者的度量，這種情況下該列往往是事實；如果該列是對具體值的描述，是一個文字或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性。但是還是要結合業務進行最終判斷是維度還是事實。

資料輕度彙總層DM

資料輕度彙總層

此層命名為輕彙總層，就代表這一層已經開始對資料進行彙總，但是不是完全彙總，只是對相同粒度的資料進行關聯彙總，不同粒度但是有關係的資料也可進行彙總，此時需要將粒度透過聚合等操作進行統一。

資料應用層APP

資料應用層

資料應用層的表就是提供給使用者使用的，數倉建設到此就接近尾聲了，接下來就根據不同的需求進行不同的取數，如直接進行報表展示，或提供給資料分析的同事所需的資料，或其他的業務支撐。

最後

技術是為業務服務的，業務是為公司創造價值的，離開業務的技術是無意義的。所以數倉的建設與業務是息息相關的，公司的業務不同，數倉的建設也是不同的，只有適合的才是最好的。

指標體系

指標體系是什麼？如何使用OSM模型和AARRR模型搭建指標體系？如何統一流程、規範化、工具化管理指標體系？本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。

什麼是指標體系

1. 指標體系定義

指標體系是將零散單點的具有相互聯絡的指標，系統化的組織起來，透過單點看全域性，透過全域性解決單點的問題。它主要由指標和體系兩部分組成。

指標是指將業務單元細分後量化的度量值，它使得業務目標可描述、可度量、可拆解，它是業務和資料的結合，是統計的基礎，也是量化效果的重要依據。

指標主要分為結果型和過程型：

• 結果型指標：用於衡量使用者發生某個動作後所產生的結果，通常是延後知道的，很難進行干預。結果型指標更多的是監控資料異常，或者是監控某個場景下使用者需求是否被滿足
• 過程型指標：使用者在做某個動作時候所產生的指標，可以透過某些運營策略來影響這個過程指標，從而影響最終的結果，過程型指標更加關注使用者的需求為什麼被滿足或沒被滿足

體系是由不同的維度組成，而維度是指使用者觀察、思考與表述某事物的“思維角度”，維度是指標體系的核心，沒有維度，單純說指標是沒有任何意義的。

維度主要分為定性維度和定量維度，定性維度，主要是偏文字描述類如城市、性別、職業等;定量維度，主要是數值類描述如收入、年齡等，對定量維度需要做數值分組處理。

2. 指標體系生命週期

生命週期主要包含定義、生產、消費、下線四個階段。針對整個生命週期要持續做指標運維、質量保障，同時為了提高指標資料複用度，降低使用者使用成本需要做對應的資料運營工作。

3. 綜合使用場景

指標體系主要是結合使用者的業務場景來進行使用，多個不同的指標和維度可以組合起來進行業務的綜合分析，使用者可透過指標的變化看到整體業務的變化，並能夠快速發現問題、定位問題。常用的場景一種是決策分析的場景，透過資料看清業務現狀進行戰略決策支援；另一種是運營分析場景，無論是做使用者運營、產品運營還是活動運營都需要各類指標資料的支撐去看清問題、分析問題和指導解決問題。

為什麼搭建指標體系

1. 衡量業務發展質量

指標體系可以反映業務客觀事實，看清業務發展現狀，透過指標對業務質量進行衡量，把控業務發展情況，針對發現的業務問題聚焦解決，促進業務有序增長

2. 建立指標因果關係

主要明確結果型指標和過程型指標關係，透過結果指標回溯過程指標，找到解決問題的核心原因

3. 指導使用者分析工作

目的建立產品評估體系、活動效果評估體系、智慧運營分析體系

4. 指導基礎資料建設

明確基礎資料建設方向，集中資源，避免過程和結果分析指標資料的遺漏或缺失

5. 指導內容產品建設

結合使用者的業務場景來進行使用，多個不同的指標和維度可以組合起來進行業務的綜合分析，使用者可透過指標的變化看到整體業務的變化，並能夠快速發現問題、定位問題

6. 統一指標消費口徑

企業內統一關鍵指標業務口徑及計算口徑，統一企業業務目標，實現自上而下目標驅動

如何搭建指標體系

指標體系建設的常用方法是透過場景化進行指標體系的搭建，以使用者的視角場景化思考，自上而下業務驅動指標體系建設，所以要在特定場景下做好指標體系建設，需要先選好指標，然後用科學的方法搭建指標體系。

1. 科學方法選指標

選指標常用方法是指標分級方法和OSM模型。

指標分級主要是指標內容縱向的思考，根據企業戰略目標、組織及業務過程進行自上而下的指標分級，對指標進行層層剖析，主要分為三級T1、T2、T3。

• T1指標：公司戰略層面指標

用於衡量公司整體目標達成情況的指標，主要是決策類指標，T1指標使用通常服務於公司戰略決策層

• T2指標：業務策略層面指標

為達成T1指標的目標，公司會對目標拆解到業務線或事業群，並有針對性做出一系列運營策略，T2指標通常反映的是策略結果屬於支援性指標同時也是業務線或事業群的核心指標。T2指標是T1指標的縱向的路徑拆解，便於T1指標的問題定位，T2指標使用通常服務業務線或事業群

• T3指標：業務執行層面指標

T3指標是對T2指標的拆解，用於定位T2指標的問題。T3指標通常也是業務過程中最多的指標。根據各職能部門目標的不同，其關注的指標也各有差異。T3指標的使用通常可以指導一線運營或分析人員開展工作，內容偏過程性指標，可以快速引導一線人員做出相應的動作。

例如：成交率的指標分級

OSM模型（Obejective，Strategy，Measurement）是指標體系建設過程中輔助確定核心的重要方法，包含業務目標、業務策略、業務度量，是指標內容橫向的思考。

• O

使用者使用產品的目標是什麼？產品滿足了使用者的什麼需求？主要從使用者視角和業務視角確定目標，原則是切實可行、易理解、可干預、正向有益

• S

為了達成上述目標我採取的策略是什麼？

• M

這些策略隨之帶來的資料指標變化有哪些？

以滴滴網約車為例，按照OSM模型，它的指標是什麼樣的？

O：使用者來使用滴滴這個產品，需求和目標是什麼？

使用者需求及目標是便捷、快速打到車，安全到達目的地

那如何讓使用者感受到自己的需求被滿足了呢？

S：滴滴做的策略是：

便捷方面，提供了獨立APP版本、小程式版本，還可以多渠道打到車，例如在高德、微信、支付寶都有叫車入口；起始、目的地地圖智慧精準定位；最優路線選擇等

快速方面，針對不同人群不同訴求提供了多品類產品選擇，例如快車、優享、拼車、計程車等業務，根據早晚高峰提高熱點區域運力，減少使用者排隊時間

安全方面，司機准入機制，司機合規機制，司機畫像

M：我們需要針對這些策略去做指標，在這裡面我們的指標分別是結果指標和過程指標：

結果指標：渠道轉化完成率、乘客取消率、供需比、司機服務分

過程指標：渠道發單數、渠道完單數、排隊乘客數、乘客排隊時長、司機好評率、司機接單量、司機取消數等

指標選取之後，下面就是最重要的分析維度選擇了，前面指標體系定義裡講過維度是指標體系的核心，沒有維度，單純說指標是沒有任何意義的。所以維度選擇層面主要透過資料分析視角結合實際分析業務場景來確定。例如城市維度、商圈維度、渠道維度、時間維度、使用者標籤維度等。

複製

2. 用分析模型搭建指標體系

在《精益資料分析》一書中給出了兩套比較常用的指標體系建設方法論，其中一個就是比較有名的海盜指標法，也就是我們經常聽到的AARRR海盜模型。海盜模型是使用者分析的經典模型，它反映了增長是系統性地貫穿於使用者生命週期各個階段的：使用者拉新(Acquisition)、使用者啟用(Activation)、使用者留存(Retention)、商業變現(Revenue)、使用者推薦(Referral)。

AARRR模型

• A拉新

透過各種推廣渠道，以各種方式獲取目標使用者，並對各種營銷渠道的效果評估，不斷最佳化投入策略，降低獲客成本。涉及關鍵指標例如新增註冊使用者數、啟用率、註冊轉化率、新客留存率、下載量、安裝量等

• A活躍

活躍使用者指真正開始使用了產品提供的價值，我們需要掌握使用者的行為資料，監控產品健康程度。這個模組主要反映使用者進入產品的行為表現，是產品體驗的核心所在。涉及關鍵指標例如DAU/MAU 、日均使用時長、啟動APP時長、啟動APP次數等

• R留存

衡量使用者粘性和質量的指標。涉及關鍵指標例如留存率、流失率等

• R變現

主要用來衡量產品商業價值。涉及關鍵指標例如生命週期價值(LTV)、客單價、GMV等

• R推薦

衡量使用者自傳播程度和口碑情況。涉及關鍵指標例如邀請率、裂變係數等

可以根據實際業務場景，結合使用OSM和AARRR模型，來系統性的選擇不同階段所需要的核心資料指標。

3. 場景化搭建指標體系

目前階段網際網路業務比較流行的一種通用抽象場景“人、貨、場”，實際就是我們日常所說的使用者、產品、場景，在通俗點講就是誰在什麼場景下使用了什麼產品，不同的商業模式會有不同的組合模式。以滴滴實際場景為例：哪些場景（此處場景定義為終端，如Native，微信，支付寶）的什麼人（乘客）在平臺上使用了哪些貨（平臺業務線，如快車/專車等），進而為評估使用者增長的價值和效果。

• "人"的視角

從“人”的視角，我們比較關心的是什麼乘客在什麼時間打的車，排了多長時間，等了多長時間上車，週期內第幾次叫車，叫車花了多少錢，是否有投訴和取消行為，具體到資料指標主要看發單使用者數、完單使用者數、客單價、週期內完單訂單數、取消訂單數、評價訂單數等。

• "貨"的視角

從“貨”的視角，我們比較關心的就是成交了多少，交易額多少，花了多少，到具體資料指標主要會看GMV、成交率、取消率指標，在進一步會細分到城市、區域，一級品類、二級品類。資料的效果透過目標對比，橫向對比、歷史比較等方式進行分析確定。

• "場"的視角

從“場”的視角，我們比較關心的就是哪個渠道使用者點選量大曝光率大，帶來了多少新使用者，完成多少交易訂單，客單價是多少；或者是哪個活動拉新或促活效果怎麼樣轉化率多少，結合場景資料實際情況制定對應策略。

以上分別從“人”、“貨”、“場”三個角度進行了資料指標和分析維度的提煉，下面我們把三類指標結合指標分級方法進行分解關聯。

怎麼管理指標體系

1. 痛點分析

主要從業務、技術、產品三個視角來看：

• 業務視角

業務分析場景指標、維度不明確；

頻繁的需求變更和反覆迭代，資料包表臃腫，資料參差不齊；

使用者分析具體業務問題找資料、核對確認資料成本較高。

• 技術視角

指標定義，指標命名混亂，指標不唯一，指標維護口徑不一致；

指標生產，重複建設；資料彙算成本較高；

指標消費，資料出口不統一，重複輸出，輸出口徑不一致；

• 產品視角

缺乏系統產品化支援從生產到消費資料流沒有系統產品層面打通；

2. 管理目標

• 技術目標

統一指標和維度管理，指標命名、計算口徑、統計來源唯一， 維度定義規範、維度值一致

• 業務目標

統一資料出口、場景化覆蓋

• 產品目標

指標體系管理工具產品化落地；指標體系內容產品化落地支援決策、分析、運營例如決策北極星、智慧運營分析產品等

3. 模型架構

業務板塊定義原則：業務邏輯層面進行抽象、物理組織架構層面進行細分，可根據實際業務情況進行層級分拆細化，層級分級建議進行最多進行三級分拆，一級細分可公司層面統一規範確定，二級及後續拆分可根據業務線實際業務進行拆分。

例如滴滴出行領域業務邏輯層面兩輪車和四輪車都屬於出行領域可抽象出行業務板塊(level一級)，根據物理組織架構層面在進行細分普惠、網約車、計程車、順風車（level二級），後續根據實際業務需求可在細分,網約車可細分獨乘、合乘，普惠可細分單車、企業級。

規範定義

資料域

指面向業務分析，將業務過程或者維度進行抽象的集合。其中，業務過程可以概括為一個個不拆分的行為事件，在業務過程之下，可以定義指標；維度，是度量的環境，如乘客呼單事件，呼單型別是維度。為了保障整個體系的生命力，資料域是需要抽象提煉，並且長期維護更新的，變動需執行變更流程。

業務過程

指公司的業務活動事件，如呼單、支付都是業務過程。其中，業務過程不可拆分。

時間週期

用來明確統計的時間範圍或者時間點，如最近30天、自然周、截止當日等。

修飾型別

是對修飾詞的一種抽象劃分。修飾型別從屬於某個業務域，如日誌域的訪問終端型別涵蓋APP端、PC端等修飾詞。

修飾詞

指的是統計維度以外指標的業務場景限定抽象，修飾詞屬於一種修飾型別，如在日誌域的訪問終端型別下，有修飾詞APP、PC端等。

度量/原子指標

原子指標和度量含義相同，基於某一業務事件行為下的度量，是業務定義中不可再拆分的指標，具有明確業務含義的名稱，如支付金額。

維度

維度是度量的環境，用來反映業務的一類屬性，這類屬性的集合構成一個維度，也可以稱為實體物件。維度屬於一個資料域，如地理維度（其中包括國家、地區、省市等）、時間維度（其中包括年、季、月、周、日等級別內容）。

維度屬性

維度屬性隸屬於一個維度，如地理維度裡面的國家名稱、國家ID、省份名稱等都屬於維度屬性。

指標分類主要分為原子指標、派生指標、衍生指標

1. 原子指標

基於某一業務事件行為下的度量，是業務定義中不可再拆分的指標，具有明確業務含義的名稱，如呼單量、交易金額

1. 派生指標

是1個原子指標+多個修飾詞（可選）+時間週期，是原子指標業務統計範圍的圈定。派生指標又分以下二種型別：

1. 事務型指標

是指對業務過程進行衡量的指標。例如，呼單量、訂單支付金額，這類指標需要維護原子指標以及修飾詞，在此基礎上建立派生指標。

1. 存量型指標

是指對實體物件（如司機、乘客）某些狀態的統計，例如註冊司機總數、註冊乘客總數，這類指標需要維護原子指標以及修飾詞，在此基礎上建立派生指標，對應的時間週期一般為“歷史截止當前某個時間”。

1. 衍生指標

是在事務性指標和存量型指標的基礎上覆合成的。主要有比率型、比例型、統計型均值。

模型設計

主要採用維度建模方法進行構建，基礎業務明細事實表主要儲存維度屬性集合和度量/原子指標；分析業務彙總事實表按照指標類別(去重指標、非去重指標)分類儲存，非去重指標彙總事實表儲存統計維度集合、原子指標或派生指標，去重指標彙總事實表只儲存分析實體統計標籤集合。

指標體系在數倉物理實現層面主要是結合數倉模型分層架構進行指導建設，滴滴的指標資料主要儲存在DWM層，作為指標的核心管理層。

指標體系後設資料管理

維度管理

包括基礎資訊和技術資訊，由不同角色進行維護管理。

基礎資訊對應維度的業務資訊，由業務管理人員、資料產品或BI分析師維護，主要包括維度名稱、業務定義、業務分類。

技術資訊對應維度的資料資訊，由資料研發維護，主要包括是否有維表（是列舉維度還是有獨立的物理維表）、是否是日期維、對應code英文名稱和中文名稱、對應name英文名稱和中文名稱。如果維度有維度物理表，則需要和對應的維度物理表繫結，設定code和name對應的欄位。如果維度是列舉維，則需要填寫對應的code和name。維度的統一管理，有利於以後資料表的標準化，也便於使用者的查詢使用。

指標管理

包括基礎資訊、技術資訊和衍生資訊，由不同角色進行維護管理。

基礎資訊對應指標的業務資訊，由業務管理人員、資料產品或BI分析師維護，主要包括歸屬資訊(業務板塊、資料域、業務過程)，基本資訊(指標名稱、指標英文名稱、指標定義、統計演算法說明、指標型別(去重、非去重))，業務場景資訊(分析維度，場景描述)；

技術資訊對應指標的物理模型資訊，由資料研發進行維護，主要包括對應物理表及欄位資訊；

衍生資訊對應關聯派生或衍生指標資訊、關聯資料應用和業務場景資訊，便於使用者查詢指標被哪些其它指標和資料應用使用，提供指標血緣分析追查資料來源的能力。

原子指標定義歸屬資訊 + 基本資訊 + 業務場景資訊派生指標定義時間週期 + 修飾詞集合 + 原子指標修飾型別主要包含型別說明、統計演算法說明、資料來源(可選)

指標體系建設流程

建模流程

建模流程主要是從業務視角指導工程師對需求場景涉及的指標進行主題抽象，歸類，統一業務術語，減少溝通成本，同時避免後續的指標重複建設。

分析資料體系是模型架構中彙總事實表的物理集合，業務邏輯層面根據業務分析物件或場景進行指標體系抽象沉澱。滴滴出行主要是根據分析物件進行主題抽象的，例如司機主題、安全主題、體驗主題、城市主題等。指標分類主要是根據實際業務過程進行抽象分類，例如司機交易類指標、司機註冊類指標、司機增長類指標等。基礎資料體系是模型架構中明細事實表和基礎維度表的物理集合，業務邏輯層面根據實際業務場景進行抽象例如司機合規、乘客註冊等，還原業務核心業務過程。

開發流程

開發流程是從技術視角指導工程師進行指標體系生產、運維及質量管控，也是資料產品或資料分析師和數倉研發溝通協調的橋樑。

指標體系圖譜建設

指標體系圖譜概述

指標體系圖譜也可稱為資料分析圖譜主要是依據實際業務場景抽象業務分析實體，整合梳理實體涉及的業務分類、分析指標和維度的集合。

建設方法：主要是透過業務思維、使用者視角去構建，把業務和資料緊密關聯起來，把指標結構化分類組織

建設目的：

• 對於使用者：

便於使用者能夠快速定位所需指標和維度，同時透過業務場景化沉澱指標體系，能夠快速觸達使用者資料訴求

• 對於研發：

利於後續指標生產模型設計、資料內容邊界化、資料體系建設迭代量化和資料資產的落地

指標體系產品化

指標體系涉及的產品集主要是依據其生命週期進行相應建設，透過產品工具打通資料流，實現指標體系統一化、自動化、規範化、流程化管理。因為指標體系建設本質目標是服務業務，實現資料驅動業務價值，所以建設的核心原則是“輕標準、重場景，從管控式到服務式”。透過工具、產品、技術和組織的融合提高使用者使用資料效率，加速業務創新迭代。

其中和指標體系方法論強相關產品就是指標字典工具的落地，其產品的定位及價值：

• 支撐指標管理規範從方法到落地的工具，自動生成規範指標，解決指標名稱混亂、指標不唯一的問題，消除資料的二義性
• 統一對外提供標準的指標口徑和後設資料資訊

工具設計流程 (方法論->定義->生產->消費)

指標定義

指標生產

這部分整體介紹了指標體系建設方法論和工具產品的建設情況，目前指標字典和開發工具已實現流程打通，與資料消費產品的打通後續會透過DataAPI方式提供資料服務，規劃建設中。

資料治理

一、資料治理 治的是“資料”嗎？

資料是指對客觀事件進行記錄並可以鑑別的符號，是對客觀事物的性質、狀態以及相互關係等進行記載的物理符號或這些物理符號的組合。其實在我看來，資料可以分為兩個部分，一是數字，二是文字。數字是沒有意義的抽象符號，資料是有意義的數字。文字表意，數字表量，當兩者結合起來，資料就產生了。

在我們的生活和工作當中，資料無處不在。對企業來講，有很多資料是無關企業重大利益的資料，是沒有治理的必要的。資料治理的物件必須是重要的資料資源，是關乎企業重大商業利益的資料資源，這樣的資料資源可以稱其為“資料資產”。正如北大教授王漢生先生所說：“資料治理不是對“資料”的治理，而是對“資料資產”的治理，是對資料資產所有相關方利益的協調與規範。”

我們需要分開來理解這句話：

①什麼是資料資產？

②資料資產的相關利益方是誰？

③協調與規範什麼？

先說一說什麼是資料資產。我們說不是所有資料都是資料資產，那到底什麼才是資料資產呢？

《企業會計準則-基本準則》第20條規定：“資產是指企業過去的交易或者事項形成的、由企業擁有或者控制的、預期會給企業帶來經濟利益的資源。” 如果照貓畫虎修改一下，不難獲得一個關於資料資產的定義：“資料資產是指企業過去的交易或者事項形成的，由企業擁有或者控制的，預期會給企業帶來經濟利益的資料資源。”由此可見，資料要成為資料資產，至少要滿足3個核心必要條件：

①資料資產應該是企業的交易或者事項形成的；

②企業擁有或者控制；

③預期會給企業帶來經濟利益。

資料資產的利益相關方是誰？

根據資料資產的定義，資料資產的利益相關方，包括：

①資料的生產者，即透過業務交易或事項產生資料的人或組織。

②資料的擁有或控制者，生產資料的人不一定是擁有資料，就像我們天天上網的各種資料都不歸我們自己所有，而是落在了各個網際網路公司的資料庫中。

③資料價值和經濟利益的收益者。資料治理就是對資料生產者、擁有或控制者，資料價值獲益者的規範和協調。

都什麼是需要協調和規範？

首先是資料的標準化，定義統一的資料標準，“寫中國字、說普通話”讓資料資產的相關利益方在同一個“頻道”溝通。資料的標準化包含幾個層面：①資料模型標準化。②核心資料實體的標準化（主資料的標準化）。③關鍵指標的標準化。

其次是資料的確權。資料一旦成為資產，就一定有擁有方，或者實際控制人，可以把他們統稱產權人。與實物不同的是，實物的產權是比較明確的，資料則比較複雜。產品在生產製造過程中，並沒有與消費者交易之前，製造商擁有完全產權。產品生產出來後，消費者透過購買支付相應的貨幣，便擁有了產品的產權。而資料的生產過程就不一樣了，我們的各種上網行為每天都會產生大量的資料，例如：網上購物、瀏覽網頁、使用地圖、評論/評價……。這些資料到底歸誰所有？控制權該如何治理？這是擺在面前的一個難題！我們看到近幾年一些不良商家，利用我們的上網資料，導致安全隱私洩密的事件也層出不窮。希望隨著技術和商業的進步，儘快能夠找到解決方案！

第三是流程的最佳化。資料治理的兩個目標：一個是提質量，一個是控安全。網際網路資料的確權目前已經是一個世界級難題，做好企業業務流程的最佳化可能會對隱私保護起到一定的作用。透過業務流程最佳化，規範資料從產生、處理、使用到銷燬的整個生命週期，使得資料在各階段、各流程環節安全可控，合規使用。另外，透過一定的流程最佳化，透過對相關流程進行監管，按照資料的質量規則進行資料校驗，符合“垃圾進、垃圾出”的資料採集、處理、儲存原則，提升資料治理，賦能業務應用。

二、資料治理 到底在哪裡治？

資料治理到底應該放在中臺，還是後臺，我個人的理解是：小資料標準化治理靠人工、大資料預測性分析靠智慧，將兩者結合起來：“人工+智慧”形成了完整的資料治理技術體系。一個企業的資料治理既離不開小資料的標準化治理，也離不開大資料的預測性分析。

這裡的小資料，是在承載事物實體的資料，例如：人、財、物等，是企業所有業務開展的載體。其實說白了就是主資料管理。對於主資料的治理筆者認為是一個後臺行為，治理核心是“唯一資料來源、統一資料標準”，而要達到這一目標是需要從資料的源頭抓起的，並且需要大量的人為干預，比如：資料標準的制定和落實，資料質量的清洗，資料的申請審批，資料的分發和共享等。從這裡也能夠看出小資料的治理，追求的是標準化、精確化，應該是一個後臺行為。

而在大資料時代，得益於大資料技術的突破，大量的結構化、非結構化、異構化的資料能夠得到儲存、處理、計算和分析，這一方面提升了我們從海量資料中獲取知識和洞見的能力。對於大資料，傳統的一味追求精確的思維受到了挑戰。而對於大資料的治理，允許一定程度上的容錯，反而可以在宏觀層面擁有更好的知識和洞察力。對於大資料的治理更多的是採用AI技術，例如：知識圖譜、語音識別等，對大資料的採集、處理、使用過程加以控制，使其能夠合規使用。所以，大資料的治理放在中臺似乎更為合適。

三、資料治理 到底應該怎麼治？

1、找症狀，明確目標

任何企業實施資料治理都不是為了治理資料而治理資料，其背後都是管理和業務目標的驅動。企業中普遍存在的資料質量問題有：資料不一致、資料重複、資料不準確、資料不完整、資料關係混亂、資料不及時等。

由於這些資料問題的存在對業務的開展和業務部門之間的溝通造成了較大的困擾，產生了很大的成本；各異構的系統中資料不一致，導致業務系統之間的應用整合無法開展；資料質量差無法支撐資料分析，分析結果與實際偏差較大。然而要實現資料驅動管理、資料驅動業務的目標，沒有高質量的資料支撐是行不通的。

目標：企業實施資料治理的第一步，就是要明確資料治理的目標，理清資料治理的關鍵點。

技術工具：實地調研、高層訪談、組織架構圖。

輸入：企業資料戰略規劃，亟待解決的業務問題，經營發展需求，業務需求等；

輸出：資料治理的初步溝通方案，專案任務書，工作計劃表；

2、理資料，現狀分析

針對企業資料治理所處的內外部環境，從組織、人員、流程、資料四個方面入手，進行資料治理現狀的分析。

某企業資料治理痛點分析

組織方面：是否有專業的資料治理組織，是否明確崗位職責和分工。

人員方面：資料人才的資源配置情況，包括資料標準化人員、資料建模人員，資料分析人員，資料開發人員等，以及資料人才的佔比情況。

流程方面：資料管理的現狀，是否有歸口管理部門，是否有資料管理的流程、流程各環節的資料控制情況等；

資料方面：梳理資料質量問題列表，例如：資料不一致問題，資料不完整，資料不準確、資料不真實、資料不及時、資料關係混亂，以及資料的隱私與安全問題等。

目標：分析企業資料管理和資料質量的現狀，確定初步資料治理成熟度評估方案。

技術工具：實地訪談、調研表、資料質量問題評議表、關鍵資料識別方法論（例如：主資料特徵識別法）；

輸入：需求及現狀調研表、訪談記錄、資料樣本、資料架構、資料管理制度和流程檔案；

輸出：資料問題列表、資料U/C矩陣、資料治理現狀分析報告、資料治理評估方案；

3、資料治理成熟度評估

資料治理成熟度反映了組織進行資料治理所具備的條件和水平，包括後設資料管理、資料質量管理、業務流程整合、主資料管理和資訊生命週期管理。

CMMI DMM資料管理能力成熟度評估模型

資料治理成熟度評估是利用標準的成熟度評估工具結合行業最佳實踐，針對企業的資料治理現狀進行的客觀評價和打分，找到企業資料治理的短板，以便制定切實可行的行動方案。資料治理成熟度結束後形成初步的行動方案，一般包括資料治理戰略，資料治理指標，資料治理規則，資料治理權責。資料治理願景和使命是資料治理的整體目標；資料治理指標定義了資料治理目標的衡量方法；資料治理規則和定義包括與資料相關的政策、標準、合規要求、業務規則和資料定義等；權利和職責規定了由誰來負責制訂資料相關的決策、何時實施、如何實施，以及組織和個人在資料治理策略中該做什麼。

目標：結合業界標準的資料治理成熟度模型，根據企業管理和業務需求進行資料治理成熟的評估，形成初步的資料治理策略和行動路線。

技術工具：資料治理評估模型，例如：DCMM，CMMI DMM，IBM資料治理成熟度評估模型等；

輸入：第2步的輸入以及資料治理評估模型、資料治理評估工具（評估指標、打分表等）；

輸出：資料治理評估結果，資料治理策略，初步的行動方案；

4、資料質量問題根因分析

資料治理的目的是解決資料質量問題提升資料質量，從而為資料驅動的數字化企業提供源動力，而提到資料質量問題，做過BI、數倉的同學一定知道，這是一個技術和業務“經常打架”相互推諉的問題。

某企業資料問題根因分析魚骨圖

產生資料質量問題的原因有很多，有業務方面的、有管理方面的、也有技術方面的，按照80/20法則，80%的問題是由20%的原因造成起的。所以，如果能夠解決這20%的問題，就能得到80%的改進。

目標：分析並找到資料質量問題產生的根本原因，制定行之有效的解決方案；

技術工具：頭腦風暴、5W1H、SWOT、因果（魚刺）圖、帕拉圖等；

輸入：資料問題列表、資料U/C矩陣、資料治理現狀分析報告、資料治理評估結果；

輸出：資料質量評估結果、對業務的潛在影響和根本原因。

5、業務影響及實施優先順序評估

透過資料治理成熟度評估，從組織、流程、制度、人員、技術等方面找到企業在資料治理的待提升的領域和環節，再透過資料質量根因分析找到資料質量問題發生的根本原因，進一步明確了資料治理的目標和內容。再接下來，就需要確定資料治理策略，定義資料治理的實施優先順序。

某企業主資料治理實施優先順序評估

不同的資料治理領域解決的是不同的問題，而資料治理的每個領域都有它的實施難點，對企業來說，需要從業務的影響程度，問題的緊急程度、實施的難易程度等多個維度進行分析和權衡，從而找到符合企業需求並滿足企業發展的方案。

目標：確定資料治理核心領域和支撐體系的建設/實施優先順序；

技術工具：四象限法則（分別從業務影響程度/實施難以程度，問題重要程度/問題緊急程度繪製優先順序矩陣）、KANO模型

輸入：資料治理成熟度能力評估結果、資料質量問題根因分析結果；

輸出：資料治理實施優先順序策略

6、制定資料治理行動路線和計劃

路線圖是使用特定技術方案幫助達到短期或者長期目標的計劃，用於新產品、專案或技術領域的開發，是指應用簡潔的圖形、表格、文字等形式描述技術變化的步驟或技術相關環節之間的邏輯關係。路線圖是一種目標計劃，就是把未來計劃要做的事列出來，直至達到某一個目標，就好像沿著地圖路線一步一步找到終點一樣，故稱路線圖。

某企業資料治理實施路線圖

企業資料治理的實施路線圖的制定是以企業資料戰略——願景和使命為綱領，以急用優先為原則，以分步實施為策略進行了整體設計和規劃。實施路線圖主要包含的內容：分幾個階段實施，每個階段的目標、工作內容、時間節點要求、環境條件等。筆者觀點：任何一個企業的資料治理都不是一蹴而就，一步到位的，需要循序漸進、持續最佳化！實施路線圖就是基於此產生的，因此說資料治理實施路線圖也是說服利益相關者支援的一個重要手段。

目標：確定資料治理的階段以及每個階段的目標；

技術工具：路線圖法

輸入：資料治理成熟度能力評估結果、業務影響及實施優先順序評估結果；

輸出：資料治理實施路線圖或稱階段目標計劃

7、制定資料治理詳細實施方案

資料治理詳細實施方案是用於指導主資料的各項實施工作，一般包括：資料治理核心領域、資料治理支撐體系、資料治理專案管理三個方面。

資料治理總體框架圖

資料治理核心領域包括：資料架構、資料服務、後設資料管理、資料質量管理、資料標準管理、主資料管理、資料安全管理、資料生命週期管理。

資料治理支撐體系包括：組織（組織架構、組織層次、崗位職責）、制度（管控模式、規章制度、考核機制）、流程（歸口部門、管理流程、流程任務等）、技術（資料整合、資料清洗、資料開發、資料應用、資料運營、支撐平臺、實施方案等）。

資料治理專案管理方案包括：專案組隊、專案計劃、質量保證計劃、配置管理計劃、培訓和售後等。

關於資料治理的核心領域，詳見筆者之前分享的資料治理框架解讀系列文章。

關於資料治理的支撐體系，詳見筆者之前分享的資料治理成功關鍵要素系列文章。

目標：基於資料質量根因分析、業務影響和實施優先順序評估結果，制定詳細實施方案；

輸入：業務影響及實施優先順序評估結果，行動路線和計劃；

輸出：資料治理詳細實施方案。

8、資料治理實施過程控制

資料治理實施過程控制是對資料治理專案的範圍控制、進度控制、質量控制和成本控制，透過對企業的各項資源的合理協調與利用，而達成的資料治理目標的各種措施。從專案管理的角度來講也是專案管理的黃金三角：範圍、時間、質量、成本。

任何專案的質量和進度是需要良好的專案管理來保證的，資料治理也一樣。與傳統的軟體工程專案不同，資料治理專案有著範圍邊界模糊、影響範圍廣、短期難見效、實施週期長等特點：

①範圍邊界模糊，資料治理涉及到的關鍵領域如後設資料管理、資料質量管理、資料標準管理、主資料管理等很多是存在交叉的，邊界很難界定，例如：實施資料質量管理專案，會涉及後設資料管理、資料標準管理等，同樣一個後設資料管理專案也會涉及資料標準和資料質量。

②影響範圍廣，資料治理的實施不是一個部門能夠完成的，是需要從高階管理層、到各業務部門、資訊部門通力協作，共同完成的；

③短期難見效，資料治理專案實施完成後，其資料治理的效果被每個業務點滴操作所“稀釋”，並不像其他專案，例如BI，那樣明顯的體現出來，所以主導資料治理的部門會經常遭到質疑。

④實施週期長，在沒有清晰的資料治理目標和範圍約定的情況下，資料治理是一個“無底洞”。所以，在實施資料治理專案之前制定好實施路線圖和詳細的實施方案就顯得格外重要（第6、7步）。

目標：透過對資料治理專案實施過程的進度控制、質量控制和成本控制以實現資料治理的目標；

技術工具：PP（專案計劃）、PMC（專案控制）、IPM（整合專案管理）、RSKM（風險管理）——CMMI過程域；

輸入：6-7步的輸出：資料治理實施路線圖，資料治理詳細實施方案；

輸出：各項專案控制措施，例如：專案計劃、SOW、專案風險列表、專案報告、專案總結等；

9、監控評估資料治理實施效果

隨著大資料技術的不斷髮展，應當從企業的全域性資料治理環境的角度，明確資料治理關鍵技術運用及其標準規範，構建成效評估指標體系，進行治理效果評價；並運用資料治理能力成熟度模型再次評估，界定資料管理層次，從而使得跨系統、跨業務、跨部門的資料治理體系的建設與實施能夠透過各方協作順利進行，實現卓越資料治理，進而透過資料驅動業務、資料驅動管理和運營以實現企業的降本、增效、提質、創新。

某企業資料治理看板（資料已脫敏）

資料治理成效評估指標體系應根據企業及資料治理專案的實際情況制定，一般包括：時間性、數量性、完整性、準確性四個維度。

①時間性即資料的及時性。該維度主要透過源業務系統資料接入的上報及時性、接入及時性等方面進行核對。透過分析月指標、周指標、日指標的資料及時率，得出在規定時間和頻度週期內接入系統的比例，以此反映資料接入及時性。

②數量性。該維度是從資料存量，資料增量，資料訪問量，資料交換量、資料使用量等指標反映資料的使用情況，可以分為月度指標、周指標、日指標、時分指標等。

③準確性。這個維度主要由各類資料中邏輯的準確性、資料值的準確性、資料頻段和欄位之間的準確性以及資料的精度等內容組成。該準確率同樣包括：月度、每週、每日等準確率指標。

④完整性。此維度主要以單元維度完整性、資料業務維度組合完整性、索引值完整性等不同方面進行核對，是驗證資料質量完整性的主要組成部分，包括月度指標、周指標、日指標資料的完整性等內容。

目標：檢驗各項資料治理指標的落實情況，查漏補缺，夯實資料治理效果；

技術工具：資料治理效果的評價指標體系、各種資料圖表工具；

輸入：資料治理效果評估指標；

輸出：資料治理評估的月報、週報、日報等；

10、資料治理持續改進

資料治理模式應業務化、常態化，不應是一個專案、“一陣風”的模式。

資料治理工作應向企業生產、銷售業務一樣作為一項重點的業務工作來開展，構建專業的資料治理組織，設定合適的崗位權責，建立相應的管理流程和制度，讓資料標準貫徹到每個業務環節，形成一種常態的工作。在筆者看來，在資料來源頭加強企業資料的治理，讓常態化治理成為日常業務，才能從根本上徹底解決企業資料質量的各種問題，讓資料真正轉化為企業資產，以實現資料驅動流程最佳化、資料驅動業務創新、資料驅動管理決策的目標。

目標：資料治理常態化，持續提升資料質量，驅動流程最佳化和管理創新。

輸入：持續的、規範的、標準的各項業務操作；資料治理監控的各項指標和報告；

輸出：持續輸出的高質量的資料。

四、美團配送資料治理實戰

從大的階段來看，資料治理主要分為存量資料“由亂到治”的階段，以及增量資料嚴格按照規章制度實施確保“行不逾矩”的運營階段。在“由亂到治”的過程中，我們需要沉澱出規章制度、標準規範，以及輔以規章制度標準規範實施的工具和組織。在增量資料的運營階段，我們主要靠對應的組織確保規章制度的落實，透過審計定期考察實施效果，並在長期的運營中不斷完善規章制度。在實現存量資料“由亂到治”的階段，我們主要採取了“兩步走”策略，具體執行策略如下所示。

4.1 定標準，提質量

4.1.1 業務標準

業務標準主要是指標的管理和運營標準，我們主要解決三個問題：指標由誰來定義，指標該如何定義，指標該如何運營。基於這三個問題，我們同時提出了三條原則：

• 業務團隊負責指標的定義。
• 產研商分負責給出指標定義標準和輔助工具，輔助業務團隊完成指標的規範定義，達成指標認知一致性這一目標。
• 最後由指標管理委員會負責指標的管理與運營，保障指標從建立、稽核、上線以及到最後消亡的整個生命週期的運營。

為統一指標的定義，我們將指標分為原子指標、衍生指標和派生指標，原子指標透過限定條件和時間的限定生成衍生指標。衍生指標間的“四則混合運算”構成了派生指標。我們不但制定了指標的標準定義，還對其做了準確的資產歸屬，一個指標出自一個具體的業務過程，一個業務過程歸屬於不同的資料域，多個資料域構成了美團配送業務線下的分析場景，如下圖所示：

指標定義標準

4.1.2 技術標準

這裡所說的技術標準，主要是針對資料RD提出的建模標準和資料生產規範，透過建模標準來明確數倉分層架構，並清晰定義每一層的邊界與職責，採用維度建模的設計理念。我們的整個倉庫架構分為四層：操作層、基礎事實層、中間層和應用層，並在每一層同步制定對應的建模規範，如下圖所示：

數倉架構以及建模標準

除了建模標準外，我們還制定了涵蓋從生產到運維環節的生產規範以保障模型的質量，主要包括上線前的模型評審、生產過程中的完成後設資料配置、DQC、SLA和生命週期設定以及上線後的日常運維機制等等。尤其針對後設資料管理和生命週期管理，我們分別制定了倉庫每一層後設資料維護規範和生命週期管理規範，其中後設資料管理規範，是依據數倉各層級中各種型別表的建模標準來制定，需要做到規範命名，明確資料歸屬，並打通業務後設資料和技術後設資料之間的關係。而生命週期管理規範，是依據配送業務特點和數倉各層級現狀來制定的，如下表所示：

倉庫各層後設資料管理標準

倉庫各層生命週期管理策略

4.1.3 安全標準

圍繞資料安全標準，首先要有資料的分級、分類標準，確保資料在上線前有著準確的密級。第二，針對資料使用方，要有明確的角色授權標準，透過分級分類和角色授權，來保障重要資料拿不走。第三，針對敏感資料，要有隱私管理標準，保障敏感資料的安全儲存，即使未授權使用者繞過許可權管理拿到敏感資料，也要確保其看不懂。第四，透過制定審計標準，為後續的審計提供審計依據，確保資料走不脫。

安全標準建設

4.1.4 資源管理標準

在資源管理方面，配送技術工程部已經對資源管理涉及的內容進行了合理抽象和準確定義，抽象出租戶、資源和專案組等概念。不管是後續的資源預算還是資源管理，我們都需要基於租戶和專案組來進行運營，因此，對於業務團隊而言，我們只需要將租戶和專案組特定職能劃分清楚，然後根據不同的職能歸屬我們的資產，並分配生產該資產所需要的資源。為了方便後續的運營，我們對每個租戶和專案組分配確定了責任人，由責任人對運營結果負責。

對業務部門來說，資源管理的關鍵是對資料資產做清晰的分類，基於資料的分類劃分不同的租戶和專案組，將資料和租戶、專案組實現一一對映。由於租戶和專案組都有特定的責任人對其負責，因此，我們透過這種對映關係，不僅實現了資產的隔離，還實現了資產確權（專案組負責人同時對資產負責和運營）。我們整體將資料分為兩大類，一是原始資料，包括流到資料中心的資料和日誌中心的資料，針對流入資料中心的資料，根據其產生的方式不同，又進一步分為業務資料和流量資料。二是加工資料，對應著資料團隊的倉庫建設和其他團隊的集市建設。基於上述的描述，針對資源管理，我們做了如下劃分和確權：

資源劃分與管理

4.2 重實施，保落實

第二步，落實第一步的標準，完成資料治理第一階段的目標，實現存量資料“由亂到治”，並完成相應組織和工具的建設，為實現第二階段“行不逾矩”這一目標提供工具和組織能力。在此過程中，主要分成三個方面的治理工作：第一，架構模型“由亂到治”的治理，消除模型冗餘、跨層引用和鏈路過長等問題，在架構上保證模型的穩定性和資料一致性；第二，後設資料“由亂到治”的治理，實現指標的標準定義、技術後設資料的完整採集並建立指標與表、欄位的對映關係，徹底解決指標認知一致性，以及使用者在使用資料過程中的“找數難”等問題；第三，圍繞著隱私安全和共享安全加強資料的安全管控來實現資料走不脫、拿不走，以及隱私資料看不懂這一目標。

4.2.1 架構治理

總結起來，架構方面的治理主要是解決兩個問題：第一，模型的靈活性，避免需求變更和業務迭代對核心模型帶來的衝擊，讓RD深陷無休止的需求迭代中；第二，資料一致性，消除因模型冗餘、跨層引用等問題帶來的資料一致性問題。

模型靈活性

配送解決的是效率、成本和體驗三者之間的平衡問題，即在滿足一定使用者體驗的條件下，如何提升騎手配送效率，服務更多的商家，以及如何管控騎手，降低配送成本。抽象到資料層面，基本上反映為上游包裹來源的變化、配送對外提供服務的變化以及對內業務管控的變化。為遮蔽業務迭代給核心模型帶來的衝擊，我們透過對外封裝包裹屬性和對內封裝運單屬性，抽象出包裹來源、提供服務、業務架構等一致性維度，任何業務迭代在資料層面只涉及維度的調整，大大降低了對核心模型衝擊和“煙囪式”資料建設問題（新來一個業務，就拉起一個分支進行建設）。

包裹事實分配到運單明細構造單一運單模型

配送指標體系建設的一個重點就是要輸出各組織層級的規模、體驗和效率指標，實現對運力的有效管控，運力所屬組織的層級關係會隨業務的迭代而不斷變化。為了適應這種變化，避免僅僅因增加維度帶來中間層資料的重複建設，我們將組織層級維表由固定層級建模方式調整為橋接表的方式來自適配組織層級變化，從而實現了中間層模型可以自動適配組織層級的變化，能自動產生新維度的指標。如下圖所示：

橋接表自適配組織層級靈活變動

在精細化分析的場景下，業務會有分時段、分距離段以及分價格段的資料分析訴求。我們以分時段為例，有晚高峰、午高峰、下午茶等不同的分時段，不同的業務方對同一個時段的定義口徑不同，即不同的業務方會有不同的分時段策略。為解決該場景下的分析訴求，我們在事實表中消除退化維度，將原來封裝到事實表的時段邏輯遷移到維度表中，並將事實表中的時間進行按特定的間隔進行刻度化作為維表中的主鍵，將該主鍵作為事實表的外來鍵。這樣，針對業務不同的時間策略需要，我們就可以在維表中進行配置，避免了重複調整事實表和反覆刷數的問題。即透過將時間、價格、距離事實刻度化，實現靈活維度分析。如下圖所示：

透過將時間刻度化，實現靈活分析

資料一致性

資料一致性得不到保障的一個根本原因，是在建模的過程中沒有實現業務口徑標籤化，並將業務口徑下沉到主題層。很多同學在基於需求進行開發時，為實現方便，將新指標口徑透過“Case When”的方式在應用層和中間層進行封裝開發，主題層建設不能隨著業務的迭代不斷完善，RD在開發過程中會直接引用倉庫的快照表在中間層或應用層完成需求開發。久而久之，就會造成資料複用性低下，相同指標的口徑封裝在不同的應用表來滿足不同報表的需求，但隨著應用的增多，很難保障相同指標在不用應用表封裝邏輯的一致性，資料一致性難以得到保障，同時這種方式還帶來兩個嚴重後果：第一，跨層引用增多，資料複用性低下，造成計算和儲存成本的浪費；第二，一旦指標口徑發生變化，將是一個“災難”，不僅影響評估是一個問題，而且涉及該指標的應用層邏輯調整對RD來說也是一個巨大的挑戰。

治理前模型架構

因此，我們在“由亂到治”的治理過程中，以衍生事實的方式實現業務口徑標籤化，將業務邏輯下沉到主題層，消除跨層引用和模型冗餘等問題，從技術層面保障資料一致性是該階段架構治理的重點。我們在業務上，已經劃分了嚴格的資料域和業務過程，在主題建設層面，將業務劃分的資料域作為我們的主題，並基於業務過程進行維度建模，將屬於該業務過程的指標口徑封裝在對應業務過程下的衍生事實中。

治理後模型架構

4.2.2 後設資料治理

後設資料治理主要解決三個問題：首先，透過建立相應的組織、流程和工具，推動業務標準的落地實施，實現指標的規範定義，消除指標認知的歧義；其次，基於業務現狀和未來的演進方式，對業務模型進行抽象，制定清晰的主題、業務過程和分析方向，構建完備的技術後設資料，對物理模型進行準確完善的描述，並打通技術後設資料與業務後設資料的關係，對物理模型進行完備的刻畫；第三，透過後設資料建設，為使用資料提效，解決“找數、理解數、評估”難題以及“取數、資料視覺化”等難題。

首先，為保障業務標準的順利實施，實現業務對指標認知一致性這一目標。我們協同產研、商分、業務部門推動成立了度量衡委員會，並建立起指標運營機制，透過組織保障來實現指標運營按照規範的標準和流程實施。如下圖所示：

指標註冊流程

其次，基於配送業務的現狀和未來演進方式，我們進行了高度的業務抽象，完成了主題、業務過程和分析方向等後設資料內容的建設。配送即物流，透過線上系統和線下運營，我們將使用者的配送需求和美團的運力進行有效的資源配置，實現高服務體驗、低成本的配送服務。對外，我們將配送服務透過平臺化的方式，提供給使用者、商戶和電商平臺，以滿足不同使用者在不同業務場景下的配送需求。對內，我們透過不同的排程模式將運單池中的運單排程給合適的騎手來完成履約，平衡規模、成本和體驗之間的關係。如下圖所示：

配送業務模式抽象

基於以上的業務模式，我們劃分了運單主題（對履約資料域下的資料進行構建，支撐規模和體驗的資料分析需求）、排程主題（排程資料域下產生的資料，用於支撐排程策略的分析）、結算、評價、投訴、取消主題（用於支撐體驗、成本資料分析需求）和管控主題（用於支撐運力獎懲、違規和招募分析需求）等各種主題，並在每個主題下劃分對應的業務過程，在應用層制定分析方向的分析標籤，透過對後設資料內容的建設完成對業務的抽象，為物理模型的刻畫準備了基礎資料。

第三，後設資料服務建設，我們打通了後設資料從採集到構建再到應用的整條鏈路，為使用資料提效，解決“找數、理解數、評估”難題以及“取數、資料視覺化”難題。在整個建設過程中，我們圍繞著後設資料採集、元模型構建、後設資料服務以及最後的產品應用進行展開，整體架構如下圖所示：

後設資料建設架構圖

後設資料採集

後設資料採集分為人工錄入和自動抽取，透過人工錄入的方式實現物理表的準確歸屬（包括該表屬於倉庫哪一層、對應的主題、業務過程、星型模型關係等）以及指標的採集，從而完成技術後設資料和業務後設資料的採集，透過自動抽取的方式完成生產後設資料的採集和使用後設資料的採集，主要包括：物理模型的依賴關係、儲存佔用、熱度、等資訊。

元模型構建

分為以物理表為核心的基礎元模型構建，以及以血緣為中心的血緣元模型。基礎元模型構建以物理表為中心，打通其與技術後設資料（主題、業務過程、Schema）的關係，實現了物理表的清晰歸屬，打通其與生產後設資料的關係，為其加上了物理表查詢熱度、資源消耗、查詢密級等生產使用資訊，打通其與指標、維度和應用的對應關係，為上層的取數應用建立了完備的後設資料。血緣元模型以血緣為中心，不僅構建了從上游業務表到倉庫離線表的物理血緣，而且打通了倉庫離線表到下游對應報表的血緣，為後續的影響評估構建了完備的後設資料基礎。

後設資料服務

統一後設資料服務（OneService），主要提供兩類後設資料服務，提供查詢表、指標、維度基本資訊的基礎後設資料服務以及查詢表級血緣、欄位級血緣的血緣服務。

後設資料應用

主要孵化出了三個產品，以“找數、理解數、影響評估”為應用場景的資料地圖（Wherehows），以“取數、資料視覺化”為應用場景的資料視覺化（QuickSight），以及以管理審計為目的的管理審計報表。

4.2.3 安全治理

安全治理主要加強了敏感資料的安全治理和資料共享環節的安全治理。透過對隱私資料的安全治理，不僅要保證其在儲存環節的不可見性，而且還要保證在其使用環節對使用者進行雙重鑑權，欄位的密級鑑權和解密的金鑰鑑權；透過對資料共享環節的安全治理，我們在資料分級分類的基礎上，使資料的許可權控制從表級許可權控制擴充套件到行級許可權控制。

敏感資料安全治理

敏感資料的安全治理，主要是解決敏感資料的儲存安全和使用安全。離線場景下，敏感資料儲存安全要解決兩大挑戰：

• 確保倉庫側處理方案既要遮蔽上游業務系統變動帶來的影響，又要遮蔽自身策略對下游BI系統的影響。
• 要避免敏感資料在整個加工鏈路中的擴散。

因此，為解決倉庫處理方案與上游業務系統和下游BI系統的解耦問題，我們在上游敏感資料落到ODS環節，確保落到ODS層的敏感資料必須是明文，為保障其安全，對ODS層的所有資料進行檔案加密，但是在使用層面，對下游鏈路透明保障下游鏈路的正常生產，並限制ODS層資料許可權的開放。

ODS層資料只用於安全生產，透過此方案既遮蔽了上游處理方案對倉庫的影響，又解決了敏感資料的安全問題。當資料從離開倉庫時，在傳輸環節對敏感資料進行可逆操作，將敏感資料以明文的形式推入BI庫，實現與下游BI系統的解耦。為解決敏感資料在整個生產鏈路的擴散，我們在快照層對敏感資料進行脫敏處理，從快照層開始消除敏感資料，為保障敏感資料的可逆性，將ODS層的敏感資料抽取到安全庫中並進行加密儲存，實現安全獨立管理。具體執行如下圖所示：

針對敏感資料的使用安全，我們透過對敏感欄位的許可權控制和對解密金鑰的許可權控制，來實現敏感資料使用安全這一目標。針對單獨抽取的敏感資料，我們除了針對敏感資料設定其相應的密級確保敏感資料的許可權管控外，還基於"暗語"的加密方式為每個專案組分配一個相同的金鑰，並且將該金鑰存放到與Hadoop叢集整合的KMS進行管理（確保支撐離線計算的高併發），確保解密時實現金鑰的許可權管控。

共享環節安全治理

針對共享環節的安全治理，我們主要是在資料生產環節完成資料的分級分類和資料確權，在資料的使用環節完成資料的表級許可權控制和行級許可權控制。確保資料在使用環節規範的審批流轉，許可權開放以後的安全審計，保證資料走不脫。

首先，我們在生產環節B3、B2、B1層資料按照主題或實體C層資料按照應用方向進行邏輯劃分，並設定資源的密級和許可權負責人。特別地為實現B3層資料在查詢環節可按照業務線進行許可權管控這一目標（即行級鑑權），針對B3層資料，我們標記該資料需要在查詢環節進行行級許可權管控，標記使用行級鑑權所需的欄位和該欄位對應的列舉值。

其次，在使用環節，我們按照資產密級和使用人角色完成資料的審批流轉，實現資料的安全共享。

第三，針對B3層資料，審計是否設定了行級許可權管控。在資料開放時是否存在越權使用的情況，以及針對即將離職員工加強資料的使用審計，保證資料走不脫。

在資料“由亂到治”的治理過程中，我們不僅實現了存量資料的“由亂到治”，並且在此過程中沉澱出了一系列的建模方法論、工具，並建立了相應的安全小組和指標運營組織。同時，我們為後續增量資料治理確保資料建設“行不逾矩”，提供了強有力的組織保障、穩定的輔助工具和嚴格的執行標準。在資料治理的第二階段實現增量資料的“行不逾矩”的過程中，我們主要圍繞大資料架構審計、大資料安全與隱私管理審計、大資料質量管理審計和大資料生命週期管理審計這四方面的工作展開，保障治理工作的持續進行，不斷提高了組織的治理水平。

5. 工具簡介

5.1 資料地圖（Wherehows）

資料地圖作為後設資料應用的一個產品，聚焦於資料使用者的“找數”場景，實現檢索資料和理解資料的“找數”訴求。我們透過對離線資料集和線上資料集的後設資料刻畫，滿足了使用者找數和理解數的訴求，透過血緣圖譜，完成物理表到產品的血緣建設，消除使用者人肉評估的痛苦。

離線資料場景

1. 關鍵字檢索和嚮導查詢共同解決了“找資料”的問題：大部分的檢索資料場景下，資料使用者都可以透過關鍵字檢索來得到匹配結果。剩下的一小部分場景，例如，對於新人入職後如何瞭解整個數倉和指標的體系（數倉分幾層，每層解決什麼問題，都孵化出什麼模型；整個指標、維度體系都是怎麼分類，有哪些指標和維度），這部分場景可以使用嚮導查詢功能。嚮導查詢相當於分類查詢，將表和指標按照業務過程進行分類，使用者可以按照分類逐步找到想要的表或指標。

2. 我們打通了業務後設資料和技術後設資料之間的關係，提高了“找資料”的能力：透過“Wherehows”查詢到指標後，不僅不可檢視指標的業務定義，還能檢視指標的技術實現邏輯，指標在哪些維度或維度組合中已經實現，並且能夠在哪張表裡找到這些維度，或維度組合的指標資料。反之，也可以知道在某個維度下已經實現了哪些指標，對應的指標在哪些表裡。這些功能能讓使用者更加方便地找到想要的資料。

3. 我們提供了較為完善的資料資訊，幫助使用者更好理解資料：對於表的資訊，“Wherehows”除了提供表和欄位的中英文名稱、描述資訊等基礎資訊外，為了幫助使用者更好地理解表的建設思路，我們還提供了表的星型模型（可以關聯的一致性維度及對應的維度表）、表的血緣關係等資訊。

4. 我們透過評論問答功能，幫助使用者可以快速得到問題反饋：如果使用者看了資訊後還是感到有問題，“Wherehows”提供評論問答的功能，使用者透過這個功能可以進行提問，會有相應的負責人進行回覆。對於重複問反覆問的問題，使用者透過檢視其它人的提問和回覆就能找到答案。並且負責人還會定期的將問答資訊沉澱到對應的後設資料裡，不斷地對後設資料進行補充和完善。

業務資料場景

業務資料場景主要想解決的一個問題是，如何知道一個業務表（MySQL表）有沒有同步到數倉。如果沒有同步，能夠找誰進行同步。因為已經打通“業務表 -> 數倉表 -> 產品”三者之間的血緣關係，我們能夠輕鬆解決業務資料場景的問題。

生產評估場景

在日常資料生產工作中，我們經常需要對錶進行影響評估、故障排查、鏈路分析等工作，這些工作如果靠純人工去做，費時費力。但現在我們已經打通了“業務表/欄位 -> 數倉表/欄位 -> 產品”三者之間的血緣關係，就能夠在10分鐘內完成評估工作。對於不同的場景，血緣鏈路提供了兩個便捷的功能：過濾和剪枝。例如，某個表邏輯需要修改，需要看影響哪些下游表或產品？應該要通知哪些RD和PM？這種情況下，血緣工具直觀地顯示影響了哪些負責人和產品，以及這個表的下游鏈路。

有些表的鏈路很長，整個血緣關係圖很大，這樣會導致使用者定位資訊或問題。所以血緣工具提供了剪枝的功能，對於沒用的、不想看到的分支可以剪掉，從而讓整個鏈路變得更加直觀。

5.2 資料視覺化（QuickSight）

聚焦於資料使用者“取數”場景，使用QuickSight，使用者可以不再關心資料的來源，不再擔心資料的一致性，不再依賴RD的排期開發。透過所選即所得的方式，滿足了使用者對業務核心指標的二次加工、報表和取數訴求。首先，我們透過指標池、資料集等概念對離線生產的指標進行邏輯隔離，針對不同使用者開發不同的資料集以達到許可權控制的目的，如下圖所示：

使用者、指標池與資料集間的關係

其次，我們為使用者提供一系列的元件，幫助使用者基於為其開放的資料集實現指標的二次加工和資料視覺化功能，滿足其在不同業務場景下的取數和視覺化應用。如下圖所示：

指標加工元件

6. 總結與展望

經過三個階段的治理工作，我們在各個方面都取得了較好的效果：

• 在資料標準方面，我們制定了業務標準、技術標準、安全標準、資源管理標準，從而保障了資料生產、管理、使用合規。
• 在資料架構方面，我們透過橋接表、時間刻度化、業務口徑下沉等手段提升模型靈活性，並保障資料一致性，消除跨層引用和模型冗餘等問題。
• 在資料安全方面，我們加強了對敏感資料和資料共享環節的安全治理，保證資料拿不走、走不脫，隱私資料看不懂。
• 在後設資料建設方面，我們打通了從採集到構建再到應用的整條鏈路，併為資料使用人員提供資料地圖、資料視覺化等後設資料應用產品，幫助他們解決了“找數”、“取數”、“影響評估”等難題。

未來，我們還會繼續透過組織、規範、流程等手段持續對資料安全、資源利用、資料質量等各方面進行治理，並在資料易用性上下功夫，持續降低使用者的資料使用成本。

• 在資料架構方面，隨著資料庫技術的飛速進步，現在已經有很多資料庫能夠支援千萬級乃至億級資料的現算先用，我們也在嘗試使用這些資料庫幫助提升資料開發效率，改善數倉分層管理和應用支撐效率。
• 在資料產品方面，我們將持續完善資料地圖、資料視覺化等資料應用產品，幫助使用者快速探查、高效分析，真正發揮資料的業務價值。