阿里巴巴的日志采集分享（下）

发表于 2017-09-01 分类于产品阅读次数： Waline：

UserTrack 高级功能

曝光日志预聚合

曝光日志，是电商场景下很特殊的一类日志，具体来说：比如商品图墙列表上有多少商品给用户展示过就是一种典型的曝光日志，一般用来作为推荐算法的输入信息或者广告展示计费用途。曝光日志一般是点击日志的几十到几百倍，而一页内的曝光信息又大致雷同，所以一般都会做聚合。

只是如何聚合，由客户端采集框架聚合还是由业务自身聚合（比如曝光日志设计为一条可以直接记录一批商品），这会是需要权衡考虑的。

回退识别

用户回退行为的识别，也是比较棘手的，因为跟踪用户浏览行为的目的，主要是为了分析链路转化率，用来优化业务或分析活动效果等。而页面回退行为对这些行为分析是一种干扰。在下游数据分析过程中再识别这种行为往往很难，在采集端会有更充分的信息进行识别。但具体实现也并不是总能万无一失，而且有些特殊情况下，可能还需要保留这种回退行为的数据。

H5 和 native 日志统一

H5 和 native 日志统一：H5 日志通过 JS 接口传给 Native 的方法，转换成 native 的格式统一输出

H5 越来越流行，Hybrid 的应用越来越普及，用户并不关心你的页面是 native 的还是 H5 的，但是日志的采集方案在 Web 端和 Native 端通常却是两套架构，后续采集传输流程等等很可能也不在一条链路上。如果不加处理，对于用户行为的链路分析会带来很大的麻烦。

具体怎么处理，不外乎是要自动识别 H5 页面的运行环境，打通 H5 跳转到 Native 和 Native 跳转到 H5 两个方向的页面数据传递，加上各种回退之类行为要处理，安卓和 IOS 的方案要兼容等等，真的实现起来，还是要费不少力气处理好各种细节的。

数据保障

日志处理链路

日志分流

日志分流：根据页面业务类型的不同，采用不同的 URL Log 记录地址，将分流工作从客户端开始做起
日志分流的目的，自然是为了增加日志链路水平拓展的能力，然后降低后续流程具体业务的计算代价，所以理论上来说，分流得越早，分流得越彻底，这方面的收益越高。

日志缓存

主要使用缓存部分日志先不发送，以及日志采样等
日志分流以后，当然可以做开关，缓存，采样等工作，这也是分流的收益之一。

阿里现在日志的上传率是 98%，目前是国内上传率最高的公司。平时每天大概会有 4000 亿的日志上传，双十一期间会高达 6000 亿，这还是在减少一些通用型数据上传的情况下。

在网络差的时候，阿里会把数据分包，如果还是上传会继续拆分，一直到 10k。如果还是上传不上去，就会采取其他技术手段。

埋码流程

基本流程

阿里的埋码流程如下：

埋点申请，埋点配置，埋点验证，数据监控，采集管理

埋点申请：在平台上申请埋码，并记录埋点信息
埋点配置：埋码分为可视化自动埋码，和非可视化手动埋码
埋点验证：sdk 自动触发点击事件，和平台上提交的埋点信息做验证
数据监控：监控埋码质量
采集管理：采集数据管理

埋码测试

本地测试

本地会使用自动埋码测试工具

灰度版本测试

阿里会对部分软件的部分用户进行灰度测试，验证灰度测试结果

上期的分享

流量产品整体介绍
采集规范
- 采集规则统一
- SPM 和 SCM
- 黄金令箭
数据采集
- 整体设计
- Aplus - WEB 采集
- UserTrack - APP 采集
- UTDID

文章中图片因版权原因移除，详细内容可以查看《大数据之路》。

The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.

由WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证。

本文永久链接：https://blog.naaln.com/2017/09/alibaba-data-track-2/