大数据之路 阿里巴巴大数据实践 读书笔记
一 、总述
人类正在从IT时代走向DT时代。现在的数据呈爆炸式增长，其潜在的巨大价值有待发掘。但是如果不对数据进行有序、有结构的分类组织和存储，它将变成一场灾难。
在阿里内部，数据的存储达到EB级别。这些给数据采集、存储、计算都带来了极大的挑战。随着数阿里内部数据量的剧增，以及日益丰富的业态，这些都给大数据系统的构建提供了更复杂的要求。
本书介绍的阿里巴巴大数据系统架构，就是为了满足不断变化的业务需求，同时实现系统的高度扩展性、灵活性以及数据展现的高性能而设计的。
其系统机构大致包含六层。
数据采集层
阿里巴巴建立了一套标准的数据采集体系方案，致力于全面，高性能，规范的完成海量数据的采集，并将其传输到大数据平台。
其日志采集体系方案主要包括量大体系：
- Aplus.JS 是Web端日志采集技术方案
- UserTrack 是APP端日志采集技术方案。
数据计算层
从采集系统收集带大量原始数据，进入数据计算层中被进一步整合和计算。
阿里巴巴的数据计算层包含两大体系：
- 数据存储及计算云平台
- 数据整合及管理体系
数据服务层
数据被整合计算好后，需要提供给产品和应用进行数据消费。数据服务层对外提供数据服务主要是通过统一的数据服务平台（OneService）。OneService以数据仓库整合计算好的数据作为数据源，对外通过接口的方式提供数据服务。
数据应用层
阿里对数据的应用表现在各个方面，如搜索、推荐、广告等。商家、阿里内部 的搜索、推荐、广告、金融等平台，阿里内部的运营和管理人员都是数据应用方。
二、日志采集
浏览器的页面日志采集
浏览器的页面日志采集可以分为两大类：
- 页面浏览（展现日志采集）。
指当一个页面诶浏览器价值呈现时采集的日志。
目前阿里巴巴采用的页面浏览日志采集方案的大体流程如下：
- 客户端采集日志。由一小段被植入页面HTML文档的JavaScript脚本执行。
- 客户端发送日志。采集脚本执行时，会向日志服务器发起一个日志请求，将采集 到的数据发送到日志服务器。
- 服务器端日志收集。服务器收到日志后向浏览器回应请求成功响应。并将日志请求内容写入日志缓冲区。
- 服务器端日志解析存档。
- 页面交互日志采集
用于了解用户在访问某个页面时具体的互动特征。在阿里巴巴，通过一套名为“黄金令箭”的采集方案来解决交互日志的采集问题。
- 业务方在元数据管理界面注册需求，系统生成日志采集模板代码。
- 业务方将交互日志采集代码植入目标页面
- 用户在页面互动时，采集代码被触发
- 代码触发后发送日志请求。
无线客户端的日志采集
- 页面事件
UserTrack提供页面事件的无痕埋点，无需开发者进行任何编码即可实现。同时UT提供透传参数功能。 - 控件点击及其他事件
控件点击相对简单，就是操作页面上的某个控件，因此只需把相关基础信息告诉采集SDK即可。
日志采集挑战
- 日志分流与定制处理
采用分治策略作为日志采集体系的基本原则 - 采集与计算一体化设计
以PV为例，阿里日志采集针对这个问题使用两套日志规范和与之对应的元数据中心。 - 大促保证
- 首先实现服务器推送配置到客户端
- 其次对日志进行分流
- 最后，在实时处理方面做优化提高吞吐量
三、数据同步
数据同步技术通用的指的是不同系统之间的数据流转，有多种不同的应用场景。主要有三种直连同步、数据文件同步、数据库日志解析同步。
阿里数据仓库的同步方式
阿里数据仓库的数据同步有两个特点，一是数据来源的多样性，二是体现在在他的数据量上。
批量数据同步
离线类型的数据仓库应用，需要将不同的数据源批量同步到数据仓库，以及将数据仓库处理的数据数据批量同步到业务系统。阿里采用DataX来实现。
数据实时同步
对于日志类数据来，每天产生的日志是源源不断，且分布在不同的服务器，需要实时尽快的将数据同步到数据仓库。大多数情况下，是通过消息订阅模式来实现数据实时同步。阿里的TimeTunnel就是这样的一个数据实时传输平台。
数据同步遇到的问题
分库分表的处理
目前主流的数据库都支持分库分表操作。阿里的TDDL是一个分布式数据库访问引擎，通过建立中间表的逻辑状态来整合统一分库分表的访问。
高效同步和批量同步
阿里研发OneClick产品，对不同数据源的同步配置透明化，简化了数据同步的操作步骤，降低了数据同步技能门槛。实现了数据的一键化和批量化同步。
增量同步与全量同步的合并
随着数据表量的发展，周期的进行全量同步的方式会影响处理效率。此时采用同步更新增量数据与上次的全量数据进行合并，从而获得最版本的全量数据。
同步性能的处理
传统的数据同步模式存在的几个问题导致数据同步的任务运行不稳定。其数据实践团队总结出了一套基于负载均衡的新型数据同步方案。
数据漂移处理
源系统同步进入数据仓库的第一层数据成为ODS。数据漂移通常指的是同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天变更的数据。
通常有两种处理方式：
- 多获取后一天的数据。但此方法有可能出错，比如后一天关闭了前一天支付的订单。
- 冗余时间，比如冗余前后15分钟。通过多个时间戳字段限制时间来获取相对准确的数据。
四、离线数据开发
面对海量的数据和复杂的计算，阿里巴巴的数据计算层包括两大体系：数据存储及计算平台(离线计算平台 MaxCompute和实时计算平台 StreamCompute)、数据整合及管理体系。
数据开发平台
统一计算平台
阿里离线数据仓库的存储和计算都是在阿里云大数据计算服务MaxCompute上完成的。
MaxCompute采用抽象的作业处理框架，将不同场景的各种计算任务统一在同一个平台上，为来自不同用户需求的各种数据处理任务提供统一的编程接口和界面。他由四部分组成，分别是客户端、接入层、逻辑层、及存储计算层。他具有计算性能高且更加惠普、集群规模大且稳定性高、功能组件强大、安全性高等特点。
统一开发平台
阿里数据开发平台集成了多个子系统来解决实际生产中的各种痛点。围绕MaxCompute平台，从任务开大、调试、测试、发布、监控、报警到运维管理，形成了整套工具和产品，既提高了开发效率，又保证了数据质量，并且在确保数据产出时效的同时，能对数据进行有效管理。
任务调度系统
整个调度系统有两个核心模块：调度引擎和执行引擎。调度引擎的作用是根据任务节点属性以及依赖关系进行实例化，生成调度树；执行引擎任务是根据调度引擎生成的具体任务实例和配置信息，分配CPU内存等资源，在任务对应的执行环境中运行节点代码。
当前的调度系统具有调度配置、定时调度、周期调度、手动运行、补数据、基线管理、监控报警等特点。
五、实时技术
业务诉求是希望能在第一时间拿到经过加工后的数据，以便实时监控当前业务状态并作出运营决策，引导业务往好的方向发展。按照数据的延迟情况，可以把数据时效性分为三种：
- 离线：在今天处理N天前的数据，延迟时间粒度为天。
- 准实时：在当前小时处理N小时前的数据，时间粒度为小时。
- 实时：在当前时刻处理当前的数据，时间粒度为秒。
离线和准实时都可以在批处理系统中实现只是调度周期不同，实时数据则要求在流式系统中完成。
流式一般具有以下系统特点：实时性高、属于常驻任务、性能要求高、应用具有局限性。
流式系统架构
流失系统各个子系统按功能划分可分为四个部分：数据采集、数据处理、数据存储、数据服务四个部分。
- 数据采集：数据采集是整个链路的源头，既然需要实时计算则需要源头实时采集。采集内容一般包括数据库变更日志和引擎访问日志。
- 数据处理：实时计算任务部署在流式计算系统上，通过数据中间件获取到实时源数据后进行实时加工处理。在阿里内部使用的是阿里云提供的StreamCompute系统。在处理过程中可能会遇到去重指标、数据倾斜、事务处理等问题需要解决。
- 数据存储：实时任务运行过程中，会计算许多维度和指标，这些数据需要放在一个存储系统中作为恢复或者关联使用。其中涉及到三类数据类型：中间计算结果、最终结果数据、维表数据。
- 数据服务:实时数据落地到存储系统后，就可以通过统一的数据服务获取到实时数据。
流式数据模型
数据模型设计师贯通数据处理过程的，流式数据处理也一样，需要对数据流进行建模分层。一般数据分层分为五层（ODS、DWD、DWS、ADS、DIM）。
多流关联
在流式计算中常常需要把两个实时数据进行主键关联，以得到对应的实时明细表。
维表使用
在实时计算中，关联维表一般会使用当前的实时数据（T）去关联T-2的维保数据，相当于在数据到达之前需要把维表数据准备好，并且一般是一份静态数据。这样做的原因：
- 数据无法及时准备好。
- 无法准确获取全量的最新数据。
- 数据的无序性。
大促挑战&保障
大促特种
- 毫秒级延时
- 洪峰明显
- 高保障性
大促保障
- 进行实时任务优化
- 独占资源和共享资源策略
- 合理悬着缓存机制，降低数据读写次数
- 计算单元合并，降低拓扑层级
- 内存对象共享，避免字符串拷贝
- 在高吞吐量和低延时之间进行平衡
- 进行数据链路保障： 通过增加备用链路，在主备链路之间切换。
- 如何进行压测：对数据链路进行多次压测，模拟线上峰值情况，验证系统能否正常云心。分为数据压测和产品压测。
六、数据服务
没有数据服务的年代，数据开放的方式非常简单，直接将数据导给对方，这种当时低效而且有许多安全问题。
服务架构演进
经过内部迭代，服务架构主要经历了四个部分的演进。
DWSOA
DWSOA是数据服务的第一个阶段，根据业务方的需求将数据以SOA的方式暴露出去，由需求驱动。
此阶段开发效率低，投入的人力成本较高。
OpenAPI
OpenAPI是数据服务的第二阶段。具体的做法是将数据按照统计粒度进行聚合，同维度的数据，形成一张逻辑表，采用同样的接口描述。这种方式有效的收敛了接口数量。
SmartDQ
当OpenAPI数据维度越来越多，生产已有接近100个接口时，带来了大量对象关系映射的维护工具。
在OpenAPI的基础上，在抽象一层用DSL来描述数据需求，采用了标准的SQL语法。
统一的数据服务层OneService
SmartDQ只满足了简单的查询服务需求，并不能解决复杂的业务逻辑。OneService主要提供多种服务类型来满足用户需求。
最佳性能实践
性能
- 资源分配：系统的资源是有限的，如果能合理的分配资源，使资源利用最大化，系统的性能就会上一个台阶。
- 剥离计算资源
- 查询资源分配
- 执行计划优化
- 缓存优化
- 元数据缓存
- 模型缓存
- 结果缓存
- 查询能力
- 合并查询
- 推送服务
稳定性
- 发布系统
- 使用元数据隔离：一般都使用三个系统：日常环境，预发布环境和线上环境。
- 隔离发布：发布系统还需要考虑到一点，隔离发布，不同用户的发布不会互相影响。
- 隔离
- 机房隔离：将服务器部署在两个机房中，每个机房独立部署一个模块，当摸个模块出现问题时，仍然能保证高可用。
- 分组隔离：不同的调用者的优先级不同，根据某些查询条件将调用者分层，将服务端机器划分成若干个组。
- 安全限制
对调用者做安全限制，以防止查询消耗大量的资源或者返回太多的记录。
监控
- 调用日志采集：要对调用的日志进行采集，首先要保证调用日志的完整性。
- 调用监控： 有了调用日志，就可以对调用进行监控，及时发现问题。
限流、降级
系统的总体容量主要根据平时的性能监控，以及定期的全链路压测评估得出，但是难免会遇到突发流量涌入的情况。此时系统需要用限流和服务降级等功能应对突增流量，以免系统被压垮。
七、数据挖掘
面对海量数据，如何从数据中挖掘出有效的信息形成真正的生产力，是所有大数据公司面对的共同课题。
数据挖掘中台体系
挖掘数据中台
通过算法生成的结果数据进行合理的分层存储，有的结果非常的通用和基础化，可以在很多业务场景进行复用，有的数据相对个性化和场景化，只适用于某个场景，因此需要对数据进行分层隔离，减少不必要的重复建设。基于以上分析，把数据中台分为三层：特征层、中间层和应用层，其中中间层包括个体中间层和关系中间层。不同层存储不同数据。
挖掘算法中台
阿里巴巴的数据挖掘算法中台建设目的在于各种各样的挖掘场景中抽象出有代表性的几类场景，并形成想用的方法论和实噪模板。
数据挖掘案列
用户画像
阿里全数据域提供了足够的数据基础，基于用户网购和搜索影音娱乐等行为的数据洞察，可以利用数据分析辅助算法的视角对用户进行特征刻画。即对用户打上各种各样的标签。
互联网反作弊
主要体现在一下几个方面：
- 账户/资金安全与网络欺诈防控
- 非人行为和账户识别
- 虚假订单与信用炒作
- 广告推荐与APP安装反作弊
- UGC恶意信息检测
现在的反作弊方法主要有一下几种： - 基于业务规则的方法
- 基于有监督学习的方法
- 基于无监督学习的方法
八、大数据领域建模综述
数据模型就是数据组织和存储的方法，它强调从业务、数据存取和使用角度合理存储数据。大数据系统需要数据模型方法来更好地组织和存储数据，以便在性能、成本、效率和质量之间取得平衡。
九、阿里巴巴数据整合及管理体系
阿里巴巴大数据建设方法论的核心是：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设。
定位价值
建设统一的、规范化的数据接入层和数据中间层，即数据公共层的建设。提供标准化、共享的数据服务能力，降低数据互通成本，释放计算、存储、人力等资源，消除业务和技术之痛。
规范定义
规范定义指以维度建模作为理论基础，构建总线矩阵，划分和定义数据域、业务过程、维度、度量/原子指标、修饰类型、修饰词、时间周期、派生指标。
指标体系
- 基本原则：组成体系之间有一定关系，命名约定，算法概述等。
- 操作细则：
1. 派生类的指标种类：分三类：事务性指标、存量型指标和复合型指标。
2. 复合型指标的规则：有比率型，比例型，变化量型，统计型，排名型等。
3. 其他规则：上下层级派生指标同时存在，父子关系原子指标存在时。
模型设计
阿里巴巴集团数据公共层设计理念遵循维度建模思想，主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。
模型层次
阿里巴巴的数据团队把表数据模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）和应用数据层（ADS），其中公共维度模型层包括明细数据层（DWD）和汇总数据层（DWS）。
基本原则
- 高内聚和低耦合
- 核心模型和扩展模型分离
- 公共处理逻辑下沉及单一
- 成本与性能平衡
- 数据可回滚
- 一致性
- 命名清晰、可理解
模型实施
OneData实施过程
- 数据调研：业务调研、需求调研
- 架构设计：数据域划分、构建总线矩阵
- 规范定义：定义指标体系
- 模型设计
- 总结：过程是一个高度迭代和动态的过程，一般采用螺旋实施法。
十、维度设计
维度设计基础
维度的基本概念
在维度建模中，将度量称为“事实”，将环境描述称为“维度”，维度是用于分析事实所需要的多样环境。维度所包含的表示维度的列，称为维度属性。维度使用主键标识其唯一性，主键也是确保与之相连的任何事实表之间存在应用完整性的基础。
维度设计的基本方法
以淘宝的商品维度为例：
- 选着维度或者新建维度
- 确定主维表
- 确定相关维表
- 确定维度属性
维度的层次结构
维度中的一些描述属性以层次方式或一对多的方式相互关联，可以被理解为包含连续主从关系的属性层次。层次的最底层代表维度中描述最低级别的详细信息，最高层代表最高级别的概要信息。
规范化和反规范化
规范化：大多数联机事物处理系统的底层数据结构设计时采用此种规范化技术，通过规范化处理将重复性属性移至其自身所属的表中，删除冗余数据。
反规范化：将维度的属性层次合并到单个维度中的操作称为反规范化。采用范规范化处理可以使结果方便其易用性能好。
一致性维度和交叉探查
数据仓库总线架构的重要基石之一就是一致性维度。将不同数据域的商品的事实合并在一起进行数据探查，如计算转化率等称为交叉探查。
如果不同数据域的计算过程使用维度不一致，就会导致交叉探查存在问题。
维度设计高级主题
维度整合
数据仓库的数据来源是大量的、分散的面向应用的操作型环境。所以数据进入数据仓库后需要进行数据集成。具体体现在以下几个方面：
- 命名规范的统一
- 字段类型的统一
- 公共代码及代码值得统一
- 业务含义相同的表的统一
维表的整合设计的内容和上面介绍的几个方面相同，维表整合有两个表现形式。
- 垂直整合：及不同来源表包含相同的数据集，只是存储的信息不同。
- 水平整合：即不同来源表包含不同的数据集，不同子集之间无交叉，也可能存在部分交叉。
维度变化
缓慢变化维
维度缓慢变化的提出是因为在现实世界中，维度的属性并不是静态的，太会随着时间的流逝发生缓慢的变化。
- 第一种处理方式：重写维度值。采用此种方式，不保留历史数据，始终取最新数据。
- 第二种处理方式：插入新的维度行。采用此种方式，保留历史数据，纬度值变化前的事实和过去的维度值相关联，维度值变化后的事实和当前的维度值相关联。
- 第三种处理方式：添加维度列。采用第二种处理方式不能讲变化前后记录的事实归一为变化前的读或者归一为变化后的维度。
特殊维度
递归层次
维度的递归层次按照层级是否固定分为均衡层次结构和非均衡层次结构。对此处理方法：
- 层次结构扁平化：降低递归层次使用复杂度最简单和有效的方法是层次结构的扁平化，通过建立维度的固定数量级别的属性来实现。
- 层次桥接表：针对层次结构扁平化所存在的问题，采用桥接表的方式来解决。
行为维度
类似如卖家地址、类目等维度，都和事实相关，如交易物流等称为行为维度。对于行为维度，有两种处理方式，其中一种是将其冗余至现有的维度表中，如将卖家信用等级冗余至卖家维表中。另一种是加工成单独的行为维表，如卖家主营类目。
多值维度
对于多值维度，一种情况是事实表的一条记录在某维表中有多记录与之相对应。常见处理方式有三种。
- 第一种是降低事实表的粒度。
- 第二种是处理方式是采用多字段。
- 第三种处理方式是采用较为通用的桥接表。
多值属性
维表中的某个属性字段包含多个值时，称为多值属性。
常见处理方式三种：
- 第一种保持维度主键不变，将多值属性放在维度的一个属性字段中。
- 第二种也是保持维度的主键不变，但将多值属性放在维度的多个属性字段中。
- 第三种是维度的主键会发生变化，一个维度值存放多条记录。
事实表设计
事实表基础
事实表特性
事实表有三种类型：事物事实表、周期快照事实表和累积快照事实表。
事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用维度和业务过程相关的度量。
事实表设计原则
- 尽可能包含所有与业务过程相关的事实
- 只选择与业务过程相关的事实
- 分解不可加性事实为可加组件
- 在选择维度和事实之前必须先声明粒度
- 在同一个事实表中不能有多种不同粒度的事实
- 事实的单位要保一致
- 对事实的NULl 值要处理
- 使用退化维度提高事实表的易用性
事实表的设计方法
- 选着业务过程及确定事实表类型
- 声明粒度
- 确定维度
- 确定事实
- 冗余维度
事物事实表
事物事实表，即针对发货签收等过程构建的一类事实表，用以跟踪定义业过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据。
周期快照事实表
快照事实表在确定的间隔内对实体的度量进行抽样，这样可以很容易的研究实体的度量值，而不需要聚集长期的事物历史。
特性
- 用快照采样状态：快照事实表以预定的间隔采样状态度量。
- 快照粒度：其粒度通常总是被多维声明，可以简单的理解为快照采样的周期以及什么将被采样。
- 密度与稀疏性：快照事实表示稠密的，无论当天是否有业务过程发生都会记录。
- 半可加性：收集到的状态度量都是半可加的。
累积快照事实表
对于类似研究事件之间时间间隔的需求，采用累积快照事实表可以很好的解决。
设计过程
- 选着业务过程
- 确定粒度
- 确定维度
- 确定事实
- 退化维度
特点
- 数据不断更新
- 多业务过程日期
三种事实表的比较
事物事实表记录的事物层面的事实，用于跟踪业务过程的行为，并支持集中描述行为的事实，保存的是最原子的数据，也成为“原子事实表”。
周期快照事实表以具有规律性的可预见的时间间隔来记录事实，时间间隔为每天每月每年等。
累积快照事实表被用来跟踪实体的一系列业务过程的进展情况，通常具有多个日期字段，用于研究业务过程中的里程碑过程的时间间隔。
十二、元数据
元数据是关于数据的数据。将元数据按用途不同分为两大类：技术类元数据和业务类元数据。技术类元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库视使用的数据。业务员数据从业务角度描述数据仓库中的数据，他提供了介于使用者和实际系统之间语义层，是不懂计算机鸡舍的业务员人员也能读懂数据仓库中的数据。
元数据应用
-
在阿里内部，使用Data Profile承担元数据画像任务，利用它，不仅可以节约研发人员的时间成本同时也提高了数据的利用率。
-
元数据门户致力于打造一站式的数据管理平台，高效一体化的数据市场。
-
同时还可以用于数据链路分析、数据建模和驱动ETL开发等。
十三、计算管理
目前内部MaxCompute集群上有200多万个任务，每天存储资源和计算的资源消耗都是很大的。
系统优化
HBO
HBO是根据任务历史执行情况任务分配更合理的资源，包括内存、CPU以及实例个数。
效果：
- 提高了CPU的利用率
- 提高了内存的使用率
- 提高了实例的并发数
- 降低了执行时长
CBO
这是基于代价的优化器，根据收集的统计信息来计算每种执行方式的代价，进而选着最优的执行方式。
任务优化
包括Map倾斜和Join倾斜以及Reduce倾斜，详细的过程参考书籍13章。
十四、存储和成本管理
数据压缩
在分布式系统中，为了提高数据的可用性和性能，通常会将数据存储为3分，这样则会使得数据的物理空间占用量变大。一般采用不同的数据压缩方法来降低数据存储成本。
数据重分布
在阿里的计算系统中，由于每个表的数据分布不同，插入的数据顺序不一样，会导致数据的压缩效果有很大差异。通过修改数据重分布，避免列热点，将会进一步节省存储空间。
生命周期管理
管理策略：
- 周期性删除策略
- 彻底删除策略
- 永久保留策略
- 存储极限策略
- 冷数据管理策略
- 增量表merge全量表策略
十五、数据质量
数据质量是数据分析结论和有效性准确性的基础，这是一切的前提。
数据质量保障原则
- 完整性：指数据记录的信息是否完整，是否存在缺失的情况。
- 准确性：指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息
- 一致性：一般体现在跨度很大的数据仓库体系中
- 及时性：保证数据的前三个特性后，则需要保证数据能够及时产出，这样才能体现数据的价值。
质量衡量
- 数据质量起夜率：数据仓库作业都是在凌晨运行的，一旦数据出现问题则需要开发人员半夜起来进行处理。因此每个月的起夜次数将是衡量数据质量建设完善度的一个指标。
- 数据质量事件：针对每一个数据质量问题，都记录一个数据质量事件。
- 数据质量故障体系：对于严重的数据质量事件，将升级为数据故障。
十六、数据应用
在前面有了完整的数据体系后，本章对数据的一些应用进行举例。
比如生意参谋（对内 对外 对敌情）和对内的数据产品平台等。