最近在做資料倉儲相關的工作，專案快要收尾了，總結下資料倉儲資料分層設計的一些心得；雖然以前做過很多olap相關的工作，就像流量統計分析這種，這種型別分析，我們往往就弄一張大寬表和幾張維度表；所有的統計分析都基於這張大寬表與維度表，在這種簡單的應用場景，這種設計倒沒有什麼問題，簡單明瞭；但是如果業務場景複雜，資料種類多，維度多，那資料倉儲的設計就尤為重要，特別是在資料出了問題情況下，要進行排查，結構清晰明了的資料倉儲設計將大有裨益，廢話不多說直接上圖
ods原始資料
mysql中的資料，資料量大的表我們會按天歸檔到hdfs上，資料量少的就直接使用，我們的計算引擎使用的是presto，支援hive表和mysql表關聯這種跨資料來源查詢；presto跨資料來源的這種特性，使得我們在mysql歸檔到hdfs的工作十分高效簡單,大多數情況下也就是一條sql
insert hive.catalog.hivetable select * from mysql.db.tablename where id>111dwd明細檢視，拉鍊表
這一層的資料依賴於ods層，在這一層我們會做一些過濾，轉換，剔除髒資料的工作，當然還有一點非常重要的就是做拉鍊表；為什麼要做拉鍊表？ods資料有部分是**mysql，mysql中的資料是時刻會變化的，今天匯入到hdfs中的資料，明天就會發生變化，這個是不可避免的，具體怎麼做，可以參照下面這個鏈結
其實如果你不需要知道資料的變化歷史，而且資料量也不是特別大的話，增量資料也不是特別多的話（例如十幾萬）完全可以每次導全表；這裡的資料需要永久儲存的
維度建模
維度建模，資料拆分成事實表和維度表，這裡不多說，參照
寫的很贊，找不到第二篇更好的了，推薦多讀幾遍
dm寬表，資料檢視，資料集市
這個叫啥的都有，但說到底，就是把同種類別的資料組合起來，做成每種業務做成一張大寬表，方便業務快速生成報表，通常會做成檢視
這個就是最終展示給使用者看的報表，通常都是聚合儲存在mysql
表命名規範
資料層_bussiness_分割槽類別|檢視
或者bussiness_分割槽類別|檢視_資料層
ods_bussiness_day
dwd_bussiness_month
dm_bussiness_view
或者bussiness_day_ods
bussiness_day_dwd
bussiness_day_view
小看法關於資料倉儲個人的一些粗俗看法：資料分層沒有嚴格的規則，只要你做到以下幾點，怎麼分都可以
而且資料倉儲為什麼這麼分，往往都是隨著業務發展不斷演變而來的。
資料倉儲設計寫的有什麼不對的地方，大家多指正
參考
資料倉儲分層
下面的內容是基於參考中的文件進行的二次讀書筆記。傳統行業的資料倉儲工程師,開始嘗試架構工程領域比較流行的er模型 維度模型方式，構建出乙個四層的模型架構 阿里在構建er時碰到了較大的挑戰，主要是業務快速發展，人員快速變化 業務知識功底的不夠全面，導致er模型產出困難。阿里得出了乙個結論 在不太成熟 ...
資料倉儲分層
資料倉儲更多代表的是一種對資料的管理和使用的方式，它是一整套包括了etl 排程 建模在內的完整的理論體系。現在所謂的大資料更多的是一種資料量級的增大和工具的上的更新。兩者並無衝突，相反，而是一種更好的結合。資料倉儲在構建過程中通常都需要進行分層處理。業務不同，分層的技術處理手段也不同。分層的主要原因...
資料倉儲分層
資料倉儲分層的主要原因是在管理資料的時候，能對資料有乙個更加清晰的掌控，詳細來講，主要有下面幾個原因 為什麼最低要分三層呢？在實際的生產環境中，資料倉儲的資料一般會有多個 資料可能比較亂，有很多的髒資料，資料的單位可能會不一樣等原因，我們要對資料進行分析或者對資料進行聚合等操作顯然不那麼方便，這時候...