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

此书下载传送门http://www.java1234.com/a/javabook/yun/2018/0308/10578.html

第1章 总述

阿里巴巴大数据系统体系主要分为，数据采集、数据计算、数据服务和数据应用四大层次。

数据采集工具：web端、App端、H5
数据计算层：数据存储、云计算平台（离线计算平台、实时计算平台、数据整合管理体系ONE DATA）
数据服务层：以数据仓库整合计算好的数据作为数据源，对外通过接口的方式提供数据服务，主要提供简单数据查询服务，复杂数据查询服务和实时数据推送服务三大特色数据服务。
数据应用：如搜索、推荐、广告……

第2章 日志采集

浏览器的页面日志采集

• 分为两大类：
  页面浏览，日志采集。页面浏览量（page view, PV）和访客数（unique visitors, UV）
  • 页面浏览日志采集流程。
    1）客户端日志采集，在HTML文档内植入日志采集脚本的动作可以由业务服务器在响应业务请求时动态直线，也可以在开发页面时有开发人员手动植入。
    2）客户端日志发送。采集脚本执行时，会向日志嗯，服务器发起一个日志请求，以将采集到的数据发送到日志服务器。
    3）服务器端日志收集。
    4）服务端日志解析归档。
  • 页面交互日志采集。
    需要了解用户在访问某个页面时，具体的互动行为特征，比如鼠标或输入焦点的移动变化。

APP

• 在客户端对这类日志进行适当聚合，以减少对日志采集服务器端的请求，适当减小日志大小。
• 在进行业务分析时，回退同样作为特殊场景而存在。

H5

• 执行时通过加的日志采集javascript脚本采集当前页面参数，包括浏览行为的上下文信息，以及一些运行环境信息。
• 在浏览器日志采集的javascript 脚本中实现将所采集的数据打包到一个对象中。

设备标识

• 历史上, MEI IMSI MAC 苹果禁用前的UDID, 曾经都可以用，如果一个是靠谱的话，那么设备唯一标识就简单了。这些目前设备上都对其进行了设备控制，所以都不可靠。阿里使用自研的UTDID, 应该是不同的设备场景下采用不同的策略，包裹没有权限时的处理，区分同一个设备

日志传输

• 客户端数据上传时是向服务器发送POST请求，服务器端处理上传请求，对请求进行shudsucw,uqf数据追加到本地进行存储，存储方式使用Nginx的access_log， access_log的切分天，即当天日志当天的日志文件中。

• 对于一些技术日志可以使用采样的方式，如页面加载情况、消耗内存等

第3单 数据同步

数据同步基础

• 直连同步：比如说JDBC接口抽数据
• 数据库文件同步：源数据库导出文件，通过FTP或类似方式传输到目标系统加载
• 数据库日志解析同步：例如mysql binlog
  • 针对删除这种变更，主要有三种方式
  1. 不过滤删除流水，下游逻辑删除
  2. 过滤最后一条删除流水，比如存在手工批量删除或者备份删除，则数据还是有效的不应当置为无效
  3. 过滤删除流水和之前的流水

阿里数据仓库的同步方式

批量 文件导出，实时查询
实时 binlog解析通过my kafka传输

• 数据漂移的处理，多获取一部分第二天的数据（比如跨日以后的15分钟），然后根据可以判断业务时间的字段，过滤，排序等方式来得到需要的数据

第4章 离线数据开发

数据仓库的清洗采用非侵入式的清洗策略，在数据同步过程中不进行数据清洗，避免影响数据同步的效率。数据进入ODS层后，开始清洗，符合清洗数据清洗掉，并保存到DIRTY表

任务调度系统

数据仓库系统使用crontab定时任务功能进行任务调度处理，缺点：

• 任务之间基于执行时间实现调度，容易造成前面的任务未结束或失败而后面的任务已经运行。
• 任务难以并发执行，增加了整体的处理时间
• 无法设置任务优先级
• 任务的管理维护很不方便，无法进行执行效果分析等

分为调度引擎（phoenix Engine）和执行引擎（Alisa）两个子系统。

