資料倉庫系列文章(持續更新)

1. 數倉架構發展史
2. 數倉建模方法論
3. 數倉建模分層理論
4. 數倉建模—寬表的設計
5. 數倉建模—指標體系
6. 資料倉庫之拉鍊表
7. 數倉—資料整合
8. 數倉—資料集市
9. 數倉—商業智慧系統
10. 數倉—埋點設計與管理
11. 數倉—ID Mapping
12. 數倉—OneID
13. 數倉—AARRR海盜模型
14. 數倉—匯流排矩陣
15. 數倉—資料安全
16. 數倉—資料質量
17. 數倉—數倉建模和業務建模

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

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

1. 提高效能
2. 避免錯誤
3. 方便管理

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

資料層次的劃分

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

• 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資料型別

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,但是這個東西只要大家認可就行，但是不能因為不認可就不遵守。

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