大数据：日志采集

一、概述

• 数据采集渠道：主要采集 Web 端和 App 端日志数据；
•  数据加工分层理念：操作数据层（Operational Data Store ，ODS）、明细数据层（Data Warehouse Detail，DWD）、汇总数据层（Data Warehouse Summary，DWS）、应用数据层（Application Data Store，ADS）。
• 元数据模型整合及应用主要组成部分：数据源元数据、数据仓库元数据、数据链路元数据、工具类元数据、数据质量类元数据等。
• 元数据：其应用主要面向数据发现、数据管理等，如用于存储、计算和成本管理等。
• 数据服务层对外提供数据服务主要通过统一的数据服务平台（OneService）。
• OneService 以数据仓库整合计算好的数据作为数据源，对外通过接口的方式提供数据服务，主要提供：简单数据查询、复杂数据查询（承接集团用户识别、用户画像等）、实时数据推送。

 

二、浏览器的日志采集

• 页面浏览日志采集：当一个页面被浏览器加载呈现时采集的日志。（是目前所有互联网产品的两大基本指标：页面浏览量(Page View，PV) 和访问量(Unique Visitors，US) 的统计基础。）
• 页面交互日志采集：当页面加载和渲染完成后，用户在页面上的各种操作。

 

1、网页浏览日志采集

　　1）网页浏览过程

• 网页访问过程：浏览器请求、服务器响应并返回请求的内容；（浏览器和服务器之间通信准守 HTTP 协议，浏览器发起的请求称 HTTP 请求(HTTP Requesst)，服务器的返回称 HTTP 响应(HTTP Response)）
• 
• 1/1 ：浏览器发起请求 

　　　　# 一个标准的 HTTP 请求：请求行（HTTP Request Line）、请求报头（HTTP Message Header）、请求正文（HTTP Message Body）。

　　　　　　 # 请求行三要素：请求方法、所请求资源的 URL 以及 HTTP 协议版本号。（例：GET、http://www.taobao.com、HTTP1.1）

　　　　　　# 请求报头：浏览器在请求时向服务器提交的附加信息。

　　　　　　　　# 请求报头一般包含很多内容项（每个内容项称为一个头域(Header Field)），如果用户浏览过网址或者已经登录，请求头中会附加一个或多个Cookie 项。

　　　　　　# 请求正文：该部分是可选的，一般 HTTP 请求的正文都是空白的。

• 1/2 ：服务器接收并分析请求

• 一个标准的 HTTP 响应：状态行、响应报头、响应正文。

　　　　# 状态行：标识服务器怼此次 HTTP 请求的处理结果。

　　　　　　# 主要内容一个三位数状态码。（例，202：成功响应、404：所请求的资源在服务器端没有被找到）

　　　　# 响应报头：最重要的一类 Header 为 Cookie；

• 例：如果用户在页面登录，服务器会在登录请求的响应报头内指示浏览器新增一个名为 userid 的 Cookie 项，其中记录了登录用户的 id，当用户随后再次访问该网站时，浏览器自动在请求报头内附加这个 Cookie，服务器由此即可得知本次请求对应的用户到底是谁；如果服务器发现浏览器在请求时传递过来的 Cookie 有缺失、错误或需要更新，则会在响应报头内指令浏览器增加或更新对应的 Cookie。

　　　　# 响应正文：为可选部分，但一般不为空，浏览器请求的文档、图片、脚本等，被包含在响应正文中。

• 1/3：浏览器接收到服务器的响应内容，并将其按照文档（HTML 文档）规范展现给用户，从而完成一次请求。

 

　　2）采集

• 方法：在 HTML 文档适当位置增加一个日志采集节点，当浏览器解析到这个节点时，将触发一个特定的 HTTP 请求到日志采集服务器，当日志采集服务器接收到这个请求时，即可确定浏览器已经成功地接收和打开了页面。

• 日志采集节点不能放在网页浏览过程的前两步中，只能放在浏览器开始解析 HTML 文档中，因为只有浏览器开始解析 HTML 文档时才能确保用户已确实打开页面。
• 

• 2/1：客户端日志采集

