天险之路（上）

 这条看似不可能完成的路，慢慢的，被一步一个脚印所征服。

---

阿里巴巴大数据体系架构

阿里巴巴的数据计算层包括两大体系：

从数据计算频率角度来看：

数据加工链路：

一、日志采集

两大体系

浏览器的页面日志采集

1. 页面浏览（展现）日志采集
   1. 页面浏览量（Page View PV）
   2. 访客数（Unique Visitors UV）
2. 页面交互日志采集

1. 用户在浏览器内点击淘宝首页链接
2. 浏览器向淘宝服务发起HTTP请求。

一个标准的HTTP请求

1. 请求行（HTTP Requestrian Line）。中包含三个要素，分别是 请求方法、所请求资源的URL以及HTTP协议版本号。
2. 请求报头（HTTP Message Header）。 请求报头是浏览器在请求时向服务器提交的附加信息，请求报头一般会附加很多内容项（每个内容被称为一个头域（Header Field），在不引起混淆的情况下，往往将 Header Field 简称为 Header）。如果用户已经访问或登录过，一般都会在请求头中附加一个或多个Cookie数据项。
3. 请求正文（HTTP Message Body）。这一部分可选，一般而言，HTTP请求的正文都是空的。

1. 服务器接收并解析请求。服务器端的业务处理模块按业务逻辑处理本次请求并按照HTTP协议规定的格式，将结果以HTTP响应形式发回浏览器。

一个标准的HTTP响应

1. 状态行。状态行标识了服务器对于此次HTTP请求的处理结果。状态行内的主要内容是一个由三位数字构成的状态码
2. 响应报头。服务器在执行响应时，同样可以附加一些数据项，这些数据项将在浏览器端被读取和使用。
3. 响应正文。这一部分为可选部分，但对于大多数HTTP响应而言，这一部分都是非空的，浏览器请求的文档、图片、脚本等，其实就是被包装在正文内返回浏览器的。

1. 浏览器接收到服务器的响应内容，并将其按照文档规范展现给用户，从而完成一次请求。

记录浏览器行为，需要在第四步，也就是浏览器开始解析文档时才能进行。

日志采集思路：在HTML文档内的适当位置增加一个日志采集节点，当浏览器解析到这个节点时，将自动触发一个特定的HTTP请求到日志采集服务器。如此一来，当日志采集服务器接收到这个请求时，就可以确定浏览器已经成功地接收和打开了页面。

1. 客户端日志采集

植入页面文档内的js脚本执行。可由业务服务器在响应业务请求时动态执行，也可以在开发页面时由开发人员手动植入。

1. 客户端日志发送

采集脚本执行时，会向日志服务器发起一个日志请求，以将采集到的数据发送到日志服务器。

1. 服务器端日志收集。日志服务器接收到客户端发来的日志请求后，一般会立即向浏览器发回一个请求成功的响应，以免对页面的正常加载造成影响；同时，日志服务器的日志收集模块将会日志请求内容写入一个日志缓冲区内，完成此条浏览日志的收集。
2. 服务器端日志解析存档。服务器接收到的浏览日志进入缓冲区后，会被一段专门的日志处理程序顺序读出并按照约定的日志处理逻辑解析。由日志采集脚本记录在日志请求行内的参数，将在这个环节被解析（有时候伴随着转义和解码）出来，转存入标准的日志文件中并注入实时消息通道内供其它后端程序读取和进一步加工处理。

页面交互日志采集

用户在访问某个页面时具体的互动行为特征。通过一套“黄金令箭”的采集方案来解决交互日志采集的问题。

“黄金令箭” 基于HTTP协议的日志服务。

1. 业务方在“黄金令箭”的元数据管理界面一次注册需要采集交互日志的业务，在注册完成后，系统将生成与之对应的交互日志采集代码模板。
2. 业务方将交互采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定。
3. 当用户在页面上产生指定行为时，采集代码和正常的业务交互想要代码一起被触发和执行。
4. 采集代码在采集动作完成后将对于的日志通过HTTP协议发送到日志服务器，日志服务器接收到日志后，对于保存在HTTP请求参数部分的自定义数据，即用户上传的数据，原则上不做解析处理，只做简单的转存。

随后这些日志可被业务需要使用。

页面日志的服务器端清洗和预处理

1. 识别流量攻击，网络爬虫和流量作弊（虚假流量）
2. 数据缺项补正（保证数据统一口径 如：在用户登录后，对登录前页面日志做身份信息的回补）
3. 无效数据剔除（无效数据、失效、冗余）会干扰计算
4. 日志隔离分发

无线端日志采集

在用户进入页面时采集用户信息，用户离开页面发送日志信息。

使用UserTrack 的 SDK 来进行无线客户端日志采集

特殊情况SDK日志采集

1. 利用页面的生命周期来实现适当的聚合及确定发送时机。
2. 对于存在主会场的场景下，避免各类详情页干扰，利用页面的生命周期，识别页面的复用，配合栈的深度来识别是否是回退行为。

H5 & Native 日志统一

H5 嵌入 APP 即 Hybrid APP

 可以选择将 h5 的日志归到 native日志，也可以将 native 日志归集到 h5 日志。

