日志采集系统flume和kafka有什么区别及联系,它们分别在什么时候使用,什么时候又可以结合?

关注者
309
被浏览
31,649

10 个回答

很凑巧,都用过这两个系统。
简言之:这两个差别很大,使用场景区别也很大。
先说flume:
日志采集。线上数据一般主要是落地文件或者通过socket传输给另外一个系统。这种情况下,你很难推动线上应用或服务去修改接口,直接向kafka里写数据。这时候你可能就需要flume这样的系统帮你去做传输。
对于数量级别,做过单机upd的flume source的配置,100+M/s数据量,10w qps flume就开始大量丢包。因此我们在搭建系统时,抛弃了flume,自己研发了一套传输系统。但flume设计的source-channel-sink模式还是比较好的,我们在开发系统时无耻的也抄袭了这种方式。

Kafka:
我个人觉得kafka更应该定位为中间件系统。LinkedIn开发这个东西目的也是这个初衷。可以理解为一个cache系统。你甚至可以把它理解为一个广义意义的数据库,里面可以存放一定时间的数据。kafka设计使用了硬盘append方式,获得了非常好的效果。我觉得这是kafka最大的亮点。不同系统之间融合往往数据生产/消费速率不同,这时候你可以在这些系统之间加上kafka。例如线上数据需要入HDFS,线上数据生产快且具有突发性,如果直接上HDFS(kafka-consumer)可能会使得高峰时间hdfs数据写失败,这种情况你可以把数据先写到kafka,然后从kafka导入到hdfs上。印象中LinkedIn公司有这么用。

业界比较典型的一中用法是:
线上数据 -> flume -> kafka -> hdfs -> MR离线计算 或者:
线上数据 -> flume -> kafka -> storm
Flume和Kafka本身是很相似的系统,都能无压力传输很大的数据量。

细节上他们当然有很多不同,但是总结下来,如果你纠结到底是用Kafka还是Flume:
1. Kafka是pull based, 如果你有很多下游的Data Consumer,用Kafka;
2. Kafka有Replication,Flume没有,如果要求很高的容错性(Data High Availability),选kafka;
2. 需要更好的Hadoop类产品接口,例如HDFS,HBase等,用Flume。

当然,这两个区别就会让人自然而然的想到整合两者,这样既可以拥有Kafka的容错能力,和Flume的多种接口,例如:
Events --->Flume ---> Kafka ---> Flume ---> Storage System (Hadoop Cluster)
当然,坏处就是你需要开发维护多个系统...

前一段似乎看到Cloudera提出过一款Flafka的app,说的就是这两款产品的整合,有兴趣可以去搜搜。