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

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

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

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

1、規(guī)范制定

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

2、規(guī)范討論?

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

3、規(guī)范推行?

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

4、規(guī)范的執(zhí)行監(jiān)督?

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

5、規(guī)范完善?

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

這里，把數(shù)倉規(guī)范一共分為四大類：設(shè)計規(guī)范、流程規(guī)范、質(zhì)量管理規(guī)范、安全規(guī)范。設(shè)計規(guī)范，又劃分為四部分：

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

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

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

1、數(shù)據(jù)模型設(shè)計 橫向分層

說明

分層設(shè)計是數(shù)據(jù)架構(gòu)設(shè)計的產(chǎn)出之一，在模型設(shè)計環(huán)節(jié)做為強制規(guī)范遵守。

分層規(guī)范

應(yīng)用層，面向最終應(yīng)用。

主題域劃分，依據(jù)是最終應(yīng)用。生命周期也與應(yīng)用同步。

匯總數(shù)據(jù)層+主題寬表。

數(shù)據(jù)域劃分，依據(jù)參考下邊的縱向分域。

對數(shù)據(jù)源做清洗、轉(zhuǎn)換、補全、編碼轉(zhuǎn)換后加載到明細數(shù)據(jù)層。

數(shù)據(jù)域劃分，依據(jù)參考下邊的縱向分域。

貼源層，原始數(shù)據(jù)不做變化或者僅做最簡單的補全后存入。

數(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ù)量不能太多。建議不超過十個。

必須保持穩(wěn)定。既能涵蓋當(dāng) 前所有的業(yè)務(wù)需求，又能在新業(yè)務(wù)進入時無影響地被包含進已有的數(shù)據(jù)域中或擴展新的數(shù)據(jù)域。

需要結(jié)合團隊和業(yè)務(wù)的實際情況，比如業(yè)務(wù)是否穩(wěn)定、團隊成員建模水平等。

適度的抽象。太低不好適應(yīng)變化，太高不易于理解使用。

分類

面向分析場景，實現(xiàn)較難，對業(yè)務(wù)理解、抽象能力等要求高。

依據(jù)業(yè)務(wù)流程劃分，實現(xiàn)相對容易。

數(shù)據(jù)/業(yè)務(wù)主題域

分析主體域

劃分依據(jù)

按照業(yè)務(wù)或業(yè)務(wù)過程劃分：比如一個靠銷售廣告位置的門戶網(wǎng)站主題域可能會有廣告域，客戶域等，而廣告域可能就會有廣告的庫存，銷售分析、內(nèi)部投放分析等主題。

根據(jù)需求方劃分：比如需求方為財務(wù)部，就可以設(shè)定對應(yīng)的財務(wù)主題域，而財務(wù)主題域里面可能就會有員工工資分析，投資回報比分析等主題。

按照功能或應(yīng)用劃分：比如微信中的朋友圈數(shù)據(jù)域、群聊數(shù)據(jù)域等，而朋友圈數(shù)據(jù)域可能就會有用戶動態(tài)信息主題、廣告主題等。

按照部門劃分：比如可能會有運營域、技術(shù)域等，運營域中可能會有工資支出分析、活動宣傳效果分析等主題。

基本原則

高內(nèi)聚和低耦合

核心模型與擴展模型分離

公共處理邏輯下沉及單一

成本與性能平衡

數(shù)據(jù)可回滾

一致性

命名清晰、可理解附加字段

維表：創(chuàng)建時間、更新時間

事實表：ETL 日期、更新時間其它要求

表、字段的備注信息，必須言簡意賅，在描述清楚的前提下盡量簡潔。

字段類型的約束：比如字符串用 String，數(shù)值用 Int，年月日都用 String 比如 yyyyMMdd 等。

2、命名規(guī)范 統(tǒng)一規(guī)范?

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

3、代碼設(shè)計規(guī)范

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

4、指標(biāo)體系建設(shè)?

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

05 流程規(guī)范

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

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

2、模型設(shè)計流程 數(shù)據(jù)調(diào)研、業(yè)務(wù)調(diào)研、需求調(diào)研 數(shù)據(jù)建模 確定業(yè)務(wù)過程->聲明粒度->確定維度->確定事實 業(yè)務(wù)建模->邏輯建模->物理建模 構(gòu)建總線矩陣 構(gòu)建指標(biāo)體系 根據(jù)已有的分層分域，分治、各個擊破。 總體思路 多種方式結(jié)合使用 評審 除了模型設(shè)計，還需要拉上必要的開發(fā)、業(yè)務(wù)、分析師、產(chǎn)品經(jīng)理、數(shù)倉運維等。 上線、迭代、完善?

3、ETL開發(fā)流程 需求理解 數(shù)據(jù)探查 程序開發(fā) 流程依賴 配置調(diào)度 前端開發(fā)規(guī)范 接口規(guī)范 代碼部署規(guī)范?

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

上線支持團隊就緒

嚴(yán)格按照上線操作步驟執(zhí)行

失敗回滾

1、源端管控 源端變動，必須提前通知數(shù)倉側(cè)。 有條件的話，使用工具監(jiān)控源端重點內(nèi)容的變動。?

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

3、應(yīng)用管控 統(tǒng)一指標(biāo)定義 統(tǒng)一指標(biāo)口徑 統(tǒng)一外部數(shù)據(jù)輸出歸口

網(wǎng)絡(luò)安全

內(nèi)外網(wǎng)隔離，外網(wǎng)環(huán)境訪問內(nèi)網(wǎng)需要登錄 VPN；

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

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

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

ODS 層不對外開放，只對 ODS-DWD 層相關(guān)部分開發(fā)人員可見。

特別敏感數(shù)據(jù)，如用戶年齡、號碼、身份證好、地址等，應(yīng)該放到專門的數(shù)據(jù)庫里，數(shù)倉主庫只存放用戶 ID 和其它必須字段。例如年齡應(yīng)該脫敏成年齡區(qū)間或開發(fā)特定的 UDF 轉(zhuǎn)化函數(shù)。