數(shù)倉規(guī)范詳解文檔（1）

規(guī)范約束的是數(shù)倉建設(shè)的全流程，以及后續(xù)的迭代和運(yùn)維。事實(shí)上，數(shù)倉規(guī)范文檔，應(yīng)該隨著架構(gòu)設(shè)計(jì)文檔，在數(shù)倉開發(fā)啟動(dòng)之前，分發(fā)給所有相關(guān)人員，且是所有人都必須嚴(yán)格遵守的約定。

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

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

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

從 0 到 1，從無到有，這個(gè)環(huán)節(jié)應(yīng)該有 Leader 或架構(gòu)師，充分考慮公司實(shí)際情況，參考行業(yè)標(biāo)準(zhǔn)或約定俗成的規(guī)范，綜合統(tǒng)一制定。
也可以將規(guī)范拆分后交由各個(gè)部分核心開發(fā)人員編寫， Leader 或架構(gòu)師統(tǒng)一整合。比如我們之前的團(tuán)隊(duì)就是，模型設(shè)計(jì)師負(fù)責(zé)模型設(shè)計(jì)規(guī)范，ETL 工程師負(fù)責(zé) ETL 開發(fā)規(guī)范，BI 開發(fā)人員制定前端開發(fā)規(guī)范，部署上線規(guī)范直接采用項(xiàng)目上已有的即可。
總體上，初稿應(yīng)該盡量保證規(guī)范的完整性和各個(gè)部分間的兼容性。

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

定稿后，規(guī)范已經(jīng)具備了全面推廣的條件，可以下發(fā)所有團(tuán)隊(duì)成員。

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

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

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

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

發(fā)行稿，從大面上應(yīng)該不會(huì)有啥問題，但細(xì)節(jié)上可能會(huì)有考慮不周的情況，在宣講階段、執(zhí)行階段遇到問題阻礙的時(shí)候，應(yīng)該根據(jù)實(shí)際情況對(duì)規(guī)范做出調(diào)整，唯有經(jīng)過實(shí)踐檢驗(yàn)才能愈發(fā)完善，相信經(jīng)過一段時(shí)間的持續(xù)實(shí)踐，規(guī)范會(huì)成為組織文化的一部分，進(jìn)而降低溝通成本、提高開發(fā)效率、保證交付質(zhì)量，從而實(shí)現(xiàn)團(tuán)隊(duì)和個(gè)人的雙贏。

為了讓大家了解到數(shù)倉規(guī)范全貌，特意花大力氣整理出以上分類。歡迎大家推廣普及運(yùn)用。由于只是一家之言，大家如有不同的見解、更好的方案或者有可以再補(bǔ)充的，歡迎關(guān)注我們一起進(jìn)步。
這里，我把數(shù)倉規(guī)范，一共分為四大類：設(shè)計(jì)規(guī)范、流程規(guī)范、質(zhì)量管理規(guī)范、安全規(guī)范。
設(shè)計(jì)規(guī)范，又劃分為四部分：數(shù)據(jù)模型設(shè)計(jì)、命名規(guī)范、指標(biāo)體系設(shè)計(jì)、詞根庫。
流程規(guī)范，主要是從數(shù)倉管理的角度，對(duì)數(shù)倉場(chǎng)景下的各種流程進(jìn)行約束。核心流程一共提煉出來五類：需求提交、模型設(shè)計(jì)、ETL開發(fā)、前端開發(fā)、上線流程。
質(zhì)量管控規(guī)范，之所以單獨(dú)列出來，是因?yàn)閿?shù)據(jù)質(zhì)量，跟模型設(shè)計(jì)一樣，對(duì)數(shù)倉建設(shè)的成敗關(guān)系極大。試想下，一個(gè)數(shù)據(jù)質(zhì)量都無法保證的數(shù)據(jù)倉庫，有誰會(huì)用?  數(shù)據(jù)質(zhì)量規(guī)范，主要是從數(shù)據(jù)流動(dòng)的角度分為三類：源端管控、數(shù)倉管理、應(yīng)用管控。
安全規(guī)范，隨著國家、社會(huì)、企業(yè)對(duì)數(shù)據(jù)的越來越重視，另一方面隨著互聯(lián)網(wǎng)的普及使得個(gè)人隱私變的越來越難以保證，數(shù)據(jù)泄露時(shí)有發(fā)生。數(shù)據(jù)安全對(duì)于數(shù)據(jù)倉庫的重要程度急速提升，所以安全規(guī)范被單列了出來。從大的層面上安全規(guī)范分為三類：網(wǎng)絡(luò)安全、賬號(hào)安全、數(shù)據(jù)安全。

橫向分層

