大資料時代的到來，讓越來越多的企業看到了資料資產的價值。將資料視為企業的重要資產，已經成為業界的一種共識，企業也在快速探索應用場景和商業模式，並開始建設技術平臺。
但這裡要特別強調一下，如果在大資料“拼圖”中遺忘了資料治理，可能再多的技術投入也是一種徒勞。因為沒有資料治理這一環節，其帶來後果往往是：隨處可見的資料不統一，難以提升的資料質量，難以完成的模型梳理，難以保障的資料安全等等，源源不斷的基礎性資料問題會進一步產生，進而導致資料建設難以真正發揮其商業價值。
因此，消除資料的不一致性，建立規範的資料標準，提高資料治理能力，實現資料安全共享，並能夠將資料作為企業的寶貴資產應用於業務、管理、戰略決策中，發揮資料資產價值變得尤為迫切和重要，資料治理呼之欲出。本文將介紹美團配送技術團隊在資料治理方面的一些探索和實踐，希望能夠對大家有所啟發和幫助。
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的排期開發。通過所選即所得的方式，滿足了使用者對業務核心指標的二次加工、報表和取數訴求。首先，我們通過指標池、資料集等概念對離線生產的指標進行邏輯隔離，針對不同使用者開發不同的資料集以達到許可權控制的目的，如下圖所示：
其次，我們為使用者提供一系列的元件，幫助使用者基於為其開放的資料集實現指標的二次加工和資料視覺化功能，滿足其在不同業務場景下的取數和視覺化應用。如下圖所示：
6.總結與展望
經過三個階段的治理工作，我們在各個方面都取得了較好的效果：
- 在資料標準方面，我們制定了業務標準、技術標準、安全標準、資源管理標準，從而保障了資料生產、管理、使用合規。
- 在資料架構方面，我們通過橋接表、時間刻度化、業務口徑下沉等手段提升模型靈活性，並保障資料一致性，消除跨層引用和模型冗餘等問題。
- 在資料安全方面，我們加強了對敏感資料和資料共享環節的安全治理，保證資料拿不走、走不脫，隱私資料看不懂。
- 在後設資料建設方面，我們打通了從採集到構建再到應用的整條鏈路，併為資料使用人員提供資料地圖、資料視覺化等後設資料應用產品，幫助他們解決了“找數”、“取數”、“影響評估”等難題。
未來，我們還會繼續通過組織、規範、流程等手段持續對資料安全、資源利用、資料質量等各方面進行治理，並在資料易用性上下功夫，持續降低使用者的資料使用成本。
- 在資料架構方面，隨著資料庫技術的飛速進步，現在已經有很多資料庫能夠支援千萬級乃至億級資料的現算先用，我們也在嘗試使用這些資料庫幫助提升資料開發效率，改善數倉分層管理和應用支撐效率。
- 在資料產品方面，我們將持續完善資料地圖、資料視覺化等資料應用產品，幫助使用者快速探查、高效分析，真正發揮資料的業務價值。
作者簡介
- 王鵬，2016年加入美團點評，目前在配送事業部資料團隊負責眾包業務資料建設、資料治理和系統化相關工作。
- 家豪，2018年加入美團點評，目前在配送事業部資料團隊負責眾包業務資料建設、資料治理和系統化相關工作。
閱讀更多技術文章，請關注「美團技術團隊」微信公眾號。
