大数据之路读书笔记（六）

前言

        上一章主要研究的是无线客户端日志采集中与浏览器端日志采集相对应的技术方案，现在开始要进行无线客户端日志采集特有技术的学习。

特殊场景

        页面事件和控件点击及其他事件都是一个行为产生一条日志，如果处理普通业务场景是足够的，但是一但业务场景体量非常大就不太适用了，因此为了平衡日志大小、减少流量消耗、采集服务器压力、网络传输压力等，采集SDK提供了聚合功能，对某些场景如曝光或一些性能技术类日志，在客户端就进行适当的聚合，以减少对日志采集服务器端的请求，适当减小日志大小。总体思路就是每个曝光的元素一般都属于一个页面，利用页面的生命周期来实现适当的聚合及确定发送时机。

        区别于浏览器的页面访问，在无线客户端用户的访问行为路径存在明显的回退行为（如点击回退按钮、各种滑屏等），在进行业务分析时回退同样作为特殊场景存在。针对回退行为特殊场景，一般是使用特殊的设计，利用页面的生命周期，识别页面的复用，配合栈数据结构的特性来识别是否是回退行为。

H5&Native日志统一

        APP分为两种：一种是纯Native APP（即原生应用程序，为特定平台（如IOS、Android等）开发的应用）；另一种是既有Native又有H5页面嵌入的APP，即Hybrid APP（即混合应用程序，是一种结合原生应用和网页应用特点的应用类型）。Native页面采用采集SDK进行日志采集，H5页面一般采用基于浏览器的页面日志采集方案进行采集。在当前的实践中，使用不同的采集方式采集的内容和发送的采集日志服务器都会分离开。一方面，如果需要对Hybrid APP进行完整的数据分析，则需要将两种类型的采集日志在数据处理时进行关联，而即使不考虑处理成本的情况下，Native和H5互相跳转的场景，对日志进行关联也无法还原用户路径，数据丢失严重；另一方面，在不同的终端采用不同的方案采集日志，以不同的算法来做日志统计，忍受多端之间的数据隔离，成本越来越高；所以考虑后续日志数据处理的便捷性、计算成本、数据的合理性及准确性，需要对Native和H5日志进行统一处理。

        要想实现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中对应的实现即可

        基于统一的方案，为后续构建完整的用户行为路径还原树打下基础。此方案也有局限性，必须浏览器采集JavaScript、WebView、客户端采集SDK的配合，而往往业务并不希望做任何调整，更多的希望减少依赖，提高响应速度，这是目前的一个矛盾点。

设备标识

        所有互联网产品的基本指标是页面浏览（Page View，PV）和访客数（Unique Visitors，UV）。关于UV，对于登录用户，可以使用用户ID来进行唯一标识，但是很多日志行为并不要求用户登录，这就导致在很多情况下采集上来的日志没有用户ID。PC端一般是使用Cookie信息作为设备的唯一信息，对于APP来说，就需要想办法获取唯一标识设备的信息。

        历史上，IMEI（即国际移动设备识别码）、IMSI（即国际移动用户识别码）、MAC（MAC地址即媒体访问控制地址）、苹果UDID（即唯一设备标识符），曾经都可以用，但随着用户的自我保护意识加强以及系统升级，很多基本的设备信息获取都不再那么容易。例如苹果禁用UDID，IDFA（即苹果设备广告标识符）、IMEI、IMSI做了权限控制，Android系统也对设备信息获取做了权限控制。

        无线设备唯一标识符使用UTDID，即每台设备唯一标识符，需要随着IOS和Android系统对权限控制的不断升级，进行同步的调整。

日志传输

        无线客户端日志的上传，不是产生一条日志上传一条，而是无线客户端产生日志后，先存储在客户端本地，然后再伺机上传。所谓伺机，就需要数据分析的支持，如启动后、使用过程中、切换到后台时这些场景分别多久触发一次上传动作。当然单纯靠间隔时间来决定上传动作是不够的，还需要考虑日志的大小及合理性（如单条日志超大，可能就是错误日志）。另外，还需要考虑上传时网络耗时，来决定是否要调整上传机制。

        客户端数据上传时是向服务器发送POST请求，服务器端处理上传请求，对请求进行相关校验，将数据追加到本地文件中进行存储，存储方式使用Nginx（web服务器软件）的access_log，access_log的切分维度为天，即当天接收的日志存储在当天的日志文件中。考虑到后续的日志处理，以及特殊时期不同日志的保障级别，还要对日志进行分流。比如根据应用及事件类型对每日的日志进行分流。分流的好处显而易见，当时日志数据量过大时，服务器及后续的数据计算压力就非常大，而对于重要的数据计算来说，很可能只需要页面事件及控件点击事件即可，此时就可以适当地释放其他类型的日志资源来处理更重要的页面事件及控件点击事件。

        从客户端用户行为，到日志采集服务器的日志，整个日志采集过程就结束了。至于日志采集服务器的日志到下游的过程，方法有很多，可以使用消息队列（TimeTunel，TT）来实现从日志采集服务器到数据计算的MaxCompute。简单来讲，就是TT将消息收集功能部署到日志采集服务器上进行信息收集，而后续应用可以是实时应用实时的订阅TT收集到的消息，进行实时计算，也可以是离线应用定时的获取信息，完成离线计算。