《数据技术篇》

2.1 浏览器的页面日志采集

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

• 页面浏览（展现）日志采集：页面被浏览器加载时产生的日志，此类日志是最基础的互联网日志，核心指标为页面浏览量（Page View，PV）和访客数（Unique Visitors， UV）；页面浏览日志是目前成熟度和晚辈度最高，同时也是最具挑战性的日志采集任务
• 页面交互日志采集：记录用户在页面上进行的各种操作的日志，以便通过量化获知用户的兴趣点或者体验优化点

2.1.1 页面浏览日志采集流程

要了解页面浏览日志采集，首先要了解互联网页面从请求到响应的基本流程

下面介绍典型的互联网页面请求到响应的一个过程：

Step 1：浏览器输入网址

Step 2：浏览器向网址服务器发出HTTP请求【请求行（GET、URL、HTTP1.1）、请求报头（包含Cookie）、请求正文】

Step 3：服务器接到请求并解析【状态行（200 OK、404 Not Found）、响应报头（包含Cookie记录指令）、响应正文（文件、图片、脚本等）】

Step 4：浏览器接收到服务器内容（埋点一般在这一步进行，为了确保网页正常解析显示）

下面重点介绍一下，阿里巴巴目前采用的页面浏览日志采集方案：

Step 1：客户端日志采集【一般由一小段被植入页面HTML文档内的JavaScript脚本来执行】

Step 2：客户端发送日志【脚本执行会向服务器发送日志请求，已将收集到的数据发送到服务器】

Step 3：服务器端日志收集【收到请求后，发回一个请求成功响应】

Step 4：服务器端日志解析存档

2.1.2 页面交互日志采集

为了满足对用户精细化运营的需求，交互日志采集的需求越来越多样化和定制化。

在阿里巴巴，一套”黄金令箭“来解决交互日志的采集问题。它是一个开放的，基于HTTP协议的日志服务，日志的采集步骤如下：

Step 1：业务方，在元数据管理界面依次注册需要采集交互日志的业务、具体的业务场景以及场景下的具体交互采集点，在注册完成之后，系统将生成与之对应的交互日志采集代码模板

Step 2：业务方将交互日志采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定

Step 3：用户出触发行为，采集代码和正常的业务互动响应代码一起被触发和执行

Step 4：采集动作完成后，将对应日志通过HTTP协议发送到日志服务器

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

经过上面讲的两种方案收集的日志并不直接提供给下游使用，一般还需要进行相应的离线预处理：

Reason 1：识别流量攻击、网络爬虫和流量作弊（虚假流量）。【对日志进行合法性校验，使用算法识别非正常流量】

Reason 2：数据缺项补正。【取值归一、标准化处理、反向补正】

Reason 3：无效数据剔除

Reason 4：日志隔离分发

2.2 无线客户端的日志采集

无线客户端的日志采集用采集SDK完成，在阿里内部，多使用名为UserTrack的SDK来进行。”事件“为无线客户端行为的最小单位，常用的包括页面事件和控件点击事件。

• 为什么要对事件进行分类？

Reason 1： 不同事件的日志触发时机、日志内容和实现方式有差异之处

Reason 2：更好地完成数据分析，降低了后续处理的复杂性

2.2.1 页面事件

每条页面事件记录三类信息：

• 设备信息和用户信息
• 被访问页面信息（例如：商品详情页商品ID、所属的店铺等）
• 访问基本路径（页面来源、来源的来源等）

对于页面事件，不同的SDK有不同的实现：

• 有些SDK选择页面创建时即发送日志
• UT提供了页面时间的无痕埋点，即无须开发者进行任何编码即可实现
• 手动模式的埋点，UT提供了两个接口，分别在页面展现时和页面退出时调用

为了平衡采集、计算、和分析成本，在部分场景下我们选择采集更多的信息来：

• UT提供了透传参数功能。即把当前页面的某些信息，传递到下一个页面甚至下下个页面的日志中。
• 在阿里内，使用SPM（Super Position Model，超级位置模型）进行来源去向的追踪，在无线客户端也同样使用SPM，SPM信息可以通过透传机制带入到下一步甚至下下一步的浏览页面，这样整个用户行为路径还原就轻松实现了。

