以下文章來源于五分鐘學大數(shù)據(jù) ，作者園陌
本文將全面講解數(shù)倉建設規(guī)范趋急，從數(shù)據(jù)模型規(guī)范，到數(shù)倉公共規(guī)范势誊，數(shù)倉各層規(guī)范呜达，最后到數(shù)倉命名規(guī)范，包括表命名粟耻，指標字段命名規(guī)范等查近！

目錄：

一眉踱、數(shù)據(jù)模型架構原則

1. 數(shù)倉分層原則
2. 主題域劃分原則
3. 數(shù)據(jù)模型設計原則

二、數(shù)倉公共開發(fā)規(guī)范

1. 層次調用規(guī)范
2. 數(shù)據(jù)類型規(guī)范
3. 數(shù)據(jù)冗余規(guī)范
4. NULL字段處理規(guī)范
5. 指標口徑規(guī)范
6. 數(shù)據(jù)表處理規(guī)范
7. 表的生命周期管理

三霜威、數(shù)倉各層開發(fā)規(guī)范

1. ODS層設計規(guī)范
2. 公共維度層設計規(guī)范
3. DWD明細層設計規(guī)范
4. DWS公共匯總層設計規(guī)范

四谈喳、數(shù)倉命名規(guī)范

1. 詞根設計規(guī)范
2. 表命名規(guī)范
3. 指標命名規(guī)范

一、數(shù)據(jù)模型架構原則

1. 數(shù)倉分層原則

優(yōu)秀可靠的數(shù)倉體系戈泼，往往需要清晰的數(shù)據(jù)分層結構婿禽，即要保證數(shù)據(jù)層的穩(wěn)定又要屏蔽對下游的影響，并且要避免鏈路過長大猛。那么問題來了扭倾，一直在講數(shù)倉要分層，那數(shù)倉分幾層最好挽绩？

目前市場上主流的分層方式眼花繚亂膛壹，不過看事情不能只看表面，還要看到內在的規(guī)律唉堪，不能為了分層而分層模聋，沒有最好的，只有適合的唠亚。

分層是以解決當前業(yè)務快速的數(shù)據(jù)支撐為目的链方，為未來抽象出共性的框架并能夠賦能給其他業(yè)務線，同時為業(yè)務發(fā)展提供穩(wěn)定趾撵、準確的數(shù)據(jù)支撐侄柔，并能夠按照已有的模型為新業(yè)務發(fā)展提供方向，也就是數(shù)據(jù)驅動和賦能占调。

一個好的分層架構暂题，要有以下好處：

1. 清晰數(shù)據(jù)結構；
2. 數(shù)據(jù)血緣追蹤究珊；
3. 減少重復開發(fā)薪者；
4. 數(shù)據(jù)關系條理化；
5. 屏蔽原始數(shù)據(jù)的影響剿涮。

數(shù)倉分層要結合公司業(yè)務進行言津，并且需要清晰明確各層職責，一般采用如下分層結構：

圖片

數(shù)倉建模在哪層建設呢取试？我們以維度建模為例悬槽，建模是在數(shù)據(jù)源層的下一層進行建設，在上圖中瞬浓，就是在DW層進行數(shù)倉建模初婆，所以DW層是數(shù)倉建設的核心層。

下面詳細闡述下每層建設規(guī)范，和上圖的分層稍微有些區(qū)別：

1. 數(shù)據(jù)源層：ODS（Operational Data Store）

ODS 層磅叛，是最接近數(shù)據(jù)源中數(shù)據(jù)的一層屑咳，為了考慮后續(xù)可能需要追溯數(shù)據(jù)問題，因此對于這一層就不建議做過多的數(shù)據(jù)清洗工作弊琴，原封不動地接入原始數(shù)據(jù)即可兆龙，至于數(shù)據(jù)的去噪、去重敲董、異常值處理等過程可以放在后面的 DWD 層來做紫皇。

2. 數(shù)據(jù)倉庫層：DW（Data Warehouse）

數(shù)據(jù)倉庫層是我們在做數(shù)據(jù)倉庫時要核心設計的一層，在這里臣缀，從 ODS 層中獲得的數(shù)據(jù)按照主題建立各種數(shù)據(jù)模型坝橡。

DW 層又細分為 DWD（Data Warehouse Detail）層、DWM（Data WareHouse Middle）層和 DWS（Data WareHouse Servce） 層精置。

1) 數(shù)據(jù)明細層：DWD（Data Warehouse Detail）

