第2章日记采集

阿里巴巴日志采集的两大体系

Web端，基于浏览器日志采集技术方案：Aplus.JS
APP端，无线客户端日志采集技术方案：UserTrack

2.1 浏览器的页面日志采集

页面浏览日志的采集，也就是当一个页面被浏览器加载呈现时的日志采集
包含两大最基础的数据：访客数：UV（Unique Visitors）和浏览量PV（Page View）
页面交互日志的采集，就是对用户在浏览器上与网页进行互动行为的数据采集

2.1.1 页面浏览日志采集流程

采集-发送-收集-解析存档
整个过程都是依照HTML规范和HTTP协议自动进行，减少人工干预，保证日志的准确性

客户端日志采集
HTML文档内植入采集脚本，一种是在服务器返回响应数据时动态植入（见下图），一种是在开发页面时手动植入。
采集的信息包含浏览行为的上下文信息、运行环境信息等等
客户端日志发送
采集脚本执行时，向日志服务器发起日志请求。大多数情况下会立即执行发送，个别场景下会延迟发出。
日志采集和发送模块集成在一个脚本内，采集到的信息一般以URL参数形式放在HTTP请求行内。
服务端接收日志
日志服务器接收到日志请求后，一般会发回成功响应，以免影响页面加载。同时将请求内容写入日志缓冲区。
日志服务器解析文档
由专门的日志处理程序顺序读出，并按照约定处理逻辑解析。
然后转存入日志文件，并注入实时消息通道，供其他程序读取和加工处理。

2.1.2 页面交互日记采集

由于终端类型、页面内容、交互方式和用户实际行为的千变万化不可预估，交互日志的采集无法规定统一的采集内容。
阿里巴巴通过一套"黄金令箭"的的采集解决方案来解决，步骤如下

业务方在元数据管理界面注册需要采集交互日志的业务、具体的业务场景以及场景下的具体交互采集点，注册完成后，系统生成对应的采集代码模板
黄金令箭使用方法参考：
https://github.com/alvarto/gulp-magix-spmlog
https://blog.naaln.com/2017/08/alibaba-data-track-1/
业务方将采集代码植入页面，并与交互行为做绑定
用户产生指定行为，采集代码、业务互动响应代码一起触发和执行
采集动作完成后，由采集代码通过HTTP协议发送到日志服务器

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

识别流量攻击、网络爬虫和流量作弊（虚假流量），通过算法识别并归纳出规则，对日志进行过滤。
数据缺项补正，比如取值归一，标准化处理或反向补正
剔除无意义、已经失效或者冗余的数据
日志隔离分发

2.2 无线客户端的日志采集

UserTrack（UT）根据用户行为分成不同的事件，常用的包括页面事件、控件点击事件
对事件进行分类
一方面是因为不同事件的触发时机、日志内容，实现方式有所差异
另一方面是为了更好的完成数据分析，降低后续处理的复杂性

2.2.1 页面事件

每条页面事件记录三类信息

设备及用户的基本信息
被访问页面的信息，主要是业务参数，如商品ID，所属店铺
访问基本路径，如页面来源，来源的来源，用于还原完整的访问行为
UT提供了两个接口
页面展示时调用接口，记录状态信息，但此时不发送日志
页面退出时调用接口（退出有可能是点击了其他商品、返回、退出APP）发送日志
还有一个是页面退出前，页面扩展信息的接口，比如给店铺详情页添加店铺ID，店铺类别
上述3个接口需配合使用，页面展示和页面退出必须成对使用

为了平衡采集、计算和分析的成本，UT提供了透传参数功能，就是把当前页面的某些信息，传递到下一个甚至下下一个页面的日志中

2.2.2 控件点击及其他事件

控件点击事件除了记录设备信息、用户信息，还记录了控件所在页面的名称、控件的名称、控件的业务参数
其他事件，就是用户可以根据业务场景需求，使用自定义事件来采集相关信息，UT帮助提供了一些额外的功能，比如记录事件的名称、时长、携带的属性、对应的页面
UT还提供了一些默认的采集方法，比如引用崩溃，应用退出，页面前后台切换

