最近出現了好幾次同樣的對話場景： 問：你是做什麼的? 答：最近在搞資料倉庫。 問：哦，你是傳統行業的吧，我是搞大資料的。 答：……
發個牢騷，搞大資料的也得建設資料倉庫吧。而且不管是傳統行業還是現在的網際網路公司，都需要對資料倉庫有一定的重視，而不是談一句自己是搞大資料的就很厲害了。資料倉庫更多代表的是一種對資料的管理和使用的方式，它是一整套包括了etl、排程、模組化在内的完整的理論體系。現在所謂的大資料更多的是一種資料量級的增大和工具的上的更新。 兩者并無沖突，相反，而是一種更好的結合。
話說，單純用用hadoop、spark、flume處理處理資料，其實隻是學會幾種新的工具，這是搞工具的，隻是在資料倉庫中etl中的一部分。
當然，技術的更新往往能領到一個時代的變革，比如hadoop的誕生，光是深入研究一個大資料元件就要花很大的時間和精力。但是在熱潮冷卻之後，我們更應該考慮地是如何更好地管理和使用自己的資料。
對于資料的從業者來講，要始終重視緊跟技術的變革，但是切記資料為王，在追求技術的極緻的時候，不要忘了我們是搞資料的。
文章主題
吐槽完畢，本文主要講解資料倉庫的一個重要環節：如何設計資料分層!
本文對資料分層的讨論适合下面一些場景，超過該範圍場景 or 資料倉庫經驗豐富的大神就不必浪費時間看了。
資料建設剛起步，大部分的資料經過粗暴的資料接入後就直接對接業務。
資料建設發展到一定階段，發現資料的使用雜亂無章，各種業務都是從原始資料直接計算而得。
各種重複計算，嚴重浪費了計算資源，需要優化性能。
文章結構
最初在做資料倉庫的時候遇到了很多坑，由于自身資源有限，接觸資料倉庫的時候，感覺在網際網路行業裡面的資料倉庫成功經驗很少，網上很難找到比較實踐性強的資料。而那幾本經典書籍裡面又過于理論，折騰起來真是生不如死。還好現在過去了那個坎，是以多花一些時間整理自己的思路，幫助其他的小夥伴少踩一些坑。
為什麼要分層?這個問題被好幾個同學質疑過。是以分層的價值還是要說清楚的。
分享一下經典的資料分層模型，以及每一層的資料的作用和如何加工得來。
分享兩個資料分層的設計，通過這兩個實際的例子來說明每一層該怎麼存資料。
給出一些建議，不是最好的，但是可以做參考。
0x01 為什麼要分層
我們對資料進行分層的一個主要原因就是希望在管理資料的時候，能對資料有一個更加清晰的掌控，詳細來講，主要有下面幾個原因：
清晰資料結構：每一個資料分層都有它的作用域，這樣我們在使用表的時候能更友善地定位和了解。
資料血緣追蹤：簡單來講可以這樣了解，我們最終給業務誠信的是一能直接使用的張業務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準确地定位到問題，并清楚它的危害範圍。
減少重複開發：規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算。
把複雜問題簡單化。講一個複雜的任務分解成多個步驟來完成，每一層隻處理單一的步驟，比較簡單和容易了解。而且便于維護資料的準确性，當資料出現問題之後，可以不用修複所有的資料，隻需要從有問題的步驟開始修複。
屏蔽原始資料的異常。
屏蔽業務的影響，不必改一次業務就需要重新接入資料。
資料體系中的各個表的依賴就像是電線的流向一樣，我們都希望它是很規整，便于管理的。但是，最終的結果大多是第一幅圖，而非第二幅圖。
0x02 怎樣分層
理論
我們從理論上來做一個抽象，可以把資料倉庫分為下面三個層，即：資料營運層、資料倉庫層和資料産品層。
1. ods全稱是operational data store，操作資料存儲
“面向主題的”，資料營運層，也叫ods層，是最接近資料源中資料的一層，資料源中的資料，經過抽取、洗淨、傳輸，也就說傳說中的etl之後，裝入本層。本層的資料，總體上大多是按照源頭業務系統的分類方式而分類的。
例如這一層可能包含的資料表為：人口表(包含每個人的身份證号、姓名、住址等)、機場登機記錄(包含乘機人身份證号、航班号、乘機日期、起飛城市等)、銀聯的刷卡資訊表(包含銀行卡号、刷卡地點、刷卡時間、刷卡金額等)、銀行賬戶表(包含銀行卡号、持卡人身份證号等)等等一系列原始的業務資料。這裡我們可以看到，這一層面的資料還具有鮮明的業務資料庫的特征，甚至還具有一定的關系資料庫中的資料範式的組織形式。
但是，這一層面的資料卻不等同于原始資料。在源資料裝入這一層時，要進行諸如去噪(例如去掉明顯偏離正常水準的銀行刷卡資訊)、去重(例如銀行賬戶資訊、警察局人口資訊中均含有人的姓名，但是隻保留一份即可)、提髒(例如有的人的銀行卡被盜刷，在十分鐘内同時有兩筆分别在中國和日本的刷卡資訊，這便是髒資料)、業務提取、機關統一、砍字段(例如用于支撐前端系統工作，但是在資料挖掘中不需要的字段)、業務判别等多項工作。
2. 資料倉庫層(dw)，是資料倉庫的主體
在這裡，從ods層中獲得的資料按照主題建立各種資料模型。例如以研究人的旅遊消費為主題的資料集中，便可以結合航空公司的登機出行資訊，以及銀聯系統的刷卡記錄，進行結合分析，産生資料集。在這裡，我們需要了解四個概念：維(dimension)、事實(fact)、名額(index)和粒度( granularity)。
3. 資料産品層(app)，這一層是提供為資料産品使用的結果資料
在這裡，主要是提供給資料産品和資料分析使用的資料，一般會存放在es、mysql等系統中供線上系統使用，也可能會存在hive或者druid中供資料分析和資料挖掘使用。 比如我們經常說的報表資料，或者說那種大寬表，一般就放在這裡。
技術實踐
這三層技術劃分，相對來說比較粗粒度，後面我們會專門細分一下。在此之前，先聊一下每一層的資料一般都是怎麼流向的。這裡僅僅簡單介紹幾個常用的工具，側重中開源界主流。
1. 資料來源層–> ods層
這裡其實就是我們現在大資料技術發揮作用的一個主要戰場。 我們的資料主要會有兩個大的來源：
業務庫，這裡經常會使用sqoop來抽取，比如我們每天定時抽取一次。在實時方面，可以考慮用canal監聽mysql的binlog，實時接入即可。
埋點日志，線上系統會打入各種日志，這些日志一般以檔案的形式儲存，我們可以選擇用flume定時抽取，也可以用用spark streaming或者storm來實時接入，當然，kafka也會是一個關鍵的角色。
其它資料源會比較多樣性，這和具體的業務相關，不再贅述。
注意： 在這層，理應不是簡單的資料接入，而是要考慮一定的資料清洗，比如異常字段的處理、字段命名規範化、時間字段的統一等，一般這些很容易會被忽略，但是卻至關重要。特别是後期我們做各種特征自動生成的時候，會十分有用。後續會有文章來分享。
2. ods、dw –> app層
這裡面也主要分兩種類型：
每日定時任務型：比如我們典型的日計算任務，每天淩晨算前一天的資料，早上起來看報表。 這種任務經常使用hive、spark或者生撸mr程式來計算，最終結果寫入hive、hbase、mysql、es或者redis中。
實時資料：這部分主要是各種實時的系統使用，比如我們的實時推薦、實時使用者畫像，一般我們會用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檔案格式。
庫與表命名。庫名：dwb,表名：初步考慮格式為：dwb_日期_業務表名,待定。
主題層(dm，date market或dws, data warehouse service)
概念：又稱資料集市或寬表。按照業務劃分，如流量、訂單、使用者等，生成字段比較多的寬表，用于提供後續的業務查詢，olap分析，資料分發等。
資料生成方式：由輕度彙總層和明細層資料計算生成。
日志存儲方式：使用impala内表，parquet檔案格式。
庫與表命名。庫名：dm,表名：初步考慮格式為：dm_日期_業務表名,待定。
應用層(app)
概念：應用層是根據業務需要，由前面三層資料統計而出的結果，可以直接提供查詢展現，或導入至mysql中使用。
資料生成方式：由明細層、輕度彙總層，資料集市層生成，一般要求資料主要來源于集市層。
庫與表命名。庫名：暫定apl，另外根據業務不同，不限定一定要一個庫。
0x04 如何更優雅一些
前面提到的一種設計其實相對來講已經很詳細了，但是可能層次會有一點點多，而且在區分一張表到底該存放在什麼位置的時候可能還有一點點疑惑。 我們在這一章裡再設計一套資料倉庫的分層，同時在前面的基礎上加上維表和一些臨時表的考慮，來讓我們的方案更優雅一些。
下圖，做了一些小的改動，我們去掉了上一節的buffer層，把資料集市層和輕度彙總層放在同一個層級上，同時獨立出來了維表和臨時表。
這裡解釋一下dws、dwd、dim和tmp的作用。
dws：輕度彙總層，從ods層中對使用者的行為做一個初步的彙總，抽象出來一些通用的次元：時間、ip、id，并根據這些次元做一些統計值，比如使用者每個時間段在不同登入ip購買的商品數等。這裡做一層輕度的彙總會讓計算更加的高效，在此基礎上如果計算僅7天、30天、90天的行為的話會快很多。我們希望80%的業務都能通過我們的dws層計算，而不是ods。
dwd：這一層主要解決一些資料品質問題和資料的完整度問題。比如使用者的資料資訊來自于很多不同表，而且經常出現延遲丢資料等問題，為了友善各個使用方更好的使用資料，我們可以在這一層做一個屏蔽。
dim：這一層比較單純，舉個例子就明白，比如國家代碼和國家名、地理位置、中文名、國旗圖檔等資訊就存在dim層中。
tmp：每一層的計算都會有很多臨時表，專設一個dwtmp層來存儲我們資料倉庫的臨時表。
xff 總結
資料分層是資料倉庫非常重要的一個環節，它決定的不僅僅是一個層次的問題，還直接影響到後續的血緣分析、特征自動生成、中繼資料管理等一系列的建設。是以适于盡早考慮。
另外，每一層的名字不必太過在意，自己按照喜好就好。
本文分享了筆者自己對資料倉庫的一些了解和想法，不一定十分準确，有什麼問題可以多交流。
初步估計在資料倉庫方面，應該還會有三個主題分享：血緣分析、特征自動生成、中繼資料管理。分享完成之後，資料倉庫相關的就告一段落了。
本文轉自d1net（轉載）