該層一般保持和 ODS 層一樣的數(shù)據(jù)粒度计寇，并且提供一定的數(shù)據(jù)質量保證。DWD 層要做的就是將數(shù)據(jù)清理脂倦、整合番宁、規(guī)范化、臟數(shù)據(jù)赖阻、垃圾數(shù)據(jù)蝶押、規(guī)范不一致的、狀態(tài)定義不一致的火欧、命名不規(guī)范的數(shù)據(jù)都會被處理棋电。

同時，為了提高數(shù)據(jù)明細層的易用性苇侵，該層會采用一些維度退化手法赶盔，將維度退化至事實表中，減少事實表和維表的關聯(lián)榆浓。

另外于未，在該層也會做一部分的數(shù)據(jù)聚合，將相同主題的數(shù)據(jù)匯集到一張表中陡鹃，提高數(shù)據(jù)的可用性 烘浦。

2) 數(shù)據(jù)中間層：DWM（Data WareHouse Middle）

該層會在 DWD 層的數(shù)據(jù)基礎上，數(shù)據(jù)做輕度的聚合操作萍鲸，生成一系列的中間表闷叉，提升公共指標的復用性，減少重復加工脊阴。

直觀來講握侧，就是對通用的核心維度進行聚合操作捌肴，算出相應的統(tǒng)計指標。

在實際計算中藕咏，如果直接從 DWD 或者 ODS 計算出寬表的統(tǒng)計指標，會存在計算量太大并且維度太少的問題秽五，因此一般的做法是孽查，在 DWM 層先計算出多個小的中間表，然后再拼接成一張 DWS 的寬表坦喘。由于寬和窄的界限不易界定盲再，也可以去掉 DWM 這一層，只留 DWS 層瓣铣，將所有的數(shù)據(jù)再放在 DWS 亦可答朋。

3) 數(shù)據(jù)服務層：DWS（Data WareHouse Servce）

DWS 層為公共匯總層，會進行輕度匯總棠笑，粒度比明細數(shù)據(jù)稍粗梦碗，基于 DWD 層上的基礎數(shù)據(jù)，整合匯總成分析某一個主題域的服務數(shù)據(jù)蓖救，一般是寬表洪规。DWS 層應覆蓋 80% 的應用場景。又稱數(shù)據(jù)集市或寬表循捺。

按照業(yè)務劃分斩例，如主題域流量、訂單从橘、用戶等念赶，生成字段比較多的寬表，用于提供后續(xù)的業(yè)務查詢恰力，OLAP 分析叉谜，數(shù)據(jù)分發(fā)等。

一般來講牺勾，該層的數(shù)據(jù)表會相對比較少正罢，一張表會涵蓋比較多的業(yè)務內容，由于其字段較多驻民，因此一般也會稱該層的表為寬表翻具。

3. 數(shù)據(jù)應用層：APP（Application）

在這里，主要是提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)回还，一般會存放在 ES裆泳、 PostgreSql、Redis 等系統(tǒng)中供線上系統(tǒng)使用柠硕，也可能會存在 Hive 或者 Druid 中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用工禾。比如我們經(jīng)常說的報表數(shù)據(jù)运提，一般就放在這里。

4. 維表層（Dimension）

如果維表過多闻葵，也可針對維表設計單獨一層民泵，維表層主要包含兩部分數(shù)據(jù)：

高基數(shù)維度數(shù)據(jù)：一般是用戶資料表、商品資料表類似的資料表槽畔。數(shù)據(jù)量可能是千萬級或者上億級別栈妆。

低基數(shù)維度數(shù)據(jù)：一般是配置表，比如枚舉值對應的中文含義厢钧，或者日期維表鳞尔。數(shù)據(jù)量可能是個位數(shù)或者幾千幾萬。

2. 主題域劃分原則

1) 按照業(yè)務或業(yè)務過程劃分

業(yè)務容易理解早直，就是指的功能模塊/業(yè)務線寥假。

業(yè)務過程：指企業(yè)的業(yè)務活動事件，如下單霞扬、支付糕韧、退款都是業(yè)務過程。不過需要注意的是祥得，一個業(yè)務過程是一個不可拆分的行為事件兔沃，通俗的講，業(yè)務過程就是企業(yè)活動中的事件级及。

圖片

2) 按照數(shù)據(jù)域劃分

數(shù)據(jù)域是指面向業(yè)務分析乒疏，將業(yè)務過程或者維度進行抽象的集合。其中饮焦，業(yè)務過程可以概括為一個個不可拆分的行為事件怕吴，在業(yè)務過程下，可以定義指標县踢，維度是指度量的環(huán)境转绷，如買家下單事件，買家是維度硼啤。為保障整個體系的生命力议经，數(shù)據(jù)域是需要抽象提煉，并且長期維護和更新的谴返，但不輕易變動煞肾。在劃分數(shù)據(jù)域時，既能涵蓋當前所有的業(yè)務需求嗓袱，又能在新業(yè)務進入時無影響地被包含進已有的數(shù)據(jù)域中和擴展新的數(shù)據(jù)域籍救。