2.2.3 特殊场景

比如场景曝光，提倡对这类日志进行聚合，以减少对日志服务器的请求，适当减少日志的大小。利用页面的生命周期实现适当的聚合及确定发送时机。
再比如明显的回退行为，点击回退按钮，滑屏等，举例
A主页面->B分类页->C详情页->回退到B分类页->D详情页。如果按照普通的路径来处理，第二次进入B分类页的来源就会记录为C详情页，以此类推，就会记录到很多B分类页的来源都来自于详情页。这种就需要做特殊处理

2.2.4 H5 & Native日志统一

移动应用粗分为3种：原生应用（Native APP）、网页应用（HTML5 APP、web APP）、混合模式移动应用（Hybird APP）
现在很多都是采用Hybird APP，页面就在Native 和 H5 之间互跳，导致无法还原用户路径，数据容易丢失
这时候就需要将两类日志进行归一，阿里巴巴采用的是把H5日志向Native日志归
原因有二：

Native可以采集到更多的设备信息
Natvie会在本地缓存，网络不佳也可以延迟上报，保证数据不丢失

2.2.5 设备标识

移动设备的唯一标识

PC端一般用Cookie
移动端设备就很复杂了，包括MEI,IMSI,MAC UDID,IDFA,IMEI。系统的升级、用户的自我保护意识更强，导致获取设备的信息更难了
阿里采用的是UTDID，而且随着IOS和安卓系统对权限控制的不断升级，方案和算法也一直在调整

2.2.6 日志传输

无线客户端日志的上传，不是产生一条上传一条，而是产生日志后，存储在客户端本地，在伺机上传。
上传时时向服务器发送post请求，服务端进行校验，然后追加到本地文件存储。存储方式采用nginx的accesslog，按天存储。
日志服务器通过消息队列（TimeTunel ，TT）来实现日志服务器到数据的计算的服务器

2.3 日志采集的挑战

2.3.1 典型场景

日志分流和定制处理
业界通用的是采集日志请求路径几乎归一，阿里日志的请求URL是随着页面所在业务类型不同二变化的
采集与计算一体化设计

2.3.2 大促保障

第3章数据同步

3.1 数据同步基础

数据存储的方式不同，需要对数据同步进行不一样的处理

数据类型
- 关系型数据库，如MySql，Oracle，DB2，SQL Server等
- 非关系性数据库，如MongoDB，Redis，HBase，OceanBase等
- 阿里云对象存储OSS，华为云对象存储OBS等
同步方式分为
- 直连同步
- 数据文件同步
- 数据库日志解析同步

3.1.1 直连同步

通过定义好的API接口直接连接业务库进行同步

优点：配置简单，实现容易，适合操作型业务系统的数据同步
缺点：对源系统性能影响较大，数据量大时，会降低或者拉胯业务系统的性能

3.1.2 数据文件同步

通过哦约定好的文件编码、大小、格式等，直接从源系统生成数据的文本文件，由专门的文件服务器传输到目标系统，然后加载到数据库系统

适合多个异构的数据库系统（如MySQL、Oracle，SQL Server、DB2等）
文件上传可能丢包或错误，可以同时上传一个校验文件，内容包含数据量、文件大小等校验信息，保证数据的准确性
源系统生成文件可以进行加密和加密，目标系统在进行解压缩和解密，提高传输效率和安全性

3.1.3 数据库日志解析同步

通过读取归档日志文件收集数据信息，并判断信息是否属于被收集对象，再解析到目标数据文件。
可以通过网络协议，实现源系统和目标系统之间的数据文件传输。

读操作是在操作系统层面完成，不需要通过数据库，不会给源系统带来性能影响。
对性能影响较小，广泛应用于业务系统到数据仓库的数据同步
存在的问题：
- 数据延迟。批量操作可能导致更新量超出系统处理峰值
- 投入较大。需要部署一个系统实时抽取数据
- 数据漂移和遗漏。

3.2 阿里数据仓库的同步方式

数据仓库的特性之一：集成，整合不同的数据来源，不同形式的数据。
针对不同的数据源类型和数据应用的时效性要求才去不同的策略

