掌握大数据之道：详解网页日志采集（第二章第一节）

浏览器的页面型产品／服务的日志采集可分为如下两大类。
( 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 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）服务器接收并解析请求。服务器端的业务处理模块按业务逻辑处理本次请求并按照 HTT 协议规定的格式，将处理结果以 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 文档内的 JavaSc ript 脚本来执行。采集脚本被浏览器加载解析后执行，在执行时采集当前页面参数、浏览行为的上下文信息（如读取用户访问当前页面时的上 步页面）以及 些运行环境信息（如当前的浏览器和分辨率等）。
（2）客户端日志发送。采集脚本执行时，会向日志服务器发起一个日志请求，以将采集到的数据发送到日志服务器。日志采集和发送模块 般会集成在同一个JavaScript 脚本文件内，且通过互联网浏览器必然支持的 HTTP 协议与日志服务器通信，采集到的日志信息 般以 URL 参数形式放在 HTTP日志请求的请求行内。
（3）服务器端日志收集。日志服务器接收到客户端发来的日志请求后，一般会立即向浏览器发回一个请求成功的响应，以免对页面的正常加载造成影响；同时，日志服务器的日志收集模块会将日志请求内容写入一个日志缓冲区内，完成此条浏览日志的收集。
（4）服务器端日志解析存档。服务器接收到的浏览日志进人缓冲区后，会被一段专门的日志处理程序顺序读出并按照约定的日志处理逻辑
解析。由日志采集脚本记录在日志请求行内的参数，将在这个环节被解析（有时候伴随着转义和解码）出来，转存入标准的日志文件中并注人实时消息通道内供其他后端程序读取和进 步加工处理。

2.1.2 页面交互日志采集流程

因为终端类型 页面内容、交互方式和用户实际行为的千变万化不可预估，交互日志的采集和 日志的采集不同，无法规定统 的采集内容，呈现出高度自定义的业务特征。与之相适应，在阿里巴巴的日志采集实践中，交互日志的采集（即“黄金令箭”）是以技术服务的形式呈现的。
具体而言，“黄金令箭”是一个开放的基于 HTT 协议的日志服务，需要采集交互日志的业务（下文简称“业务方”），经过如下步骤即可将自助采集的交互日志发送到日志服务器。
（1）业务方在“黄金令箭”的元数据管理界面依次注册需要采集交互日志的业务、具体的业务场景以及场景下的具体交互采集点，在注册完成之后，系统将生成与之对应的交互日志来集代码模板。
（2）业务方将交互日志采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定。
（3）当用户在页面上产生指定行为时，采集代码和正常的业务互动响应代码 起被触发和执行。
（4）采 代码在采集动作完成后将对应的日志通过 HTTP 协议发送到日志服务器，日志服务器接收到日志后，对于保存在 HTTP 请求参数
部分的自定义数据，即用户上传的数据，原则上不做解析处理，只做简单的转储。

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

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