《大数据之路：阿里巴巴大数据实践》系列丛书

第1章 总述

第1篇 数据技术篇
      第2章 日志釆集
      第3章 数据同步
      第4章 离线数据开发
      第5章 实时技术
      第6章 数据服务
      第7章 数据挖掘
第2篇 数据模型篇
      第8章 大数据领域建模综述
      第9章 阿里巴巴数据整合及管理体系
      第10章 维度设计
      第11章事实表设计
第3篇数据管理篇
      第12章 元数据
      第13章 计算管理
      第14章 存储和成本管理
      第15章 数据质量
第4篇数据应用篇
      第16章 数据应用

第2章 日志采集

      数据采集作为阿里大数据系统体系的第一环尤为重要。因此阿里巴 巴建立了一套标准的数据釆集体系方案，致力全面、高性能、规范地完 成海量数据的釆集，并将其传输到大数据平台。本章主要介绍数据采集 中的日志釆集部分。
      阿里巴巴的日志采集体系方案包括两大体系：Aplus.JS是Web端 （基于浏览器）日志釆集技术方案；UserTrack是APP端（无线客户端） 日志釆集技术方案。
       本章从浏览器的页面日志采集、无线客户端的日志釆集以及我们遇 到的日志采集挑战三块内容来阐述阿里巴巴的日志采集经验。

2.1浏览器的页面日志采集

       浏览器的页面型产品/服务的日志采集可分为如下两大类。

1. 页面浏览（展现）日志采集。顾名思义，页面浏览日志是指当 一个页面被浏览器加载呈现时采集的日志。此类日志是最基础的互联网 日志，也是目前所有互联网产品的两大基本指标：页面浏览量(PageView, PV)和访客数(Unique Visitors, UV)的统计基础。页面浏览日 志是目前成熟度和完备度最高，同时也是最具挑战性的日志采集任务， 我们将重点讲述此类日志的采集。
2. 页面交互日志采集。当页面加载和渲染完成之后，用户可以在页面上执行各类操作。随着互联网前端技术的不断发展，用户可在浏览 器内与网页进行的互动已经丰富到只有想不到没有做不到的程度，互动设计都要求采集用户的互动行为数据，以便通过量化获知用户的兴趣点 或者体验优化点。交互日志釆集就是为此类业务场景而生的。

       除此之外，还有一些专门针对某些特定统计场合的日志釆集需求， 如专门采集特定媒体在页面被曝光状态的曝光日志、用户在线状态的实 时监测等，但在基本原理上都脱胎于上述两大类。限于篇幅，此内容在 本书中就不予展开介绍了。

2.1.1页面浏览日志采集流程

      网站页面是互联网服务的基本载体，即使在如今传统互联网形态逐 渐让位于移动互联网的背景下，HTML页面依旧是最普遍的业务形态, 对于以网页为基本展现形式的互联网产品和服务，衡量其业务水平的基 本指标是网页浏览量(PV)和访客数(UV)。为此，我们需要采集页 面被浏览器加载展现的记录，这是最原始的互联网日志采集需求，也是 一切互联网数据分析得以展开的基础和前提。
      目前典型的网页访问过程是以浏览器请求、服务器响应并返回所请 求的内容(大多以HTML文档的形式)这种模式进行的，浏览器和服 务器之间的通信普遍遵守HTTP协议(超文本传输协议，目前以HTTP 1.1为主，逐渐向最新的HTTP 2.0过渡)。浏览器发起的请求被称为HTTP 请求(HTTP Request) Response)。
      我们以用户访问淘宝首页(www.taobao.com)为例，一次典型的页 面访问过程描述如图2.1所示。

      (1)用户在浏览器内点击淘宝首页链接(或在地址栏中输入 www.taobao.com 并回车)。
      (2)浏览器向淘宝服务器发起HTTP请求。在本例子中，用户可以 看见的内容只是显示于浏览器地址栏内的http://www.taobao.com,而浏 览器在执行时，会解析用户请求并按照HTTP协议中约定的格式将其转 化为一个HTTP请求发送出去。
      按照HTTP协议，一个标准的HTTP请求由如下三部分构成。

