2. 程式人生 > >【資料倉庫】5.如何優雅地設計資料分層

【資料倉庫】5.如何優雅地設計資料分層

阿新 • • 發佈：2018-12-03

0x00 前言

一、文章主題

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

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

  • 資料建設剛起步，大部分的資料經過粗暴的資料接入後就直接對接業務。

  • 資料建設發展到一定階段，發現數據的使用雜亂無章，各種業務都是從原始資料直接計算而得。

  • 各種重複計算，嚴重浪費了計算資源，需要優化效能。

二、文章結構

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

  1. 為什麼要分層？這個問題被好幾個同學質疑過。因此分層的價值還是要說清楚的。

  2. 分享一下經典的資料分層模型，以及每一層的資料的作用和如何加工得來。

  3. 分享兩個資料分層的設計，通過這兩個實際的例子來說明每一層該怎麼存資料。

  4. 給出一些建議，不是最好的，但是可以做參考。

0x01 為什麼要分層

我們對資料進行分層的一個主要原因就是希望在管理資料的時候，能對資料有一個更加清晰的掌控，詳細來講，主要有下面幾個原因：

  1. 清晰資料結構：每一個數據分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。

  2. 資料血緣追蹤：簡單來講可以這樣理解，我們最終給業務誠信的是一能直接使用的張業務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地定位到問題，並清楚它的危害範圍。

  3. 減少重複開發：規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算。

  4. 把複雜問題簡單化。講一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護資料的準確性，當資料出現問題之後，可以不用修復所有的資料，只需要從有問題的步驟開始修復。

  5. 遮蔽原始資料的異常。

  6. 遮蔽業務的影響，不必改一次業務就需要重新接入資料。

資料體系中的各個表的依賴就像是電線的流向一樣，我們都希望它是規整、流向清晰、便於管理的，如下圖：

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

0x02 怎樣分層

一、理論

我們從理論上來做一個抽象，可以把資料倉庫分為下面三個層，即：資料運營層、資料倉庫層和資料產品層。

1. ODS 全稱是 Operational Data Store，操作資料儲存

“面向主題的”，資料運營層，也叫ODS層，是最接近資料來源中資料的一層，資料來源中的資料，經過抽取、洗淨、傳輸，也就說傳說中的 ETL 之後，裝入本層。本層的資料，總體上大多是按照源頭業務系統的分類方式而分類的。

但是，這一層面的資料卻不等同於原始資料。在源資料裝入這一層時，要進行諸如去噪（例如有一條資料中人的年齡是 300 歲，這種屬於異常資料，就需要提前做一些處理）、去重（例如在個人資料表中，同一 ID 卻有兩條重複資料，在接入的時候需要做一步去重）、欄位命名規範等一系列操作。

2. 資料倉庫層(DW)，是資料倉庫的主體

在這裡，從 ODS 層中獲得的資料按照主題建立各種資料模型。這一層和維度建模會有比較深的聯絡，可以多參考一下前面的幾篇文章。

3. 資料產品層（APP），這一層是提供為資料產品使用的結果資料

在這裡，主要是提供給資料產品和資料分析使用的資料，一般會存放在 ES、Mysql 等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供資料分析和資料探勘使用。
比如我們經常說的報表資料，或者說那種大寬表，一般就放在這裡。

二、技術實踐

這三層技術劃分，相對來說比較粗粒度，後面我們會專門細分一下。在此之前，先聊一下每一層的資料一般都是怎麼流向的。這裡僅僅簡單介紹幾個常用的工具，側重中開源界主流。

1. 資料來源層→ ODS層

這裡其實就是我們現在大資料技術發揮作用的一個主要戰場。 我們的資料主要會有兩個大的來源：

  1. 業務庫，這裡經常會使用 Sqoop 來抽取，比如我們每天定時抽取一次。在實時方面，可以考慮用 Canal 監聽 Mysql 的 Binlog，實時接入即可。

  2. 埋點日誌，線上系統會打入各種日誌，這些日誌一般以檔案的形式儲存，我們可以選擇用 Flume 定時抽取，也可以用用 Spark Streaming 或者 Storm 來實時接入，當然，Kafka 也會是一個關鍵的角色。

  3. 其它資料來源會比較多樣性，這和具體的業務相關，不再贅述。

     

