阿里巴巴大数据实践所得

一、为什么需要建模

数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。
合理的数据模型：
性能：快速查询所需要的数据，减少数据的吞吐。
成本：极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
效率：极大地改善用户使用数据的体验，提高使用数据的效率。
质量：良改善数据统计口径的不一致性，减少数据计算错误的可能性。

二、模型设计
操作数据层(ODS)、明细数据层(DWD)、汇总数据层(DWS)、维度表(DIM)、应用数据层(ADS)
操作数据层：把操作系统数据几乎无处理地存放在数据仓库系统中。
明细数据层：采用些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据易用性;
汇总数据层：基于OneData体系构建命名规范、口径和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标建立逻辑汇总宽表。
加强指标的维度退化，采取更多的宽表手段构建公共指标数据层，提升公共指标的复用性，减少重复加工;
应用数据层：存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成；个性化指标加工：不公用性、复杂性(指数型、比值型、排名型指标)。
基于应用的数据组装 大宽表集市、横表转纵表、趋势指标串；
数据调用服务优先使用公共维度模型层(CDM)数据，当公共层没有数据时，需评估是否需要创建公共层数据，当不需要建设公用的公共层时，
方可直接使用操作数据层(ODS)数据。应用数据层(ADS)作为产品特有的个性化数据一般不对外提供数据服务，但是ADS作为被服务方也需要遵守这个约定。

三、OneData 实施工作流
1.数据调研：业务调研(了解业务)、需求调研(需求沟通、报表需求)
2.架构设计: 数据域划分(面向分析，将业务过程\维度抽象)、构建总线矩阵(每个数据域包含哪些业务过程、及业务过程涉及的维度)、
3.规范定义：定义指标体系(原子指标、修饰词、时间周期、派生指标)
4.模型涉及: 维度及属性、维表及事实表模型设计

四、维表的设计
1.确定维度属性的提示：
尽可能生成丰富的维度属性
尽可能多给出一些富有意义的文字描述
区分数值型属性和事实
尽量沉淀出通用的维度属性(淘宝商品的 property 字段，使用 key:value 方式存储多个商品属性)

2.维度反范式化
将维度的属性层次合并到单个维度中的操作称为反规范化。分析系统的主要目的是用于数据分析和统计，
如何更方便用户进行统计分析决定了分析系统的优劣。采用雪花模式，用户在统计分析的过程中需要量的关联操作，
使用复杂度高，同时查询性能很差；而采用反规范化处理，则方便、易用且性能好。

3.维度整合
3.1 采用主从表的设计方式，将两个表或多个表都有的字段放在主表中(主要基本信息),从属信息分别放在各自的从表中。
3.2 对于主表中的主键，要么采用复合主键、源主键和系统或表区别标志：要么采用唯一主键、"源主键和系统或表区别标志"
生成新的主键。通常建议采用复合主键的方式。
3.3 不合并，因为源表的表结构及主键等差异很大，无法合并。

4.递归层次
按照层级是否固定分为均衡层次结构和非均衡层次结构。
1. 层次结构扁平化
类目名称
类目层级
一级类目ID
一级类目名称
二级类目ID 
二级类目名称
三级类目ID 
三级类目名称
四级类目ID
四级类目名称
五级类目ID 
五级类目名称
是否叶子类日

2.层次桥接表
父关键字
子关键字
父层数
层级间隔
层名
底端标识
顶端标识 

5.行为维度(事实维度)
如卖家主营类目维度、主营品牌维度，通过卖家的商品分布和交易分布情况，采用算法计算得到。
类似的维度，都和事实相关，如交易、物流等，称之为"行为维度"，或"事实衍生的维度"。
分类：
另外一个维度的过去行为，如卖家/买家最近一次访问/交易时间。
快照事实行为维度，买家从年初直接交易金额、买家信用分值、卖家信用分值等。
分组事实行为维度，将数值型转换为枚举项，如买家年初至今交易金额等级、买家信用分值划分信用等级。
复杂逻辑事实行为维度，通过算法加工多个事实表综合加工得到。比如商品热度根据访问、收藏、加入购物车、交易等综合计算得到。
行为维度，两种处理方式：
将其冗余至现有的维度表中，比如卖家信用等级冗余至卖家维度表中。
加工成单独的行为维度表，比如卖家主营类目。
具体采用哪种方式参考以下原则：
第一、避免维度过快增长。第二避免耦合度过高(ETL逻辑复杂，维护性差、产出延迟)。