• 调度配置：常用的调度配置方式是对具体任务手工依赖的上游任务，阿里的方式是任务提交时，SQL解析引擎自动识别此任务的输入表和输出表，输入表自动关联产出些表的任务。
• 定时调度：可以根据实际需求，设定任务的运行时间，5种时间类型：分钏、小时、日、周、月，具体可以精确到秒。
• 周期调度：无须指定具体的开始运行时间
• 手动运行
• 补数据
• 基线管理：基于充分利用计算资源，保证重点业务数据优先产出，合理安排各类优先级任务的运行，调度系统引入了按优先级分类方法。优先级分类1~9，数字越大代表优先级越高，系统会先保障高优先级任务的运行资源。
• 监控报警; 任务系统做到大都要有这一步

第5章 实时技术

数据时效性一般分为三种：

• 离线：在今天（T）处理N天前（T-N, N>=1）的数据，延迟时间粒度为天
• 准实时：在当前小时（H）处理N小时前（H-N,N>0,如0.5小时）的数据，延迟粒度为小时。
• 实时：在当前时刻处理当前的数据，延迟时间粒度为秒。

实时数据则需要在流式处理系统中完成。简单来说，流失处理技术是指业务系统每产生一条数据，就立即被采集并实时发送到流式任务中进行处理，不需要定时调度任务来处理数据。由于数据源是流式的，在数据具有上下文关系的情况下，数据到达时间的不确定性会导致实时处理的结果与离线处理会有一定的差异。

流式技术架构

• 数据采集，从所采集的数据种类来看，主要划分为两种：
  • 数据库变更日志，
  • 引擎访问日志。

一般情况下，出于吞吐量及系统压力上的考虑。并不是新增一条记录就采集一次。而是基于数据大小限制，或者时间阈值限制，按批次对数据进行采集。对于采集到的数据，需要一个数据交换平台分发给下游, 比如kafka.
消息系统一般会用做业务数据库变更的消息中转，比如订单下单，支付等消息，对于其他较大的业务数据，一般会通过数据中间件系统买中转.虽然它的延迟在秒级，但是其支持的吞吐量高。

• 数据处理
  Strom、S4、Spark

  • 去重指标
    精确去重，在这种情况下，明细数据是必须要保存下来的，当遇到内存问题时，可以通过数据倾斜来处理，把一个节点的内存压力分到多个节点上。
    模糊去重，再去重大的明细，数据量非常大，而业务的精度要求不高的情况下，可以使用相关的去重算法。把内存的使用量降到1‰甚至万分之一。如布隆过滤器、基数估计。
  • 数据倾斜
  • 事务处理

• 数据存储

  • 中间计算结果，比如去重指标的明细数据
  • 最终结果数据
  • 维表数据

• 流式数据模型

  • ODS 操作数据层
  • DWD 实时事实明细层
  • DWS 通用维度汇总层
  • ADS 应用数据层
  • DIM 实时维表层

• 多流关联
  在流式计算中常常需要把两个实时流进行主键关联，以得到对应的实时明细表。实时数据的到达是一个增量的过程，并且数据到达的时间是不确定和无序的，因此在数据处理过程中会涉及中间状态的保存和恢复机制等细节问题。

  实时采集两张表的数据，每到来一条新数据是都在内存中的对方表截止当前的全量数据中查找，如果能查找到，则说明关联成功，直接输出，如果没查找到，则这把数据放在内存中的自己表数据集合中等待。另外，不管是否关联成功，内存中的数据都需要备份到外部存储系统中，在任务重启时，可以从外部存储系统中恢复内存数据。

  在实际处理时考虑到查找数据的性能，实时关联这个步骤一般会把数据按照关联主键进行分桶处理，并且在故障恢复时也根据分桶来进行，以降低查找数据量和提高吞吐量。

第6章 数据服务

dws 使用逻辑宽表做为防腐层
数据部门字段的变更相对于比较频繁，这种底层变更对应用层来说应该算是最糟糕的变更之一了，而逻辑表层的设计，很好的规避了这个痛点，只变更逻辑表中物理字段的映射关系，并且即刻生效，对调用方来说完全无感知。

逻辑表可以理解为数据库中的视图是一张虚拟表，也可以看作是由若干主键相同的物理表构成的大宽表。

