大数据的真正价值在于生命性和生态性。
更新历史
- 2022.03.18:完成初稿
读后感
说来惭愧,从业以来,虽然和很多大数据平台打过交道,但接触到的最大的数据,还是广告投放时每天超过百亿的请求。广告场景是非常特殊的,大部分请求是无用的,只有不到 1% 的数据需要进一步加工。可以想象,面对双十一等大促活动,阿里要面对的问题和挑战要大的多,这也是这本书的价值。如果能从中学到一点核心思想并应用在自己的工作中,就再好不过了。
读书笔记
总述
阿里巴巴大数据系统体系架构
- 数据采集层
- 数据库
- 数据库同步工具(离线)
- 日志采集技术 -> 日志文件 -> 消息中间件(离线/实时)
- 数据计算层
- 实时计算
- 离线计算
- 数据架构&构建方法&工具平台
- 数据管理
- OneData 数据建设体系
- 数据开发平台
- DIM 实时维表
- ADS 应用数据
- DWS 公共汇总
- DWD 公共明细
- ODS 操作数据
- 数据服务层
- 服务&工具层数据源
- 数据服务&基础工具层 OneService
- 数据应用层
- 对内
- 对平台
- 对商家
- 对公众
数据技术
- 一套标准的数据采集体系方案
- 日志采集的挑战
- 典型场景
- 日志分流与定制处理:有些分类直接在客户端进行
- 采集与计算一体化设计:规范制定 - 元数据注册 - 日志采集 - 自动化计算 - 可视化展现
- 大促保障
- 服务器推送配置到客户端
- 对日志做分流
- 非重要日志进行适当限流,错峰后逐步恢复
- 典型场景
- 数据同步三种方式:直连同步、数据文件同步、数据库日志解析同步
- 表名设计:汇总层标识 + 数据域 + 主维度 + 时间维度
- rowkey 设计:MD5 + 主维度 + 维度标识 + 子维度 1 + 时间维度 + 子维度 2
- 数据分层
- ODS 操作数据层,直接从业务系统采集过来的最原始数据,包含了所有业务的变更过程,数据粒度也是最细的。在这一层,实时和离线在源头上是统一的,这样的好处是用同一份数据加工出来的指标,口径基本是统一的
- DWD 事实明细层,在 ODS 基础上,根据业务过程建模出来的。对于访问日志这种数据(没有上下文关系,并且不需要等待过程的记录),会回流到离线系统供下游使用,最大程度地保证实时和离线数据在 ODS 层和 DWD 层是一致的
- DWS 通用汇总层,计算各个维度的汇总指标
- ADS 个性化维度汇总层,存放不是特别通用的统计维度数据,常用于一些垂直创新业务中
- DIM 实时维表层,从离线维表层倒出来的,抽取到在线系统中供实时应用调用
- 分层数据举例说明:
- ODS:订单粒度的变更过称,一笔订单有多条记录
- DWD:订单粒度的支付记录,一笔订单只有一条记录
- DWS:卖家的实时成交金额,一个卖家只有一条记录,并且指标在实时刷新
- ADS:外卖地区的实时成交金额,只有外卖业务使用
- DIM:订单商品类目和行业的对应关系维表
- 大促挑战&保障(实时技术)
- 大促特征:毫秒级延时、洪峰明显、高保障性
- 实时任务优化
- 独占资源和共享资源的策略:如果一个任务在运行时 80% 以上的时间都需要去抢资源,就需要考虑分配独占资源
- 合理选择缓存机制,尽量降低读写库次数
- 计算单元合并,降低拓扑层级
- 内存对象共享,避免字符拷贝
- 在高吞吐量和低延时间取平衡
- 数据服务架构演进
- DWSOA:将业务方对数据的需求通过 SOA 服务的方式暴露出去。由需求驱动,一个需求开发一个或者几个接口,编写接口文档,开放给业务方调用
- 接口粒度比较粗,灵活性不高,扩展性差,复用率低,开发效率不高
- 接口数量 5000/年
- OpenAPI:将数据按照其统计粒度进行聚合,同样维度的数据,形成一张逻辑表,采用同样的接口描述,可以有效收敛接口数量
- 带来大量对象关系映射的维护工作量
- 接口数量 200/年
- SmartDQ:在 OpenAPI 的基础上再抽象一层,用 DSL 来描述取数需求,采用 SQL 标准语法。至此,所有的简单查询服务减少到只有一个接口,大大降低了数据服务的维护成本
- 接口易上难下,即使一个接口也会绑定一批人,所以对外提供的数据服务接口一定要尽可能抽象,接口的数量要尽可能收敛
- OneService:覆盖剩余场景
- 个性化取数业务场景:一类需求开发一个插件,不同插件通过 Docker 隔离
- 实时数据推送服务
- 定时任务服务
- DWSOA:将业务方对数据的需求通过 SOA 服务的方式暴露出去。由需求驱动,一个需求开发一个或者几个接口,编写接口文档,开放给业务方调用
数据模型
- OneData 是阿里巴巴内部进行数据整合及管理的方法体系和工具
- 体系架构
- 模型设计:
- 汇总事实表:把明细事实聚合的事实表
- 明细事实表:最原始粒度的明细数据
- 维表:把逻辑维度物理化的宽表
- 规范定义
- 修饰类型 -> 修饰词
- 业务过程
- 原子指标
- 度量
- 维度 -> 维度属性
- 派生指标 = 原子指标 + 时间周期 + 修饰词
- 模型设计:
- 名词术语
- 数据域:指面向业务分析,将业务过程或者维度进行抽象的集合。数据域需要抽象提炼并且长期维护和更新,但不轻易变动。如:交易域
- 业务过程:指企业的业务活动事件,如下单、支付、退款都是业务过程,是一个不可拆分的行为事件。如:支付
- 时间周期:明确数据统计的时间范围或者时间点。如:最近 1 天
- 修饰类型:对修饰词的抽象划分。如:支付方式
- 修饰词:业务场景限定抽象。如:花呗、信用卡
- 度量/原子指标:指某一业务事件行为下的度量,是业务定义中不可再拆分的指标。如:支付金额
- 维度:是度量的环境,用来反映业务的一类属性,这类属性的集合构成一个维度,也可以称为实体对象。如:订单维度、地理维度、时间维度
- 维度属性:维度的具体属性,如:订单 ID、创建时间等
- 派生指标:一个原子指标+多个修饰词(可选)+时间周期。如:最近 1 天通过花呗支付的金额
pay_amt_1d_009
- 派生指标的种类
- 事务型指标:对业务活动进行衡量的指标。如:新发产品数、新增注册会员数。这类指标需维护原子指标及修饰词,在此基础上创建派生指标
- 存量型指标:对实体对象(如商品、会员)某些状态的统计。如:商品总数、注册会员总数。这类指标需维护原子指标及修饰词,在此基础上创建派生指标
- 复合型指标:在事务型指标和存量型指标的基础上复合而成的。如:浏览 UV - 下单买家数转化率
- 规则:比率型、比例型、变化量型、变化率型、统计型、排名型、对象集合型
- 模型设计原则
- 高内聚和低耦合
- 核心模型与扩展模型分离
- 公共处理逻辑下沉及单一
- 成本与性能平衡
- 数据可回滚
- 一致性
- 命名清晰、可理解
- 事实表设计原则
- 尽可能包含所有与业务过程相关的事实
- 只选择与业务过程相关的事实
- 分解不可加性事实为可加的组件
- 在选择维度和事实之前必须先声明粒度
- 在同一个事实表中不能有多种不同粒度的事实
- 事实的单位要保持一致
- 对事实的 null 值要处理
- 使用退化维度提高事实表的易用性
- 事实表设计方法
- 选择业务过程及确定事实表类型
- 声明粒度:即精确定义事实表的每一行所表示的业务含义,应尽量选择最细级别的原子粒度
- 确定维度
- 确定事实
- 冗余维度:通常会冗余方便下游用户使用的常用维度,以实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等操作
数据管理
- 元数据打通了源数据、数据仓库、数据应用,记录了数据从产生到消费的全过程
- 按照用途分为两类:技术元数据、业务元数据
- 元数据门户致力打造一站式的数据管理平台、高效的一体化数据市场
- 数据质量保障原则
- 完整性
- 准确性
- 一致性
- 及时性