01數據層次的劃分

具體倉庫的分層情況需要結合業務場景、數據場景、系統場景進行綜合考慮，下面我們看一下常見的分層：

ODS：Operational Data Store，操作數據層，在結構上其與源系統的增量或者全量數據基本保持一致。它相當于一個數據準備區，同時又承擔著基礎數據的記錄以及歷史變化。其主要作用是把基礎數據引入到數倉。

CDM：Common Data Model，公共維度模型層，又細分為DWD和DWS。它的主要作用是完成數據加工與整合、建立一致性的維度、構建可復用的面向分析和統計的明細事實表以及匯總公共粒度的指標。

DWD：Data Warehouse Detail，明細數據層。 DWS：Data Warehouse Summary，匯總數據層。

ADS：Application Data Service，應用數據層。

02數據分類架構

該數據分類架構在ODS層分為三部分：數據準備區、離線數據和準實時數據區。在進入到CDM層后，由以下幾部分組成：

公共維度層：基于維度建模理念思想，建立整個企業的一致性維度。

明細粒度事實層：以業務過程為建模驅動，基于每個具體業務過程的特點，構建最細粒度的明細層事實表。您可以結合企業的數據使用特點，將明細事實表的某些重要維度屬性字段做適當的冗余，即寬表化處理。

公共匯總粒度事實層：以分析的主題對象為建模驅動，基于上層的應用和產品的指標需求，構建公共粒度的匯總指標事實表，以寬表化手段來物理化模型。

03數據劃分及命名約定

請根據業務劃分數據并約定命名，建議針對業務名稱結合數據層次約定相關命名的英文縮寫，這樣可以給后續數據開發過程中，對項目空間、表、字段等命名做為重要參照。

（1）數據劃分

按業務劃分：命名時按主要的業務劃分，以指導物理模型的劃分原則、命名原則及使用的ODS project。

按數據域劃分：命名時按照CDM層的數據進行數據域劃分，以便有效地對數據進行管理，以及指導數據表的命名。

按業務過程劃分：當一個數據域由多個業務過程組成時，命名時可以按業務流程劃分。業務過程是從數據分析角度看客觀存在的或者抽象的業務行為動作。

（2）命名約定

如果公司業務線比較多，我們可以按照項目的模式進行劃分，如果不是直接按照層次劃分，project_ods、project_dwd

（3）ODS層命名規范

表命名規范 表命名規則：{層次}{源系統表名}{時間單位與增全量},i表示增量，f表示全量 ,d 表示天, h表示小時

增量數據：{project_name}.s{源系統表名}_di。

全量數據：{project_name}.s{源系統表名}_df。

ODS ETL過程的臨時表：{project_name}.tmp{臨時表所在過程的輸出表}{從0開始的序號}。

按小時同步的增量表：{project_name}.s{源系統表名}_hi。

按小時同步的全量表：{project_name}.s{源系統表名}_hf。

當不同源系統同步到同一個Project下的表命名沖突時，您需要給同步較晚的表名加上源系統的dbname以解決沖突。

字段命名規范 ?字段默認使用源系統的字段名。

字段名與關鍵字沖突時，在源字段名后加上_col，即源字段名_col。

同步任務命名規范 ?任務名：建議和表名保持一致。

（4）dim 層命名規范

命名規則：{project_name}.dim{業務/pub}{維度定義}[_{自定義命名標簽}]，其中的pub與具體業務無關，各個業務部都可以共用，例如時間維度。

公共區域維表dim_pub_area

公司社群板塊的群成員全量表dim_group_member

（5）dwd ?層命名規范

通常需要遵照的命名規范為：dwd_{業務板塊/pub}{數據域縮寫}{業務過程縮寫}[_{自定義表命名標簽縮寫}] _{單分區增量全量標識}，pub表示數據包括多個業務板塊的數據。

單分區增量全量標識通常為：i表示增量，f表示全量。例如：dwd_group_create_inf_df（公司社群創建事實表，日刷新全量）及dwd_group_chat_di（公司社群發消息事實表，日刷新增量）。