3.2.1 批量数据同步

阿里巴巴的DataX是一个能满足多方向高自由度的异构数据交换服务产品。

数据源读取转换为中间状态

3.2.2 实时数据同步

通过解析MySQL的binlong日志实时获得数据更新，并通过消息订阅模式实现数据的实时同步

3.3 数据同步遇到的问题和解决方案

3.3.1 分库分表的处理

3.3.2 高效同步和批量同步

存在的问题

随着业务的发展和变化，使用传统的方式完成同步工作，一方面工作量特别大，另一方面降低开发人员工作热情
数据源种类丰富，需要开发人员了解不同类型的特殊配置
真正的数据需求方，由于存在专业技能门槛，需要交给数据开发方来完成

基于以上问题，阿里巴巴研发了OneClick产品

不同数据源配置透明化，通过库名和表名唯一定位，通过IDB接口获取元数据自动生成配置信息
简化操作步骤，实现建表、配置任务、发布、测试操作一键化处理
降低数据同步的技能门槛

注：IDB是阿里巴巴集团用于统一管理MySQL、OceanBase、PostgreSQL、 Oracle, SQL Server等关系型数据库的平台，它是一种集数据管理、结构管理、诊断优化、实时监控和系统管理于一体的数据管理服务；在对集团数据库表的统一管理服务过程中，IDB产出了数据库、表、字段各个级别元数据信息，并且提供了元数据接口服务。

3.3.3 增量与全量同步的合并

随着业务发展，数据量变大，如果周期全量同步会影响效率。这时，可以选择每次同步新变更的增量数据，然后与上一个同步周期的全量数据合并，获得最新的全量数据。

传统大多数采用merge（update+insert），现在比较推荐的是全外连接（full out join）+数量全量覆盖加载（insert overwrite）

扩展：mysql 全外连接：指返回左右表中所有的记录和左右表中连接字段相等的记录

举例
第一张member表：

id	name
1	张三
2	李四
3	王五

第二张job表：

id	memberId	job
1	1	老师
2	3	工人
3	4	律师

SELECTmember.name,job.job
FROMmember mFULL JOIN job j ON m.id = j.memberId

结果

name	job
张三	老师
李四	null
王五	工人
null	律师

3.3.4 同步性能的处理

略

3.3.5 数据漂移

从源系统同步进入数据仓库的第一层数据成为ODS，数据漂移是ODS层的一个顽疾，通常是指ODS表的同一个业务日期数据中包含前一天或后一天的凌晨附近的数据或者丢失当天的变更数据
举例：
用户在当天23点59分59秒支付的订单，但是由于支付系统需要处理一系列流程或者网络故障等原因，导致更新时间变为第二天01点02分，统计支付订单时，就会变成统计为第二天的数据

第4章离线数据开发

原始数据收集后，只有被整合和计算，才能被用于洞察商业规律，挖掘潜在信息，从而实现大数据价值。

4.1 数据开发平台

4.1.1 统一计算平台

大数据计算服务MaxCompute,有四部分组成，客户端、接入层、逻辑层、存储与计算层

客户端包括Web、SDK、CLT（Command Line Tool）、IDE
接入层提供HTTP服务、Cache、负载均衡、实现用户认证和服务层面的繁文控制
逻辑层又称控制层，是核心部分，实现用户空间和对象的管理、命令的解析和执行逻辑、数据对象的访问控制和授权等。
计算层就是飞天内核，它包括Pangu分布式文件系统、Fuxi资源调度系统、Nuwa/ZK Namespace服务、Shennong监控模块等

4.1.2 统一开发平台

略

4.2 任务调度系统

略

第5章实时技术

数据的价值是具有时效性的，如果不能及时处理数据并在业务系统中使用，就不能让数据保持最高的“鲜活度”和价值最大化

5.1 简介

按照数据的延迟情况，数据时效性一般分为三种：离线、准实时、实时