1. 日志采集工作由一段被植入页面 HTML 文档内的 JavaScript 脚本执行。
2. 采集脚本被浏览器加载解析后执行，在执行时采集当前页面参数、浏览行为的上下文信息（如读取用户访问当前页面时的上一步页面）、运行环境信息（如当前的浏览器和分辨率等）。
3. 采集脚本可以由业务服务器在响应业务请求时动态执行，也可以在开发页面时由开发人员手动植入。

• 2/2：客户端日志发送

1. 采集脚本执行时，向日志服务器发起一个日志请求，以将采集到的数据发送到日志服务器。
2. 大多数情况，采集完成后会立即执行发送，但在个别场景下，日志采集后可能会经过一段的时间延迟才被发送。
3. 日志采集和发送模块一般集成在同一个 JavaScript 脚本文件内，通过 HTTP 协议与日志服务器通信，将采集到的日志一般以 URL 参数形式放在 HTTP 日志请求的请求行。

• 2/3：服务器端日志收集

1. 日志服务器收到客户端发来的日志请求后，一般会立即向浏览器发送一个请求成功的响应，以免对页面的正常加载造成影响；同时，日志服务器的日志收集模块会将日志请求内容写入一个日志缓冲区，完成此条浏览器日志的收集。

• 2/4：服务器日志解析存档

1. 服务器接收到的浏览日志进入缓冲区后，被一段专门的日志处理程序顺序读出并按照约定的日志处理逻辑解析。由日志采集脚本记录在日志请求行内的参数，将在这个环节被解析（有时候伴随着转义和解码）出来，转存入标准的日志文件中并注入实时消息通道内供其他后端程序读取和进一步加工处理。

 

2、页面交互日志采集

• PV 日志采集得到用户访问过的页面和访问路径，不能得到用户访问某个页面时具体的互动行为特征，比如鼠标或输入焦点的移动变化（代表用户关注内容的变化）、对某些页面交互的反应（可借此判断用户是否对某些页面元素发生认知困难）等。
• 阿里交互日志采集（基于“黄金令箭”(一个开放的基于 HTTP 协议的日志服务)）

1. 业务方在“黄金令箭”的元数据管理界面依次注册需要采集交互日志的业务、具体的业务场景以及场景下的具体交互采集点，系统将生产与之对应的交互日志采集代码模板。
2. 业务方将交互日志采集代码植入目标页面，并将采集代码与需要检测的交互行为做绑定。
3. 当用户在页面上产生制定行为时，采集代码和正常的业务互动响应代码一起被触发和执行。
4. 采集代码在采集动作完成后将对应的日志通过 HTTP 协议发送到日志服务器，日志服务器接收到日志后，对于保存在 HTTP 请求参数部分的自定义数据，即用户上传的数据，原则上不做解析处理，只做简单的转存。

 

3、页面日志的服务器端清洗和预处理

• 采集到的页面浏览日志与交互日志，不能直接提供给下游使用，需要进行相应的离线预处理：

　　# 1）识别流量攻击、网络爬虫、流量作弊（虚假流量）

　　　　# 依托算法识别非正常的流量并归纳出对应的过滤规则加以滤除。

　　# 2）数据缺项补正

　　　　# 为了便利后续的日志应用、保证基本的数据统计口径一致，需要对日志中的一些公用且重要的数据做取值归一、标准化处理或反向补正。

　　　　# 反向补正：根据新日志对稍早收集的日志中的个别数据项做回补或修订。

　　# 3）无效数据剔除

　　　　# 因业务变更或配置不当，产生无意义、已经失效或者冗余的数据。

　　　　# 定期检查配置并依照配置剔除无效数据。

　　# 4）日志隔离分发

　　　　# 分离原因：基于数据安全或者业务特性。

• 预处理后的数据，具备了结构化或者半结构化，才能被关系型数据库装载和使用。

 

三、无线客户端的日志采集

• 无线客户端的日志采集采用 “采集 SDK” 来完成。（阿里内部多采用 UserTreak）
• 移动端的日志采集根据不同的用户行为分成不同的事件，“事件” 为无线客户端日志行为的最小单位，SDK 把事件分成了几类，常用的：页面事件（同页面浏览）、控件点击事件（同页面交互）。

