大数据之路_采集篇
一.日志采集
阿里巴巴的日志采集体系方案包括两大体系： Ap us.JS Web
（基于浏览器）日志采集技术方案： UserTrack APP 端（无线客户端
日志采集技术方案。
1.浏览器的页面日志采集
( 1 ）页面浏览（展现）日志采集，也是目前所有互联网产品的两大基本指标：页面浏览量（ Page
View, PY ）和访客数（ Unique Visitors, UV ）的统计基础。
(2 ）页面交互日志采集。
页面浏览日志采集流程:
一个标准 HTTP 请求由如下三部分构成。
请求行（ HTTP Request Line ）。请求行内有 个要素，分别是请求方法、所请求资源的 URL 以及 HTTP 协议版本号。在本例子中，这 个要素分别是 GET http: //www.taobao.com ／以及 HTTP1.1 ，对于我们所讨论的话题，记住请求行内最重要的信息是这URL 就可以了。
请求报头（ HTTP Message Header ）。请求报头是浏览器在请求时向服务器提交的附加信息，请求报头一般会附加很 容项（每项内容被称为一个头域（ Header Field ），在不引起混 的情况下，往往将 Header Field 简称为 Header 。需要注意的是，如果用户在本次页面访问之前已经到访过网站或者已经登录，则一般都会在请求头中附加一个或多个被称为 Cookie 的数据项，其中记录了用户上一次访问时的状态或者身份信息，我们只需理解浏览器在发起请求时会带上一个标明用户身份的 Cookie 即可。
请求正文（ HTTP Message Body ）。这 部分是可选的， 般而言，HTTP 请求的正文都是 的，可以忽略。
一个标准的 HTTP 应也由三部分构成。
状态行。状态行标识了服务器对于此次 HTTP 请求的处理结果状态行内的主要内容是一个由三位数字构成的状态码，我们最熟知的两个状态码分别是代表成功响应的 200 (OK ）和代表所请求的资源在服务器端没有被找到的 404 (Not Found ）。
日志采集思路：在 HTML 文档内的适当位置增加一个日志采集节点，当浏览器解析到这个节点时，将自动触发 个特定HTTP 请求到日志采集服务器。
页面浏览日志采集过程:
( 1 ）客户端日志采集。日志采集工作 般由 小段被植人页面HTML 文档内的 JavaSc ript 脚本来执行。
(2 ）客户端日志发送。采集脚本执行时，会向日志服务器发起请求，以将采集到的数据发送到日志服务器。
(3 ）服务器端日志收集。日志服务器接收到客户端发来的日志请求后，一 般会立即向浏览器发回 个请求成功的响应，以免对页面的正常加载造成影响；同时，日志服务器的日志收集模块会将日志请求内容写入一个日志缓冲区内，完成此条浏览日志的收集。
(4 ）服务器端日志解析存档。服务器接收到的浏览日志进人缓冲区后，会被 段专门的日志处理程序顺序读出并按照约定的日志处理逻辑解析。
经过来集 发送 收集 解析存档四个步骤，我们将 次页面浏览日志成功地记录下来。
页面交互日志采集
具体而言，“黄金令箭”是一个开放的基于 HTT 协议的日志服务，需要采集交互日志的业务（下文简称“业务方”），经过如下步骤即可将自助采集的交互日志发送到日志服务器。
( l ）业务方在“黄金令箭”的元数据管理界面依次注册需要采集交互日志的业务、具体的业务场景以及场景下的具体交互采集点，在注册完成之后，系统将生成与之对应的交互日志来集代码模板。
(2 ）业务方将交互日志采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定。
(3 ）当用户在页面上产生指定行为时，采集代码和正常的业务互动响应代码一 起被触发和执行。
(4 ）采 集代码在采集动作完成后将对应的日志通过 HTTP 协议发送到日志服务器，日志服务器接收到日志后，对于保存在 HTTP 请求参数部分的自定义数据，即用户上传的数据，原则上不做解析处理，只做简单的转储。
页面日志的服务器端清洗和预处理
但在大部分场合下，经过上述解析处理之后的日志并不直接提供给下游使用。基于如下几个原因，对时效要求较宽松的应用场合下，一般还需要进行相应的离线预处理。
( 1 ）识别流量攻击、网络爬虫和流量作弊（虚假流量）。
(2 ）数据缺项补正。
(3 ）无效数据剔除。
(4 ）日志隔离分发。
原始日志经过上述的清洗、修正，并结构化变形处理之后， Web页面日志的采集流程就算完成了。此时的日志已经具备了结构化或者半结构化的特征，可以方便地被关系型数据库装载和使用。
2.无线客户端的日志采集
众所周知，日志来集多是为了进行后续的数据分析。移动端的数据采集，一是为了服务于开发者，协助开发者分析各类设备信息；二是为了帮助各 PP 更好地了解自己的用户，了解用户在 APP 上的各类行为帮助各应用不断进行优化，提升用户体验。
无线客户端的日志采集采用采集 SOK 来完成，在阿里巴巴内部，多使用名为 UserTrac 来进行无线客户端的日志采集。无线客户端的日志采集和浏览器的日志采集方式有所不同，移动端的日志采集根据不同的用户行为分成不同的事件，“事件”为无线客户端日志行为的最小单位。基于常规的分析， serTrack (UT ）把事件分成了几类，常用的包括页面事件（同前述的页面浏览）和控件点击事件（同前述的页面交互）等。
页面事件：
每条页面事件日志记录三类信息 ①设备及用户的基本信息：②被访问页面的信息，这里主要是一些业务参数（如商品详情页的商品 ID 、所属的店铺等） ; ③访问基本路径（如页面来源、来源的来源 ），用于还原用户完整的访问行为。
控件点击及其他事件：
控件点击事件比页面事件要简单得多，首先，它和页面事件一样，记录了基本的设备信息、用户信息：其次，它记录了控件所在页面名称、控件名称、控件的业务参数等。由于控件点击事件的逻辑简单得多，就是操作页面上的某个控件，因此只需把相关基础信息告诉采集 即可。
H5 & Native 日志统一：
APP 分为两种：一种是纯 Native APP; 一种是既有 Native又有 H5 页面嵌入的 APP ，即 Hybrid APP 。当前，纯 Native APP 经非常少了，一般都是 Hybrid APP Native 页面采用采集 SDK 进行日 志采集， H5 页面 般采用基于浏览器的页面日志采集方式进行采集。在当前的实践中，由于采集方式的不同，采集到的内容及采集服务器均分开。考虑到后续日志数据处理的便捷性、计算成本、数据的合理性及准确性，我们需要对 Native H5 日志进行统 一处理。
设备标识：无线设备唯一标识使用 UTDID ，它 当然有很清晰的责任和目标，就是每台设备一个 ID 作为唯 标识。
日志传输：无线客户端日志的上传，不是产生一条日志上传一条，而是无线客户端产生 日志后，先存储在客户端本地，然后再伺机上传。所谓伺机，就需要有数据分析的支持，如在启动后、使用过程中、切换到后台时这些场景下分别多久触发一次上传动作。当然单纯地靠间隔时间来决定上传动作是不够的，还需要考虑日志的大小及合理性（如单条日志超大，可能就是错误日志）。另外，还需要考虑上传时网络的耗时，来决定是否要调整上传机制。
将数据追加到本地文件中进行存储，存储方式使用 Nginx access_log, access_log 的切分维度为天。
3.日志采集的挑战
典型场景：（1）日志分流与定制处理：
大型互联网网站的日志类型和日志规模都呈现出高速增长的态势，而且往往会出现短时间的流量热点爆发。这一特点，使得在日志服务器端采用集中统一的解析处理方案变得不可能，其要求在日志解析和处理过程中必须考虑业务分流（相互之间不应存在明显的影响，爆发热点不应干扰正常业务日志的处理）、日志优先级控制，以及根据业务特点实现定制处理。
（2）采集与计算一体化设计
阿里日志采集针对这一问题给出的答案是两套日志规范和与之对应的元数据中心 。
（3）大促保障
从端上埋点采集，到日志服务器收集，经过数据传输，再到日志实时解析、实时分析，任何一个环节出现问题，全链路保障就是失败的考虑到服务器的收集能力（如峰值 等）、数据传输能力（ TT 的搬运速度）、实时解析的吞吐量、实时业务分析的处理能力，我们在各环节都做了不少的工作。