离线：在今天处理N天前的数据，延迟时间粒度为天
准实时：在当前小时处理N小时前的数据，延迟时间粒度为小时
实时：在当前时刻处理当前的数据，延迟时间粒度为秒
离线、准实时都可以在拍出来系统中实现，实时数据需要在流式处理系统中完成，业务系统每产生一条数据，就会立刻被采集并实时发送到流式任务中处理
流式数据处理特征

时效性高：实时采集、实时处理
常驻任务：任务一旦启动就一直运行
性能要求高：需要在数据量快速膨胀的情况下也能保持高吞吐量和延时
应用局限性：业务复杂的场景，支持不足。具有上下文关系的情况下，数据到达时间的不确定性导致结果处理会有差异

5.2 流式技术架构

子系统功能划分

数据采集
数据处理
数据去重

1、去重指标
- 精确去重
- 模糊去重
1. 布隆过滤器
2. 基数估计
2、数据倾斜
数据存储
- 数据类型
  中间计算结果
  最终结果数据
  维表数据
- 表名设计
  设计规则：汇总层标识+数据域+主维度+时间维度
  例如： dws trd _s lr dtr ，表示汇总层交易数据，根据卖家（ sir ）主维度
  +O 点截至当日（ dtr 进行统计汇总。
- rowkey设计
  设计规则： MD5 ＋主维度＋维度标识＋子维度＋时间维度＋子维度
  例如：卖家 ID MD5 前四位＋卖家 ID+ app 级类目 ID+ddd ＋二级类目 ID
数据服务

5.3 流式数据模型

数据模型分为5层：ODW、DWD、DWS、ADS、DIM

5.3.1 数据分层

ODS层
ODS是属于操作数据层，是直接从业务系统采集过来的最原始数据，包含了所有业务的变更过程，数据粒度也是最细的。例如：原始的订单变更记录，服务器引擎的访问日志。
数据举例：订单粒度的变更过程，一笔订单有多条记录。
DWD层
DWD层是在ODS层的基础上，根据业务过程建模出来的实时事实明细层。例如：订单的支付明细表，退款明细表，用户的访问日志明细表
数据举例：订单粒度的支付记录，一笔订单只有一条记录。
DWS层
计算各个维度的汇总指标。例如：电商数据的几大维度汇总表。卖家、商品、买家
数据举例：卖家的实时成交金额，一个卖家只有一条记录，且实时刷新
ADS层
个性化维度汇总层，针对不是特别通用的统计维度数据。例如：淘宝下面的某个爱逛街、微淘等垂直业务
数据举例：外卖地区的实时成交金额，只有外卖业务使用
DIM层
实时维表层。例如商品维表、卖家维表、买家维表、类目维表。
数据举例：订单商品类目和行业的对应关系维表
实时为表层

5.3.2 多流关联

5.3.3 维表使用

事实表：表格里存储了能体现实际数据或详细数值，一般由维度编码和事实数据组成。例如下图的
维度表：表格里存放了具有独立属性和层次结构的数据，一般由维度编码和对应的维度说明(标签)组成。

5.4 大促挑战&保障

略

第6章数据服务

数据部门产出的海量数据，如何方便高效的开放出去。本章将介绍服务架构的演进过程及详细的技术细节。

6.1 服务架构演进

阿里不断升级数据服务的架构，依次经理了DWSOA、OpenAPI、SmartDQ、OneService

6.1.1 DWSOA

根据需求通过SOA服务的方式，由需求驱动，一个需求开发一个或者几个接口，编写接口文档，开放给业务方。
缺陷：

接口粒度较粗，灵活性不高，扩展性差，复用率低，
随着业务对需求增加，接口数量也会一直增加，维护成本高
开发效率低，无法快速响应业务，从需求、开发、测试、上线流程长。即使增加一两个字段，也要走整套流程。
接口众多不好维护

SOA：面向服务架构（Service-Oriented Architecture）
百度百科：面向服务架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
简单理解就是根据业务的需求，把系统拆分成大小刚好的，合适的，独立部署的模块，每个模块之间互相独立。
参考：https://www.zhihu.com/question/42061683?sort=created

6.1.2 OpenAPI

