日志采集系统flume和kafka区别及联系:

 

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

观点一：

简言之：这两个差别很大，使用场景区别也很大。

flume：

日志采集。线上数据一般主要是落地文件或者通过socket传输给另外一个系统。这种情况下，你很难推动线上应用或服务去修改接口，直接向kafka里写数据。这时候你可能就需要flume这样的系统帮你去做传输。

对于数量级别，做过单机upd的flume source的配置，100+M/s数据量，10w qps flume就开始大量丢包。因此我们在搭建系统时，抛弃了flume，自己研发了一套传输系统。但flume设计的source-channel-sink模式还是比较好的，我们在开发系统时无耻的也抄袭了这种方式。

Kafka：

我个人觉得kafka更应该定位为中间件系统。开发这个东西目的也是这个初衷。可以理解为一个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；

3. 需要更好的Hadoop类产品接口，例如HDFS，HBase等，用Flume。

 

当然，这两个区别就让人自然而然的想到整合两者，这样既可拥有Kafka的容错能力，和Flume的多种接口，例如：

Events --->Flume ---> Kafka ---> Flume ---> Storage System (Hadoop Cluster)

当然，坏处就是你需要开发维护多个系统... 

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

 

观点三：

我偏爱Flume，因为架构简单，依赖少。

但是同样的，功能也简单，但是够灵活。

它的定位是数据通道，不是消息队列。

Flume和Kafka应该结合来使用，Flume作为日志收集端，Kafka作为日志消费端。

flume：日志采集系统

kafka：消息中间件

也用过楼上说的组合：

log->flume->kafka->hdfs(solr)

Flume的Source-Channel-Sink模型，非常适合作为日志收集的模型。你可以想一下，如果你来做一个日志收集的Agent，如果做能尽量保证日志数据的传输成功率，应对服务端的各种异常情况，以及如何灵活的接入各种不同的日志类型。

Kafka就不必多说了，生产者消费者模型，看你怎么去构建日志消费的下游了。有了消息队列作为中间件，消费的下游和上游可以完美的解耦。