大数据之路-阿里巴巴大数据实践
2024-03-28 18:43:20 6 举报AI智能生成
结合阿里整个大数据实践历程总结出的大数据方法论
作者其他创作
大纲/内容
数据管理篇
元数据
元数据概述
元数据定义
是关于数据的数据
打通了源数据、数据仓库、数据应用，记录了数据从生产到消费的全过程
主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态以及ETL的任务运行状态
按用途的不同分为两类
技术元数据
分布式计算系统存储元数据
分布式计算系统运行元数据
数据开发平台中的数据同步、计算任务、任务调度等信息
数据质量和运维相关元数据，如任务监控、运维报警、数据质量、故障等信息，包括任务监控运行日志、告警配置及运行日志、故障信息等
业务元数据
OneData元数据，如维度及属性、业务过程、指标等的规范化定义，用于更好地管理和使用数据
数据应用元数据，如数据报表、数据产品等的配置和运行元数据
元数据价值
在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持
在数据内容方面为集团数据进行数据域、数据主题、业务属性等的提取和分析提供数据素材
在数据应用方面打通产品及应用链路、保障产品数据准确、及时产出
统一元数据体系建设
元数据建设的目标是打通数据接入到加工、再到数据消费的整个链路，规范元数据体系与模型，提供统一的元数据服务出口，保障元数据产出的稳定性和质量
元数据应用
Data Profile
为元数据画像
基础标签
针对数据存储情况、访问情况、安全等级等进行打标
数仓标签
针对数据是增量还是全量、是否可再生、数据的生命周期来进行标签化处理
业务标签
根据数据归属的主题域、产品线、业务类型为数据打上不同的标签
潜在标签
这类标签主要是为了说明数据潜在的应用场景，比如社交、媒体、广告、电商、金融等
元数据门户
一站式的数据管理平台、高效的一体化数据市场
前台产品
数据地图，定位消费市场，实现检索数据、理解数据等找数据需求
围绕数据搜索，服务于数据分析、数据开发、数据挖掘、算法工程师、数据运营等数据表的使用者和拥有者
后台产品
数据管理平台，定位于一站式数据管理，实现成本管理、安全管理、质量管理等
围绕数据管理，服务于个人开发者、BU管理者、系统管理员等用户
应用链路分析
通过元数据血缘来分析产品及应用的链路，通过血缘链路可以清楚的统计到某个产品所用到的数据在计算、存储、质量上存在哪些问题，通过治理优化保障产品数据的稳定性
通过应用链路分析，产出表级血缘、字段血缘和表的应用血缘
常见的应用链路分析应用主要有影响分析、重要性分析、下线分析、链路分析、寻根溯源、故障排查等
数据建模中的应用
应用到数据建模的元数据有以下
表的基础元数据
下游情况、查询次数、关联次数、聚合次数、产出时间等
表的关联关系元数据
关联表、关联类型、关联字段、关联次数等
表字段的基础元数据
字段名称、字段注释、查询次数、关联次数、聚合次数、过滤次数等
在星形模型设计过程中，可能类似于如下使用元数据
基于下游使用中关联次数大于某个阈值的表或查询次数大于某个阈值的表等元数据信息，筛选用于数据模型建设的表
基于表的字段元数据，如字段中的时间字段、字段在下游使用中的过滤次数等，选择业务过程标识字段
基于主从表的关联关系、关联次数，确定和主表关联的从表
基于主从表的字段使用情况，如字段的查询次数、过滤次数、关联次数、聚合次数等，确定哪些字段进入目标模型
驱动ETL开发
OneClick产品
计算管理
系统优化
HBO
CBO
任务优化
Map倾斜
Join倾斜
Reduce倾斜
存储和成本管理
数据压缩
archive压缩
数据重分布
由于每个表的数据分布不同，插入数据的顺序不一样，会导致压缩效果有很大的差异，通过修改表的数据重分布，避免列热点，将会节省一定的存储空间
存储治理项优化
未管理表、空表、最近62天未访问表、数据无更新无任务表、数据无更新有任务表、开发库数据大于100GB且无访问表、长周期表等
生命周期管理
根本目的：以最少的存储成本来满足最大的业务需求，使数据价值最大化
生命周期管理策略
1、周期性删除策略
2、彻底删除策略
3、永久保留策略
4、极限存储策略
以超高压缩重复镜像数据，通过平台化配置手段实现透明访问
5、冷数据管理策略
6、增量表merge全量表策略
通用的生命周期管理矩阵
历史数据的等级划分
P0：非常重要的主题域数据和应用数据，具有不可恢复性，如交易、日志、集团KPI数据、IPO关联表等
P1：重要的业务数据和应用数据，具有不可恢复性，如重要的业务产品数据
P2：重要的业务数据和应用数据，具有可恢复性，如交易线ETL产生的中间过程数据
P3：不重要的业务数据和应用数据，具有可恢复性，如某些SNS产品报表
表类型划分
事件型流水表（增量表）
指数据无重复或者无主键数据，如日志
事件型镜像表（增量表）
指业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更
维表
包括维度和维度属性数据，如用户表、商品表
Merge全量表
业务过程性数据或者维表数据
由于数据本身有新增或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行merge操作，主键对应的属性只会保留最新的状态，历史状态保留在前一天分区中
ETL临时表
一般不建议保留，最多7天
TT临时数据
普通全量表
很多小业务数据或者产品数据，BI一般是直接全量拉取
数据成本计量
存储成本
计算成本
扫描成本
数据使用计费
计算付费、存储付费、扫描付费
数据资产成本管理分为数据成本计量和数据使用计费两个步骤
从成本的角度反映出数据加工链路中是否存在加工复杂、链路过长、依赖不合理等问题，间接辅助数据模型优化，提升数据整合效率
通过数据使用计费，可以规范下游用户的数据使用方法，提升数据使用效率
数据质量
数据质量保障原则
完整性
准确性
一致性
及时性
数据质量方法概述
消费场景知晓
通过数据资产等级和基于元数据的应用链路分析解决消费场景知晓的问题
根据应用的影响程度，确定资产等级；根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所涉及数据的资产等级和在各加工环节上根据资产等级的不同所采取的不同处理方式
数据资产（Asset）等级定义
毁灭性质，A1
全局性质，A2
局部性质，A3
一般性质，A4
未知性质，A5
数据资产等级落地方法
如何给每一份数据打上一个等级标签
同步到数据仓库的业务数据原始表主要用于承载业务需求，往往不能直接用于数据产品中，在数据产品中使用的都是经过数据仓库加工后的产出表
通过给不同的数据产品划分数据资产等级，再依托元数据的上下游血缘就可以将整个消费链路打上某一类数据资产标签
解决了消费场景知晓的问题，就知道了数据的重要等级，接下来就是针对不同的等级采取不同的保障措施
数据生产加工各环节卡点校验
在线系统
在线业务系统的数据生成过程中进行卡点校验
准确性校验：数据监控
一致性校验：在线数据变更如何高效的通知到离线数据仓库
通过工具，首先是发布平台，在业务进行重大变更时，订阅这个发布过程，然后给到离线开发人员；其次是数据库表的变化感知，主动通知到离线开发人员
操作离线数据工具的人员向在线业务开发人员强调数据资产的重要性程度
离线系统
数据从在线业务系统到数据仓库再到数据产品过程中需要在数据仓库这一层完成数据的清洗、加工，如何保障数据加工过程中的质量
首先是代码提交时的卡点检验，代码扫描工具SQLSCAN
其次是任务发布上线时的卡点校验，每一次变更都需要线下完成测试后再到线上测试，线下测试主要包括Code Review和回归测试，线上测试做Dry Run测试或真实环境运行测试
最后是节点变更或数据重刷前的变更通知
风险点监控
针对数据在日常运行过程中容易出现的风险进行监控并设置报警机制
在线数据风险点监控：BCP检测平台
离线数据风险点监控
DQC检测，保证数据准确性
摩萨德监控报警系统，根据离线任务的运行情况实时决策是否告警、何时告警、告警方式、告警给谁等
质量衡量
如何评价数据质量保障方案的优劣
1、数据质量起夜率，数据故障需要开发人员起夜处理，频繁起夜说明数据质量体系建设不够完善
2、数据质量事件
3、数据质量故障体系
故障定义
故障等级
故障处理
故障Review
数据应用篇
数据应用
生意参谋
外部商家使用的数据产品平台
对内数据产品平台
定位
数据产品的本质是产品，既然是产品，那么首先回答用户是谁、用户的痛点是什么、产品要解决用户的哪些痛点等
产品建设历程
临时需求阶段，2003年
V2.0自动化报表阶段，2006年
自主研发BI工具阶段，2012年
V4.0数据产品平台，2014年
整体架构介绍
数据质量和数据安全是数据产品最基础的要求
数据安全管理，数据权限管控
阿里对内数据产品平台即阿里数据平台，共有四个层次
数据监控
孔明灯
专题分析
应用分析
数据决策
数据模型篇
大数据领域建模综述
为什么需要数据建模
就像我们希望图书馆里的书籍分门别类的放置在书架上便于我们查找一样，数据建模的目的就是将数据有序有结构的分类组织和存储
数据模型就是数据组织和存储的方法，它强调从业务、数据存取和使用角度合理存储数据
数据建模有利于
1、性能，快速查找，I/O吞吐
2、成本，降低冗余
3、数据应用开发效率提升
4、数据质量，降低不同数据统计口径带来的不同结果的可能性
关系数据库系统和数据仓库
数据仓库的数据建模方法也依赖于关系型数据库理论，尽管分布式导致NoSQL的流行
大数据领域基于数据存取的特点在关系数据模型的范式上有了不同的选择
OLTP和OLAP系统的区别
OLTP: OnLine Transactional Processing，联机事务处理
主要是基本的、日常的事务处理，直白点讲，就是各种增删改查
OLAP: OnLine Analytical Processing，联机分析处理
主要是面向日常数据分析，它的数据主要是插入和查询，基本不涉及删除和修改操作
典型的数据仓库建模方法
ER模型
Entity Relationship，实体关系
出发点是整合数据，不能直接用于分析决策
从全企业的高度设计一个3NF模型
需要全面了解企业业务数据
实施周期非常长
对建模人员的能力要求非常高
与OLTP系统的3NF区别在于它是站在企业角度面向主题的抽象，而不是针对某个具体的业务流程的实体对象关系的抽象
1N：属性不可分
2N：属性依赖于主键
3N：属性直接依赖于主键
建模步骤分为三个阶段
高层模型
主题之间的关系，用于描述企业的业务总体概况
中层模型
在高层模型的基础上细化主题的数据项
物理模型/底层模型
在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等
案例：FS-LDM，Financial Services Logical Data Model，通过对金融业务的高度抽象和总结，将金融业务划分为10大主题，并以设计面向金融仓库模型的核心为基础，企业基于此模型做适当调整和扩展就能快速落地实施
维度模型
数据仓库领域Ralph Kimball大师所创，数据仓库建模的经典
出发点是分析决策的需求，为分析需求服务，关注用户如何快速的完成分析
典型代表
星型模型
雪花模型
特殊场景下使用
设计步骤
1、选择需要进行分析决策的业务过程，具体看我们分析的是某些事件的发生还是当前状态或是事件流转效率
单个业务事件，比如支付、退款等
某个事件的状态，比如当前余额等
一系列相关业务事件组成的业务流程
2、选择粒度
分析需要细分的程度
粒度是维度的一个组合
3、识别维表
选好粒度之后再基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选
4、选择事实
确定分析需要衡量的指标
Data Vault模型
ER模型的衍生品
出发点也是为了实现数据整合，不能直接用于数据分析决策
组成部分
Hub：企业的核心业务实体
Link：代表Hub之间的关系
这是与ER模型最大的区别：将关系作为一个独立的单元抽象，可以提升模型的扩展性
Satellite：Hub的详细描述内容
核心思想比喻：Hub可以想象成人的骨架，那么Link就是连接骨架的韧带，Satellite就是骨架上面的血和肉
比ER模型更容易设计和产出，它的ETL加工可实现配置化
Anchor模型
对Data Vault模型进一步规范化处理
出发点是设计一个高度可扩展模型
核心思想是所有的扩展只是添加而不是修改，因此将模型规范到6NF，基本变成了k-v结构化模型
组成部分
Anchors：类似于Hub
Attributes：类似于Satellite
Ties：类似于Link
Knots：可能会在多个Anchor中共用的属性的提炼
具有极大扩展性，但也会增加非常多的查询join操作
阿里巴巴数据模型实践综述
第一阶段
完全应用驱动
将数据以与源结构相同的方式同步到Oracle（ODS层），数据工程师基于ODS数据进行分析统计
没有系统化的模型方法体系
数据架构只有两层：ODS+DSS
第二阶段
ER模型+维度模型
数据架构有四层
ODL：操作数据层，和源数据保持一致
BDL：基础数据层，引入ER模型，加强数据的整合，构建一致的基础数据层
IDL：接口数据层，基于维度模型方法构建集市层
ADL：应用数据层，完成应用的个性化和基于展现需求的数据组装
困难和挑战：互联网的快速发展，人员的快速变化，业务知识功底不够全面，导致ER模型迟迟不能产出
经验：在不太成熟、快速变化的业务面前，构建ER模型风险极大
第三阶段
分布式的时代，选择维度模型，构建了公共层模型数据架构体系
数据公共层的建设
目的：着力解决数据存储和计算的共享问题
指导方法：一套统一化的集团数据整合及管理的方法体系（OneData）
一致性的指标定义体系
一致性的模型设计方法体系以及配套工具
阿里巴巴数据整合及管理体系：OneData体系和实施方法论
概述
定位和价值
数据可管理、可追溯、可规避重复建设
建设统一的、规范化的数据接入层（ODS）和数据中间层（DWD和DWS）
提供标准化、共享的数据服务能力，降低数据互通成本，释放计算、存储、人力等资源，以消除业务和技术之痛
体系架构
业务板块划分
阿里巴巴业务生态庞大，根据业务属性划分出几个相对独立的业务板块，各版块之间的指标或业务重叠性较小
规范定义
一套数据规范命名体系
模型设计
以维度建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实（进行规范定义）
规范定义
以维度建模作为理论基础，构建总线矩阵，划分和定义数据域、业务过程、维度、度量/原子指标、修饰类型、修饰词、时间周期、派生指标
名词术语
数据域：面向业务分析，将业务过程或者维度进行抽象的集合
业务过程：是一个不可拆分的行为事件，企业活动事件，通常使用行为动词表示业务执行活动，如下单、支付、退款
时间周期
修饰词
修饰类型：对修饰词的抽象划分
度量/原子指标：度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额
派生指标：对原子指标业务统计范围的圈定，即一个原子指标+多个修饰词+时间周期
维度：度量的环境，业务一类属性的集合，也可称为实体对象，如地理维度，时间维度
维度属性：隶属于一个维度，如地理维度里面的国家名称、省份名称等
指标体系
基本原则
由原子指标、派生指标、修饰类型、修饰词、时间周期组成
命名约定：业务过程、指标、修饰词等命名规范
算法说明
算法概述
举例
SQL算法说明
操作细则
派生指标的种类
事务型指标：对业务活动进行衡量的指标，例如新发商品数、订单支付金额
存量型指标：对实体对象某些状态的统计，例如商品总数、注册会员总数等
复合型指标：在事务型指标和存量型指标的基础上复合而成，例如浏览UV-下单买家数转化率
复合型指标规则
比率型：创建原子指标
比例型：创建原子指标
变化量型：不创建原子指标，增加修饰词，在此基础上创建派生指标
变化率型：创建原子指标
统计型：均值、分位数等，不创建原子指标
排名型：创建原子指标
对象集合型：创建原子指标
其他规则
上下层级派生指标同事存在时
父子关系原子指标存在时
模型设计
指导理论：以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实
模型层次
三层
操作数据层（ODS）
把操作系统的数据几乎无处理的存放在数据仓库系统中
同步：全量or增量
结构化处理并存储
保留累积历史、清洗数据
公共维度模型层（CDM）
存放明细事实数据、维表数据以及公共指标汇总数据
明细事实数据、维表数据一般根据ODS层数据加工生产
公共指标汇总数据一般根据维表数据和明细事实数据加工生成
细分为明细数据层（DWD）、汇总数据层（DWS）
应用数据层（ADS）
存放数据产品个性化的统计指标数据，根据CDM层和ODS层加工生成
个性化指标加工
基于应用的数据组装
调用原则
优先使用CDM层数据
没有CDM层数据的时候需要评估是否创建公共层数据，当不需要建设公共层时方可直接使用ODS层数据
ADS层作为产品特有的个性化数据一般不对外提供数据服务
基本原则
1、高内聚、低耦合
主要从数据业务特性和访问特性考虑
业务相近、粒度相同的数据设计为一个逻辑或者物理模型
高概率同时访问的数据放在一起
...
2、核心模型和扩展模型分离
3、公共处理逻辑下沉及单一
就是对底层进行封装与实现，而不暴露给应用层实现，不要让公共逻辑多出同时存在
4、成本与性能平衡
适当数据冗余可换取查询和刷新性能
5、数据可回滚
处理逻辑不变，不同时间多次运行数据结果确定不变
6、一致性
相同含义的字段在不同表中的命名必须相同，且规范命名
7、命名清晰、可理解
模型实施
业界常用的模型实施过程
Kimball 模型实施过程
四阶段
高层模型设计时期
定义业务过程维度模型的范围，提供每种星形模型的技术和功能描述
创建高层维度模型图，它是对业务过程中的维表和事实表的图形描述
确定维表创建的初始属性列表，为每个事实表创建提议度量
详细模型设计时期
对每个星形模型添加属性和度量信息
不断测试模型能否满足业务需求，确保模型的完备性
确定每个维表的属性和每个事实表的度量，并确定信息来源的位置、定义
确定属性和度量如何填入模型的初步业务规则
模型的审查、再设计和验证
产生详细的设计文档，提交ETL工程师设计和开发，由ETL人员完成物理模型的设计和开发
Inmon模型实施过程
定位：建立一个数据模型，描述数据仓库各部分是如何结合在一起，方便协调不同人员的工作以及适应不同类型的用户
三个层次
ERD层：Entity Relationship Diagram，实体关系图
数据模型最高层，描述了公司业务中的实体或主题域以及它们之间的关系
DIS层：Data Item Set，数据项集
中间层，描述了数据模型中的关键字、属性以及细节数据之间的关系
物理层：Physical Model，物理模型
最底层，描述数据模型的物理特性
其他模型实施过程
业务建模
生成业务模型，主要解决业务层面的分解和程序化
领域建模
生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型
逻辑建模
生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化
物理建模
生成物理模型，主要解决逻辑模型针对不同关系数据库的物理化以及性能等一些具体的技术问题
OneData实施过程
指导方针
首先，要进行充分的业务调研和需求分析
其次，进行数据总体架构设计，主要是根据数据域对数据进行划分，按照维度建模理论，构建总线矩阵、抽象出业务过程和维度
再次，对报表需求进行抽象整理出相关指标体系，使用OneData工具完成指标规范定义和模型设计
最后，就是代码研发和运维
实施工作流
1、数据调研
业务调研
数据仓库是要涵盖所有业务领域，还是各个业务领域独自建设
各个业务领域、业务线的业务有什么共同点和不同点
各个业务线可以细分为哪几个业务模块
每个业务模块具体的业务流程又是怎样
需求调研
收集数据使用者的需求，一般是数据分析师、业务运营人员等
调研途径
与数据使用者沟通获知需求
对报表系统中现有的报表进行研究分析
2、架构设计
数据域划分
根据业务过程进行归纳、抽象出数据域
构建总线矩阵
明确每个数据域下又哪些业务过程
业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度
3、规范定义
主要定义指标体系，包括原子指标、修饰词、时间周期、派生指标
4、模型设计
维度及属性的规范定义
维表、明细事实表和汇总事实表的模型设计
维度设计
维度设计基础
维度的基本概念
维度：维度建模中，将环境描述为“维度”
维度用于分析事实所需要的多样环境，比如在分析交易过程时，可以通过买家、卖家、商品、时间等维度描述交易发生的环境
维度使用主键标识其唯一性，主键也是确保与之相连的任何事实表之间存在引用完整性的基础
主键有两种
代理键
不具有业务含义，比如自增，一般用于处理缓慢变化维
自然键
具有业务含义的键，比如商品ID
维度属性：维度所包含的表示维度的列，称为维度属性
维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键
事实：维度建模中，将度量称为“事实”
维度的基本设计方法
维度的设计过程就是确定维度属性的过程
设计方法
1、选择维度或者新建维度
作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性
2、确定主维表
此处主维表一般是ODS表，直接与业务系统同步
3、确定相关维表
不同业务系统或者同一业务系统中的表之间存在关联性，根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性
4、确定维度属性
从主维表中选择维度属性或生成新的维度属性
从相关维表中选择维度属性或生成新的维度属性
确定维度属性的几点提示
1、尽可能生成丰富的维度属性
2、尽可能多的给出包括一些 富有意义的文字性描述
ID一般用于不同表之间的关联，而名称一般用于报表标签
3、区分数值型属性和事实
可以参考字段的一般用途
如果通常用于查询约束条件或分组统计，则是作为维度属性
如果通常用于参与度量的计算，则是作为事实
4、尽量沉淀出通用的维度属性
可以提高下游使用的方便性，减少复杂度
避免下游使用解析时由于各自逻辑不通而导致口径不一致
维度的层次结构
维度中的一些描述属性以层次方式或一对多的方式相互关联，可以被理解为包含连续主从关系的属性层次
例如，商品属于类目、类目属于行业...
在属性的层次结构中进行钻取是数据钻取的方法之一
规范化和反规范化
雪花模式
当属性层次被实例化为一系列维度，而不是单一维度时，被称为雪花模式
大多数联机事务处理系统（OLTP）的底层数据结构在设计时采用此种规范化技术，通过规范化处理将重复属性移至其自身所属的表中，删除冗余数据，以防止冗余带来的数据不一致性
反规范化
将维度的属性层次合并到单个维度中的操作称为反规范化
分析系统（OLAP）是用于数据分析和统计，如何方便用户进行统计分析决定了分析系统的优劣
采用雪花模式，用户在做统计分析的时候需要大量的关联操作，使用复杂度高，同时查询性能很差，而采用反规范化处理，则方便、易用且性能好
采用雪花模式，除了可以节约一部分存储外，对于OLAP系统来说没有其他效用，而现阶段存储的成本非常低
出于易用性和性能的考虑，维表一般是很不规范化的
在实际应用中几乎总是使用维表的空间来换取简明性和查询性能
一致性维度和交叉探查
构建企业级数据仓库不可能一蹴而就，一般采用迭代式构建过程，而单独构建存在的问题是形成独立型数据集市，导致严重的不一致性
可以通过构建企业范围内一致性维度和事实来构建总线架构，从而消除以上产生的不一致性问题
将不同数据域的商品的事实合并在一起进行数据探查，如计算PV和UV到下单GMV的转化率，称为交叉探查
交叉探查必须保证维度一致性，否则结果不可信
维度不一致性通常体现在维度格式和内容两种类型的不一致
维度一致性的几种表现形式
共享维表
一致性上卷，其中一个维度的维度属性是另一个维度的维度属性的子集，且两个维度的公共维度属性结构和内容相同
交叉属性，两个维度具有部分相同的维度属性
维度设计高级主题
维度整合
数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用来支持管理人员的决策。其中集成是数据仓库中的四个特性中最重要的一个
数据仓库的数据来源于大量的、分散的面向应用的操作型环境，不同的应用在设计过程中，可以自由决策，主要满足本应用的需求，很少会考虑其他系统进行数据集成
应用之间的差异具体表现
编码、命名习惯、度量单位等存在很大差异
应用出于性能和扩展性的考虑，或者随着技术架构的演变，以及业务的发展，采用不同的物理实现
拆分至不同类型的数据库中，部分数据采用关系型数据库，部分采用NoSQL
拆分成同一类型数据库中的多个物理表
将面向应用的数据转换为面向主题的数据仓库数据，需要进行数据集成
命名规范的统一
表名、字段名等
字段类型的统一
公共代码及代码值的统一
业务含义相同的表的统一
依据高内聚、低耦合的理念，在物理视线中将业务关系大、源系统影响差异小的表进行整合，将业务关系小、源系统影响差异大的表进行分而治之
集成方式
采用主从表的设计方式，主表存基本通用信息，从表存个性信息，主表主键建议采用复合主键
直接合并，共有信息和个性信息都放在同一个表中，如果表的字段重合度低，则会出现大量空值，对存储和易用性会有影响，需谨慎选择
不合并，在源表的表结构及主键等差异很大，无法合并，使用数据仓库里的多个表存放各自的数据
维表的整合
垂直整合
不同来源的表包含相同的数据集，只是存储的信息不同
水平整合
不同来源的表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉
如果存在交叉，需要去重
如果不存在交叉，需要考虑不同子集的自然键是否存在冲突
如果不冲突，可以考虑将各子集的自然键作为整合后的表的自然键
设置超自然键（联合主键）
水平拆分
维度通常可以按照类别或类型进行细分，不同类别其维度属性可能相同也可能不同，这种情况如何设计维度
方案一是将维度的不同分类实例化为不同的维度，同时在主维度中保存公共属性
方案二是维护单一维度，包含所有可能的属性
选择哪种方案需要考虑以下三个原则
扩展性：高内聚、低耦合
效能：可牺牲一定的存储成本达到性能和逻辑的优化
易用性：模型可理解性高，访问复杂度低
根据数据模型设计思想，对维度进行水平拆分的时候应考虑
维度的不同分类的属性差异情况
如果属性差异大，选方案一
业务的关联程度
两个相关性较低的业务，耦合在一起弊大于利
垂直拆分
在进行维度设计时，依据维度设计原则，尽可能丰富维度属性，同时进行反规范化处理
在具体实现时可能存在的问题
某些维度属性的来源表产出时间较早，有些较晚
某些维度属性的热度高，使用频繁，有些热度低、较少使用
某些维度属性经常变化，而某些比较稳定
出于扩展性、产出时间、易用性等方面考虑，设计主从维度
主维表存放稳定、产出时间早、热度高的属性
从维表存放变化较快、产出时间较晚、热度低的属性
历史归档
定期将历史数据归档至历史维表
归档策略
同前台归档策略，规定时间周期对历史数据进行归档
适用于前台归档策略逻辑简单，且变更不频繁的情况
同前台归档策略，但采用数据库变更日志的方式
使用增量日志的删除标志，作为前台数据归档的标志，通过此标志对数据仓库的数据进行归档
此方式不需要关注前台归档策略，简单易行，但对前台应用的要求是数据库的物理删除只有在归档时才执行，应用中的删除只是逻辑删除
数据仓库自定义归档策略
维度变化
缓慢变化维
缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化，相对数据增长较快的事实表相比，维度变化相对缓慢
三种方式处理缓慢变化维
重写维度值
此方式不保留历史数据，始终取最新数据
插入新的维度行
保留历史数据
插入维度列
保留历史数据，可以使用任何一个属性列
快照维表
在Kimball的维度建模中，必须使用代理键作为每个维表的主键，用于处理缓慢变化维
在阿里巴巴的数据仓库建设中虽然使用的是Kimball的维度建模理论，但实际上并未使用代理键
为什么不使用代理键
对于分布式系统，不存在事务的概念，对于每个表的记录生成稳定的全局唯一的代理键难度很大
使用代理键会大大增加ETL的复杂性，对ETL任务的开发和维护成本很高
不使用代理键如何处理缓慢变化维
采用快照方式，即处理维度变化的方式就是每天保留一份全量快照数据
优点
简单有效，开发和维护成本低
使用方便，理解性好
弊端
浪费极大存储
此方法实现了牺牲存储获取ETL效率的优化和逻辑上的简化
要杜绝过度使用这种方法，而且必须要有对应的数据生命周期制度，清除无用的历史数据
极限存储
目的：降低快照维表产生的极大存储的弊端
全量存储
历史拉链存储
利用维度模型中缓慢变化维的第二种处理方式，这种处理方式是通过新增两个时间戳字段，将所有以天为粒度的变更数据都记录下来
分区字段也是时间戳字段，start_dt/end_dt
弊端
对于下游使用方式存在一定的理解障碍
使用start_dt和end_dt做分区，随着时间的推移，分区数量会极度膨胀，而现行的数据库系统都有分区数量限制
极限存储
解决历史拉链存储的两个弊端
1、透明化
底层的数据还是历史拉链存储，但是上层做一个视图操作或者在Hive里做一个hook，通过分析语句的语法树，把对极限存储前的表的查询转换成极限存储表的查询。对下游用户来说，极限存储表和全量存储的方式是一样的，此解决历史拉链存储的第一个弊端
2、分月做历史拉链表
每个月月初重新开始做历史拉链表，大大减少分区数
利
极大的压缩了全量存储的成本，又可以对下游用户透明的效果
弊
产出效率很低，大部分极限存储通常需要t-2
对变化频率高的数据并不能达到节约成本的效果
综合利弊，在实际生产中做极限存储需要进行一些额外的处理
在做极限存储前有一个全量存储表，全量存储表仅保留最近一段时间的全量分区数据，历史数据通过映射的方式关联到极限存储表，即用户只访问全量存储表，对用户来说极限存储是不可见的
对于部分变化频率频繁的字段需要过滤，如果不过滤的话极限存储就相当于每个分区存储一份全量数据，起不到节约存储成本的效果
微型维度
通过将一些属性从维表中移出，放置到全新的维表中，可以解决维度的过渡增长导致极限存储效果的大打折扣的问题，两种方案
垂直拆分
微型维度
微型维度的创建是通过将一部分不稳定的属性从主维度中移出，并将它们放置到拥有自己代理键的新表中来实现，这些属性相互之间没有直接关联，不存在自然键
弊
微型维度是事先用所有可能值的组合加载的，需要考虑每个属性的基数，且必须是枚举值，但很多属性可能是非枚举型
ETL逻辑复杂，对于分布式系统，生成代理键和使用代理键进行ETL加工都非常复杂
破坏了维度的可浏览性
特殊维度
递归层次
维度的递归层次按照层级是否固定分为均衡层次结构和非均衡层次结构
在物理实现时可以通过递归SQL实现
由于很多数据仓库系统和商业智能工具不支持递归SQL，且用户使用递归SQL的成本较高，所以在维度模型中，需要对此层次结构进行处理
1、层次结构扁平化
对于均衡层次结构，采用扁平化最有效
对于非均衡层次结构，可以通过预留级别的方式来解决，但扩展性较差
2、层次桥接表
行为维度
和事实相关，事实衍生的维度
按照加工方式划分
另一个维度的过去行为
快照事实行为的维度
分组事实行为的维度
复杂逻辑事实行为维度
对于行为维度，有两种处理方式
将其冗余至现有的维表中
加工成单独的行为维表
采用哪种处理方式主要参考如下两个原则
避免维度过快增长
避免耦合度过高
多值维度
事实表中的一条记录在某维表中有多条记录与之对应，比如父订单一条记录对于多条子订单记录
常见处理方式有三种
降低事实表的粒度
采用多字段
采用较为通用的桥接表
桥接方式更加灵活、扩展性更好，但是逻辑复杂、开发和维护成本较高，可能带来双重计算的风险，选择此方式需慎重
根据业务的表现形式和统计分析需求进行选择
多值属性
维表中的某个属性字段同时有多个值。它是多值维表的另一种表现形式
常见处理方式有三种
保持维度主键不变，将多值属性放在维度的一个属性字段中
保持维度主键不变，但将多值属性放在维度的多个属性字段中
维度主键发生变化，一个维度值存放多条记录
杂项维度
由操作系统中的指示符或者标志字段组合而成的，一般不在一致性维度之列
物理实现时不能进行物理化，订单杂项维度和其他维度一起，会将维度属性退化至事实表中
事实表设计
事实表基础
事实表特性
事实表紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程相关的度量
事实表设计的目的是为了度量业务过程
粒度
事实表中的一条记录所表达的业务细节程度被称为粒度
通常粒度可以通过两种方式来表述
维度属性组合所表示的细节程度
所表示的具体业务含义
作为度量业务过程的事实，一般为整型或者浮点型的十进制数值，有三种类型
可加性事实：可以按照与事实表关联的任意维度进行汇总
半可加性事实：只能按照特定维度汇总，不能对所有维度汇总
不可加性事实：比如比率型事实。对于不可加性事实可以分解为可加的组件来实现聚集
相对维表来说，通常事实表要细长很多，行的增加速度也比维表快很多
退化维度
存储到事实表中的维度属性
与其他维度一样，退化维度也可以用来进行事实表的过滤查询、实现聚合操作等
事实表有三种类型
事务事实表
用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称原子事实表
周期快照事实表
以具有规律性、可预见性的时间间隔记录事实，如每天、每月、每年
累积快照事实表
用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改
事实表设计原则
1、尽可能包含所有与业务过程相关的事实
2、只选择与业务过程相关的事实
3、分解不可加性事实为可加的组件
4、在选择维度和事实之前必须先声明粒度，且每个维度与事实必须与所定义的粒度保持一致
5、在同一个事实表中不能有多种不同粒度的事实
6、事实的单位要保持一致
7、对事实的null值要处理，因为数据库中null只对常用数字型字段的SQL过滤条件都不生效，建议用零值填充
8、使用退化维度提高事实表的易用性
事实表设计方法
第一步，选择业务过程及确定事实表类型
第二步，声明粒度
尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性
第三步，确定维度
完成粒度声明，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了
第四步，确定事实
事实可以通过回答“过程的度量是什么”来确定
选择与业务过程有关的所有事实
事实的粒度要与所声明的事实表的粒度一致
不可加性事实需要分解为可加的组件
第五步，冗余维度
反规范化
事务事实表
设计过程
任何类型的事件都可以被理解为一种事务，事务事实表就是针对这些事务构建一类事实表，用以跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据
案例：淘宝交易事务事实表
1、选择业务过程
2、确定粒度
3、确定维度
4、确定事实
5、冗余维度
单事务事实表
针对每个业务过程设计一个事实表
优点是可以方便的对每个业务过程进行独立的分析研究
多事务事实表
同一个事实表包含不同的业务过程
在设计时有两种方法进行事实的处理
不同业务过程的事实使用不同的事实字段进行存放
案例：淘宝交易事务事实表将拥有3个相同粒度的业务，即下单、支付、成功，放到同一个事实表中
不同业务过程的事实使用同一个事实字段进行存放，但是增加一个业务过程标签
案例：淘宝收藏商品事务事实表将收藏商品和删除商品放在同一个事实表中
多事务事实表的选择
当业务过程度量比较相似，差异不大时，可采用第二种多事务事实表的设计方式，使用同一字段来表示度量数据
当不同业务过程的度量差异较大时，可以选择第一种多事务事实表的设计方式，将不同业务过程的度量使用不同字段冗余到表中，非当前业务过程则置零表示，这种方式所存在的问题是度量字段零值较多
两种事实表对比
1、业务过程
多个业务过程是否放到同一个事实表中，首先需要分析不同业务过程之间的相似性和业务源系统
2、粒度和维度
当不同业务过程的粒度相同，同时拥有相似性维度时，此时就可以考虑采用多事务事实表。如果粒度不同，则必定是不同的事实表
3、事实
如果单一业务过程的事实较多，同时不同业务过程的事实又不相同，则可以考虑使用单事务事实表，处理更加清晰
4、下游用户使用
单事务事实表对应下游用户而言更容易理解，而多事务事实表包含多个业务过程，用户使用时较为困惑
5、冗余维度
多事务事实表不同的业务过程只需要冗余一次，而单事务事实表需要冗余多次
6、计算成本
当业务过程数据来源于同一个业务系统，具有相同的粒度和维度，且维度较多而事实相对不多时，此时可以考虑使用多事务事实表，不仅其加工计算成本较低，同时在存储上也相对节省，是一种较优的处理方式
父子事实的处理方式
案例：分摊父订单金额到各子订单
事实的设计准则
1、事实完整性
尽可能多地获取所以度量
2、事实一致性
3、事实的可加性
周期快照事实表
背景
事务事实表能很好地跟踪一个事件，并对其度量，以提供丰富的分析能力。然而，当需要一些状态度量时，比如账户余额、买卖家星级、商品库存等，则需要聚集与之相关的事务才能进行识别计算，或者聚集事务无法识别，比如温度等。对于这些状态度量，事务事实表是无效率的
周期快照事实表是在确定的间隔内对实体的度量进行抽样，这样可以容易地研究实体的度量值，而不需要聚集长期的事务历史
特性
1、用快照采样状态
以预定的间隔采样状态度量
2、快照粒度
快照事实表的粒度通常总是被多维声明，可以简单地理解为快照需要采样的周期以及什么将被采样
3、密度与稀疏性
事务事实表是稀疏的，只有当天发生的业务过程，事实表才会记录该业务过程的事实；而快照事实表是稠密的，无论当天是否有业务过程发生，都会记录一行
4、半可加性
与事务事实表的可加性事实不同，半可加性事实不能根据时间维度获得有意义的汇总结果（时间一般被作为周期）
快照事实表的设计步骤
确定快照事实表的快照粒度
确定快照事实表采样的状态度量
实例
单维度的每天快照事实表
混合维度的每天快照事实表
相当于单维度，只是在每天的采样周期上针对多个维度进行采样
全量快照事实表
周期快照事实表产出模式
从事务事实表进行汇总产出
直接使用操作型系统的数据作为周期快照事实表的数据源进行加工
比如淘宝卖家星级、卖家DSR（物流服务、描述相符、服务态度）事实表
注意事项
1、事务事实表和快照事实表往往都是成对设计、互相补充，以满足更多的下游统计分析需求
2、附加事实
3、周期到日期度量
累积快照事实表
背景
对于类似于研究事件之间时间间隔的需求，比如，统计买家下单到支付的时长、买家支付到卖家发货的时长、买家从下单到确认收货的时长等，如果使用事务事实表进行统计，则逻辑复杂且性能很差，采用累积快照事实表可以很好的解决
适用于具有较明确起止时间的短生命周期的实体，比如交易订单、物流订单等，对于实体的每一个实例，都会经历从诞生到消亡等一系列步骤
对于商品、用户等具有长生命周期的实体，一般采用周期快照事实表更合适
设计过程
第一步，选择业务过程
第二步，确定粒度
第三步，确定维度
第四步，确定事实
累积快照事实表解决的最重要的问题是统计不同业务过程之间的时间间隔，建议将每个过程的时间间隔作为事实放在事实表中
第五步，退化维度
在传统的维度模型设计完成之后，在物理实现中将各维度的常用属性退化到事实表中，以大大提高对事实表的过滤查询、统计聚合等操作的效率
特点
1、数据不断更新
2、多业务过程日期
用于计算业务过程之间的时间间隔
特殊处理
1、非线性过程
业务过程统一
针对业务关键里程碑构建全面的流程
循环流程的处理
2、多源过程
针对多业务过程建模时，业务过程可能来自于不同的系统或者来源于不同的表
针对多源业务建模，主要考虑事实表的粒度问题
3、业务过程取舍
物理实现
第一种方式是全量表的形式
适用于全量数据较少的情况
第二种方式是全量表的变化形式
主要针对事实表数据量很大的情况
第三种方式是以业务实体的结束时间分区
三种事实表的比较
时期/时间
日期维度
粒度
事实
事实表加载
事实表更新
无事实的事实表
在维度模型中，事实表用事实来度量业务过程，不包含事实或度量的事实表称为“无事实的事实表”
虽然没有明确的事实，但可以用来支持业务过程的度量
常见的无事实的事实表主要两种
事件类，记录实践的发送，比如日志类事实表
条件、范围或资格类
聚集型事实表
聚集
利
通过汇总明细粒度数据，快速响应用户的查询，减少数据库在响应查询时必须执行的工作量，改进查询性能
减少不同用户访问明细数据带来的结果不一致问题
弊
需要事先对其进行加载和维护
聚集的基本原则
一致性
聚集表必须提供与查询明细粒度数据一致的查询结果
确保一致性最简单的方法是确保聚集星形模型中的维度和度量与原始模型中的维度和度量保持一致
避免单一表设计
不要在同一个表中存储不同层次的聚集数据，否则将会导致双重计算或者出现更糟糕的事情
避免此类问题的做法
在聚集时显式的加入数据层级列以示区别
把按天和按月汇总的数据用两列存放
聚集粒度可不同
聚集不需要保持与原始明细粒度数据一样的粒度，聚集只关心所需要查询的维度
聚集的基本步骤
第一步，确定聚集维度
第二步，确定一致性上钻
第三步，确定聚集事实
阿里公共汇总层
1，基本原则
除了聚集的基本原则外，还应该遵循
1，数据公用性
2、不跨数据域
3、区分统计周期
在表的命名上要能说明数据的统计周期，如_1d/_td/_nd/...
2、交易汇总表设计流程
按商品粒度汇总
按卖家粒度汇总
按卖家、买家、商品粒度汇总
按二级类目汇总
聚集补充说明
1、聚集是不跨越事实的
为了获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致
2、聚集带来的问题
聚集会带来查询性能的提升，但聚集也会增加ETL维护的难度
当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整，这一额外工作随着业务复杂性的增加，会导致多数ETL人员选择简单强力的方法，删除并重新聚集数据
数据技术篇
日志采集
数据同步
离线数据开发
实时技术
数据服务
数据挖掘
收藏
0 条评论
下一页
为你推荐
查看更多
