kafka和flume的区别和对比使用

﹏ヽ暗。殇╰゛Y 2022-06-03 00:35 231阅读 0赞

（1）kafka和flume都是日志系统。kafka是分布式消息中间件，自带存储，提供push和pull存取数据功能。flume分为agent（数据采集器）,collector（数据简单处理和写入）,storage（存储器）三部分，每一部分都是可以定制的。比如agent采用RPC（Thrift-RPC）、text（文件）等，storage指定用hdfs做。

（2）kafka做日志缓存应该是更为合适的，但是 flume的数据采集部分做的很好，可以定制很多数据源，减少开发量。所以比较流行flume+kafka模式，如果为了利用flume写hdfs的能力，也可以采用kafka+flume的方式。

采集层 主要可以使用Flume, Kafka两种技术。

Flume：Flume 是管道流方式，提供了很多的默认实现，让用户通过参数部署，及扩展API.

Kafka：Kafka是一个可持久化的分布式的消息队列。

*  Kafka 是一个非常通用的系统。你可以有许多生产者和很多的消费者共享多个主题Topics。相比之下,Flume是一个专用工具被设计为旨在往HDFS,HBase发送数据。它对HDFS有特殊的优化，并且集成了Hadoop的安全特性。所以，Cloudera 建议如果数据被多个系统消费的话，使用kafka；如果数据被设计给Hadoop使用，使用Flume。

*  正如你们所知Flume内置很多的source和sink组件。然而，Kafka明显有一个更小的生产消费者生态系统，并且Kafka的社区支持不好。希望将来这种情况会得到改善，但是目前：使用Kafka意味着你准备好了编写你自己的生产者和消费者代码。如果已经存在的Flume Sources和Sinks满足你的需求，并且你更喜欢不需要任何开发的系统，请使用Flume。

*  Flume可以使用拦截器实时处理数据。这些对数据屏蔽或者过量是很有用的。Kafka需要外部的流处理系统才能做到。

*  Kafka和Flume都是可靠的系统,通过适当的配置能保证零数据丢失。然而，Flume不支持副本事件。于是，如果Flume代理的一个节点奔溃了，即使使用了可靠的文件管道方式，你也将丢失这些事件直到你恢复这些磁盘。如果你需要一个高可靠行的管道，那么使用Kafka是个更好的选择。

*  Flume和Kafka可以很好地结合起来使用。如果你的设计需要从Kafka到Hadoop的流数据，使用Flume代理并配置Kafka的Source读取数据也是可行的：你没有必要实现自己的消费者。你可以直接利用Flume与HDFS及HBase的结合的所有好处。你可以使用Cloudera Manager对消费者的监控，并且你甚至可以添加拦截器进行一些流处理。

Flume和Kafka可以结合起来使用。通常会使用Flume + Kafka的方式。其实如果为了利用Flume已有的写HDFS功能，也可以使用Kafka + Flume的方式。

讨论日志处理为什么要同时使用Flume和Kafka，是否可以只用Kafka 不使用Flume？当时想到的就只用Flume的接口多，不管是输入接口(socket 和 文件)以及输出接口(Kafka/HDFS/HBase等)。

考虑单一应用场景，从简化系统的角度考虑，在满足应用需求的情况下可能只使用一个比较好。但是考虑到现有系统业务发展，为了后面的灵活扩展，在先用系统设计时留有一定的扩展性感觉更重要，可能使用Flume+kafka架构相对只使用Kafka会多占用1-2台机器做Flume日志采集，但是为了方便以后日志数据处理方式的扩展，可以采用Flume+kafka架构。

Flume ：管道 ----个人认为比较适合有多个生产者场景，或者有写入Hbase、HDFS和kafka需求的场景。

Kafka ：消息队列-----由于Kafka是Pull模式，因此适合有多个消费者的场景。

目前应用场景，一台日志转发机负责产生日志。后端需要通过Strom消费日志信息，建议可以设置成log-->Kafka->Strom.如果以后有写入Hbase或者HDFS的需求可以，在Kafka后面再接上Strom，或者在日志转发机上直接日志落地，由Flume去读取日志消息。