3. 數(shù)據(jù)模型設計原則

1) 高內聚、低耦合

即主題內部高內聚渠抹、 不同主題間低耦合蝙昙。明細層按照業(yè)務過程劃分主題闪萄，匯總層按照“實體+ 活動”劃分不同分析主題，應用層根據(jù)應用需求劃分不同應用主題奇颠。

2) 核心模型和擴展模型要分離

建立核心模型與擴展模型體系败去，核心模型包括的字段支持常用的核心業(yè)務，擴展模型包括的字段支持個性化或少量應用的需要烈拒，不能讓擴展模型的字段過度侵入核心模型为迈，以免破壞核心模型的架構簡潔性與可維護性。

3) 公共處理邏輯下沉及單一

越是底層公用的處理邏輯越應該在數(shù)據(jù)調度依賴的底層進行封裝與實現(xiàn)缺菌，不要讓公用的處理邏輯暴露給應用實現(xiàn)，不要讓公共邏輯多處同時存在搜锰。

4) 成本與性能平衡

適當?shù)臄?shù)據(jù)冗余可換取查詢和刷新性能伴郁，不宜過度冗余與數(shù)據(jù)復制。

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

處理邏輯不變蛋叼，在不同時間多次運行數(shù)據(jù)結果確定不變焊傅。

二、數(shù)倉公共開發(fā)規(guī)范

1. 層次調用規(guī)范

穩(wěn)定業(yè)務按照標準的數(shù)據(jù)流向進行開發(fā)狈涮，即 ODS –> DWD –> DWS –> APP狐胎。非穩(wěn)定業(yè)務或探索性需求，可以遵循 ODS -> DWD -> APP 或者 ODS -> DWD -> DWM ->APP 兩個模型數(shù)據(jù)流歌馍。

在保障了數(shù)據(jù)鏈路的合理性之后握巢，也必須保證模型分層引用原則：

• 正常流向：ODS -> DWD -> DWM -> DWS -> APP，當出現(xiàn) ODS -> DWD -> DWS -> APP 這種關系時松却，說明主題域未覆蓋全暴浦。應將 DWD 數(shù)據(jù)落到 DWM 中，對于使用頻度非常低的表允許 DWD -> DWS晓锻。
• 盡量避免出現(xiàn) DWS 寬表中使用 DWD 又使用（該 DWD 所歸屬主題域）DWM 的表歌焦。
• 同一主題域內對于 DWM 生成 DWM 的表，原則上要盡量避免砚哆，否則會影響 ETL 的效率独撇。
• DWM、DWS 和 APP 中禁止直接使用 ODS 的表躁锁， ODS 的表只能被 DWD 引用纷铣。
• 禁止出現(xiàn)反向依賴，例如 DWM 的表依賴 DWS 的表灿里。

舉例：

圖片

2. 數(shù)據(jù)類型規(guī)范

需統(tǒng)一規(guī)定不同的數(shù)據(jù)的數(shù)據(jù)類型关炼，嚴格按照規(guī)定的數(shù)據(jù)類型執(zhí)行：

1. 金額：double 或 使用 decimal(28,6) 控制精度等，明確單位是分還是元匣吊。
2. 字符串：string儒拂。
3. id類：bigint寸潦。
4. 時間：string。
5. 狀態(tài)：string

3. 數(shù)據(jù)冗余規(guī)范

寬表的冗余字段要確保：

1. 冗余字段要使用高頻社痛，下游3個或以上使用见转。
2. 冗余字段引入不應造成本身數(shù)據(jù)產(chǎn)生過多的延后。
3. 冗余字段和已有字段的重復率不應過大蒜哀，原則上不應超過60%斩箫，如需要可以選擇join或原表拓展。

4. NULL字段處理規(guī)范

• 對于維度字段撵儿，需設置為-1
• 對于指標字段乘客，需設置為 0

5. 指標口徑規(guī)范

保證主題域內，指標口徑一致淀歇，無歧義易核。

通過數(shù)據(jù)分層，提供統(tǒng)一的數(shù)據(jù)出口浪默，統(tǒng)一對外輸出的數(shù)據(jù)口徑牡直，避免同一指標不同口徑的情況發(fā)生。

1) 指標梳理

