本书是阿里巴巴分享描述了按照其公司业务的一些大数据技术实施的方案, 是阿里巴巴对大数据的认知其中也有很多值得学习的资料
本书分为数据技术篇数据模型篇数据管理篇数据应用篇
1 数据技术篇涉及阿里面对各种数据使用需求时的技术应对方案, 其中包括日志采集数据同步离线数据开发及实时技术数据服务数据挖掘等大数据在技术平台上的应用
2 数据模型篇涉及数据在平台架构的基础上, 合理组织和储存数据
3 数据管理篇涉及对元数据的管理, 数据计算和存储成本管理数据质量的管理
4 数据应用涉及阿里巴巴的数据应用平台(生意参谋, 内部应用)
本篇文章是基于数据模型的知识整理:
面对数据规模的快速扩大, 如何有序有结构的的分类组织和存储数据是我们面临的极大挑战
数据模型解决面对业务需求, 如何有效的组织和存储数据的问题, 其强调数据的性能, 成本效率质量(这 4 哥们都是相辅相成的如何达到四者的平衡是数据模型的研究对象)
典型的数据仓库模型:
1ER 模型
出发点是对数据的整合, 对业务需求的抽象和总结, 整理出描述分析需求的主题然后根据分析主题构建适合的高层模型 (描述主题和主题间关系的业务概括) 中层模型 (细化高层模型的数据项) 物理模型(基于中层模型的基础上, 对数据进行物理存储)
ER 模型最典型的应用代表为金融业务的 10 大主题
2 维度模型
维度建模从分析决策的需求出发构建模型, 把分析需求拆解为维度和事实, 然后针对维度进行数据建模
3data vault 模型
出发点也是为了数据整合, 但加入了审计的思想, 要保留数据的历史性质, 讲求数据的可塑性(对主维度也进行了维度化, 通过关系 id 找回数据记录)
4anchor 模型
把 data vault 模型更一步极致化, 基本把所有数据记录成 key-value 化
(个人理解: ER 模型和维度模型都是专注与对数据的整合和规范, ER 模型从需求分析出发规范数据从查阅层面的储存, 维度模型更多的关心是数据仓库内部的一种数据存储机制两者其实互相不冲突, 可以在数据仓库实施中使用维度模型, 在数据模型设计数据集市实施时使用 ER 模型整合数据阿里巴巴的数据模型也是使用维度模型为核型理念进行模型方法论, 在搭建数据整合及管理体系 (onedata) 时, 使用的思想也符合 ER 模型的设计思想)
阿里巴巴数据模型层次为:
1ODS 操作数据层: 数据同步清洗保存历史
2CDM 公共维度模型层:
ß 1)DWD 明细数据层: 面向业务过程建模, 把维度退化到事实表中(减少事实表和维表的关联, 提高明细数据表的易用性); 生成事务型周期性快照累计快照的事实表
2)DWS 汇总数据层: 面向分析主题建模, 使用明细数据宽表, 复用关联计算, 减少数据扫描; 统一口径, 实现数据命名和算法的规范化; 构建一致性的维度, 统一数据的计算口径;
3ADS 应用数据层: 存放个性化 (不公用, 复杂性) 的统计指标; 基于个性化定制报表的应用
构建数据仓库的基本原则:
1 高内聚和低耦合: 将业务相近或者相关粒度相同的数据设计为一个逻辑或者物理模型; 按照使用概率将数据进行分开储存
2 核心模型和扩展模型分离: 核心模型包括的字段支持最常用的业务, 保持核心模型的简洁
3 公共处理逻辑下沉: 对公用处理逻辑进行提早下沉
4 成本和性能的平衡: 适当的冗余能换取查询性能不适宜过度冗余浪费储存成本
5 数据可回滚: 支持数据可以回滚
6 一致性: 统一企业数据的口径
7 命名清晰可理解
阿里巴巴数据整合及管理体系(one data)
构建数据模型, 最重要的还是有一个统一规范可共享的体系全公司以统一的方式理解分类数据, 才能有更完善的可用的数据模型
搭建数据整合管理体系的核心是: 从业务架构设计到模型和设计从数据研发到数据服务, 做到数据可管理可追溯可规避重复建设
阿里巴巴构建的体系
1 业务板块
根据业务属性进行板块划分, 阿里巴巴业务板块之间的指标或业务重叠性比较小
2 规范定义
对数据模型建设中的数据域业务过程维度度量修饰类型时间指标等进行一一定义
数据域: 指面向业务分析, 将业务过程或者维度进行抽象的集合
业务过程: 指企业的业务活动事件
时间周期: 用来明确数据统计的时间范围或者时间点
修饰类型: 修饰类型属于某个业务域, 用于描述修饰词
修饰词: 除了维度意外用于具象指标的定义
度量原子指标: 基于某一业务事件行为下的度量不可再拆分
维度: 维度是度量的环境
维度属性: 用于描述维度
派生指标: 派生指标 = 原子指标 + 多个修饰词 + 时间周期
指标体系: 阿里巴巴有一套成熟的指标命名规范
模型实施过程
业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功
实施工作流包括: 1 数据调研(包括业务调研与需求调研, 简单理解就是分析现有的业务流程分析需求行业要求)2 架构设计(数据区域划分和构建总线矩阵, 根据分析需求做业务板块的划分, 构建指标维度关系表, 清晰分析过程)
维度设计
确定维度属性及维度之间的关联关系, 找到业务源系统中的主维度表, 然后梳理各系统之间的维度关系和维度属性
维度处理的主要原则:
1 尽可能生成丰富的维度属性
2 尽可能多的给出包括一些富有意义的文字属性
3 区分数值型属性和事实
4 尽量沉淀出通用的维度属性
维度拥有层次结构, 当维度有钻取功能时, 可以设计反规范化的维度表进行储存 (分析系统的主要目的是用于数据的分析和统计, 如何更方便用户进行统计分析决定了分析系统的优劣) 维度采用雪花模型进行设计在统计分析时需要大量的关联操作, 使用复杂性高, 查询性能差采用反规范化的设计则方便易用且性能较好
一致性维度
数据仓库总线架构的重要基石之一就是一致性维度在数据仓库中使用多个指标进行交互是要注意维度是否完全一致
维度整合
垂直整合: 将多个源系统的维度数据整合到一个维度表
水平整合: 使用关联键进行维度组合(数据冲突的情况, 建议使用)
维度拆分:
拆分原则: 扩展性效能易用性
水平拆分: 按照维度的不同分类或维度的业务关联程度作为拆分依据, 可将维度进行水平拆分
垂直拆分: 当有维度属性产出时间有差异, 热度高度不同等, 可以构建垂直拆分
历史归档:
1 同前台归档策略, 在数据仓库中实现前台归档算法
2 同前台归档策略, 但采用数据库变更日志的方式
3 数据仓库自定义归档策略
维度变化:
缓慢变化维度:
1 插入新的维度行, 对新增修改的维度进行新记录的形式进行保存
2 添加维度列, 在维度设计中增加一列保存维度的变化情况, 优点是方便把维度归于旧值或新值计算
3 快照维度: 直接快照记录每天的维度情况优点: 简单有效, 开发和维护成本低; 使用方便, 理解性好缺点: 浪费存储
极限储存: 做缓慢变化时的历史拉链一般用分区来记录 start_dt,end_dt 随着时间的迁移, 分区数量会越来越多使用极限储存的办法是每月月初重新开始做历史拉链表; 每月 1 号做全量的数据, 月内剩下的每个日子存储上一天的变化情况
微型维度: 把维度进行组合, 对组合值进行枚举以建立维度
特殊维度:
递归层次: 当维度拥有层次等级, 可以建立递归的层次结构建立维度
行为维度: 通过后台算法计算得到的一些维度(如卖家主营业务的维度), 按照行为维度的计算频率, 逻辑复杂性确定维度的设计方式(冗余至现有维度或者单独加工生成维度)
多值维度: 同一个事实表需要多次调用同一个维度(1 可以降低事实表粒度, 把事实分摊到维度的方式; 2 事实表采用多维度; 3 桥接表的形式记录维度(使用桥接表记录事实表中使用了的维度, 并在桥接表中记录对应的维度信息))
杂项维度: 事实表中有些字段只是含有某种说明性需求, 存放在事实表, 或者生成维度保存都不妥当, 则可以建立杂项维度, 把这些字段建立到一个维度表中, 通过外键进行关联
事实表设计:
事实表类型: 1 事务事实表; 2 周期快照事实表; 3 累计快照事实表;
事实表设计原则:
1 尽可能包含所有与业务过程相关的事实:
2 选择对应的业务过程建立事实表, 并确保事实只与业务过程相关;
3 对于可加性事实进行分解(比如订单优惠率分解为订单原价金额, 订单优惠金额)
4 在选择维度和事实之前必须先声明粒度
5 在同一个事实表中不能有多种不同的粒度
6 保持事实单位的一致性
7 处理事实数据中的 null 值
8 退化维度到事实表, 提高事实表的易用性
9 父子事实的结构处理进行父度量分摊到子度量的操作
事实表设计实施方法:
1 选择业务过程及确定事实表类型(针对需要分析的需求, 从业务流中对业务过程进行筛选)
2 声明粒度(精确定义事实表的每一行的业务含义, 确定主键, 粒度应该选择最细力度的级别, 方便满足各项需求)
3 确定维度(选择能够清楚描述业务过程所处的环境的维度信息)
4 确定事实(选择与业务过程有关的所有事实, 对事实区分可加性, 半可加性, 非可加性,)
6 冗余维度(对事实表进行维度退化处理)
事务事实表:
单事务事实表: 单个业务过程使用单个事实表进行记录
多事务事实表: 把多个业务过程记录到同一张事实表中
对比: 多事务事实表能有效减少计算储存成本, 但会造成度量数据的大量冗余, 并增加下游业务使用的理解难度并且有一定的使用要求(同一个粒度, 一致维度)
设计原则: 1 业务过程包含完整性; 2 维度度量数据的一致性(确保度量单位统一, 数据分摊准确);3 事实可加性需要对度量进行分摊
周期快照表:
对确定的时间间隔内进行度量的计算, 这样很容易得出实体度量值, 而不需要聚集长期的事务历史
特性:
1 使用快照采样状态(以预定的间隔采样状态度量)
2 快照粒度, 计算快照的粒度范围
3 密度和稀疏性,(周期快照表需要定时记录数据)
4 半可加性(注意度量的汇总)
事务与快照应成对设计, 设计事务数据的时候应设计快照数据
可在快照事实表中多放置事实状态, 避免事实表的重复应用
考虑多周期的事实度量
累积快照表:
用于计算保存发生事件的时间隔间的需求
特性:
1 数据不断更新(数据必须进行每天不断更新, 记录每个业务日期的时间, 并保证更新正确)
2 多业务过程日期(一个业务流里面记录多个业务过程)
物理实现:
1 全量表形式, 每天的分区存储昨天的全量数据和当天的增量数据合并结果使用全量数据较少的情况
2 全量表变化, 分区保存最近产生 N 天的数据, 其余数据做归档需要保存多天的数据, 数据量较大, 存储消耗较大
3 以业务实体的结束时间分区, 每天的分区存放当天结束的数据并设计一个分区放置归档数据存放截至当前未结束的数据
无事实的事实表
1 记录一些事件类的事实, 如日志信息; 2 记录条件, 范围或资格类的信息
公共汇总层:
聚集型事实表, 通过对维度的汇总实现初步计算, 能有效减少数据的查询性能
原则:
一致性: 确保聚集表中的维度和度量与原始模型的维度和度量是一致的
避免单一表设计: 为减少用户的误用统计口径的几率, 每列应为单一的数据应用(筛选条件越复杂人们误用率越大)
聚集粒度可不同: 聚集可按照日常最基本的使用进行汇总
数据的公用性: 尽量考虑多个数据应用场景, 把需要经常分析的维度都考虑进去
不跨数据域: 数据域是在较高层次上对数据进行分类聚集的抽象, 数据聚集不需要跨数据域进行汇总
区分统计周期: 在表的命名上区分数据的统计周期
来源: http://www.jianshu.com/p/a35bbb721af4