大數據時代的到來，讓越來越多的企業看到了數據資產的價值。將數據視為企業的重要資產，已經成為業界的一種共識，企業也在快速探索應用場景和商業模式，并開始建設技術平臺。

但這里要特別強調一下，如果在大數據“拼圖”中遺忘了數據治理，可能再多的技術投入也是一種徒勞。因為沒有數據治理這一環節，其帶來后果往往是：隨處可見的數據不統一，難以提升的數據質量，難以完成的模型梳理，難以保障的數據安全等等，源源不斷的基礎性數據問題會進一步產生，進而導致數據建設難以真正發揮其商業價值。

因此，消除數據的不一致性，建立規范的數據標準，提高數據治理能力，實現數據安全共享，并能夠將數據作為企業的寶貴資產應用于業務、管理、戰略決策中，發揮數據資產價值變得尤為迫切和重要，數據治理呼之欲出。本文將介紹美團配送技術團隊在數據治理方面的一些探索和實踐，希望能夠對大家有所啟發和幫助。

1. 如何理解數據治理

數據治理，從嚴格的定義來講是對組織的大數據管理并利用其進行評估、指導和監督的體系框架。企業通過制定戰略方針、建立組織架構、明確職責分工等，實現數據的風險可控、安全合規、績效提升和價值創造，并提供創新的大數據服務。從個人實踐的層面來講，數據治理是對存量數據治理和增量數據管控的一個過程，對存量數據實現由亂到治、建章立制，對增量數據實現嚴格把控、行不逾矩的約束。

2. 要達成的目標

數據治理本身并不是目的，它只是實現組織戰略目標的一個手段而已。從組織職能和體量大小方面來看，不同類型組織的數據治理目標大不相同，而基于目前美團配送數據團隊所處的組織職能和發展階段來說，我們希望通過數據治理解決數據生產、管理和使用過程中遇到的問題，完善已有的生產管理流程規范，保障數據安全和數據一致性，從而促進數據在組織內無障礙地進行共享。

3. 何時進行數據治理

找準數據治理的切入點，是關乎數據治理成敗的關鍵。很多同學會問，如果將數倉建設分為數倉雛形階段、數倉迭代階段和能力沉淀階段，數據治理應該在哪個階段切入為宜呢？其實，我們不該把數據治理看作是一個階段性的項目，它應該是一個貫徹數據建設各階段的長期工程，只是在不同階段根據業務特點和技術特點其覆蓋的范圍和關注的目標有所不同而已。

在數倉雛形階段，也就是美團配送業務剛成立時，在該階段中業務有兩個特點：第一，重規模、快擴張；第二，業務變化快，數據需求多。為了快速響應業務的需求，并能夠保障數據交付結果的準確性，我們主要進行技術規范和指標口徑的治理，在規范治理方面，通過制定一系列研發規范來保障研發質量，并在實際建模過程中不斷迭代和完善我們的研發質量。在指標治理方面，我們對存量指標口徑進行梳理，從而確保指標口徑對外輸出一致。

在數倉迭代階段，我們希望通過架構治理改變前期開發的“煙囪式”模型，消除冗余，提升數據一致性。并且隨著數倉中管理的數據越多，數據安全和成本問題也變得越發重要。所以在該階段，我們在產研層面逐步開展架構治理、資源治理和安全治理。在架構治理方面，我們明確了數倉中各層和各主題的職責和邊界，構建一致的基礎數據核心模型，并制定一系列的指標定義規范來確保指標的清晰定義，并基于業務迭代來不斷完善和迭代相應的模型和規范。在資源治理方面，我們通過對不同層級的數據采用不同生命周期管理策略，確保用最少的存儲成本來滿足最大的業務需求。在安全治理方面，我們通過制定一系列的數據安全規范來確保數據的使用安全。

在能力沉淀階段，我們基于前兩個階段所做的業務和技術沉淀，將前期一系列規范形成標準，從業務到產研，自上而下地推動數據治理，并通過建立相應的組織、流程和制度來保障標準在該階段的全面落地實施，并通過建設數據治理平臺來輔助更高質量地執行標準。

4.如何開展數據治理

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

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的排期開發。通過所選即所得的方式，滿足了用戶對業務核心指標的二次加工、報表和取數訴求。首先，我們通過指標池、數據集等概念對離線生產的指標進行邏輯隔離，針對不同用戶開發不同的數據集以達到權限控制的目的，如下圖所示：

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

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

在數據標準方面，我們制定了業務標準、技術標準、安全標準、資源管理標準，從而保障了數據生產、管理、使用合規。

在數據架構方面，我們通過橋接表、時間刻度化、業務口徑下沉等手段提升模型靈活性，并保障數據一致性，消除跨層引用和模型冗余等問題。

在數據安全方面，我們加強了對敏感數據和數據共享環節的安全治理，保證數據拿不走、走不脫，隱私數據看不懂。

在元數據建設方面，我們打通了從采集到構建再到應用的整條鏈路，并為數據使用人員提供數據地圖、數據可視化等元數據應用產品，幫助他們解決了“找數”、“取數”、“影響評估”等難題。

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

在數據架構方面，隨著數據庫技術的飛速進步，現在已經有很多數據庫能夠支持千萬級乃至億級數據的現算先用，我們也在嘗試使用這些數據庫幫助提升數據開發效率，改善數倉分層管理和應用支撐效率。

在數據產品方面，我們將持續完善數據地圖、數據可視化等數據應用產品，幫助用戶快速探查、高效分析，真正發揮數據的業務價值。

作者簡介

王鵬，2016年加入美團點評，目前在配送事業部數據團隊負責眾包業務數據建設、數據治理和系統化相關工作。

家豪，2018年加入美團點評，目前在配送事業部數據團隊負責眾包業務數據建設、數據治理和系統化相關工作。
編輯：hfy