BDK，BigData Knowledge的简称，主要用于更新以下但不限于数据仓库的设计与建设、ETL、大数据架构相关内容的专栏，知识内容来自于相关书籍的个人学习总结笔记，相关资料可见文末的附录。
从上次文章可以知道，数据最原始的来源之一就是日志采集，这一环是很重要的。
???? Index
浏览器的页面日志采集流程
服务端日志的清洗与预处理
无线客户端的日志采集
???? 浏览器的页面日志采集流程
浏览器的页面型产品/服务的日志采集可以大致分为两类。
1）页面浏览（展现）日志采集。常见的基本指标有PV和UV。
2）页面交互日志采集。当页面被加载和渲染完毕后，用户在页面进行的一切操作，包括点击、停留、输入等等的操作，这往往是量化用户兴趣点或者优化体验的着手点。
目前典型的网页访问过程是以浏览器请求、服务器响应并返回所请求的内容的模式进行的。浏览器和服务器之间的通信基本都是遵守 HTTP协议（超文本传输协议）的。浏览器发起的请求被称之为HTTP Request，服务器返回的则被称为HTTP Response。
我们先来了解下HTTP协议，一个标准的HTTP Request由下面的3个部分构成：
（1）请求行（HTTP Request Line）：由3个元素构成，分别是请求方法、所请求资源的URL以及HTTP协议版本号。
（2）请求报头（HTTP Message Header）：报头是浏览器在请求时向服务器提交的附加信息，一般附加的内容还蛮多的（每项内容被称为头域（Header Field），一般简称为Head），这里和我们常见的Cookie也是有关系的，当我们在本次页面浏览前就浏览过这个页面，一般请求头都会附有一个或者多个Cookie的数据项，它记录了我们上一次访问的状态or身份信息。
（3）请求正文（HTTP Message Body）：一般来说这里都是空的。
与之对应的，HTTP Response也是由3部分构成：
（1）状态行：标识了服务器对本次请求的处理结果，主要都是一个由三位数字构成的状态码。如我们熟悉的200代表OK，404代表Not Found。
（2）响应报头：服务器在执行响应时，也是可以附加一些数据项的，就比如Cookie记录我们的登陆账户名，下次再次打开这个网页的时候，直接呈现我们面前的就是附带有用户名的页面，我们只需要输入密码即可，这就是通过报头的方式来实现的。
（3）响应正文：这一部分包含了浏览器请求的文档、图片、脚本等，就存储在这个响应正文内。
总结来说，一次典型的网页浏览大致可以分为4步：
用户输入链接or点击链接
浏览器向服务器发起HTTP请求
服务器接收并解析请求
浏览器接收来自服务器的响应内容
如果我们需要记录浏览行为，其实前三步并不能确认用户浏览了网页，只有第四步才有可能。所以我们日志采集的位置都是在这里进行的。大体的思路：在HTML文档的适当位置增加一个日志采集节点，当浏览器解析到这个节点的时候，将自动触发一个特定的HTTP 请求到日志采集服务器。
而如果我们只是记录访问的页面以及访问路径其实可以获取到的信息量是很少的，很多情况下我们需要去了解用户在访问某个网页的互动行为，从而了解客户的反应。因此，就有了记录页面交互日志的需求。
这一类的行为其实比较复杂，一般也不好做一套标准就适用于大多数情况，基本都是按需开发。
???? 服务端日志的清洗与预处理
作为数据挖掘工程师，可能做过的特征预处理很多了，但是对于这种原始日志数据的清洗还是蛮少接触的。我们通过上面的方式采集到的日志数据，其实是不能直接拿来使用的，原因有几点：
（1）流量攻击、网络爬虫和流量作弊的存在。在实际中，我们采集到的日志数据中有一定比例是虚假or恶意的流量日志，这些东西如果不做处理的话会导致后续相关指标统计的偏差。这里我们需要指定一些规则，对日志进行合法性的校验，同时依托算法识别非正常的流量，过滤掉无效非法的流量，这一块用到机器学习的知识也是蛮多的。就好像之前科大讯飞的虚假流量的识别大赛就是相关的竞赛。
（2）数据存在缺失。一般会对一些公用且重要的数据项做取值归一、标准化或反向补正。这里解释一下反向补正，意思就是根据历时日志，对新日志的部分数据项进行回补或修订（比如用户再次登录后，身份验证信息会缺失，这时候可以拿用户第一次的数据来进行填补）。
（3）存在无效数据。因为业务配置不当or业务调整，有一些采集的日志数据已经没有意义或者冗余失效，这会消耗存储空间和算力，这种情况需要定期检查配置并做调整。
（4）日志需要隔离分发。这是从数据安全和业务特性的角度去考虑的。
✍️ 无线客户端的日志收集
随着现在互联网的普及，各式各样的APP安装在我们的电脑上，当然也会记录了很多客户的行为数据，可以分析各类设备信息、了解客户在APP上的各类行为，优化客户体验。
????页面事件
从实现方法来说无线客户端的日志采集就是通过SDK来对不同事件进行实现，对一些通用的用户行为会抽象出一些通用的接口方法。而对于页面事件，其实就是页面浏览行为信息，一般都会包含三类信息：
① 设备及用户的基本信息
② 被访问页面的信息，主要是一些业务参数信息，如商品sku、店铺id等
③ 访问基本路径，如页面来源、来源的来源等，可以用来还原用户完整的访问行为记录
????控件点击及其他事件
首先是控件点击，它和页面事件一样记录了基本的设备信息、用户信息，另外它还记录了控件所在页面名称、控件名称、控件的业务参数等。
而其他事件，就是用户可以根据业务场景需求使用自定义事件来采集相关信息。
????特殊场景
上述讲到到场景都是一个行为产生一条日志，如一次浏览、一次点击等，对于少业务量来说还是可以满足需求的，但是对于大业务体量的系统来说就会有点压力了，为了平衡日志大小、减少流量消耗、采集服务器压力、网络传输压力等，采集SDK提供了聚合功能，对日志进行适当聚合后再回传服务器。
????H5&Naive 日志统一
简单来说，APP分为两种，一种是纯Native APP，另一种就是H5页面嵌入的APP，即Hybird APP（为什么是hybird，因为除了有H5的，也有native的）。
Native页面一般采用采集SDK进行日志采集，而H5页面一般采用基于浏览器的页面日志采集方式进行采集。由于采集方式的不同，一般都会分离开来采集，如果需要完整的数据分析，则需要关联，且不说关联成本的问题，在很多情况下，APP和H5之间总是会互跳的，比如你在H5上操作着就可以跳转到APP上继续操作，这样子如何关联也很难还原用户路径，数据丢失严重。
所以基于这个痛点，也是有一套处理的逻辑提供给你的：
要实现日志的统一处理，就需要对Hybird日志有统一的方案，简单的思路就是归一两种日志，可以从H5日志归一到Native日志，相反也可以。阿里巴巴的就是采用H5日志归到Native日志。
????设备标识
很多时候页面浏览是没有登录用户的，所以我们必须找到一个可以标记用户的东西，对于PC端一般会使用Cookie信息，对于APP则使用设备标识。
但是没那么简单，设备信息获取越来越难，苹果对UDID禁用，也对IDFA、IMEI、IMSI做权限控制，Android新系统对设备信息的获取进行了权限控制。
????日志传输
日志传输前是需要做一些处理来提高传输的效率的，包括上传、压缩。
无线客户端日志的上传不是来一条上传一条的，都是先存储在本地，然后伺机上传，这里需要考虑间隔时间、上传日志的大小及合理性、还有就是上传的网络耗时，从而一起来决定和调整上传机制。
???? Reference
[1] 大数据之路：阿里巴巴大数据实践
3777
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
