數倉規範詳解

一、設計規範

1.1 數據模型設計

橫向分層

分層設計是數據架構設計的產出之一，在模型設計環節做爲強制規範遵守。

分層規範

ODS：

貼源層，原始數據不做變化或者僅做最簡單的補全後存入。
數據域劃分，依據是數據源。

DWD：

對數據源做清洗、轉換、補全、編碼轉換後加載到明細數據層。
數據域劃分，依據參考下邊的縱向分域。

DWS

彙總數據層+主題寬表
數據域劃分，依據參考下邊的縱向分域

ADS：

應用層，面向最終應用。
主題域劃分，依據是最終應用。生命週期也與應用同步。

層次調用規範

禁止反向調用
ODS 只能被 DWD 調用。
DWD 可以被 DWS 和 ADS 調用。
DWS 只能被 ADS 調用。
數據應用可以調用 DWD、DWS、ADS，但建議優先考慮使用匯總度高的數據。
ODS->DWD->DWS>ADS
ODS->DWD->ADS 縱向分域

縱向分域

主題域通常是聯繫較爲緊密的數據主題的集合，方便尋找和使用數據。

基本原則

高內聚、低耦合。
數量不能太多。建議不超過十個。
必須保持穩定。既能涵蓋當前所有的業務需求，又能在新業務進入時無影響地被包含進已有的數據域中或擴展新的數據域。
需要結合團隊和業務的實際情況，比如業務是否穩定、團隊成員建模水平等。
適度的抽象。太低不好適應變化，太高不易於理解使用。

分類

數據/業務主題域：依據業務流程劃分，實現相對容易。
分析主題域：面向分析場景，實現較難，對業務理解、抽象能力等要求高。

劃分依據

按照業務或業務過程劃分：比如一個靠銷售廣告位置的門戶網站主題域可能會有廣告域，客戶域等，而廣告域可能就會有廣告的庫存，銷售分析、內部投放分析等主題。
根據需求方劃分：比如需求方爲財務部，就可以設定對應的財務主題域，而財務主題域裏面可能就會有員工工資分析，投資回報比分析等主題。
按照功能或應用劃分：比如微信中的朋友圈數據域、羣聊數據域等，而朋友圈數據域可能就會有用戶動態信息主題、廣告主題等。
按照部門劃分：比如可能會有運營域、技術域等，運營域中可能會有工資支出分析、活動宣傳效果分析等主題。

基本原則

高內聚和低耦合
核心模型與擴展模型分離
公共處理邏輯下沉及單一
成本與性能平衡
數據可回滾
一致性
命名清晰、可理解

附加字段

維表：創建時間、更新時間
事實表：ETL 日期、更新時間其它要求

其他要求

表、字段的備註信息，必須言簡意賅，在描述清楚的前提下儘量簡潔。
字段類型的約束：比如字符串用 String，數值用 Int，年月日都用 String 比如 yyyyMMdd 等

1.2 ETL設計規範

抽取加載策略設計文檔

節點名稱，與目標表一致
負責人
源表、目標表
抽取方式、加載策略
增量新增數據的判斷條件
是否支持重複執行

ETL 映射設計文檔

節點名稱，與目標表一致
所在層級、所屬 Job
Job 中的位置、上游節點名稱
負責人
參數列表
源表、目標表
字段映射轉換關係
是否支持重複執行

調度設計文檔

頂層調度有幾個？
頂層 Job 調度時機
頂層調度參數列表
每個 Job 內的任務調度順序編排
調度是否支持重複執行
調度是否支持並行

1.3 命名規範

共有規範

採用蛇形命名法，即採用一個下劃線分隔詞根
優先使用詞根中已有關鍵字（數倉標準配置中的詞根管理），定期 Review 新增命名的不合理性
禁止採用非標準的縮寫
命名一律採用小寫，只能以字母開頭
命名不宜過長

專有規範

表
- 分層-分域-分詞根-分時間週期
- 正式表，所在層級名稱+數據域+表描述+時間週期或加載策略，如增量、快照、拉鍊/小時、日、周、月、季、年
- 中間表,對應正式表+mid+阿拉伯數字
- 臨時表，z+創建者姓名檢查+表名
視圖
- 參照表命名規範+_v
字段
- 優先從詞根中取，多次出現的要增加到詞根庫
任務
- 與目標表名相同
指標
- 原子指標：業務修飾詞 + 詞根
- 衍生指標：原子指標+時間週期（可選）
- 派生指標：一個原子指標＋多個修飾詞（可選）＋時間週期

1.4 指標體系建設

指標層級劃分方式

按分析主題

一級分類
二級分類

按業務過程

一級分類
二級分類
三級分類

指標定義

內容

所屬分類
指標類別
名稱
描述
口徑/算法
計量單位
適用維度
...

原則

唯一性
可擴展
易理解

類別

原子指標（某一業務事件行爲下的度量，不可再拆分的指標）例如：訂單金額
衍生指標（對原子指標進行四則運算）
派生指標（統計週期+統計粒度+業務限定+原子/衍生指標）例如：最近一天+新創建的+訂單個數（阿里大數據之路對於派生指標的定義：派生指標=原子指標+時間週期修飾詞+其它修飾詞。唯一歸屬於某一個原子指標，繼承該原子指標的數據域。）

說明

網上對於指標分類說法不統一，大家知道咋回事兒就行了。
搜了一下阿里的大數據之路，沒有衍生指標的概念。
說法一：衍生指標=派生指標。那麼用我上邊派生指標的定義即可。
說法二：衍生指標是對原子指標進行四則運算得到的。
那麼衍生指標就是原子指標增加減少幾個修飾詞或者時間週期擴大縮小後得到的。所以感覺衍生指標有點雞肋搞不好就變成原子/派生指標了。