阿里巴巴选择 Native部署采集 SDK 方式。将H5 归集到 native

1. SDK可以采集到更多的数据
2. SDK采集日志，会在本地缓存，然后再接机上传。

具体流程：

1. 将 h5 页面浏览和页面交互的数据，在执行时通过加载日志采集的js脚本。
2. 在浏览器日志采集的js实现将采集的数据打包，然后调用WebView框架的JSBridge接口，调用移动客户端对应的接口方法，将埋点数据对象当作参数传入。
3. 移动客户端日志采集SDK，封装提供接口，实现将传入的内容转换成移动客户端日志格式。采集SDK会识别是页面流量事件还是控件点击事件。这样做的优点是未来增加新的事件类型，就不需要改动WebView层的接口，只需改动js的部分内容和SDK中对应的内容即可。

此方案也是有局限性，必须要浏览器采集js、WebView、客户端采集 SDK 的配合。很多时候业务不希望做调整，更多的是希望减少依赖。

设备标识

互联网产品的两大基本指标是页面浏览量（Page View PV）和 访客数（Unique Visitors UV）

本来采用UDID，即设备唯一标识，但现在很多设备禁用该功能。

用户在不登录的情况下定位为该用户（除了使用设备唯一码，还需突破点）

日志传输

无线客户端日志的上传、压缩及传输的特殊性。

先存储在客户端本地，然后再伺机（如启动后，使用过程中、切换到后台）上传。

存储方式使用 Nginx 的 access_log

日志文件传输到下游

使用消息队列（TimeTunel，TT）来实现从日志采集服务器到数据计算的MaxCompute

日志采集的挑战

如何实现日志数据的结构化和规范化组织

1. 日志分流与定制处理

分治策略

阿里pv日志的请求url是随页面所在业务类型的不同而变化的。通过尽可能靠前地布置路由差异，就可以尽可能早地进行分流，降低日志处理过程中的分支判断消耗。

1. 采集与计算一体化设计

SPM(super position model 超级位置模型 url后的spm参数)

SPM规范和SPM元数据中心

数据全链路

 面对高峰期，采用延迟上报、部分采用功能。

延时上报，日志将被暂存在客户端，待配置恢复后再上传到服务器。

部分采样，满足条件的日志将被实施采样。

二、数据同步

直连同步

通过api接口和基于动态链接库的方式直连业务库。【缺点】对源系统的性能影响较大。

数据文件同步

通过专门的文本服务器，传输到目标系统。可增加压缩和加密功能，提高传输效率与安全性。（MySQL、Oracle、SQL Server）

数据库日志解析同步（性能好、效率高、影响小）

通过源系统的进程，读取归档日志文件来收集变化的数据信息，将其解析到目标数据文件。此操作系统层面完成，不需要通过数据库。再通过网络，实现源系统和目标系统之间的数据文件传输。【缺点】数据延时、投入较大、数据漂移和遗漏

数据仓库的同步方式

批量数据同步

将源数据类型统一转换为字符串类型的方式，实现数据格式统一。

阿里巴巴 DataX (高自由度的异构数据交换服务，采用 FrameWork+Plugin) 通过插件的形式提供支持，将数据从数据源读出并转换为中间状态。

实时数据同步

通过解析MySQL的binlog日志来实时获得增量的数据更新，并通过消息订阅模式来实现数据的实时同步。

建立一个日志数据交换中心。

TimeTunnel

数据同步问题与解决方案

分库分表处理

分库分表对于同步处理的复杂度提升

TDDL（taobao distributed data layer）通过建立中间状态的逻辑表来整合统一分库分表的访问。

高效同步和批量同步

数据库不统一问题

OneClick （统一管理mysql、oceanbase、postgresql、oracle......）

1. 对不同数据源的数据同步配置透明化。
2. 简化了数据同步操作

增量与全量同步的合并

全外链接（full outer join）+ 数据全量覆盖重新加载（insert overwrite）

将当天的增量数据和前一天的全量数据做全外连接，重新加载最新的全量数据。

同步性能处理

存在问题

（1）设备性能导致同步速度低

（2）不合理的CPU资源影响同步效率

(3) 重要的同步线程得不到CPU资源

解决方案

（1）创建任务的同时，提交任务

（2）预估总线程数

（3）拆分成数据块，将所有线程提交至同步控制器

（4）优先发送时间最长、优先级最高且为同一任务的线程

数据漂移处理

由于时间戳字段的准确性问题导致发生数据漂移

1. 数据库表中用来标识数据记录更新时间的时间戳字段
2. 日志中用来标记数据记录更新时间的时间戳字段
3. 具体业务过程发生时间的时间戳字段
4. 标识数据记录被抽取到时间的时间戳字段

造成的原因

1. 数据抽取需要时间
2. 手工修改数据未更新时间
3. 网页或系统压力

解决方案

1. 多获取后一天的数据
2. 通过多个时间戳字段（前一天最后几分钟的数据，和后一天开始几分钟的数据，再对时间进行去重）(全外链接)

三、离线数据处理

 阿里数据仓研发流程

MaxCompute 大数据计算服务

MaxCompute是海量数据处理平台，主要服务于海量数据的存储和计算，提供完善的数据导入方案，以及分布式计算模型，提供海量数据仓库的解决方案。