日期为今天是展现的是实时数据，日期为昨天事展现的就是离线数据，其背后的复杂性在于。

• 在数据公共层中，实时数据是在流计算平台Galaxy上进行计算的，结果保存在HBase中；而离线数据的计算和存储都是在MaxCompute中进行的。这就造成了实时数据与离线数据存储在
  两个数据源中，调用者的查询方式完全不同。
• 离线数据的产出时间，取决于上游任务的执行时间，以及当前平台的资源情况。所以其产出时间是无法估算的，有可能3：00产出，也有可能延迟到6：00。在昨天的离线任务产出之前，其前台展现的数字只能来源于实时数据。
• 出于对性能和成本的考虑，定时作业做了一些折中，去重时，视树情况可能使用一些不精准的去重算法，这就导致实时数据的计算到综上所述，离线数据最准确，需要优先使用离线数据。如果离线数据还未产出则改用实时数据

第7章 数据挖掘

第8章 大数据领域建模综述

Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系。

• ER模型
• 维度模型
• Data Vault 模型
• Anchor 模型

第9章 阿里巴巴数据整合及管理体系

DDD

第10章 维度设计

维度设计基础

选择维度或者新建维度，以淘宝商品维度为例，有且只允许有一个维度定义。

• 确定主维表

• 确定相关维表

• 确定维度属性

  • 尽可能生成丰富的维度属性
  • 尽可能多地给出包括一些富有意义的文字性描述
  • 区分数据型属性和事实
  • 尽量常常出通用的维度属性

• 维度的层次结构
  维度中的一些精连属性以层次方式成一对多的方式相互差联。比如陶宝商品维度，有卖家、类目、品牌制商品属于类目，类目属于行业，其中类目的最低级别是叶子类目，叶子类目属于二级类目，二级类目属子一级类目。

• 一致性维度和交叉探查
  数据仓库总线架构的重要基石之一就是一致性维度。在针对不同数据域进行迭代构建或并行构建时，存在很多需求是对于不同数据域的业务过程或者同一数据域的不同业务过程合并在一起观察。比如对于日志数据域，统计了商品维度的最近一天的PV和UV；对于交易数据域，统计了商品维度的最近一天的下单GMV。现在将不同数据域的商品的事实合并在一起进行数据探查，如计算转化率等，称为交又探查。

维度设计高级主题

• 水平拆分
  主要有两种解决方案：方案1是将维变的不同分类实例化为不同的维度，同时在主维度中保存公共属性：方案2是维护单一维度，包含所有可能的属性。出于扩展性、产出时间、马用性等方面
• 垂直拆分
  出于扩展性、产出时间、易用性等方面的考虑，设计主从维度。主维表存放稳定、产出时间早、热度高的属性，从维表存放变化较快、产出时间晚、热度低的属性。比如在阿里巴巴数据仓库中，设计了商品主维度和商品扩展维度。其中商品主维度在每口的l：30左右产出，而商品扩展维度在3：00左右产出。

维度变化

• 缓慢变化维
  重写维度值
  插入新的维度行
  添加维度列
• 快照维表
• 极限存储
  stat_dt<=20160101 and end_dt>2-160101 用于理解大数据平台的sql. 极限存储并不存储每天的快照。如果数据没有发生变化，就不存储。
  底层的数据还是历史拉链存储，但是上层做一个视图操作或者在Hive 里做一个hook，通过分析语句的语法树，把对极限存储前的表的查询转换成对极限存储表的查询。对于下游用户来说，极限存储表和全量存储方式是一样的：
  Select ·from A where ds =20160101
  等价于
  Select *from A EXST where start_dt <=20160101 and end_dt>20160101；

特殊维度

• 递归层次
  本节的递归层次指的是某维度的实例值的层次关系，比如淘宝类目体系。
  维度的递归层次，按照层级是否固定分为均衡层次结构和非均衡层次结构对于数量级别不固定的递归层次，称为“非均衡层次结构”。
  用户使用递归SQL的成本较高，所以在维度模型中，需要对此层次结构进行处理。

  • 层次结构扁平化，宽表，每个级别作为一个字段属性
  • 层次桥接表，也就是关联表。这个可能是作者自己的想法，实际不太可能落实。