注意： 在這層，理應不是簡單的資料接入，而是要考慮一定的資料清洗，比如異常欄位的處理、欄位命名規範化、時間欄位的統一等，一般這些很容易會被忽略，但是卻至關重要。特別是後期我們做各種特徵自動生成的時候，會十分有用。後續會有文章來分享。

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 總結

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

另外，每一層的名字不必太過在意，自己按照喜好就好。

本文分享了筆者自己對資料倉庫的一些理解和想法，不一定準確也不一定通用，但是可以作為一個參考的思路。有什麼問題歡迎多交流。

轉載

相關推薦

【資料倉庫】5.如何優雅地設計資料分層

0x00 前言 一、文章主題 本文主要講解資料倉庫的一個重要環節：如何設計資料分層！其它關於資料倉庫的內容可參考之前的文章。 本文對資料分層的討論適合下面一些場景，超過該範圍場景 or 資料倉庫經驗豐富的大神就不必浪費時間看了。 資料建設剛起步，大部分的資

【資料倉庫】6. ETL 的設計

0x00 前言 資料倉庫體系裡面的主要內容也寫的差不多了，現在補一點之前遺漏的點。這一篇就來聊一下 ETL。 文章結構 先聊一下什麼是 ETL。 聊一下大致的概念和一般意義上的理解。 聊一聊資料流是什麼樣子。因為 ETL 的工作主要會體現在一條條的資料處理流上，因此這裡做一個

資料倉庫系列——4.如何優雅地設計資料分層

一、文章主題 本文主要講解資料倉庫的一個重要環節：如何設計資料分層!其它關於資料倉庫的內容可參考之前的文章。 本文對資料分層的討論適合下面一些場景，超過該範圍場景 or 資料倉庫經驗豐富的大神就不必浪費時間看了。 資料建設剛起步，大部分的資料經過粗暴的資料接入後就直接對

【資料倉庫】2.維度建模

0x00 前言 前一篇已經對常用的幾種資料模型做了簡單的介紹，本篇主要對其中最常用的維度建模做一個深入的理解。 0x01 什麼是維度建模 維度模型是資料倉庫領域另一位大師 Ralph Kimball 所倡導，他的《The DataWarehouse Toolkit-The Complet

【資料倉庫】1.資料模型

0x00 前言 翻出來之前零零散散寫的資料倉庫的內容，重新修正整理成一個系列，此為第一篇《資料模型》。 資料倉庫包含的內容很多，比如系統架構、建模和方法論。對應到具體工作中的話，它可以包含下面的這些內容： 以Hadoop、Spark、Hive等元件為中心的資料架構體系

【資料倉庫】6.資料質量監控

0x00 前言 往往那些不起眼的功能，最能毀掉你的工作成果。 本篇分享一些和資料質量監控相關的內容。資料質量監控是一個在快速發展的業務中最容易被犧牲和忽略的功能，但是它確實至關重要的。 文章結構 資料質量監控的意義和價值就不再談了，本文主要討論下面三個主題：

【資料倉庫】4. 拉鍊表

0x00 前言 過了半年時間，對資料倉庫的理解又有了一些不同的認識，翻出來之前寫的關於拉鍊表的內容，稍作修改重新發出來。本篇將會談一談在資料倉庫中拉鍊表相關的內容，包括它的原理、設計、以及在我們大資料場景下的實現方式。 內容 全文由下面幾個部分組成： 先分享一下拉鍊表的用途、

【資料倉庫】3.緩慢變化維度（SCD）

0x00 前言 本文會分享資料倉庫中和緩慢變化維度相關的內容。在看之前建議回顧一下和維度建模相關的知識點，可參考這篇：No.12 【漫談資料倉庫】維度建模。 為什麼會分享這個聽起來很奇怪的東西？因為站在的筆者的視角中，只要是做資料倉庫的小夥伴們，在工作中基本上都會接觸和維度建模相關的內容，而

【資料倉庫】資料模型

