不知其來源出處，感覺是一字一字碼出來的經驗之談，特分享與此。
1.電信通訊
stage層 ->bdl層 ->analysis層
2.傳統金融/保險
ods層 ->pdm層 ->dm層
3.互聯網金融/電商
odl層 ->bdl層 ->idl層 ->adl層
儘管行業不同，但套路卻差不多。
ODL層 （Operational Data Layer）：操作數據層
外部數據什麼樣，該層數據就是什麼樣（關係型數據庫、JSON格式等)
部分關係型數據可以直接轉IDL層
BDL層 （Base Data Layer）：基礎數據層
ODL層經過簡單格式化解析後存儲到BDL層，常見於JSON日誌格式的解析。
IDL層 （Interface Data Layer）：接口層，也稱主題表，寬表
由BDL層經過去重、去噪、字典翻譯、空值轉化，日期格式化、關聯JOIN、維度分析等清洗後的數據
如：用戶、產品、綁卡、訂單、用戶行爲等明細數據。
ADL層（Application Data Layer）：應用層 ，也稱數據集市
通常與需求對接，由IDL層基於某些維度的深度加工統計彙總等操作轉化而來，涉及到多個主題以及tmp數據之間的關聯JOIN後的結果。
DIC層（Dictionary Data Layer）：字典層
存儲一些諸如省、市、縣區域表、渠道列表、商品類目等等表數據，可以從數據源直接sqoop生成dic_xxx表，也可以通過odl層轉化層dic_表。
TMP層（Temporary Data Layer）：臨時層
存儲一些中間計算結果
層次間的轉換沒必要循規蹈矩，按部就班，適當做到靈活，避免重複清洗浪費資源；
ODL層乾淨的關係型數據可以直接轉換爲IDL層數據，減少計算量；
ODL層側重與外部對接，BDL層/TMP層/IDL層側重清洗，IDL層和ADL層側重對外提供應用服務；
層數太少不夠靈活，太多則在數據推翻重洗耗時，增加時間成本；
數據源提供的數據越詳細越好，避免後期大量重複的清洗工作。
（1）星型模型：事實表+維度表（區域、類目、性別...)等多表通過預先JOIN冗餘到一張寬表裏去，常見IDL層。
（2）雪花模型：在計算的時候，纔將事實表跟維度表做join。
現在一般都是採用（1）的模式，爲什麼呢？ 預先計算，挺高性能，避免後續重複計算。CPU和內存的資源永遠比磁盤空間寶貴的多。至於（2)的方式，有點就是靈活，不需要太多的重複清洗，但是性能不如（1）。
ODL層：表名前綴 odl_
BDL層：表名前綴 bdl_
IDL層：表名前綴 idl_
ADL層：表名前綴 adl_
特別的
TMP表：表名前綴 tmp_ ,用於存儲中間計算、臨時的數據,配合前面4層計算
DIC表：表名前綴 dic_ ,用於存儲變化不大的字典信息，如省份城市、區域、類目等數據。
Impala查詢的速度，是Hive的幾十倍，一般1~5秒內可以解決。
Impala不適合清洗，因爲語法跟hive還是有很大一部分差異的，Impala比較耗內存；一般商業智能分析工具如tableau、帆軟獲取其它的都支持Impala。
