美團配送數據治理實踐

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

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

所以，消除數據的不一致性，創建規範的數據標準，提升數據治理能力，實現數據安全共享，並可以將數據做爲企業的寶貴資產應用於業務、管理、戰略決策中，發揮數據資產價值變得尤其迫切和重要，數據治理呼之欲出。本文將介紹美團配送技術團隊在數據治理方面的一些探索和實踐，但願可以對你們有所啓發和幫助。

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進行管理（確保支撐離線計算的高併發），確保解密時實現密鑰的權限管控。

共享環節安全治理

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

首先，咱們在生產環節B三、B二、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年加入美團點評，目前在配送事業部數據團隊負責衆包業務數據建設、數據治理和系統化相關工做。

閱讀更多技術文章，請關注「美團技術團隊」微信公衆號。