一、文章主題
本文主要講解數(shù)據(jù)倉庫的一個重要環(huán)節(jié)：如何設計數(shù)據(jù)分層！其它關于數(shù)據(jù)倉庫的內容可參考之前的文章。
本文對數(shù)據(jù)分層的討論適合下面一些場景，超過該范圍場景?or?數(shù)據(jù)倉庫經驗豐富的大神就不必浪費時間看了。
數(shù)據(jù)建設剛起步，大部分的數(shù)據(jù)經過粗暴的數(shù)據(jù)接入后就直接對接業(yè)務。數(shù)據(jù)建設發(fā)展到一定階段，發(fā)現(xiàn)數(shù)據(jù)的使用雜亂無章，各種業(yè)務都是從原始數(shù)據(jù)直接計算而得。各種重復計算，嚴重浪費了計算資源，需要優(yōu)化性能。二、文章結構
最初在做數(shù)據(jù)倉庫的時候遇到了很多坑，由于自身資源有限，接觸數(shù)據(jù)倉庫的時候，感覺在互聯(lián)網行業(yè)里面的數(shù)據(jù)倉庫成功經驗很少，網上很難找到實踐性比較強的資料。而那幾本經典書籍里面又過于理論，折騰起來真是生不如死。還好現(xiàn)在過去了那個坎，因此多花一些時間整理自己的思路，幫助其他的小伙伴少踩一些坑。文章的結構如下：
為什么要分層？這個問題被好幾個同學質疑過。因此分層的價值還是要說清楚的。分享一下經典的數(shù)據(jù)分層模型，以及每一層的數(shù)據(jù)的作用和如何加工得來。分享兩個數(shù)據(jù)分層的設計，通過這兩個實際的例子來說明每一層該怎么存數(shù)據(jù)。給出一些建議，不是最好的，但是可以做參考。0x01 為什么要分層
我們對數(shù)據(jù)進行分層的一個主要原因就是希望在管理數(shù)據(jù)的時候，能對數(shù)據(jù)有一個更加清晰的掌控，詳細來講，主要有下面幾個原因：
清晰數(shù)據(jù)結構：每一個數(shù)據(jù)分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。數(shù)據(jù)血緣追蹤：簡單來講可以這樣理解，我們最終給業(yè)務誠信的是一能直接使用的張業(yè)務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地定位到問題，并清楚它的危害范圍。減少重復開發(fā)：規(guī)范數(shù)據(jù)分層，開發(fā)一些通用的中間層數(shù)據(jù)，能夠減少極大的重復計算。把復雜問題簡單化。講一個復雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便于維護數(shù)據(jù)的準確性，當數(shù)據(jù)出現(xiàn)問題之后，可以不用修復所有的數(shù)據(jù)，只需要從有問題的步驟開始修復。屏蔽原始數(shù)據(jù)的異常。屏蔽業(yè)務的影響，不必改一次業(yè)務就需要重新接入數(shù)據(jù)。數(shù)據(jù)體系中的各個表的依賴就像是電線的流向一樣，我們都希望它是規(guī)整、流向清晰、便于管理的，如下圖：
但是，最終的結果大多卻是依賴復雜、層級混亂，想梳理清楚一張表的聲稱途徑會比較困難，如下圖：
0x02 怎樣分層
一、理論
我們從理論上來做一個抽象，可以把數(shù)據(jù)倉庫分為下面三個層，即：數(shù)據(jù)運營層、數(shù)據(jù)倉庫層和數(shù)據(jù)產品層。
在這里，主要是提供給數(shù)據(jù)產品和數(shù)據(jù)分析使用的數(shù)據(jù)，一般會存放在 ES、Mysql 等系統(tǒng)中供線上系統(tǒng)使用，也可能會存在 Hive 或者 Druid 中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用。
如我們經常說的報表數(shù)據(jù)，或者說那種大寬表，一般就放在這里。
二、技術實踐
這三層技術劃分，相對來說比較粗粒度，后面我們會專門細分一下。在此之前，先聊一下每一層的數(shù)據(jù)一般都是怎么流向的。這里僅僅簡單介紹幾個常用的工具，側重中開源界主流。
1. 數(shù)據(jù)來源層→ ODS層
這里其實就是我們現(xiàn)在大數(shù)據(jù)技術發(fā)揮作用的一個主要戰(zhàn)場。 我們的數(shù)據(jù)主要會有兩個大的來源：
業(yè)務庫，這里經常會使用 Sqoop 來抽取，比如我們每天定時抽取一次。在實時方面，可以考慮用 Canal 監(jiān)聽 Mysql 的 Binlog，實時接入即可。埋點日志，線上系統(tǒng)會打入各種日志，這些日志一般以文件的形式保存，我們可以選擇用 Flume 定時抽取，也可以用用 Spark Streaming 或者 Storm 來實時接入，當然，Kafka 也會是一個關鍵的角色。其它數(shù)據(jù)源會比較多樣性，這和具體的業(yè)務相關，不再贅述。
注意：?在這層，理應不是簡單的數(shù)據(jù)接入，而是要考慮一定的數(shù)據(jù)清洗，比如異常字段的處理、字段命名規(guī)范化、時間字段的統(tǒng)一等，一般這些很容易會被忽略，但是卻至關重要。特別是后期我們做各種特征自動生成的時候，會十分有用。后續(xù)會有文章來分享。
2. ODS、DW → App層
這里面也主要分兩種類型：
每日定時任務型：比如我們典型的日計算任務，每天凌晨算前一天的數(shù)據(jù)，早上起來看報表。 這種任務經常使用 Hive、Spark 或者生擼 MR 程序來計算，最終結果寫入 Hive、Hbase、Mysql、Es 或者 Redis 中。實時數(shù)據(jù)：這部分主要是各種實時的系統(tǒng)使用，比如我們的實時推薦、實時用戶畫像，一般我們會用 Spark Streaming、Storm 或者 Flink 來計算，最后會落入 Es、Hbase 或者 Redis 中。0x03 舉個例子
網上的例子很多，就不列了，只舉個筆者早期參與設計的數(shù)據(jù)分層例子。分析一下當初的想法，以及這種設計的缺陷。上原圖和內容。
當初的設計總共分了 6 層，其中去掉元數(shù)據(jù)后，還有5層。下面分析一下當初的一個設計思路。
緩沖層(buffer)
概念：又稱為接口層（stage），用于存儲每天的增量數(shù)據(jù)和變更數(shù)據(jù)，如Canal接收的業(yè)務變更日志。數(shù)據(jù)生成方式：直接從kafka接收源數(shù)據(jù)，需要業(yè)務表每天生成update,delete,inseret數(shù)據(jù)，只生成insert數(shù)據(jù)的業(yè)務表，數(shù)據(jù)直接入明細層討論方案：只把canal日志直接入緩沖層，如果其它有拉鏈數(shù)據(jù)的業(yè)務，也入緩沖層。日志存儲方式：使用impala外表，parquet文件格式，方便需要MR處理的數(shù)據(jù)讀取。日志刪除方式：長久存儲，可只存儲最近幾天的數(shù)據(jù)。討論方案：直接長久存儲表schema：一般按天創(chuàng)建分區(qū)庫與表命名。庫名：buffer,表名：初步考慮格式為：buffer日期業(yè)務表名,待定。明細層（ODS, Operational Data Store,DWD: data warehouse detail）
概念：是數(shù)據(jù)倉庫的細節(jié)數(shù)據(jù)層，是對STAGE層數(shù)據(jù)進行沉淀，減少了抽取的復雜性，同時ODS/DWD的信息模型組織主要遵循企業(yè)業(yè)務事務處理的形式，將各個專業(yè)數(shù)據(jù)進行集中，明細層跟stage層的粒度一致，屬于分析的公共資源數(shù)據(jù)生成方式：部分數(shù)據(jù)直接來自kafka，部分數(shù)據(jù)為接口層數(shù)據(jù)與歷史數(shù)據(jù)合成。canal日志合成數(shù)據(jù)的方式待研究。討論方案：canal數(shù)據(jù)的合成方式為：每天把明細層的前天全量數(shù)據(jù)和昨天新數(shù)據(jù)合成一個新的數(shù)據(jù)表，覆蓋舊表。同時使用歷史鏡像，按周/按月/按年 存儲一個歷史鏡像到新表。日志存儲方式：直接數(shù)據(jù)使用impala外表，parquet文件格式，canal合成數(shù)據(jù)為二次生成數(shù)據(jù)，建議使用內表，下面幾層都是從impala生成的數(shù)據(jù)，建議都用內表+靜態(tài)/動態(tài)分區(qū)。日志刪除方式：長久存儲。表schema：一般按天創(chuàng)建分區(qū)，沒有時間概念的按具體業(yè)務選擇分區(qū)字段。庫與表命名。庫名：ods,表名：初步考慮格式為ods日期業(yè)務表名,待定。舊數(shù)據(jù)更新方式：直接覆蓋
輕度匯總層(MID或DWB, data warehouse basis)
概念：輕度匯總層數(shù)據(jù)倉庫中DWD層和DM層之間的一個過渡層次，是對DWD層的生產數(shù)據(jù)進行輕度綜合和匯總統(tǒng)計（可以把復雜的清洗，處理包含，如根據(jù)PV日志生成的會話數(shù)據(jù)）。輕度綜合層與DWD的主要區(qū)別在于二者的應用領域不同，DWD的數(shù)據(jù)來源于生產型系統(tǒng)，并未滿意一些不可預見的需求而進行沉淀；輕度綜合層則面向分析型應用進行細粒度的統(tǒng)計和沉淀數(shù)據(jù)生成方式：由明細層按照一定的業(yè)務需求生成輕度匯總表。明細層需要復雜清洗的數(shù)據(jù)和需要MR處理的數(shù)據(jù)也經過處理后接入到輕度匯總層。日志存儲方式：內表，parquet文件格式。日志刪除方式：長久存儲。表schema：一般按天創(chuàng)建分區(qū)，沒有時間概念的按具體業(yè)務選擇分區(qū)字段。庫與表命名。庫名：dwb,表名：初步考慮格式為：dwb日期業(yè)務表名,待定。舊數(shù)據(jù)更新方式：直接覆蓋主題層（DM，data market或DWS, data warehouse service）
概念：又稱數(shù)據(jù)集市或寬表。按照業(yè)務劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用于提供后續(xù)的業(yè)務查詢，OLAP分析，數(shù)據(jù)分發(fā)等。數(shù)據(jù)生成方式：由輕度匯總層和明細層數(shù)據(jù)計算生成。日志存儲方式：使用impala內表，parquet文件格式。日志刪除方式：長久存儲。表schema：一般按天創(chuàng)建分區(qū)，沒有時間概念的按具體業(yè)務選擇分區(qū)字段。庫與表命名。庫名：dm,表名：初步考慮格式為：dm日期業(yè)務表名,待定。舊數(shù)據(jù)更新方式：直接覆蓋應用層(App)
概念：應用層是根據(jù)業(yè)務需要，由前面三層數(shù)據(jù)統(tǒng)計而出的結果，可以直接提供查詢展現(xiàn)，或導入至Mysql中使用。數(shù)據(jù)生成方式：由明細層、輕度匯總層，數(shù)據(jù)集市層生成，一般要求數(shù)據(jù)主要來源于集市層。日志存儲方式：使用impala內表，parquet文件格式。日志刪除方式：長久存儲。表schema：一般按天創(chuàng)建分區(qū)，沒有時間概念的按具體業(yè)務選擇分區(qū)字段。庫與表命名。庫名：暫定apl，另外根據(jù)業(yè)務不同，不限定一定要一個庫。舊數(shù)據(jù)更新方式：直接覆蓋。0x04 如何更優(yōu)雅一些
前面提到的一種設計其實相對來講已經很詳細了，但是可能層次會有一點多，而且在區(qū)分一張表到底該存放在什么位置的時候可能還有不小的疑惑。我們在這一章里再設計一套數(shù)據(jù)倉庫的分層，同時在前面的基礎上加上維表和一些臨時表的考慮，來讓我們的方案更優(yōu)雅一些。
下圖，做了一些小的改動，我們去掉了上一節(jié)的Buffer層，把數(shù)據(jù)集市層和輕度匯總層放在同一個層級上，同時獨立出來了維表和臨時表。
這里解釋一下DWS、DWD、DIM和TMP的作用。
DWS：輕度匯總層，從ODS層中對用戶的行為做一個初步的匯總，抽象出來一些通用的維度：時間、ip、id，并根據(jù)這些維度做一些統(tǒng)計值，比如用戶每個時間段在不同登錄ip購買的商品數(shù)等。這里做一層輕度的匯總會讓計算更加的高效，在此基礎上如果計算僅7天、30天、90天的行為的話會快很多。我們希望80%的業(yè)務都能通過我們的DWS層計算，而不是ODS。DWD：這一層主要解決一些數(shù)據(jù)質量問題和數(shù)據(jù)的完整度問題。比如用戶的資料信息來自于很多不同表，而且經常出現(xiàn)延遲丟數(shù)據(jù)等問題，為了方便各個使用方更好的使用數(shù)據(jù)，我們可以在這一層做一個屏蔽。DIM：這一層比較單純，舉個例子就明白，比如國家代碼和國家名、地理位置、中文名、國旗圖片等信息就存在DIM層中。TMP：每一層的計算都會有很多臨時表，專設一個DWTMP層來存儲我們數(shù)據(jù)倉庫的臨時表。0x05 問答
有朋友問了一些問題，有一些之前的確沒講清楚，補到這里。
問答一： dws 和 dwd 的關系
問：dws 和dwd 是并行而不是先后順序？
答：并行的，dw 層
問：那其實對于同一個數(shù)據(jù)，這兩個過程是串行的？
答：dws 會做匯總，dwd 和 ods 的粒度相同，這兩層之間也沒有依賴的關系
問：對呀，那這樣 dws 里面的匯總沒有經過數(shù)據(jù)質量和完整度的處理，或者單獨做了這種質量相關的處理，為什么不在 dwd 之上再做匯總呢？我的疑問其實就是，dws的輕度匯總數(shù)據(jù)結果，有沒有做數(shù)據(jù)質量的處理？
答：ods 直接到 dws 就好，沒必要過 dwd，我舉個例子，你的瀏覽商品行為，我做一層輕度匯總，就直接放在 dws 了。但是你的資料表，要從好多表湊成一份，我們從四五份個人資料表中湊出來了一份完整的資料表放在了 dwd 中。然后在 app 層，我們要出一張畫像表，包含用戶資料和用戶近一年的行為，我們就直接從dwd中拿資料， 然后再在 dws 的基礎上做一層統(tǒng)計，就成一個app表了。當然，這不是絕對，dws 和 dwd 有沒有依賴關系主要看有沒有這種需求。
問答二： ods 和 dwd 的區(qū)別
問：還是不太明白 ods 和 dwd 層的區(qū)別，有了 ods 層后感覺 dwd 沒有什么用了。
答：嗯，我是這樣理解的，站在一個理想的角度來講，如果 ods 層的數(shù)據(jù)就非常規(guī)整，基本能滿足我們絕大部分的需求，這當然是好的，這時候 dwd 層其實也沒太大必要。 但是現(xiàn)實中接觸的情況是 ods 層的數(shù)據(jù)很難保證質量，畢竟數(shù)據(jù)的來源多種多樣，推送方也會有自己的推送邏輯，在這種情況下，我們就需要通過額外的一層 dwd 來屏蔽一些底層的差異。
問：我大概明白了，是不是說 dwd 主要是對 ods 層做一些數(shù)據(jù)清洗和規(guī)范化的操作，dws 主要是對 ods 層數(shù)據(jù)做一些輕度的匯總？
答：對的，可以大致這樣理解。
問答三：app 層是干什么的？
問：感覺數(shù)據(jù)集市層是不是沒地方放了，各個業(yè)務的數(shù)據(jù)集市表是應該在 dwd 還是在 app？
答：這個問題不太好回答，我感覺主要就是明確一下數(shù)據(jù)集市層是干什么的，如果你的數(shù)據(jù)集市層放的就是一些可以供業(yè)務方使用的寬表表，放在 app 層就行。如果你說的數(shù)據(jù)集市層是一個比較泛一點的概念，那么其實 dws、dwd、app 這些合起來都算是數(shù)據(jù)集市的內容。
問：那存到 Redis、ES 中的數(shù)據(jù)算是 app層嗎？
答：算是的，我個人的理解，app 層主要存放一些相對成熟的表，能供業(yè)務側使用的。這些表可以在 Hive 中，也可以是從 Hive 導入 Redis 或者 ES 這種查詢性能比較好的系統(tǒng)中。
0xFF 總結
數(shù)據(jù)分層是數(shù)據(jù)倉庫非常重要的一個環(huán)節(jié)，它決定的不僅僅是一個層次的問題，還直接影響到血緣分析、特征自動生成、元數(shù)據(jù)管理等一系列功能的建設。因此適于盡早考慮。
另外，每一層的名字不必太過在意，自己按照喜好就好。
本文分享了筆者自己對數(shù)據(jù)倉庫的一些理解和想法，不一定準確也不一定通用，但是可以作為一個參考的思路。有什么問題歡迎多交流。
- 第九屆華為ICT大賽中國總決賽收官 84支隊伍晉級全球總決賽
- 聯(lián)想集團黃建恒：SSG業(yè)務已連續(xù)15個季度雙位數(shù)增長
- 聯(lián)想集團ISG總裁：已將多款暢銷服務器進行升級
- 全球超大規(guī)模數(shù)據(jù)中心數(shù)量五年翻倍，2024年新增137個！
- 華為楊超斌：行業(yè)智能化是開啟產業(yè)新紀元的磅礴引擎
- 華為郭振興：2025年行業(yè)數(shù)智化將呈現(xiàn)五大特征
- 加速行業(yè)智能化！華為攜手伙伴共筑解決方案競爭力，共贏時代新機遇
- 華為李鵬：AI正深刻改變每一個行業(yè)，攜手伙伴共贏全面智能化時代
- 華為汪濤：全面推進“全面智能化”戰(zhàn)略，發(fā)展伙伴“同路人”共贏智能未來
- 因聚而生，眾智有為：華為中國合作伙伴大會2025圓滿舉行
免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。