MaxCompute客户端

提供几种服务形式：Web、SDK、CLT（Command Line Tool）、IDE

MaxCompute接入层

提供HTTP服务、Cache、负载均衡，实现用户认证和服务层的访问控制。

MaxCompute逻辑层（核心）

实现用户空间和对象的管理、命令的解析与执行逻辑、数据对象的访问控制与授权等功能。有Worker、Scheduler、Executor三个角色。

Worker 处理所以的restful请求

Scheduler 负责MaxCompute Instance 的调度和拆解，并向计算层的计算集群询问资源占用情况进行流控。

Executor 负责MaxCompute Instance 的执行，向计算层的计算集群提交计算服务。

MaxCompute计算层（飞天内核）

运行在和控制层相互独立的计算集群上。

MaxCompute 中的元数据存储在阿里云计算的另一个开放服务OTS（Open Table Service，开放结构化数据服务）。元数据主要包括 用户空间元数据、Table/Partition Schema、ACL、job元数据、安全体系等。

MaxCompute组件

SQL：标准的SQL语法，提供各类操作和函数来处理数据。

MapReduce ：提供JAVA MapReduce编程模型，通过接口编写MR程序处理MaxCompute中的程序。

Graph：面向迭代的图计算处理框架，PageRank、单源最短距离算法、K-均值聚类算法。

Spark：使用Spark接口编程处理存储在MaxCompute中的数据。

RMaxCompute：使用R处理MaxCompute中的数据。

Volume：以Volume的形式支持文件。

数据开发流程

开发工作流的产品和工具

D2

是集成任务开发、调试及发布，生产任务调度及大数据运维，数据权限申请及管理等功能的一站式数据开发平台，并能承担数据分析工作台的功能。

SQLSCAN

将在任务开发中遇到的各种问题，SQL质量差、性能低、不遵守规范等，总结后形成规则，并通过系统及研发流程保障，事前解决故障隐患，避免事后处理。

DQC

Data quality center，数据质量中心。主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控。

主要有数据监控和数据清洗两大功能。

数据监控有强规则和弱规则之分，强规则会阻断任务的执行，而弱规则只告警而不会阻断任务执行。

阿里数据清洗策略：在数据同步过程中不进行数据清洗，避免影响数据同步效率。对于需要清洗的表 ，首先在DQC配置清洗规则；对于离线任务，规定固定的时间间隔，数据入仓后，启动清洗任务。

在彼岸

大数据系统的自动化测试平台

数据测试的测试方法是功能测试，主要验证目标数据是否符合预期。

1. 新增业务需求

对上线前的ETL任务进行测试，主要对目标数据和源数据进行对比，包括数据量、主键、字段空值、字段枚举值、复杂逻辑（UDF、多路分支等测试）

1. 数据迁移、重构和修改

组件：

1. 数据对比（不同集群、异构数据 库的表做数据对比）
2. 数据分布（提取表和字段的一些特征值）
3. 数据脱敏（将敏感数据模糊化）

任务调度系统

调度引擎——任务状态机模型

调度引擎——工作流状态机模型

调度引擎工作原理

• Async Dispatcher：异步处理任务调度
• Sync Dispatcher：同步处理任务调度
• Task事件处理器：工作流事件处理器，与任务状态机交互
• DAG 事件处理器：工作流事件处理器，与工作流状态机交互

一个DAG事件处理器包含若干个Task事件处理器

执行引擎工作原理

任务管理接口：供用户系统向Alisa中提交、查询和操作离线任务，并获得异步通知。

系统管理接口：供系统管理员进行后台管理，包括为集群增加新的的机器、划分资源组、查看集群资源和负载、追踪任务状态等。

Driver：Alisa 的调度器，Driver中实现了任务管理接口和系统管理接口；负责任务的调度策略、集群容灾和伸缩、任务失败备援、负载均衡实现。Drive 的任务调度策略是可插拔替换的，以满足不同的使用场景。Driver 使用 Resoerce manager 管理整个集群的负载。相当于Hadoop的JobTracker。

Task pool：Driver 也将已经提交的全部任务都放入到 Task pool 中管理，包括待资源、数据质量检测、运行中、运行成功和失败的所有任务。直到任务运行完成，并且用户确实获取到了关于这个状态的通知，Driver 才会将任务从 Task pool中移除。Driver 和 Node 通过 Task pool 提供的事件机制进行可靠的通信。整个系统全部状态都保存在 Task pool 中，这样系统的其它部分很容易实现高可用性和伸缩性。而 Task pool 本身采用 Zookeeper 实现，这样它本身也是具备高可用能力。

Resource manager：这个组件专注于集群整体资源的管理。

Task container：类似于Web Server，为 Task 提供运行的容器。容器负责处理Task的公共逻辑，如文件下载，任务级 Session、流程级 Session 的维护等。同时 Task container 负责收集机器的实际负载并上报给 Resource manager。

Session manager：这个组件实现了对 Task session 的管理。

Node：Node 代表 Alisa 集群中的一个节点。节点负责提供任务所需的物理资源。Node是逻辑概念，一台物理机器上可以部署一个或者多个Node。

