高屋建瓴 | 阿里巴巴大数据之路

By 大数据技术与架构

场景描述：

在阿里巴巴集团内，数据人员面临的现实情况是：集团数据存储已经达到EB级别，部分单张表每天的数据记录数高达几千亿条；在2016年“双11购物狂欢节”的24小时中，支付金额达到了1207亿元人民币，支付峰值高达12万笔/秒，下单峰值达17.5万笔/秒，媒体直播大屏处理的总数据量高达百亿级别且所有数据都需要做到实时、准确地对外披露……巨大的信息量给数据采集、存储和计算都带来了极大的挑战。

《大数据之路：阿里巴巴大数据实践》就是在此背景下完成的。《大数据之路：阿里巴巴大数据实践》中讲到的阿里巴巴大数据系统架构，就是为了满足不断变化的业务需求，同时实现系统的高度扩展性、灵活性以及数据展现的高性能而设计的。

关键词：啤酒   智能酿造   

《大数据之路：阿里巴巴大数据实践》由阿里巴巴数据技术及产品部组织并完成写作，是阿里巴巴分享对大数据的认知，与生态伙伴共创数据智能的重要基石。相信《大数据之路：阿里巴巴大数据实践》中的实践和思考对同行会有很大的启发和借鉴意义。

 

综述

阿里巴巴数据平台总共分为四个基本层级：

• 数据采集层：数据采集包括日志采集和数据库数据同步两部分，其中日志采集包括：Aplus.JS是Web端日志采集技术方案；UserTrack是APP端日志采集技术方案。

• 数据计算层：阿里巴巴的数据计算层包括两大体系：数据存储及计算云平台（离线计算平台MaxCompute和实时计算平台StreamCompute）和数据整合及管理体系（内部称之为“OneData”）。从数据计算频率角度来看，阿里数据仓库可以分为离线数据仓库和实时数据仓库。离线数据仓库主要是指传统的数据仓库概念，数据计算频率主要以天（包含小时、周和月）为单位；如T-1，则每天凌晨处理上一天的数据。阿里数据仓库的数据加工链路也是遵循业界的分层理念，包括操作数据层（Operational Data Store，ODS）、明细数据层（Data Warehouse Detail，DWD）、汇总数据层（Data Warehouse Summary，DWS）和应用数据层（Application Data Store，ADS）。

• 数据服务层：数据服务层对外提供数据服务主要是通过统一的数据服务平台（为方便阅读，简称为“OneService”）。OneService以数据仓库整合计算好的数据作为数据源，对外通过接口的方式提供数据服务，主要提供简单数据查询服务、复杂数据查询服务（承接集团用户识别、用户画像等复杂数据查询服务）和实时数据推送服务三大特色数据服务。

• 数据应用层：对内，阿里数据平台产品主要有实时数据监控、自助式的数据网站或产品构建的数据小站、宏观决策分析支撑平台、对象分析工具、行业数据分析门户、流量分析平台等。对外，有服务于商家的数据产品——生意参谋。

 

日志采集

01、阿里巴巴的日志采集体系方案包括两大体系：

• Aplus.JS是Web端（ 基于浏览器）日志采集技术方案；

• UserTrack是APP端（无线客户端）日志采集技术方案。

02、浏览器的页面日志采集（Aplus.JS）

• 页面浏览（展现）日志采集

顾名思义，页面浏览日志是指当一个页面被浏览器加载呈现时采集的日志。 此类日志是最基础的互联网日志，也是目前所有互联网产品的两大基本指标： 页面浏览量（Page View，PV）和访客数（UniqueVisitors，UV）的统计基础。

在HTML文档内植入日志采集脚本的动作可以业务服务器在响应业务请求时动态执行，也可以在开发页面时由开发人员手动植入。 在阿里巴巴，这两种方式均有采用，其中自动方式的占比较高。

• 页面交互日志采集

当页面加载和渲染完成之后，用户可以在页面上执行各类操作。 随着互联网前端技术的不断发展，用户可在浏览器内与网页进行的互动已经丰富到只有想不到没有做不到的程度，互动设计都要求采集用户的互动行为数据，以便通过量化获知用户的兴趣点或者体验优化点。 交互日志采集就是为此类业务场景而生的。

交互日志呈现高度自定义的业务特征（例如活动页面的游戏交互和购物车页面的功能交互两者截然不同）。 在阿里巴巴，通过“黄金令箭”的采集方案来解决交互日志的采集问题。

