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

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

https://blog.csdn.net/helloxiaozhe/article/details/79481319

 

日志采集系统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就没必要多说了，生产者消费者模型，看你怎么去构建日志消费的下游了。有了消息队列做为中间件，消费的下游和上游能够完美的解耦。