大数据系统日常应用的各种场景

四、实时技术

流式数据处理技术是指业务系统每产生一条数据，就会立刻被采集并实时发送到流式任务中进行处理，不需要定时调度任务来处理数据。

流式技术架构

数据采集

采集内容：

数据库变更日志：MySQL 的 binlog 日志、HBase 的 hlog日志、OceanBase 的变更日志等。

引擎访问日志：用户访问网站产生的Apache引擎日志，搜索引擎的接口查询日志等。

采集条件：

数据大小限制：当达到限制条件时，把目前采集到的新数据作为一批（列如 512KB 写一批）

时间阀值限制：当时间达到一定条件时，会把目前采集到的新数据作为一批，避免在数据量少的情况下一直不采集（例如 30 秒写一批）

消息系统一般会用作业务数据库变更的消息中转，对于其他较大的业务数据（TB），一般会通过数据中间件系统来中转。

	时效性	吞吐量
消息系统	毫秒	低
数据中间件	秒	高

数据处理

实时计算任务部署在流式计算系统上，通过数据中间件获取到实时源数据后进行实时加工处理。（流计算引擎系统：推特Storm系统、雅虎S4系统、Apache Spark Streaming系统、Flink）

阿里巴巴StreamCompute系统，开发人员通过写SQL就可以实现实时计算，不需要关心其中的计算状态细节，提高了开发效率，降低了流计算门槛。

spout：拓扑的输入，从数据中间件中读取数据，并且根据自定义的分发规则发送给下游的bolt，可以有多个输入源。

bolt：业务处理单元，可以根据处理逻辑分为多个步骤，其相互之间的数据分发规则也是自定义的。

实时数据处理应用出于性能考虑，计算任务往往是多线程的。一般会根据业务主键进行分桶处理，并且大部分计算过程需要的数据都会放在内存中，这样会大大提高应用的吞吐量。当然，为了避免内存溢出，内存中过期的数据需要定时清理，可以按照LRU（最近最少使用）算法或者业务时间集合归类清理。

去重指标

在BI（商业智能）统计类实时任务中，对于资源的消耗有一类指标是非常高的，那就是去重指标。由于实时任务为了追求处理性能，计算逻辑一般都是在内存中完成的，中间结果数据也会在缓存在内存中，这就带来了内存消耗过多的问题。当去重数据在内存中放不下数据时分两种情况：

• 精准去重。通过数据倾斜来进行处理，把一个节点的内存压力分到多个节点上。
• 模糊去重。在业务精度要求不高的情况下，可以使用相关的去重算法，把内存的使用量降到千分之一或者更低，以提高内存的利用率。

数据处理算法

• 布隆过滤器：该算法是位数组算法的应用，不保存真实的明细数据，只保存明细数据对应哈希值的标记位。适用场景：统计精度要求不高，统计维度非常多的情况。
• 基数估计：利用哈希的原理，按照数据的分散程度来估算现有数集的边界，从而得出大概的去重值总和。适用场景：统计精度要求不高，统计维度非常粗的情况。

数据倾斜

在一个节点上完成相关的计算任务。在数据量非常大的时候，单个节点的处理能力是有限的，必然会遇到性能瓶颈。这时就需要对数据进行分桶处理，分桶处理和离线处理的思路是一样的。

• 去重指标分桶：通过对去重值进行分桶Hash，相同的值一定会被放在同一桶中去重，最后再把每个桶里面的值进行加和就得到总值，这里利用了每个桶的CPU和内存资源。
• 非去重指标分桶：数据随机分发到每个桶中，最后再把每个桶的值汇总，主要利用的是各个桶的CPU能力。

事务处理

由于实时计算是分布式处理的，系统的不稳定性必然会导致数据的处理有可能出现失败的情况。如网络的抖动导致数据发送不成功、机器重启导致数据丢失等。

• 超时时间：由于数据处理是按照批次来进行的，当一批数据处理超时时，会从拓扑的spout端重发数据。另外，批次处理的数据量不宜过大，应该增加一个限流的功能（限定一批数据的记录数或者容量等），避免数据处理超时。
• 事务信息：每批数据都会附带一个事务ID的信息，在重发的情况下，让开发者自己根据事务信息去判断数据第一次到达和重发时不同的处理逻辑。
• 备份机制：开发人员需要保证内存数据可以通过外部存储恢复，因此在计算机中用到的中间结果数据需要备份到外部存储中。

数据存储

在实时任务在运行过程中，会计算很多维度和指标，这些数据需要放在一个存储系统中作为恢复或者关联使用。

• 中间计算结果——在实时应用处理过程中，会有一些状态的保存（比如去重指标的明细数据），用于在发生故障时，使用数据库中的数据恢复内存现场。
• 最终结果数据——指的是通过ETL处理后的实时结果数据，这些数据是实时更新的，写的频率非常高，可以被下游直接使用。
• 维表数据——在离线计算系统中，通过同步工具导入到在线存储系统中，供实时任务来关联实时数据。

对于海量数据的实时计算，一般会采用非关系型数据库，以应对大量的多并发读写。

应对多并发读写表面设计和rowkey设计实践经验：

1.表名设计

设计规则：汇总层标识 + 数据域 + 主维度 + 时间维度