0x00 前言 翻出來之前零零散散寫的資料倉庫的內容，重新修正整理成一個系列，此為第一篇《資料模型》。 資料倉庫包含的內容很多，比如系統架構、建模和方法論。對應到具體工作中的話，它可以包含下面的這些內容： 以Hadoop、Spark、Hive等元件為中心的資料架構體

【資料倉庫】3. 拉鍊表

0x00 前言 過了半年時間，對資料倉庫的理解又有了一些不同的認識，翻出來之前寫的關於拉鍊表的內容，稍作修改重新發出來。本篇將會談一談在資料倉庫中拉鍊表相關的內容，包括它的原理、設計、以及在我們大資料場景下的實現方式。 內容 全文由下面幾個部分組成： 先分享一下拉

uoj#269. 【清華集訓2016】如何優雅地求和（FFT）

傳送門 題解： 把fff二項式變換一下就行了，變換可以用二項式反演。 #include <bits/stdc++.h> using namespace std; const int RLEN=1<<18|1; inline char n

【資料結構】5.1 順序表的查詢以及二分查詢的實現

類的結構如下： class StaticSearchTable { private: int *data; int data_number; bool search_seq(int loc,int key); void select_sort(); bool f

【sklearn例項】5--資料標準化/歸一化

標準化&歸一化 Standardization: z-score標準化（-1 ~ 1） 將資料均值轉化為0，標準差轉化為1。處理後的資料符合標準正態分佈。 Normalization: min-max歸一化（0 ~ 1） 利用最大最

【深度學習】5：CNN卷積神經網路原理、識別MNIST資料集

前言：先坦白的說，深度神經網路的學習在一開始對我造成的困擾還是很大的，我也是通過不斷地看相關的視訊資料、文獻講解嘗試去理解記憶。畢竟這些內容大多都是不可查的，我們看到的都只是輸入輸出的東西，裡面的內部運作以及工作原理，都需要沉心靜思。 這篇CNN卷積神經網路的

uoj#269. 【清華集訓2016】如何優雅地求和（數論）

傳送門 首先，如果\(f(x)=1\)，那麼根據二項式定理，有\(Q(f,n,k)=1\) 當\(f(x)=x\)的時候，有\[Q=\sum_{i=0}^ni\times \frac{n!}{i!(n-i)!}k^i(1-k)^{n-i}\] \[Q=\sum_{i=0}^nnk\times \frac{

【資料倉庫】大資料定義

      2012年Gartner公司將大資料定義為3V，即：大容量（Volume）、高流速（Velocity）、多樣化（Variety），後來人們在3V基礎上增加新的V-"Veracity"，即真

【資料倉庫】資料集市

概念 資料集市是資料倉庫的一種簡單形式，通常由組織內的業務部門自己建立。一個數據集市面向單一主題，如銷售、財務、市場等。資料集市的資料來源可以是是操作型系統（獨立資料集市），也可以是資料倉庫（從屬資料

【高並發解決方案】5、如何設計一個秒殺系統

電商 進程 atom 統架構 多用戶 能力 如果能 後臺 寫鎖 https://www.cnblogs.com/wangzhongqiu/p/6557596.html 什麽是秒殺 秒殺場景一般會在電商網站舉行一些活動或者節假日在12306網站上搶票時遇到。對於電商網站中

UOJ269. 【清華集訓2016】如何優雅地求和 [生成函數]

原來 pen ini inline ble bits spl n! ali 傳送門 思路 神仙題.jpg 腦子一抽，想把\(f(x)\)表示成下降冪的形式，也就是 \[ f(x)=\sum_{i=0}^m f_ix_{(i)}\x_{(i)}=\prod_{k=0}^{i-

【商城應用】商品運費流程設計

我們在購買商品的時候都會涉及到運費，運費無非就兩種：一種是包郵，一種是非包郵。包郵的簡單，直接不管運費就可以了，非包郵就相對比較複雜了，這邊就給大家介紹一下，如何通過運費模板來實現非包郵的情況。 需求分析： 在開始設計之前我們先來分析一下影響運費的幾種情況： 目標地址 商