• 请求行(HTTP Request Line)。请求行内有三个要素，分别是请 求方法、所请求资源的URL以及HTTP协议版本号。在本例子 中，这三个要素分别是GET、http://www.taobao.com/以及HTTP 1.1,对于我们所讨论的话题，记住请求行内最重要的信息是这 个URL就可以了。
• 请求报头(HTTP Message Header)。请求报头是浏览器在请求时 向服务器提交的附加信息，请求报头一般会附加很多内容项(每 项内容被称为一个头域(Header Field)，在不引起混淆的情况下， 往往将Header Field简称为Header)。需要注意的是，如果用户 在本次页面访问之前已经到访过网站或者已经登录，则一般都会 在请求头中附加一个或多个被称为Cookie的数据项，其中记录 了用户上一次访问时的状态或者身份信息，我们只需理解浏览器 在发起请求时会带上一个标明用户身份的Cookie即可。
• 请求正文(HTTP Message Body) 0这一部分是可选的，一般而言， HTTP请求的正文都是空的，可以忽略。
        (3)服务器接收并解析请求。服务器端的业务处理模块按业务逻辑
  处理本次请求并按照HTTP协议规定的格式，将处理结果以HTTP响应 形式发回浏览器。

      与HTTP请求相对应，一个标准的HTTP响应也由三部分构成。

• 状态行。状态行标识了服务器对于此次HTTP请求的处理结果。 状态行内的主要内容是一个由三位数字构成的状态码，我们最熟 知的两个状态码分别是代表成功响应的200 (OK)和代表所请 求的资源在服务器端没有被找到的404 (Not Found)
• 响应报头。服务器在执行响应时，同样可以附加一些数据项，这 些数据项将在浏览器端被读取和使用。事实上，在大多数页面和 应用中，响应报头内的内容在确保页面正确显示和业务正常进行 方面都发挥着至关重要的作用。其中最重要的一类Header即上 面所提到的Cookie,浏览器所记录的Cookie,其实是由服务器 在响应报头内指令浏览器记录的。举个例子，如果用户在页面登 录，则服务器会在登录请求的响应报头内指示浏览器新增一个名
  为userid的Cookie项，其中记录了登录用户的id。如此一来， 当用户随后再次访问该网站时，浏览器将自动在请求报头内附加 这个Cookie,服务器由此即可得知本次请求对应的用户到底是 谁，如果服务器发现浏览器在请求时传递过来的Cookie有缺失、 错误或者需要更新，则会在响应报头内指令浏览器增加或更新对 应的 Cookie。
• 响应正文。和请求正文一样，这一部分在协议中也被定义为可选 部分，但对于大多数HTTP响应而言，这一部分都是非空的，浏 览器请求的文档、图片、脚本等，其实就是被包装在正文内返回 浏览器的。在本例子中，服务器会将淘宝首页对应的HTML文 档封装在正文内。

      (4)浏览器接收到服务器的响应内容，并将其按照文档规范展现给 用户，从而完成一次请求。在本例子中，浏览器请求淘宝首页，服务器 返回对应的HTML文档，浏览器即按照HTML文档规范解析文档并将 整个页面渲染在屏幕上。
      上面描述了一次典型的网页浏览过程，如果需要记录这次浏览行 为，则釆集日志的动作必然是附加在上述四个步骤中的某一环节内完成 的。在第一步和第二步，用户的请求尚未抵达服务器；而直到第三步完 成，我们也只能认为服务器处理了请求，不能保证浏览器能够正确地解 析和渲染页面，尚不能确保用户已确实打开页面，因此在前三步是无法 采集用户的浏览日志的。那么采集日志的动作，需要在第四步，也就是 浏览器开始解析文档时才能进行。根据前文所述，可以很自然地得出在 这一模式下最直接的日志采集思路：在HTML文档内的适当位置增加 一个日志釆集节点，当浏览器解析到这个节点时，将自动触发一个特定 的HTTP请求到日志采集服务器。如此一来，当日志采集服务器接收到 这个请求时，就可以确定浏览器已经成功地接收和打开了页面。这就是 目前几乎所有互联网网站页面浏览日志采集的基本原理，而业界的各类 网页日志采集的解决方案只是在实施的细节、自动釆集内容的广度以及 部署的便利性上有所不同。
      目前阿里巴巴采用的页面浏览日志采集方案的流程框架如图2.2所 示。在图2.2所示的页面浏览日志采集过程中，所涉及的日志相关的几 个主要过程简单介绍如下：

1. 客户端日志釆集。日志采集工作一般由一小段被植入页面 HTML文档内的JavaScript脚本来执行。采集脚本被浏览器加载解析后执行，在执行时釆集当前页面参数、浏览行为的上下文信息（如读取用户访问当前页面时的上一步页面）以及一些运行环境信息（如当前的浏览器和分辨率等）。在HTML文档内植入日志采集脚本的动作可以由业务服务器在响应业务请求时动态执行，也可以在开发页面时由开发人员手动植入。在阿里巴巴，这两种方式均有采用，其中前一种方式的占比较高，这一点与业界的普遍状况有所不同。图2.2中的第三、四步描述 了阿里业务服务器端植入日志采集脚本的过程。