指標口徑的不一致使得數(shù)據(jù)使用的成本極高纳决，經(jīng)常出現(xiàn)口徑打架碰逸、反復核對數(shù)據(jù)的問題信轿。在數(shù)據(jù)治理中雁乡，我們將需求梳理到的所有指標進行進一步梳理，明確其口徑嘴拢，如果存在兩個指標名稱相同胜榔，但口徑不一致约急，先判斷是否是進行合并，如需要同時存在苗分，那么在命名上必須能夠區(qū)分開厌蔽。

2) 指標管理

指標管理分為原子指標維護和派生指標維護。

原子指標：

• 選擇原子指標的歸屬產(chǎn)線摔癣、業(yè)務板塊奴饮、數(shù)據(jù)域、業(yè)務過程
• 選擇原子指標的統(tǒng)計數(shù)據(jù)來源于該業(yè)務過程下的原始數(shù)據(jù)源
• 錄入原子指標的英文名稱择浊、中文名稱戴卜、概述
• 填寫指標函數(shù)
• 系統(tǒng)根據(jù)指標函數(shù)自動生成原子指標的定義表達式
• 系統(tǒng)根據(jù)指標定義表達式以及數(shù)據(jù)源表生成原子指標SQL

派生指標：

• 在原子指標的基礎之上選擇了一些維度或者修飾限定詞。

6. 數(shù)據(jù)表處理規(guī)范

1) 增量表

新增數(shù)據(jù)琢岩，增量數(shù)據(jù)是上次導出之后的新數(shù)據(jù)投剥。

1. 記錄每次增加的量，而不是總量担孔；
2. 增量表江锨，只報變化量吃警，無變化不用報；
3. 每天一個分區(qū)啄育。

2) 全量表

每天的所有的最新狀態(tài)的數(shù)據(jù)酌心。

1. 全量表，有無變化挑豌，都要報安券；
2. 每次上報的數(shù)據(jù)都是所有的數(shù)據(jù)（變化的 + 沒有變化的）；
3. 只有一個分區(qū)氓英。

3) 快照表

按日分區(qū)侯勉，記錄截止數(shù)據(jù)日期的全量數(shù)據(jù)。

1. 快照表铝阐，有無變化壳鹤，都要報；
2. 每次上報的數(shù)據(jù)都是所有的數(shù)據(jù)（變化的 + 沒有變化的）饰迹；
3. 一天一個分區(qū)。

4) 拉鏈表

記錄截止數(shù)據(jù)日期的全量數(shù)據(jù)余舶。

1. 記錄一個事物從開始啊鸭，一直到當前狀態(tài)的所有變化的信息；
2. 拉鏈表每次上報的都是歷史記錄的最終狀態(tài)匿值，是記錄在當前時刻的歷史總 量赠制；
3. 當前記錄存的是當前時間之前的所有歷史記錄的最后變化量（總量）；
4. 只有一個分區(qū)挟憔。

7. 表的生命周期管理

這部分主要是要通過對歷史數(shù)據(jù)的等級劃分與對表類型的劃分生成相應的生命周期管理矩陣钟些。

1) 歷史數(shù)據(jù)等級劃分

主要將歷史數(shù)據(jù)劃分P0、Pl绊谭、P2政恍、P3 四個等級，其具體定義如下：

• P0 ：非常重要的主題域數(shù)據(jù)和非常重要的應用數(shù)據(jù)达传，具有不可恢復性篙耗，如交易、日志宪赶、集團 KPI 數(shù)據(jù)宗弯、 IPO 關聯(lián)表。
• Pl ：重要的業(yè)務數(shù)據(jù)和重要的應用數(shù)據(jù)搂妻，具有不可恢復性蒙保，如重要的業(yè)務產(chǎn)品數(shù)據(jù)。
• P2 ：重要的業(yè)務數(shù)據(jù)和重要的應用數(shù)據(jù)欲主，具有可恢復性邓厕，如交易線 ETL 產(chǎn)生的中間過程數(shù)據(jù)逝嚎。
• P3 ：不重要的業(yè)務數(shù)據(jù)和不重要的應用數(shù)據(jù)，具有可恢復性邑狸，如某些 SNS 產(chǎn)品報表懈糯。

2) 表類型劃分

1. 事件型流水表（增量表）

事件型流水表（增量表）指數(shù)據(jù)無重復或者無主鍵數(shù)據(jù)，如日志单雾。

1. 事件型鏡像表（增量表）

事件型鏡像表（增量表）指業(yè)務過程性數(shù)據(jù)赚哗，有主鍵，但是對于同樣主鍵的屬性會發(fā)生緩慢變化硅堆，如交易屿储、訂單狀態(tài)與時間會根據(jù)業(yè)務發(fā)生變更。

1. 維表

