0%

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

大数据的真正价值在于生命性和生态性。


更新历史

  • 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 隔离
      • 实时数据推送服务
      • 定时任务服务

数据模型

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

数据管理

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