2. 客户端日志发送。采集脚本执行时，会向日志服务器发起一个日志请求，以将采集到的数据送到日志服务器。在大多数情况下，采 集完成之后会立即执行发送，但在个别场景下，日志采集之后可能会经过一段时间的延迟才被发出。日志采集和发送模块一般会集成在同一个
   JavaScript脚本文件内，且通过互联网浏览器必然支持的HTTP协议与日志服务器通信，采集到的日志信息一般以URL参数形式放在HTTP 日志请求的请求行内。
3. 服务器端日志收集。日志服务器接收到客户端发来的日志请求后，一般会立即向浏览器发回一个请求成功的响应，以免对页面的正常 加载造成影响；同时，日志服务器的日志收集模块会将日志请求内容写入一个日志缓冲区内，完成此条浏览日志的收集。
4. 服务器端日志解析存档。服务器接收到的浏览日志进入缓冲区 后，会被一段专门的日志处理程序顺序读出并按照约定的日志处理逻辑 解析。由日志采集脚本记录在日志请求行内的参数，将在这个环节被解析（有时候伴随着转义和解码）出来，转存入标准的日志文件中并注入 实时消息通道内供其他后端程序读取和进一步加工处理。

      经过采集一发送一收集一解析存档四个步骤，我们将一次页面浏览 日志成功地记录下来。可见，除了采集代码在某些场合下需要手动植入 之外，整个过程基本都是依照HTML规范和HTTP协议自动进行的， 这种依赖协议和规范自动运行的采集机制最大限度地减少了人工干预 的扰动，进而保证了日志的准确性。
      阿里巴巴的页面浏览日志采集框架，不仅指定了上述的釆集技术方 案，同时也规定了 PV H志的采集标准规范，其中规定了 PV 0志应采 集和可采集的数据项，并对数据格式做了规定。这些格式化日志，为后 续的日志加工和计算得以顺利开展打下了基础。

2.1.2页面交互日志采集

      pv日志的采集解决了页面流量和流量来源统计的问题，但随着互 联网业务的发展，仅了解用户到访过的页面和访问路径，已经远远不能 满足用户细分研究的需求。在很多场合下，需要了解用户在访问某个页 面时具体的互动行为特征，比如鼠标或输入焦点的移动变化（代表用户 关注内容的变化）、对某些页面交互的反应（可借此判断用户是否对某 些页面元素发生认知困难）等。因为这些行为往往并不触发浏览器加载 新页面，所以无法通过常规的PV H志釆集方法来收集。在阿里巴巴， 通过一套名为“黄金令箭”的采集方案来解决交互日志的采集问题。
      因为终端类型、页面内容、交互方式和用户实际行为的千变万化不 可预估，交互日志的采集和PV H志的采集不同，无法规定统一的采集 内容（例如，活动页面的游戏交互和淘宝购物车页面的功能交互两者相 比，所需记录的行为类型、行为数据以及数据的结构化程度都截然不 同），呈现出高度自定义的业务特征。与之相适应，在阿里巴巴的日志 采集实践中，交互日志的采集（即“黄金令箭”）是以技术服务的形式 呈现的。
具体而言，“黄金令箭”是一个开放的基于HTTP协议的日志服务， 需要采集交互日志的业务（下文简称“业务方”），经过如下步骤即可将 自助釆集的交互日志发送到日志服务器。

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

      经过上述步骤采集到日志服务器的业务随后可被业务方按需自行 解析处理，并可与正常的PV 0志做关联运算。

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

      上面介绍了阿里巴巴的两类浏览器页面日志的釆集方案，并粗略介 绍了日志到达日志服务器之后的解析处理。但在大部分场合下，经过上 述解析处理之后的日志并不直接提供给下游使用。基于如下几个原因， 在对时效要求较宽松的应用场合下，一般还需要进行相应的离线预处理。

