【读书笔记】阿里巴巴大数据实践：日志采集（第2章）

第2章 日志采集

---

一句话评论：日志是重要的数据来源之一，对日志的收集、处理、集成的数据开发工作，尤其是多个渠道（网页端、APP端、小程序端、公众号端等）的数据整合是较大的难点，对后续的业务分析至关重要。

---

2.1 浏览器的页面日志采集

页面浏览（展现）日志采集：PV UV

• 网页访问的过程：浏览器发起HTTP请求，服务器返回响应，浏览器解析并渲染

source：作者据书整理。

页面交互日志采集：“黄金令箭”，高度自定义的业务特质

• 业务方注册需要采集交互日志的业务、场景和交互采集点，系统将生成与之对应的交互日志采集代码模板
• 将采集代码植入页面，并绑定交互行为
• 当用户与页面交互时，采集代码和业务互动响应代码一起被执行
• 采集代码在采集行为完成后将日志通过HTTP协议发送到日志服务器
  

页面日志的服务器端清洗和预处理：对时效要求不高的话，要先进行离线预处理，因为

• 识别流量共计 网络爬虫和虚假浏览
• 数据缺项补正，取值归一、标准化处理、反向补正
• 无效数据剔除
• 日志隔离分发，之后这些日志数据就可以被关系型数据装载和使用了。
  

2.2 无线客户端（APP）的日志采集：SDK

（1）页面事件（同页面浏览）：UT

• 每条日志记录三类信息，设备及用户的基本信息+被访问页面的信息+访问的基本路径
• 抽象出通用的接口方法，3个接口方法结合使用：
  • 页面展现时调用的接口方法
  • 页面扩展信息的接口方法
  • 页面退出时调用的接口方法。
• 离开页面时发送日志，可以准确地收集用户在页面的停留时间。
• UT提供透传参数机制，使用SPM模型（超级位置模型）追踪用户行为路径。
  

（2）控件点击事件（同页面交互）

• 把基础信息告诉采集SDK即可
  

（3）其他事件：自定义事件采集相关信息

（4）特殊场景

• SDK聚合功能，在客户端对大量日志进行适当聚合，以减少对日志采集服务器的请求
• 回退场景：利用页面的生命周期，识别页面的复用，配合栈的深度来识别回退行为
  

（5）H5 和 Native 日志统一

• Hybrid APP：Native 页面–>SDK采集，H5 页面–>同浏览器的页面日志采集方式，不同采集方式和不同终端的采集日志是分离的。
• 为了统一处理 Native 页面和 H5 页面的日志数据，将H5 日志归入 Native 日志：
  • 因为，SDK方式可以在网络延迟时在本地缓存，数据不会丢失
  • 具体的流程：
    • H5 页面的采集与浏览器的页面采集方法一样，只需要手动植入日志采集的JS脚本即可。
    • 该JS脚本采集日志并打包成一个对象，调用WebView框架的JSBridge接口，将买带你数据对象当作参数传入
    • 移动端采集SDK将传入的H5日志转换成APP日志格式。
      

（6）设备标识

• 无需用户登录的场景下需要一个唯一标识用户的ID
• PC 端使用cookie来唯一标识未登录的用户
• APP端曾经可以使用MEI/IMSI/MAC/UDID等来唯一标识，但随着系统升级，这些标识都有一些权限控制。因此，阿里巴巴集团目前使用UTDID，但目前还不完善。
  

（7）日志传输

• 无线客户端日志的上传、压缩和传输的特殊性：
  • 先存储在本地，然后再伺机上传：考虑日志的大小、重要性、上传时网络耗时
  • 上传：客户端向日志服务器发送POST请求，服务器使用Nginx的access_log，切分维度为天，即当天的日志追加存储到当天的日志文件中。
  • 考虑到数据处理的需求，还进行了日志分流。
  • 传输到下游：使用消息队列TimeTunnel(TT)，将日志传输到负责计算的MaxCompute；实时和离线应用都可以订阅TT收集到的消息。
    

2.3 日志采集的挑战

• 主要挑战：对大量日志数据的结构化和规范化组织。
  

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

• PV日志的请求位置URL随着页面所在业务类型的不同而变化，实现真正的分布式。
• 日志采集代码更新频率周/月，并实现了更新的配置化。
• 还考虑将分类任务前置到客户端。
  

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

• 日志采集之后的基础性操作是归类与汇总
• 旧方法：以URL正则规则集对日志进行分类
• 新方法：采集与计算一体化，给出两套日志规范和与之相对应的元数据中心。
  • PV日志：SPM规范
  • 自定义日志：黄金令箭/APP端的点击或其他日志规范及其配置中心
    

（3）大促保障

• 双11 近万亿的数据量，优化数据处理全链路：
  • 服务器端推送配置到客户端，高到达率
  • 日志分流
  • 实时处理优化