指標管理流程

指標新增申請
初審：明確指標口徑，檢查指標庫是否包含
二審：審覈指標定義需要的各項元素是否準確完備
入指標庫

1.5 詞根庫

定義

把可能會多次用到的短語，集中命名，保證全局範圍內的命名含義一致性。

內容

所屬分類
名稱
英文簡稱
數據類型
備註

公共字段

公共字段=詞根組合+其它關鍵詞
公共字段放入詞根庫不太嚴謹，但字段命名時候可以直接取用，降低了命名不一致的風險，所以工具化不太完善的公司推薦這樣使用。

二、流程規範

2.1 需求提交流程

提出需求

需求提出人：以文檔的形式提出需求（寫清楚需求內容、交付物、期望交付日期），發給數倉 Leader。

溝通需求

數倉 Leader 將需求分配給相關人承接，同時協商好實際交付日期。
如果需求提出人的交付日期與數倉 Leader 的交付日期不一致，雙方需要進一步協商一致。

開發交付

需求承接人，需按照協商一致的交付日期，按期交付。

2.2 模型設計流程

數據調研、業務調研、需求調研

數據建模

總體思路
- 根據已有的分層分域，分治、各個擊破。
多種方式結合使用
- 確定業務過程->聲明粒度->確定維度->確定事實
- 業務建模->邏輯建模->物理建模
- 構建總線矩陣
- 構建指標體系

評審

除了模型設計，還需要拉上必要的開發、業務、分析師、產品經理、數倉運維等。

上線、迭代、完善

2.3 ETL開發流程

需求理解

數據探查

程序開發

命名規範
- Job 命名規範：J_層次名_內容描述。
- 節點命名規範：跟目標表一致。
- 參數命名規範：統一命名，禁止私自創造。
代碼編寫原則
- 代碼清晰、整齊，具有一定的可觀賞性。
- 代碼編寫要充分考慮執行速度最優原則。
- 代碼行整體層次分明、結構化強。
- 代碼中應有必要的註釋以增強代碼的可讀性。
- 規範要求非強制性地約束代碼開發人員的代碼編寫行爲。在實際應用中，只要不違反常規要求，允許存在可理解的偏差。
代碼開發規範
- 腳本是否有備註、複雜計算邏輯是否有註釋。
- 任務是否支持多次重跑而輸出不變，不能有 insert into 語句。
- 分區表是否使用分區鍵過濾並且有有效裁剪。
- 外連接的過濾條件是否使用正確，例如在左連接的 where 語句存在右表的過濾條件。
- 關聯小表，是否使用/*+ map join * /。
- 不允許引用別的計算任務臨時表。
- 原則上不允許存在一個任務更新多個目標表。
- 是否存在笛卡爾積。
- 禁止在代碼裏面使用 drop、create、rename 等 DDL 語句。
- 使用動態分區時，有沒有檢查分區鍵值爲 NULL 的情況。
- 對於重要的任務 DQC 質量監控規則是否配置，嚴禁裸奔。
- 代碼中有沒有進行適當的規避數據傾斜語句。
日誌輸出規範
- 每個任務節點，都需要輸出成功/失敗標誌，如果失敗最好輸出錯誤信息。
- 每個 Job 也要輸出成功/失敗標誌，如果失敗必須輸出失敗任務節點名稱。

流程依賴

配置調度

2.4 前端開發規範

接口規範
代碼部署規範

2.5 上線流程

申請

上線時間
上線功能範圍
對其它模塊、上下游依賴的影響
上線支持團隊清單
上線詳細操作步驟
測試報告
回滾方案

評審

代碼 Review
上下游影響分析

上線

上線支持團隊就緒
嚴格按照上線操作步驟執行
失敗回滾

三、質量管控規範

3.1 源端管控

源端變動，必須提前通知數倉側。
有條件的話，使用工具監控源端重點內容的變動。

3.2 數倉管理

對已有規範沒有貫徹的給予警告、處罰：建模規範、開發規範、上線規範
使用工具加強數據質量監控，發現問題及時通知、告警。
建立數據質量解決機制，責任到人。
定期覆盤
- 重要常見問題入告警規則
- 源端數據質量問題，協調源端解決
- 存儲模型、ETL開發、上線流程等引起的問題，需要制定合適的解決方案

3.3 應用管控

統一指標定義
統一指標口徑
統一外部數據輸出歸口

四、安全規範

4.1 網絡安全

內外網隔離，外網環境訪問內網需要登錄 VPN
核心數據存儲、功能模塊，只開放給特定的少部分人。

4.2 賬號安全

每個人分配獨立的賬號，賦予合理的權限，禁止相互借用。
數據庫、大數據組件開通多個角色賬號。比如只讀、部分表讀寫、管理員等。當然還可以按實際需求細分。Hive、ODPS 的話也是可以實現單人單號的。
服務器登錄。也是單人單號
公司內部應用賬號。單人單號。

4.3 數據安全

至少做到表級別的權限控制，實在不行就分庫。
ODS 層不對外開放，只對 ODS-DWD 層相關部分開發人員可見。
特別敏感數據，如用戶年齡、號碼、身份證好、地址等，應該放到專門的數據庫裏，數倉主庫只存放用戶 ID 和其它必須字段。例如年齡應該脫敏成年齡區間或開發特定的 UDF 轉化函數。