（6）dws 層命名規范

公共匯總事實表命名規范：dws_{業務板塊縮寫/pub}{數據域縮寫}{數據粒度縮寫}[{自定義表命名標簽縮寫}]{統計時間周期范圍縮寫}。

關于統計實際周期范圍縮寫，缺省情況下，離線計算應該包括最近一天（_1d），最近N天（_nd）和歷史截至當天（_td）三個表。

對于小時表（無論是天刷新還是小時刷新），都用_hh 來表示。

對于分鐘表（無論是天刷新還是小時刷新），都用_mm來表示。

舉例如下：

dws_group_patient_join_1d（公司社群患者加群一日匯總事實表）

dws_group_patient_exit_td（公司社群患者退群截至當日匯總表）

04層次調用約定

應用層應優先調用公共層數據，必須存在中間層數據，不允許應用層跨過中間層從ODS層重復加工數據。一方面，中間層人員應該積極了解應用層數據的建設需求，將公用的數據沉淀到公共層，為其他人員提供數據服務。

另一方面，應用層人員也應積極配合中間層人員進行持續的數據公共建設的改造。必須避免出現過度的引用ODS層、不合理的數據復制以及子集合冗余。

ODS層數據不能被應用層任務引用，中間層不能有沉淀的ODS層數據，必須通過CDM層的視圖訪問。CDM層視圖必須使用調度程序進行封裝，保持視圖的可維護性與可管理性。

CDM層任務的深度不宜過大（建議不超過10層）。

原則上一個計算刷新任務只允許一個輸出表。

如果多個任務刷新輸出一個表（不同任務插入不同的分區），DataWorks上需要建立一個依賴多個刷新任務的虛擬任務，通常下游應該依賴此虛擬任務。

CDM匯總層應優先調用CDM明細層。在調用可累加類指標計算時，CDM匯總層盡量優先調用已經產出的粗粒度匯總層，以避免大量匯總直接從海量的明細數據層計算。

CDM明細層累計快照事實表優先調用CDM事務型事實表，以保持數據的一致性產出。

避免應用層過度引用和依賴CDM層明細數據，需要針對性地建設好CDM公共匯總層。

05數據類型規范

ODS層的數據類型應基于源系統數據類型轉換。例如，源數據為MySQL時的轉換規則如下。

MySQL數據類型和Hive數據類型：

MySQL數據類型	Hive 數據類型
TINYINT	TINYINT
SMALLINT/MEDIUMINT	SMALLINT
INTEGER	INT
BIGINT	BIGINT
FLOAT	FLOAT
DOUBLE	DOUBLE
DECIMAL	DECIMAL
CHAR/VARCHAR	VARCHAR
LONGTEXT/TEXT	STRING
DATE/TIMESTAMP/TIME/YEAR	STRING
DATETIME	DATETIME

CDM數據公共層如果是引用ODS層數據，則默認使用ODS層字段的數據類型。其衍生加工數據字段按以下標準執行：

金額類及其它小數點數據使用DOUBLE類型。

字符類數據使用STRING類型。

ID類和整形數值使用BIGINT類型。

時間類型數據使用STRING類型（如果有特殊的格式要求，可以選擇性使用DATETIME類型）。

狀態使用STRING類型。

06公共字段定義規范

數據統計日期的分區字段按以下標準：

按天分區：ds(YYYYMMDD)。

按小時分區：hh(00-23)。

按分鐘：mi (00-59)。

is_{業務}：表示布爾型數據字段。以Y和N表示，不允許出現空值域。

原則上不需要冗余分區字段。

07數據冗余

一個表做寬表冗余維度屬性時，應該遵循以下建議準則：

冗余字段與表中其它字段高頻率（大于3個下游應用SQL）同時訪問。

冗余字段的引入不應造成其本身的刷新完成時間產生過多后延。

公共層數據不允許字段重復率大于60%的相同粒度數據表冗余，可以選擇在原表基礎上拓寬或者在下游應用中通過JOIN方式實現。

08數據拆分