• 行为维度
  在阿里巴巴的数据仓库中，存在很多维表，如卖家主营类目维度卖家主营品牌维度、用户常用地址维度等。其中卖家主营类目和主营牌通过卖家的商品分布和交易分布情况，采用算法计算得到：去家常月地址通过最近一段时间内物流中卖家的发货地址和买家的收货地址
  行统计得到。类似的维度，都和事实相关，如交易、物流等，称之为
  按照加工方式，行为维度可以划分为以下几种：

  • 另一个维度的过去行为，如买家最近一次访问淘宝的时间、买家最近一次发生淘宝交易的时间等。
  • ·快照事实行为维度，如买家从年初截至当前的淘宝交易金额、买家信用分值、卖家信用分值等。
  • 分组事实行为维度，将数值型事实转换为枚举值。如买家从年初截至当前的淘宝交易金额按照金额划分的等级、买家信用分值按照分数划分得到的信用等级等。
  • 复杂逻辑事实行为维度，通过复杂算法加工或多个事实综合加得到。如前面提到的卖家主营类目，商品热度根据访问、收藏、加入购物车、交易等情况综合计算得到。

• 多值维度
  对于多值维度，一种情况是事实表的一条记录在某维表中有多条记录与之对应。比如对于淘宝交易订单，买家一次购买了多种商品，如一件毛衣和两双袜子，称为交易父订单；对于每种商品的交易，称为交易子订单：此交易父订单有两个子订单与之对应。假设设计交易父订单事实表，则对于此事实表的每一条记录，在商品表中都有一到多条记录与之对应。

• 多值属性
  维表中的某个属性字段同时有多个值，称之为“多值属性”。它是多值维度的另一种表现形式。在阿里巴巴的数据仓库中，存在很多维表，如商品SKU维表、商品属性维表、商品标签维表等。每个商品均有一到多个SKU、一到多个属性和一到多个标签，所以商品和SKU、属性、标制
  签都是多对多的关系。

  对于多值属性，常见的处理方式有三种，可以根据具体情况进行选择。
  第一种处理方式是保持维度主键不变，将多值属性放在维度的一个属性字段中。json 格式
  第二种处理方式也是保持维度主键不变，但将多值属性放在维度的多个属性字体中，扩展性较差
  第三种处理方式是维度主键发生变化，一个维度值存放多条记录。数据膨胀严重

第11章 事实表设计

事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度：一种是所表示的具体业务含义。

事实表有三种类型：事务事实表、周期快照事实表和累积快照事实表，具体内容后面章节会详细介绍。事务事实表用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据.周期快照事实表以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，比如交易开始、交易结束。

事务事实表

在淘宝交易过程中有四个重要业务过程，需要为每个业务过程确定一个粒度。其中下单、支付和成功完结三个业务过程选择交易子订单程度，即每个子订单为事务事实表的一行，每个子订
单所表达的细节信息为：交易时间、卖家、买家、商品。

• 单事务事实表 多表
• 多事务事实表 单表

周期快照事实表

解决使用事实表在大时间跨度下，效率变低的问题。
快照事实表中收集到的状态量都是半可加的。比如淘宝交易卖家快照事实表，每天的历史至今的下单金额进行汇总，也没有汇总意义。

累积快照事实表

用于考察实体的唯一实例，所以子订单在此表中只有一行记录，事件发生时，对此实例进行更新。

无事实的事实表

日志

聚集型事实表

第12章 元数据

第13章 计算管理

系统优化

HBO
HBO分配资源的步骤如下：

• 前提：最近7天内任务代码没有发生变更且任务运行4次。
• Instance分配逻辑：基础资源估算值+加权资源估算值

CBO
Volcano模型，不明白

任务优化

• Map倾斜
  在Map端读数据时，由于读人数据的文件大小分布不均匀，因此会导致有些Map Instance读取并且处理的数据特别多，而有些Map Instance处理的数据特别少，造成Map端长尾。以下两种情况可能会导别致Map端长尾：

  • 上游表文件的大小特别不均匀，并且小文件特别多，导致当前表Map端读取的数据分布不均匀，引起长尾。
  • Map端做聚合时，由于某些Map Instance读取文件的某个值特别多而引起长尾，主要是指Count Distinct操作。