使用 断字母 + 下划线 方式，所有主维度相同的数据都放在一张物理表中，避免表数量过多，难以维护，其次从表名上也容易判断数据内容，方便排查问题。

2.rowkey设计

设计规则：MD5 + 主维度 + 维度标识 + 子维度1 + 时间维度 + 子维度2

以MD5的前几位作为rowkey的第一部分，可以把数据散列，让服务器整体负载是均衡的，避免热点问题。每个统计维度都会生成一个维度标识，以便在rowkey上做区分。

数据服务

OneService 好处：

• 不需要直连数据库，数据源等信息在数据服务层维护，这样当存储系统迁移时，对下游是透明的。
• 调用方只需要使用服务层暴露的接口，不需要关心底层取数逻辑的实现。
• 屏蔽存储系统间的差异，统一的调用日志输出，便于分析和监控下游使用情况。

流式数据模型

数据模型设计是贯通数据处理过程的，流式数据处理也一样，需要对数据流建模分层。实时建模跟离线建模非常类似，数据模型整体上分为五层（ODS、DWD、DWS、ADS、DIM）。

实时数据模型是离线数据模型的一个子集，在实时数据处理过程中，很多模型设计就是参考离线数据模型实现的。

数据分层5层

ODS层

ODS层属于操作数据层，是直接从业务系统采集过来的最原始数据，包含了所有业务的变更过程，数据粒度也是最细的。在这一层，实时和离线在源头上是统一的，这样的好处是用同一份数据加工出来的指标，口径基本是统一的，可以更方便进行实时和离线间数据比对。

DWD层

DWD层是在ODS层基础上，根据业务过程建模出来的实时 事实 明显层，对于访问日志这种数据，会回流到离线系统供下游使用，最大程度地保证实时和离线数据在ODS层和DWD层是一致的。例如：订单的支付明细表、退款明细表、用户的访问日志明细表。

DWS层

订阅明细层的数据后，会在实时任务中计算各个维度的汇总指标。如果维度是各个垂直业务线通用的，则会放在实时通用汇总层，作为通用的数据模型使用。比如电商网站的卖家粒度，只要涉及交易过程，就会跟这个维度相关，所以卖家维度是各个垂直业务的通用维度，其中的汇总指标也是各个业务线共有。

ADS层

个性化维度汇总层，对于不是特别通用的统计维度数据会放在这一层中，这里计算只有自身业务才会关注的维度和指标，跟其他业务线一般没有交集，常用于一些垂直创新业务中。

DIM层

实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线系统中供实时应用调用。这一层对实时应用来说是静态的，所有的ETL处理工作会在离线系统中完成。维表在实时应用的使用中跟离线稍有区别。

• ODS层到DIM层的ETL处理是在离线系统中进行的，处理完成后会同步到实时计算所使用的存储系统。
• ODS层和DWD层会放在数据中间件中，供下游订阅使用。
• 而DWS层和ADS层会落地到在线存储系统中，下游通过接口调用的形式使用。

多流关联

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

在两个表进行实时关联时，由于无法知道两个表的到达顺序，在两个数据流的每条新数据到来时，都需要到另外一张表中进行查找。如果其中一个表里的数据先到达，可以以此数据为基准管理另一张表，拼接成一条记录直接输出到下游。如果关联不上，则需要放在内存或外部存储中等待，直到数据到达。

不管是否关联成功，内存中的数据都需要备份到外部存储系统中，在任务重启时，可以从外部存储系统中恢复内存数据，这样才能保证数据不丢失。

此外，订单记录的变更有可能发生多次，需要根据订单ID去重，避免多次关联。

实时关联一般会根据关联主键进行分桶处理，并且在故障恢复时也需要分桶来进行，来降低查找数据量和提高吞吐量。

维表使用

在离线系统中，一般根据业务分区来关联事实表和维表。在实时计算中，一般会根据当前实时数据去关联维表数据。

实时计算中，数据关联遇到的一些问题

1.维表数据无法及时准备好

2.无法准确获取全量的最新数据

3.数据的无序性

高并发数据请求保障

数据量是其它时间点的几倍甚至数十倍，此时对系统的抗压能力要求非常高。

特征

1.毫秒级延时 2.洪峰明显 3.高保障性

保障

实时任务优化

独占资源和共享资源的策略

一任务在运行时80%以上的时间都需要去抢资源，这时候就需要考虑分配更多的资源，避免抢不到CPU资源导致吞吐量急剧下降。

合理选择缓存机制，尽量降低读写库次数

让最可能使用的数据留在内存中，使库读写次数降低。

计算单元合并，降低拓扑层级

拓扑结构越深，性能越差。

内存对象共享，避免字符拷贝

在不同线程间合理共享对象，可以大幅降低字符拷贝带来的性能消耗，需要注意不合理使用带来的内存溢出问题。

在高吞吐量和低延时中取平衡

将多个读写库操作和ACK操作合并成一个，降低网络请求带来的消耗，但会导致延时上升。

数据链路保障

（数据同步>数据计算>数据存储>数据服务）进行多链路搭建，多机房容灾。

压测

对平台本身进行压测和前端页面稳定性压测

平台本身：QPS:500次/秒进行压测

