【漫談數據倉庫】 如何優雅地設計數據分層 ODS DW DM層級

轉載http://bigdata.51cto.com/art/201710/554810.htm

1、文章主題

本文主要講解數據倉庫的一個重要環節：如何設計數據分層!其它關於數據倉庫的內容可參考以前的文章。

本文對數據分層的討論適合下面一些場景，超過該範圍場景 or 數據倉庫經驗豐富的大神就沒必要浪費時間看了。

• 數據建設剛起步，大部分的數據通過粗暴的數據接入後就直接對接業務。
• 數據建設發展到必定階段，發現數據的使用雜亂無章，各類業務都是從原始數據直接計算而得。
• 各類重複計算，嚴重浪費了計算資源，須要優化性能。

2、文章結構

最初在作數據倉庫的時候遇到了不少坑，因爲自身資源有限，接觸數據倉庫的時候，感受在互聯網行業裏面的數據倉庫成功經驗不多，網上很難找到實踐性比較強的資料。而那幾本經典書籍裏面又過於理論，折騰起來真是生不如死。還好如今過去了那個坎，所以多花一些時間整理本身的思路，幫助其餘的小夥伴少踩一些坑。文章的結構以下：

• 爲何要分層?這個問題被好幾個同窗質疑過。所以分層的價值仍是要說清楚的。
• 分享一下經典的數據分層模型，以及每一層的數據的做用和如何加工得來。
• 分享兩個數據分層的設計，經過這兩個實際的例子來講明每一層該怎麼存數據。
• 給出一些建議，不是最好的，可是能夠作參考。

0x01 爲何要分層

咱們對數據進行分層的一個主要緣由就是但願在管理數據的時候，能對數據有一個更加清晰的掌控，詳細來說，主要有下面幾個緣由：

• 清晰數據結構：每個數據分層都有它的做用域，這樣咱們在使用表的時候能更方便地定位和理解。
• 數據血緣追蹤：簡單來說能夠這樣理解，咱們最終給業務誠信的是一能直接使用的張業務表，可是它的來源有不少，若是有一張來源表出問題了，咱們但願可以快速準確地定位到問題，並清楚它的危害範圍。
• 減小重複開發：規範數據分層，開發一些通用的中間層數據，可以減小極大的重複計算。
• 把複雜問題簡單化。講一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。並且便於維護數據的準確性，當數據出現問題以後，能夠不用修復全部的數據，只須要從有問題的步驟開始修復。
• 屏蔽原始數據的異常。
• 屏蔽業務的影響，沒必要改一次業務就須要從新接入數據。

數據體系中的各個表的依賴就像是電線的流向同樣，咱們都但願它是規整、流向清晰、便於管理的，以下圖：

可是，最終的結果大多倒是依賴複雜、層級混亂，想梳理清楚一張表的聲稱途徑會比較困難，以下圖：

0x02 怎樣分層

1、理論

咱們從理論上來作一個抽象，能夠把數據倉庫分爲下面三個層，即：數據運營層、數據倉庫層和數據產品層。

• ODS 全稱是 Operational Data Store，操做數據存儲.「面向主題的」，數據運營層，也叫ODS層，是最接近數據源中數據的一層，數據源中的數據，通過抽取、洗淨、傳輸，也就說傳說中的 ETL 以後，裝入本層。本層的數據，整體上大可能是按照源頭業務系統的分類方式而分類的。可是，這一層面的數據卻不等同於原始數據。在源數據裝入這一層時，要進行諸如去噪(例若有一條數據中人的年齡是 300 歲，這種屬於異常數據，就須要提早作一些處理)、去重(例如在我的資料表中，同一 ID 卻有兩條重複數據，在接入的時候須要作一步去重)、字段命名規範等一系列操做。
• 數據倉庫層(DW)，是數據倉庫的主體.在這裏，從 ODS 層中得到的數據按照主題創建各類數據模型。這一層和維度建模會有比較深的聯繫，能夠多參考一下前面的幾篇文章。
• 數據產品層(APP)，這一層是提供爲數據產品使用的結果數據