2.2.2 控件点击及其他事件

控件点击事件比页面事件要简单得多：

• 它和页面事件一样，记录了基本的设备信息、用户信息
• 它记录了控件所在页面名称、控件名称、控件的业务参数

UT提供了一个自定义的埋点类，包括：

• 事件名称
• 事件时长
• 事件所携带的属性
• 事件对应的页面

UT还可以自动捕捉应用崩溃，并且产生一条日志记录崩溃相关信息。

2.2.3 特殊场景

对于巨大的业务体量来说，为了平衡日志大小、减小流量消耗、减轻采集服务器和网络传输的压力等，提倡在客户端对这类日志进行适当聚合，以减少对日志采集服务器端的请求，适当减小日志大小。总体思路就是利用页面的生命周期来实现适当的聚合及确定发送时机。

2.2.4 H5&Native 日志统一

一般来说，APP分为两种：

• 纯Native APP
• Native + H5 的APP，我们称之为Hybrid APP

Native 页面采用采集SDK进行日志采集，H5页面一般采用基于浏览器的页面日志采集方式进行采集。

在当前的业务应用中，由于采集方式的不同，他们采集到的内容及采集服务器均分离开。这就涉及到一个问题，如果需要进行完整的数据分析，就需要将两类日志在数据处理时进行关联，在很多情况下，会产生很大的成本，而且Native和H5互跳，即使关联也无法还原用户路径，造成数据丢失严重。为了解决这一问题，我们就必须打通H5和Native日志：

如果对Hybrid日志进行统一的处理，简单的思路就是首先将两类日志进行归一。如何进行归一呢？

• 可以把Native日志向H5日志归
• 也可以把H5日志向Native日志归

考虑到两种日志采集方式的特点及关注点，阿里选择了Native部署采集SDK的方式将H5日志归到Native中。

原因：

Reason 1：采用采集SDK可以采集到更多的设备相关数据，这在移动端的数据分析中尤为重要

Reason 2：采集到的SDK处理日志会现在本地缓存，然后借机上传，在网络状况不佳时延迟上报，保证数据不丢失

具体流程：

Step 1： H5页面浏览和页面交互的数据，在执行时通过加载日志采集的JavaScript脚本，采集当前页面参数，包括浏览行为的上下文信息以及一些运行环境信息。

Step 2：在浏览器日志采集的JavaScript脚本中实现将所采集的数据打包到一个对象中，然后调用WebView框架的JSBridge接口，调用移动客户端对应的接口方法，将埋点数据对象当作参数传入

Step 3：移动客户端日志采集SDK，封装提供接口，实现将传入的内容转换成移动客户端日志格式。

2.2.5 设备标识

互联网的两大基本指标是页面浏览量（Page View， PV）和访客数（Unique Visitors，UV）。关于UV对于登录用户，可以使用用户ID来进行唯一标识，但是很多日志行为并不要求用户登录，这就导致在很多情况下采集上来的日志都没有用户ID。

PC端一般使用Cookie新消息来作为设备的唯一信息

APP端一般用MEI、IMSI、MAC、UDID等作为设备，但是随着用户信息保护意识的加强以及各系统升级，很多基本的设备信息获取都不再容易。阿里目前对无线设备用UTDID作为唯一标识（但目前UTDID并未完全实现其使命）。

2.2.6 日志传输

（1）无线客户端日志的上传

• 无线客户端日志的上传，不是产生一条日志上传一条，而是无线客户端产生日志后，先存储在客户端本地，然后再伺机上传（所谓的伺机的时间可以设置，考虑因素为日志的大小、合理性、上传时耗、时间间隔等）

首先是客户端向POST服务器发送请求，服务器端处理并进行校验，然后将数据追加到本地文件中进行存储（存储方式使用Nginx的access_log，access_log的切分维度为天，即当天接收的日志存储到当天的日志文件中）

