目录
关系型数据收集
背景与目的
- 关系型数据(结构化数据)常见,通常存在关系型数据库中。
- 要利用大数据技术处理和存储就需要将数据导入到大数据的存储系统,以便使用大数据计算引擎分析和处理。
- 为了便于与前端可视化系统对接(目前绝大部分可视化工具与关系型数据库对接较好),经大数据系统分析过的结果还要导回到关系型数据库中。
如何高效实现关系型数据库与大数据系统之间数据的导入导出?
Sqoop
设计动机
解决关系型数据库与Hadoop之间的数据(即结构化数据)的传输问题
可以完成的任务
数据迁移、可视化分析结果、增量导入
sqoop不能高效地收集增量数据,高效增量数据收集:canal
特点
- 插拔式架构
- 高性能
- 自动类型转换:可以读取数据源的元信息,自动完成数据类型的映射,用户也可以自定义类型映射关系。
- 自动传播元信息:发送数据时也会传递元信息,保证了数据发送和接收端有一致的元信息。
CDC & Canal & Otter & SETL模型
-
CDC
change data capture:增量数据捕获 -
Canal
CDC的开源实现,基于数据库增量日志解析,模块化架构(便于扩展) -
Otter
基于Canal的开源产品,多机房数据同步系统。
采用Manager(Web管理)+Node(工作节点)的管理系统架构。
Manager:发布同步任务,接受任务反馈的状态信息。
Node:执行同步任务,将任务状态反馈给Manager。
使用了Zookeeper解决分布式状态调度(管理节点的状态),使得多Node节点可以协同工作。 -
SETL
Otter同步流程的四个阶段:Select、Extract、Transform、Load
Select:数据接入,解决数据来源的差异性。
Extract:数据提取
Transform:数据转换
Load:数据载入
用户可以根据需要设置不同阶段的部署方式。一般S和E阶段只能在源端进行(原机房),T和L阶段常布置在目的机房。
非关系型数据收集
非关系型数据
视频、图片、网页、日志
背景
日志数据流式、数据量大。各种设备的各种服务和组件都会产生日志。
如何高效、可靠地收集这些日志?——Flume
Flume
插拔式软件架构
Flume的基本架构
- Flume 的数据流由一系列Agent组件构成:
Agent可以从客户端/前一个Agent接收数据,经过滤和路由,传给下一个或多个Agent,直到抵达目标系统。
用户可拼接任意多个Agent组成一个数据流水线 - 数据流水线中传递的数据被称为Event:
每个Event由头部和字节数组两部分构成。
头:一系列key-Value对构成,用于数据路由。
字节数组:封装了实际要传输的内容。
Flume Agent 的基本架构
一个Flume Agent主要由Source,Chanel和Sink构成。
XX sink 将数据发送到XX系统中,如HDFS sink将数据写入HDFS中;
XX Source从XX系统收集数据。
XXChanel 将数据缓存在XX系统中:如memory缓存在内存队列中,file——磁盘文件,JDBC——支持JDBC驱动,将Event写入数据库。
-
Source:
接收Event。
从Client程序/上一个Agent接收数据,写入一个或多个Chanel。 -
Chanel
缓冲区,暂存Source写入的Event,直到被Sink发送。 -
Sink
从Chanel中读取数据并发送给下一个Agent。
Flume Agent的高级组件(了解)
用户可以设置高级组件以更灵活地控制数据流。
- Interceptor:允许用户修改或丢弃一些Event(有些Event不需要)
- Chanel Selector:允许Source选择一个或多个Chanel来写入
- Sink Processor:允许用户将多个Sink组成一个逻辑实体——Sink Group,Sink Processor在Group的基础上提供负载均衡和容错。
Flume的拓扑架构:多路合并&多路复用
多路合并
每个Web Server将日志发送到一个对应的Agent,Agent收到后再统一发送到一个汇总Agnet,由它写入HDFS(因此汇总Agent的sink是HDFS Sink)。
应用:日志文件每一条记录数据很少,但是量很大;大量小文件的写非常耗时——解决:合成大文件,一次性写入磁盘。
多路复用
Source产生的数据按照类别被写入不同的Chanel,再由不同的Sink写入不同的目标系统。
多路合并VS多路复用
合并:多个sink发给同一个source
复用:一个source发给多个chanel