1. 识别流量攻击、网络爬虫和流量作弊(虚假流量)。 页面日志 是互联网分析和大数据应用的基础源数据，在实际应用中，往往存在占 一定比例的虚假或者恶意流量日志，导致日志相关指标的统计发生偏差或明显谬误。为此，需要对所采集的日志进行合法性校验，依托算法识 别非正常的流量并归纳出对应的过滤规则集加以滤除。这是一个长期而艰苦的对抗过程。
2. 数据缺项补正。 为了便利后续的日志应用和保证基本的数据统 计口径一致，在大多数情况下，需要对日志中的一些公用且重要的数据项做取值归一、标准化处理或反向补正。反向补正，即根据新日志对稍 早收集的日志中的个别数据项做回补或修订(例如，在用户登录后，对登录前页面日志做身份信息的回补)。
3. 无效数据剔除。 在某些情况下，因业务变更或配置不当，在釆 集到的日志中会存在一些无意义、已经失效或者冗余的数据项。这些数据项不仅消耗存储空间和运算能力，而且在偶然的情况下还可能干扰正 常计算的进行。为了避免此类异常的发生，需要定时检查配置并依照配置将此类数据项剔除。
4. 日志隔离分发。 基于数据安全或者业务特性的考虑，某些日志 在进入公共数据环境之前需要做隔离。 原始日志经过上述的清洗、修正，并结构化变形处理之后，Web页面日志的釆集流程就算完成了。此时的日志已经具备了结构化或者半 结构化的特征，可以方便地被关系型数据库装载和使用。

2.2无线客户端的日志采集

      众所周知，日志采集多是为了进行后续的数据分析。移动端的数据 采集，一是为了服务于开发者，协助开发者分析各类设备信息；二是为 了帮助各APP更好地了解自己的用户，了解用户在APP上的各类行为, 帮助各应用不断进行优化，提升用户体验。
      无线客户端的日志采集采用采集SDK来完成，在阿里巴巴内部， 多使用名为UserTrack的SDK来进行无线客户端的日志采集。无线客 户端的日志采集和浏览器的日志采集方式有所不同，移动端的日志釆集 根据不同的用户行为分成不同的事件，“事件”为无线客户端日志行为 的最小单位。基于常规的分析，UserTrack (UT)把事件分成了几类， 常用的包括页面事件(同前述的页面浏览)和控件点击事件(同前述的 页面交互)等。
      对事件进行分类的原因，除了不同事件的日志触发时机、日志内容 和实现方式有差异之外，另一方面是为了更好地完成数据分析。在常见 的业务分析中，往往较多地涉及某类事件，而非全部事件，故为了降低后续处理的复杂性，对事件进行分类尤为重要。要更好地进行日志数据 分析，涉及很多方面的内容，如需要处理Hybrid应用，实现H5和Native 日志的统一；又如识别设备，保证同一设备上各应用获取到的设备信息 是唯一的。除此之外，对于采集到的数据如何上传，以及后续又如何合 理处理等，每个过程都值得我们进行深入的研究和探索。

2.2.1页面事件

      从实现方法上说，日志采集SDK对于不同事件的实现，大致是类 似的，只是对于通用的用户行为，抽象出来一些通用的接口方法。我们 把常用的行为类别单独列出来，作为单独的事件来处理，如本节要讲的 页面事件（页面浏览行为）。每条页面事件日志记录三类信息：①设备 及用户的基本信息；②被访问页面的信息，这里主要是一些业务参数（如 商品详情页的商品ID、所属的店铺等）；③访问基本路径（如页面来源、 来源的来源等），用于还原用户完整的访问行为。
      对于页面事件，不同的SDK有不同的实现，有些采集SDK选择在 页面创建时即发送日志。结合业务分析，UT提供了页面事件的无痕埋 点，即无须开发者进行任何编码即可实现。限于篇幅，本处主要讲一下 手动模式的埋点。UT提供了两个接口，分别在页面展现和页面退出时 调用。以进入手机淘宝的某店铺详情页来举例，当进入该店铺详情页时, 调用页面展现的接口，该接口会记录页面进入时的一些状态信息，但此 时不发送日志，当从该店铺详情页离开时（可能是在店铺详情页上点击 某个商品到了对应的商品详情页，也可能是退出了手机淘宝，抑或是点 击返回，返回到了之前的一个页面），调用页面退出的接口，该接口会 发送日志。除了基础的两个接口外，还提供了添加页面扩展信息的接口； 在页面离开前，使用该接口提供的方法给页面添加相关参数，比如给店 铺详情页添加店铺ID、店铺类别（天猫店铺或淘宝店铺）等。
      显然，上述三个接口方法必须配合使用，即页面展现和页面退出方 法必须成对使用，而页面扩展信息的接口必须在使用页面展现和页面退 出方法的前提下使用。再来说说，为什么不在页面进入时就发送日志， 而是在页面离开时才发送日志呢？可以思考一下：基于浏览器的日志采 集，在每次页面进入时就实现采集日志的发送，每个页面停留时长的计 算一直困扰着分析师；而无线客户端的日志采集，在页面离开时发送日 志，此时页面停留时长就是天然自带的准确值了。还可以进一步思考， 还有什么其他的优势呢？
      上述三个方法是采集SDK提供的页面事件采集的基础方法；除此 之外，为了平衡采集、计算和分析的成本，在部分场景下我们选择采集 更多的信息来减少计算及分析的成本。于是，UT提供了透传参数功能。 所谓透传参数，即把当前页面的某些信息，传递到下一个页面甚至下下 一个页面的日志中。举个例子，在手机淘宝首页搜索“连衣裙”，进入 搜索list页面，然后点击某个商品进入商品A详情页。如果需要分析“连 衣裙”这个关键词，或者商品A的来源搜索词，此时就需要把“连衣 裙”这个关键词带入到搜索list页面日志、商品A详情页日志中，这样 一来，分析搜索词的效果就显而易见了。在阿里系内，使用SPM （Super Position Model,超级位置模型）进行来源去向的追踪，在无线客户端 也同样使用SPM, SPM信息就可以通过透传机制带入到下一步甚至下 下一步的浏览页面，这样整个用户行为路径还原就轻松实现了。