前端压测：8~24小时前端页面稳定性压测。浏览器内存，CPU消耗等。

五、数据服务

服务架构演进

DWSOA

将业务方对数据的需求通过SOA服务的方式暴露出去。由需求驱动，一个需求开发一个或者几个接口，编写接口文档，开放给业务方调用。

缺点：接口粒度粗，不灵活，扩展性差，复用率低。开发效率不高，无法快速响应业务。

OpenAPI

将数据按照其统计粒度进行聚合，同样维度的数据，形成一张逻辑表，采用同样的接口描述。

SmartDQ

在OpenAPI的基础上，再抽象一层，用DSL（Domain Specific Language）来描述取数需求。采用标准的SQL语法。同时使用ORM（Object Relation Mapping）框架封装DataSource。

接口易上难下，即使一个接口也会绑定一批让人（业务方、接口开发维护人员、调用方）。对外提供的数据服务接口一定要尽可能抽象，接口的数量要尽可能收敛，最后在保障服务质量的情况下，尽可能减少维护工作量。

统一的数据服务层（OneService）

技术架构

SmartDQ

元数据模型

自底向上：

1. 数据源：底层支持接入多种数据源，MySQL、HBase等。
2. 物理表：每张物理表都需要指明主键由哪些列组成，主键确定后即可得知该表的统计粒度。
3. 逻辑表：可理解为数据库中的视图，是一张虚拟表，也可以看作是由若干主键相同的物理表构成的大宽表。

架构图

查询数据库

1. 实时公共层的计算作业直接将计算结果写入HBase；
2. 通过同步作业将公共层的离线数据同步带对应的查询库；

服务层

1. 元数据配置：数据发布者到元数据中心进行元数据配置，建好物理表与逻辑表的映射关系，服务层会将元数据加载到本地缓存中，以便进行后续的模型解析。
2. 主处理模块：
   1. DSL解析：对用户的查询DSL进行语法解析，构建完整的查询树。
   2. 逻辑Query构建：遍历查询树，通过查找元数据模型，转变为逻辑Query。
   3. 物理Query构建：通过查询元数据模型中的逻辑表与物理表的映射关系，将逻辑Query转变为物理Query。
   4. Query拆分：如果该次查询涉及多张物理表，并且在该查询场景下允许拆分，则将Query拆分为多个SubQuery.
   5. SQL执行：将拆分后的SubQuery组装成SQL语句，交给对应的DB执行。
   6. 结果合并：将DB执行的返回结果进行合并，返回给调用者。

iPush

通过定制过滤规则，向Web、无线等终端推送消息的中间件平台。iPush核心服务器端基于高性能异步事件驱动模型的网络通信框架Netty4实现，结合使用Guava缓存实现本地注册信息的存储，Filter与Server之间的通信采用Thrift异步调用高效服务实现，消息基于Disruptor高性能的异步处理框架的消息队列，在服务器运行中Zookeeper实时监控服务器状态，以及Diamond作为统一的控制触发中心。

Lego

一个面向中度和高度定制化数据查询需求、支持插件机制的服务容器。采用Node.js技术栈实现，适合处理高并发、低延迟的IO密集型场景。

只提供日志、服务注册、Diamond配置监听、鉴权、数据源管理等一系列基础设施，具体的数据服务则由服务插件提供。基于Lego的插件框架可以快速实现个性化需求并发布上线。

uTiming

uTiming是基于在云端的任务调度应用，提供批量数据处理服务，支撑用户识别、用户画像、人群圈选三类服务的离线计算，以及用户识别、用户画像、人群透视的服务数据预处理、入库。

最加实践

性能

资源分配

        剥离计算资源

        剥离复杂的计算统计逻辑，将其全部交由底层的数据公共层进行处理，只保留核心的业务处理逻辑。

        查询资源分配

        设计两个独立的线程池，将Get请求和List请求分离。

        执行计划优化

        1.查询拆分：将查询拆分成几个独立的指标，这些指标分别在不同的物理表中，引擎层调用者的请求拆分成独立的查询，分别去不同的物理表中查询。查询结束后，将三个查询的结果汇总到一起返回给调用者。

        2.查询优化：分析用户请求中的SQL语句，将符合条件的List查询转换为Get查询。

缓存优化

        元数据缓存

        在服务启动时就将全量数据加载到本地缓存中，以最大程度地减少元数据调用的性能损耗。后台对数据生产者的发布信息进行监听，一旦有新的发布，就重新加载一次元数据。

        模型缓存

        将解析后的模型（包括逻辑模型、物理模型）缓存在本地。需要注意，由于模型缓存在本地，为了避免占用太多的内存，需要定期将过期的模型淘汰掉。

        结果缓存

        某些查询可能很复杂，响应时间较长，可以将结果查询进行缓存。

查询能力

        合并查询

        查询数据需求到不同类型的数据查询方式，造成实时数据与离线数据存储在两个数据源中，调用者的查询方式完全不同。

        离线数据最准确，需要优先使用离线数据。

        为了降低这种场景的复杂性，阿里巴巴设计了一种新的语言——REPLACE

        推送服务

        推送服务很好地解决了数据更新的实时性问题，同时也减少了对服务器的请求压力。

        1.对消息生产者进行监听。

        2.采用无锁的队列Disruptor来存放消息。在采用Disruptor的情况下，推送应用也考虑到可以对重要的消息配置单独的队列单线程运转，以提高性能。

        3.消息推送基于Socket来实现，采用基于高性能异步事件的网络通信框架Netty。