維表包括維度與維度屬性數(shù)據(jù)渐逃，如用戶表够掠、商品表。

1. Merge 全量表

Merge 全量表包括業(yè)務過程性數(shù)據(jù)或者維表數(shù)據(jù)茄菊。由于數(shù)據(jù)本身有新增的或者發(fā)生狀態(tài)變更疯潭，對于同樣主鍵的數(shù)據(jù)可能會保留多份，因此可以對這些數(shù)據(jù)根據(jù)主鍵進行 Merge 操作面殖，主鍵對應的屬性只會保留最新狀態(tài)竖哩，歷史狀態(tài)保留在前一天分區(qū) 中。例如脊僚，用戶表相叁、交易表等都可以進行 Merge 操作。

1. ETL 臨時表

ETL 臨時表是指 ETL 處理過程中產(chǎn)生的臨時表數(shù)據(jù)辽幌，一般不建議保留增淹，最多7天。

1. TT 臨時數(shù)據(jù)

TT 拉取的數(shù)據(jù)和 DbSync 產(chǎn)生的臨時數(shù)據(jù)最終會流轉到 DS 層乌企，ODS 層數(shù)據(jù)作為原始數(shù)據(jù)保留下來虑润，從而使得 TT&DbSync 上游數(shù)據(jù)成為臨時數(shù)據(jù)。這類數(shù)據(jù)不建議保留很長時間加酵，生命周期默認設置為 93天端辱，可以根據(jù)實際情況適當減少保留天數(shù)。

7. 普通全量表

很多小業(yè)務數(shù)據(jù)或者產(chǎn)品數(shù)據(jù)虽画，BI一般是直接全量拉取舞蔽，這種方式效率快，對存儲壓力也不是很大码撰，而且表保留很長時間渗柿，可以根據(jù)歷史數(shù)據(jù)等級確定保留策略。

通過上述歷史數(shù)據(jù)等級劃分與表類型劃分，生成相應的生命周期管理矩陣朵栖，如下表所示：

圖片

三颊亮、數(shù)倉各層開發(fā)規(guī)范

1. ODS層設計規(guī)范

同步規(guī)范：

1. 一個系統(tǒng)源表只允許同步一次；
2. 全量初始化同步和增量同步處理邏輯要清晰陨溅；
3. 以統(tǒng)計日期和時間進行分區(qū)存儲终惑；
4. 目標表字段在源表不存在時要自動填充處理。

表分類與生命周期：

1. ods流水全量表：

• 不可再生的永久保存门扇；
• 日志可按留存要求雹有；
• 按需設置保留特殊日期數(shù)據(jù)；
• 按需設置保留特殊月份數(shù)據(jù)臼寄；

1. ods鏡像型全量表：

• 推薦按天存儲霸奕；
• 對歷史變化進行保留；
• 最新數(shù)據(jù)存儲在最大分區(qū)吉拳；
• 歷史數(shù)據(jù)按需保留质帅；

1. ods增量數(shù)據(jù)：

• 推薦按天存儲；
• 有對應全量表的留攒，建議只保留14天數(shù)據(jù)煤惩；
• 無對應全量表的，永久保留炼邀；

1. ods的etl過程中的臨時表：

• 推薦按需保留魄揉；
• 最多保留7天；
• 建議用完即刪汤善，下次使用再生成；

1. BDSync非去重數(shù)據(jù)：

• 通過中間層保留票彪，默認用完即刪红淡，不建議保留。

數(shù)據(jù)質量：

1. 全量表必須配置唯一性字段標識降铸；
2. 對分區(qū)空數(shù)據(jù)進行監(jiān)控在旱；
3. 對枚舉類型字段，進行枚舉值變化和分布監(jiān)控推掸；
4. ods表數(shù)據(jù)量級和記錄數(shù)做環(huán)比監(jiān)控桶蝎；
5. ods全表都必須要有注釋；

2. 公共維度層設計規(guī)范

1) 設計準則

1. 一致性

共維度在不同的物理表中的字段名稱谅畅、數(shù)據(jù)類型登渣、數(shù)據(jù)內容必須保持一致（歷史原因不一致，要做好版本控制）

1. 維度的組合與拆分

• 組合原則：

將維度與關聯(lián)性強的字段進行組合毡泻，一起查詢胜茧，一起展示，兩個維度必須具有天然的關系，如：商品的基本屬性和所屬品牌呻顽。

無相關性：如一些使用頻率較小的雜項維度雹顺，可以構建一個集合雜項維度的特殊屬性。

行為維度：經(jīng)過計算的度量廊遍，但下游當維度處理嬉愧，例：點擊量 0-1000,100-1000等，可以做聚合分類喉前。