1、页面事件

• 每条页面事件日志几类三类信息：设备及用户的基本信息、被访问页面的信息（主要是业务参数：如商品详情页的商品ID、所属店铺等）、访问基本路径（页面来源等），基于这三类信息，还原用户完整的访问行为。

1. 对于页面事件，不同的 SDK 有不同的实现，UT 采用无痕埋点，即无须开发者进行任何编码即可实现。
2. UT 的手动埋点：UT 提供了连个接口，分别在页面展现和页面退出时调用。
3. 例进入手机淘宝某店铺详情页：当进入店铺详情页时，调用页面展现接口（记录页面进入时的状态信息），但不发送日志；当从该店铺详情页离开时，调用页面退出接口，该接口会发送日志。
4. 除了页面展现和页面退出连个基础接口，UT 还提供了添加页面扩展信息的接口：在页面离开前，使用该接口提供的方法给页面添加相关的参数（如店铺ID、店铺类别等）。
5. 在页面进入时不发送日志，而在页面退出时发送日志的原因：考虑用户浏览页面的时长。
6. UT 还提供了透传参数功能 SPM：用于实现用户行为路径还原。

 

2、控件点击及其他事件

• 控件点击事件：操作页面上的某个控件，记录基本的设备信息、用户信息，以及控件所在页面名称、控件名称、控件的业务参数等。一般只需将相关基础信息告诉 SDK 即可。
• 其他事件：用户可以根据业务场景需要，使用自定义事件来采集相关信息。

 

3、特殊场景

• 页面浏览和交互为行为日志。
• 对于巨大的业务量来说，为了平衡日志大小、减小流量消耗、采集服务器压力、网络传输压力等，采集 SDK 提供了聚合功能。
• 聚合功能：对日志适当聚合，减少对日志采集服务器的请求、减小日志大小。
•  聚合功能的思路：每一个曝光的元素一般属于一个页面，利用页面的生命周期来实现适当的聚合及确定发送时机。
• 例：曝光日志，如果商品的一次曝光对应一条日志，那么在搜索结果页的一次滚动浏览过程中将产生几十条甚至上百条日志，从下游使用及分析角度来讲，其实只想知道哪些内容被曝光，此时为了平衡业务需求及减少全链路资源消耗，采集 SDK 提供了本地聚合功能，在客户端对这类日志进行聚合，上传聚合后的日志到采集服务器即可，
•  回退操作：在进行业务分析时，用户的回退操作作为特殊场景对待。（利用页面的生命周期，识别页面的复用，配合栈的深度来识别是否是回退行为）

 

4、H5 & Native 日志统一

•  Native APP：使用原生系统内核的，相当于直接在系统上操作。是我们传统意义上的软件，更加稳定。
• H5 APP：先得调用系统的浏览器内核，相当于是在网页中进行操作，较原生APP稳定性稍差。
• Hybrid APP：既有Native，又有H5页面嵌入。是当前大多数 APP 模式。
• Hybrid APP 日志采集的问题难点：Native 采用采集 SDK 进行日志采集，H5 采用基于浏览器的页面日志采集方式进行采集，由于采集方式不同，采集到的内容及采集服务器均分离开。但是若要进行完整的数据分析，需要将两类日志在数据处理是进行关联，增加了计算成本。而且就算不考虑处理成本，在很多情况下，Native 和 H5 互跳，及时关联也无法还原用户路径，数据丢失严重。（现实工作中：产品经理、运营、管理、数据分析人员，需要在不同终端采用不同的方案采集日志，一不同的算法来做日志统计，忍受多端的数据隔离，并对此导致的多样数据口径进行整理分析和解释）

• H5 & Natative 日志统一：
• 
• 思路：将两类日志进行归一（两种方法：把 Native 日志向 H5 日志归，或者把 H5 日志向 Native 日志归——具体选择时根据业务情况而定）。
• 阿里集团一般讲 H5 日志向 Native 日志归，原因有二：

1.  一是采用采集 SDK 可以采集到更多的设备相关数据，这在移动端的数据分析中尤为重要；
2. 二是采集 SDK 处理日志，会先在本地缓存，而后借机上传，在网络状态不佳时延迟上报，保证数据不丢失。

