統一規范

• 采用蛇形命名法，即采用一個下劃線分隔詞根。
• 優先使用詞根中已有關鍵字（數倉標準配置中的詞根管理），- - 定期 Review 新增命名的不合理性。
• 禁止采用非標準的縮寫。
• 命名一律采用小寫，只能以字母開頭。
• 命名不宜過長。專有規范
• 表
• 分層-分域-分詞根-分時間周期
• 正式表，所在層級名稱+數據域+表描述+時間周期或加載策略，如增量、快照、拉鏈/小時、日、周、月、季、年
• 中間表,對應正式表+_mid+阿拉伯數字
• 臨時表，z+創建者姓名檢查+表名
• 視圖
• 參照表命名規范+_v
• 字段
• 優先從詞根中取，多次出現的要增加到詞根庫
• 任務
• 與目標表名相同
• 指標
• 一個原子指標＋多個修飾詞（可選）＋時間周期
• 原子指標+時間周期（可選）
• 原子指標
  業務修飾詞 + 詞根
• 衍生指標
• 派生指標

• 腳本是否有備注、復雜計算邏輯是否有注釋釋。
• 任務是否支持多次重跑而輸出不變，不能有 insert into 語句。
• 分區表是否使用分區鍵過濾并且有有效裁剪。
• 外連接的過逑條件是否使用正確，例如在左連接的 where 語句存在右表的過濾條件。
• 關聯小表，是否使用/*+ map join * /。
• 不允許引用別的計算任務臨時表。
• 原則上不允許存在一個任務更新多個目標表。
• 是否存在笛卡爾積。
• 禁止在代碼里面使用 drop、create、rename 等 DDL 語句。
• 使用動態分區時，有沒有檢查分區鍵值為 NULL 的情況。
• 對于重要的任務 DQC 質量監控規則是否配置，嚴禁裸奔。
• 代碼中有沒有進行適當的規避數據傾斜語句。

• 指標層級劃分方式
• 一級分類
• 二級分類
• 三級分類
• 一級分類
• 二級分類
• 按分析主題
• 按業務過程
• 指標定義
• 原子指標(某一業務事件行為下的度量，不可再拆分的指標) 例如：訂單金額
• 衍生指標（對原子指標進行四則運算）
• 派生指標（統計周期+統計粒度+業務限定+原子指標）例如：最近一天+新創建的+訂單個數（阿里大數據之路對于派生指標的定義：派生指標=原子指標+時間周期修飾詞+其它修飾詞。唯一歸屬于某一個原子指標，繼承原子指標的數據域）
• 唯一性
• 可擴展
• 易理解
• 所屬分類
• 指標類別
• 名稱
• 描述
• 口徑/算法
• 計量單位
• 適用維度
• ...
• 內容
• 原則
• 類別
• 說明：網上對于指標分類說法不統一，大家知道咋回事兒就行了。搜了一下阿里的大數據之路，沒有衍生指標的概念。說法一：衍生指標=派生指標。那么用我上邊派生指標的定義即可。說法二：衍生指標是對原子指標進行四則運算得到的。那么衍生指標就是原子指標增加減少幾個修飾詞或者時間周期擴大縮小后得到的。所以感覺衍生指標有點雞肋搞不好就變成原子/派生指標了。
• 指標管理流程
• 指標新增申請
• 初審：明確指標口徑，檢查指標庫是否包含
• 二審：審核指標定義需要的各項元素是否準確完備
• 入指標庫

這里，我把數倉規范，一共分為四大類：設計規范、流程規范、質量管理規范、安全規范。

設計規范，又劃分為四部分：數據模型設計、命名規范、指標體系設計、詞根庫。
流程規范，主要是從數倉管理的角度，對數倉場景下的各種流程進行約束。核心流程一共提煉出來五類：需求提交、模型設計、ETL開發、前端開發、上線流程。
質量管控規范，之所以單獨列出來，是因為數據質量，跟模型設計一樣，對數倉建設的成敗關系極大。試想下，一個數據質量都無法保證的數據倉庫，有誰會用?  數據質量規范，主要是從數據流動的角度分為三類：源端管控、數倉管理、應用管控。
安全規范，隨著國家、社會、企業對數據的越來越重視，另一方面隨著互聯網的普及使得個人隱私變的越來越難以保證，數據泄露時有發生。數據安全對于數據倉庫的重要程度急速提升，所以安全規范被單列了出來。從大的層面上安全規范分為三類：網絡安全、賬號安全、數據安全。

橫向分層

• 說明
• 分層設計是數據架構設計的產出之一，在模型設計環節做為強制規范遵守。
• 分層規范
• 應用層，面向最終應用。
• 主題域劃分，依據是最終應用。生命周期也與應用同步。
• 匯總數據層+主題寬表。
• 數據域劃分，依據參考下邊的縱向分域。
• 對數據源做清洗、轉換、補全、編碼轉換后加載到明細數據層。
• 數據域劃分，依據參考下邊的縱向分域。
• 貼源層，原始數據不做變化或者僅做最簡單的補全后存入。
• 數據域劃分，依據是數據源。
• 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 等。

統一規范

• 采用蛇形命名法，即采用一個下劃線分隔詞根。
• 優先使用詞根中已有關鍵字（數倉標準配置中的詞根管理），- - 定期 Review 新增命名的不合理性。
• 禁止采用非標準的縮寫。
• 命名一律采用小寫，只能以字母開頭。
• 命名不宜過長。專有規范
• 表
• 分層-分域-分詞根-分時間周期
• 正式表，所在層級名稱+數據域+表描述+時間周期或加載策略，如增量、快照、拉鏈/小時、日、周、月、季、年
• 中間表,對應正式表+_mid+阿拉伯數字
• 臨時表，z+創建者姓名檢查+表名
• 視圖
• 參照表命名規范+_v
• 字段
• 優先從詞根中取，多次出現的要增加到詞根庫
• 任務
• 與目標表名相同
• 指標
• 一個原子指標＋多個修飾詞（可選）＋時間周期
• 原子指標+時間周期（可選）
• 原子指標
業務修飾詞 + 詞根
• 衍生指標
• 派生指標

• 腳本是否有備注、復雜計算邏輯是否有注釋釋。
• 任務是否支持多次重跑而輸出不變，不能有 insert into 語句。
• 分區表是否使用分區鍵過濾并且有有效裁剪。
• 外連接的過逑條件是否使用正確，例如在左連接的 where 語句存在右表的過濾條件。
• 關聯小表，是否使用/*+ map join * /。
• 不允許引用別的計算任務臨時表。
• 原則上不允許存在一個任務更新多個目標表。
• 是否存在笛卡爾積。
• 禁止在代碼里面使用 drop、create、rename 等 DDL 語句。
• 使用動態分區時，有沒有檢查分區鍵值為 NULL 的情況。
• 對于重要的任務 DQC 質量監控規則是否配置，嚴禁裸奔。
• 代碼中有沒有進行適當的規避數據傾斜語句。

• 指標層級劃分方式
• 一級分類
• 二級分類
• 三級分類
• 一級分類
• 二級分類
• 按分析主題
• 按業務過程
• 指標定義
• 原子指標(某一業務事件行為下的度量，不可再拆分的指標) 例如：訂單金額
• 衍生指標（對原子指標進行四則運算）
• 派生指標（統計周期+統計粒度+業務限定+原子指標）例如：最近一天+新創建的+訂單個數（阿里大數據之路對于派生指標的定義：派生指標=原子指標+時間周期修飾詞+其它修飾詞。唯一歸屬于某一個原子指標，繼承原子指標的數據域）
• 唯一性
• 可擴展
• 易理解
• 所屬分類
• 指標類別
• 名稱
• 描述
• 口徑/算法
• 計量單位
• 適用維度
• ...
• 內容
• 原則
• 類別
• 說明：網上對于指標分類說法不統一，大家知道咋回事兒就行了。搜了一下阿里的大數據之路，沒有衍生指標的概念。說法一：衍生指標=派生指標。那么用我上邊派生指標的定義即可。說法二：衍生指標是對原子指標進行四則運算得到的。那么衍生指標就是原子指標增加減少幾個修飾詞或者時間周期擴大縮小后得到的。所以感覺衍生指標有點雞肋搞不好就變成原子/派生指標了。
• 指標管理流程
• 指標新增申請
• 初審：明確指標口徑，檢查指標庫是否包含
• 二審：審核指標定義需要的各項元素是否準確完備
• 入指標庫

• 定義
• 把可能會多次用到的短語，集中命名，保證全局范圍內的命名含義一致性。
• 內容
• 所屬分類
• 名稱
• 英文簡稱
• 數據類型
• 備注
• 分類
• 普通詞根：描述事物的最小單元體，如：交易-trade。
• 專有詞根：具備約定成俗或行業專屬的描述體，如：美元-USD。
• 公共字段

流程規范

• 公共字段=詞根組合+其它關鍵詞。

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

• 提出需求
• 需求提出人：以文檔的形式提出需求（寫清楚需求內容、交付物、期望交付日期），發給數倉 Leader。
• 溝通需求
• 數倉 Leader 將需求分配給相關人承接，同時協商好實際交付日期。
• 如果需求提出人的交付日期與數倉 Leader 的交付日期不一致，雙方需要進一步協商一致。
• 開發交付
• 需求承接人，需按照協商一致的交付日期，按期交付。

• 數據調研、業務調研、需求調研
• 數據建模
• 確定業務過程->聲明粒度->確定維度->確定事實
• 業務建模->邏輯建模->物理建模
• 構建總線矩陣
• 構建指標體系
• 根據已有的分層分域，分治、各個擊破。
• 總體思路
• 多種方式結合使用
• 評審
• 除了模型設計，還需要拉上必要的開發、業務、分析師、產品經理、數倉運維等。
• 上線、迭代、完善

• 需求理解
• 數據探查
• 程序開發
• 流程依賴
• 配置調度

• 接口規范
• 代碼部署規范

• 申請
• 上線時間
• 上線功能范圍
• 對其它模塊、上下游依賴的影響
• 上線支持團隊清單
• 上線詳細操作步驟
• 測試報告
• 回滾方案
• 評審
• 代碼 Review
• 上下游影響分析
• 上線

質量管控規范

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

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

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

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

• 內外網隔離，外網環境訪問內網需要登錄 VPN；

• 核心數據存儲、功能模塊，只開放給特定的少部分人。

• 每個人分配獨立的賬號，賦予合理的權限，禁止相互借用。

• 數據庫、大數據組件開通多個角色賬號。比如只讀、部分表讀寫、管理員等。當然還可以按實際需求細分。Hive、ODPS 的話也是可以實現單人單號的。

• 服務器登錄。也是單人單號

• 公司內部應用賬號。單人單號。

• 至少做到表級別的權限控制，實在不行就分庫。

• ODS 層不對外開放，只對 ODS-DWD 層相關部分開發人員可見。

• 特別敏感數據，如用戶年齡、號碼、身份證好、地址等，應該放到專門的數據庫里，數倉主庫只存放用戶 ID 和其它必須字段。例如年齡應該脫敏成年齡區間或開發特定的 UDF 轉化函數。

  
  

我們分別從設計規范、流程規范、質量管控、數據安全四個方面，詳細闡述了數倉規范。應該已經涵蓋了數倉規范的方方面面。