大数据之路读书笔记-02日志采集

大数据之路读书笔记-02日志采集

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

---

2.1 浏览器的页画日志采集

浏览器的页面型产品／服务的日志采集可分为如下两大类。
( 1 ）页面浏览（展现）日志采集。顾名思义，页面浏览日志是指一个页面被浏览器加载呈现时采集的日志。此类日志是最基础的互联网日志， 也是目前所有互联网产品的两大基本指标：页面浏览量（ PageView, PY ）和访客数（ Unique Visitors, UV ）的统计基础。页面浏览日志是目前成熟度和完备度最高 ，同时也是最具挑战性的日志来集任务，我们将重点讲述此类日志的采集。
(2 ）页面交互日志采集。当页面加载和渲染完成之后，用户可以在页面上执行各类操作。随着互联网前端技术的不断发展，用户可在浏览器内与网页进行的互动已经丰富到只有想不到没有做不到的程度，互动设计都要求采集用户的互动行为数据 ，以便通过量化获知用户的兴趣点或者体验优化点。交互日志采集就是为此类业务场景而生的。
除此之外，还有一些专门针对某些特定统计场合的日志采集需求，如专门采集特定媒体在页面被曝光状态的曝光日志、用户在线状态的实时监测等，但在基本原理上都脱胎于上述两大类。限于篇幅，此内容在本书中就不予展开介绍了。

2.1.1 页面浏览日志采集流程

网站页面是互联网服务的基本载体，即使在如今传统互联网形态逐渐让位于移动互联网的背景下 HTML 页面依旧是最普遍的业务形态，对于以网页为基本展现形式互联网产品和服务，衡量其业务水平的基本指标是网页浏览量 PV ）和访客数（ UV ）。为此，我们需要采集页面被浏览器加载展现的记录，这是最原始的互联网日志采集需求，也是一切互联网数据分析得以展开的基础和前提。
目前典型的网页访问过程是以浏览器请求、服务器响应并返回所请求的内容 （大 多以 HTML 文档的形式）这种模式进行的，浏览器和服务器之间的通信普遍遵守 HTTP 协议（超文本传输协议，目前以 HTTP1.1 为主，逐渐向最新的 HTTP 2.0 过渡）。浏览器发起的请求被称为HTTP 请求（ HTTP Request ），服务器的返回则被称为 HTTP 响应（ HTTPResponse）。
我们以用户访问向宝首页（ 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 ／以及 HTTP1.1 ，对于我们所讨论的话题，记住请求行内最重要的信息是这URL 就可以了。
请求报头（ HTTP Message Header ）。请求报头是浏览器在请求时向服务器提交的附加信息，请求报头一般会附加很多内容项（每项内容被称为一个头域（ Header Field ），在不引起混淆的情况下，往往将 Header Field 简称为 Header 。需要注意的是，如果用户在本次页面访问之前已经到访过网站或者已经登录，则一般都会在请求头中附加一个或多个被称为 Cookie 的数据项，其中记录了用户上一次访问时的状态或者身份信息，我们只需理解浏览器在发起请求时会带上一个标明用户身份的 Cookie 即可。
请求正文（ HTTP Message Body ）。这 部分是可选的，一般而言，HTTP 请求的正文都是空的，可以忽略。
(3 ）服务器接收并解析请求。服务器端的业务处理模块按业务逻辑处理本次请求并按照 HTTP 协议规定的格式，将处理结果以 HTTP形式发回浏览器。
与HTTP 请求相对应，一个标准的 HTTP 应也由三部分构成。
状态行。状态行标识了服务器对于此次 HTTP 请求的处理结果状态行内的主要内容是一个由三位数字构成的状态码，我们最熟知的两个状态码分别是代表成功响应的 200 (OK ）和代表所请求的资源在服务器端没有被找到的 404 (Not Found ）。
响应报头。服务器在执行响应时，同样可以附加一些数据项，这些数据项将在浏览器端被读取和使用。事实上，在大多数页面和应用中，响应报头内的内容在确保页面正确显示和业务正常进行方面都发挥着至关重要的作用。其中最重要的一类 Header 即上面所提到的 Cookie ，浏览器所记录的 Cookie ，其实是由服务器在响应报头内指令浏览器记录的。举个例子 ，如果用 户在页面登录，则服务器会在登录请求的响应报头内指示浏览器新增一个名use rid 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日志应采集和可采集的数据项，并对数据格式做了规定。这些格式化日志，为后续的日志加工和计算得以顺利开展打下了基础。

2.1.2 页面交互日志采集

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

具体而言，“黄金令箭”是一个开放的基于 HTTP 协议的日志服务，需要采集交互日志的业务（下文简称“业务方”），经过如下步骤即可将自助采集的交互日志发送到日志服务器。
( l ）业务方在“黄金令箭”的元数据管理界面依次注册需要采集交互日志的业务、具体的业务场景以及场景下的具体交互采集点，在注册
完成之后，系统将生成与之对应的交互日志来集代码模板。
(2 ）业务方将交互日志采集代码植入目标页面，并将采集代码与要需监测的交互行为做绑定。
(3 ）当用户在页面上产生指定行为时，采集代码和正常的业务互动相应代码一起被触发和执行。
(4 ）采集代码在采集动作完成后将对应的日志通过 HTTP 协议发送到日志服务器，日志服务器接收到日志后，对于保存在 HTTP 请求参数部分的自定义数据，即用户上传的数据，原则上不做解析处理，只做简单的转储。
经过上述步骤采集到日志服务器的业务随后可被业务方按需自行解析处理，并可与正常的 PV 日志做关联运算。

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

上面介绍了阿里巴巴的两类浏览器页面日志的采集方案，并粗略介绍了日志到达日志服务器之后的解析处理。但在大部分场合下，经过上述解析处理之后的日志并不直接提供给下游使用。基于如下几个原因，对时效要求较宽松的应用场合下，一般还需要进行相应的离线预处理。
( 1 ）识别流量攻击、网络爬虫和流量作弊（虚假流量）。页面日志互联网分析和大数据应用的基础源数据，在实际应用中，往往存在占一定比例的虚假或者恶意流量日志，导致日志相关指标的统计发生偏差或明显谬误。为此，需要对所采集的日志进行合法性校验，依托算法识别非正常的流量并归纳出对应的过滤规则集加以滤除。这是一个长期而艰苦的对抗过程。
(2 ）数据缺项补正。为了便利后续的日志应用和保证基本的数据统计口径一致，在大多数情况下，需要对日志中的一些公用且重要的数据项做取值归一、标准化处理或反向补正。反向补正，即根据新日志对稍早收集的日志中的个别数据项做回补或修订（例如，在用户登录后，对登录前页面日志做身份信息的回补）。
(3 ）无效数据剔除。在某些情况下，因业务变更或配置不当，在采集到的日志中会存在一些无意义、已经失效或者冗余的数据项。这些数据项不仅消耗存储空间和运算能力，而且在偶然的情况下还可能干扰正常计算的进行。为了避免此类异常的发生，需要定时检查配置并依照配置将此类数据项剔除。
(4 ）日志隔离分发。基于数据安全或者业务特性的考虑，某些日志在进入公共数据环境之前需要做隔离。

原始日志经过上述的清洗、修正，并结构化变形处理之后， Web页面日志的采集流程就算完成了。此时的日志已经具备了结构化或者半结构化的特征，可以方便地被关系型数据库装载和使用。

2.2 无线客户端的日志采集

众所周知，日志采集多是为了进行后续的数据分析。移动端的数据采集，一是为了服务于开发者，协助开发者分析各类设备信息；二是为了帮助各 APP 更好地了解自己的用户，了解用户在 APP 上的各类行为帮助各应用不断进行优化，提升用户体验。

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

2.2.1 页面事件

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

2.2.2 控件点击及其他事件

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

2.2.3 特殊场景

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

2.2.4 H5 & Native 日志统一

简单来说， APP 分为两种： 一种是纯 Native APP; 一种是既有 Native又有 H5 页面嵌入的 APP ，即 Hybrid APP 。当前，纯 Native APP 经非常少了，一般都是 Hybrid APP Native 页面采用采集 SDK 进行日志采集， H5 页面一般采用基于浏览器的页面日志采集方式进行采集。在当前的实践中，由于采集方式的不同，采集到的内容及采集服务器均分离开。若需要进行完整的数据分析，就需要将两类日志在数据处理时进行关联，而就算不考虑处理成本，在很多情况下， Native H5 互跳，即使关联也无法还原用户路径，数据丢失严重。对于产品经理以及运营、管理、数据分析人员而言，在不同的终端采用不同的方案采集日志，以不同的算法来做日志统计，忍受多端之间的数据隔离，并对由此导多样数据口径进行整理分析和解释，已经是越来越不能容忍的切身之痛。考虑到后续日志数据处理的便捷性、计算成本、数据的合理性及准确性，我们需要对 Native H5 日志进行统一处理（见图2.3 ）。
要想实现，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 中对应的实现可。
基于这种统一的方案，为后续构建完整的用户行为路径还原树打下了基础。当然，此方案也有其局限性，必须要浏览器采集 JavaScriptWeb View 、客户端采集 SDK 的配合。而往往很多时候业务并不希望做任何调整，更多的是希望减少依赖，所以在这方面我们也在寻求新的突破。

2.2.5 设备标识

正如本章开头所说的，所有互联网产品的两大基本指标是页面浏览量（ Page View, PY ）和访客数（ 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_log, access_log 的切分维度为天，即当天接收的日志存储到当天的日志文件中。考虑到后续的数据处理，以及特殊时期不同日志的保障级别，还对日志进行了分流。 比如阿里巴巴集团的Adash （无线日志服务器端处理程序），根据应用及事件类型对每日高达数千亿的日志进行了分流。分流的好处显而易见，如“双 1 1 ”时，日常数千亿的日志可能冲高到万亿，此时服务器及后续的数据计算压力就非常大了 ：而对于重要的数据计算来说 ，很可能只需要页面事件及控件点击事件即可，此时就可以适当地释放其他类型日志的资源来处理更重要的页面事件及控件点击事件。
从客户端用户行为，到日志采集服务器的日志，整个日志采集的过程就算结束了。那么日志采集服务器的日志怎么给到下游呢？方法有很多，阿里巴巴集团主要使用消息队列（ TimeTunel, TT ）来实现从日志采集服务器到数据计算的 MaxCompute 。简单来讲，就是 TT 将消息收集功能部署到日志采集服务器上进行消息的收集，而后续的应用可以是实时的应用实时来订阅 TT 收集到的消息，进行实时计算，也可以是离线的应用定时来获取消息，完成离线的计算。有关消息队列，以及日志数据的统计计算等细节内容，将在后续章节中进行详细讲述。

2.3 日志采集的挑战

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

2.3.1 典型场景

这里介绍两个最典型的场景和阿里巴巴所采用的解决方案。
1. 日志分流与定制处理
大型互联网网站的日志类型和日志规模都呈现出高速增长的态势，而且往往会出现短时间的流量热点爆发。这一特点，使得在日志服务器端采用集中统一的解析处理方案变得不可能，其要求在日志解析和处理过程中必须考虑业务分流（相互之间不应存在明显的影响，爆发热点不应干扰定常业务日志的处理）、日志优先级控制，以及根据业务特点实现定制处理。例如，对于电商网站而言，数据分析人员对位于点击流前端的促销页面和位于后端的商品页面的关注点是不一样的，而这两类页面的流量又往往同等重要且庞大 ，如果采用统一的解析处理方案，则往往需要在资源浪费（尽可能多地进行预处理）和需求覆盖不全（仅对最重要的内容进行预处理）两个选择之间进行取舍。这种取舍的结果一般不是最优的。
考虑到阿里日志体量的规模和复杂度，分治策略从一开始便是阿里互联网日志采集体系的基本原则。这里以 PV 日志采集领域 个最浅显的例子来说明，与业界通用的第三方日志采集方案的日志请求路径几乎归一不同，阿里 PV 日志的请求位置（ URL ）是随着页面所在业务类型的不同而变化的。通过尽可能靠前地布置路由差异，就可以尽可能早地进行分流，降低日志处理过程中的分支判断消耗，并作为后续的计算资源调配的前提，提高资源利用效率。与业界方案的普遍情况相比，阿里的客户端日志采集代码的一个突出特点是实现了非常高的更新频次（业界大多以季度乃至年为单位更新代码，阿里则是以周／月为单位），并实现了更新的配置 。我们不仅考虑诸如日志分流处理之类的日志服务器端分布计算方案，而且将分类任务前置到客户端（从某种程度上讲，这才是真正的“分布式” ！）以实现整个系统的效能最大化。最后可以在计算后端几乎无感知的情况下，承载更大的业务量并保证处理质量和效率。
2.采集与计算一体化设计
以PV日志为例，页面 PV日志采集之后一个基础性操作是日志的归类与汇总。在早期的互联网日志分析实践中，是以 URL 路径，继而以URL （正则）规则集为依托来进行日志分类的。在网站规模较小时，这一策略还可以基本顺利地运转下去 ，但随着网站的大型化和开发人员的增加 URL 规则的维护和使用成本会很快增长到不现实的程度，同时失控的大规模正则适配甚至会将日志计算硬件集群彻底榨干。
这一状况要求日志采集方案必须将来集与计算作为一个系统来考量，进行一体化设计。阿里日志采集针对这一问题给出的答案是两套日志规范和与之对应的元数据中 。其中，对应于 PV 日志的解决方案是目前用户可直观感知的 SPM 规范（例如，在页面的 URL 内可以看见 spm参数）和 SPM 元数据中心。通过 SPM 的注册和简单部署（仅需要在页面文件内声明一个或多个标签），用户即可将任意的页面流量进行聚类，不需要进行任何多余的配置就可以在相应的内部数据产品内查询聚合统计得到的流量、转化漏斗、引导交易等数据，以及页面各元素点击数据的可视化视图。对应于自定义日志的解决方案则是黄金令箭( Goldlog) APP 端的点击或其他日志规范及其配置中心。通过注册一个与所在页面完全独立的令箭实体／控件实体，用户可以一键获得对应的埋点代码，并自动获得实时统计数据和与之对应的可视化视图。通过简单的扩展配置，用户还可以自动获得自定义统计维度下的分量数据。
在当前的互联网环境下，互联网日志的规模化采集方案必须具备一个与终端设备的技术特点无关，具有高度扩展弹性和适应性，同时深入契合应用需求的业务逻辑模型，并基于此制定对应的采集规范交由产品开发人员执行。若非如此，则不足以保障采集–解析–处理–应用整个流程的通畅。目前阿里已成功实现规范制定–元数据注册–日志采集–自动化计算–可视化展现全流程的贯通。通过一体化设计，用户甚至可以在不理解规范的前提下，通过操作向导式界面，实现日志采集规范的自动落地和统计应用。日志本身不是日志采集的目的，服务于基于日志的后续应用，才是日志采集正确的着眼点。

2.3.2 大促保障

日志数据在阿里系乃至整个电商系应该都是体量最大的一类数据，在“双 11”期间，日志必然会暴涨，近万亿的数据量对日志全链路来说，无疑是不小的挑战（见图 2.4 ）。
从端上埋点采集，到日志服务器收集，经过数据传输，再到日志实时解析、实时分析，任何一个环节出现问题，全链路保障就是失败的。考虑到服务器的收集能力（如峰值QPS等）、数据传输能力（ TT 的搬运速度）、实时解析的吞吐量、实时业务分析的处理能力，我们在各环节都做了不少的工作。
首先，端上实现了服务器端推送配置到客户端，且做到高到达率其次 ，对日志做了分流，结合日志的重要程度及各类日志的大小，实现了日志服务器端的拆分；最后，在实时处理方面，也做了不少的优化以提高应用的吞吐量。在上面几项的基础上，结合实时处理能力，评估峰值数据量 ，在高峰期通过服务器端推送配置的方式对非重要日志进行适当限流 ，错峰后逐步恢复。此处说的服务器端推送配置包含较多的内容，首先是作用范围，可以针对应用、平台、事件、事件中的某个场景：其次是具体实施，包括延迟上报、部分采样等。所谓延迟上报，即配置生效后 ，满足条件的日志将被暂时存在客户端，待配置恢复后再上传到服务器 ；所谓采样 ，即配置生效后，满足条件的日志将被实施采样（对于一些技术类日志，如页面加载情况、消耗内存等，可以实施采样），上报部分日志到服务器。读到这里，可能会有读者发现，整个日志处理流程还是比较长的，对于对实时性要求极高的业务场景，如上链路显然不能满足需求。所以一方面，我们从业务上进行改造，采用端上记录；一方面，我们也在链路各环节做优化，如从采集服务器直接完成解码并调用业务API完成业务的计算（省去中间的传输和过多的处理） 。在这方面我们也面临着巨大的挑战，在保证稳定的同时扩展功能， 在稳定及业务深度之间做到很好的平衡。
在如上策略下， 2016 年的“双 11 ”，日志采集浏览等核心用户行为日志均实现了 100% 及实时服务，支持天猫所有会场的实时推荐。在“双 11 ”中，用户的浏览、点击、滚屏等每个操作行为，都实时影响到后续为其推荐的商品，很好地提高了用户体验。