總第363篇
2019年 第41篇
背景
隨着業務的發展，頻繁迭代和跨部門的垂直業務單元變得越來越多。但由於缺乏前期規劃，導致後期數倉出現了嚴重的數據質量問題，這給數據治理工作帶來了很大的挑戰。在數據倉庫建設過程中，我們總結的問題包括如下幾點：
缺乏統一的業務和技術標準，如：開發規範、指標口徑和交付標準不統一。
缺乏有效統一的數據質量監控，如：列值信息不完整和不準確，SLA時效無法保障等。
業務知識體系散亂不集中，導致不同研發人員對業務理解存在較大的偏差，造成產品的開發成本顯著增加。
數據架構不合理，主要體現在數據層之間的分工不明顯，缺乏一致的基礎數據層，缺失統一維度和指標管理。
目標
在現有大數據平臺的基礎上，借鑑業界成熟OneData方法論，構建合理的數據體系架構、數據規範、模型標準和開發模式，以保障數據快速支撐不斷變化的業務並驅動業務的發展，最終形成我們自己的OneData理論體系與實踐體系。
OneData探索
OneData：行業經驗
在數據建設方面，阿里巴巴提出了一種OneData標準，如圖-1所示：
OneData：我們的思考
他山之石，可以攻玉。我們結合實際情況和業界經驗，進行了如下思考：
1. 對阿里巴巴OneData的思考
整個OneData體系覆蓋範圍廣，包含數據規範定義體系、數據模型規範設計、ETL規範研發以及支撐整個體系從方法到實施的工具體系。
實施週期較長，人力投入成本較高。
推廣落地的工作比較依賴工具。
2. 對現有實際的思考
現階段工具保障方面偏弱，人力比較缺乏。
現有開發流程不能全部推翻。
經過綜合考量，我們發現直接全盤複用他人經驗是不合理的。那我們如何定義自己的OneData，即能在達到目標的前提下，又能避免上述的難題呢？
OneData：我們的想法
首先，結合行業經驗，自身階段的實踐及以往的數倉經驗，我們預先定義了OneData核心思想與OneData核心特點。
OneData核心思想：從設計、開發、部署和使用層面，避免重複建設和指標冗餘建設，從而保障數據口徑的規範和統一，最終實現數據資產全鏈路關聯、提供標準數據輸出以及建立統一的數據公共層。
OneData核心特點：三特性和三效果。
三特性：統一性、唯一性、規範性。
三效果：高擴展性、強複用性、低成本性。
OneData：我們的策略
OneData即有核心思想又有核心特點，到底怎麼來實現核心思想又能滿足其核心特點呢？通過以往經驗的沉澱，我們提出兩個統一方法策略：統一歸口、統一出口。
根據兩個統一的方法策略，我們開啓了OneData的實踐之路。
OneData實踐
統一業務歸口
數據來源於業務並支撐着業務的發展。因此，數倉建設的基石就是對於業務的把控，數倉建設者即是技術專家，也應該是“大半個”業務專家。基於互聯網行業的特點，我們基本上採用需求推動數據的建設，這也帶來了一些問題，包括：數據對業務存在一定的滯後性；業務知識沉澱在各個需求裏，導致業務知識體系分散。針對這些問題，我們提出統一業務歸口，構建全局知識庫，進而保障對業務認知的一致性。
設計統一歸口
爲了解決數據倉庫建設過程中出現的各種痛點，我們從模型與規範兩個方面進行建設，並提出設計統一歸口。
1. 模型
規範化模型分層、數據流向和主題劃分，從而降低研發成本，增強指標複用性，並提高業務的支撐能力。
(1) 模型分層
優秀可靠的數倉體系，往往需要清晰的數據分層結構，即要保證數據層的穩定又要屏蔽對下游的影響，並且要避免鏈路過長。結合這些原則及以往的工作經驗，我們將分層進行統一定義爲四層：
(2) 模型數據流向
重構前，存在大量的煙囪式開發、分層應引用不規範性及數據鏈路混亂、血緣關係很難追溯和SLA時效難保障等問題。
重構之後，穩定業務按照標準的數據流向進行開發，即ODS-->DWD-->DWA-->APP。非穩定業務或探索性需求，可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP兩個模型數據流。在保障了數據鏈路的合理性之後，又在此基礎上確認了模型分層引用原則：
正常流向：ODS>DWD->DWT->DWA->APP，當出現ODS >DWD->DWA->APP這種關係時，說明主題域未覆蓋全。應將DWD數據落到DWT中，對於使用頻度非常低的表允許DWD->DWA。
儘量避免出現DWA寬表中使用DWD又使用（該DWD所歸屬主題域）DWT的表。
同一主題域內對於DWT生成DWT的表，原則上要儘量避免，否則會影響ETL的效率。
DWT、DWA和APP中禁止直接使用ODS的表， ODS的表只能被DWD引用。
禁止出現反向依賴，例如DWT的表依賴DWA的表。
2. 主題劃分
傳統行業如銀行、製造業、電信、零售等行業中，都有比較成熟的主題劃分，如BDWM、FS-LDM、MLDM等等。但從實際調研情況來看，主題劃分太抽象會造成對業務理解和開發成本較高，不適用互聯網行業。因此，結合各層的特性，我們提出了兩類主題的劃分：面向業務、面向分析。
面向業務：按照業務進行聚焦，降低對業務理解的難度，並能解耦複雜的業務。我們將實體關係模型進行變種處理爲實體與業務過程模型。實體定義爲業務過程的參與體；業務過程定義是由多個實體作用的結果，實體與業務過程都帶有自己特有的屬性。根據業務的聚合性，我們把業務進行拆分，形成了七大核心主題。
面向分析：按照分析聚焦，提升數據易用性，提高數據的共享與一致性。按照分析主體對象不同及分析特徵，形成分析域主題在DWA進行應用，例如銷售分析域、組織分析域。
3. 規範
模型是整個數倉建設基石，規範是數倉建設的保障。爲了避免出現指標重複建設和數據質量差的情況，我們統一按照最詳細、可落地的方法進行規範建設。
(1) 詞根
詞根是維度和指標管理的基礎，劃分爲普通詞根與專有詞根，提高詞根的易用性和關聯性。
普通詞根：描述事物的最小單元體，如：交易-trade。
專有詞根：具備約定成俗或行業專屬的描述體，如：美元-USD。
(2) 表命名規範
通用規範
表名、字段名採用一個下劃線分隔詞根（示例：clienttype->client_type）。
每部分使用小寫英文單詞，屬於通用字段的必須滿足通用字段信息的定義。
表名、字段名需以字母爲開頭。
表名、字段名最長不超過64個英文字符。
優先使用詞根中已有關鍵字（數倉標準配置中的詞根管理），定期Review新增命名的不合理性。
在表名自定義部分禁止採用非標準的縮寫。
表命名規則
表名稱 = 類型 + 業務主題 + 子主題 + 表含義 + 存儲格式 + 更新頻率 +結尾，如下圖所示：
(3) 指標命名規範
結合指標的特性以及詞根管理規範，將指標進行結構化處理。
A. 基礎指標詞根，即所有指標必須包含以下基礎詞根：
B. 業務修飾詞，用於描述業務場景的詞彙，例如trade-交易。
C.日期修飾詞，用於修飾業務發生的時間區間。
D.聚合修飾詞，對結果進行聚集操作。
E.基礎指標，單一的業務修飾詞+基礎指標詞根構建基礎指標 ，例如：交易金額-trade_amt。
F.派生指標，多修飾詞+基礎指標詞根構建派生指標。派生指標繼承基礎指標的特性，例如：安裝門店數量-install_poi_cnt。
G.普通指標命名規範，與字段命名規範一致，由詞彙轉換即可以。
H.日期類型指標命名規範，命名時要遵循：業務修飾詞+基礎指標詞根+日期修飾詞/聚合修飾詞。將日期後綴加到名稱後面，如下圖所示：
I.聚合類型指標，命名時要遵循：業務修飾詞+基礎指標詞根+聚合類型+日期修飾詞。將累積標記加到名稱後面，如下圖所示：
(4) 清洗規範
確認了字段命名和指標命名之後，根據指標與字段的部分特性，我們整理出了整個數倉可預知的24條清洗規範：
結合模型與規範，形成模型設計及模型評審兩者的工作職責，如下圖所示：
統一應用歸口
在對原有的應用支持流程進行梳理的時候，我們發現整個研發過程是煙囪式。如果不進行改善就會導致前面的建設“毀於一旦”，所以需對原有應用支持流程進行改造，如下圖所示：
從圖中可以看出，重構前一個應用存在多次迭代，每次迭代都各自維護自己的文檔。煙囪式開發會導致業務信息混亂、應用無法與文檔對齊、知識傳遞成本、維護成本和迭代成本大大增加等問題。重構後，應用與知識庫相對應，保證一個應用只對應一份文檔，且應用統一要求在一份文檔上進行迭代，從根源上改變應用支持流程。同時，針對核心業務細節和所支撐的數據信息，進行了全局調研並歸納到知識庫。綜合統一的知識庫，降低了知識傳遞、理解、維護和迭代成本。
統一歸口策略包含業務歸口統一、設計歸口統一和應用歸口統一，從底層保證了數倉建設的三特性和三效果。
統一數據出口
數倉建設不僅僅是爲了數據內容而建設，同時也爲了提高交付的數據質量與數據使用的便利性。如何保證數據質量以及推廣數據的使用，我們提出了統一數據出口策略。在進行數據資產管理和統一數據出口之前，必須高質量地保障輸出的數據質量，從而樹立OneData數據服務體系的權威性。
1. 交付標準化
如何保證數據質量，滿足什麼樣的數據纔是可交付的，是數據建設者一直探索的問題。爲了保證交付的嚴謹性，在具體化測試方案之前，我們結合數倉的特點明確了數據交付標準的五個特性，如下圖所示：
《交付標準化》完善了整個交付細節，從根本上保證了數據的質量，如：業務測試保障數據的合理性、一致性；技術測試保障數據的唯一性、準確性；數據平臺的穩定性和後期人工維護保障數據的及時性。
2. 數據資產管理
針對如何解決數據質量中維度與指標一致性以及如何提高數據易用性的問題，我們提出數據資產的概念，藉助公司內部平臺工具“起源數據平臺”實現了整個數據資產管理，它的功能如下圖所示：
借用起源數據平臺，我們實現了：
統一指標管理，保證了指標定義、計算口徑、數據來源的一致性。
統一維度管理，保證了維度定義、維度值的一致性。
統一數據出口，實現了維度和指標元數據信息的唯一出口，維值和指標數據的唯一出口。
通過交付標準化和數據資產管理，保證了數據質量與數據的易用性，同時我們也構建出OneData數據體系中數據指標管理的核心。
實踐的成果
流程改善
我們對開發過程進行梳理，服務於整個OneData體系。對需求分析、指標管理、模型設計、數據驗證進行了改善，並結合OneData模型策略，改善了數倉管理流程。
數倉全景圖
基於OneData主題建設，我們採用面向業務、面向分析的建設策略，形成數倉全景圖，如下圖所示：
資產管理列表
基於起源數據平臺形成的資產管理體系，如下圖所示：
項目收益
基於OneData建設成果，我們結合實際項目建設樣例，對比以前未進行OneData建設時的收益。如下圖所示：
總結和展望
我們結合了OneData核心思想與特點，構建一種穩定、可靠的基礎數據倉庫，從底層保障了數據質量，同時完成OneData實踐，形成自有的OneData理論體系。
未來，我們還將在技術上引入實時數據倉庫，滿足靈活多樣、低延時的數據需求；在業務層面會橫向拓展其他業務領域，不間斷地支撐核心業務的決策與分析。下一步，我們將爲企業級One Entity數據中臺（以Data As a Service爲理念），提供強有力的數據支撐。在後續數倉維護過程中，不斷地發現問題、解決問題和總結問題，保障數據穩定性、一致性和有效性，爲核心業務構建價值鏈，最終形成企業級的數據資產。
作者簡介
祿平，周成，黃浪，健平，高謙，美團數據研發工程師。
---------- END ----------
招聘信息
美團點評餐飲生態收銀數據團隊誠招數據算法專家，數據倉庫專家，Base北京、成都。我們致力於構建中國餐飲行業數據中臺，協同餐飲B端業務和C端業務雙平臺聯動發展，推動餐飲行業向自動化和智能化邁進。歡迎有興趣的同學投送簡歷到 [email protected]（郵件標題註明：美團點評餐飲生態收銀數據團隊）。
也許你還想看
