導讀：規范約束的是數倉建設的全流程，以及后續的迭代和運維。事實上，數倉規范文檔，應該隨著架構設計文檔，在數倉開發啟動之前，分發給所有相關人員，且是所有人都必須嚴格遵守的約定。

俗話說的好，無規矩不成方圓，沒有規范豈不亂套了? 個人覺得，規范是為了解決團體作戰中的效率和協同問題，是對最終交付質量的有力保證。大家工作中有沒有遇到類似的問題？

接到了一個需求，不知道該從那張表出數，表A貌似可以，表B好像也行。問了同事甲，他說他每次都是從C表出的。對著三張表探索了好久，發現誰跟誰都對不上，算了吧，我從源頭再算一次吧，結果又變出來一張表D。

數據庫里幾千張表，好像我用到的也就那么十幾張，其它的都是干啥用的呢，問了一圈沒有人知道，刪掉吧？更沒有人敢動。 有個流程報錯了，領導讓我去看一下，點進去后，屎一樣的代碼完全看不懂，另外，找了好久死活找不到上游依賴。 有位同事要離職，他負責的那部分內容，換了一個人接手，累死累活好多天依然捋不出個所以然，一氣之下又走了一個人。 由于以上種種問題，造成數倉團隊的整體開發效率、產出質量、工作幸福感、數倉維護成本等等越來越差。隨著人員流動，通常受累的往往是那些任勞任怨、對公司忠誠的員工。相信做過數據開發的人，多多少少都會有過上邊提到的部分苦惱。我覺得問題的根源通常在于沒有規范或者規范沒有得到貫徹。大家有時候為了按時完成業務側的需求，走些捷徑也是可以理解的，但是欠下的技術債應該盡早還上，并且組織不應該苛責員工，這個鍋應該領導來背。領導重視大家就都重視，領導不重視，豈不各個放飛自我了？數據倉庫，是我們數據工程師的無形產品。數據規范是數倉體系建設的'語言'，是數據使用的說明書和翻譯官，同時也是數據質量的保駕護航者。為了數據體系能夠長久健康的發展，數倉管理，應該從人治逐步轉變到制度化、規范化、工具化的道路上了來。

1、規范制定

從 0 到 1，從無到有，這個環節應該有 Leader 或架構師，充分考慮公司實際情況，參考行業標準或約定俗成的規范，綜合統一制定。也可以將規范拆分后交由各個部分核心開發人員編寫， Leader 或架構師統一整合。比如我們之前的團隊就是，模型設計師負責模型設計規范，ETL 工程師負責 ETL 開發規范，BI 開發人員制定前端開發規范，部署上線規范直接采用項目上已有的即可?？傮w上，初稿應該盡量保證規范的完整性和各個部分間的兼容性。

2、規范討論?

初稿完成后，難免有考慮不周的情況，這時候最好有 Leader ?牽頭，組織部分核心成員（人數不易太多，三五個即可。人多容易造成混亂、決策困難、沒有人提意見造成 Leader 一言堂等等問題。）進一步完善各個細節，糾正初稿的不足。多人共同完善的規范，理論上來講不會有什么大問題了。

3、規范推行?

定稿后，規范已經具備了全面推廣的條件，可以下發所有團隊成員。 可以通過群聊天，也可以通過正式回郵件的方式，當然為了引起大家的重視，可以專門組會宣講。 分發宣講后進入執行階段，所有人必須嚴格遵守，如有違犯給予警告，嚴重的給予懲罰，屢勸不改的取消年終調級調薪等。 為了確保規范的貫徹落實，除了通過以上兩點引起全員重視外，還需要組織、制度、流程上的多方面保障。 數據模型應該有統一歸口，比如數據架構師，架構師定期檢查模型是否合理合規。 組織數據開發人員，定期 Review 每個人的代碼，但不必針對個人更不要上綱上線，目的是通過對比和討論讓大家明白什么樣的才是好代碼，最終使“寫好代碼”成為基本素養。沒有條件的話就有 Leader 負責定期檢查，有問題的私下指出來幫助組員逐漸規范。 入職新人，熟讀規范后，還應該安排專人指導，是合規性檢查的重點關注對象。?

4、規范的執行監督?

規范的執行監督，上邊提到的，更多是依靠制度流程以及相關人的自覺性，制度流程又依賴于人。這會帶來如下幾個問題：短期堅持還好，但長期的專注很難。有時候人忙起來了，快速產出和規范該選哪個？代碼 Review 還要不要做？新建的表要不要找數據架構師審核？數據建模最好是有專門的人或者小團隊去做，其他人使用，這往往會影響整體效率，所以通常都是誰用誰建，但撒出去后再想靠人去檢查合規性，真的就太難了。有條件的最好引入相應的工具加強監管。比如，我們有指標體系元數據、有詞根庫元數據、有建表的元數據、有 ETL 流程的元數據等等。那我們是否可以開發部分報表或其它頁面，通過 UI 輔助人去檢查，或者通過校驗元數據的方法去監管（比如備注是否為空、字段或表命名里的詞根是否都在詞根庫里存在、表或頁面等用到的指標是否都存在于指標體系、數據血緣中是否存在閉環或者孤立的節點）。

5、規范完善?

發行稿，從大面上應該不會有啥問題，但細節上可能會有考慮不周的情況，在宣講階段、執行階段遇到問題阻礙的時候，應該根據實際情況對規范做出調整，唯有經過實踐檢驗才能愈發完善，相信經過一段時間的持續實踐，規范會成為組織文化的一部分，進而降低溝通成本、提高開發效率、保證交付質量，從而實現團隊和個人的雙贏。為了讓大家了解到數倉規范全貌，特意花大力氣整理出以上分類。歡迎大家推廣普及運用。由于只是一家之言，大家如有不同的見解、更好的方案或者有可以再補充的，歡迎關注我們一起進步。

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

數據模型設計、命名規范、指標體系設計、詞根庫。流程規范，主要是從數倉管理的角度，對數倉場景下的各種流程進行約束。核心流程一共提煉出來五類：需求提交、模型設計、ETL開發、前端開發、上線流程。

質量管控規范，之所以單獨列出來，是因為數據質量，跟模型設計一樣，對數倉建設的成敗關系極大。試想下，一個數據質量都無法保證的數據倉庫，有誰會用? ?數據質量規范，主要是從數據流動的角度分為三類：源端管控、數倉管理、應用管控。

安全規范，隨著國家、社會、企業對數據的越來越重視，另一方面隨著互聯網的普及使得個人隱私變的越來越難以保證，數據泄露時有發生。數據安全對于數據倉庫的重要程度急速提升，所以安全規范被單列了出來。從大的層面上安全規范分為三類：網絡安全、賬號安全、數據安全。

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 等。

2、命名規范 統一規范?

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

3、代碼設計規范

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

4、指標體系建設?

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

05 流程規范

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

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

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

3、ETL開發流程 需求理解 數據探查 程序開發 流程依賴 配置調度 前端開發規范 接口規范 代碼部署規范?

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

上線支持團隊就緒

嚴格按照上線操作步驟執行

失敗回滾

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

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

3、應用管控 統一指標定義 統一指標口徑 統一外部數據輸出歸口

網絡安全

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

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

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

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

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

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