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

第2章日记采集

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

Web端，基于浏览器日志采集技术方案：Aplus.JSAPP端，无线客户端日志采集技术方案：UserTrack 2.1 浏览器的页面日志采集

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

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

2.1.2 页面交互日记采集

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

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

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

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

2.2.1 页面事件

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

为了平衡采集、计算和分析的成本，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	律师

SELECT
	member.name,
	job.job 
FROM
	member m
	FULL 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 简介

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

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

子系统功能划分

数据采集

数据处理
数据去重

1、去重指标

精确去重模糊去重

布隆过滤器基数估计

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 数据分层

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

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

大数据系统相关栏目本月热门文章

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