考虑到后续的数据处理，以及特殊时期不同日志的保障级别，对日志进行了分流处理。比如阿里巴巴用的Adash（无线日志服务器端处理程序），根据应用及事件类型对每日高达数千亿的日志进行了分流。为什么分流呢？比如“双11”，日常数千亿的日志在这一天可能达到万亿级别，对服务器造成了很大的压力；但对于重要的数据计算来说，占用的计算资源就会变少，因此释放其他类型日志资源来保障重要数据的计算，就是数据分流。

（2）日志采集服务器的日志下游

日志采集服务器的日志如何给到下游？

方法有很多种，这里举个阿里的方法。

阿里巴巴集团主要使用消息队列（Time Tunel， TT）来实现从日志采集服务器到数据计算的。

就是TT将消息收集功能部署到日志采集服务器上进行消息的收集，而后续的应用可以做到实时查看TT收集的数据，进行实时计算；也可以定时获取离线数据，完成离线计算。

2.3 日志采集的挑战

目前日志采集的挑战从没有日志阶段到海量日志如何管理的阶段。如何实现日志数据的结构化和规范化，实现高效的下游计算，提供符合业务价值的数据展现以及算法，成为了目前日志采集面临的巨大挑战。

2.3.1 典型场景

（1）日志分流与定制处理

方法背景：由于大型互联网网站的日志类型和日志规模都呈现出告诉增长的态势，而且往往会出现短时间的流量热点爆发。使得在日志服务器端采集集中统一的分析处理方案变得不可行

分流定制特点：在日志解析和处理过程中必须考虑业务分流

分流与定制原则：业务分流要做到项目之间不应存在明显的影响，爆发热点不应干扰日常业务日志处理、日志优先级控制、根据业务特点实现定制处理

阿里案例：PV日志采集

阿里PV日志请求URL是随着页面所在业务类型的不同而变化的。通过尽可能靠前地布置路由差异，就可以尽早进行分流，从而降低日志处理过程中的分支判断消耗，提高资源利用率。

（2）采集与计算一体化设计

方法背景：在早期的互联网日志分析中，是以URL路径 + 正则表达式为依托进行日志分类，但随着网站规模的不断扩大，这种方法的使用和维护成本增长到了不显示的程度，同时失控的大规模正则适配也会将日志计算硬件集群彻底榨干。

一体化设计特点：具备与终端设备的技术无关、具有高度扩展弹性和适应性、契合业务逻辑模型

一体化设计原则：将采集与计算作为一个系统进行一体化设计

阿里案例：PV日志采集和自定义日志

• PV日志采集

阿里使用了，目前用户可以直观感知的SPM规范和SPM元数据中心。通过SPM注册和简单部署，用户可以将任意的页面流量进行聚类，不需要进行任何多余的配置就可以在相应的内部数据产品内查询聚合统计得到的流量、转化漏斗、阴道交易等数据，以及各页面各元素点击数据的可视化图表。

• 自定义日志采集

黄金令箭（GoldLog）或者APP端的配置日志规范是目前阿里用于解决这一问题的方案。通过注册一个与所在页面完全独立的令箭实体/控件实体，用户可以一键获得对应的埋点代码，并自动获得实时统计数据和与之对应的可视化图表。通过简单的扩展配置，用户还可以自动获得自定义统计维度下的分量数据。

2.3.2 大促保障

数据处理全链路：

• 端上实现了服务器端推送配置到客户端，且做到高到达率
• 结合日志的重要程度及各类日志的大小，对日志进行分流
• 优化实时处理，提高应用吞吐量
• 结合实时处理，评估峰值数据量，在高峰期通过服务器端推送配置的方式对非重要日志进行适当限流，错峰后逐步恢复

实施方法：

• 延迟上报：日志暂时存在客户端，待配置恢复后再上传到服务器
• 部分采样：将满足条件的日志进行采样，上报该部分采样日志到服务器
• 业务上采用端上记录避免日志处理流程长导致日志的实时性没法保障
• 链路环节做优化，如从采集服务器直接完成解码并调用业务API完成业务的计算