在這裏，主要是提供給數據產品和數據分析使用的數據，通常會存放在 ES、Mysql 等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供數據分析和數據挖掘使用。

如咱們常常說的報表數據，或者說那種大寬表，通常就放在這裏。

2、技術實踐

這三層技術劃分，相對來講比較粗粒度，後面咱們會專門細分一下。在此以前，先聊一下每一層的數據通常都是怎麼流向的。這裏僅僅簡單介紹幾個經常使用的工具，側重中開源界主流。

1. 數據來源層→ ODS層

這裏其實就是咱們如今大數據技術發揮做用的一個主要戰場。 咱們的數據主要會有兩個大的來源：

業務庫，這裏常常會使用 Sqoop 來抽取，好比咱們天天定時抽取一次。在實時方面，能夠考慮用 Canal 監聽 Mysql 的 Binlog，實時接入便可。

埋點日誌，線上系統會打入各類日誌，這些日誌通常以文件的形式保存，咱們能夠選擇用 Flume 定時抽取，也能夠用用 Spark Streaming 或者 Storm 來實時接入，固然，Kafka 也會是一個關鍵的角色。

其它數據源會比較多樣性，這和具體的業務相關，再也不贅述。

注意： 在這層，理應不是簡單的數據接入，而是要考慮必定的數據清洗，好比異常字段的處理、字段命名規範化、時間字段的統一等，通常這些很容易會被忽略，可是卻相當重要。特別是後期咱們作各類特徵自動生成的時候，會十分有用。後續會有文章來分享。

2. ODS、DW → App層

這裏面也主要分兩種類型：

1. 每日定時任務型：好比咱們典型的日計算任務，天天凌晨算前一天的數據，早上起來看報表。 這種任務常用 Hive、Spark 或者生擼 MR 程序來計算，最終結果寫入 Hive、Hbase、Mysql、Es 或者 Redis 中。
2. 實時數據：這部分主要是各類實時的系統使用，好比咱們的實時推薦、實時用戶畫像，通常咱們會用 Spark Streaming、Storm 或者 Flink 來計算，最後會落入 Es、Hbase 或者 Redis 中。

0x03 舉個例子

網上的例子不少，就不列了，只舉個筆者早期參與設計的數據分層例子。分析一下當初的想法，以及這種設計的缺陷。上原圖和內容。

當初的設計總共分了 6 層，其中去掉元數據後，還有5層。下面分析一下當初的一個設計思路。

緩衝層(buffer)

• 概念：又稱爲接口層(stage)，用於存儲天天的增量數據和變動數據，如Canal接收的業務變動日誌。
• 數據生成方式：直接從kafka接收源數據，須要業務表天天生成update,delete,inseret數據，只生成insert數據的業務表，數據直接入明細層
• 討論方案：只把canal日誌直接入緩衝層，若是其它有拉鍊數據的業務，也入緩衝層。
• 日誌存儲方式：使用impala外表，parquet文件格式，方便須要MR處理的數據讀取。
• 日誌刪除方式：長久存儲，可只存儲最近幾天的數據。討論方案：直接長久存儲
• 表schema：通常按天建立分區
• 庫與表命名。庫名：buffer,表名：初步考慮格式爲：buffer日期業務表名,待定。

明細層(ODS, Operational Data Store,DWD: data warehouse detail)

• 概念：是數據倉庫的細節數據層，是對STAGE層數據進行沉澱，減小了抽取的複雜性，同時ODS/DWD的信息模型組織主要遵循企業業務事務處理的形式，將各個專業數據進行集中，明細層跟stage層的粒度一致，屬於分析的公共資源
• 數據生成方式：部分數據直接來自kafka，部分數據爲接口層數據與歷史數據合成。

canal日誌合成數據的方式待研究。