黄金令箭的步骤： 配置元数据->业务方把交互日志采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定->当用户在页面上产生交互行为时，采集代码触发执行。

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

A、依托算法识别非正常的流量并归纳出对应的过滤规则集加以滤除。

B、数据缺项补正： 例如，用户登录后对登录前的日志做身份信息的回补。

C、无效数据剔除： 某些情况下，因业务变更或配置不当导致的无效数据。

D、日志隔离分发： 基于数据安全，某些日志在进入公共环境之前需要做隔离。

03、无线客户端的日志采集（UserTrack）

无线客户端的日志采集采用SDK来完成，在阿里巴巴内部使用名为UserTrack的SDK来进行无线客户端的日志采集。 无线客户端的日志采集和浏览器的日志采集方式有所不同，移动端的日志采集根据不同的用户行为分成不同的事件，“事件”为无线客户端日志行为的最小单位。 基于常规的分析，UserTrack（UT）把事件分成了几类，常用的包括页面事件（同前述的页面浏览）和控件点击事件（同前述的页面交互）等。

• 页面事件

阿里巴巴提供了对页面事件的无痕埋点，即无须开发者进行任何编码即可实现。 对于手动方式埋点，UT提供了两个接口分别用于页面展现和页面退出时调用（这样可以得到停留时长），还提供了添加页面扩展信息的接口。

为了节约计算和分析的成本，UT提供了透传参数功能： 把当前页面的某些信息，传递到下一个页面，甚至下下个页面的日志中。 可以使用阿里SPM超级位置模型来进行来源去向的追踪。

• 控件点击及其他事件

和浏览器客户端的日志采集一样，交互日志也呈现出高度自定义的业务特征。 记录了： 基本的设备信息、用户信息、控件所在页面名称、控件名称和控件的业务参数。

04、高级功能

• 无线客户端曝光日志预聚合：可以利用无线客户端的本地存储进行曝光日志预聚合。

• 无线客户端回退识别：由于无线客户端存在明显的回退行为，需要利用页面生命周期，识别页面的复用，配合栈的深度来识别是否是回退行为。

• H5和native日志统一

APP的native页面采用sdk进行采集，而H5页面采用基于浏览器的页面日志采集方案，因此目前这是两套不同的方案，需要一种方式进行统一。阿里巴巴选择将H5日志归到Native日志的方案：H5页面浏览->触发JS脚本并搜集当前页面参数->JS脚本将所采集的数据打包到一个对象中，然后调用WebView框架的JSBridge接口，调用移动客户端对应的接口方法，将埋点数据对象当作参数传入。

• 设备标识

对于登录用户，可以使用用ID进行唯一标识，但是很多日志行为并不要求用户登录，这就导致很多情况下采集上来的日志都没有用户ID。阿里巴巴采用UTDID方案，但就目前的进展来说，UTDID还未实现其使命。

• 无线客户端日志传输

无线客户端的日志传输，一般不是产生一条上传一条，而是先存储在本地，然后再伺机上传。

05、日志采集的挑战

• 日志分流与定制处理：由于数据量巨大，尽可能早的进行分流。

• 采集与计算一体化设计：对应于PV日志的解决方案是SPM规范（在页面的URL内可以看见SPM参数）和SPM元数据中心；对应于自定义日志的解决方案是黄金令箭/APP端的日志规范及其配置中心。

2016年的双11，阿里日志采集浏览等核心用户行为日志均实现了100%全量及实时服务，支持天猫所有会场的实时推荐。在双11中，用户的浏览、点击、滚屏等每个操作行为，都实时影响到后续为其推荐的商品，很好的提高了用户体验。

 

数据同步

数据同步的几种方式：

• 直连同步：通过ODBC/JDBC等接口直连数据库，对源系统性能影响较大。

• 数据文件同步：简单，实用，松耦合，可加密、可压缩。

• 数据库日志解析同步：比如oracle的ogg，对源系统影响小。需要注意的是：要根据业务系统的实际情况，选择D删除记录的处理逻辑。

阿里巴巴的数据同步方式：

• 批量数据同步：通过DataX来实现，能满足多方向、高自由度的异构数据交换服务产品；对于不同的数据源，能够通过插件的形式提供支持。

• 实时数据同步：通过TT来实现。

数据同步遇到的问题与解决方案：

