一、各行業使用的分層模型
不同的行業使用的分層也有所不同，但思想都差不多
1.電信通訊
stage層 ->bdl層 ->analysis層
2.傳統金融/保險
ods層 ->pdm層 ->dm層
3.互聯網金融/電商
odl層 ->bdl層 ->idl層 ->adl層
二、專業術語
ODL層 （Operational Data Layer）：操作數據層
保存原始數據。外部數據什麼樣，該層數據就是什麼樣（關係型數據庫、JSON格式等)。
BDL層 （Base Data Layer）：基礎數據層
做統一的清洗處理。去重、去噪、字典翻譯、空值轉化，日期格式化等操作。
IDL層 （Interface Data Layer）：接口層，也稱主題表，寬表
業務數據底表。在bdl層上，join各表後產生業務所需要的完整數據。
ADL層（Application Data Layer）：應用層 ，也稱數據集市**
與需求對接。由idl層基於某些維度的深度加工統計彙總等操作轉化而來，涉及到多個主題以及tmp數據之間的關聯JOIN後的結果。
DIM層（Dictionary Data Layer）：字典層，又稱dic層
存儲一些諸如省、市、縣區域表、渠道列表、商品類目等等表數據，可以從數據源sqoop導入。
TMP層（Temporary Data Layer）：臨時層
存儲一些中間計算結果
image
- 層次間的轉換沒必要循規蹈矩，按部就班，適當做到靈活，避免重複清洗浪費資源
- ODL層乾淨的關係型數據可以直接轉換爲IDL層數據，減少計算量
- ODL層側重與外部對接，BDL層/TMP層/IDL層側重清洗，IDL層和ADL層側重對外提供應用服務
- 層數太少不夠靈活，太多則在數據推翻重洗耗時，時間成本（一個坑）
- 數據源提供的數據越詳細越好，避免後期大量重複的清洗工作。
此外，大家可能經常聽到“星型模型”和“雪花模型”，簡單解釋下
（1）星型模型：事實表+維度表（區域、類目、性別...)等多表通過預先JOIN冗餘到一張寬表裏去，常見IDL層。
（2）雪花模型：在計算的時候，纔將事實表跟維度表做join。
現在一般都是採用（1）的模式，爲什麼呢？ 預先計算，提高性能，避免後續重複計算。CPU和內存的資源永遠比磁盤空間寶貴的多。至於（2)的方式，有點就是靈活，不需要太多的重複清洗，但是性能不如（1）.
數據倉庫的建設需要從從需求出發，逆推應用層ADL結構，進而推導出它涉及的主題表IDL表結構，再推導可能涉及的基礎表BDL表結構，最後分析所需的數據源取自何處。需求需要包含“明確”需求和“潛在”需求。
三、開發步驟
- 創建ODL、BDL、IDL、ADL層表結構(HQL)
- 確定數據抽取方案（增量或全量）
- 編寫sqoop腳本將數據同步到dim層、使用腳本將源數據同步到odl層
- 編寫ODL->BDL->IDL->ADL層ETL清洗腳本(HQL)
- 確保上一層的數據穩定，減少對下一層的影響
- 編寫azkaban、Ooize腳本
- 打通Kylin、FineBI、Hive關係，實現數據可視化、可導出目標
四、HIVE開發規範
表命名規範
ODL層：表名前綴 odl_
BDL層：表名前綴 bdl_
IDL層：表名前綴 idl_
ADL層：表名前綴 adl_
TMP表：表名前綴 tmp_
DIM表：表名前綴 dim_
外部表和內部表
儘量使用內部表。從數據安全的角度考慮，源數據可能被丟失，損壞，而這些情況在hadoop集羣上發生的機率更小
建表規範
- 每個表增加個ds時間分區，表示數據是哪一天的，也方便重跑數據
- boolean類型統一使用0或1
- 錢相關的金額建議使用decimal，而非double ，避免一些計算導致精度不準確
- 日期格式使用 YYYY-MM-DD HH:MM:SS 、YYYY-MM-DD或 YYYYMMDD格式
- ...