2.2.2控件点击及其他事件

      为了和基于浏览器客户端的日志采集做比较，我们暂且把除了页面 事件外的各类事件放到一起来讲。
      和浏览器客户端的日志采集一样，交互日志的采集无法规定统一的 采集内容，交互类的行为呈现出高度自定义的业务特征。与之相适应， 在阿里巴巴的无线客户端日志采集实践中，将交互日志采集从页面事件 采集中剥离出来，这就是控件点击事件和其他事件。
      先来说说控件点击事件。控件点击事件比页面事件要简单得多，首 先，它和页面事件一样，记录了基本的设备信息、用户信息；其次，它 记录了控件所在页面名称、控件名称、控件的业务参数等。由于控件点 击事件的逻辑简单得多，就是操作页面上的某个控件，因此只需把相关 基础信息告诉采集SDK即可。
      再来说说其他事件。所谓其他事件，就是用户可以根据业务场景需 求，使用自定义事件来采集相关信息。从某种程度上说，它几乎能满足 用户的所有需求，包括页面事件和控件点击事件，只是若采用通用的页 面事件埋点方法，UT会帮助实现一些额外的功能（如上个页面的信息）。 UT提供了一个自定义埋点类，其包括：①事件名称；②事件时长，③事 件所携带的属性；④事件对应的页面。当然，具体实现什么功能，需要 带哪些内容，各个采集SDK可以自行决定。
      除了上述这些需要应用开发者触发的日志采集接口方法外，UT还 提供了一些默认的日志采集方法，比如可以自动捕获应用崩溃，并且产 生一条日志记录崩溃相关信息。类似的日志采集方法还有很多，比如应 用的退出、页面的前后台切换等。诸如一些和业务信息不是非常相关， 但又对分析起很大作用的日志釆集，就完全没有必要让应用开发者去触 发埋点了。

2.2.3特殊场景

      上述场景均为一个行为产生一条日志，如一次浏览、一次点击等。 如此用来处理普通的业务是足够的，但对于阿里巴巴巨大的业务体量来 说，为了平衡日志大小，减小流量消耗、采集服务器压力、网络传输压 力等，采集SDK提供了聚合功能，对某些场景如曝光或一些性能技术 类日志，我们提倡在客户端对这类日志进行适当聚合，以减少对日志采 集服务器端的请求，适当减小日志大小。总体思路就是每个曝光的元素 一般都属于一个页面，利用页面的生命周期来实现适当的聚合及确定发 送时机。拿曝光日志来举例，若一个商品的一次曝光就对应一条日志的 话，那么在搜索结果页的一次滚屏浏览过程中将产生几十条甚至上百条 日志，从下游使用及分析的角度来说，其实只是想知道哪些内容被曝光, 此时为了平衡业务需求及减少全链路资源消耗，釆集SDK提供了本地 聚合功能，在客户端对这类日志进行聚合，上传聚合后的日志到采集服 务器即可。同时对于一些只需要计数，而不需要知道具体内容的场景， 如需要分析某些接口的调用次数，此功能就更加凸显出其作用了。
      区别于浏览器的页面访问，在无线客户端用户的访问行为路径存在 明显的回退行为（如点击回退按钮、各种滑屏等），在进行业务分析时, 回退同样作为特殊场景而存在。例如，“双11”主会场页T女装分会场 ―女装店铺A-回退到女装分会场一女装店铺B,在这个访问路径中， 若只是按照普通的路径来处理，则会认为第二次浏览的女装分会场来源 为店铺A,就会把女装分会场的一次浏览效果记为女装店铺A带来的。 倘若这样处理，就会发现类似的活动承接页其来源有一大部分均为各类 详情页（店铺详情页/商品详情页），这必然干扰到分析。所以针对这种 场景，我们做了特殊的设计，利用页面的生命周期，识别页面的复用， 配合栈的深度来识别是否是回退行为。
      如上列举了两个比较典型的特殊场景，随着业务的不断发展，业务 的复杂性不断提高，采集需要处理的特殊场景也层出不穷，限于篇幅， 此处不再一一展开介绍。

