第一章 总述
第二章 日志收罗
2.1 浏览器的页面日志收罗
览器的页面型产物/服务的日志收罗可分为如下两大类
（1）页面浏览（展现）日志收罗。顾名思义，页面浏览日志是指：一个页面被浏览器加载呈现时收罗的日志。此类日志是最基础的互联日志，也是目前全部互联网产物的两大根本指标：页面浏览量（Page View，PV）和访客数（UnigueVisitors，UV）的统计基础。贞面浏览日志是目前成熟度和完备度最高，同时也是最具挑战性的日志收罗任务，我们将重点报告此类日志的收罗。
（2）贞面交互目志收罗。当贞面加载和染完成之后，用户可以在页面上实行各类操纵。随着互联网前端技术的不断发展，用户可在浏览器内与网页举行的互动已经丰富到只有想不到没有做不到的水平，互动筹划都要求收罗用户的互动行为数据，以便通过量化获知用户的爱好点或者体验优化点。交互日志收罗就是为此类业务场景而生的。
除此之外，还有一些专门针对某些特定统计场合的日志收罗需求，如专门收罗特定媒体在页面被曝光状态的曝光日志、用户在线状态的实时监测等，但在根本原理上都脱胎于上述两大类。限于篇幅，此内容在本书中就不予睁开介绍了。
2.1.1 页面浏览日志收罗流程
上面描述了一次典型的网页浏览过程，如果必要记录这次浏览行为，则收罗日志的动作一定是附加在上述四个步调中的某一环节内完成的。在第一步和第二步，用户的请求尚未抵达服务器：而直到第三步完成，我们也只能以为服务器处理了请求，不能包管浏览器可以或许正确地分析和染页面，尚不能确保用户已确实打开页面，因此在前三步是无法收罗用户的浏览日志的。那么收罗日志的动作，必要在第四步，也就是浏览器开始分析文档时才能举行。根据前文所述，可以很天然地得出在这一模式下最直接的日志收罗思路：在HTML文档内的得当位置增长一个日志收罗节点，当浏览器分析到这个节点时，将主动触发一个特定的HTTP请求到日志收罗服务器。如此一来，当日志收罗服务器吸收到这个请求时，就可以确定浏览器已经成功地吸收和打开了页面。这就是目前几乎全部互联网网站页面浏览目志收罗的根本原理，而业界的各类网页日志收罗的解决方案只是在实行的细节、主动收罗内容的广度以及部署的便利性上有所不同。
2.1.2 页面交互日志收罗
PV目志的收罗解决了页面流量和流量泉源统计的问题，但随着互联网业务的发展，仅相识用户到访过的页面和访问路径，已经远远不能满足用户细分研究的需求。在很多场合下，必要相识用户在访问某个页面时具体的互动行为特征，好比鼠标或输入焦点的移动变革（代表用户关注内容的变革）、对某些页面交互的反应（可借此判断用户是否对某些页面元素发生认知困难）等。因为这些行为每每并不触发浏览器加载新页面，以是无法通过常规的PV日志收罗方法来网络。在阿里巴巴，通过一套名为“黄金令箭”的收罗方案来解决交互日志的收罗问题。
因为终端类型、页面内容、交互方式和用户实际行为的于变方化不可预估，交互日志的收罗和PV日志的收罗不同，无法规定统一的收罗内容（比方，活动页面的游戏交互和淘宝购物车页面的功能交互两者相比，所需记录的行为类型、行为数据以及数据的结构化水平都截然不同），呈现出高度自界说的业务特征。与之相顺应，在阿里巴巴的日志收罗实践中，交互日志的收罗（即“黄金令箭”）是以技术服务的形式皇现的。
具体而言，“黄金令箭”是一个开放的基于HTTP协议的日志服务必要收罗交互志的业务（下文简称“业务方”），颠末如下步调即可将自助收罗的交互日志发送到日志服务器。
（1）业务方在“黄金令箭”的元数据管理界面依次注册必要收罗交互日志的业务、具体的业务场景以及场景下的具体交互收罗点，在注册完成之后，体系将生成与之对应的交互日志收罗代码模板。
（2）业务方将交互日志收罗代码植入目标页面，并将收罗代码与必要监测的交互行为做绑定。
（3）当用户在页面上产生指定行为时，收罗代码和正常的业务互动相应代码一起被触发和实行。
（4）收罗代码在收罗动作完成后将对应的日志通过HTTP协议发送到日志服务器，日志服务器吸收到日志后，对于保存在HTTP请求参数部门的自界说数据，即用户上传的数据，原则上不做分析处理，只做简单的转储。
颠末上述步调收罗到日志服务器的业务随后可被业务方按需自行分析处理，并可与正常的PV日志做关联运算。
2.1.3 页面日志的服务器端洗濯和预处理
（1）识别流量攻击、网络爬虫和流量作弊。
（2）数据缺项补正。
（3）无效数据剔除。
（4）日志隔离分发。
第四章 离线数据开辟
4.1 数据开辟平台
4.1.1 统一计算平台
1. MaxCompute的体系架构
MaxCompute由四部门组成，分别是客户端（MaxComputeClient）、接人层（MaxComputeFrontEnd）、逻辑层（MaxComputeServer）及存储与计算层（ApsaraCore）。
MaxCompute客户端有以下几种形式。
- Web：以RESTfulAPI的方式提供离线数据处理服务。
- SDK：对RESTfulAPI的封装，目前有Java等版本的实现。
- CLT（CommandLineTool）：运行在Windows/Linux下的客户端工具，通过CLT可以提交命令完成Project管理、DDL、DML 等操纵。
- IDE：上层可视化ETL/BI工具，即阿里内部名称是在云端（D2），用户可以基于在云端完成数据同步、任务调治、报表生成等常见操纵。
4.2 任务调治体系
任务状态机模子
第五章 实时技术
5.2 流式技术架构
5.2.3 数据存储
实时任务在运行过程中，会计算很多维度和指标，这些数据必要放在一个存储体系中作为规复或者关联使用。此中会涉及三种类型的数据。
中间计算效果逐一在实时应用处理过程中，会有一些状态的保存（好比去重指标的明细数据），用于在发生故障时，使用数据库中的数据规复内存现场。
终极效果数据逐一指的是通过ETL处理后的实时效果数据，这些数据是实时更新的，写的频率非常高，可以被卑鄙直接使用。
维表数据——在离线计算体系中，通过同步工具导入到在线存储体系中，供实时任务来关联实时流数据。后面章节中会讲到维表的使用方式。
下面介绍在数据统计中表名筹划和rowkey筹划的一些实践履历。
1.表名筹划
筹划规则：汇总层标识+数据域+主维度+时间维度
比方：dws_trd_slr_dtr，表现汇总层交易数据，根据卖家（slr）主维度+0点停止当日（dtr）举行统计汇总。
这样做的利益是，全部主维度雷同的数据都放在一张物理表中，避免表数量过多，难以维护。别的，可以从表名上直观地看到存储的是什么数据内容，方便排查问题。
2.rowkey筹划
筹划规则：MD5+主维度+维度标识+子维度1+时间维度+子维度2
比方：卖家ID的MD5前四位+卖家ID+aPp+一级类目ID+ddd+二级类目ID。
以MD5的前四位作为rowkey的第一部门，可以把数据散列，让服务器整体负载是均衡的，避免热门问题。在上面的例子中，卖家ID属于主维度，在查数据时是必传的。每个统计维度都会生成一个维度标识，以便在rowkey上做区分。
5.3 流式数据模子
数据模子筹划是贯通数据处理过程的，流式数据处理也一样，必要对数据流建模分层。实时建模跟离线建模非常类似，数据模子整体上分为五层（ODS、DWD、DWS、ADS、DIM)。
由于实时计算的局限性，每一层中并没有像离线做得那么宽，维度和指标也没有那么多，特别是涉及回溯状态的指标，在实时数据模子中几乎没有。
整体来看，实时数据模子是离线数据模子的一个子集，在实时数据处理过程中，很多模子筹划就是参考离线数据模子实现的。
下面从数据分层、多流关联、维表使用这三个方面来详细说明。
第6章 数据服务
6.1 服务架构演进
第四个阶段是统一的数据服务层（即OneService）。各人心里大概会有疑问：SQL并不能解决复杂的业务逻辑啊。确实，SmartDQ实在只满足了简单的查询服务需求。我们遇到的场景还有这么几类：个性化的垂直业务场景、实时数据推送服务、定时任务服务。以是OneService重要是提供多种服务类型来满足用户需求，分别是OneService-SmartDQ, OneService-Lego,OneService-iPush,OneService-uTiming。上面提到过，SmartDQ不能满足个性化的取数业务场景，可以使用Lego。Lego采用插件化方式开辟服务，一类需求开辟一个插件，目前一共生产5个插件。为了避免插件之间相互影响，我们将插件做成微服务，使用Docker做隔离。
实时数据服务iPush重要提供WebSocket和longpolling两种方式其应用场景重要是商家端实时直播。在“双11”当天，商家会迫不及待地去革新页面，在这种环境下longpolling会给服务器带来成倍的压力。而WebSocket方式，可以在这种场景下，有效地缓解服务器的压力，给用户带来最实时的体验。
uTiming重要提供即时任务和定时任务两种模式，其重要应用场景是满足用户运行大数据量任务的需求。
在OneService阶段，开始真正走向平台化。我们提供数据服务的核心引擎、开辟配置平台以及流派网站。数据生产者将数据入库之后，服务提供者可以根据尺度规范快速创建服务、发布服务、监控服务、下线服务，服务调用者可以在流派网站中快速检索服务，申请权限和调用服务。
6.2 技术架构
6.2.1 SmartDQ
1. 元数据模子
SmartDQ的元数据模子，简单来说，就是逻辑表到物理表的映射。
自底向上分别是：
（1）数据源
SmartDQ支持跨数据源查询，底层支持接入多种数据源，好比MySQL、HBase、OpenSearch等。
（2）物理表
物理表是具体某个数据源中的一张表。每张物理表都必要指明主键由哪些列组成，主键确定后即可得知该表的统计粒度。
（3）逻辑表
逻辑表可以明白为数据库中的视图，是一张假造表，也可以看作是由若于主键雷同的物理表构成的大宽表。SmartDQ对用户展现的只是逻辑表，从而屏蔽了底层物理表的存储细节。
（4）主题
逻辑表一般会挂载在某个主题下，以便举行管理与查找。
2. 架构图
6.2.2 iPush
iPush应用产物是一个面向TT，MetaQ等不同消息源，通过定制过滤规则，向Web、无线等终端推送消息的中间件平台。iPush核心服务器端基于高性能异步事件驱动模子的网络通信框架Netty4实现，联合使用Guava缓存实现本地注册信息的存储，Filter与Server之间的通信采用Thrift异步调用高效服务实现，消息基于Disruptor高性能的异步处理框架（可以以为是最快的消息框架）的消息队列，在服务器运行中Zookeeper实时监控服务器状态，以及通过Diamond作为统一的控制触发中央。
6.2.3 Lego
Lego被筹划成一个面向中度和高度定制化数据查询需求、支持插件机制的服务容器。它本身只提供日志、服务注册、Diamond配置监听、鉴权、数据源管理等一系列基础办法，具体的数据服务则由服务插件提供基于Lego的插件框架可以快速实现个性化需求并发布上线。
6.2.4 uTiming
uTiming是基于在云端的任务调治应用，提供批量数据处理服务，支持用户识别、用户画像、人群圈选三类服务的离线计算，以及用户识别、用户画像、人群透视的服务数据预处理、入库。
uTiming-scheduler负责调治实行SQL或特定配置的离线任务，但并不直接对用户暴露任务调治接口。用户使用数据超市工具或LegoAPI创建任务。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