• 說明
• 分層設(shè)計(jì)是數(shù)據(jù)架構(gòu)設(shè)計(jì)的產(chǎn)出之一，在模型設(shè)計(jì)環(huán)節(jié)做為強(qiáng)制規(guī)范遵守。
• 分層規(guī)范
• 應(yīng)用層，面向最終應(yīng)用。
• 主題域劃分，依據(jù)是最終應(yīng)用。生命周期也與應(yīng)用同步。
• 匯總數(shù)據(jù)層+主題寬表。
• 數(shù)據(jù)域劃分，依據(jù)參考下邊的縱向分域。
• 對(duì)數(shù)據(jù)源做清洗、轉(zhuǎn)換、補(bǔ)全、編碼轉(zhuǎn)換后加載到明細(xì)數(shù)據(jù)層。
• 數(shù)據(jù)域劃分，依據(jù)參考下邊的縱向分域。
• 貼源層，原始數(shù)據(jù)不做變化或者僅做最簡單的補(bǔ)全后存入。
• 數(shù)據(jù)域劃分，依據(jù)是數(shù)據(jù)源。
• ODS
• DWD
• DWS
• ADS
• 層次調(diào)用規(guī)范
• 禁止反向調(diào)用
• ODS 只能被 DWD 調(diào)用。
• DWD 可以被 DWS 和 ADS 調(diào)用。
• DWS 只能被 ADS 調(diào)用。
• 數(shù)據(jù)應(yīng)用可以調(diào)用 DWD、DWS、ADS，但建議優(yōu)先考慮使用匯總度高的數(shù)據(jù)。
• ODS->DWD->DWS>ADS
• ODS->DWD->ADS
  
縱向分域

• 定義
• 主題域通常是聯(lián)系較為緊密的數(shù)據(jù)主題的集合，方便尋找和使用數(shù)據(jù)。
• 基本原則
• 高內(nèi)聚、低耦合。
• 數(shù)量不能太多。建議不超過十個(gè)。
• 必須保持穩(wěn)定。既能涵蓋當(dāng) 前所有的業(yè)務(wù)需求，又能在新業(yè)務(wù)進(jìn)入時(shí)無影響地被包含進(jìn)已有的數(shù)據(jù)域中或擴(kuò)展新的數(shù)據(jù)域。
• 需要結(jié)合團(tuán)隊(duì)和業(yè)務(wù)的實(shí)際情況，比如業(yè)務(wù)是否穩(wěn)定、團(tuán)隊(duì)成員建模水平等。
• 適度的抽象。太低不好適應(yīng)變化，太高不易于理解使用。
• 分類
• 面向分析場(chǎng)景，實(shí)現(xiàn)較難，對(duì)業(yè)務(wù)理解、抽象能力等要求高。
• 依據(jù)業(yè)務(wù)流程劃分，實(shí)現(xiàn)相對(duì)容易。
• 數(shù)據(jù)/業(yè)務(wù)主題域
• 分析主體域
• 劃分依據(jù)
• 按照業(yè)務(wù)或業(yè)務(wù)過程劃分：比如一個(gè)靠銷售廣告位置的門戶網(wǎng)站主題域可能會(huì)有廣告域，客戶域等，而廣告域可能就會(huì)有廣告的庫存，銷售分析、內(nèi)部投放分析等主題。
• 根據(jù)需求方劃分：比如需求方為財(cái)務(wù)部，就可以設(shè)定對(duì)應(yīng)的財(cái)務(wù)主題域，而財(cái)務(wù)主題域里面可能就會(huì)有員工工資分析，投資回報(bào)比分析等主題。
• 按照功能或應(yīng)用劃分：比如微信中的朋友圈數(shù)據(jù)域、群聊數(shù)據(jù)域等，而朋友圈數(shù)據(jù)域可能就會(huì)有用戶動(dòng)態(tài)信息主題、廣告主題等。
• 按照部門劃分：比如可能會(huì)有運(yùn)營域、技術(shù)域等，運(yùn)營域中可能會(huì)有工資支出分析、活動(dòng)宣傳效果分析等主題?；驹瓌t
• 高內(nèi)聚和低耦合
• 核心模型與擴(kuò)展模型分離
• 公共處理邏輯下沉及單一
• 成本與性能平衡
• 數(shù)據(jù)可回滾
• 一致性
• 命名清晰、可理解
  附加字段
• 維表：創(chuàng)建時(shí)間、更新時(shí)間
• 事實(shí)表：ETL 日期、更新時(shí)間
  其它要求
• 表、字段的備注信息，必須言簡意賅，在描述清楚的前提下盡量簡潔。
• 字段類型的約束：比如字符串用 String，數(shù)值用 Int，年月日都用 String 比如 yyyyMMdd 等。