2.2.4 H5& Native 日志统一

      简单来说，APP分为两种：一种是纯Native APP；—种是既有Native, 又有H5页面嵌入的APP,即Hybrid APPO当前，纯Native APP已经非 常少了，一般都是Hybrid APPO Native页面采用采集SDK进行日志釆 集，H5页面一般采用基于浏览器的页面日志釆集方式进行采集。在当 前的实践中，由于采集方式的不同，釆集到的内容及采集服务器均分离 开。若需要进行完整的数据分析，就需要将两类日志在数据处理时进行 关联，而就算不考虑处理成本，在很多情况下，Native和H5互跳，即 使关联也无法还原用户路径，数据丢失严重。对于产品经理以及运营、 管理、数据分析人员而言，在不同的终端采用不同的方案采集日志，以 不同的算法来做日志统计，忍受多端之间的数据隔离，并对由此导致的 多样数据口径进行整理分析和解释，已经是越来越不能容忍的切身之 痛。考虑到后续日志数据处理的便捷性、计算成本、数据的合理性及准 确性，我们需要对Native和H5日志进行统一处理（见图2.3）0

      要想实现Native和H5日志的统一处理，就需要对Hybrid日志有 统一的方案。简单的思路就是首先将两类日志进行归一。用什么方式把 两类日志归一呢？是把Native日志向H5日志归，还是把H5日志归到 Native日志呢？其实两条路均可以实现，没有绝对的答案。选择时可以 自行斟酌，在阿里巴巴集团，分别考虑两条路的优缺点，考虑到两种日 志釆集方式的特点以及关注点，我们选择Native部署采集SDK的方式。
      原因有二：一是釆用釆集SDK可以采集到更多的设备相关数据， 这在移动端的数据分析中尤为重要；二是采集SDK处理日志，会先在 本地缓存，而后借机上传，在网络状况不佳时延迟上报，保证数据不丢 失。基于这两点，我们选择将H5日志归到Native日志。
具体的流程如下：

1.  H5页面浏览和页面交互的数据，在执行时通过加载日志釆集 的JavaScript脚本，采集当前页面参数，包括浏览行为的上下文信息以 及一些运行环境信息。在APP中打开H5页面和在浏览器中的处理完全 一样，在前端页面的开发中无须做任何特殊的处理，只需在页面开发时 手动植入日志采集的JavaScript脚本即可。
2. 在浏览器日志采集的JavaScript脚本中实现将所釆集的数据打 包到一个对象中，然后调用WebView框架的JSBridge接口，调用移动 客户端对应的接口方法，将埋点数据对象当作参数传入。
3. 移动客户端日志采集SDK,封装提供接口，实现将传入的内 容转换成移动客户端日志格式。采集SDK会根据日志类别来识别是页 面浏览事件，还是控件点击事件，然后调用内部相应的接口进行处理，将埋点数据转换成移动客户端日志的统一格式。而后就同移动客户端的 日志处理一样，先记录到本地日志缓存中，择机上传。通过日志类别的识别来做不同的日志格式转换，这样，未来如果要实现新的事件类别，比如自定义事件，就不需要改动WebView层的接口，只需改动JavaScript 的部分内容及移动客户端日志采集SDK中对应的实现即可。

  基于这种统一的方案，为后续构建完整的用户行为路径还原树打下 了基础。当然，此方案也有其局限性，必须要浏览器釆集JavaScript, WebView,客户端采集SDK的配合。而往往很多时候业务并不希望做任 何调整，更多的是希望减少依赖，所以在这方面我们也在寻求新的突破。