稳定性

        发布系统

        根据应用环境设计三套元数据：日常元数据、预发元数据和线上元数据。

        通过元数据的隔离，使得用户的变得用户的变更可以在预发环境中进行充分的验证，验证通过后再发布到线上环境中，避免了因用户误操作而导致线上故障。

        隔离发布

        资源划分：首先需要确定隔离的最小单元。控制在逻辑表层上。

        资源独占：当用户开始修改的时候，系统会锁定其正在修改的逻辑表及其下挂的物理表等资源，禁止其他用户修改。

        增量更新：发布时引擎是不需要重新加载全量元数据的，只需要加载所发布的逻辑表元数据即可。

        隔离（机房隔离、分组隔离）

        将系统划分为若干个独立模块，当某个模块出现问题时，整体功能仍能保证可用。也可以对系统资源进行有效的管理，从而提高系统的可用性。

        安全限制

        对调用者的调用做了诸多安全限制，以防止查询消耗大量的资源。

        1.最大返回记录数：数据库的查询强制带上LIMIT限制。

        2.必传字段：每张逻辑表都会配置主键，并标识哪些字段是调用者必须传入的。

        3.超时时间：以使得超时的查询能及时终止并释放资源，保障系统不会被偶发的超时拖垮。

监控

调用日志采集：1.基础信息 2.调用者信息 3.调用信息 4.性能指标 5.错误信息

调用监控：1.性能趋势 2.零调用统计 3.慢SQL查找 4.错误排查

限流、降级

限流

应用内QPS保护。针对调用者以及数据源等关键角色做QPS阈值控制。

降级

1. 通过限流措施，将QPS置为0，则对应的所有访问全部立即失败，防止故障扩散。
2. 通过修改元数据，将存在问题的资源置为失效状态，重新加载元数据后，对应的访问就全部失败。

六、数据挖掘

基于大数据的企业级数据挖掘需要包含两个要素：1.面向机器学习算法的并行计算框架与算法平台。2.面向企业级数据挖掘的算法资产管理体系。

数据挖掘算法平台

需要频繁进行网络通信、内存消耗高、计算要求快速迭代的算法任务，MPI是最佳的选择。MPI是一种基于消息传递的并行计算框架。

 

数据挖掘中台体系（两大应用场景、两大要素）

        可分为两大类应用：个体挖掘应用 与 关系挖掘应用。

        个体挖掘应用

        对单个实体的行为特征进行预测与分析。

        关系挖掘应用

        研究多个实体间的关系特征。

        两大要素：数据和算法。

挖掘数据中台

包含两类数据：特征数据与结果数据。

通过合理的分层，有效隔离通用性和个性化强的结果。

 

FDM层：用于存储在模型训练前常用的特征指标，并进行统一的清洗和去噪处理，提升机器学习特征工程环节的效率。

IDM层：个体挖掘指标中间层，面向个体挖掘场景（目标对象的相关属性），用于存储通用性强的结果数据。

RDM层：关系挖掘指标中间层，面向关系挖掘场景（与目标对象的相关的相关属性），用于存储通用性强的结果数据。

ADM层：用来沉淀比较个性偏应用的数据挖掘指标。

挖掘算法中台

建立一套评分卡建模的方法论和实操模板。

数据挖掘案例

用户画像

分析用户偏好的商品类型、品牌、风格元素、下单时间，构成复杂的行为模块。利用机器学习算法，可以从用户行为中推测其身份。

互联网反作弊

1. 账户/资金安全与网络欺诈防控
2. 非人行为和账户识别
3. 虚假订单与信用炒作识别
4. 广告推广与APP安装反作弊
5. UGC恶意信息检测

反作弊方法

1. 基于业务规则的方法

通过查看单个设备的单日出现城市数、登录账号数、设备id合法性等建立规则来衡量作弊情况。优点是精度高、可解释性强，能准确识别老的作弊方式；缺点是人力成本高，而且对新的作弊手法滞后性较强。

1. 基于有监督学习的方法

按照有监督分类算法的流程来建模，通过正负样本标记、特征提取、模型训练及预测等过程来识别作弊行为。

1. 基于无监督学习的方法

1.离线反作弊系统：包含规则判断、分类识别、异常检测等模块，通过历史行为和业务规则的沉淀，来判断未来行为的作弊情况。

2.实时反作弊系统：将离线中的许多规则和算法进行总结，在基本满足准确率和覆盖率的前提下抽取出其中计算速度较快的部分，以此来满足对实时性的要求。

七、数据模型

• 良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐
• 良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
• 良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率
• 良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

从OLTP和OLAP系统的区别看模型方法论的选择

OLTP系统通常面向的主要数据操作是随机读写，主要采用满足3NF的实体关系模型存储数据，从而在事务处理中解决数据冗余和一致性问题；而OLAP系统面向的主要数据操作是批量读写，事务处理中的一致性不是OLAP所关注的，其主要关注数据的整合，以及在一次性复杂大数据查询和处理中的性能，因此它需要采用一些不同的数据建模方法。