• 拆分與冗余：

針對重要性没酣，業(yè)務相關性、源被饿、使用頻率等可分為核心表四康、擴展表。

數(shù)據(jù)記錄較大的維度狭握，可以適當冗余一些子集闪金。

2) 存儲及生命周期管理

建議按天分區(qū)。

1. 3個月內最大訪問跨度<=4天時论颅，建議保留最近7天分區(qū)哎垦；
2. 3個月內最大訪問跨度<=12天時，建議保留最近15天分區(qū)恃疯；
3. 3個月內最大訪問跨度<=30天時漏设，建議保留最近33天分區(qū)；
4. 3個月內最大訪問跨度<=90天時今妄，建議保留最近120天分區(qū)郑口；
5. 3個月內最大訪問跨度<=180天時，建議保留最近240天分區(qū)盾鳞；
6. 3個月內最大訪問跨度<=300天時犬性，建議保留最近400天分區(qū)；

3. DWD明細層設計規(guī)范

1) 存儲及生命周期管理

建議按天分區(qū)腾仅。

1. 3個月內最大訪問跨度<=4天時乒裆，建議保留最近7天分區(qū)；
2. 3個月內最大訪問跨度<=12天時推励，建議保留最近15天分區(qū)鹤耍；
3. 3個月內最大訪問跨度<=30天時，建議保留最近33天分區(qū)验辞；
4. 3個月內最大訪問跨度<=90天時稿黄，建議保留最近120天分區(qū)；
5. 3個月內最大訪問跨度<=180天時跌造，建議保留最近240天分區(qū)抛猖；
6. 3個月內最大訪問跨度<=300天時，建議保留最近400天分區(qū)；

2) 事務型事實表設計準則

• 基于數(shù)據(jù)應用需求的分析設計事務型事實表财著，結合下游較大的針對某個業(yè)務過程和分析指標需求联四，可考慮基于某個事件過程構建事務型實時表；
• 一般選用事件的發(fā)生日期或時間作為分區(qū)字段撑教，便于掃描和裁剪朝墩；
• 冗余子集原則，有利于降低后續(xù)IO開銷伟姐；
• 明細層事實表維度退化收苏，減少后續(xù)使用join成本。

3) 周期快照事實表

• 周期快照事實表中的每行匯總了發(fā)生在某一標準周期愤兵，如某一天鹿霸、某周、某月的多個度量事件秆乳。
• 粒度是周期性的懦鼠，不是個體的事務。
• 通常包含許多事實屹堰，因為任何與事實表粒度一致的度量事件都是被允許的肛冶。

4) 累積快照事實表

• 多個業(yè)務過程聯(lián)合分析而構建的事實表，如采購單的流轉環(huán)節(jié)扯键。
• 用于分析事件時間和時間之間的間隔周期睦袖。
• 少量的且當前事務型不支持的，如關閉荣刑、發(fā)貨等相關的統(tǒng)計馅笙。

4. DWS公共匯總層設計規(guī)范

數(shù)據(jù)倉庫的性能是數(shù)據(jù)倉庫建設是否成功的重要標準之一。聚集主要是通過匯總明細粒度數(shù)據(jù)來獲得改進查詢性能的效果厉亏。通過訪問聚集數(shù)據(jù)董习，可以減少數(shù)據(jù)庫在響應查詢時必須執(zhí)行的工作量，能夠快速響應用戶的查詢叶堆，同時有利于減少不同用訪問明細數(shù)據(jù)帶來的結果不一致問題阱飘。

1) 聚集的基本原則

• 一致性斥杜。聚集表必須提供與查詢明細粒度數(shù)據(jù)一致的查詢結果虱颗。
• 避免單一表設計。不要在同一個表中存儲不同層次的聚集數(shù)據(jù)蔗喂。
• 聚集粒度可不同忘渔。聚集并不需要保持與原始明細粒度數(shù)據(jù)一樣的粒度，聚集只關心所需要查詢的維度缰儿。

2) 聚集的基本步驟

第一步：確定聚集維度

在原始明細模型中會存在多個描述事實的維度畦粮，如日期、商品類別、賣家等宣赔，這時候需要確定根據(jù)什么維度聚集预麸，如果只關心商品的交易額情況，那么就可以根據(jù)商品維度聚集數(shù)據(jù)儒将。

第二步：確定一致性上鉆

這時候要關心是按月匯總還是按天匯總吏祸，是按照商品匯總還是按照類目匯總，如果按照類目匯總钩蚊，還需要關心是按照大類匯總還是小類匯總贡翘。當然，我們要做的只是了解用戶需要什么砰逻，然后按照他們想要的進行聚集鸣驱。