2.2.5设备标识

  正如本章开头所说的，所有互联网产品的两大基本指标是页面浏览 量(Page View, PV)和访客数(Unique Visitors, UV)。关于 UV,对 于登录用户，可以使用用户ID来进行唯一标识，但是很多日志行为并 不要求用户登录，这就导致在很多情况下采集上来的日志都没有用户 ID。PC端一般使用Cookie信息来作为设备的唯一信息，对于APP来 说，我们就要想办法获取到能够唯一标识设备的信息。
  历史上，MEI、IMSI、MAC、苹果禁用之前的UDID,曾经都可以 用，如果它们之中有一个是靠谱的话，那么设备唯一标识就简单了。但 事实上，随着用户的自我保护意识加强以及各系统升级，很多基本的设 备信息获取都不再那么容易。苹果UDID禁用，IDFA, IMEI、IMSI做 了权限控制，Android新系统也对设备信息的获取做了权限控制。
  对于只有单APP的公司来说，设备唯一标识不是需要攻克的难题, 但对于像阿里巴巴这样拥有众多APP的公司来说，设备唯一标识就显得尤为重要。阿里巴巴集团无线设备唯一标识使用UTDID,它当然有 很清晰的责任和目标，就是每台设备一个ID作为唯一标识。UTDID随 着iOS和Android系统对权限控制的不断升级，对方案做了多次调整， 包括存储方式、存储位置、共享方式等，以及和服务器端的配合，其生 成方式也使用一套较完备的算法。但就目前的进展来说，UTDID还未 完全实现其使命。在这方面，欢迎有思路、有想法的读者和我们联系。

2.2.6日志传输

  在上面的章节中大概讲述了如何从无线客户端釆集日志，本节将简 单介绍一下无线客户端日志的上传、压缩及传输的特殊性。
  无线客户端日志的上传，不是产生一条日志上传一条，而是无线客 户端产生日志后，先存储在客户端本地，然后再伺机上传。所谓伺机， 就需要有数据分析的支持，如在启动后、使用过程中、切换到后台时这 些场景下分别多久触发一次上传动作。当然单纯地靠间隔时间来决定上 传动作是不够的，还需要考虑日志的大小及合理性（如单条日志超大， 很可能就是错误日志）。另外，还需要考虑上传时网络的耗时，来决定 是否要调整上传机制。
  客户端数据上传时是向服务器发送POST请求，服务器端处理上传 请求，对请求进行相关校验，将数据追加到本地文件中进行存储，存储 方式使用Nginx的access Jog, accessjog的切分维度为天，即当天接 收的日志存储到当天的日志文件中。考虑到后续的数据处理，以及特殊 时期不同日志的保障级别，还对日志进行了分流。比如阿里巴巴集团的 Adash （无线日志服务器端处理程序），根据应用及事件类型对每日高达 数千亿的日志进行了分流。分流的好处显而易见，如“双11”时，日 常数千亿的日志可能冲高到万亿，此时服务器及后续的数据计算压力就 非常大了；而对于重要的数据计算来说，很可能只需要页面事件及控件 点击事件即可，此时就可以适当地释放其他类型日志的资源来处理更重 要的页面事件及控件点击事件。
  从客户端用户行为，到日志采集服务器的日志，整个日志采集的过 程就算结束了。那么日志采集服务器的日志怎么给到下游呢？方法有很 多，阿里巴巴集团主要使用消息队列（TimeTunel, TT）来实现从日志 采集服务器到数据计算的MaxCompute。简单来讲，就是TT将消息收 集功能部署到日志釆集服务器上进行消息的收集，而后续的应用可以是 实时的应用实时来订阅TT收集到的消息，进行实时计算，也可以是离 线的应用定时来获取消息，完成离线的计算。有关消息队列，以及日志 数据的统计计算等细节内容，将在后续章节中进行详细讲述。

2.3日志采集的挑战

  对于目前的互联网行业而言，互联网日志早已跨越初级的饥饿阶段 （大型互联网企业的日均日志收集量均以亿为单位计量），反而面临海量 日志的淹没风险。各类采集方案提供者所面临的主要挑战已不是日志采 集技术本身，而是如何实现日志数据的结构化和规范化组织，实现更为 高效的下游统计计算，提供符合业务特性的数据展现，以及为算法提供 更便捷、灵活的支持等方面。

2.3.1典型场景

  这里介绍两个最典型的场景和阿里巴巴所采用的解决方案。

