《大数据之路：阿里巴巴大数据实践》：看阿里人从IT时代走向DT时代的经验之谈！_大数据之路 阿里巴巴大数据实践 感悟

最近一直在看《大数据之路：阿里巴巴大数据实践》一书，读完之后感觉受益良多。第一，对于整个大数据的体系有了更多且清晰的认知；第二，对于不同系统的逻辑处理方式给予了引导；第三，毕竟是阿里多年技术的累计产出，而且都是阿里技术大牛写的，干货相当多；最后，如果对于大数据方向想有更深入的了解，推荐大家阅读！

一直以来，我都对大数据真正的价值有思考。后来才发现，大、快、多样性只是表象，大数据的真正价值在于生命性和生态性。

阿里将这类数据称之为“活数据”：活数据是全本记录、实时驱动决策和迭代，它的价值是随着使用场景和方式动态变化的，不可估量。

二、阿里巴巴大数据系统体系架构

首先是一张镇楼图，阿里巴巴的大数据系统的体系架构图，划分为数据采集、数据计算、数据服务及数据应用四层，后面的内容就是围绕这张图展开的，技术含量有多高，大家都懂的，如果读到后面迷失了，可以重新回过头来理解这张图。

数据计算分层：操作数据层、明细数据层、汇总数据层和应用数据层。通过数据仓库不同层次之间的加工过程实现从数据资产向信息资产的转化，并对整个过程进行有效的元数据管理及数据质量处理。

三、数据采集

阿里巴巴的日志采集体系方案包括两大体系：Aplus.JS是Web端日志采集技术方案 ；UserTrack是APP端的日志采集方案。 大多传统公司由于长期经营线下，对于Web，APP等的主动采集能力是偏弱的，一般数据管理部门对于Web或APP端的采集基本是源端推送过来的文件，对于采集没有实际主导权，内容丰富程度大打折扣，同时无论是Web的JS脚本还是APP的SDK,实际上都是有一定的技术门槛，企业APP源端由于受限于合作伙伴的能力，往往采集能力不够，数据质量参差不齐。

互联网源端的日志留存，到底哪些是源端本身的要求，哪些是大数据管理的要求，需要想清楚，大数据管理部门如果想获得更好的数据，是否考虑要往前走一步，毕竟OLAP和OLTP对待数据的角度不一样，人家没必要为你留你所需要的数据。

企业的大数据能否适应互联网的新的形式，打破条线分割，在常规的数据库、文本、消息等采集基础上，新增线上的主动采集工具，是巨大的挑战。当前一些企业提供的企业级大数据采集工具，是缺了这条腿的，以后企业往线上走，这个PaaS能力的确是要具备的。

在采集技术的基础上，阿里巴巴用面向各个场景的埋点规范，来满足通用浏览、点击、特殊交互、APP事件、H5及APP里的H5和Native日志数据打通等多种业务场景。

3.1 浏览器的页面日志采集

3.1.1 页面浏览日志采集

1. 在HTML文档内的适当位置增加一个日子采集节点，但浏览器解析到这个节点时，将自动触发一个特定的HTTP请求到日志采集服务器。
2. 植入采集脚本的动作可以由服务器在相应业务请求时动态执行，也可以在开发页面时由开发人员手动植入。
3. 采集到日志后大多会立刻将日志发送到日志采集服务器，服务器立即返回成功响应，并将日志存储到日志缓存区。
4. 顺序读取日志并处理，转存成标准日志文件，加入到实时消息通道供后端程序读取和进一步处理。

3.1.2 页面交互日志采集

交互日志因为页面类型的不同，无法规定统一的采集内容，故以技术服务的形式采集交互日志。

由业务方注册要采集好交互日志的业务、业务场景和场景下具体的采集点，由系统自动生成采集日志的代码模板。

3.1.3 服务器端数据清洗和预处理

• 识别流量攻击、网络爬虫和虚假流量
• 数据缺项补正
• 剔除无效数据
• 基于数据安全和业务特性的日志隔离分发

3.2 无线客户端的日志采集

无线客户端的日志采集采用采集 SOK 来完成，在阿里巴巴内部，多使用名为 UserTrac 来进行无线客户端的日志采集。

“事件”为无线客户端日志行为的最小单位。基于常规的分析， UserTrack (UT ）把事件分成了几类，常用的包括页面事件（同前述的页面浏览）和控件点击事件（同前述的页面交互）等。

3.3 日志采集的挑战

3.3.1 日志分流与定制处理

PV日志的请求位置（URL）是随着页面所在业务类型的不同而变化的。不仅考虑日志服务器端的分布计算方案，而且将分类任务前置到客户端。

3.3.2 采集与计算一体化

以URL的正则集来对日志进行分类会随着日志复杂度的增长榨干硬件集群。由用户自己制定需要采集的页面，系统自动对页面采集的来的日志进行计算。

3.3.3 大促保障

日志数据在阿里系乃至整个电商系应该都是体量最大的一类数据，在“双 11”期间，日志必然会暴涨，近万亿的数据量对日志全链路说，无疑是不小的挑战。

从端上埋点采集，到日志服务器收集，经过数据传输，再到日志时解析、实时分析，任何一个环节出现问题，全链路保障就是失败的。考虑到服务器的收集能力（如峰值QPS等）、数据传输能力（ TT 的搬运速度）、实时解析的吞吐量、实时业务分析的处理能力，阿里在各环节都做了不少的工作。

四、数据同步

对于大数据系统来说，包含数据从业务系统同步进入数据仓库和数据从数据仓库同步进入数据服务或数据应用两个方面。

源业务系统的数据类型多种多样，有来源于关系型数据库的结构化数据，如 MySQL Orac le DB2, SQL Server ：也有来源于非关系型数据库的非结构化数据，如 Ocean Base HBase Mongo DB 等，这类数据通常存储在数据库表中：还有来源于文件系统的结构化或非结构化据，如阿里云对象存储 oss 、文件存储 NAS 等，这类数据通常以文件形式进行存储。

数据同步需要针对不同的数据类型及业务场景选择不同的同步方式。总的来说，同步方式可以分为三种：

• 直连同步 数据直抽