『 懶人10分鐘—大數據篇（一）』數據建模是什麼？

• 2019 年 10 月 8 日
• 筆記

數據模型是什麼？帶你了解大數據技術架構。 —— 23號老闆

0

1

概念

原創：lianxiaobao

文章概覽

|— 概念

|— 建模方法

|— 模型層次劃分

|— 數據模型規範

|— 建模指導 ODS

|— ODS常用的設計方法

|— 應用場景

1、什麼是數據模型？

數據模型就是數據的組織和存儲方法。主要關注的是從業務、數據存取和使用角度合理存儲數據。

2、典型數據倉庫建模方法

– 範式模型

– ER實體關係模型

– 緯度模型

建模四步曲：確定業務流程->確定粒度->確定緯度->確定事實表

3、模型層次劃分

ADS

該層為應用數據層，根據業務需求組織數據 該層支持百花齊放、儘可能都依賴DWS，特殊情況可依賴DWD的數據， 該層定期需要定期review，將公共指標沉澱到DWS中

DWS

該層按不同粒度、維度對明細數據進行統計匯總產生或算法產生的各類標籤數據，包括用於減少數據量的多維分析子層、單粒度單維度的基礎標籤子層，和多粒度多維度易用性更強的寬表標籤子層

DWD

該層對分來源明細數據進行數據清洗、過濾、記歷史等操作， 並完成多來源同類明細數據的融合操作，包括分來源基礎數據子層和融合數據子層

ODS

如果下游有stage層，則該層在stage層的基礎上僅完成源數據格式到標準數據格式轉換工作 如果下游無stage層，則業務源系統數據接入到此層，此層數據不做任何加工，禁止重複進入。

STG

業務源系統數據接入到此層，此層數據不做任何加工，禁止重複進入。

DIM

該層為公共維表層，該層獨立於DWD、DWS、ADS，為DWD、DWS、ADS提供維度字段說明。

EVL

該層為數據質量評估層，該層獨立於ODS、DWD、DWS、ADS、DIM以外，對ODS、DWD、DWS、ADS、DIM的數據質量進行評估，存儲評估指標數據。

4、數據模型規範

– 物理、邏輯模型設計規範

– 標準編碼規範

– 中英文縮寫規範

0

2

理解

下面我就對如何建模做一些簡單的介紹，如果想更細緻的學習數倉知識推薦《阿里巴巴——大數據之路》。

建模指導

ODS，全稱是Operational Data Store 操作數據存儲。根據「數據倉庫之父」 的BIll.Inmon《數據倉庫》中對ODS的定義：

數據倉庫是一個面向主題的、集成的、隨時間變化的、當前的細節數據集合，用於支持企業對於即時性、操作性、集成的全體信息的需求；

而Kimball 在《數據倉庫工具箱》中是這樣定義ODS：

a、操作型系統的集成，用於當前、歷史以及其他細節查詢（業務系統的一部分）；

b、為決策支持提供當前細節數據（數據倉庫的一部分）；

因此ODS是用於支持企業日常的全局應用的數據集合，ODS的數據具有面向主題、集成的、可變的以及數據是當前的或是接近當前的這4個基本特徵。 同樣也可以看出ods 是基於DB和DW之間的一種數據存儲技術。

需要注意的是Kimball所說的ODS落地在操作系統（即 關係型數據庫），但是在實際生產中，ODS往往是物理落在數據倉庫中。

ODS和業務系統（DB）、數據倉庫（DW）的關係

ods和業務系統的主要差異在於兩者之間面向業務需求是不同的，業務系統是面向多並發讀寫同時具有滿足數據的一致性，而ODS數據是面向數據報表等批量數據查詢需求。

(1)集成方式不同，ODS不像業務系統會因為性能壓力需要對同一個邏輯表進行分庫操作，也不會根據業務劃分在物理上進行分庫分表。ODS會將業務系統中同一個邏輯表統一到一個物理實體中存儲，並且會對重複冗餘、不符合業務規則對臟數據清洗、統一編碼。

(2)業務系統在數據上需要嚴格遵循三範式、並且需要創建相對複雜的索引結構來提升系統效率，而ODS在數據主外鍵和索引上不需要投入大量的系統資源。

(3)兩者存儲系統不一樣 業務系統通常都是Oracle、Mysql、DB2等以食物處理見長的數據型系統，ODS往往落在Hadoop等分佈式系統

與原來面嚮應用等分散的業務系統相比，ODS中的數據組織方式和DW 一樣也是面向主題和集成的，所以對進入ODS的數據也進入數據倉庫的數據一樣進行集成處理。面向主題和集成性得ODS數據在靜態特徵上很接近DW中的數據但兩者之間還是存在許多基本和重要的區別的：

ODS只是存放當前或者接近當前的數據，如果需要的話還可以對ODS中的數據進行增刪更新等操作。

但DW中的數據一般不進行修改，所以兩者的區別主要體現在可變性、當前性、穩定性、匯總性上。

0

3

ODS常用設計

1、ods表的抽取一般分為三部分

文件抽取、數據庫抽取和原始日誌的抽取

文件同步的系統架構圖：

數據庫直連同步：

數據庫日誌抽取：

原始日誌的抽取一般是採用logfile或者前端js代碼的方式直接在後端部署日誌採集不同的業務採用不同的形式就不再做圖。

2、數據質量處理

(1) 數據質量的基本要求是數據的五大特性：準確性，及時性，一致性，完整性，邏輯性。

(2) 數據監控

一般是串行或者並行。串行適用於比較重要的稽核，需要打斷ETL任務的繼續執行並行使用與部署很重要的稽核指標 不會影響ETL的繼續執行。

(3) 數據清洗

在落庫之前需要做額外的加工處理後在做入庫操作。數據清洗的主要對象是那些不符合要求的數據，具體為不合格的數據，錯誤的數據，重複的數據。

3、ods表設計

(1) 命名規則：不管是表命名還是字段命名盡量保持和業務系統一致，但是要通過標示來區分增量和全量表

(2) 存儲方式：為滿足歷史數據分析需求我們需要在ods中增加一個時間維度，這個維度我們通常在ods表中作為分區字段

增量存儲：按天為單位的增量存儲，即用業務日期作為分區，沒個分區存放日增量的業務數據

全量存儲：以天為單位的全量存儲，即用業務日期作為分區，沒個分區存放截止到業務日期未知的全量的業務數據

歷史拉鏈數據：是指利用維度模型中緩慢變化的處理方式，真宗方式是通過新增兩個時間戳字段（start_dt和end_dt）將所有的以天為單位的變更數據都記錄下來。

極限數據：全量數據對於下游使用方存在一定的理解障礙，另一方面全量存儲隨着時間的推移分區數據會極度膨脹，而現行的系統都有分區數量限制所以為解決上述兩個問題，提出極限存儲的方式處理。

a、透明化處理也就是通過在hive中添加hook或者視圖的方式分析語法對sql分析轉換為對應的極限hql；

b、分月做拉鏈數據。

0

4

小結

ods表的設計方案主要從以下幾個角度考慮：

1、應用需求 （是否為全量存儲，生命周期的考慮）

2、產出性能（抽取方式會帶來不同的性能）

3、存儲成本

4、數據質量

未完待續……

下篇將對ods中一些問題和挑戰以及數倉中dwd，dws等維度分析進行總結介紹。