《阿里巴巴大数据之路》记录--日志采集同步

架构图

日志采集

两大指标：PV页面浏览量，UV客户数

日志产生过程

http 请求和响应
	请求http
		请求行：请求方法（如GET/POST），URL（最重要），HTTP协议版本号（如1.1）
		请求头：附加信息，如记录用户ID的Cookie
		正文：可选，一般为空
	响应http
		状态行：状态码（如200，404）
		响应报头：如请求头Cookie有缺失，响应头对增加Cookie更新指令
		响应正文：一般非空，浏览器响应结果，如HTML

日志采集动作
	时间：发生在浏览器开始解析响应正文文档时，HTML文档某个位置触发日志采集操作

除了PV，UV外，阿里也支持“黄金令箭”自主注册采集的功能。

对于采集到的数据也需要做好清洗和预处理（如识别异常数据，数据补正等）

无线客户端的日志采集采用SDK来完成

日志的统一

APP的两种日志H5和Native日志，为了计算方便等原因，需要对Native和H5进行统一
阿里采用了H5向Native日志统一，个人对客户端不了解，就简单略过了

设备标识

需要一个值来唯一确定客户，如UUID等
这里阿里采用了UTDID。也就是苹果和安卓每个设备一个ID来唯一标识

日志传输
无线客户端上传，压缩和传输的特殊性

日志处理方案例子

1 日志分流和定制处理
2 采集和计算一体化设计

数据同步

直连同步

配置简单，适合业务数据的同步。不适合仓库数据同步，即使使用主备依然性能较差

数据文件同步

上传和下载容易丢包。
所以经常也需要上传校验文件，传输中加密和压缩后再解密解压等形式。可以增加安全性和传输效率

数据库日志解析同步

该读操作可以在操作系统层面完成，不需要通过数据库，避免了数据库压力
通过网络协议实现数据文件传输，确保文件正确接收和网络数据包的正确顺序
性能好，效率高，业务系统影响小
但是也有数据延迟，部署实时抽取数据系统代价大，数据漂移遗漏等问题

批量数据同步

DataX 可分布式纯内存不读写磁盘操作，也没有进程通信

实时数据同步

数据同步问题和解决方案

分库分表

分库分表增加了数据同步难度，使用全局管理的中间表可以很好改善

增量和全量合并问题

传统合并时insert+update，但是大数据存储经常不支持update，并且update性能也慢
目前流行 当天增量全外连接昨天全量+新数据全覆盖昨天数据 的方式，全量更新性能也比update好

同步性能问题

线程数量的合理分配

数据飘逸的问题