第三步：確定聚集事實

在原始明細模型中可能會有多個事實的度量，比如在交易中有交易額蝠咆、交易數(shù)量等踊东，這時候要明確是按照交易額匯總還是按照成交數(shù)量匯總。

3) 公共匯總層設計原則

除了聚集基本的原則外勺美，公共匯總層還必須遵循以下原則：

• 數(shù)據(jù)公用性递胧。匯總的聚集會有第三者使用嗎？基于某個維度的聚集是不是經(jīng)常用于數(shù)據(jù)分析中赡茸？如果答案是肯定的缎脾，那么就有必要把明細數(shù)據(jù)經(jīng)過匯總沉淀到聚集表中。
• 不跨數(shù)據(jù)域占卧。數(shù)據(jù)域是在較高層次上對數(shù)據(jù)進行分類聚集的抽象遗菠。如以業(yè)務
• 區(qū)分統(tǒng)計周期。在表的命名上要能說明數(shù)據(jù)的統(tǒng)計周期华蜒，如 _Id表示最近1天辙纬，_td 表示截至當天，_nd 表示最近N天叭喜。

四贺拣、數(shù)倉命名規(guī)范

1. 詞根設計規(guī)范

詞根屬于數(shù)倉建設中的規(guī)范，屬于元數(shù)據(jù)管理的范疇捂蕴，現(xiàn)在把這個劃到數(shù)據(jù)治理的一部分譬涡。完整的數(shù)倉建設是包含數(shù)據(jù)治理的，只是現(xiàn)在談到數(shù)倉偏向于數(shù)據(jù)建模啥辨， 而談到數(shù)據(jù)治理涡匀，更多的是關于數(shù)據(jù)規(guī)范、數(shù)據(jù)管理溉知。

表命名陨瘩，其實在很大程度上是對元數(shù)據(jù)描述的一種體現(xiàn)腕够，表命名規(guī)范越完善，我 們能從表名獲取到的信息就越多舌劳。比如：一部分業(yè)務是關于貨架的帚湘，英文名是：rack， rack 就是一個詞根甚淡，那我們就在所有的表客们、字段等用到的地方都叫 rack，不要叫成 別的什么材诽。這就是詞根的作用底挫，用來統(tǒng)一命名，表達同一個含義脸侥。

指標體系中有很多“率”的指標建邓，都可以拆解成 XXX+率，率可以叫 rate睁枕，那我 們所有的指標都叫做 XXX+rate官边。

詞根：可以用來統(tǒng)一表名、字段名外遇、主題域名等等注簿。

舉例：以流程圖的方式來展示，更加直觀和易懂跳仿，本圖側重 dwm 層表的命名 規(guī)范诡渴，其余命名是類似的道理：

圖片

第一個判斷條件是該表的用途，是中間表菲语、原始日志還是業(yè)務展示用的表 如果該表被判斷為中間表妄辩，就會走入下一個判斷條件：表是否有 group 操作 通過是否有 group 操作來判斷該表該劃分在 dwd 層還是 dwm 和 dws 層 如果不是 dwd 層，則需要判斷該表是否是多個行為的匯總表（即寬表） 最后再分別填上事業(yè)群山上、部門眼耀、業(yè)務線、自定義名稱和更新頻率等信息即可佩憾。

分層：表的使用范圍

事業(yè)群和部門：生產(chǎn)該表或者該數(shù)據(jù)的團隊

業(yè)務線：表明該數(shù)據(jù)是哪個產(chǎn)品或者業(yè)務線相關

主題域：分析問題的角度哮伟，對象實體

自定義：一般會盡可能多描述該表的信息，比如活躍表妄帘、留存表等

更新周期：比如說天級還是月級更新

數(shù)倉表的命名規(guī)范如下：

1. 數(shù)倉層次:

公用維度：dim

DM層：dm

ODS層：ods

DWD層：dwd

DWS層：dws

2. 周期/數(shù)據(jù)范圍：

日快照：d

增量：i

全量：f

周：w

拉鏈表：l

非分區(qū)全量表：a

2. 表命名規(guī)范

1) 常規(guī)表

常規(guī)表是我們需要固化的表楞黄，是正式使用的表，是目前一段時間內需要去維護去 完善的表寄摆。

規(guī)范：分層前綴[dwd|dws|ads]_部門_業(yè)務域_主題域_XXX_更新周期|數(shù)據(jù)范圍

業(yè)務域谅辣、主題域我們都可以用詞根的方式枚舉清楚修赞，不斷完善婶恼。

