做者簡介數據結構
Leon Gu，攜程數據倉庫專家，負責度假數據中臺和數據倉庫等工做，專一於大數據、數據倉庫、數據治理等領域。架構
1、前言運維
攜程度假包含跟團遊、自由行、玩樂、門票、用車等十多條業務線，業務涵蓋線上預約到線下門店，業務線之間的差別性大，業務系統之間的複雜度高。爲了知足業務的快速發展與創新，前期數據團隊都是以小數倉的方式來快速響應需求。經歷了多年的發展演變，主要面臨如下幾個問題：函數
（1） 各業務線端到端重複建設浪費資源，人力配置不均衡，團隊效率低；工具
（2） 大量重複建設的模型、報表及應用，需求場景不清晰，歷史包袱重；大數據
（3） 維度不統一，數據整合難度大；指標口徑不一致，數據理解成本高；優化
本文將介紹度假數據治理項目中需求梳理與模型設計的實踐經驗和思考，但願可以對你們有所借鑑和幫助。設計
2、實踐篇日誌
數據治理的問題並不只僅只是治理數據自己，其最終目標是提高數據價值，它是一個包括組織、制度、流程、工具的管理體系。那咱們就從對組織的思考拉開度假數據治理的介紹。對象
2.1 如何思考數據團隊效率優化的問題
爲了快速響應業務的發展，前期度假數據團隊保持着小數倉的組織結構，以下圖所示，每一個業務線配置了必定資源的數倉開發人員，經過統一的接口人與業務方對接交付全部數據需求。
這種結構的好處是比較靈活，各業務線有本身固定獨立的資源池，也比較適合當時度假組織架構快速變化的大背景。壞處也是顯而易見的，一方面，好比服務域、流量域，業務數據源基本都是一致的，但每一個小數倉都須要重起爐竈進行端到端的重複建設，資源浪費不可避免。另外一方面，因爲各業務線的投入不一樣，相較於大業務線兵多將廣，小業務線每每人力匱乏，取數工做已佔據了幾乎全部的時間，也無暇作一些數據沉澱和業務賦能的事情。
2019年度假的數據團隊進行了合併，帶着什麼樣的組織結構能讓數據團隊效率更優的思考，咱們對團隊內部的組織結構進行了一些調整，以下圖所示。仍然保留了原先的垂直化的結構，在其下方新增了一箇中臺化的公共組，它所帶了的價值主要有三方面：
第一，將業務基本一致的數據域放到公共組進行建設，好比以前提到的服務域、流量域。這樣作的目的是直接砍掉了各業務線的重複的輪子收口統一的標準，垂直業務線不須要構建端到端的整條數據鏈路；而對於像訂單域、商品域這些業務差別性較大的數據域，仍然放在垂直的業務線進行建設並快速響應業務的需求。
第二，由公共組整合打通各業務線的數據，沉澱統一的數據資產，好比用戶域、供應商域。這樣作的目的是將原先孤島或不標準的各業務線核心數據打通，造成完整的度假的資產沉澱，這樣再反哺到業務線使用，不只更豐富了數據，又提高了複用性，對於小業務線的受益就更大了。
第三，由公共組收口數據同步和數據運維的工做。數據同步的複雜度其實並不高，特別是平臺已經提供了完善的可配置的操做界面，收口的目的更多的在於由專門的同窗來操做既能夠有一套標準熟練可執行的規範，同時保證在度假層面ODS表的惟一性。數據運維也是如此，經過元數據、血緣、平臺工具等制定出標準流程及自動規則，來賦能各業務線的運維能力。
2.2 如何經過需求梳理，理清數據治理的範圍
想要作好數據治理首先要明確咱們要治理的數據範圍是什麼，打開平臺的元數據，咱們會發現，度假有上萬個任務、上千個報表、上百個應用，這些是否就是咱們所要尋找的範圍？咱們就經過需求梳理來解開這個問題的答案。
2.2.1 現狀盤點
面對這麼多的歷史積累，咱們首先要對現狀作一個總體的盤點，清楚的知道每一個模型、每一個報表、每一個應用它的用途是什麼，包含了哪些維度和指標，與之關聯的任務和表都有哪些。以下圖所示是咱們針對現狀盤點梳理的部分模板。如何可以高效的完成這個繁重的任務是實踐中的難點，咱們作法是這樣的：
第一，如何分配盤點任務？咱們將全部的任務、報表、應用都按照數據域劃分，明確梳理的owner是誰，作到責任到人，保證團隊內部對於梳理的邊界劃分清晰，避免存在重複梳理的狀況。
第二，如何提升盤點效率？咱們利用了元數據和血緣關係將模型、報表、應用的基本信息和範圍統一獲取到，同時經過血緣的上下游能夠找到上有的數據源及下游的影響面，儘量減小人工梳理的成本。
報表 |
路徑 |
是否下線 |
維度 |
指標 |
流量報表 |
/報表路徑A |
否 |
日期 頁面 … |
PV UV … |
轉化報表 |
/報表路徑B |
需重構 |
日期 商品 … |
UV 轉化率 … |
2.2.2 現狀收斂
俗話說上線容易下線難，過去咱們一直在作加法，並無一套清晰標準的下線流程，或許從潛意識中對下線這個詞就根本不太關注，也致使了數據運維的成本極高，資源浪費的狀況嚴重。
爲了能明確數據治理的準確範圍，咱們須要對已盤點的現狀作收斂，明確哪些可下線，哪些可合併。經過現狀收斂的梳理，對模型、報表及應用都標註了收斂的類型，分爲：可以使用、可下線、可合併。
在度假的數據治理開展中，大部分數據域收斂比例爲20%-30%，某些數據域能夠達到50%以上，固然這也和一些業務線的歷史包袱有關。
報表 |
路徑 |
是否下線 |
維度 |
指標 |
商品報表 |
/報表路徑C |
是 |
日期 商品 … |
指標1 指標2 … |
2.2.2.1 可下線
可下線的標準原則有如下三點：
低訪問頻率：報表及應用近三個月被業務方訪問的總頻次小於3次；
無維護責任人：責任人缺失、離職，而且沒有業務方可以描述清楚其背景和口徑；
報錯無下游：長期報錯的模型且無人報修，或者已無下游使用，這裏說的下游使用包含了依賴關係和即席查詢；
2.2.2.2 可合併
可合併的標準原則有如下兩點：
重複建設：維度和指標相同或者有包含的關係，能夠直接合並；
口徑統一：原先的指標口徑不一致，經過梳理進行了統一後可合併；
2.2.3 明確場景
對於不少數倉的同窗來講，他們對於業務的理解是存在很大的侷限性的，每每習慣於接需求與解決需求，但並無詢問需求背後到底要解決什麼，更作不到觸類旁通。另外一方面，咱們的概括也只是一種猜想，是不是真實的需求場景？沒有誤差或錯誤？
此處就是一個大大的問號，明確場景就是要走近業務，探求數據背後的真相與本質。讓數據的同窗可以更多的瞭解業務，至少能完整的知道業務使用數據在作些什麼，怎麼作的，同時讓更多的業務場景可以沉澱下來，也是一種對於知識體系的傳承。明確場景須要清晰描述如下幾點：
第一，需求場景的背景是什麼，可以解決什麼樣的問題；
第二，須要看什麼樣的數據，從哪些維度，哪些指標來看；
第三，業務是如何利用需求的數據來進行分析和運營的；
第四，最終如何落地待解決問題，如何經過數據可衡量；
需求場景 |
維度 |
指標 |
場景：背景是什麼，可以解決什麼樣的問題 分析：如何利用數據來進行分析和運營 落地：如何落地待解決問題，如何經過數據可衡量 |
日期 商品 用戶 … |
指標1 指標2 指標3 … |
2.3 如何經過模型設計來規範治理數據？
2.3.1 數倉分層
數據倉庫的分層主要解決的是數據的存儲與管理，是對數據的橫向管理，對於數據權限的控制以及邊界的清晰定義也都有着重要的做用。其優點主要體如今如下三點：
清晰數據結構：每個數據分層都有它的做用域和職責，在使用表的時候能更方便地定位和理解數據；
減小重複開發：規範數據分層，開發一些通用的中間層數據，可以極大下降重複計算，減小煙囪式開發；
統一數據口徑：經過數據分層，提供統一的數據出口，統一對外輸出的數據口徑，避免同一指標不一樣口徑的狀況發生；
咱們對於數倉分層進行了明確的定義，共分爲四層：
分層 |
定義說明 |
ODS |
數據直接從生產同步過來，保留原始數據，便於定位問題 |
EDW |
存放明細事實數據，只是作簡單的數據清洗以及存放退化維度屬性，不存放派生指標、衍生指標 |
CDM |
面向數據域建模，爲減小存儲一般存放 EDW 的彙總數據，含具體口徑的指標的明細數據也應屬於該層，進一步進行維度屬性退化，能夠存放派生指標、衍生指標，可是不能夠跨數據域存放事實、指標。如涉及用戶/訂單/流量等多個域的模型時不該放置在該層 |
ADM |
面向應用建模，數據不跨應用訪問，數據基於 EDW、CDM 生成，能夠跨數據域存放事實 |
規範後的表名會明確帶有所屬分層的前綴，好比edw_，經過平臺的元數據，就能夠很方便的知道各分層的模型數量及比例狀況。結合上述分層的目的，咱們對四層作了必定的約束：
第一，CDM和AMD層必須基於EDW層進行加工，這就對EDW層的完整性提出了要求，數據進入數倉，必需要通過規範約束，同時作到清晰加工。
第二，指標加工必須在CDM層或以上進行加工，這就對CDM層的指標收口和複用性提出了要求，指標的加工出口必須統一，同時上層的查詢優先應該走到CDM。
第三，EDW和CDM層中加工的數據不跨數據域，若是須要加工多個數據域的數據，必須在ADM層進行，好比用戶域的資產沉澱。
2.3.2 劃分數據域
數據域是面向業務分析，將業務過程或者維度進行抽象的集合。當你面對一個全新的業務領域時，作數據域的劃分會幫助你認識全局，規劃底層的總體建設。
數據域的劃分主要是從縱向來管理數據，將有較強關聯的數據進行概念層次的歸類。如上文提到，咱們的數據治理中數據域不光是用於概括數據，同時也是項目開展的一個最細的顆粒度，項目的進度和資源的投入都是以數據域的劃分來進行跟蹤和分配的。
咱們對於數據域的劃分聽從了集團統一的定義，共分爲十四個域：
數據域中文名 |
定義 |
日期 |
對天然日的描述信息 |
地理 |
對於國家/城市、經緯度等地理信息的描述 |
用戶 |
主要指攜程註冊用戶有關的數據集 |
交易 |
交易就是買賣雙方對某同樣產品或服務進行磋商談判的一旦生意。雙方以貨幣爲沒接的價值交換 |
資源 |
例如：商戶、供應商、門店等 |
產品 |
產品和資源 在不一樣 BU 間的概念多是相反的，在數據域中的定義通常須要站在集團層面考慮概念的分類，資源更多的是指集團外部對象，產品則是指集團內部建立的對象 |
市場 |
例如：營銷優惠券、引流渠道、語言站點 |
組織 |
用於維護集團、BU 等組織結構的信息 |
服務 |
例如：投訴、點評、客服 |
財務 |
例如 ：匯率 |
日誌 |
用戶行爲觸發的每一次操做的記錄 |
元數據 |
元數據是描述數據的數據，打通了數據源、數據倉庫、數據應用，記錄了數據從生產到消費的全過程 |
系統設備 |
關於設備相關的維度 |
人事 |
用以存放員工類型的維度信息，或者人力資源相關的事實，好比考勤事實 |
2.3.3 定義統一維度
維度建模中最重要的概念是「一致性維度」，爲了實現及規範，經過系統化方式來管理，提高維度表複用，減小煙囪開發。
維度的定義與維護，須要管理維度主題、維度、維度類型、維度屬性與維表之間的關聯關係，提供建立維度、關聯維表、維護維度屬性等功能，須要事先定義好維度主題，從需求中抽象出主題，有機構、產品、資源、用戶、時間、設備、地理、營銷、財務、元數據等一級主題，一些狀況須要分出二級主題。
維度也能夠近似地認爲是維表主鍵對應的含義。維度類型，又稱SCD緩慢變化維類型，有四種分類：每日快照、屬性值不變（保留原始值）、屬性值直接變動（重寫）、拉鍊表，根據實際需求選擇。
產品目的地對度假各業務線的數據分析而言是一個相當重要的維度，但在度假這個維度存在這二義性，跟團遊產品的目的地使用的是酒店的城市維度，而郵輪產品的目的地使用的倒是攻略的POI維度。
當在度假層面咱們想作一些上層的數據整合應用時，好比作用戶對目的地的偏好時問題就來了，兩個目的地的維度的維度屬性和屬性值根本就不一致，沒有辦法將數據直接進行整合，還須要進行後續的長鏈路的轉化加工處理。
相似的問題還有不少，因此一致性維度的做用就是爲了解決維度統一的問題，使數據可以在統一維度下進行整合與分析，在度假的數據治理中，咱們會在全度假的視角下進行維度的統一，對於一些像地理、組織等公共維度，咱們還會作到與集團的維度保持一致。
2.3.4 構建總線矩陣
總線矩陣對於作過數倉的同窗應該都很熟悉，目的就是要明確每一個數據域下有哪些業務過程，業務過程與哪些維度相關，並定義每一個數據域下的業務過程和維度。
\業務過程 一致性維度\ |
下單 |
分單 |
… |
支付 |
退訂 |
日期 |
1 |
1 |
1 |
1 |
1 |
渠道 |
1 |
1 |
1 |
1 |
1 |
用戶 |
1 |
0 |
0 |
1 |
1 |
… |
… |
… |
… |
… |
… |
2.3.5 明確指標口徑
2.3.5.1 指標梳理
指標口徑的不一導致得數據使用的成本極高，常常出現口徑打架、反覆覈對數據的問題。在數據治理中，咱們將需求梳理到的全部指標進行進一步梳理，明確其口徑，若是存在兩個指標名稱相同，但口徑不一致，先判斷是不是進行合併，如須要同時存在，那麼在命名上必須可以區分開。
另外，如在數倉分層的約束中提到，指標口徑的加工咱們會約束在CDM層或以上來收口，若是指標不存在複用性，則容許在ADM層直接加工，不然，只能在CDM層進行加工，並且只能有惟一一個出口。
業務過程 |
指標中文名稱 |
指標口徑 |
下單 |
指標A |
指標A的口徑 |
下單 |
指標B |
指標B的口徑 |
下單 |
指標C |
指標C的口徑 |
2.3.5.2 指標管理
指標管理是藉助於集團上線的指標管理工具，分爲原子指標維護和派生指標維護。
原子指標：
1）選擇原子指標的歸屬產線、業務板塊、數據域、業務過程
2）選擇原子指標的統計數據來源於該業務過程下的原始數據源
3）錄入原子指標的英文名稱、中文名稱、概述
4）填寫指標函數
5）系統根據指標函數自動生成原子指標的定義表達式
6）系統根據指標定義表達式以及數據源表生成原子指標SQL
派生指標：在原子指標的基礎之上選擇了一些維度或者修飾限定詞。
另外，咱們從指標的開始建立上線到最終下線，提供了審批功能，實現指標的生命週期的閉環管理，同時統計指標的派生次數和查看次數，提供產品或者開發掌握熱點指標的使用狀況。
3、總結
最後咱們再來聚焦開頭提出的幾個問題，總結一下數據治理都是怎麼幫咱們解決的：
各業務線端到端重複建設浪費資源，人力配置不均衡，團隊效率低
經過公共化的組織結構沉澱，將部分數據整合、數據資產、數據運維進行統一，減小資源浪費、人力不均衡，同時也進一步提高團隊效率。
大量重複建設的模型、報表及應用，需求場景不清晰，歷史包袱重
經過體系化的需求梳理，盤清現狀、分清包袱，從殘酷的現狀裏洞察並甄別那些真正業務須要的場景，以這個範圍做爲數據治理的起點與目標。
維度不統一，數據整合難度大；指標口徑不一致，數據理解成本高
經過標準化的維度建模方法，構建統一的一致性維度，梳理並收口指標口徑定義，經過指標管理工具維護及查看指標的計算口徑及生產加工鏈路。
其實不少的實踐或者是落地的產物還都是基於規範或者文檔的形式，目前咱們也在與攜程平臺、公共和其餘相關事業部的同窗一塊兒推動規範標準產品化的落地，相信在不久以後，這些規範和實踐經驗也可以幫助更多同窗收穫數據治理所帶來的益處。