《大数据之路:阿里巴巴大数据实践》读书笔记

文章目录

《大数据之路:阿里巴巴大数据实践》读书笔记

阿里巴巴大数据系统体系架构

阿里巴巴大数据系统主要分为四大层次

复制代码
┌─────────────────────────────────────┐
│         数据应用层                    │  ← 生意参谋、阿里数据平台等
├─────────────────────────────────────┤
│      数据服务&基础工具层              │  ← OneService
├─────────────────────────────────────┤
│   数据架构&构建方法&工具平台           │  ← OneData体系
│  (MaxCompute / StreamCompute / DataX) │
├─────────────────────────────────────┤
│         数据采集层                    │  ← Aplus.JS / UserTrack / TimeTunnel
└─────────────────────────────────────┘

二、第1篇:数据技术篇

2.1 日志采集

阿里巴巴的日志采集体系包括两大体系:

采集方案 定位 技术要点
Aplus.JS Web端(浏览器)日志采集 页面浏览日志、页面交互日志("黄金令箭")
UserTrack APP端(无线客户端)日志采集 页面事件、控件点击、特殊场景、设备标识
页面浏览日志采集流程
  1. 客户端日志采集:通过植入HTML文档内的JavaScript脚本执行,采集页面参数、浏览行为上下文、运行环境信息
  2. 客户端日志发送:采集脚本向日志服务器发起HTTP请求,日志信息以URL参数形式发送
  3. 服务器端日志收集:日志服务器接收请求后立即响应,将日志内容写入缓冲区(nginx)
  4. 服务器端日志解析存档:专门的日志处理程序解析日志(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以数据仓库整合计算好的数据作为数据源,对外通过接口方式提供三大特色数据服务:

  1. 简单数据查询服务:基础的单表/单维度查询
  2. 复杂数据查询服务:承接集团用户识别、用户画像等复杂查询
  3. 实时数据推送服务:主动推送数据变更
核心组件
组件 功能
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 应用数据层 面向具体应用场景的数据产品
基本原则
  1. 高内聚、低耦合:同一业务过程的数据放在一起
  2. 核心模型与扩展模型分离:核心模型稳定,扩展模型灵活
  3. 公共处理逻辑下沉:公共计算下沉到公共层
  4. 成本与性能平衡:不追求极致规范化,考虑计算和存储成本
  5. 数据可回滚:支持数据回溯和重跑
OneData实施过程

相比业界常用的模型实施过程,OneData强调:

  • 从业务需求出发,但不被短期需求绑架
  • 充分进行数据域和业务过程的分析
  • 规范定义先行,模型设计跟进
  • 持续迭代优化

3.3 维度设计

维度的基本概念

维度是描述事实的角度,如时间、地域、商品、买家、卖家等。

维度的基本设计方法
  1. 选择维度(或新建维度)
  2. 确定主维表和相关维表
  3. 确定维度属性
  4. 设计维度层次
维度的层次结构

维度属性之间存在层次关系,如:

  • 地域:国家 → 省份 → 城市 → 区县
  • 类目:一级类目 → 二级类目 → 三级类目 → 叶子类目
  • 时间:年 → 季度 → 月 → 日 → 小时
规范化 vs 反规范化
方式 说明 适用场景
规范化 维度属性拆分到多个子维表 节省存储,但关联多
反规范化 维度属性合并到一张维表 查询快,存储冗余

在阿里巴巴实践中,更多地采用反规范化设计,因为:

  • 存储成本相对计算成本更低
  • 减少关联操作,提高查询效率
  • 分布式系统中Join成本很高
一致性维度与交叉探查
  • 一致性维度:不同业务过程共用同一套维度定义
  • 交叉探查:基于一致性维度,可以进行跨业务域的分析
维度设计高级主题
主题 说明
维度整合 将不同来源的同类维度整合为统一维度
水平拆分 按维度属性或业务类型拆分维度表
垂直拆分 将不常用属性拆分到扩展表
历史归档 将历史维度数据归档处理
缓慢变化维(SCD)

维度属性会随时间变化,常见处理方式:

类型 方式 说明
SCD Type 1 直接覆盖 不保留历史值
SCD Type 2 增加新行 保留历史,增加生效/失效时间
快照维表 每日全量快照 每天保存一份全量维度数据
极限存储 拉链表 记录变更历史,节省存储
微型维度 拆分变化属性 将频繁变化的属性拆分到微型维度

3.4 事实表设计

事实表特性
  • 事实表存储业务过程的度量数据
  • 通过外键与维度表关联
  • 通常是最细粒度的数据
事实表设计原则
  1. 尽可能包含所有与业务过程相关的事实
  2. 只选择与业务过程相关的事实
  3. 分解不可加性事实为可加的组件
  4. 事实表粒度要明确且单一
事实表设计方法
复制代码
第一步:选择业务过程
    ↓
第二步:确定粒度
    ↓
第三步:确定维度
    ↓
第四步:确定事实
    ↓
第五步:退化维度(物理实现时)
三种事实表对比
特性 事务事实表 周期快照事实表 累积快照事实表
时间特性 离散的业务时间点 有规律的、可预测的时间间隔 时间跨度不确定的不断变化的工作流
日期维度 业务日期 快照日期 多个业务过程日期
每行代表 一个事务 某时间周期的一个实体 一个实体的生命周期
事实类型 事务事实 累积事实 业务过程事实和时间间隔事实
加载方式 插入 插入 插入与更新
更新方式 不更新 不更新 业务过程变更时更新
典型例子 交易订单明细 库存日快照 交易订单全流程跟踪
事务事实表
  • 记录事务发生时的状态
  • 数据增量加载,不更新历史数据
  • 可以是单事务事实表 (一个业务过程一张表)或多事务事实表(多个业务过程一张表)
周期快照事实表
  • 以固定时间间隔记录事实
  • 适用于记录库存、余额、层级、温度等状态度量
  • 典型例子:库存日快照表
累积快照事实表
  • 跟踪实体的一系列业务过程进展
  • 具有多个日期字段,用于计算业务过程之间的时间间隔
  • 数据会被更新
  • 物理实现方式:
    1. 全量表:每天分区存储全量数据(适合数据量小)
    2. 滑动窗口全量表:保留最近N天全量数据(如最近200天)
    3. 业务实体结束时间分区:每天分区存放当天结束的数据,大分区存放未结束数据
聚集型事实表(公共汇总层)

基本原则

  • 一致性:聚集表必须提供与明细数据一致的查询结果
  • 避免单一表设计:不同层级的聚集数据不要放在同一个表中
  • 聚集粒度可不同:只关心需要的查询维度

阿里公共汇总层设计原则

  • 数据公用性:聚集数据有被第三者使用
  • 不跨数据域:如交易统一划到交易域下
  • 区分统计周期_1d表示最近1天,_td表示截至当天,_nd表示最近N天

聚集的基本步骤

  1. 确定聚集维度
  2. 确定一致性上钻(按月/按天?按商品/按类目?)
  3. 确定聚集事实(交易额/成交量?)

四、第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 数据质量

数据质量保障原则
  1. 完整性:数据不缺失
  2. 准确性:数据正确无误
  3. 一致性:数据之间无矛盾
  4. 及时性:数据按时产出
数据质量方法
方法 说明
消费场景知晓 了解数据的应用场景和重要程度,确定保障等级
数据加工过程卡点校验 在ETL关键环节设置校验规则,阻断问题数据向下游传播
风险点监控 对关键指标设置监控规则,异常时及时告警
质量衡量 建立数据质量评分体系,量化数据质量水平
数据质量保障体系
复制代码
事前:规范定义 → 模型设计评审 → 质量规则配置
事中:ETL卡点校验 → 监控告警 → 异常处理
事后:质量复盘 → 规则优化 → 评分考核

五、第4篇:数据应用篇

5.1 生意参谋

背景概述

生意参谋是阿里巴巴面向商家的对外数据产品,为商家提供全面的经营数据分析能力。

功能架构与技术能力
  • 实时数据监控:店铺实时访客、交易情况
  • 经营分析:流量分析、交易分析、商品分析、市场分析
  • 竞争情报:同行对比、市场趋势
  • 数据服务:API接口、数据定制
商家应用实践
  • 帮助商家了解店铺经营状况
  • 指导商家进行营销决策
  • 提升商家运营效率

5.2 对内数据产品平台

定位

服务于阿里巴巴内部员工的数据平台。

产品建设历程

从分散的数据工具到统一的数据平台,逐步整合各类数据能力。

主要产品
产品 功能
实时数据监控 核心业务指标实时监控
数据小站 自助式的数据网站/产品构建工具
宏观决策分析平台 支撑高层战略决策
对象分析工具 用户/商品等对象的深度分析
行业数据分析门户 行业趋势和竞争分析
流量分析平台 网站/App流量分析