數據倉庫—開發規範

數據倉庫系列文章(持續更新)

數倉架構發展史
數倉建模方法論
數倉建模分層理論
數倉建模—寬表的設計
數倉建模—指標體系
數據倉庫之拉鍊表
數倉—數據集成
數倉—數據集市
數倉—商業智能系統
數倉—埋點設計與管理
數倉—ID Mapping
數倉—OneID
數倉—AARRR海盜模型
數倉—總線矩陣
數倉—數據安全
數倉—數據質量
數倉—數倉建模和業務建模

關注公衆號：大數據技術派，回覆: 資料，領取1024G資料。

凡事無規矩不立，所以你會經常看到各種各樣的規範，面對規範需要遵守，但是不能盲目，例如我們開發人員最常看到的就是《Mysql 開發規範》、《Java 編程手冊》、《Java 開發規範》之類的東西，這些東西的出發點有三方面：

提高性能
避免錯誤
方便管理

其實很多規範都是這三方都相關的，但是我們今天介紹的數倉規範主要是爲了避免錯誤和方便管理，其實方便管理這個話題我們前面說了好多次了，這裏你可以參考前面的文章數倉建模—分層建設理論、數倉建模—數據集市這些在一定程度上來說都是爲了方便管理。

數據層次的劃分

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

ODS：Operational Data Store，操作數據層，在結構上其與源系統的增量或者全量數據基本保持一致。它相當於一個數據準備區，同時又承擔着基礎數據的記錄以及歷史變化。其主要作用是把基礎數據引入到數倉。
CDM：Common Data Model，公共維度模型層，又細分爲DWD和DWS。它的主要作用是完成數據加工與整合、建立一致性的維度、構建可複用的面向分析和統計的明細事實表以及彙總公共粒度的指標。
- DWD：Data Warehouse Detail，明細數據層。
- DWS：Data Warehouse Summary，彙總數據層。
ADS：Application Data Service，應用數據層。

數據分類架構

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

公共維度層：基於維度建模理念思想，建立整個企業的一致性維度。
明細粒度事實層：以業務過程爲建模驅動，基於每個具體業務過程的特點，構建最細粒度的明細層事實表。您可以結合企業的數據使用特點，將明細事實表的某些重要維度屬性字段做適當的冗餘，即寬表化處理。
公共彙總粒度事實層：以分析的主題對象爲建模驅動，基於上層的應用和產品的指標需求，構建公共粒度的彙總指標事實表，以寬表化手段來物理化模型。

數據劃分及命名約定

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

數據劃分

按業務劃分：命名時按主要的業務劃分，以指導物理模型的劃分原則、命名原則及使用的ODS project。
按數據域劃分：命名時按照CDM層的數據進行數據域劃分，以便有效地對數據進行管理，以及指導數據表的命名。
按業務過程劃分：當一個數據域由多個業務過程組成時，命名時可以按業務流程劃分。業務過程是從數據分析角度看客觀存在的或者抽象的業務行爲動作。

命名約定

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

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。
同步任務命名規範任務名：建議和表名保持一致。

dim 層命名規範

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

公共區域維表dim_pub_area
公司社羣板塊的羣成員全量表dim_group_member

dwd 層命名規範

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

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

dws 層命名規範

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

關於統計實際週期範圍縮寫，缺省情況下，離線計算應該包括最近一天（_1d），最近N天（_nd）和歷史截至當天（_td）三個表。
對於小時表（無論是天刷新還是小時刷新），都用_hh 來表示。
對於分鐘表（無論是天刷新還是小時刷新），都用_mm來表示。

舉例如下：

dws_group_patient_join_1d（公司社羣患者加羣一日彙總事實表）
dws_group_patient_exit_td（公司社羣患者退羣截至當日彙總表）

層次調用約定

應用層應優先調用公共層數據，必須存在中間層數據，不允許應用層跨過中間層從ODS層重複加工數據。一方面，中間層人員應該積極瞭解應用層數據的建設需求，將公用的數據沉澱到公共層，爲其他人員提供數據服務；另一方面，應用層人員也應積極配合中間層人員進行持續的數據公共建設的改造。必須避免出現過度的引用ODS層、不合理的數據複製以及子集合冗餘。

