读后感

说来惭愧，从业以来，虽然和很多大数据平台打过交道，但接触到的最大的数据，还是广告投放时每天超过百亿的请求。广告场景是非常特殊的，大部分请求是无用的，只有不到 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 隔离
  - 实时数据推送服务
  - 定时任务服务

数据模型

OneData 是阿里巴巴内部进行数据整合及管理的方法体系和工具
体系架构
- 模型设计：
  - 汇总事实表：把明细事实聚合的事实表
  - 明细事实表：最原始粒度的明细数据
  - 维表：把逻辑维度物理化的宽表
- 规范定义
  - 修饰类型 -> 修饰词
  - 业务过程
    - 原子指标
    - 度量
  - 维度 -> 维度属性
  - 派生指标 = 原子指标 + 时间周期 + 修饰词
名词术语
- 数据域：指面向业务分析，将业务过程或者维度进行抽象的集合。数据域需要抽象提炼并且长期维护和更新，但不轻易变动。如：交易域
- 业务过程：指企业的业务活动事件，如下单、支付、退款都是业务过程，是一个不可拆分的行为事件。如：支付
- 时间周期：明确数据统计的时间范围或者时间点。如：最近 1 天
- 修饰类型：对修饰词的抽象划分。如：支付方式
- 修饰词：业务场景限定抽象。如：花呗、信用卡
- 度量/原子指标：指某一业务事件行为下的度量，是业务定义中不可再拆分的指标。如：支付金额
- 维度：是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。如：订单维度、地理维度、时间维度
- 维度属性：维度的具体属性，如：订单 ID、创建时间等
- 派生指标：一个原子指标+多个修饰词（可选）+时间周期。如：最近 1 天通过花呗支付的金额 pay_amt_1d_009
派生指标的种类
- 事务型指标：对业务活动进行衡量的指标。如：新发产品数、新增注册会员数。这类指标需维护原子指标及修饰词，在此基础上创建派生指标
- 存量型指标：对实体对象（如商品、会员）某些状态的统计。如：商品总数、注册会员总数。这类指标需维护原子指标及修饰词，在此基础上创建派生指标
- 复合型指标：在事务型指标和存量型指标的基础上复合而成的。如：浏览 UV - 下单买家数转化率
  - 规则：比率型、比例型、变化量型、变化率型、统计型、排名型、对象集合型
模型设计原则
- 高内聚和低耦合
- 核心模型与扩展模型分离
- 公共处理逻辑下沉及单一
- 成本与性能平衡
- 数据可回滚
- 一致性
- 命名清晰、可理解
事实表设计原则
- 尽可能包含所有与业务过程相关的事实
- 只选择与业务过程相关的事实
- 分解不可加性事实为可加的组件
- 在选择维度和事实之前必须先声明粒度
- 在同一个事实表中不能有多种不同粒度的事实
- 事实的单位要保持一致
- 对事实的 null 值要处理
- 使用退化维度提高事实表的易用性
事实表设计方法
- 选择业务过程及确定事实表类型
- 声明粒度：即精确定义事实表的每一行所表示的业务含义，应尽量选择最细级别的原子粒度
- 确定维度
- 确定事实
- 冗余维度：通常会冗余方便下游用户使用的常用维度，以实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等操作

数据管理

元数据打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程
- 按照用途分为两类：技术元数据、业务元数据
- 元数据门户致力打造一站式的数据管理平台、高效的一体化数据市场
数据质量保障原则
- 完整性
- 准确性
- 一致性
- 及时性

2019 小土刀再启程

【大数据之路】阿里巴巴大数据实践

读后感

读书笔记

总述

数据技术

数据模型

数据管理