• 分库分表的同步：阿里巴巴是通过TDDL分布式数据库引擎把多张表的访问变成单张表的访问。

• 增量与全量同步的合并：当然增量和前一天的全量合并，传统是采用merge方式（update+insert），但大数据平台基本都不支持update操作，现在比较推荐的方式是：将当天的增量数据和前一天的全量数据做全外连接，重新加载最新的全量数据。这种方式的性能比update要高得多。

数据漂移的处理：

• 数据漂移是指ODS表的同一个业务日期中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。

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

• 阿里的上述方法，涉及到排序，其实代价也是有点高的，如果没有标准的处理模块，自己写起逻辑来也是有些麻烦。很多情况下，如果数据稍微差一点关系不大的业务，我们都选择不做处理。

 

数据计算层

一、阿里巴巴的数据计算层包括：

• 数据存储及计算平台（离线计算平台MaxCompute和实时计算平台StreamCompute）

• 数据整合及管理体系（OneData）

二、统一计算平台MaxCompute（离线）

• 有几万台机器，存储近1000PB

• 功能组件：SQL、MR、Graph、Spark、R、Volume

三、统一开发平台

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

• 使用D2进行数据开发的基本流程：用户使用IDE进行计算节点的创建，可以是SQL/MR任务，也可以是Shell任务等，设置好节点属性及依赖关系，进行试运行，并可以发布到生产环境。

• SQLSCAN：包括代码规范类规则检查（命名规范等）、代码质量类规则检查（分母为0等）、代码性能类规则检查（大表扫描等）。

• DQC：数据质量监控规则包括--主键监控、表数据量及波动监控、重要字段的非空监控、重要枚举字段的离散值监控、指标值波动监控、业务规则监控等。阿里数据仓库采用非侵入式清洗策略，在数据同步过程中不进行清洗，避免影响同步效率，在数据进入ODS层之后进行清洗。

• 在彼岸：用于大数据系统的自动化测试平台，将通用性、重复性的操作沉淀在测试平台中，避免被“人肉”，提高测试效率。

• 在彼岸--数据对比：表级对比规则主要包括数据量和全文对比；字段级对比规则主要包括字段的统计值（如sum、avg、max、min等）、枚举值、空值、去重数、长度值等。

• 在彼岸-数据分布：提取表和字段的一些特征值，并将这些特征值与预期值进行比对。表级数据特征提取主要包括数据量、主键等；字段级数据特征提取主要包括字段枚举值分布、空值分布、统计值、去重数、长度值等。

• 数据脱敏：将敏感数据模糊化。

四、任务调度系统

• 调度配置：常规的配置是手工方式，如果出错；阿里巴巴采用手工配置和自动识别相结合的方式。任务提交时，SQL解析引擎自动识别此任务的输入表和输出表，输入表自动关联产出此表的任务，输出表亦然。通过此种方式，解决了上述问题，可以自动调整任务依赖，避免依赖配置错误。

五、数据时效性

• 离线：延迟时间粒度为天；准实时：延迟时间粒度为小时；实时：延迟时间粒度为秒。

• 离线和准实时都可以在批处理系统中实现，比如Hadoop、MaxCompute等，只是调度周期不一样而已，而实时数据则需要在流式处理系统中完成。

六、流式技术架构： 流式技术架构中的系统跟离线处理是有交叉的，两套技术方案并不是完全独立的，并且在业界中有合并的趋势。

• 数据采集

不管是数据库变更日志，还是引擎访问日志，都会在服务器上落地成文件，所以只要监控文件的内容发生变化，采集工具就可以把最新的数据采集下来。 一般情况下，出于吞吐量以及系统压力上的考虑，并不是新增一条记录就采集一次，而是基于下面的原则，按批次对数据进行采集： 数据大小限制原则--当数据大小达到限制条件时触发采集； 时间阈值原则--当时间达到一定条件时触发采集。 实时采集下来的数据一般放入数据中间件，比如Kafka、TimeTunnel等。

• 数据处理

实时处理计算引擎有Storm、SparkStreaming、Flink、StreamingCompute等。 StreamingCompute： 在Storm基础上包装一层SQL语义，方便开发人员通过写SQL就可以实现实时计算，而不需要关心计算状态细节； 当然，它也支持传统模式的开发； 还提供了流计算开发平台，在这个平台上就可以完成应用的相关运维工作，而不需要登录服务器操作，极大提高运维效率。

