日志收集系统flume和kafka有什么区别和联系，它们分别何时使用，何时绑定？
观点1 :
简而言之，这两个差异很大，使用场景的差异也很大。
首先说flume :
日志收集。 在线数据主要通过落地文件或套接字传输到另一个系统。 在这种情况下，很难通过移动在线APP和服务来修改接口，然后直接将数据写入kafka。 这个时候，你可能需要像flume这样的系统帮助你传输。
在数量级别上，我们配置过独立upd的流源。 以100 M/s的数据量，10w qps flume会导致大量丢包。 所以我们在构建系统的时候，放弃了flume，自己开发了传输系统。 但是，flume设计的source-channel-sink模型还不错。 我们在系统开发时无耻地模仿了这种方式。
Kafka :
我个人认为kafka应该被定位为中间件系统。 开发这个东西的目的也是这个本来的目的。 可以理解为cache系统。 也可以把它理解为广义的数据库。 那里可以保存一定时间的数据。 kafka采用硬盘append方式，取得了非常好的效果。 我认为这是kafka最大的亮点。 系统之间的融合往往导致数据的生产/消耗速度不同。 在这种情况下，可以在这些系统之间添加kafka。 例如，在线数据需要访问HDFS，在线数据生产快速，具有突发性。 直接访问Kafka-consumer (kdfs )可能会导致在hxdbl时间写入HDFS数据失败。 在这种情况下，请将数据写入kafka，然后从kafka导入HDFS。 作为印象，LinkedIn公司是这么使用的。
行业的典型使用方法如下。
在线数据- flume - kafka - hdfs - MR离线计算或：
在线数据- flume - kafka - storm
观点2 :
Flume和Kafka本身是非常相似的系统，可以毫无压力地传输大的数据量。
在细节上他们当然有很多不同，但总的来说，如果你在为是使用Kafka还是Flume而烦恼的话：
Kafka是pull based，如果有很多下游的数据咨询者，则为Kafka； Kafka有复制，而Flume没有。 如果需要高容错能力，请选择Kafka； 需要更好的Hadoop类产品接口，例如HDFS、HBase等，使用Flume。 当然，这两者的区别自然会让我们想到将两者集成，可以有Kafka容错能力和Flume多个接口。 例如，情况如下：
事件-流- Kafka -流-存储系统(Hadoop群集)
当然，缺点是需要开发和维护多个系统…
在上一段中，我们似乎看到Cloudera提出了Flafka的app，我们谈论的是这两种产品的集成。 如果你感兴趣，请搜索一下。
观点3 :
我喜欢Flume 因为体系结构简单，依赖较少。
但是，同样，功能也很简单，但很灵活。
其定位是数据通道，而不是消息队列。
Flume和Kafka应该组合使用，Flume是日志收集方，Kafka是日志消费方。
flume :日志收集系统
kafka :消息中间件
我也用过楼上说的组合：
log-flume-kafka-hdfs(solr )
Flume的源通道同步模型非常适合作为日志收集的模型。 创建日志收集代理后，请考虑是否可以尽量确保日志数据的传输成功率，应对服务端的各种异常情况，以及是否可以灵活访问各种日志类型。
Kafka当然，生产者消费者模式，看看如何构建日志消费的下游。 消息队列作为中间件，可以使消费的下游和上游完全解耦。
概述：
)1) kafka和flume都是日志系统。 kafka是分布式消息中间件，具有存储，并提供推送和推送数据访问功能。 flume分为代理、收集器、存储三个部分，可以分别定制。 例如，代理采用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->storm.如果以后有写入Hbase或者HDFS的需求可以，在Kafka后面再接上storm，或者在日志转发机上直接日志落地，由Flume去读取日志消息。
Kafka 与 Flume 很多功能确实是重复的。以下是评估两个系统的一些建议：
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 平台监控消费者，并且通过增加过滤器的方式处理数据。