• 討論方案：canal數據的合成方式爲：天天把明細層的前天全量數據和昨天新數據合成一個新的數據表，覆蓋舊錶。同時使用歷史鏡像，按周/按月/按年 存儲一個歷史鏡像到新表。
• 日誌存儲方式：直接數據使用impala外表，parquet文件格式，canal合成數據爲二次生成數據，建議使用內表，下面幾層都是從impala生成的數據，建議都用內表+靜態/動態分區。
• 日誌刪除方式：長久存儲。
• 表schema：通常按天建立分區，沒有時間概念的按具體業務選擇分區字段。
• 庫與表命名。庫名：ods,表名：初步考慮格式爲ods日期業務表名,待定。
• 舊數據更新方式：直接覆蓋

輕度彙總層(MID或DWB, data warehouse basis)

• 概念：輕度彙總層數據倉庫中DWD層和DM層之間的一個過渡層次，是對DWD層的生產數據進行輕度綜合和彙總統計(能夠把複雜的清洗，處理包含，如根據PV日誌生成的會話數據)。輕度綜合層與DWD的主要區別在於兩者的應用領域不一樣，DWD的數據來源於生產型系統，並未滿意一些不可預見的需求而進行沉澱;輕度綜合層則面向分析型應用進行細粒度的統計和沉澱
• 數據生成方式：由明細層按照必定的業務需求生成輕度彙總表。明細層須要複雜清洗的數據和須要MR處理的數據也通過處理後接入到輕度彙總層。
• 日誌存儲方式：內表，parquet文件格式。
• 日誌刪除方式：長久存儲。
• 表schema：通常按天建立分區，沒有時間概念的按具體業務選擇分區字段。
• 庫與表命名。庫名：dwb,表名：初步考慮格式爲：dwb日期業務表名,待定。
• 舊數據更新方式：直接覆蓋

主題層(DM，data market或DWS, data warehouse service)

• 概念：又稱數據集市或寬表。按照業務劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用於提供後續的業務查詢，OLAP分析，數據分發等。
• 數據生成方式：由輕度彙總層和明細層數據計算生成。
• 日誌存儲方式：使用impala內表，parquet文件格式。
• 日誌刪除方式：長久存儲。
• 表schema：通常按天建立分區，沒有時間概念的按具體業務選擇分區字段。
• 庫與表命名。庫名：dm,表名：初步考慮格式爲：dm日期業務表名,待定。
• 舊數據更新方式：直接覆蓋

應用層(App)

• 概念：應用層是根據業務須要，由前面三層數據統計而出的結果，能夠直接提供查詢展示，或導入至Mysql中使用。
• 數據生成方式：由明細層、輕度彙總層，數據集市層生成，通常要求數據主要來源於集市層。
• 日誌存儲方式：使用impala內表，parquet文件格式。
• 日誌刪除方式：長久存儲。
• 表schema：通常按天建立分區，沒有時間概念的按具體業務選擇分區字段。
• 庫與表命名。庫名：暫定apl，另外根據業務不一樣，不限定必定要一個庫。
• 舊數據更新方式：直接覆蓋。

0x04 如何更優雅一些

前面提到的一種設計其實相對來說已經很詳細了，可是可能層次會有一點多，並且在區分一張表到底該存放在什麼位置的時候可能還有不小的疑惑。咱們在這一章裏再設計一套數據倉庫的分層，同時在前面的基礎上加上維表和一些臨時表的考慮，來讓咱們的方案更優雅一些。

下圖，作了一些小的改動，咱們去掉了上一節的Buffer層，把數據集市層和輕度彙總層放在同一個層級上，同時獨立出來了維表和臨時表。

這裏解釋一下DWS、DWD、DIM和TMP的做用。

