一篇文章搞懂資料倉庫：資料倉庫規範設計

目錄

​​一、為什麼要進行規範設計？​​

​​二、設計規範 - 名額​​

​​三、命名規範 - 表命名​​

​​3.1 正常表​​

​​3.2 中間表​​

​​3.3 臨時表​​

​​3.4 次元表​​

​​四、開發規範​​

​​五、流程規範​​

一、為什麼要進行規範設計？

無規矩、不方圓。規範設計是在具體開發工作之前制定的，過程中不斷進行完善。目的在于限制N個人對齊認知，按照一個标準或流程進行開發，以保證資料一緻性，流程清晰且穩定。

一個良好的規範設計，應當起到以下作用：提高開發效率，提升品質，降低溝通對齊成本，降低運維成本等。

下面小編将帶領大家盤一盤資料倉庫有哪些規範，從中挑選幾個重點細說：

• 設計規範

            邏輯架構、技術架構、分層設計、主題劃分、方法論

•  命名規範

            各層級命名、任務命名、表命名、字段命名、名額命名等 

• 模型規範

            模組化方法、模組化工具、血緣關系、次元退化、一緻性次元、中繼資料管理

• 開發規範

            腳本注釋、字段别名、編碼規範、腳本格式、資料類型、縮寫規範 

• 流程規範

            需求流程、工程流程、上線流程、排程流、排程和表生命周期管理

二、設計規範 - 名額

• Step1：面向主題域管理

為了提高名額管理的效率，你需要按照業務線、主題域和業務過程三級目錄方式管理名額。

• Step2：劃分原子名額和派生名額

原子名額 + 原子名額  = 派生名額

• Step3：進行名額命名規範

需要遵循兩個原則：易懂與統一

• 易懂，就是看到名額的名稱，就可以基本判斷這個名額歸屬于哪個業務過程；
• 統一，就是要確定派生名額和它繼承的原子名額命名是一緻的。

對于原子名額，标名稱适合用“動作 + 度量”的命名方式（比如注冊使用者數、購買使用者數）

對于派生名額，應該嚴格遵循“時間周期 + 統計粒度 + 修飾詞 + 原子名額”的命名方式。（比如30天内黑卡會員購買使用者數）

• Step4：分級管理

名額确實是多，如果一視同仁去管理其實很難，是以可以按照下面的原則進行等級劃分：

• 一級名額：資料中台直接産出，核心名額（提供給公司高層看的）、原子名額以及跨部門的派生名額。
• 二級名額：基于中台提供的原子名額，業務部門建立的派生名額。

三、命名規範 - 表命名

3.1 正常表

正常表是我們需要固化的表，是正式使用的表，是目前一段時間内需要去維護去完善的表。

規範：分層字首[dwd|dws|ads|bi]_業務域_主題域_XXX_更新評率|全量/增量。 

業務域、主題域我們都可以用詞根的方式枚舉清楚，不斷完善，粒度也是同樣的，主要的是時間粒度、日、月、年、周等，使用詞根定義好簡稱。

例如:  dwd_xxx_xxx_da

• di ：每日增量
• da：每日全量
• mi：每月增量
• ma：每月全量

3.2 中間表

中間表一般出現在Job中，是Job中臨時存儲的中間資料的表，中間表的作用域隻限于目前Job執行過程中，Job一旦執行完成，該中間表的使命就完成了，是可以删除的（按照自己公司的場景自由選擇，以前公司會保留幾天的中間表資料，用來排查問題）。

規範：mid_table_name_[0~9|dim]

table_name是我們任務中目标表的名字，通常來說一個任務隻有一個目标表。這裡加上表名，是為了防止自由發揮的時候表名沖突，而末尾大家可以選擇自由發揮，起一些有意義的名字，或者簡單粗暴，使用數字代替，各有優劣吧，謹慎選擇。通常會遇到需要補全次元的表，這裡我喜歡使用dim結尾。中間表在建立時，請加上 ,如果要保留曆史的中間表，可以加上日期或者時間戳

3.3 臨時表

臨時表是臨時測試的表，是臨時使用一次的表，就是暫時儲存下資料看看，後續一般不再使用的表，是可以随時删除的表。

規範：tmp_xxx

隻要加上tmp開頭即可，其他名字随意，注意tmp開頭的表不要用來實際使用，隻是測試驗證而已。

3.4 次元表

次元表是基于底層資料，抽象出來的描述類的表。次元表可以自動從底層表抽象出來，也可以手工來維護。

規範：dim_xxx

次元表，統一以dim開頭，後面加上，對該名額的描述，可以自由發揮。

四、開發規範

1	表和列的注釋釋是否有缺失，複雜計算邏輯是否有注釋釋
2	任務是否支援多次重跑而輸出不變，不能有insert into語句
3	分區表是否使用分區鍵過濾并且有有效裁剪
4	外連接配接的過逑條件是否使用正确，例如在左連接配接的where語句存在右表的過濾條件
5	關聯小表，是否使用/*+ map join * / hint
6	不允許引用别的計算任務臨時表
7	原則上不允許存在一個任務更新多個目标表
8	是否存在笞、迪卡爾積
9	禁止在代碼裡面使用drop 111ble、creat它111ble、renaiue 111ble、chan零column等ddl語句
10	使用動态分區時，有沒有檢查分區鍵值為NULL的情況
11	DQC品質監控規則是否配置，嚴禁棵奔
12	代碼中有沒有進行适當的規避資料傾斜語句
13	Where條件中is null語句有沒有進行空字元串處理

五、流程規範

1. 需求階段：資料産品經理應如何應對不斷變化的業務需求。
2. 設計階段：資料産品經理、資料開發者應如何綜合性能、成本、效率、品質等因素，更好地組織與存儲資料。
3. 開發階段：資料研發者如何高效、規範地進行編碼工作。
4. 測試階段：測試人員應如何準确地暴露代碼問題與項目風險，提升産出品質。
5. 釋出階段：如何将具備釋出條件的程式平穩地釋出到線上穩定産出。
6. 運維階段：運維人員應如何保障資料産出的時效性和穩定性。