实时数据处理遇到的几个典型问题：

A、去重指标： 模糊去重的第一个--布隆过滤器在实时指标计算中的应用； 模糊去重的第二个方法--基数估计，估算的去重值可能比真实值小，也可以大，存储1亿条数据只需要几KB的内存，适用统计精读要求不高，统计维度非常粗的情况，比如整个大盘的UV数据，基数估计在各个维度值之间不能共用，比如统计全天小时的UV数据，就需要有24个基数估计对象。

B、数据倾斜： 数据倾斜是ETL中经常遇到的问题，比如计算一天中全网访客数或者成交额时，最终的结果只有1个，通常应该是在一个节点上完成相关的计算任务。 因此，在数据量非常大的时候，单个节点的处理能力是有限的，就需要进行分桶处理，充分利用每个桶的CPU和内存资源。 第一种情况是去重指标分桶--通过对去重值进行分桶Hash，相同的值一定会被放在同一个桶中去重，最后再把每个桶里面的值进行加和得到总值； 第二种情况是非去重指标分桶--此时数据随机分发到每个桶中，最后再把每个桶的值汇总。

C、事务处理： 上面提到的几个流计算系统几乎都提供了数据自动ACK、失败重发以及事务信息等机制，这些机制都是为了保证数据的幂等性。

• 数据存储

在实践中一般使用HBase、MongoDB等列式存储系统，这些系统的读写效率都能达到毫秒级。 但是这些系统的缺点也是明显的，以HBase为例，一张表必须要有rowkey，而rowkey是按照ASCII码来排序的，这就像关系型数据库的索引一样，rowkkey的规则限制了读取数据的方式，如果业务方需要使用另一种读取数据的方式，则必须重新输出rowkey。 从这个角度来看，HBase没有关系数据库方便，但HBase可以存储几十TB的海量数据库，而关系数据库必须要分库分表才能实现这个量级的数据存储。 因此，对于海量数据的实时计算，一般会采用NoSql数据库，以应对大量的多并发读写。

• 数据服务：实时数据落地到存储系统后，使用方就可以通过OneService等把数据对外进行共享。

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

• 数据分层：ODS（实时接口层）、DWD（实时明细数据层）、DWS（实时通用汇总层）、ADS（实时个性化维度汇总层）、DIM（维表层）。一般ODS和DWD会放在数据中间件中，供下游订阅使用，而DWS和ADS会落地到在线存储系统中，DIM一般离线处理。在每一层中，可以按照重要性划分等级，优先保障最高等级的实时任务。

通过一个简单的例子来说明每一层存储的数据：

A、ODS层： 订单粒度的变更过程，一笔订单有多条记录。

B、DWD层： 订单粒度的支付记录，一笔订单只有一条记录。

C、DWS层： 卖家的实时成交金额，一个卖家只有一条记录，并且指标在实时刷新。

D、ADS层： 外卖地区的实时成交金额，只有外卖业务使用。

E、DIM层： 订单商品类目和行业的对应关系维表。

• 多流关联：实时采集两张表的数据，每到来一条新数据时都在对方内存表截止当前的全量数据中查找，如果能找到则说明关联成功直接输出，否则需要把数据放在内存中的自己表数据集合中等待。另外，不管是否关联成功，内存数据都需要备份到外部存储系统中。还有，订单记录的变更可能发生多次，需要根据订单ID去重，避免A表和B表多次关联成功。同时，考虑到内存关联查找数据的性能，一般会把数据按照关联主键进行分桶处理。

• 维表使用：在实时计算中，一般会使用当前的实时数据（T）去关联T-2的维表数据。因为到达零点时，T-1的维表数据还没准备好，所以一般在实时计算中维表关联都统一使用T-2的数据，这样对于业务来说，起码关联到的维表数据是确定的（虽然维表数据有一定的延时，但是许多业务的维表在两天之间变化是很少的）。如果维表数据量不是特别大，可以全量加载到内存使用；如果维表数据量特别大，则可以增量查找和LRU过期的形式，让最热门的数据留在内存中。

 

数据服务层

阿里数据服务架构演进过程如下：

• DWSOA：一个需求一个接口，编码实现接口，接口数量5000/年。开发效率低，投入成本高，扩展性差。

• OpenAPI：一类需求一个接口，配置实现接口，接口数量200/年。相比上一种方式，这种方式有效收敛了数量。