将数据按照统计粒度进行聚合，同样维度的数据，形成一张逻辑表。
缺陷：随着时间推移，对数据的深度使用，维度越来越多，OpenAPI接口也越来越多，带来大量对象关系映射的维护工作。

6.1.3 SmartDQ

SmartDQ封装了跨异构数据源和分布式查询功能，把逻辑表的作用真正发挥出来了。SmartDQ开放给业务方通过写SQL的方式对外提供服务，业务方不需要关心底层由多少物理表组成，甚至不需要关心物理表是HBase还是MySQL。

6.1.4 统一的数据层服务

统一的数据服务层（OneService）
服务类型：OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming
Lego：插件化开发微服务，用Docker做隔离
iPush：主要提供WebSocket和long polling，应用场景主要是商家端实时直播
uTiming：主要提供即时任务和定时任务，应用场景主要是满足用户运行大数量任务的需求

第7章数据挖掘

todo 2022-3-24 17:07:39

【大数据之路-阿里巴巴大数据实践】第一篇数据技术篇相关推荐

读《大数据之路-阿里巴巴大数据实践》数据模型篇笔记
读<大数据之路-阿里巴巴大数据实践>数据模型篇七建模综述 OLTP 面向数据随机读写 3NF OLAP 批量读写不关注一致性更关心数据整合 ER模型–衍生出dataVault 维度 ...
《大数据之路-阿里巴巴大数据实践》读书笔记
ps:这本书主讲阿里的大数据体系架构方案,从底层到高层阐述,目前对我来说此书的难度较大,不是很懂,大部分为对原书的引用归纳,我会给出相应的大牛的关于此书的读书笔记的传送门供参考.以下为大牛关于本书的读 ...
大数据之路阿里巴巴大数据实践读书笔记
一 .总述人类正在从IT时代走向DT时代.现在的数据呈爆炸式增长,其潜在的巨大价值有待发掘.但是如果不对数据进行有序.有结构的分类组织和存储,它将变成一场灾难. 在阿里内部,数据的存储达到EB级别. ...
大数据之路——阿里巴巴大数据实践：总述
阿里巴巴大数据系统架构图: Aplus.JS是web端日志采集技术 UserTask是APP端日志采集技术 TimeTunel(TT)是一个实时消息处理平台,类似于kafka+storm DataX是 ...
《大数据之路阿里巴巴大数据实践》笔记
此书下载传送门http://www.java1234.com/a/javabook/yun/2018/0308/10578.html 第1章总述阿里巴巴大数据系统体系主要分为,数据采集.数据计算. ...
《大数据之路-阿里巴巴大数据实践》第一章总述
【手把手教你如何从Tushare库下载股票数据，并保存在硬盘当中，第一篇数据过滤】
手把手教你如何从Tushare库下载股票数据,并保存在硬盘当中.第一篇数据过滤前言一.Tushare是什么? 二.代码 1.引入库 2.交易日的逻辑 3.先把每天个股的基础数据调出来 3.接下来我 ...
迁移学习训练分类模型实践第一篇
迁移学习训练分类模型实践第一篇前言数据获取.预处理构建模型查看模型参数量和FLOPs 测试模型前言为了简洁,本文不包含任何训练过程,仅介绍处理数据.构建模型.使用随机初始化权重推断: 关于 ...
matlab实现鬼波信号压制算法（附鬼波算法压制工具包）代码实践--第一篇频率-空间域自适应鬼波压制
matlab实现鬼波信号压制算法(附鬼波算法压制工具包) 代码实践涵盖了频率-空间域.频率-波数域.拉东域鬼波压制算法建议实践之前熟练掌握各个域鬼波压制方法的原理,才能对代码有更深入的了 ...
胖子哥的大数据之路（15）：互联网企业数据战略运营规划之总决式
一.总决 "天下武功唯快不败",数据化运营战略在不同的行业.不同的企业之间是不同的,但是亦有其共性,即:快速的数据就绪和响应能力.完美主义者适合生活在保温箱里,唯有实践者才是真英雄 ...

【大数据之路-阿里巴巴大数据实践】第一篇 数据技术篇

第2章 日记采集