數據的水平和垂直拆分是按照訪問熱度分布和數據表非空數據值、零數據值在行列二維空間上分布情況進行劃分的。

在物理上劃分核心模型和擴展模型，將其字段進行垂直劃分。

將訪問相關度較高的列在一個表存儲，將訪問相關度較低的字段分開存儲。

將經常用到的Where條件按記錄行進行水平切分或者冗余。水平切分可以考慮二級分區手段，以避免多余的數據復制與冗余。

將出現大量空值和零值的統計匯總表，依據其空值和零值分布狀況可以做適當的水平和垂直切分，以減少存儲和下游的掃描數據量。

09空值處理原則

匯總類指標的空值：空值處理，填充為零。

維度屬性值為空：在匯總到對應維度上時，對于無法對應的統計事實，記錄行會填充為-99（未知），對應維表會出現一條-99（未知）的記錄。

10設計準則

一致性維度規范

公共層的維度表中相同維度屬性在不同物理表中的字段名稱、數據類型、數據內容必須保持一致。除了以下情況：

在不同的實際物理表中，如果由于維度角色的差異，需要使用其他的名稱，其他名稱也必須是規范的維度屬性的別名。例如，定義一個標準的會員ID時，如果在一個表中，分別要表示買家ID，賣家ID，那么設計規范階段就預先對會員ID分別定義買家ID和賣家ID。 如果由于歷史原因，在暫時不一致的情況下，必須在規范的維度定義一個標準維度屬性，不同的物理名也必須是來自標準維度屬性的別名。

維度的組合與拆分

對于維度屬性過多，涉及源較多的維度表（例如會員表），可以做適當拆分。 數據記錄數較大的維度表（例如商品表），可以適當冗余一些子集合，以減少下游掃描數據量。 拆分為核心表和擴展表。核心表相對字段較少，刷新產出時間較早，優先使用。擴展表字段較多，且可以冗余核心表部分字段，刷新產出時間較晚，適合數據分析人員使用。 根據維度屬性的業務不相關性，將相關度不大的維度屬性拆分為多個物理表存儲。 可以根據當天是否有行為，產出一個有活躍行為的相關維表，以減少應用的數據掃描量。 可根據所屬業務掃描數據范圍大小的不同，進行適當子集合冗余。 將維度所描述業務相關性強的字段在一個物理維表實現。相關性強是指經常需要一起查詢或進行報表展現、兩個維度屬性間是否存在天然的關系等。例如，商品基本屬性和所屬品牌。 無相關性的維度可以適當考慮雜項維度（例如交易），可以構建一個交易雜項維度收集交易的特殊標記屬性、業務分類等信息。也可以將雜項維度退化在事實表中處理，不過容易造成事實表相對龐大，加工處理較為復雜。 所謂的行為維度是經過匯總計算的指標，在下游的應用使用時將其當維度處理。如果有需要，度量指標可以作為行為維度冗余到維度表中。 組合原則。 拆分與冗余。?

11數據存儲及生命周期管理規范

CDM公共維度層的表的類型為維度表，存儲方式為按天分區。

模型設計者根據自身業務需求設置表的生命周期管理。您可依據3個月內的最大需要訪問的跨度設置保留策略，具體計算方式如下：

當3個月內的最大訪問跨度小于或等于4天時，建議將保留天數設為7天。 當3個月內的最大訪問跨度小于或等于12天時，建議將保留天數設為15天。 當3個月內的最大訪問跨度小于或等于30天時， 建議將保留天數設為33天。 當3個月內的最大訪問跨度小于或等于90天時，建議將保留天數設為93天。 當3個月內的最大訪問跨度小于或等于180天時， 建議將保留天數設為183天。 當3個月內的最大訪問跨度小于或等于365天時，建議將保留天數設為368天。 12總結

其實規范這個東西很重要，但是有時候它的設計不那么可續，例如我們公司的天分區字段是ds而不是pt，但是這個東西只要大家認可就行，但是不能因為不認可就不遵守。

規范其實就是約定，所以需要大家共同去維護和遵守。