第5章 数据采集、传输、交换、同步服务
5.1 数据交换服务场景和常见开源方案
数据交换:不同系统之间传输和同步数据。
1 、大数据平台数据交换服务业务场景
1)场景:数据采集到大数据平台-大数据平台回写或导出到业务系统-大数据开发平台组件间
2)常见数据源:
- 关系型数据库:比如MySQL、Oracle……
- 文件类:比如log、CSV、Excel等
- 消息队列类:比如Kafka和各种MQ
- 各类大数据相关组件:HDFS、Hive、HBase、ES
- 其他网络接口或服务类:FTP、HTTP、Socket
2、常见解决方案
1)关系型数据库为主要处理对象的系统
- Tungsten-replicator
商业解决方案,能处理Oracle、MySQL的数据复制同步。数据同步、管理及稳定性是强项。
- Canal和Otter
Canal基于Binlog机制来获取增量数据,Otter则是构建在Canal智商的数据库远程同步管理工具。优点是流程架构简单,部署容易;缺点是Server和Client之间是一对一的消费,不太适用于需要多消费和数据分发的场景。
- 阿里的DRC/警卫等
定位与已购数据库实时同步,数据记录变更订阅服务。没有开源。蘑菇街的Pigeon基于Canal的Binlog解析代码模块基础上,参照DRC的思想进行的开发(Parser->MQ)。
- 日志或者消息队列
- Flume
定位是离线日志的采集、聚合和传输。
- Logstash
ELK著名组件,负责日志采集和转换。
- Camus
基于Kafka->HDFS的工具
3)通用的数据同步解决方案
-
Sqoop
定位于大数据平台的数据采集业务,整体架构以Hadoop为核心。不少公司使用Sqoop来构建自己的数据采集同步方案。 -
DataX
阿里的一款开源插件,以通用的异构数据交换为目标的产品。思路:通过表昏花的输入/输出模块,将点对点扩展成星形拓扑结构。图Data3.0
- Heka
mozilla开源的,与Logstash类似
5.2 具体产品实践
1、底层组件
模块分为输入、过滤转换、输出三个模块
5.3 用户行为链路分析之日志埋点采集跟踪方案实践
1、记日志有什么难的
全方位不遗漏的采集数据。
- 首先,页面全覆盖
- 其次,流量全覆盖
用js脚本、日志服务接口、日志采集SDK等手段来标准化。比如Google Analytic、百度统计、GrowingIO等
2、采集方案
1)整体流程
- 页面浏览类日志:js采集,然后向日志服务器特定URL发起HTTP请求,由日志服务器记录落库。
- 服务端日志类:agent收集日志,发送Kafka消息队列
2)埋点管理 (记录特定的事件ID)
- 浏览类日志的ID标识,大多是按照规则自动生成的
- 点击交互类日志:先注册登记,然后业务方通过SDK记录
3)PV/UV和独立交互类事件统计
- 页面类按一类页面一个ID
- 用户点击类,也是一类事件一个ID
4)用户浏览行为链路跟踪方案
- SPM编码方案(a.b.c.d.e),分层级的定位体系
a 字段代表的是站点;b代表这个业务下的页面ID;c代表页面中的模块;d代表点击的链接在模块内部的索引位置;e是一个特定规则生成的UniqueID,用来区分不同的session或者点击。
- 如何自动化生成个字段的ID信息
a 字段,种类不会太多,直接定义好,写入页面的后台公共模板就行
b字段,Web端,可以采用后台具体页面模板的URL的Hash值,用一个不宜冲突的Hash函数
c字段,ID通常只需要页面内部唯一,所以ID本身自动生成一个
d字段根据页面标签加特定属性的方式自动生成一个固定的ID
5)其他问题
- 客户端回退行为识别
- Hybrid混合模式的处理。