為什么是臟活、累活？

1. 源數據

煙囪式開發：

業務繁多、數據庫多而亂，系統與系統之間錯綜復雜

數據庫種類：

架構經歷多次變遷，切換不完全，需要從Mysql、oracle、hbase甚至excle表中跨庫、跨實例、跨種類才能獲得有效業務數據

數據結構混亂：

同一字段，類型、命名都不一致

文檔缺失：

無數據庫文檔或文檔陳舊

2. 變遷

系統版本升級：

每一次升級都只是掩蓋之前的錯誤，數據治理需要從源頭

人員變更：

梳理過程中的大部分問題最終答案：

“不清楚，原來維護人已離職”

數據流轉：

數據從源頭經過很多次不規范的同步

3. 存量

各自為政：

各業務部門已有自己的統計邏輯和報表，同一指標匯總維度又不一致，梳理、治理、輸出還要盡量不影響已有報表結果

半途而廢：

前任都知道數據治理、統一出口的重要性，但只完成一部分就放棄了。

問題在于“完成的一部分”有人還在用

怎么開始？ 1. 方法論

統一定義：

對個性化的數據指標統一規范定義

標準建模：

建立數據公共層對模型架構進行標準規范設計和管理

規范研發：

將建模方法體系貫穿在整個數據研發流程

工具保障：

通過研發一系列的工具保障方法體系的落地實施

2. 統一方法策略：統一歸口、統一出口 圖片來源：阿里巴巴 OneData3. 統一業務歸口

1.模型

規范化模型分層、數據流向和主題劃分，從而降低研發成本，增強指標復用性，并提高業務的支撐能力。

2.規范

規范是數倉建設的保障。為了避免出現指標重復建設和數據字段難以理解的情況

(1)詞根

詞根是維度和指標管理的基礎，劃分為普通詞根與專有詞根，提高詞根的易用性和關聯性。

普通詞根：

描述事物的最小單元體

專有詞根：

具備約定成俗或行業專屬的描述體，如：

-USD。

(2) 表命名規范

通用規范

表名、字段名采用一個下劃線分隔詞根（示例：clienttype->client_type）。

每部分使用小寫英文單詞，屬于通用字段的必須滿足通用字段信息的定義。

表名、字段名需以字母為開頭

表名、字段名最長不超過64個英文字符。

優先使用詞根中已有關鍵字（數倉標準配置中的詞根管理)

在表名自定義部分禁止采用非標準的縮寫

表命名規則

表名稱 = 所處分層 + 業務主題 + 子主題 + 表含義 + 更新頻率 + [分表：_0、_10]

(3) 指標命名規范

結合指標的特性以及詞根管理規范，將指標進行結構化處理。

A. 基礎指標詞根，即所有指標必須包含以下基礎詞根：

基礎指標詞根	英文全稱	Hive數據類型	MySQL數據類型	長度	精度	詞根	樣例
數量	count	Bigint	Bigint	10	0	cnt
金額類	amout	Decimal	Decimal	20	4	amt
比率/占比	ratio	Decimal	Decimal	10	4	ratio	0.9818

B.日期修飾詞，用于修飾業務發生的時間區間。

日期類型	全稱	詞根	備注
日	daily	d
周	weekly	w
月	monthy	m
季度	quarterly	q	Q1 ~ Q4

C.聚合修飾詞，對結果進行聚集操作。

聚合類型	全稱	詞根	備注
平均	average	avg
周累計	wtd	wtd

E.基礎指標，單一的業務修飾詞 + 基礎指標詞根構建基礎指標 ，例如：交易金額 - trade_amt

F.派生指標，多修飾詞+基礎指標詞根構建派生指標。派生指標繼承基礎指標的特性，例如：新增門店數量-new_store_cnt

(4) 清洗規范

確認了字段命名和指標命名之后，根據指標與字段的部分特性，我們整理出了整個數倉可預知的24條清洗規范：

數據類型	數據類別	Hive類型	MySQL類型	長度	精度	詞根	格式說明	備注
日期類型	字符日期類	string	varchar	10		date	YYYY-MM-DD	日期清洗為相應的格式
數據類型	數量類	bigint	bigint	10	0	cnt	活躍門店

3. 統一數據出口

數倉建設保證數據質量以及數據的使用，對數據資產管理和統一數據出口之前：

統一指標管理，保證了指標定義、計算口徑、數據來源的一致性

統一維度管理，保證了維度定義、維度值的一致性

統一數據出口，實現了維度和指標元數據信息的唯一出口，維值和指標數據的唯一出口

4. 數據資產沉淀 圖片來源：阿里巴巴 OneData

詞根、命名歸檔

指標定義說明、指標樹歸檔

維度、維度樹、數據類型

計算邏輯統一，如：

利潤、成本等形成標準計算公式

5. 流程改善 建立運維監控體系 開發流程(僅包含數據模型及 ETL )，關鍵節點維度、指標及計算邏輯確定 開發流程

6.?標準化規范化數據流向

避免大量的煙囪式開發、重復生成明細表或輕度匯總表、分層引用等不規范性及數據鏈路混亂

標準化數據流向圖

標準的數據流向進行開發：

即ODS–>DWD–>DWS–>APP 或 ODS–>DWD–>DWM–>APP

新業務數據流：

遵循ODS->DWD->APP或者ODS->DWD->DWS->APP兩個模型數據流