不知其来源出处，感觉是一字一字码出来的经验之谈，特分享与此。
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。
不知其来源出处，感觉是一字一字码出来的经验之谈，特分享与此。