赞
踩
对于采集MySQL 的Binlog并实时解析,我们知道Canal直接对接的消息队列MQ中就包含Kafka组件,
那么我们为什么不能直接使用Canal + Kafka + SparkStreaming 架构呢?
其实上面的问题答案是可以的。
Canal负责采集
Kafka负责消息传输以及固化
SparkStreaming使用Spark引擎解析日志并提取有用的价值。
那么我们为什么要使用 Canal + Flume + Kafka 架构,而不是Canal + Kafka架构?
原因就在于扩展性上面,我们知道 Canal 只是模拟 MySQL 中的 Slave 备份库,“骗来的”日志,
那么我们在业务方面如果有其他的数据源 Oracle, CSV,PostgreSQL,等等需要采集的时候,
我们得去寻找Yugong, 等等类似于Canal一样的能收集到对应数据库或者数据源组件,这个时候我们不建议设计多套架构
AAAA + Kafka + ...
BBBB + Kafka + …
CCCC + RocketMQ + …
因此我们为了统一数据源,我们使用Flume。
Flume是一个分布式,可靠的,易用的,可以将不同源的日志进行,收集,汇总,或者存储的中间件。
所以这个问题就解决了上面提到的架构问题。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。