文章目录
- 《大数据之路:阿里巴巴大数据实践》读书笔记
-
- 阿里巴巴大数据系统体系架构
- 二、第1篇:数据技术篇
-
- [2.1 日志采集](#2.1 日志采集)
- [2.2 数据同步](#2.2 数据同步)
- [2.3 离线数据开发](#2.3 离线数据开发)
- [2.4 实时技术](#2.4 实时技术)
- [2.5 数据服务](#2.5 数据服务)
- [2.6 数据挖掘](#2.6 数据挖掘)
- 三、第2篇:数据模型篇
-
- [3.1 大数据领域建模综述](#3.1 大数据领域建模综述)
-
- 为什么需要数据建模
- 四种典型的数据仓库建模方法论
- [OLTP vs OLAP](#OLTP vs OLAP)
- [3.2 阿里巴巴数据整合及管理体系 --- OneData](#3.2 阿里巴巴数据整合及管理体系 — OneData)
- [3.3 维度设计](#3.3 维度设计)
-
- 维度的基本概念
- 维度的基本设计方法
- 维度的层次结构
- [规范化 vs 反规范化](#规范化 vs 反规范化)
- 一致性维度与交叉探查
- 维度设计高级主题
- 缓慢变化维(SCD)
- [3.4 事实表设计](#3.4 事实表设计)
- 四、第3篇:数据管理篇
-
- [4.1 元数据](#4.1 元数据)
- [4.2 计算管理](#4.2 计算管理)
-
- [HBO(History-Based Optimizer,基于历史的优化器)](#HBO(History-Based Optimizer,基于历史的优化器))
- [CBO(Cost-Based Optimizer,基于代价的优化器)](#CBO(Cost-Based Optimizer,基于代价的优化器))
- [任务优化 --- 倾斜处理](#任务优化 — 倾斜处理)
- [4.3 存储和成本管理](#4.3 存储和成本管理)
- [4.4 数据质量](#4.4 数据质量)
- 五、第4篇:数据应用篇
《大数据之路:阿里巴巴大数据实践》读书笔记
阿里巴巴大数据系统体系架构
阿里巴巴大数据系统主要分为四大层次:
┌─────────────────────────────────────┐
│ 数据应用层 │ ← 生意参谋、阿里数据平台等
├─────────────────────────────────────┤
│ 数据服务&基础工具层 │ ← OneService
├─────────────────────────────────────┤
│ 数据架构&构建方法&工具平台 │ ← OneData体系
│ (MaxCompute / StreamCompute / DataX) │
├─────────────────────────────────────┤
│ 数据采集层 │ ← Aplus.JS / UserTrack / TimeTunnel
└─────────────────────────────────────┘
二、第1篇:数据技术篇
2.1 日志采集
阿里巴巴的日志采集体系包括两大体系:
| 采集方案 | 定位 | 技术要点 |
|---|---|---|
| Aplus.JS | Web端(浏览器)日志采集 | 页面浏览日志、页面交互日志("黄金令箭") |
| UserTrack | APP端(无线客户端)日志采集 | 页面事件、控件点击、特殊场景、设备标识 |
页面浏览日志采集流程
- 客户端日志采集:通过植入HTML文档内的JavaScript脚本执行,采集页面参数、浏览行为上下文、运行环境信息
- 客户端日志发送:采集脚本向日志服务器发起HTTP请求,日志信息以URL参数形式发送
- 服务器端日志收集:日志服务器接收请求后立即响应,将日志内容写入缓冲区(nginx)
- 服务器端日志解析存档:专门的日志处理程序解析日志(Filebeat),转存入标准日志文件并注入实时消息通道(Kafka)
无线客户端日志采集要点
- 页面事件:记录页面曝光、停留时长等
- 控件点击及其他事件:按钮点击、滑动等交互行为
- H5 & Native日志统一:实现H5页面与Native应用的日志数据打通
- 设备标识:解决设备唯一标识问题
- 日志传输:建立高性能、高可靠性的传输通道
2.2 数据同步
三种数据同步基础方式
| 同步方式 | 原理 | 适用场景 |
|---|---|---|
| 直连同步 | 直接连接业务数据库读取数据 | 数据量小、实时性要求高的场景 |
| 数据文件同步 | 通过文件传输方式同步数据 | 异构系统间数据交换 |
| 数据库日志解析同步 | 解析数据库Binlog实现增量同步 | 大数据量、低延迟的实时同步 |
阿里数据仓库的同步方式
- 批量数据同步:通过DataX和同步中心,直连异构数据库(备库)抽取各种时间窗口的数据
- 实时数据同步:通过TimeTunnel(TT)传输数据库的增量数据
常见问题与解决方案
| 问题 | 解决方案 |
|---|---|
| 分库分表处理 | 统一数据路由规则,屏蔽分库分表对下游的复杂性 |
| 高效同步和批量同步 | 采用批量合并、异步处理等策略提高同步效率 |
| 增量与全量同步的合并 | 设计合理的合并策略,保证数据一致性 |
| 同步性能处理 | 优化并行度、合理分配资源、避免热点 |
| 数据漂移处理 | 采用多时间戳策略,处理业务时间与系统时间的漂移问题 |
2.3 离线数据开发
统一计算平台 --- MaxCompute
MaxCompute是阿里巴巴自主研发的离线大数据平台,提供:
- 强大的分布式存储能力
- 丰富的SQL/MR计算能力
- 完善的安全和权限管理
- 海量数据的离线处理能力
统一开发平台
提供一站式的数据开发环境,包括:
- 可视化SQL开发
- 任务调试与测试
- 版本管理
- 代码评审
任务调度系统
- 背景:海量任务需要按依赖关系有序执行
- 特点:支持复杂的任务依赖配置、基线管理、优先级调度、失败重试等
- 应用:保障每日数据按时产出,特别是大促期间的基线保障
2.4 实时技术
流式技术架构
阿里巴巴的实时计算平台 StreamCompute(流式大数据平台),架构包括:
数据源 → 数据采集 → 消息队列 → 实时计算 → 实时存储 → 数据服务
| 环节 | 技术组件 | 说明 |
|---|---|---|
| 数据采集 | 日志采集系统 | 实时采集日志和数据库变更 |
| 消息队列 | 消息中间件 | 承担数据缓冲和分发 |
| 实时计算 | StreamCompute | 流式数据处理引擎 |
| 数据存储 | HBase/MySQL等 | 低延迟的数据查询存储 |
| 数据服务 | 实时数据接口 | 对外提供实时数据服务 |
流式数据模型
- 数据分层:同样遵循ODS→DWD→DWS→ADS的分层理念
- 多流关联:解决多个数据流之间的关联计算问题
- 维表使用:在流计算中高效使用维度数据
2.5 数据服务
服务架构演进
| 阶段 | 名称 | 特点 |
|---|---|---|
| 1 | DWSOA | 早期基于SOA的数据服务架构 |
| 2 | OpenAPI | 开放API方式,但缺乏统一管控 |
| 3 | SmartDQ | 智能数据查询层,基于逻辑表的概念 |
| 4 | 统一数据服务层(OneService) | 统一、标准化、高性能的数据服务平台 |
OneService 技术架构
OneService以数据仓库整合计算好的数据作为数据源,对外通过接口方式提供三大特色数据服务:
- 简单数据查询服务:基础的单表/单维度查询
- 复杂数据查询服务:承接集团用户识别、用户画像等复杂查询
- 实时数据推送服务:主动推送数据变更
核心组件
| 组件 | 功能 |
|---|---|
| SmartDQ | 智能数据查询,将逻辑查询转换为物理查询 |
| iPush | 实时数据推送服务 |
| Lego | 乐高式数据服务编排 |
| uTiming | 定时数据服务 |
最佳实践
- 性能优化:缓存策略、SQL优化、并行查询
- 稳定性保障 :
- 元数据隔离(日常/预发/线上三套环境)
- 机房隔离(双机房容灾)
- 分组隔离(按优先级分层)
- 安全限制(最大返回记录数、必传字段、超时时间)
- 完善的调用监控和日志采集
2.6 数据挖掘
数据挖掘中台体系
| 层次 | 内容 |
|---|---|
| 挖掘数据中台 | 统一的特征工程平台、样本数据管理 |
| 挖掘算法中台 | 统一的算法平台、模型训练与部署 |
典型应用案例
- 用户画像:构建全面的用户标签体系
- 互联网反作弊:识别刷单、虚假交易等作弊行为
三、第2篇:数据模型篇
3.1 大数据领域建模综述
为什么需要数据建模
- 数据有序、有结构地分类组织和存储
- 避免数据的冗余和重复建设
- 规避数据烟囱和不一致性
- 提高数据易用性
四种典型的数据仓库建模方法论
| 模型 | 提出者 | 核心思想 | 适用场景 |
|---|---|---|---|
| ER模型 | Bill Inmon | 实体关系建模,高度规范化 | 企业级数据仓库,强调数据一致性 |
| 维度模型 | Ralph Kimball | 以事实表为中心,围绕维度表 | 面向分析的数据集市,查询性能高 |
| Data Vault模型 | Dan Linstedt | 面向细节的、可追踪历史的模型 | 强调数据血缘和历史追溯 |
| Anchor模型 | Lars Rönnbäck | 高度规范化的可扩展模型 | 极端灵活性和可扩展性要求 |
OLTP vs OLAP
| 特性 | OLTP | OLAP |
|---|---|---|
| 定位 | 业务操作处理 | 分析决策支持 |
| 数据特征 | 当前细节数据 | 历史汇总数据 |
| 访问模式 | 增删改查 | 大量查询分析 |
| 数据量 | GB级 | TB/PB级 |
| 响应时间 | 毫秒级 | 秒级/分钟级 |
3.2 阿里巴巴数据整合及管理体系 --- OneData
定位及价值
OneData是阿里巴巴数据整合及管理的方法体系和工具,核心价值:
- 构建统一、规范、可共享的全域数据体系
- 避免数据的冗余和重复建设
- 规避数据烟囱和不一致性
- 充分发挥阿里巴巴在海量、多样性数据方面的独特优势
体系架构
┌─────────────────────────────────────┐
│ 数据应用层(ADS) │
├─────────────────────────────────────┤
│ 汇总数据层(DWS) │
├─────────────────────────────────────┤
│ 明细数据层(DWD) │
├─────────────────────────────────────┤
│ 操作数据层(ODS) │
└─────────────────────────────────────┘
规范定义
名词术语标准化:
- 业务板块:根据业务属性划分的高标准数据分类
- 数据域:面向业务过程的数据分类(如交易域、商品域)
- 业务过程:如下单、支付、发货等
- 维度/属性:描述事实的角度和特征
- 指标/度量:可量化的数值
指标体系:
- 原子指标:不可再拆分的最小度量(如支付金额)
- 派生指标:原子指标 + 修饰词 + 时间周期(如最近1天无线端支付金额)
模型设计指导理论
- 以维度建模为基础
- 综合考虑ER模型的规范化思想
- 结合阿里巴巴业务特点进行适配
模型层次
| 层次 | 名称 | 说明 |
|---|---|---|
| ODS | 操作数据层 | 原始数据接入,结构与源系统保持一致 |
| DWD | 明细数据层 | 数据清洗、规范化,维度退化 |
| DWS | 汇总数据层 | 按维度汇总,构建公共汇总指标 |
| ADS | 应用数据层 | 面向具体应用场景的数据产品 |
基本原则
- 高内聚、低耦合:同一业务过程的数据放在一起
- 核心模型与扩展模型分离:核心模型稳定,扩展模型灵活
- 公共处理逻辑下沉:公共计算下沉到公共层
- 成本与性能平衡:不追求极致规范化,考虑计算和存储成本
- 数据可回滚:支持数据回溯和重跑
OneData实施过程
相比业界常用的模型实施过程,OneData强调:
- 从业务需求出发,但不被短期需求绑架
- 充分进行数据域和业务过程的分析
- 规范定义先行,模型设计跟进
- 持续迭代优化
3.3 维度设计
维度的基本概念
维度是描述事实的角度,如时间、地域、商品、买家、卖家等。
维度的基本设计方法
- 选择维度(或新建维度)
- 确定主维表和相关维表
- 确定维度属性
- 设计维度层次
维度的层次结构
维度属性之间存在层次关系,如:
- 地域:国家 → 省份 → 城市 → 区县
- 类目:一级类目 → 二级类目 → 三级类目 → 叶子类目
- 时间:年 → 季度 → 月 → 日 → 小时
规范化 vs 反规范化
| 方式 | 说明 | 适用场景 |
|---|---|---|
| 规范化 | 维度属性拆分到多个子维表 | 节省存储,但关联多 |
| 反规范化 | 维度属性合并到一张维表 | 查询快,存储冗余 |
在阿里巴巴实践中,更多地采用反规范化设计,因为:
- 存储成本相对计算成本更低
- 减少关联操作,提高查询效率
- 分布式系统中Join成本很高
一致性维度与交叉探查
- 一致性维度:不同业务过程共用同一套维度定义
- 交叉探查:基于一致性维度,可以进行跨业务域的分析
维度设计高级主题
| 主题 | 说明 |
|---|---|
| 维度整合 | 将不同来源的同类维度整合为统一维度 |
| 水平拆分 | 按维度属性或业务类型拆分维度表 |
| 垂直拆分 | 将不常用属性拆分到扩展表 |
| 历史归档 | 将历史维度数据归档处理 |
缓慢变化维(SCD)
维度属性会随时间变化,常见处理方式:
| 类型 | 方式 | 说明 |
|---|---|---|
| SCD Type 1 | 直接覆盖 | 不保留历史值 |
| SCD Type 2 | 增加新行 | 保留历史,增加生效/失效时间 |
| 快照维表 | 每日全量快照 | 每天保存一份全量维度数据 |
| 极限存储 | 拉链表 | 记录变更历史,节省存储 |
| 微型维度 | 拆分变化属性 | 将频繁变化的属性拆分到微型维度 |
3.4 事实表设计
事实表特性
- 事实表存储业务过程的度量数据
- 通过外键与维度表关联
- 通常是最细粒度的数据
事实表设计原则
- 尽可能包含所有与业务过程相关的事实
- 只选择与业务过程相关的事实
- 分解不可加性事实为可加的组件
- 事实表粒度要明确且单一
事实表设计方法
第一步:选择业务过程
↓
第二步:确定粒度
↓
第三步:确定维度
↓
第四步:确定事实
↓
第五步:退化维度(物理实现时)
三种事实表对比
| 特性 | 事务事实表 | 周期快照事实表 | 累积快照事实表 |
|---|---|---|---|
| 时间特性 | 离散的业务时间点 | 有规律的、可预测的时间间隔 | 时间跨度不确定的不断变化的工作流 |
| 日期维度 | 业务日期 | 快照日期 | 多个业务过程日期 |
| 每行代表 | 一个事务 | 某时间周期的一个实体 | 一个实体的生命周期 |
| 事实类型 | 事务事实 | 累积事实 | 业务过程事实和时间间隔事实 |
| 加载方式 | 插入 | 插入 | 插入与更新 |
| 更新方式 | 不更新 | 不更新 | 业务过程变更时更新 |
| 典型例子 | 交易订单明细 | 库存日快照 | 交易订单全流程跟踪 |
事务事实表
- 记录事务发生时的状态
- 数据增量加载,不更新历史数据
- 可以是单事务事实表 (一个业务过程一张表)或多事务事实表(多个业务过程一张表)
周期快照事实表
- 以固定时间间隔记录事实
- 适用于记录库存、余额、层级、温度等状态度量
- 典型例子:库存日快照表
累积快照事实表
- 跟踪实体的一系列业务过程进展
- 具有多个日期字段,用于计算业务过程之间的时间间隔
- 数据会被更新
- 物理实现方式:
- 全量表:每天分区存储全量数据(适合数据量小)
- 滑动窗口全量表:保留最近N天全量数据(如最近200天)
- 业务实体结束时间分区:每天分区存放当天结束的数据,大分区存放未结束数据
聚集型事实表(公共汇总层)
基本原则:
- 一致性:聚集表必须提供与明细数据一致的查询结果
- 避免单一表设计:不同层级的聚集数据不要放在同一个表中
- 聚集粒度可不同:只关心需要的查询维度
阿里公共汇总层设计原则:
- 数据公用性:聚集数据有被第三者使用
- 不跨数据域:如交易统一划到交易域下
- 区分统计周期 :
_1d表示最近1天,_td表示截至当天,_nd表示最近N天
聚集的基本步骤:
- 确定聚集维度
- 确定一致性上钻(按月/按天?按商品/按类目?)
- 确定聚集事实(交易额/成交量?)
四、第3篇:数据管理篇
4.1 元数据
元数据定义
元数据(Metadata)是关于数据的数据,打通了源数据、数据仓库、数据应用,记录了数据从产生到消费的全过程。
两类元数据
| 类型 | 说明 | 典型内容 |
|---|---|---|
| 技术元数据 | 数据仓库系统技术细节 | 表结构、分区信息、作业运行信息、任务调度信息、数据质量监控等 |
| 业务元数据 | 从业务角度描述数据 | 维度定义、业务过程定义、指标定义、报表配置等 |
统一元数据体系建设
数据源元数据 → 元仓底层 → 元仓中间层 → 统一元数据服务出口
↓
计算/存储/质量/安全/模型等治理领域
元数据应用
| 应用 | 说明 |
|---|---|
| Data Profile | 为数据"画像",建立数据血缘图谱。四类标签:基础标签、数仓标签、业务标签、潜在标签 |
| 元数据门户 | 一站式数据管理平台。"前台"为数据地图(找数据),"后台"为数据管理(成本/安全/质量管理) |
| 应用链路分析 | 通过血缘链路分析产品依赖的数据,进行影响分析、重要性分析、下线分析、故障排查 |
| 数据建模 | 基于下游使用的元数据指导数据参考建模 |
| 驱动ETL开发 | 通过元数据指导一键同步、数据运维、自动下线等 |
4.2 计算管理
HBO(History-Based Optimizer,基于历史的优化器)
原理:根据任务历史执行情况为任务分配更合理的资源(内存、CPU、Instance个数)
任务执行历史 + 集群状态信息 + 优化规则 → 更优的执行配置
效果:
- CPU利用率从40%提升到80%
- Instance峰值并发数提升57%
- 某集群总执行时长减少4472小时(从8356小时降至3884小时)
CBO(Cost-Based Optimizer,基于代价的优化器)
原理:根据收集的统计信息计算每种执行方式的代价,选择最优执行方式
特点:
- 引入Volcano模型
- 支持Join Reorder(重新排序Join)
- 支持Auto MapJoin(自动MapJoin)
- MaxCompute 2.0离线计算比Hive 2.0 on Tez快90%以上
任务优化 --- 倾斜处理
| 倾斜类型 | 原因 | 解决方案 |
|---|---|---|
| Map倾斜 | 读入文件块数据分布不均匀,加上UDF、Join、聚合等操作 | 使用distribute by rand()打乱数据分布 |
| Join倾斜 | Join Key相同的数据量过大 | MapJoin优化、SkewJoin优化、数据加盐 |
| Reduce倾斜 | Group By Key数据分布不均 | 两阶段聚合、增加并行度 |
4.3 存储和成本管理
数据压缩
- 采用合适的压缩算法减少存储空间
- 在压缩比和读写性能之间取得平衡
数据重分布
- 优化数据在分布式存储中的分布
- 避免数据热点,提高查询性能
存储治理项优化
- 识别冷数据、冗余数据
- 定期清理无用数据
生命周期管理
| 策略 | 说明 |
|---|---|
| 生命周期管理策略 | 根据数据重要性和使用频率定义存储周期 |
| 通用生命周期管理矩阵 | 不同等级数据对应不同的保留策略 |
数据成本计量与计费
- 建立数据使用计费体系
- 推动各业务方合理使用数据资源
- 实现数据成本的精细化管理
4.4 数据质量
数据质量保障原则
- 完整性:数据不缺失
- 准确性:数据正确无误
- 一致性:数据之间无矛盾
- 及时性:数据按时产出
数据质量方法
| 方法 | 说明 |
|---|---|
| 消费场景知晓 | 了解数据的应用场景和重要程度,确定保障等级 |
| 数据加工过程卡点校验 | 在ETL关键环节设置校验规则,阻断问题数据向下游传播 |
| 风险点监控 | 对关键指标设置监控规则,异常时及时告警 |
| 质量衡量 | 建立数据质量评分体系,量化数据质量水平 |
数据质量保障体系
事前:规范定义 → 模型设计评审 → 质量规则配置
事中:ETL卡点校验 → 监控告警 → 异常处理
事后:质量复盘 → 规则优化 → 评分考核
五、第4篇:数据应用篇
5.1 生意参谋
背景概述
生意参谋是阿里巴巴面向商家的对外数据产品,为商家提供全面的经营数据分析能力。
功能架构与技术能力
- 实时数据监控:店铺实时访客、交易情况
- 经营分析:流量分析、交易分析、商品分析、市场分析
- 竞争情报:同行对比、市场趋势
- 数据服务:API接口、数据定制
商家应用实践
- 帮助商家了解店铺经营状况
- 指导商家进行营销决策
- 提升商家运营效率
5.2 对内数据产品平台
定位
服务于阿里巴巴内部员工的数据平台。
产品建设历程
从分散的数据工具到统一的数据平台,逐步整合各类数据能力。
主要产品
| 产品 | 功能 |
|---|---|
| 实时数据监控 | 核心业务指标实时监控 |
| 数据小站 | 自助式的数据网站/产品构建工具 |
| 宏观决策分析平台 | 支撑高层战略决策 |
| 对象分析工具 | 用户/商品等对象的深度分析 |
| 行业数据分析门户 | 行业趋势和竞争分析 |
| 流量分析平台 | 网站/App流量分析 |