• 日志归一流程：

• 1）H5 页面浏览和页面交互的数据，在执行时通过加载日志采集的 JavaScript 脚本，采集当前页面参数，包括浏览行为的上下文信息以及一些运行环境信息。
• 在 APP 中打开 H5 页面和浏览器中的处理完全一样，在签订页面的开发中无须做任何特殊的处理，只需在页面开发时手动植入日志采集的 JavaScript 脚本即可。

• 2）在浏览器日志采集的 JavaScript 脚本中实现将所采集的数据打包到一个对象中，然后调用 WebView 框架的 JSBridge 接口，调用移动客户端对应的接口方法，将埋点数据对象当做参数传入。

• 3）移动客户端日志采集 SDK，封装提供接口，实现将传入的内容装换称移动客户端日志格式。
• 采集 SDK 会根据日志类别来识别是页面浏览事件，还是控件点击事件，人后调用内部响应的接口进行处理，将埋点数据装缓存移动客户端日志的统一格式。而后就同移动客户端的日志处理一样，先记录到本地日志缓存中，择机上传，
• 通过日志类别的识别类做不同的日志格式转换，这样，未来如果要实现新的事件类别，比如自定义事件，就不需要改动 WebView 层的接口，只需要改动 JavaScript 的部分内容及移动客户端日志采集 SDK 中对应的实现即可。

• 日志归一方法的弊端：必须要浏览器采集 JavaScript 、WebView、客户端采集 SDK 的配合，而往往很多时候业务并不希望做任何调整，更多的是希望减少依赖。

5、设备标识

•  PC 端一般使用 Cookie 信息来作为设备的唯一信息。
• APP ，一般使用 UDID，但是由于手机系统权限控制，需要用户授权才能获取。（阿里集团无线设备唯一标识使用 UTDID）

6、日志传输

• 无线客户端日志的上传，不是产生一条日志上传一条，而是无线客户端产生日志后，先存储在客户端本地，任何再伺机上传。

1. （伺机：需要有数据分析的支持，如在启动后、使用过程中、切换到后台时这些场景下分别多久触发一次上传动作。）
2. （单纯地靠间隔时间来决定上传动作是不够的，还需要考虑日志的大小及合理性(如单条日志超大，很可能就是错误日志)，另外还需要考虑上传时网络的耗时，来决定是否调整上传机制）

• 上传过程：

1. 客户端向服务器发送 POST 请求；
2. 服务器端出来上传请求，对请求进行相关校验，将数据追加到本地文件中进行存储（存储方式：使用 Nginx 的 access_log，access_log 的切分维度为天，即当天接收的日志存储到当天的日志文件中）。
3. 分流：由于后续的数据处理，以及特殊是不同日志的保障级别，对日志进行分流。

• 例：阿里集团的 Ada是（无线日志服务器处理程序），根据应用及事件类型对每日高达数千亿的日志进行了分流。（如“双11”时，日常数千亿的日志可能冲高达万亿，此时服务器及后续的数据计算压力就非常大，而对于重要的数据计算来说，很可能只需要页面事件及控件点击事件即可，此时就可以适当地释放其他类型日志的资源来处理更重要的页面事件及控件点击事件。）

• 日志采集服务器的日志怎么给到下游？

1. 方法很多，阿里集团主要使用消息队列（TimeTunel，TT），TT 将消息收集功能部署到日志采集服务器上进行消息的收集，而后续的应用可以是实时的应用实时来订阅 TT 收集到的消息，进行实时计算，也可以是离线的应用定时来获取消息，完成离线的计算。

四、日志采集的挑战

• 目前，面对海量的数据，各类采集方案提供者所面临的主要挑战不是日志采集技术本身，而是如何实现日志数据的结构化和规范化组织，实现更为高效的下游统计计算，提供符合业务特性的数据展现，以及为算法提供更编辑、灵活的支持等。

1、典型场景

• 两个实例场景及阿里集团采用的解决方案：

• 1）日志分流与定制处理