典型的数据仓库建模方法论

ER模型

• 高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况。
• 中层模型：在高层模型的基础上，细化主题的数据项。
• 物理模型（底层模型）：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。

维度模型

1. 选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，也可以是某个事件的状态，
2. 选择粒度。
3. 识别维表。用于分析时进行分组和筛选。
4. 选择事实。确定分析需要衡量的指标。

Data Vault 模型

• Hub：是企业的核心业务实体，由实体key、数据仓库序列代理健、装载时间、数据来源组成。
• Link：代表Hub之间的关系。由Hub的代理键、装载时间、数据来源组成。
• Satellite：是Hub的详细描述内容，一个Hub可以有多个Satellite。由Hub的代理键、装载时间、来源类型、详细的Hub描述信息组成。

Anchor模型

组成

• Anchors：类似于 Data Vault 的 Hub，代表业务实体，且只有主键。
• Attributes：功能类似于Data Vault 的 Satellite，将其全部K-V结构化，一个表只有一个Anchors的属性描述。
• Ties：就是Anchors之间的关系，单独用表来描述，类似于Data Vault 的 Link，可以提升整体模型关系的扩展能力。
• Knots：代表那些可能会在多个Anchors中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。

数据模型实践综述

第一阶段：以Oracle为基础，基于ODS数据进行统计。

第二阶段：引入MPP架构体系的Greenplum，开始尝试ER+维度模型方式，构成ODL(操作数据层)+BDL（基础数据层）+IDL（接口数据层）+ADL（应用数据层）。

第三阶段：以Hadoop为代表的分布式存储计算平台的快速发展，以及自研分布式计算平台MaxCompute。和Kimball的维度建模为核心概念的模型方法论。共同构建了阿里巴巴公共层模型数据架构体系。

八、数据整合及管理体系

构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设。从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设。

定位及价值

提供标准版的（Standard）、共享的（Shared）、数据服务（Service）能力，降低数据互通成本，释放计算、存储、人力等资源，已消除业务和技术之痛。

体系架构

业务板块

根据业务的属性划分出几个相对独立的业务板块，业务板块之间的指标或业务重叠性较小。

规范定义

设计出一套数据规范命名体系，规范定义将会被用在模型设计中。

模型设计

以维度建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实。

规范定义

以维度建模作为理论基础，构建总线矩阵，划分和定义数据域、业务过程，维度、度量/原子指标、修饰类型、修饰词、时间周期、派生指标。

名词术语

指标体系

基本原则

组成体系之间的关系

• 派生指标由原子指标、时间周期修饰词、若干其他修饰词组合得到。

• 原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域
• 派生指标可以选择多个修饰词，修饰词之间的关系为“或”或者“且”，由具体的派生指标语义决定。
• 派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关。
• 原子指标有确定的英文字段名、数据类型和算法说明；派生指标要继承原子指标的英文名、数据类型和算法要求。

命名约定

• 尽量使用英文简写，不要过长
• 周期修饰词

算法

算法概述——算法对应的用户容易理解的阐述

举例——通过具体例子帮助理解指标算法

SQL算法说明——对于派生指标给出SQL的写法或者伪代码

操作细则

派生指标的种类

复合型指标的规则

比率型、比例型、变化量型、变化率型、统计型、排名型、对象集合型。

其它规则

1.上下层级派生指标同时存在时

2.父子关系原子指标存在时

模型设计

指导理论

参考： StarSchema-The Comlpete Refernce 和 The Data Warehouse Toolkit-TheDefinitive Guide to Dimensional Modeling

数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。

模型层次

基本原则

1. 高内聚和低耦合
2. 核心模型与扩展模型分离
3. 公共处理逻辑下沉及单一
4. 成本与性能平衡
5. 数据可回滚
6. 一致性
7. 命名清晰、可理解

模型实施

业界常用的模型实施过程

Kimball模型实施过程

高层模型

创建高层维度模型图。确定维表创建初始属性列表，为每个事实表创建提议度量。

详细模型

确定每个维表的属性和每个事实表的度量，并确定信息来源的位置、定义，确定属性和度量如何填入模型的初步业务规则。

模型审查、再设计和验证

进行模型的审查和验证，根据审查结果对详细维度进行再设计。

提交ETL设计和开发

由ETL人员完成物理模型的设计和开发。

Inmon模型实施过程

其他模型实施过程

• 业务建模，生成业务模型，主要解决业务层面的分解和程序化。
• 领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
• 逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
• 物理建模，生成物理模型，主要解决逻辑模型针对不同关系数据库的物理化以及性能等一些具体的技术问题。

OneData实施过程

数据调研

需求调研

1. 根据与分析师、业务运营人员的沟通获知需求；
2. 对报表系统中现有的报表进行研究分析。

数据域划分

面向业务分析，将业务过程或者维度进行抽象的集合。

构建总线矩阵

1. 明确每个数据域下有哪些业务过程。
2. 业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

---

本文旨在读《阿里巴巴大数据之路》时，对相关知识点进行摘录与总结，并与大家分享。