• SmartDQ：所有需求一个接口，配置实现接口，接口数量1，缺点是服务形式不够丰富，只能满足简单的查询服务需求（毕竟SQL并不能解决复杂的业务逻辑）。SmartDQ通过在OpenAPI的基础上，再抽象一层，用DSL（领域专用语言）来描述取数需求，新做一套DSL必然有学习成本，因此采用标准的SQL语法。

• OneService：提供多种服务类型来满足用户需求。

A、OneService-SmartDQ：通过SQL语法提供简单的查询服务需求。

B、OneService-Lego：采用插件方式满足个性化需求，为了避免插件之间相互影响，我们将插件做成微服务，使用Docker做隔离。Lego可以采用轻量级的Node.JS技术栈实现，适合处理高并发、低延迟的IO密集型场景。

C、OneService-iPush：主要提供websocket和long polling两种方式，其应用场景主要是商家端实时直播。比如双11，此时使用websocket方式可以有效缓解服务器压力，给用户带来最实时的体验。

D、OneService-uTiming：主要提供即时任务和定时任务两种模式，其主要应用场景是满足用户运行大数据量任务的需求。

最佳实践：

• 资源分配：复杂的计算逻辑可以提前计算；Get接口只返回一条记录，查询代价小响应时间短，List接口返回多条记录，查询时间相对较长，可以设计Get线程池和List线程池两个独立的线程池避免Get接口和List接口相互影响；查询可以在引擎层自动进行拆分查询，然后再把查询结果进行合并。

• 缓存优化：元数据缓存、模型缓存、结果缓存。

• 查询能力：由于离线数据和实时数据存放在不同地方，并且离线数据最准确，需要优先使用离线数据，如果离线数据还未产出，则改用实时数据，这就是要对离线和实时进行合并查询；能采用推送的，就不采用轮询，因为轮询对服务器压力大。

• 限流、降级：限流就是直接降到0，降级就是只将存在问题的资源置为失效状态。

 

数据挖掘中台

2012年以前，由于数据的规模还不是特别庞大，大部分挖掘应用所需处理的样本量在百万以内，而处理的特征一般也少于100维，那时像SAS、SPSS、Clementine等单机版的数据挖掘软件已经能满足大部分挖掘应用的需求。

随着数据量的爆炸，如今挖掘平台面对的训练数据量动辄上亿，特征维度动辄百万，因此需要分布式、可视化的数据挖掘算法平台。

就数据挖掘的商业场景而言，可以分为两大类：个体挖掘和关系挖掘。个体挖掘是指对单个实体的行为特征进行预测与分析，关系挖掘是指研究多个实体间的关系特征，如商品的相似关系和竞争关系。

就数据挖掘的技术而言，可以分为两大类：数据挖掘数据中台、数据挖掘算法中台。

1、数据中台

• 数据挖掘的过程中包括两类数据：特征数据和结果数据。算法需要的特征变量就是特征数据，算法最终输出的商品销量的预测结果就是结果数据。

• 对于特征数据，挖掘项目中80%的时间可能都是在处理特征，这些特征的提取、清洗、标准化以及基于业务场景的再组合和二次加工往往工作繁重。因此，就想到可以按照标准、规范构建一个全局特征库，每个挖掘工程师只需访问几张物理表就能迅速搜集到大部分自己想要的特征。

• 对于结果数据，可以进行分层存储：通用结果和个性化结果。

• 基于以上分析，可以把挖掘数据中台分为三层：特征层FDM（Featural Data Mining Layer）、个体中间层IDM（Individual Data Mining Layer）、关系中间层RDM（Relational Data Mining Layer）和应用层ADM（Application-oriented Data Mining Layer）；分层架构见下图。

• 特征层：用于存储在模型训练前常用的特征指标，并进行统一的清洗和去噪处理。

• 中间层：个体中间层IDM和关系中间层RDM统一称为中间层。其中，IDM面向个体挖掘场景，用于存储通用性强的结果数据；RDM面向关系挖掘场景，用于存储通用性强的结果数据。

• 应用层：用来沉淀比较个性应用的数据挖掘结果指标。

2、算法平台

• 算法中台的建设目的是从各种各样的挖掘场景中抽象出有代表性的几类场景，并形成相应的方法论和实操模板。

• 比较有代表性的数据挖掘应用场景：

欢迎点赞+收藏+转发朋友圈素质三连