更新周期主要的是時間粒度桑阶、日、月勾邦、年蚣录、周等。

2) 中間表

中間表一般出現(xiàn)在 Job 中眷篇，是 Job 中臨時存儲的中間數(shù)據(jù)的表萎河，中間表的作 用域只限于當前 Job 執(zhí)行過程中，Job 一旦執(zhí)行完成蕉饼，該中間表的使命就完 成了虐杯，是可以刪除的（按照自己公司的場景自由選擇，以前公司會保留幾天 的中間表數(shù)據(jù)昧港，用來排查問題）擎椰。

規(guī)范：mid_table_name_[0~9|dim]

table_name 是我們任務中目標表的名字，通常來說一個任務只有一個目標表创肥。這里加上表名达舒，是為了防止自由發(fā)揮的時候表名沖突，而末尾大家可以選擇自由發(fā)揮叹侄，起一些有意義的名字巩搏，或者簡單粗暴，使用數(shù)字代替趾代，各有優(yōu)劣吧贯底，謹慎選擇。

通常會遇到需要補全維度的表撒强，這里使用 dim 結尾丈甸。

如果要保留歷史的中間表，可以加上日期或者時間戳尿褪。

3) 臨時表

臨時表是臨時測試的表睦擂，是臨時使用一次的表，就是暫時保存下數(shù)據(jù)看看杖玲，后續(xù)一般不再使用的表顿仇，是可以隨時刪除的表。

規(guī)范：tmp_xxx

只要加上 tmp 開頭即可摆马，其他名字隨意臼闻，注意 tmp 開頭的表不要用來實際使用，只是測試驗證而已囤采。

4) 維度表

維度表是基于底層數(shù)據(jù)述呐，抽象出來的描述類的表。維度表可以自動從底層表抽象出來蕉毯，也可以手工來維護乓搬。

規(guī)范：dim_xxx

維度表思犁，統(tǒng)一以 dim 開頭，后面加上进肯，對該指標的描述激蹲。

5) 手工表

手工表是手工維護的表，手工初始化一次之后江掩，一般不會自動改變学辱，后面變更，也是手工來維護环形。

一般來說策泣，手工的數(shù)據(jù)粒度是偏細的，所以暫時統(tǒng)一放在 dwd 層抬吟，后面如果有目標值或者其他類型手工數(shù)據(jù)着降，再根據(jù)實際情況分層。

規(guī)范：dwd_業(yè)務域_manual_xxx

手工表拗军，增加特殊的主題域任洞，manual，表示手工維護表发侵。

3. 指標命名規(guī)范

1) 公共規(guī)則

• 所有單詞小寫
• 單詞之間下劃線分割（反例：appName 或 AppName）
• 可讀性優(yōu)于長度 (詞根交掏，避免出現(xiàn)同一個指標，命名一致性)
• 禁止使用 sql 關鍵字刃鳄，如字段名與關鍵字沖突時 +col
• 數(shù)量字段后綴 _cnt 等標識...
• 金額字段后綴 _price 標識
• 天分區(qū)使用字段 dt盅弛，格式統(tǒng)一（yyyymmdd 或 yyyy-mm-dd）
• 小時分區(qū)使用字段 hh，范圍（00-23）
• 分鐘分區(qū)使用字段 mi叔锐，范圍（00-59）
• 布爾類型標識：is_{業(yè)務}挪鹏，不允許出現(xiàn)空值

2) 指標命名規(guī)范

結合指標的特性以及詞根管理規(guī)范，將指標進行結構化處理愉烙。

1. 基礎指標詞根讨盒，即所有指標必須包含以下基礎詞根：

[圖片上傳失敗...(image-a72db1-1637195734275)]

1. 業(yè)務修飾詞，用于描述業(yè)務場景的詞匯步责，例如trade-交易返顺。

3.日期修飾詞，用于修飾業(yè)務發(fā)生的時間區(qū)間蔓肯。

圖片

4.聚合修飾詞遂鹊，對結果進行聚集操作。

圖片

5.基礎指標蔗包，單一的業(yè)務修飾詞+基礎指標詞根構建基礎指標 秉扑，例如：交易金額-trade_amt。

6.派生指標调限，多修飾詞+基礎指標詞根構建派生指標舟陆。派生指標繼承基礎指標的特性误澳，例如：安裝門店數(shù)量-install_poi_cnt。

圖片

參考

本文檔規(guī)范依據(jù)來源參考：

1. 《大數(shù)據(jù)之路：阿里巴巴大數(shù)據(jù)實踐》
2. 《數(shù)倉工具箱：維度建模權威指南》
3. 《OneData建設：美團SaaS數(shù)倉建設》