• DWS：輕度彙總層，從ODS層中對用戶的行爲作一個初步的彙總，抽象出來一些通用的維度：時間、ip、id，並根據這些維度作一些統計值，好比用戶每一個時間段在不一樣登陸ip購買的商品數等。這裏作一層輕度的彙總會讓計算更加的高效，在此基礎上若是計算僅7天、30天、90天的行爲的話會快不少。咱們但願80%的業務都能經過咱們的DWS層計算，而不是ODS。
• DWD：這一層主要解決一些數據質量問題和數據的完整度問題。好比用戶的資料信息來自於不少不一樣表，並且常常出現延遲丟數據等問題，爲了方便各個使用方更好的使用數據，咱們能夠在這一層作一個屏蔽。
• DIM：這一層比較單純，舉個例子就明白，好比國家代碼和國家名、地理位置、中文名、國旗圖片等信息就存在DIM層中。
• TMP：每一層的計算都會有不少臨時表，專設一個DWTMP層來存儲咱們數據倉庫的臨時表。

0x05 問答

有朋友問了一些問題，有一些以前的確沒講清楚，補到這裏。

問答一： dws 和 dwd 的關係

問：dws 和dwd 是並行而不是前後順序?

答：並行的，dw 層

問：那其實對於同一個數據，這兩個過程是串行的?

答：dws 會作彙總，dwd 和 ods 的粒度相同，這兩層之間也沒有依賴的關係

問：對呀，那這樣 dws 裏面的彙總沒有通過數據質量和完整度的處理，或者單獨作了這種質量相關的處理，爲何不在 dwd 之上再作彙總呢?個人疑問其實就是，dws的輕度彙總數據結果，有沒有作數據質量的處理?

答：ods 直接到 dws 就好，不必過 dwd，我舉個例子，你的瀏覽商品行爲，我作一層輕度彙總，就直接放在 dws 了。可是你的資料表，要從好多表湊成一份，咱們從四五份我的資料表中湊出來了一份完整的資料表放在了 dwd 中。而後在 app 層，咱們要出一張畫像表，包含用戶資料和用戶近一年的行爲，咱們就直接從dwd中拿資料， 而後再在 dws 的基礎上作一層統計，就成一個app表了。固然，這不是絕對，dws 和 dwd 有沒有依賴關係主要看有沒有這種需求。

問答二： ods 和 dwd 的區別

問：仍是不太明白 ods 和 dwd 層的區別，有了 ods 層後感受 dwd 沒有什麼用了。

答：嗯，我是這樣理解的，站在一個理想的角度來說，若是 ods 層的數據就很是規整，基本能知足咱們絕大部分的需求，這固然是好的，這時候 dwd 層其實也沒太大必要。 可是現實中接觸的狀況是 ods 層的數據很難保證質量，畢竟數據的來源多種多樣，推送方也會有本身的推送邏輯，在這種狀況下，咱們就須要經過額外的一層 dwd 來屏蔽一些底層的差別。

問：我大概明白了，是否是說 dwd 主要是對 ods 層作一些數據清洗和規範化的操做，dws 主要是對 ods 層數據作一些輕度的彙總?

答：對的，能夠大體這樣理解。

問答三：app 層是幹什麼的?

問：感受數據集市層是否是沒地方放了，各個業務的數據集市表是應該在 dwd 仍是在 app?

答：這個問題不太好回答，我感受主要就是明確一下數據集市層是幹什麼的，若是你的數據集市層放的就是一些能夠供業務方使用的寬表表，放在 app 層就行。若是你說的數據集市層是一個比較泛一點的概念，那麼其實 dws、dwd、app 這些合起來都算是數據集市的內容。

問：那存到 Redis、ES 中的數據算是 app層嗎?

答：算是的，我我的的理解，app 層主要存放一些相對成熟的表，能供業務側使用的。這些表能夠在 Hive 中，也能夠是從 Hive 導入 Redis 或者 ES 這種查詢性能比較好的系統中。

0xFF 總結

數據分層是數據倉庫很是重要的一個環節，它決定的不只僅是一個層次的問題，還直接影響到血緣分析、特徵自動生成、元數據管理等一系列功能的建設。所以適於儘早考慮。

另外，每一層的名字沒必要太過在乎，本身按照喜愛就好。

本文分享了筆者本身對數據倉庫的一些理解和想法，不必定準確也不必定通用，可是能夠做爲一個參考的思路。有什麼問題歡迎多交流。