互联网金融行业数仓分层

专业术语

  • 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）：临时层

    存储一些中间计算结果

image

简要说明:

  1. 层次间的转换没必要循规蹈矩，按部就班，适当做到灵活，避免重复清洗浪费资源
  2. ODL层干净的关系型数据可以直接转换为IDL层数据，减少计算量
  3. ODL层侧重与外部对接，BDL层/TMP层/IDL层侧重清洗，IDL层和ADL层侧重对外提供应用服务
  4. 层数太少不够灵活，太多则在数据推翻重洗耗时，时间成本（一个坑）
    数据源提供的数据越详细越好，避免后期大量重复的清洗工作。

“星型模型”和“雪花模型”

简单解释：

  • （1）星型模型：事实表+维度表（区域、类目、性别…)等多表通过预先JOIN冗余到一张宽表里去，常见IDL层。
  • （2）雪花模型：在计算的时候，才将事实表跟维度表做join。

现在一般都是采用（1）的模式，为什么呢？ 预先计算，挺高性能，避免后续重复计算。CPU和内存的资源永远比磁盘空间宝贵的多。
至于（2)的方式，有点就是灵活，不需要太多的重复清洗，但是性能不如（1）.

建设思路

从需求出发，逆推应用层ADL结构，进而推导出它涉及的主题表IDL表结构，再推导可能涉及的基础表BDL表结构，最后分析所需的数据源取自何处。
需求包含“明确”需求和“潜在”需求。

开发步骤

  1. 创建ODL、BDL、IDL、ADL层表结构(HQL)
  2. 确定数据抽取方案（增量或全量）
  3. 编写sqoop脚本将data同步到ODL层
  4. 编写ODL->BDL->IDL->ADL层ETL清洗脚本(HQL),注意：清洗的顺序，时间
    确保上一层的数据稳定，减少对下一层的影响
  5. 编写Hue workflow Ooize脚本
  6. 打通Kylin、FineBI、Hive关系，实现数据可视化、可导出目标,将稳定后所有脚本WIKI上保存一份

其他相关的请参照原博客

作者：水星有鱼
链接：https://www.jianshu.com/p/f941967aeee8