最近在做數據倉庫相關的工作，項目快要收尾了，總結下數據倉庫數據分層設計的一些心得；雖然以前做過很多olap相關的工作，就像流量統計分析這種，這種類型分析，我們往往就弄一張大寬表和幾張維度表；所有的統計分析都基於這張大寬表與維度表，在這種簡單的應用場景，這種設計倒沒有什麼問題，簡單明瞭；但是如果業務場景複雜，數據種類多，維度多，那數據倉庫的設計就尤爲重要，特別是在數據出了問題情況下，要進行排查，結構清晰明瞭的數據倉庫設計將大有裨益，廢話不多說直接上圖
ODS原始數據
這裏的原始數據來源有兩部分：hdfs和mysql
mysql中的數據，數據量大的表我們會按天歸檔到hdfs上，數據量少的就直接使用，我們的計算引擎使用的是presto，支持hive表和mysql表關聯這種跨數據源查詢；presto跨數據源的這種特性，使得我們在mysql歸檔到hdfs的工作十分高效簡單,大多數情況下也就是一條sql
insert hive.catalog.hivetable select * from mysql.db.tablename where id>111
之前導過訂單從庫，幾千萬的數據走id索引歸檔導hdfs，也就十幾分鐘的事，這種工作最好在夜間訪問量低的時候做；剛開始的時候你可能需要全表導一次，之後就是每天增量導入對應的分區裏。這裏的數據不會存儲太久，一個月或者幾個月，沒有硬性規定，爲了方便追溯問題，儘量保存時間不要太短
DWD明細視圖，拉鍊表
這一層的數據依賴於ODS層，在這一層我們會做一些過濾，轉換，剔除髒數據的工作，當然還有一點非常重要的就是做拉鍊表；爲什麼要做拉鍊表？ODS數據有部分是來源mysql，mysql中的數據是時刻會變化的，今天導入到hdfs中的數據，明天就會發生變化，這個是不可避免的，具體怎麼做，可以參照下面這個鏈接
https://blog.csdn.net/zhaodedong/article/details/54177686
其實如果你不需要知道數據的變化歷史，而且數據量也不是特別大的話，增量數據也不是特別多的話（例如十幾萬）完全可以每次導全表；這裏的數據需要永久存儲的
維度建模
維度建模，數據拆分成事實表和維度表，這裏不多說，參照
https://www.cnblogs.com/muchen/p/5310732.html
寫的很贊，找不到第二篇更好的了，推薦多讀幾遍
DM寬表，數據視圖，數據集市
這個叫啥的都有，但說到底，就是把同種類別的數據組合起來，做成每種業務做成一張大寬表，方便業務快速生成報表，通常會做成視圖
APP應用層
這個就是最終展示給用戶看的報表，通常都是聚合存儲在mysql
表命名規範
數據層_bussiness_分區類別|視圖
ods_bussiness_day
dwd_bussiness_month
dm_bussiness_view
小看法
關於數據倉庫個人的一些粗俗看法：數據分層沒有嚴格的規則，只要你做到以下幾點，怎麼分都可以
- 處理好數據變化問題，保證數據和原始數據保持一致，減少數據冗餘
- 快速支撐報表生成，數據清晰易懂
- 快速定位問題，數據儘量做到小改動，或者不動
而且數據倉庫爲什麼這麼分，往往都是隨着業務發展不斷演變而來的。
數據倉庫設計寫的有什麼不對的地方，大家多指正
參考