• JOIN 倾斜
  MaxCompute SQL在Join执行阶段会将Join Key相同的数据分发到同一个执行Instance上处理。如果某个Key上的数据量比较大，则会导致该Instance执行时间较长。其表现为在执行日志中该Join Task的大部分Instance都已执行完成，但少数几个Instance一直处于执行中(这种现象称之为长尾)。
  因为数据倾斜导致长尾的现象比较普遍，严重影响任务的执行时间，尤其是在“双11”等大型活动期间，长尾程度比平时更严重。比如某些大型店铺的PV远远超过一般店铺的PV，当用浏览日志数据利用卖家维表关联时，会按照卖家ID进行分发，导致某些大卖家所在Instance处理的数据量远远超过其他Instance，而整个任务会因为这个长尾的Instance迟迟无法结束。

• Reduce 倾斜
  Reduce端产生长尾的主要原因就是key的数据分布不均匀。比如有些Reauce 在务instance理的数据记录多，有些处理的数据记录少，造成Reduce端长尾。如下几种情况会造成Reduce端长尾:

  • 对同一个表按照维度对不同的列进行Count Distinct操作，造成Map端数据膨胀，从而使得下游的Join和Reduce出现链路上的长尾。
  • Map端直接做聚合时出现key值分布不均匀，造成Reduce端长尾。
  • 动态分区数过多时可能造成小文件过多，从而引起Reduce端长尾。
  • 多个Distinct同时出现在一段SQL代码中时，数据会被分发多次，不仅会造成数据膨胀N倍、还会把长尾现象放大N倍。

第14章 存储和成本管理

目前已有的存储治理优化项有未管理表、空表最近62天未访问表，近据无更新无任务表、数据无更新有任务表、开发库数据大于100GB且无访问表、长周期表等。

MaxCompute中的任何一个计算任务都会涉及计算和存储资源的消耗，其中计算资源的消耗主要考虑CPU消耗。为了下面更好地描述数据计量计费的算法和规则，特做如下定义：CPU消耗的单位定义为CU，代表CPU的一个核心（Core)运行一天的消耗量。存储资源的消耗主要考虑磁盘存储的消耗，这里采用国际通用的存储单位PB来衡量.例如：计算资源的单价为1元/CU，存储资源的单价为1元/P8天。
对数据成本的计量，可以采用最简单的方式，将一个数据表的成本分为存储成本和计算成本。存储成本是为了计量数据表消耗的存储资源，计算成本是为了计量数据计算过程中的CPU消耗。但是，对这样的数据成本计量方式会存在较大的质疑和挑战。例如，如图14.4所示，表D是业务方的一个数据表，表D依赖表C，但是为了产生表C，往往上面存在一个较长的数据剧新链路。表C的成本可能是10元，但是表A、B可能会是l00元。像这样的情况，如果表C的成本仅仅用数据表C自身的存储和计算成本衡量显然是不合理、不准确的。

B

A

C

D

第15章 数据质量

在线业务复杂多变，总是在不断地变更，每一次变更都会带来数据的变化，数据仓库需要适应这多变的业务发展，工具和人员双管齐下。既要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知。

发布平台集成了通知功能，针对重要的场景发布会进行卡点，确认通知后才能完成发布。其次是数据库表的变化感知，无论是随着业务发展而做的数据库扩存还其表的DDL变化，都需要主动通知到离线开发人员。是可以的，灵活性比较大。

另外，摩萨德提供了甘特图的服务，针对业务的运行情况，摩萨德会提供一条关键路径，即完成业务的最慢任务链路图。因为每个业务上游可能有成千上万个任务，所以这条关键路径对于业务链路优化来说非常重要。

• 质量衡量
  • 数据质量起夜率
  • 数据质量事件
• 数据质量故障体系
  • 故障定义
  • 故障等级
  • 故障处理
  • 故障review
    对故障责任的判定，不是为了惩罚个人，而是通过对故障的复盘形成解决方案，避免问题再次发生！