6.多值维度
一种情况是事实表的一条记录在某维表中有多条记录与之对应。比如淘宝订单，一笔订单有多件商品。
常见三种处理方式：
降低事实表粒度，每个子订单只有一种商品对应。
采用多字段，通过预留字段的存放，比如增加买受方一、买受方二、买受方三、其他买受方
采用通用的桥接表。桥接表包含和事实表关联的分组KEY，以及作为买受方维表外键的买受方ID。
(若事实表中一条记录对应两个买受方，则桥接表建立两条记录，分组KEY相同)

7.多值属性
维表中某个属性字段同时有多个值，称之为"多值属性"。比如一个商品，其商品的标签有多个。
常见的处理方式：
保持维度主键不变，将多值属性放在维度的一个属性字段中。(以通过k-v对的形式放在property字段中)
保持主键不变，将多值属性放在多个属性字段中。(需要预留字段，扩展性差)
维表主键发生变化，一个维度值存放多条记录，每个商品有多少属性，就多少条记录。
8.杂项维度
杂项维度是由操作型系统中的指示符或者标志字段组合而成，一般不在一致性维度之列。比如淘宝交易订单
的交易类型字段，支付状态、物流状态等，它们在源系统中直接保存在交易表中。
一个事实表中可能存在多个类似字段，若作为事实存放在事实表中，会导致占用空间过大。若单独建立维表，
外键关联到事实表，会出现维度过多的情况；
通常的解决方案就是建立杂项维度 ，将这些字段建立到维表中，在事实表中只需保存一个外键即可。
多个字段的不同取值组成一条记录，生成代理键，存人维表中，并将该代理键保存到相应的事实表字段下。
建议不要直接使用所有的组合生成完整 的杂项维表，在抽取遇到新的组合时生成相应的记录即可。
杂项维度 ETL 过程比一般维度略微复杂些。
阿里实践，明细整合层的事实表，创建的杂项维度会采用实体的主键作为杂项维度的主键(比如:订单ID作为主键)。

五、事实表设计
1.事实表特性
粒度指事实表中一条记录所表达的业务细节程度。
通常粒度可以通过两种方式来表述：
一种是维度属性组合所表示的细节程度：一种是所表示的具体业务含义。
可加型(可按照任意维度汇总)、半可加型(按照特定维度汇总，比如库存不可按日期累加)、不可加性(比率型)。
不可加型可分解来实现聚集
维度属性可以存储到事实表中，成为"退化维度"。
事实表三种类型:
事务事实表(最原子数据)
周期快照事实表(按日、天等间隔记录事实)
累积快照事实表(覆盖整个生命周期，具有多个日期记录关键时间点)。

2.事实表的设计方法
选择业务过程、声明粒度、确认维度、确认事实、冗余维度。
传统的维度建模星型模型中，对维度的处理需要单独存放，通过事实表外键获取维度，目的为了减少事实表的维度冗余，从而减少存储消耗。
而在大数据的事实表模型设计中，考虑更多的是提高下游用户的使用效率，减低数据获取复杂性，减少关联的表数量。
所以通过会冗余常用维度。

3.单事务事实表、多事务事实表
单事务事实表，即针对每个业务过程设计一个事实表。比如淘宝订单，下单->付款->发货->完结，产生四条事实。
多事务事实表(仍有多条事实)，即同一个事实表包含不同的业务过程
设计时有两种方法：
A:不同业务过程使用不同的事实字段进行存放，并增加标志字段。淘宝订单举栗：
订单ID、是否当日下单、是否当日支付、是否当天完结、下单时间、支付时间、完结时间....
好处是：对于当日完成多个业务过程的记录进行合并，若业务过程不在同一天仍会产生新的事实，历史事实不更新。
B：不同业务过程使用统一事实字段进行存放，但增加业务过程标签。(收藏/删除采用同一个字段)。淘宝收藏集举栗：
业务日期、商品ID、收藏时间、删除时间、收藏删除类型
好处是：相比单事务表就是不同业务过程合并了一张表。

4.周期快照事实表
预定的间隔采样状态度量。这个东东跟聚集表不同，周期快照事实表一般都是保存采样周期结束时的状态度量，
这些状态度量都是半可加事实，比如年初至今、历史至今金额、买家数等。淘宝栗子：
业务日期、卖家ID、自然年初截至当日下单金额、XXXX下单买家数、XXXX支付金额、XXXX支付买家数

5.累计快照事实表
累积快照事实表的典型特征是多业务过程日期，用于计算业务过程之间的时间间隔。还有个作用是保存全量数据。
订单ID、买家ID、下单时间、支付时间、发货时间、确认发货时间、状态(下单、支付、发货)等等。(不同的业务过程仅更新时间字段，不产生新记录)

6.聚集型事实表
按照各个维度进行汇总统计，减少从明细表查询带来的性能问题。
阿里的设计原则不建议聚集数据跨数据域。

4.