如何構(gòu)建與優(yōu)化數(shù)據(jù)倉庫架構(gòu)與模型設(shè)計？
構(gòu)建與優(yōu)化數(shù)據(jù)倉庫·架構(gòu)與模型設(shè)計--阿里云教程
技術(shù)架構(gòu)選型
數(shù)倉分層
數(shù)據(jù)模型
層次調(diào)用規(guī)范
https://help.aliyun.com/document_detail/154238.html
技術(shù)架構(gòu)選型
教程本身是以阿里云MaxCompute為例，實際上，流程和方法論是通用的。
在數(shù)據(jù)模型設(shè)計之前，您需要首先完成技術(shù)架構(gòu)的選型。本教程中使用阿里云大數(shù)據(jù)產(chǎn)品MaxCompute配合DataWorks，完成整體的數(shù)據(jù)建模和研發(fā)流程。
完整的技術(shù)架構(gòu)圖如下圖所示。其中，DataWorks的數(shù)據(jù)集成負責完成數(shù)據(jù)的采集和基本的ETL【可以基于開源的相關(guān)技術(shù)組件構(gòu)建數(shù)據(jù)采集和ETL基礎(chǔ)平臺】。MaxCompute作為整個大數(shù)據(jù)開發(fā)過程中的離線計算引擎。DataWorks則包括數(shù)據(jù)開發(fā)、數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全、數(shù)據(jù)管理等在內(nèi)的一系列功能。
數(shù)倉分層
在阿里巴巴的數(shù)據(jù)體系中，我們建議將數(shù)據(jù)倉庫分為三層，自下而上為：數(shù)據(jù)引入層（ODS，Operation Data Store）、數(shù)據(jù)公共層（CDM，Common Data Model）和數(shù)據(jù)應(yīng)用層（ADS，Application Data Service）。
數(shù)據(jù)倉庫的分層和各層級用途如下圖所示。
數(shù)據(jù)引入層ODS（Operation Data Store）：存放未經(jīng)過處理的原始數(shù)據(jù)至數(shù)據(jù)倉庫系統(tǒng)，結(jié)構(gòu)上與源系統(tǒng)保持一致，是 數(shù)據(jù)倉庫的數(shù)據(jù)準備區(qū)。主要完成基礎(chǔ)數(shù)據(jù)引入到MaxCompute的職責，同時記錄基礎(chǔ)數(shù)據(jù)的歷史變化。數(shù)據(jù)公共層CDM（Common Data Model，又稱通用數(shù)據(jù)模型層），包括 DIM維度表、DWD和DWS，由ODS層數(shù)據(jù)加工而成。主要完成數(shù)據(jù)加工與整合，建立一致性的維度，構(gòu)建可復(fù)用的面向分析和統(tǒng)計的明細事實表，以及匯總公共粒度的指標。
公共維度層（DIM）：基于維度建模理念思想，建立整個企業(yè)的一致性維度。降低數(shù)據(jù)計算口徑和算法不統(tǒng)一風險。公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應(yīng)。
公共匯總粒度事實層（DWS）：以分析的主題對象作為建模驅(qū)動，基于上層的應(yīng)用和產(chǎn)品的指標需求，構(gòu)建公共粒度的匯總指標事實表，以寬表化手段物理化模型。構(gòu)建命名規(guī)范、口徑一致的統(tǒng)計指標，為上層提供公共指標，建立匯總寬表、明細事實表。
公共匯總粒度事實層的表通常也被稱為匯總邏輯表，用于存放派生指標數(shù)據(jù)。明細粒度事實層（DWD）：以業(yè)務(wù)過程作為建模驅(qū)動，基于每個具體的業(yè)務(wù)過程特點，構(gòu)建最細粒度的明細層事實表?？梢越Y(jié)合企業(yè)的數(shù)據(jù)使用特點，將明細事實表的某些重要維度屬性字段做適當冗余，即寬表化處理。明細粒度事實層的表通常也被稱為邏輯事實表。
數(shù)據(jù)應(yīng)用層ADS（Application Data Service）：存放數(shù)據(jù)產(chǎn)品個性化的統(tǒng)計指標數(shù)據(jù)。根據(jù)CDM與ODS層加工生成。
該數(shù)據(jù)分類架構(gòu)在ODS層分為三部分：數(shù)據(jù)準備區(qū)、離線數(shù)據(jù)和準實時數(shù)據(jù)區(qū)。整體數(shù)據(jù)分類架構(gòu)如下圖所示。
在本教程中，從交易數(shù)據(jù)系統(tǒng)的數(shù)據(jù)經(jīng)過DataWorks數(shù)據(jù)集成，同步到數(shù)據(jù)倉庫的ODS層。經(jīng)過數(shù)據(jù)開發(fā)形成事實寬表后，再以商品、地域等為維度進行公共匯總。
整體的數(shù)據(jù)流向如下圖所示。其中，ODS層到DIM層的ETL（萃?。‥xtract）、轉(zhuǎn)置（Transform）及加載（Load））處理是在MaxCompute中進行的，處理完成后會同步到所有存儲系統(tǒng)。ODS層和DWD層會放在數(shù)據(jù)中間件中，供下游訂閱使用。而DWS層和ADS層的數(shù)據(jù)通常會落地到在線存儲系統(tǒng)中，下游通過接口調(diào)用的形式使用。
數(shù)據(jù)模型
1. 數(shù)據(jù)引入層（ODS）
ODS層存放您從業(yè)務(wù)系統(tǒng)獲取的最原始的數(shù)據(jù)，是其他上層數(shù)據(jù)的源數(shù)據(jù)。業(yè)務(wù)數(shù)據(jù)系統(tǒng)中的數(shù)據(jù)通常為非常細節(jié)的數(shù)據(jù)，經(jīng)過長時間累積，且訪問頻率很高，是面向應(yīng)用的數(shù)據(jù)。
數(shù)據(jù)引入層表設(shè)計
本教程中，在ODS層主要包括的數(shù)據(jù)有：交易系統(tǒng)訂單詳情、用戶信息詳情、商品詳情等。這些數(shù)據(jù)未經(jīng)處理，是最原始的數(shù)據(jù)。邏輯上，這些數(shù)據(jù)都是以二維表的形式存儲。雖然嚴格的說ODS層不屬于數(shù)倉建模的范疇，但是合理的規(guī)劃ODS層并做好數(shù)據(jù)同步也非常重要。
本教程中，使用了6張ODS表：
記錄用于拍賣的商品信息：s_auction。
記錄用于正常售賣的商品信息：s_sale。
記錄用戶詳細信息：s_users_extra。
記錄新增的商品成交訂單信息：s_biz_order_delta。
記錄新增的物流訂單信息：s_logistics_order_delta。
記錄新增的支付訂單信息：s_pay_order_delta。
說明：
通過_delta來標識該表為增量表。
表中某些字段的名稱剛好和關(guān)鍵字重名了，可以通過添加_col1后綴解決。
建表示例（s_auction）
CREATE TABLE IF NOT EXISTS s_auction
(
id STRING COMMENT '商品ID',
title STRING COMMENT '商品名',
gmt_modified STRING COMMENT '商品最后修改日期',
price DOUBLE COMMENT '商品成交價格，單位元',
starts STRING COMMENT '商品上架時間',
minimum_bid DOUBLE COMMENT '拍賣商品起拍價，單位元',
duration STRING COMMENT '有效期，銷售周期，單位天',
incrementnum DOUBLE COMMENT '拍賣價格的增價幅度',
city STRING COMMENT '商品所在城市',
prov STRING COMMENT '商品所在省份',
ends STRING COMMENT '銷售結(jié)束時間',
quantity BIGINT COMMENT '數(shù)量',
stuff_status BIGINT COMMENT '商品新舊程度 0 全新 1 閑置 2 二手',
auction_status BIGINT COMMENT '商品狀態(tài) 0 正常 1 用戶刪除 2 下架 3 從未上架',
cate_id BIGINT COMMENT '商品類目ID',
cate_name STRING COMMENT '商品類目名稱',
commodity_id BIGINT COMMENT '品類ID',
commodity_name STRING COMMENT '品類名稱',
umid STRING COMMENT '買家umid'
)
COMMENT '商品拍賣ODS'
PARTITIONED BY (ds STRING COMMENT '格式：YYYYMMDD')
LIFECYCLE 400;
數(shù)據(jù)引入層存儲
為了滿足歷史數(shù)據(jù)分析需求，您可以在ODS層表中添加時間維度作為分區(qū)字段。實際應(yīng)用中，您可以選擇采用增量、全量存儲或拉鏈存儲的方式。
增量存儲
以天為單位的增量存儲，以業(yè)務(wù)日期作為分區(qū)，每個分區(qū)存放日增量的業(yè)務(wù)數(shù)據(jù)。舉例如下：
1月1日，用戶A訪問了A公司電商店鋪B，A公司電商日志產(chǎn)生一條記錄t1。1月2日，用戶A又訪問了A公司電商店鋪C，A公司電商日志產(chǎn)生一條記錄t2。采用增量存儲方式，t1將存儲在1月1日這個分區(qū)中，t2將存儲在1月2日這個分區(qū)中。
1月1日，用戶A在A公司電商網(wǎng)購買了B商品，交易日志將生成一條記錄t1。1月2日，用戶A又將B商品退貨了，交易日志將更新t1記錄。采用增量存儲方式，初始購買的t1記錄將存儲在1月1日這個分區(qū)中，更新后的t1將存儲在1月2日這個分區(qū)中。
交易、日志等
事務(wù)性較強的ODS表適合增量存儲方式。這類表數(shù)據(jù)量較大，采用全量存儲的方式存儲成本壓力大。此外，這類表的下游應(yīng)用對于歷史全量數(shù)據(jù)訪問的需求較小（此類需求可通過數(shù)據(jù)倉庫后續(xù)匯總后得到）。例如，日志類ODS表沒有數(shù)據(jù)更新的業(yè)務(wù)過程，因此所有增量分區(qū)UNION在一起就是一份全量數(shù)據(jù)。
全量存儲
以天為單位的全量存儲，以業(yè)務(wù)日期作為分區(qū)，每個分區(qū)存放截止到業(yè)務(wù)日期為止的全量業(yè)務(wù)數(shù)據(jù)。
例如，1月1日，賣家A在A公司電商網(wǎng)發(fā)布了B、C兩個商品，前端商品表將生成兩條記錄t1、t2。1月2日，賣家A將B商品下架了，同時又發(fā)布了商品D，前端商品表將更新記錄t1，同時新生成記錄t3。采用全量存儲方式， 在1月1日這個分區(qū)中存儲t1和t2兩條記錄，在1月2日這個分區(qū)中存儲更新后的t1以及t2、t3記錄。
對于小數(shù)據(jù)量的緩慢變化維度數(shù)據(jù)，例如商品類目，可直接使用全量存儲。
拉鏈存儲 拉鏈存儲通過 新增兩個時間戳字段（start_dt和end_dt），將所有以天為粒度的變更數(shù)據(jù)都記錄下來，通常分區(qū)字段也是這兩個時間戳字段。
拉鏈存儲舉例如下。
這樣，下游應(yīng)用可以通過限制時間戳字段來獲取歷史數(shù)據(jù)。例如，用戶訪問1月1日數(shù)據(jù)，只需限制start_dt<=20160101并且 end_dt>20160101。
緩慢變化維度
MaxCompute不推薦使用代理鍵，推薦使用自然鍵作為維度主鍵，主要原因有兩點：
MaxCompute是分布式計算引擎，生成全局唯一的代理鍵工作量非常大。當遇到大數(shù)據(jù)量情況下，這項工作就會更加復(fù)雜，且沒有必要。 使用代理鍵會增加ETL的復(fù)雜性，從而增加ETL任務(wù)的開發(fā)和維護成本。
在不使用代理鍵的情況下，緩慢變化維度可以通過快照方式處理。
快照方式下數(shù)據(jù)的計算周期通常為每天一次?；谠撝芷?，處理維度變化的方式為每天一份全量快照。
例如商品維度，每天保留一份全量商品快照數(shù)據(jù)。任意一天的事實表均可以取到當天的商品信息，也可以取到最新的商品信息，通過限定日期，采用自然鍵進行關(guān)聯(lián)即可。該方式的優(yōu)勢主要有以下兩點：
處理緩慢變化維度的方式簡單有效，開發(fā)和維護成本低。 使用方便，易于理解。數(shù)據(jù)使用方只需要限定日期即可取到當天的快照數(shù)據(jù)。任意一天的事實快照與任意一天的維度快照通過維度的自然鍵進行關(guān)聯(lián)即可。
該方法的弊端主要是存儲空間的極大浪費。例如某維度每天的變化量占總體數(shù)據(jù)量比例很低，極端情況下，每天無變化，這種情況下存儲浪費嚴重。該方法主要實現(xiàn)了通過犧牲存儲獲取ETL效率的優(yōu)化和邏輯上的簡化。請避免過度使用該方法，且必須要有對應(yīng)的數(shù)據(jù)生命周期制度，清除無用的歷史數(shù)據(jù)。
數(shù)據(jù)同步加載與處理
ODS的數(shù)據(jù)需要由各數(shù)據(jù)源系統(tǒng)同步到MaxCompute，才能用于進一步的數(shù)據(jù)開發(fā)。本教程建議您使用DataWorks數(shù)據(jù)集成功能完成數(shù)據(jù)同步。在使用數(shù)據(jù)集成的過程中，建議您遵循以下規(guī)范：
一個系統(tǒng)的源表只允許同步到MaxCompute一次，保持表結(jié)構(gòu)的一致性。 數(shù)據(jù)集成僅用于離線全量數(shù)據(jù)同步，實時增量數(shù)據(jù)同步需要您使用數(shù)據(jù)傳輸服務(wù)DTS實現(xiàn)，詳情請參見數(shù)據(jù)傳輸服務(wù)DTS。 數(shù)據(jù)集成全量同步的數(shù)據(jù)直接進入全量表的當日分區(qū)。 ODS層的表建議以統(tǒng)計日期及時間分區(qū)表的方式存儲，便于管理數(shù)據(jù)的存儲成本和策略控制。 數(shù)據(jù)集成可以自適應(yīng)處理源系統(tǒng)字段的變更： 如果源系統(tǒng)字段的目標表在MaxCompute上不存在，可以由數(shù)據(jù)集成自動添加不存在的表字段。 如果目標表的字段在源系統(tǒng)不存在，數(shù)據(jù)集成填充NULL。
2. 公共維度匯總層（DIM）
公共維度匯總層（DIM）基于維度建模理念，建立整個企業(yè)的一致性維度。
公共維度匯總層（DIM）主要由維度表（維表）構(gòu)成。維度是邏輯概念，是衡量和觀察業(yè)務(wù)的角度。維表是根據(jù)維度及其屬性將數(shù)據(jù)平臺上構(gòu)建的表物理化的表，采用寬表設(shè)計的原則。因此，構(gòu)建公共維度匯總層（DIM）首先需要定義維度。
定義維度
在劃分數(shù)據(jù)域、構(gòu)建總線矩陣時，需要結(jié)合對業(yè)務(wù)過程的分析定義維度。以本教程中A電商公司的營銷業(yè)務(wù)板塊為例，在交易數(shù)據(jù)域中，我們重點考察確認收貨（交易成功）的業(yè)務(wù)過程。
在確認收貨的業(yè)務(wù)過程中，主要有商品和收貨地點（本教程中，假設(shè)收貨和購買是同一個地點）兩個維度所依賴的業(yè)務(wù)角度。
從商品角度可以定義出以下維度：
商品ID
商品名稱
商品價格
商品新舊程度：0-全新、1-閑置、 2-二手
商品類目ID
商品類目名稱
品類ID
品類名稱
買家ID
商品狀態(tài)：0-正常、1-用戶刪除、2-下架、3-從未上架
商品所在城市
商品所在省份
從地域角度，可以定義出以下維度：
買家ID
城市code
城市名稱
省份code
省份名稱
作為維度建模的核心，在企業(yè)級數(shù)據(jù)倉庫中必須保證維度的唯一性。以A公司的商品維度為例，有且只允許有一種維度定義。例如，省份code這個維度，對于任何業(yè)務(wù)過程所傳達的信息都是一致的。
設(shè)計維表
完成維度定義后，您就可以對維度進行補充，進而生成維表了。
維表的設(shè)計需要注意：
建議維表 單表信息不超過1000萬條。維表與其他表進行Join時，建議您 使用Map Join。避免過于頻繁的更新維表的數(shù)據(jù)。
在設(shè)計維表時，您需要從下列方面進行考慮：
維表中數(shù)據(jù)的穩(wěn)定性。例如A公司電商會員通常不會出現(xiàn)消亡，但會員數(shù)據(jù)可能在任何時候更新，此時要考慮創(chuàng)建單個分區(qū)存儲全量數(shù)據(jù)。如果存在不會更新的記錄，您可能需要 分別創(chuàng)建歷史表與日常表。日常表用于存放當前有效的記錄，保持表的數(shù)據(jù)量不會膨脹；歷史表根據(jù)消亡時間插入對應(yīng)分區(qū)，使用單個分區(qū)存放分區(qū)對應(yīng)時間的消亡記錄。是否需要垂直拆分。如果一個維表存在大量屬性不被使用，或由于承載過多屬性字段導致查詢變慢，則需考慮對字段進行拆分，創(chuàng)建多個維表。 是否需要水平拆分。如果記錄之間有明顯的界限，可以考慮拆成多個表或設(shè)計成多級分區(qū)。 核心的維表產(chǎn)出時間通常有嚴格的要求。
設(shè)計維表的主要步驟如下：
完成維度的初步定義，并保證維度的一致性。 確定主維表（中心事實表，本教程中采用 星型模型）。此處的主維表通常是數(shù)據(jù)引入層（ODS）表，直接與業(yè)務(wù)系統(tǒng)同步。例如，s_auction是與前臺商品中心系統(tǒng)同步的商品表，此表即是主維表。確定相關(guān)維表。數(shù)據(jù)倉庫是業(yè)務(wù)源系統(tǒng)的數(shù)據(jù)整合，不同業(yè)務(wù)系統(tǒng)或者同一業(yè)務(wù)系統(tǒng)中的表之間存在關(guān)聯(lián)性。根據(jù)對業(yè)務(wù)的梳理，確定哪些表和主維表存在關(guān)聯(lián)關(guān)系，并選擇其中的某些表用于生成維度屬性。以商品維度為例，根據(jù)對業(yè)務(wù)邏輯的梳理，可以得到商品與類目、賣家、店鋪等維度存在關(guān)聯(lián)關(guān)系。 確定維度屬性，主要包括兩個階段。第一個階段是從主維表中選擇維度屬性或生成新的維度屬性；第二個階段是從相關(guān)維表中選擇維度屬性或生成新的維度屬性。以商品維度為例，從主維表（s_auction）和類目 、賣家、店鋪等相關(guān)維表中選擇維度屬性或生成新的維度屬性。
盡可能生成豐富的維度屬性。
盡可能多地給出富有意義的文字性描述。
區(qū)分數(shù)值型屬性和事實。
盡量沉淀出通用的維度屬性。
公共維度匯總層（DIM）維表規(guī)范
公共維度匯總層（DIM）維表命名規(guī)范：dim_{業(yè)務(wù)板塊名稱/pub}_{維度定義}[_{自定義命名標簽}]，所謂pub是與具體業(yè)務(wù)板塊無關(guān)或各個業(yè)務(wù)板塊都可公用的維度，如時間維度。
舉例如下：
公共區(qū)域維表dim_pub_area A公司電商板塊的商品全量表dim_asale_itm
建表示例
CREATE TABLE IF NOT EXISTS dim_asale_itm
(
item_id BIGINT COMMENT '商品ID',
item_title STRING COMMENT '商品名稱',
item_price DOUBLE COMMENT '商品成交價格_元',
item_stuff_status BIGINT COMMENT '商品新舊程度_0全新1閑置2二手',
cate_id BIGINT COMMENT '商品類目ID',
cate_name STRING COMMENT '商品類目名稱',
commodity_id BIGINT COMMENT '品類ID',
commodity_name STRING COMMENT '品類名稱',
umid STRING COMMENT '買家ID',
item_status BIGINT COMMENT '商品狀態(tài)_0正常1用戶刪除2下架3未上架',
city STRING COMMENT '商品所在城市',
prov STRING COMMENT '商品所在省份'
)
COMMENT '商品全量表'
PARTITIONED BY (ds STRING COMMENT '日期,yyyymmdd');
CREATE TABLE IF NOT EXISTS dim_pub_area
(
buyer_id STRING COMMENT '買家ID',
city_code STRING COMMENT '城市code',
city_name STRING COMMENT '城市名稱',
prov_code STRING COMMENT '省份code',
prov_name STRING COMMENT '省份名稱'
)
COMMENT '公共區(qū)域維表'
PARTITIONED BY (ds STRING COMMENT '日期分區(qū)，格式y(tǒng)yyymmdd')
LIFECYCLE 3600;
3. 明細粒度事實層（DWD）
明細粒度事實層以業(yè)務(wù)過程驅(qū)動建模，基于每個具體的業(yè)務(wù)過程特點，構(gòu)建最細粒度的明細層事實表。您可以結(jié)合企業(yè)的數(shù)據(jù)使用特點，將明細事實表的某些重要維度屬性字段做適當冗余，即寬表化處理。
公共匯總粒度事實層（DWS）和明細粒度事實層（DWD）的事實表作為數(shù)據(jù)倉庫維度建模的核心，需緊繞業(yè)務(wù)過程來設(shè)計。通過獲取描述業(yè)務(wù)過程的度量來描述業(yè)務(wù)過程，包括引用的維度和與業(yè)務(wù)過程有關(guān)的度量。度量通常為數(shù)值型數(shù)據(jù)，作為事實邏輯表的依據(jù)。事實邏輯表的描述信息是事實屬性，事實屬性中的外鍵字段通過對應(yīng)維度進行關(guān)聯(lián)。
事實表中一條記錄所表達的業(yè)務(wù)細節(jié)程度被稱為粒度。通常粒度可以通過兩種方式來表述：一種是維度屬性組合所表示的細節(jié)程度，一種是所表示的具體業(yè)務(wù)含義。
作為度量業(yè)務(wù)過程的事實，通常為整型或浮點型的十進制數(shù)值，有可加性、半可加性和不可加性三種類型：
可加性事實是指可以按照與事實表關(guān)聯(lián)的任意維度進行匯總。 半可加性事實只能按照特定維度匯總，不能對所有維度匯總。例如庫存可以按照地點和商品進行匯總，而按時間維度把一年中每個月的庫存累加則毫無意義。 完全不可加性，例如比率型事實。對于不可加性的事實，可分解為可加的組件來實現(xiàn)聚集。
事實表相對維表通常更加細長，行增加速度也更快。維度屬性可以存儲到事實表中，這種存儲到事實表中的維度列稱為維度退化，可加快查詢速度。與其他存儲在維表中的維度一樣，維度退化可以用來進行事實表的過濾查詢、實現(xiàn)聚合操作等。
明細粒度事實層（DWD）通常分為三種：事務(wù)事實表、周期快照事實表和累積快照事實表，詳情請參見數(shù)倉建設(shè)指南。
事務(wù)事實表用來描述業(yè)務(wù)過程，跟蹤空間或時間上某點的度量事件，保存的是最原子的數(shù)據(jù)，也稱為原子事實表。 周期快照事實表以具有規(guī)律性的、可預(yù)見的時間間隔記錄事實。 累積快照事實表用來表述過程開始和結(jié)束之間的關(guān)鍵步驟事件，覆蓋過程的整個生命周期，通常具有多個日期字段來記錄關(guān)鍵時間點。當累積快照事實表隨著生命周期不斷變化時，記錄也會隨著過程的變化而被修改。
明細粒度事實表設(shè)計原則
明細粒度事實表設(shè)計原則如下所示：
通常，一個明細粒度事實表僅和一個維度關(guān)聯(lián)。 盡可能包含所有與業(yè)務(wù)過程相關(guān)的事實 。 只選擇與業(yè)務(wù)過程相關(guān)的事實。 分解不可加性事實為可加的組件。 在選擇維度和事實之前必須先聲明粒度。 在同一個事實表中不能有多種不同粒度的事實。 事實的單位要保持一致。 謹慎處理Null值。 使用退化維度提高事實表的易用性。 明細粒度事實表整體設(shè)計流程如下圖所示。
在一致性度量中已定義好了交易業(yè)務(wù)過程及其度量。明細事實表注意針對業(yè)務(wù)過程進行模型設(shè)計。明細事實表的設(shè)計可以分為四個步驟：選擇業(yè)務(wù)過程、確定粒度、選擇維度、確定事實（度量）。粒度主要是在維度未展開的情況下記錄業(yè)務(wù)活動的語義描述。在您建設(shè)明細事實表時，需要選擇基于現(xiàn)有的表進行明細層數(shù)據(jù)的開發(fā)，清楚所建表記錄存儲的是什么粒度的數(shù)據(jù)。
明細粒度事實層（DWD）規(guī)范
通常您需要遵照的命名規(guī)范為：dwd_{業(yè)務(wù)板塊/pub}_{數(shù)據(jù)域縮寫}_{業(yè)務(wù)過程縮寫}[_{自定義表命名標簽縮寫}] _{單分區(qū)增量全量標識}，pub表示數(shù)據(jù)包括多個業(yè)務(wù)板塊的數(shù)據(jù)。單分區(qū)增量全量標識通常為：i表示增量，f表示全量。例如：dwd_asale_trd_ordcrt_trip_di（A電商公司航旅機票訂單下單事實表，日刷新增量）及dwd_asale_itm_item_df（A電商商品快照事實表，日刷新全量）。
本教程中，DWD層主要由三個表構(gòu)成：
交易商品信息事實表：dwd_asale_trd_itm_di。
交易會員信息事實表：ods_asale_trd_mbr_di。
交易訂單信息事實表：dwd_asale_trd_ord_di。
建表示例（dwd_asale_trd_itm_di）
CREATE TABLE IF NOT EXISTS dwd_asale_trd_itm_di
(
item_id BIGINT COMMENT '商品ID',
item_title STRING COMMENT '商品名稱',
item_price DOUBLE COMMENT '商品價格',
item_stuff_status BIGINT COMMENT '商品新舊程度_0全新1閑置2二手',
item_prov STRING COMMENT '商品省份',
item_city STRING COMMENT '商品城市',
cate_id BIGINT COMMENT '商品類目ID',
cate_name STRING COMMENT '商品類目名稱',
commodity_id BIGINT COMMENT '品類ID',
commodity_name STRING COMMENT '品類名稱',
buyer_id BIGINT COMMENT '買家ID',
)
COMMENT '交易商品信息事實表'
PARTITIONED BY (ds STRING COMMENT '日期')
LIFECYCLE 400;
4. 公共匯總粒度事實層（DWS）
明細粒度 ==> 匯總粒度
公共匯總粒度事實層以分析的主題對象作為建模驅(qū)動，基于上層的應(yīng)用和產(chǎn)品的指標需求構(gòu)建公共粒度的匯總指標事實表。公共匯總層的一個表通常會對應(yīng)一個派生指標。
公共匯總事實表設(shè)計原則
聚集是指針對原始明細粒度的數(shù)據(jù)進行匯總。DWS公共匯總層是面向分析對象的主題聚集建模。在本教程中，最終的分析目標為：最近一天某個類目（例如：廚具）商品在各省的銷售總額、該類目Top10銷售額商品名稱、各省用戶購買力分布。因此，我們可以以最終交易成功的商品、類目、買家等角度對最近一天的數(shù)據(jù)進行匯總。
聚集是不跨越事實的。聚集是針對原始星形模型進行的匯總。為獲取和查詢與原始模型一致的結(jié)果，聚集的維度和度量必須與原始模型保持一致，因此聚集是不跨越事實的。 聚集會帶來查詢性能的提升，但聚集也會增加ETL維護的難度。當子類目對應(yīng)的一級類目發(fā)生變更時，先前存在的、已經(jīng)被匯總到聚集表中的數(shù)據(jù)需要被重新調(diào)整。
此外，進行DWS層設(shè)計時還需遵循以下原則：
數(shù)據(jù)公用性： 需考慮匯總的聚集是否可以提供給第三方使用。您可以判斷，基于某個維度的聚集是否經(jīng)常用于數(shù)據(jù)分析中。如果答案是肯定的，就有必要把明細數(shù)據(jù)經(jīng)過匯總沉淀到聚集表中。 不跨數(shù)據(jù)域： 數(shù)據(jù)域是在較高層次上對數(shù)據(jù)進行分類聚集的抽象。數(shù)據(jù)域通常以業(yè)務(wù)過程進行分類，例如交易統(tǒng)一劃到交易域下，商品的新增、修改放到商品域下。 區(qū)分統(tǒng)計周期： 在表的命名上要能說明數(shù)據(jù)的統(tǒng)計周期，例如 _1d表示最近1天，td表示截至當天，nd表示最近N天。
公共匯總事實表規(guī)范
公共匯總事實表命名規(guī)范：dws_{業(yè)務(wù)板塊縮寫/pub}_{數(shù)據(jù)域縮寫}_{數(shù)據(jù)粒度縮寫}[_{自定義表命名標簽縮寫}]_{統(tǒng)計時間周期范圍縮寫}。關(guān)于統(tǒng)計實際周期范圍縮寫，缺省情況下，離線計算應(yīng)該包括最近一天（_1d），最近N天（_nd）和歷史截至當天（_td）三個表。如果出現(xiàn)_nd的表字段過多需要拆分時，只允許以一個統(tǒng)計周期單元作為原子拆分。即一個統(tǒng)計周期拆分一個表，例如最近7天（_1w）拆分一個表。不允許拆分出來的一個表存儲多個統(tǒng)計周期。
對于小時表（無論是天刷新還是小時刷新），都用_hh來表示。對于分鐘表（無論是天刷新還是小時刷新），都用_mm來表示。
舉例如下：dws_asale_trd_byr_subpay_1d（A電商公司買家粒度交易分階段付款一日匯總事實表）
dws_asale_trd_byr_subpay_td（A電商公司買家粒度分階段付款截至當日匯總表）
dws_asale_trd_byr_cod_nd（A電商公司買家粒度貨到付款交易匯總事實表）
dws_asale_itm_slr_td（A電商公司賣家粒度商品截至當日存量匯總表）
dws_asale_itm_slr_hh（A電商公司賣家粒度商品小時匯總表）---維度為小時
dws_asale_itm_slr_mm（A電商公司賣家粒度商品分鐘匯總表）---維度為分鐘
建表示例
滿足業(yè)務(wù)需求的DWS層建表語句如下
CREATE TABLE IF NOT EXISTS dws_asale_trd_byr_ord_1d
(
buyer_id BIGINT COMMENT '買家ID',
buyer_nick STRING COMMENT '買家昵稱',
mord_prov STRING COMMENT '收貨人省份',
cate_id BIGINT COMMENT '商品類目ID',
cate_name STRING COMMENT '商品類目名稱',
confirm_paid_amt_sum_1d DOUBLE COMMENT '最近一天訂單已經(jīng)確認收貨的金額總和'
)
COMMENT '買家粒度所有交易最近一天匯總事實表'
PARTITIONED BY (ds STRING COMMENT '分區(qū)字段YYYYMMDD')
LIFECYCLE 36000;
CREATE TABLE IF NOT EXISTS dws_asale_trd_itm_ord_1d
(
item_id BIGINT COMMENT '商品ID',
item_title STRING COMMENT '商品名稱',
cate_id BIGINT COMMENT '商品類目ID',
cate_name STRING COMMENT '商品類目名稱',
mord_prov STRING COMMENT '收貨人省份',
confirm_paid_amt_sum_1d DOUBLE COMMENT '最近一天訂單已經(jīng)確認收貨的金額總和'
)
COMMENT '商品粒度交易最近一天匯總事實表'
PARTITIONED BY (ds STRING COMMENT '分區(qū)字段YYYYMMDD')
LIFECYCLE 36000;
層次調(diào)用規(guī)范
在完成數(shù)據(jù)倉庫的分層后，您需要對各層次的數(shù)據(jù)之間的調(diào)用關(guān)系作出約定。
ADS應(yīng)用層優(yōu)先調(diào)用數(shù)據(jù)倉庫公共層數(shù)據(jù)。如果已經(jīng)存在CDM層數(shù)據(jù)，不允許ADS應(yīng)用層跨過CDM中間層從ODS層重復(fù)加工數(shù)據(jù)。CDM中間層應(yīng)該積極了解應(yīng)用層數(shù)據(jù)的建設(shè)需求，將公用的數(shù)據(jù)沉淀到公共層，為其他數(shù)據(jù)層次提供數(shù)據(jù)服務(wù)。同時，ADS應(yīng)用層也需積極配合CDM中間層進行持續(xù)的數(shù)據(jù)公共建設(shè)的改造。避免出現(xiàn)過度的ODS層引用、不合理的數(shù)據(jù)復(fù)制和子集合冗余?？傮w遵循的層次調(diào)用原則如下：
ODS層數(shù)據(jù)不能直接被應(yīng)用層任務(wù)引用。如果中間層沒有沉淀的ODS層數(shù)據(jù)，則通過CDM層的視圖訪問。CDM層視圖必須使用調(diào)度程序進行封裝，保持視圖的可維護性與可管理性。 CDM層任務(wù)的深度不宜過大（建議不超過10層）。 一個計算刷新任務(wù)只允許一個輸出表，特殊情況除外。 如果多個任務(wù)刷新輸出一個表（不同任務(wù)插入不同的分區(qū)），DataWorks上需要建立一個虛擬任務(wù)，依賴多個任務(wù)的刷新和輸出。通常，下游應(yīng)該依賴此虛擬任務(wù)。 CDM匯總層優(yōu)先調(diào)用CDM明細層，可累加指標計算。CDM匯總層盡量優(yōu)先調(diào)用已經(jīng)產(chǎn)出的粗粒度匯總層，避免大量匯總層數(shù)據(jù)直接從海量的明細數(shù)據(jù)層中計算得出。 CDM明細層累計快照事實表優(yōu)先調(diào)用CDM事務(wù)型事實表，保持數(shù)據(jù)的一致性產(chǎn)出。 有針對性地建設(shè)CDM公共匯總層，避免應(yīng)用層過度引用和依賴CDM層明細數(shù)據(jù)。