數倉規范詳解文檔（1）

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

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

• 接到了一個需求，不知道該從那張表出數，表A貌似可以，表B好像也行。問了同事甲，他說他每次都是從C表出的。對著三張表探索了好久，發現誰跟誰都對不上，算了吧，我從源頭再算一次吧，結果又變出來一張表D。
• 數據庫里幾千張表，好像我用到的也就那么十幾張，其它的都是干啥用的呢，問了一圈沒有人知道，刪掉吧？更沒有人敢動。
• 有個流程報錯了，領導讓我去看一下，點進去后，屎一樣的代碼完全看不懂，另外，找了好久死活找不到上游依賴。
• 有位同事要離職，他負責的那部分內容，換了一個人接手，累死累活好多天依然捋不出個所以然，一氣之下又走了一個人。

由于以上種種問題，造成數倉團隊的整體開發效率、產出質量、工作幸福感、數倉維護成本等等越來越差。隨著人員流動，通常受累的往往是那些任勞任怨、對公司忠誠的員工。
相信做過數據開發的人，多多少少都會有過上邊提到的部分苦惱。我覺得問題的根源通常在于沒有規范或者規范沒有得到貫徹。大家有時候為了按時完成業務側的需求，走些捷徑也是可以理解的，但是欠下的技術債應該盡早還上，并且組織不應該苛責員工，這個鍋應該領導來背。領導重視大家就都重視，領導不重視，豈不各個放飛自我了？
數據倉庫，是我們數據工程師的無形產品。數據規范是數倉體系建設的"語言"，是數據使用的說明書和翻譯官，同時也是數據質量的保駕護航者。為了數據體系能夠長久健康的發展，數倉管理，應該從人治逐步轉變到制度化、規范化、工具化的道路上了來。

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

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

定稿后，規范已經具備了全面推廣的條件，可以下發所有團隊成員。

• 可以通過群聊天，也可以通過正式回郵件的方式，當然為了引起大家的重視，可以專門組會宣講。
• 分發宣講后進入執行階段，所有人必須嚴格遵守，如有違犯給予警告，嚴重的給予懲罰，屢勸不改的取消年終調級調薪等。

為了確保規范的貫徹落實，除了通過以上兩點引起全員重視外，還需要組織、制度、流程上的多方面保障。

• 數據模型應該有統一歸口，比如數據架構師，架構師定期檢查模型是否合理合規。
• 組織數據開發人員，定期 Review 每個人的代碼，但不必針對個人更不要上綱上線，目的是通過對比和討論讓大家明白什么樣的才是好代碼，最終使“寫好代碼”成為基本素養。沒有條件的話就有 Leader 負責定期檢查，有問題的私下指出來幫助組員逐漸規范。
• 入職新人，熟讀規范后，還應該安排專人指導，是合規性檢查的重點關注對象。

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

發行稿，從大面上應該不會有啥問題，但細節上可能會有考慮不周的情況，在宣講階段、執行階段遇到問題阻礙的時候，應該根據實際情況對規范做出調整，唯有經過實踐檢驗才能愈發完善，相信經過一段時間的持續實踐，規范會成為組織文化的一部分，進而降低溝通成本、提高開發效率、保證交付質量，從而實現團隊和個人的雙贏。

為了讓大家了解到數倉規范全貌，特意花大力氣整理出以上分類。歡迎大家推廣普及運用。由于只是一家之言，大家如有不同的見解、更好的方案或者有可以再補充的，歡迎關注我們一起進步。
這里，我把數倉規范，一共分為四大類：設計規范、流程規范、質量管理規范、安全規范。
設計規范，又劃分為四部分：數據模型設計、命名規范、指標體系設計、詞根庫。
流程規范，主要是從數倉管理的角度，對數倉場景下的各種流程進行約束。核心流程一共提煉出來五類：需求提交、模型設計、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 等。