为什么选择Canal + Flume + Kafka 架构而不是Canal + Kafka架构?

对于采集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是一个分布式,可靠的,易用的,可以将不同源的日志进行,收集,汇总,或者存储的中间件。

所以这个问题就解决了上面提到的架构问题。

 

你可能感兴趣的:(大数据挖掘与大数据应用案例,实时处理架构,Flume,Canal,SparkStreaming,Kafka)