京东数仓分层相关

一、模型分层

1. 缓冲数据模型 BDM
   源业务系统数据的快照，保存细节数据，按天分区，会保持最近一段时间数据。一般情况下，每个BDM表对应着源业务系统的一个表或者一个日志文件，数据结构与线上基本是对应的。绝大多数的数据快照是经过增量抽取策略抽过来了，对于不支持增量抽取策略或者数据量极少的表采用全量抽取的策略。
2. 基础数据模型 FDM
   基础数据模型，用来保存源业务系统数据的快照，数据永久保存。对于有更新操作的数据来说，采用拉链的方式优化存储。对于没有更新操作的数据来说，采用流水方式存储。
3. 通用数据模型 GDM
   根据京东核心业务主题按照星型模型或雪花模型设计方式建设的最细业务粒度汇总层。在本层需要进行指标与维度的标准化，保证指标数据的唯一性。
4. 聚合数据模型 ADM
   根据不同的业务需求采用星型或雪花型模型设计方法构建的按维度汇总数据。
5. 维度模型 DIM
   维度表可以看作是用户来分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。例如，包含订单信息的维度表通常包含将订单分为区域、省份、城市等若干类的层次结构。在维度表中，每个表都包含独立于其他维度表的事实特性，例如，客户维度表包含有关客户级别的数据。维度表中的列字段可以将信息分为不同层次的结构级。
6. 临时层 TMP
   用来降低加工过程计算难度，提高运行效率的临时表，用完即舍，不保存历史数据。
   7 中间层(操作数据模型) ODM
   在加工通用模型的时候，对于多个模型都使用到的公共数据需要清洗转换的时候，用来封装清洗转换逻辑保存清洗后的数据，供加工通用模型使用，中间层数据保存历史状态。
7. 应用数据模型 APP
   应用数据模型按照具体的需求进行设计，其数据直接供前端报表工具展现使用，或者推送到其他系统做相关的数据支撑。

数仓分层意义：

1. 清晰数据结构体系
2. 数据血缘追踪
3. 减少重复开发和资源浪费（避免烟囱式开发）
4. 复杂问题简单化
5. 统一数据口径

二、建模分类
我们先从几个物理概念入手理解什么是流量，存量，增量
（1）存量：系统在某一时点时的所保有的数量；
（2）流量：是指在某一段时间内流入/出系统的数量
（3）增量：则是指在某一段时间内系统中保有数量的变化
（4）增量=流入量–流出量
（5）本期期末存量=上期期末存量+本期内增量

拉链表
（1）记录一个事物从开始，一直到当前状态的所有变化的信息；
（2）拉链表每次上报的都是历史记录的最终状态，是记录在当前时刻的历史总量；
（3）当前记录存的是当前时间之前的所有历史记录的最后变化量（总量）；
（4）存量是在某一时刻的总量；
（5）存量一般设计成拉链表（月报-常用、日报）；
（6）流量和存量的区别：流量是增量；存量是总量；
（7）封链时间可以是2999，3000，9999等等比较大的年份；拉链表到期数据要报0；
（8）拉链表和增量表的共同点：表结构基本一样。

流水表：对于表的每一个修改都会记录，可以用于反映实际记录的变更
　区别于拉链表：　
拉链表通常是对账户信息的历史变动进行处理保留的结果，流水表是每天的交易形成的历史；
流水表用于统计业务相关情况，拉链表用于统计账户及客户的情况

快照表：
按照每天存放的数据以及是否按天分区可以分为增量表，全量表和快照表

全量表
（1）全量表，有无变化，都要报
（2）每次上报的数据都是所有的数据（变化的 + 没有变化的）

增量表
（1）记录每次增加的量，而不是总量；
（2）流量是指在一定时间内的增量；
（3）流量一般设计成增量表（日报-常用、月报）；
（4）流量和存量的区别：流量是增量；存量是总量；
（5）增量表，只报变化量，无变化不用报

三、数据仓库建模理论
1、建模三个阶段
1.1、概念模型设计（Concept Data Modeling）
这一阶段之前的首要工作是明确需求涵盖的业务范围。然后再对需求范围内的业务及其间关系进行高度概括性的描述，把密切相关业务对象进行归类，即划分主题域。概念模型的设计是为逻辑模型的设计做准备。
1.2、逻辑模型设计（Logical Data Modeling）
逻辑数据模型（Logical Data Model）是利用数据和关系来反映集团业务的一个过程，其生成的关系数据模型，利用图形化方式来展现集团业务规则。逻辑数据模型描述了集团的重要业务元素以及这些元素之间的关系，是集团进行数据管理、分析和交流的重要手段，通过它可以清楚地了解集团的数据结构和业务规则，是IT人员和业务人员沟通的桥梁。同时，逻辑数据模型也是用来发现、记录和沟通业务，展现业务规则的详细“蓝图”。逻辑数据模型独立于技术和特定平台，逻辑数据模型在特定平台的实施即为物理数据模型。在建立逻辑模型的时候，我们要尽量把所有的业务逻辑涵盖在模型之中，不能留给程序去定义业务逻辑

1.3、物理模型设计（Physical Data Modeling）
物理数据模型与逻辑数据模型不同，因为要权衡数据源的数据组织结构、ETL过程的复杂程度以及数据库本身的特点，因此在物理模型中往往会使用一些非正则化处理，增加一些冗余字段和汇总表，而这些是不会出现在逻辑数据模型中的。另外，逻辑数据模型中的元素在物理数据库中实现时可能被重新组合，例如实体归并、属性从一个实体被移到另一个实体等。但是必须坚持的一个基本原则是，物理模型不能改变业务规则，其目的仅是提高数据分析的速度，适应具体数据库的容量、性能等限制。因此可以说，这一阶段面对的是具体的软硬件平台和性能要求。

四、数据仓库设计规范
1、逻辑模型设计
数据仓库共性加工层逻辑模型设计总体遵循以下设计原则：
中性的，共享的：服务于多个应用相同业务数据的统计；
逆范式化：设计成宽表模型，重新组织基础层数据，减少了重新关联表进行计算所带来的性能问题，加快了查询的响应时间；
规范的，易懂的：使用业务定义和语言进行模型设计，易于让业务人员理解和使用，有助于IT和业务部门人员的沟通。
2、物理模型设计
数据仓库共性加工层物理模型设计总体遵循以下设计原则：
可实施的：结合特定数据库平台进行设计，可以在相应平台上直接创建数据库，不具有平台共享性；
高效的：结合数据及使用特性的通过适度冗余、创建索引等手段保证物理数据库的高效运转；
规范的，易懂的：物理数据模型与逻辑数据模型同样需要遵循命名规范，表名、字段名命名规范一致，方便易懂、易查询。

模型开发相关：
HiveTask总结：
1. 京东SQL任务提交入口，提供如下功能：
1.1 日志存储
1.2 Spark/MR（Hive）任务切换
1.3 统一提供初始化内置参数
1.4 增加LZO索引 【Jar包】
1.6 提供合并小文件 【Jar包提供功能支持】
1.7 任务失败重试【是否切换引擎, 开启Hive重试机制】
1.8 解析表结构、分析等等