ODS層數據不能被應用層任務引用，中間層不能有沉澱的ODS層數據，必須通過CDM層的視圖訪問。CDM層視圖必須使用調度程序進行封裝，保持視圖的可維護性與可管理性。
CDM層任務的深度不宜過大（建議不超過10層）。
原則上一個計算刷新任務只允許一個輸出表。
如果多個任務刷新輸出一個表（不同任務插入不同的分區），DataWorks上需要建立一個依賴多個刷新任務的虛擬任務，通常下游應該依賴此虛擬任務。
CDM彙總層應優先調用CDM明細層。在調用可累加類指標計算時，CDM彙總層儘量優先調用已經產出的粗粒度彙總層，以避免大量彙總直接從海量的明細數據層計算。
CDM明細層累計快照事實表優先調用CDM事務型事實表，以保持數據的一致性產出。
避免應用層過度引用和依賴CDM層明細數據，需要針對性地建設好CDM公共彙總層。

數據類型規範

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類型。

公共字段定義規範

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

按天分區：ds(YYYYMMDD)。
按小時分區：hh(00-23)。
按分鐘：mi (00-59)。
is_{業務}：表示布爾型數據字段。以Y和N表示，不允許出現空值域。
原則上不需要冗餘分區字段。

數據冗餘

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

冗餘字段與表中其它字段高頻率（大於3個下游應用SQL）同時訪問。
冗餘字段的引入不應造成其本身的刷新完成時間產生過多後延。
公共層數據不允許字段重複率大於60%的相同粒度數據表冗餘，可以選擇在原表基礎上拓寬或者在下游應用中通過JOIN方式實現。

數據拆分

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

在物理上劃分核心模型和擴展模型，將其字段進行垂直劃分。
將訪問相關度較高的列在一個表存儲，將訪問相關度較低的字段分開存儲。
將經常用到的Where條件按記錄行進行水平切分或者冗餘。水平切分可以考慮二級分區手段，以避免多餘的數據複製與冗餘。
將出現大量空值和零值的統計彙總表，依據其空值和零值分佈狀況可以做適當的水平和垂直切分，以減少存儲和下游的掃描數據量。

空值處理原則

彙總類指標的空值：空值處理，填充爲零
維度屬性值爲空：在彙總到對應維度上時，對於無法對應的統計事實，記錄行會填充爲-99（未知），對應維表會出現一條-99（未知）的記錄。

設計準則

一致性維度規範

公共層的維度表中相同維度屬性在不同物理表中的字段名稱、數據類型、數據內容必須保持一致。除了以下情況：
- 在不同的實際物理表中，如果由於維度角色的差異，需要使用其他的名稱，其他名稱也必須是規範的維度屬性的別名。例如，定義一個標準的會員ID時，如果在一個表中，分別要表示買家ID，賣家ID，那麼設計規範階段就預先對會員ID分別定義買家ID和賣家ID。
- 如果由於歷史原因，在暫時不一致的情況下，必須在規範的維度定義一個標準維度屬性，不同的物理名也必須是來自標準維度屬性的別名。
維度的組合與拆分
- 組合原則
  - 將維度所描述業務相關性強的字段在一個物理維表實現。相關性強是指經常需要一起查詢或進行報表展現、兩個維度屬性間是否存在天然的關係等。例如，商品基本屬性和所屬品牌。
  - 無相關性的維度可以適當考慮雜項維度（例如交易），可以構建一個交易雜項維度收集交易的特殊標記屬性、業務分類等信息。也可以將雜項維度退化在事實表中處理，不過容易造成事實表相對龐大，加工處理較爲複雜。
  - 所謂的行爲維度是經過彙總計算的指標，在下游的應用使用時將其當維度處理。如果有需要，度量指標可以作爲行爲維度冗餘到維度表中。
- 拆分與冗餘
  - 對於維度屬性過多，涉及源較多的維度表（例如會員表），可以做適當拆分：
    - 拆分爲核心表和擴展表。核心表相對字段較少，刷新產出時間較早，優先使用。擴展表字段較多，且可以冗餘核心表部分字段，刷新產出時間較晚，適合數據分析人員使用。
    - 根據維度屬性的業務不相關性，將相關度不大的維度屬性拆分爲多個物理表存儲。
  - 數據記錄數較大的維度表（例如商品表），可以適當冗餘一些子集合，以減少下游掃描數據量：
    - 可以根據當天是否有行爲，產出一個有活躍行爲的相關維表，以減少應用的數據掃描量。
    - 可根據所屬業務掃描數據範圍大小的不同，進行適當子集合冗餘。

數據存儲及生命週期管理規範

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

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

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

總結

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

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