一. 各種名詞解釋

1.1 ODS是什麼？

• ODS層最好理解，基本上就是資料從源表拉過來，進行etl，比如mysql 對映到hive，那麼到了hive裡面就是ods層。
• ODS 全稱是 Operational Data Store，運算元據儲存.“面向主題的”，資料運營層，也叫ODS層，是最接近資料來源中資料的一層，資料來源中的資料，經過抽取、洗淨、傳輸，也就說傳說中的 ETL 之後，裝入本層。本層的資料，總體上大多是按照源頭業務系統的分類方式而分類的。但是，這一層面的資料卻不等同於原始資料。 在源資料裝入這一層時，要進行諸如去噪(例如有一條資料中人的年齡是 300 歲，這種屬於異常資料，就需要提前做一些處理) 、去重(例如在個人資料表中，同一 ID 卻有兩條重複資料，在接入的時候需要做一步去重)、欄位命名規範等一系列操作。

1.2 資料倉儲層DW？

資料倉儲層(DW)，是資料倉儲的主體.在這裡，從 ODS 層中獲得的資料按照主題 建立各種資料模型。這一層和維度建模會有比較深的聯絡。

細分：

1. 資料明細層：DWD（Data Warehouse Detail）
2. 資料中間層：DWM（Data WareHouse Middle）
3. 資料服務層：DWS（Data WareHouse Servce）

1.2.1 DWD明細層?

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

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

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

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

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

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

1.3 APP

資料產品層(APP)，這一層是提供為資料產品使用的結果資料。

主要是提供給資料產品和資料分析使用的資料，一般會存放在 ES、Mysql 等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供資料分析和資料探勘使用。

如我們經常說的報表資料，或者說那種大寬表，一般就放在這裡。

應用層(App)

• 概念：應用層是根據業務需要，由前面三層資料統計而出的結果，可以直接提供查詢展現，或匯入至Mysql中使用。
• 資料生成方式：由明細層、輕度彙總層，資料集市層生成， 一般要求資料主要來源於集市層。
• 日誌儲存方式： 使用impala內表，parquet檔案格式。
• 日誌刪除方式：長久儲存。
• 表schema： 一般按天建立分割槽，沒有時間概念的按具體業務選擇分割槽欄位。
• 庫與表命名。庫名：暫定apl，另外根據業務不同，不限定一定要一個庫。(其實就叫app_)就好了
• 舊資料更新方式：直接覆蓋

1.4 資料的來源

資料主要會有兩個大的來源：

業務庫，這裡經常會使用 Sqoop 來抽取

我們業務庫用的是databus來進行接收，處理kafka就好了。

在實時方面，可以考慮用 Canal 監聽 Mysql 的 Binlog，實時接入即可。(有機會補一下這個canal)

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

還有使用filebeat收集日誌，打到kafka，然後處理日誌

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

1.5 ODS、DW → App層

這裡面也主要分兩種型別：

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

1.6 維表層DIM？

維表層（Dimension）
最後補充一個維表層，維表層主要包含兩部分資料：

高基數維度資料：一般是使用者資料表、商品資料表類似的資料表。資料量可能是千萬級或者上億級別。

低基數維度資料：一般是配置表，比如列舉值對應的中文含義，或者日期維表。資料量可能是個位數或者幾千幾萬。

這裡解釋一下DWS、DWD、DIM和TMP的作用。

• DWS：輕度彙總層，從ODS層中對使用者的行為做一個初步的彙總，抽象出來一些通用的維度：時間、ip、id，並根據這些維度做一些統計值，比如使用者每個時間段在不同登入ip購買的商品數等。這裡做一層輕度的彙總 會讓計算更加的高效，在此基礎上如果計算僅7天、30天、90天的行為的話會快很多。 我們希望80%的業務都能透過我們的DWS層計算，而不是ODS。
• DWD：這一層主要解決一些資料質量問題和資料的完整度問題。 比如使用者的資料資訊來自於很多不同表，而且經常出現延遲丟資料等問題，為了方便各個使用方更好的使用資料，我們可以在這一層做一個遮蔽。（彙總多個表）
• DIM：這一層比較單純，舉個例子就明白，比如國家程式碼和國家名、地理位置、中文名、國旗圖片等資訊就存在DIM層中。

• TMP：每一層的計算都會有很多臨時表，專設一個DWTMP層來儲存我們資料倉儲的臨時表。

  三. 總結

• 

•