大数据之路-日志采集（第二章）

阿里巴巴的日志采集体系方案包括两大体系： Ap us.JS Web（基于浏览器）日志采集技术方案： UserTrack APP 端（无线客户端
日志采集技术方案。
本章从浏览器的页面日志采集、无线客户端的日志采集以及我们遇到的日志采集挑战三块内容来阐述间里巴巴的日志采集经验。

2.1 浏览器的页面日志采集

浏览器的页面型产品／服务的日志采集可分为如下两大类。
( 1 ）页面浏览（展现）日志采集。顾名思义，页面浏览日志是指当一个页面被浏览器加载呈现时采集的日志。此类日志是最基础的互联网日志， 也是目前所有互联网产品的两大基本指标：页面浏览量（ PageView, PY ）和访客数（ Unique Visitors, UV ）的统计基础。页面浏览日志是目前成熟度和完备度最高 ，同时也是最具挑战性的日志来集任务，我们将重点讲述 类日志 的采集。
(2 ）页面交互日志采集。当页面加载和渲染完成之后，用户可以在页面上执行各类操作。随着互联 网前端技术的不断发展，用户可在浏览
器内与网页进行的互动已经丰富到只有想不到没有做不到的程度，互动设计都要求采集用户的互动行为数据 ，以便通过 化获知用户的兴趣点或者体验优化点。交互日志采集就是为此类业务场景而生的。
除此之外 还有 些专门针对某些特定统计场合的日志采集需求，如专门采集特定媒体在页面被曝光状态的曝光日志、用户在线状态的实时监测等，但在基本原理上都脱胎于上述两大类。限于篇幅，此内容在本书中就不予展开介绍了。

2.1.1 页面浏览日志采集流程

网站页面是互联网服务的基本载体，即使在如今传统互联网形态逐渐让位于移动互联网 的背景下 HTML 页面依旧是最普遍的业务形态，
对于以网页为基本展现形式 互联网产品和服务，衡量其业务水平的基本指标是网页浏览量 PV ）和访客数（ UV ）。为此，我们需要采集页
面被浏览器加载展现的记录，这是最原始的互联网日志采集需求，也是切互联网数据分析得以展开的基础和前提。
目前典型的网页访问过程是以浏览器请求、服务器响应并返回所请求的内容 （大 多以 HTML 文档的形式）这种模式进行的，浏览器和服
务器之间的通信普遍遵守 HTTP 协议（超文本传输协议，目前以 HTTP1.1 为主，逐渐向最新的 HTTP 2.0 过渡）。浏览器发起的请求被称为HTTP 请求（ HTTP Request ），服务器的返回则被称为 HTTP 响应（ HTTPResponse）
我们以用户访问向宝首页（ www.taobao.com ）为例， 次典型的页面访问过程描述如图 2.1 示。

（1）用户在浏览器内点击淘宝首页链接（或在地址栏中输人www.taobao.com 并回车）。
（2）浏览器向淘宝服务器发起 HTTP 请求。在本例子中，用户可以看见的内容只是显示于浏览器地址栏内的 http://www.taobao.com ，而浏览器在执行时，会解析用户请求并按照 HTTP 协议中约定的格式将其转化为 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 请求的正文都是 的，可以忽略。
（3）服务器接收并解析请求。服务器端的业务处理模块按业务逻辑处理本次请求并按照 HTT 协议规定的格式，将处理结果以 HTTP响应
形式发回浏览器。
HTTP 请求相对应，一个标准的 HTTP 应也由三部分构成。
·状态行。状态行标识了服务器对于此次 HTTP 请求的处理结果状态行内的主要内容是一个由三位数字构成的状态码，我们最熟
知的两个状态码分别是代表成功响应的 200 (OK ）和代表所请求的资源在服务器端没有被找到的 404 (Not Found ）。
响应报头。服务器在执行响应时，同样可以附加 些数据项，这些数据项将在浏览器端被读取和使用。事实上，在大多数页面和应用中，响应报头内的内容在确保页面正确显示和业务正常进行方面都发挥着至关重要的作用。其中最重要的一类 Header 即上面所提到的 Cookie ，浏览器所记录的 Cookie ，其实是由服务器在响应报头内指令浏览器记录的。举个例子 ，如果用 户在页面登录，则服务器会在登录请求的响应报头内指示浏览器新增一个名为use rid Cookie 项， 其中记录了登录用户的 id 。如 一来当用户随后再次访问该网站时，浏览器将自动在请求报头内附加这个 Cookie ，服务器由此即可得知本次请求对应的用户到底是谁：如果服务器发现浏览器在请求时传递过来的 Cookie 有缺失、错误或者需要更新，则会在响应报头内指令浏览器增加或更新对应的 Cookie。
·响应正文。和请求正文一样，这一部分在协议中 也被定义为可选部分，但对于大多数 HTTP 响应而言，这一部分都是非空的，浏览器请求的文档、图片、脚本等，其实就是被包装在正文内返回浏览器的。在本例子中，服务器会将淘宝首页对应的 HTML档封装在正文内。
（4）浏览器接收到服务器的响应内容，并将其按照文档规范展现给用户，从而完成一次请求。在本例子中，浏览器请求淘宝首页，服务器
返回对应的 HTML 文档，浏览器即按照 HTML 文档规范解析文档并将整个页面渲染在屏幕上。

上面描述了一次典型的网页浏览过程，如果需要记录这次浏览行为，则采集日志的动作必然是附加在上述四个步骤中的某 环节内完成
的。那么采集日志的动作，需要在第四步，也就是浏览器开始解析文档时才能进行（前三步尚不能确保用户已确实打开页面）。所以在第四步服务器响应浏览器的 HTML 文档内的适当位置增加一个日志采集节点，当浏览器解析到这个节点时，将自动触发 个特定的HTTP 请求到日志采集服务器。如此一来，当日志采集服务器接收到这个请求时，就可以确定浏览器已经成功地接收和打开了页面。这就是目前几乎所有互联网网站页面浏览日志采集的基本原理，而业界的各网页日志采集的解决方案只是在实施的细节、自动采集内容的广度以及部署的便利性上有所不同。

目前阿里巴巴采用的页面浏览日志采集方案的流程框架如图 2.2示。在图 2.2 所示的页面浏览日志采集过程中，所涉及的日志相关的几个主要过程简单介绍如下：

（1）客户端日志采集。日志采集工作 般由 小段被植人页面HTML 文档内的 JavaSc ript 脚本来执行。采集脚本被浏览器加载解析后执行，在执行时采集当前页面参数、浏览行为的上下文信息（如读取用户访问当前页面时的上 步页面）以及 些运行环境信息（如当前的浏览器和分辨率等）。
（2）客户端日志发送。采集脚本执行时，会向日志服务器发起一个日志请求，以将采集到的数据发送到日志服务器。日志采集和发送模块 般会集成在同一个JavaScript 脚本文件内，且通过互联网浏览器必然支持的 HTTP 协议与日志服务器通信，采集到的日志信息 般以 URL 参数形式放在 HTTP日志请求的请求行内。
（3）服务器端日志收集。日志服务器接收到客户端发来的日志请求后，一般会立即向浏览器发回一个请求成功的响应，以免对页面的正常加载造成影响；同时，日志服务器的日志收集模块会将日志请求内容写入一个日志缓冲区内，完成此条浏览日志的收集。
（4）服务器端日志解析存档。服务器接收到的浏览日志进人缓冲区后，会被一段专门的日志处理程序顺序读出并按照约定的日志处理逻辑
解析。由日志采集脚本记录在日志请求行内的参数，将在这个环节被解析（有时候伴随着转义和解码）出来，转存入标准的日志文件中并注人实时消息通道内供其他后端程序读取和进 步加工处理。

2.1.2 页面交互日志采集流程

因为终端类型 页面内容、交互方式和用户实际行为的千变万化不可预估，交互日志的采集和 日志的采集不同，无法规定统 的采集内容，呈现出高度自定义的业务特征。与之相适应，在阿里巴巴的日志采集实践中，交互日志的采集（即“黄金令箭”）是以技术服务的形式呈现的。
具体而言，“黄金令箭”是一个开放的基于 HTT 协议的日志服务，需要采集交互日志的业务（下文简称“业务方”），经过如下步骤即可将自助采集的交互日志发送到日志服务器。
（1）业务方在“黄金令箭”的元数据管理界面依次注册需要采集交互日志的业务、具体的业务场景以及场景下的具体交互采集点，在注册完成之后，系统将生成与之对应的交互日志来集代码模板。
（2）业务方将交互日志采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定。
（3）当用户在页面上产生指定行为时，采集代码和正常的业务互动响应代码 起被触发和执行。
（4）采 代码在采集动作完成后将对应的日志通过 HTTP 协议发送到日志服务器，日志服务器接收到日志后，对于保存在 HTTP 请求参数
部分的自定义数据，即用户上传的数据，原则上不做解析处理，只做简单的转储。

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

上面介绍了阿里巴巴的两类浏览器页面日志的采集方案，并粗略介绍了日志到达日志服务器之后的解析处理。但在大部分场合下，经过上
述解析处理之后的日志并不直接提供给下游使用。基于如下几个原因，在对时效要求较宽松的应用场合下，一般还需要进行相应的离线预处理。
（1）识别流量攻击、网络爬虫和流量作弊（虚假流量）。页面日志是互联网分析和大数据应用的基础源数据，在实际应用中，往往存在占一定比例的虚假或者恶意流量日志，导致日志相关指标的统计发生偏差或明显谬误。为此，需要对所采集的日志进行合法性校验，依托算法识别非正常的流量并归纳出对应的过滤规则集加以滤除。这是 个长期而艰苦的对抗过程。
（2）数据缺项补正。为了便利后续的日志应用和保证基本的数据统计口径一致，在大多数情况下，需要对日志中的一些公用且重要的数据项做取值归一 、标准化处理或反向补正。反向补正，即根据新日志对稍早收集的日志中的个别数据项做回补或修订（例如，在用户登录后，对登录前页面日志做身份信息的回补）。
（3）无效数据剔除。在某些情况下，因业务变更或配置不当，在采集到的日志中会存在一些无意义、已经失效或者冗余的数据项。这些数
据项不仅消耗存储空间和运算能力，而且在偶然的情况下还可能干扰正常计算的进行。为了避免此类异常的发生，需要定时检查配置并依照配置将此类数据项剔除。
（4）日志隔离分发。基于数据安全或者业务特性的考虑，某些日志在进入公共数据环境之前需要做隔离。
原始日志经过上述的清洗、修正，并结构化变形处理之后， Web页面日志的采集流程就算完成了。此时的日志已经具备了结构化或者半
结构化的特征，可以方便地被关系型数据库装载和使用。

2.2 无线客户端的日志采集

无线客户端的日志采集采用采集 SDK 来完成，在阿里巴巴内部，多使用名为 UserTrac 来进行无线客户端的日志采集。无线客户端的日志采集和浏览器的日志采集方式有所不同，移动端的日志采集根据不同的用户行为分成不同的事件，“事件”为无线客户端日志行为的最小单位基于常规的分析， serTrack (UT ）把事件分成了几类，常用的包括页面事件（同前述的页面浏览）和控件点击事件（同前述的页面交互）等。

2.2.1 页面事件

每条页面事件日志记录三类信息 ①设备及用户的基本信息：②被访问页面的信息，这里主要是一些业务参数（如商品详情页的商品 ID 、所属的店铺等） ; ③访问基本路径（如页面来源、来源的来源 ），用于还原用户完整的访问行为。
对于页面事件，不同的 有不同的实现，有些采集 SD 选择在页面创建时即发送日 志。结合业务分析， 提供了页面事件的无痕埋点， 即无须开发者进行任何编码即可实现。限于篇幅，本处主要讲一下手动模式的埋点。 UT 提供了两个接口，分别在页面展现和页面退出时调用。以进入手机淘宝的某店铺详情页来举例，当进入该店铺详情页时，调用页面展现的接口，该接口 记录页面进人时的 些状态信息，但此时不发送日志；当从该店铺详情页离开时（可能是在店铺详情页上点击某个商品到了对应的商品详情页，也可能是退出了手机淘宝，抑或是点击返 回，返回到了之前的一个页面），调用页面退出的接口，该接口会发送 日志 。除了基础的两个接口外，还提供了添加页面扩展信息的接口；在页面离开前，使用该接口提供的方法给页面添加相关 数，比如给店铺详情页添加店铺 ID 、店铺类别（天猫店铺或淘宝店铺） 等。
显然 上述三个接口方法必须配合使用，即页面展现和页面退出方法必须成对使用，而页面扩展信息的接口必须在使用页面展现和页面退
出方法的前 下使用。在页面离开时发送日志，此时页面停留时长就是天然自带的准确值了。
上述三个方法是采集 SDK 提供的页面事件采集的基础方法 除此之外，为了平衡采集、计算和分析的成本，在部分场景下我们选择采集更多的信息来减少计算及分析的成本。于是， UT 提供了透传参数功能。所谓透传参数，即把当前页面的某些信息，传递到下一个页面甚至下下一个页面的日志中。在阿里系内，使用 SPM (Super Position Model ，超级位置模型）进行来源去向的追踪，在无线客户端也同样使用SPM, SPM 信息就可以通过透传机制带人到下一步甚至下下一步的浏览页面，这样整个用户行为路径还原就轻松实现了。

2.2.2 控件点击及其他事件

和浏览器客户端的日志采集一样 ，交互日志的采集无法规定统一的采集内容，交互类的行为呈现出高度自定义的业务特征。与之相适应，在网里巴巴的无线客户端日志采集实践中，将交互日志采集从页面事件采集中剥离出来，这就是控件点击事件和其他事件。
先来说说控件点击事件。控件点击事件比页面事件要简单得多，首先，它和页面事件一样，记录了基本的设备信息、用户信息：其次，它记录了控件所在页面名称、控件名称、控件的业务参数等。由于控件点击事件的逻辑简单得多，就是操作页面上的某个控件，因此只需把相关
基础信息告诉采集即可。
再来说说其他事件。所谓其他事件，就是用户可以根据业务场景需求，使用自定义事件来采集相关信息。从某种程度上说，它几乎能满足用户的所有需求，包括页面事件和控件点击事件，只是若采用通用的页面事件埋点方法， 会帮助实现一些额外的功能（如上个页面的信息）。
UT 提供了一个自定义埋点类，其包括：①事件名称：②事件时长 ③事件所携带的属性：④事件对应的页面。当然，具体实现什么功能，需要带哪些内容，各个采集 SDK 可以自行决定。
除了上述这些需要应用开发者触发的日志采集接口方法外，UT还提供了一些默认的日 志采集方法 ，比如可以自动捕获应用崩溃，并且产
生一条 日志记录崩溃相关信息。类似的日志采集方法还有很多，比如应用的退出 页面的前后台切换等。诸如 些和业务信息不是非常相关，
但又对分析起很大作用的日志采集 ，就完全没有必要让应用开发者去触发埋点了。

2.2.3 特殊场景

上述场景均为一个行为产生一条日志，如一次浏览、一次点击等。如此用来处理普通的业务是足够的，但对于阿里巴巴巨大的业务体量来说，为了平衡日志大小，减小流量消耗、采集服务器压力、网络传输压力等，采集 SDK 提供了聚合功能，对某些场景如曝光或一些性能技术类日志 ，我们提倡在客户端对这类日志进行适当聚合，以减少对日志采集服务器端的请求 ，适当减小日志大小。总体思路就是每个曝光的元素一般都属于一个页面，利用页面的生命周期来实现适当的聚合及确定发送时 。拿曝光日志来举例，若 个商品的一次曝光就对应一条日志的话，那么在搜索结果页的一次滚屏浏览过程中将产生几十条甚至上百条日志，从下游使用及分析的角度来说，其实只是想知道哪些内容被曝光，此时为了平衡业务需求及减少全链路资源消耗，采集 SDK 提供了本地聚合功能，在客户端对这类日志进行聚合，上传聚合后的日志到采集服务器即可。同时对于一些只需要计数，而不需要知道具体内容的场景，如需要分析某些接口的调用次数，此功能就更加凸显出其作用了。
区别于浏览器的页面访问，在无线客户端用户的访问行为路径存在明显的回退行为（如点击回退按钮、各种滑屏等），在进行业务分析时，
回退同样作为特殊场景而存在。例如，“双 11 ”主会场页 女装分会场→女装店铺 →回退到女装分会场→女装店铺 ，在这个访问路径中，若只是按照普通的路径来处理，则会认为第 次浏览的女装分会场来源为店铺 ，就会把女装分会场的 次浏览效果记为女装店铺 带来的倘若这样处理，就会发现类似的活动承接页其来源有 大部分均为各类详情页（店铺详情页／商品详情页），这必然干扰到分析。所以针对这种场景，我们做了特殊的设计，利用页面的生命周期，识别页面的复用配合校的深度来识别是否是回退行为。
如上列举了两个比较典型的特殊场景，随着业务的不断发展，业务的复杂性不断提高，采集需要处理的特殊场景也层出不穷，限于篇幅，此处不再 一展开介绍。

2.2.4 H5 & Native 日志统一

简单来说， APP 分为两种： 种是纯 Native APP; 种是既有 Native，又有 H5 页面嵌入的 APP ，即 Hybrid APP 。当前，纯 Native APP 经非常少了，一般都是 Hybrid APP Native 页面采用采集 SDK 进行日 志采集， H5 页面 般采用基于浏览器的页面日志采集方式进行采集。在当前的实践中，由于采集方式的不同，采集到的内容及采集服务器均分离开。若需要进行完整的数据分析，就需要将两类日在数据处理时进行关联。

要想实现Native HS 日 的统 处理，就需要对 Hybrid 日志有统一 方案。 的思路就是首先将两类日志进行归 。在阿 巴巴 团，分别考虑两条路的优缺点，考虑到两种日志来集方式的特点以及关注点，我们选择 Native 部署采集 SDK 的方式。
原因有二 一是采 SDK 可以采集到更 的设备相关数据，这在移动端的数据分析中尤为 要； 是采集 SDK 处理日志，会先在本地缓存，而后借机上传，在网络状况不佳时延迟上报，保证数据不丢失。基于这两点，我们选择将 HS 日志归到 Native 日志。
具体流程如下：
( 1) HS 页面浏览和页面交互的数据，在执行时通过加载日志采集的JavaScript 脚本，采集当前页面参数，包括浏览行为的上下文信息以及一 行环境信息。在 APP 中打开 HS 页面和在浏览器中的处理完全一样 ，在前端 面的开发中无须做任何特殊的处理，只需在页面开发时手动植入日 JavaScript 脚本即可。
(2 ）在浏览器日 JavaScript 脚本中实现将所采 的数据打包到一个对象中，然后调用 WebView 框架的 JSBridge 接口，调用移动
客户端对应的接口方法，将埋点数据对象当作参数传人。
(3 ）移动客户端日志采集 SDK ，封装提供接口，实现将传人的内容转换成移动客户端日志格式。采集 SDK 会根据日志类别来识别是页面浏览事件，还是控件点击事件，然后调用内部相应的接口进行处理，将埋点数据转换成移动客户端日志的统一格式。而后就同移动客户端的日志处理一样，先记录到本地日志缓存中，择机上传。通过日志类别的识别来做不同的日志格式转换，这样，未来如果要实现新的事件类别，比如自定义事件，就不需要改动 WebView 层的接口，只 需改动 JavaScript的部分内容及移动客户端日志采集 SDK 中对应的实现即可。
基于这种统一的方案，为后续构建完整的用户行为路径还原树打下了基础。当然，此方案也有其局限性，必须要浏览器采集 JavaScript
Web View 、客户端采集 SDK 的配合。而往往很多时候业务并不希望做任何调整，更多的是希望减少依赖。

2.2.5 设备标识

正如本章开头所说的，所有互联网产品的两大基本指标是页面浏览量（ Page View, PY ）和访客数（ Unique Visitors, UV ）。 关于 UV于登录用户，可以使用用户 ID 来进行唯 标识，但是很多日志行为并对不要求用户登录，这就导致在很多情况下采集上来的日志都没有用户ID PC 般使用 Cookie 信息来作为设备的唯一信息，对于 APP来说，我们就要想办法获取到能够唯一标识设备的信息。随着用户的自我保护意识加强以及各系统升级，很多基本的设备信息获取都不再那么容易。苹果 UDID 禁用， IDFA IMEI IMSI了权限控制， Android 新系统也对设备信息的获取做了权限控制。

2.2.6 日志传输

无线客户端日志的上传，不是产生一条日志上传一条，而是无线客户端产生 日志后，先存储在客户端本地，然后再伺机上传。
客户端数据上传时是向服务器发送 POST 请求，服务器端处理上传请求 ，对请求进行相关校验 ，将数据追加到本地文件中进行存储，存储
方式使用 Nginx access_log, access_log 的切分维度为天，即当天接收的日志存储到当天的日志文件中。考虑到后续的数据处理，以及特殊
时期不同日志的保障级别，还对日志进行了分流。对于重要的数据计算来说 ，很可能只需要页面事件及控件点击事件即可，此时就可以适当地释放其他类型日志的资源来处理更重要的页面事件及控件点击事件。
从客户端用户行为，到日志采集服务器的日志，整个日志采集的过程就算结束了。那么日志采集服务器的日志怎么给到下游呢？方法有很
多，阿里巴巴集团主要使用消息队列（ TimeTunel, TT ）来实现从日志采集服务器到数据计算的 MaxCompute 。简单来讲，就是 TT 将消息收集功能部署到日志采集服务器上进行消息的收集，而后续的应用可以是实时的应用实时来订阅 TT 收集到的消息，进行实时计算，也可以是离线的应用定时来获取消息，完成离线的计算。有关消息队列，以及日志数据的统计计算等细节内容，将在后续章节中进行详细讲述。

2.3 日志采集的挑战

对于目前的互联网行业而言，互联网日志早已跨越初级的饥饿阶段（大型互联网企业的日均日志收集量均以亿为单位计量），反而面临海量日志的淹没风险。各类采集方案提供者所面临的主要挑战已不是日志采集技术本身，而是如何实现日志数据的结构化和规范化组织，实现更为高效的下游统计计算，提供符合业务特性的数据展现，以及为算法提供更便捷、灵活的支持等方面。

2.3.1 典型场景

1. 日志分流与定制处理

大型互联网网站的日志类型和日志规模都呈现出高速增长的态势，而且往往会出现短时间的流量热点爆发。这一特点，使得在日志服务器
端采用集中统一的解析处理方案变得不可能，其要求在日志解析和处理过程中必须考虑业务分流（相互之间不应存在明显的影响，爆发热点不应干扰定常业务日志的处理）、日志优先级控制，以及根据业务特点实现定制处理。例如，对于电商网站而言，数据分析人员对位于点击流前端的促销页面和位于后端的商品页面的关注点是不一样的，而这两类页面的流量又往往同等重要且庞大 ，如果采用统 的解析处理方案，则往往需要在资源浪费（尽可能多地进行预处理）和需求覆盖不全（仅对最重要的内容进行预处理）两个选择之 间进行取舍。这种取舍的结果一般不是最优的。
考虑到阿里日志体量的规模和复杂度，分治策略从一开始便是阿里互联网日志采集体系的基本原则。这里以 PV 日志采集领域 个最浅显
的例子来说明，与业界通用 的第三方 日志采集方案的日志请求路径几乎归一不同，阿里 PV 日志的请求位置（ URL ）是随着页面所在业务类型的不同而变化的。通过尽可能靠前地布置路由差异，就可以尽可能早地进行分流，降低日志处理过程中 的分支判断消耗，并作为后续的计算资源调配的前提，提高资源利用效率。与业界方案的普遍情况相比，阿里的客户端日志采集代码的一个突 出特点是实现了非常高的更新频次（业界大多以季度乃至年为单位更新代码，阿里则是以周／月为单位），并实现了更新的配置 。我们不仅考虑诸如日志分流处理之类的日志服务器端分布计算方案，而且将分类任务前置到客户端（从某种程度上讲，这才是真正的“分布式” ！）以实现整个系统的效能最大化。最后可以在计算后端几乎无感知的情况下，承载更大的业务量并保证处理质量和效率。

2.3.2 大促保障

日志数据在阿里系乃至整个电商系应该都是体量最大的 类数据，在“双 ”期间，日志必然会暴涨，近万亿的数据量对日志全链路来说，无疑是不小的挑战（见图 2.4 ）。

首先，端上实现了服务器端推送配置到客户端，且做到高到达率；其次 ，对日志做了分流，结合日志的重要程度及各类日志的大小，实现了日志服务器端的拆分；最后，在实时处理方面，也做了不少的优化以提高应用的吞吐量。在上面几项的基础上，结合实时处理能力，评估峰
值数据量 ，在高峰期通过服务器端推送配置的方式对非重要日志进行适当限流 ，错峰后逐步恢复。此处说的服务器端推送配置包含较多的内容，首先是作用范围，可以针对应用、平台、事件、事件中的某个场景：其次是具体实施，包括延迟上报、部分采样等。所谓延迟上报，即配置生效后 ，满足条件的日志将被暂时存在客户端，待配置恢复后再上传到服务器 ；所谓 采样 ，即配置生效后，满足条件的日志将被实施采样（对于一些技术类日志，如页面加载情况、消耗内存等，可以实施采样），只上报部分日志到服务器。读到这里，可能会有读者发现，整个日 志处理流程还是比较长的，对于对实时性要求极高的业务场景，如上链路显然不能满足需求。所以 方面，我们从业务上进行改造，采用端上记录；另一方面，我们也在链路各环节做优化，如从采集服务器直接完成解码并调用业务 完成业务的计算（省去中间的传输和过 的处理） 。在这方面我们也面临着巨大的挑战，在保证稳定的同时扩展功能， 在稳定及业务深度之间做到很好的平衡。