- Flume更趋向于消息采集系统，Kafka更趋向于消息缓存系统。
- kafka:目前项目中主要是用来做消息推送中间件，消息的处理完全由业务方自己定义，请求频次单机吞吐量轻轻松松50W+/s，数据在集群不全挂的情况下是不会丢数据，消费也很灵活，可以指定分区和offset，可以当做成一个数据库。
- flume:用来做数据采集和落地，目前使用的是flume-ng，流程是source(kafka)->channel->hdfs 相比较kafka比较轻量级 ，就是一个数据的流通管道，当一个flume实例挂了 数据会丢失。
- Flume架构简单，依赖少，功能也简单，但是够灵活，它的定位是数据通道，不是消息队列。
- Flume的Source-Channel-Sink模型，非常适合作为日志收集的模型。
- Kafka就不必多说了，生产者消费者模型，看你怎么去构建日志消费的下游了。有了消息队列作为中间件，消费的下游和上游可以完美的解耦。
- Kafka是pull based, 如果你有很多下游的Data Consumer，用Kafka；
- Kafka有Replication，Flume没有，如果要求很高的容错性(Data High Availability)，选kafka；
- 需要更好的Hadoop类产品接口，例如HDFS，HBase等，用Flume。
- flume是海量日志采集、聚合和传输的日志收集系统，kafka是一个可持久化的分布式的消息队列。
- Flume可以使用拦截器实时处理数据，对数据屏蔽或者过滤很有用，如果数据被设计给Hadoop使用，可以使用Flume，重在数据采集阶段。
- 采集和处理数据不一定同步，所以用kafka这个消息中间件来缓冲，重在数据接入。
- kafka就是消息队列， 对日志采集系统来说是做缓存用的，供实时的应用读取。
- 当你只想进行日志的收集工作时，可直接用flume。
- 如果你收集了日志后，想输出到多个业务方，则可结合kafka。
- kafka是消息队列，可支持多个业务来读取数据。
- 由于前端一般都会做负载均衡，所以日志源会有多个，而公司可能只有一个统一的实时计算平台。所以在这个中间一般都会采用消息队列来缓存。
- Kafka 是一个通用型系统。你可以有许多的生产者和消费者分享多个主题。相反地，Flume 被设计成特定用途的工作，特定地向 HDFS 和 HBase 发送出去。Flume 为了更好地为 HDFS 服务而做了特定的优化，并且与 Hadoop 的安全体系整合在了一起。基于这样的结论，Hadoop 开发商 Cloudera 推荐如果数据需要被多个应用程序消费的话，推荐使用 Kafka，如果数据只是面向 Hadoop 的，可以使用 Flume。
- Flume 拥有许多配置的来源 (sources) 和存储池 (sinks)。然后，Kafka 拥有的是非常小的生产者和消费者环境体系，Kafka 社区并不是非常支持这样。如果你的数据来源已经确定，不需要额外的编码，那你可以使用 Flume 提供的 sources 和 sinks，反之，如果你需要准备自己的生产者和消费者，那你需要使用 Kafka。
- Flume 可以在拦截器里面实时处理数据。这个特性对于过滤数据非常有用。Kafka 需要一个外部系统帮助处理数据。
- 无论是 Kafka 或是 Flume，两个系统都可以保证不丢失数据。然后，Flume 不会复制事件。相应地，即使我们正在使用一个可以信赖的文件通道，如果 Flume agent 所在的这个节点宕机了，你会失去所有的事件访问能力直到你修复这个受损的节点。使用 Kafka 的管道特性不会有这样的问题。
- Flume 和 Kafka 可以一起工作的。如果你需要把流式数据从 Kafka 转移到 Hadoop，可以使用 Flume 代理 (agent)，将 kafka 当作一个来源 (source)，这样可以从 Kafka 读取数据到 Hadoop。你不需要去开发自己的消费者，你可以使用 Flume 与 Hadoop、HBase 相结合的特性，使用 Cloudera Manager 平台监控消费者，并且通过增加过滤器的方式处理数据。
本文地址：https://blog.csdn.net/qq_38262266/article/details/107377765
如对本文有疑问，
点击进行留言回复！！
我要评论
网友评论