• 问题：大型互联网网站的日志类型和日志规模都呈现出高速增长态势，而且往往会出现短时间的流量热点爆发，是的在日志服务器端采用集中统一的解析处理方案变得不可能，其要求在日志解析和处理过程中必须考虑业务分流（相互之间不应存在明显的影响，爆发热点不应干扰定常业务日志的处理）、日志优先级控制，以及根据业务特点实现定制处理。
•  例：电商网站，数据分析人员对位于点击流前端的促销页面和位于后端的商品页面的关注点是不一样的，而这两类页面的流量有往往同等重要且庞大，如果采用统一的解析处理方案，往往需要在资源浪费（尽可能多地进行预处理）和需求覆盖不全（仅对最重要的内容进行预处理）两个选择间进行取舍。
• 阿里集团解决方案：分治。（阿里互联网日志采集体系基本原则）

1. 尽可能靠前地布置路由差异，可以尽可能早地进行分流。（降低日志处理过程中的分支判断消耗，并作为后续的计算资源调配的前提，提高资源利用效率）
2. 特点：非常高的更新频次，实现更新的配置化，不仅考虑注入日志分流处理之类的日志服务器端分布计算方案，而且将匪类任务前置到客户端以实现整个系统的效能最大化。

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

• PV 日志采集之后的基本操作是日志的归类与汇总。
• 早期的互联网日志分析实践中，是以 URL 路径，继而以 URL（正则）规则集为依托来进行日志分类的。

1. （特点及弊端：在网络规模较小时运行，但随着网站的大型化和开发人员的增加，URL 规则集的维护和使用成本增长到不现实的程度）
2. 解决方法：将日志采集与计算作为一个系统来考量，进行一体化设计。
3. 阿里方案：两套日志规范和与之对应的元数据中心。
4. PV 日志：SPM 规范和 SPM 元数据中心。（通过 SPM 的注册和简单部署，用户即可将任意的页面流量进行聚类，统计得到的流量、转化漏斗、引导交易等数据，以及页面各元素点击数据的可视化）
5. 自定义日志（交互日志）：黄金令箭（Goldlog）/APP 端的点击或其他日志规范及其配置中心。

• 互联网日志的规模化采集方案必须具备一个与终端设备的技术特点无关，具有高度扩展弹性和适应性，同时深入契合应用需求的业务逻辑模型，并基于此制定对应的采集规范交友产品开发人员执行。若非如此，则不足以保障采集——解析——处理——应用整个流程的通畅。

• 日志本身不是日志采集的目的，服务于基于日志的后续应用，才是日志采集正确的着眼点。

2、大促保障

• 从端上埋点采集，到日志服务器收集，经过数据传输，再到日志实时解析、实时分析，任何一个环节出现问题，全链路保障就是失败的。

•  必须考虑的情况：服务器的收集能力（如峰值 QPS）、数据传输能力（TT 的搬运速度）、实时解析的吞吐量、实时业务分析的处理能力。

• 

• 数据处理全链路的特点：

1. 端上实现了服务器推送配置到客户端，且做到高到达率；
2. 对日志做了分流，结合日志的重要程度及各类日志的大小，实现了日志服务器端的拆分；
3. 在实时处理方面，做了不少的优化以提高应用的吞吐量。

• 在上面几项的基础上，结合实时处理能力，评估峰值数据量，在高峰期通过服务器端推送配置的方式对非重要日志济宁适当限流，错峰后逐步恢复。
• 服务器推送配置包含较多内容：

1. 首先是作用范围，可以针对应用、平台、事件、事件中的某个场景；
2. 其次是具体实施，包括延迟上报、部分采样等；

• （延迟上报：配置生效后，满足条件的日志将被暂时存在客户端，待配置恢复后再上传到服务器）；
• （部分采样：配置生效后，满足条件的日志将被实施采样（对于一些技术类日志，如页面加载情况、消耗内存等，可以实施采样），只上报部分日志到服务器）

• 对于实时性要求较高的业务场景，上链路不能满足需求：从业务上进行改造，采用端上记录；另一方面，在链路各个环节做优化，如从采集服务器直接完成解码并调用业务 API 完成业务的计算（省去中间的传输和过多的处理）。