• 日志分流与定制处理

  大型互联网网站的日志类型和日志规模都呈现岀高速增长的态势， 而且往往会出现短时间的流量热点爆发。这一特点，使得在日志服务器 端采用集中统一的解析处理方案变得不可能，其要求在日志解析和处理 过程中必须考虑业务分流（相互之间不应存在明显的影响，爆发热点不 应干扰定常业务日志的处理）、日志优先级控制，以及根据业务特点实 现定制处理。例如，对于电商网站而言，数据分析人员对位于点击流前T 端的促销页面和位于后端的商品页面的关注点是不一样的，而这两类页 面的流量又往往同等重要且庞大，如果采用统一的解析处理方案，则往 往需要在资源浪费（尽可能多地进行预处理）和需求覆盖不全（仅对最 重要的内容进行预处理）两个选择之间进行取舍。这种取舍的结果一般 不是最优的。
  考虑到阿里日志体量的规模和复杂度，分治策略从一开始便是阿里 互联网日志采集体系的基本原则。这里以PV日志釆集领域一个最浅显 的例子来说明，与业界通用的第三方日志采集方案的日志请求路径几乎 归一不同，阿里PV H志的请求位置（URL）是随着页面所在业务类型 的不同而变化的。通过尽可能靠前地布置路由差异，就可以尽可能早地 进行分流，降低日志处理过程中的分支判断消耗，并作为后续的计算资 源调配的前提，提高资源利用效率。与业界方案的普遍情况相比，阿里 的客户端日志采集代码的一个突出特点是实现了非常高的更新频次（业 界大多以季度乃至年为单位更新代码，阿里则是以周/月为单位），并实 现了更新的配置化。我们不仅考虑诸如日志分流处理之类的日志服务器 端分布计算方案，而且将分类任务前置到客户端（从某种程度上讲，这 才是真正的“分布式”！）以实现整个系统的效能最大化。最后可以在计 算后端几乎无感知的情况下，承载更大的业务量并保证处理质量和效率。

• 采集与计算一体化设计

  以PV日志为例，页面PV日志采集之后一个基础性操作是日志的 归类与汇总。在早期的互联网日志分析实践中，是以URL路径，继而 以URL （正则）规则集为依托来进行日志分类的。在网站规模较小时， 这一策略还可以基本顺利地运转下去，但随着网站的大型化和开发人员 的增加，URL规则集的维护和使用成本会很快增长到不现实的程度， 同时失控的大规模正则适配甚至会将日志计算硬件集群彻底榨干。
  这一状况要求日志采集方案必须将采集与计算作为一个系统来考 量，进行一体化设计。阿里日志采集针对这一问题给岀的答案是两套日 志规范和与之对应的元数据中心。其中，对应于PV日志的解决方案是 目前用户可直观感知的SPM规范（例如，在页面的URL内可以看见spm 参数）和SPM元数据中心。通过SPM的注册和简单部署（仅需要在页 面文件内声明一个或多个标签），用户即可将任意的页面流量进行聚类， 不需要进行任何多余的配置就可以在相应的内部数据产品内查询聚合 统计得到的流量、转化漏斗、引导交易等数据，以及页面各元素点击数 据的可视化视图。对应于自定义日志的解决方案则是黄金令箭 （Goldlog） /APP端的点击或其他日志规范及其配置中心。通过注册一 个与所在页面完全独立的令箭实体/控件实体，用户可以一键获得对应 的埋点代码，并自动获得实时统计数据和与之对应的可视化视图。通过 简单的扩展配置，用户还可以自动获得自定义统计维度下的分量数据。
  在当前的互联网环境下，互联网日志的规模化采集方案必须具备一 个与终端设备的技术特点无关，具有高度扩展弹性和适应性，同时深入 契合应用需求的业务逻辑模型，并基于此制定对应的釆集规范交由产品 开发人员执行。若非如此，则不足以保障采集一解析一处理一应用整个 流程的通畅。目前阿里已成功实现规范制定一元数据注册一日志釆集一 自动化计算一可视化展现全流程的贯通。通过一体化设计，用户甚至可 以在不理解规范的前提下，通过操作向导式界面，实现日志采集规范的 自动落地和统计应用。日志本身不是日志釆集的目的，服务于基于日志 的后续应用，才是日志采集正确的着眼点。

2.3.2大促保障

  日志数据在阿里系乃至整个电商系应该都是体量最大的一类数据， 在“双11”期间，日志必然会暴涨，近万亿的数据量对日志全链路来 说，无疑是不小的挑战（见图2.4）o
从端上埋点采集，到日志服务器收集，经过数据传输，再到日志实 时解析、实时分析，任何一个环节岀现问题，全链路保障就是失败的。 考虑到服务器的收集能力（如峰值QPS等）、数据传输能力（TT的搬 运速度）、实时解析的吞吐量、实时业务分析的处理能力，我们在各环 节都做了不少的工作。