Is Flume a good fit for your problem?
If you need to ingest textual log data into Hadoop/HDFS then Flume is the right fit for your problem, full stop. For other use cases, here are some guidelines:
Flume is designed to transport and ingest regularly-generated event data over relatively stable, potentially complex topologies. The notion of “event data” is very broadly defined. To Flume, an event is just a generic blob of bytes. There are some limitations on how large an event can be - for instance, it cannot be larger than what you can store in memory or on disk on a single machine - but in practice, flume events can be everything from textual log entries to image files. The key property of an event is that they are generated in a continuous, streaming fashion. If your data is not regularly generated (i.e. you are trying to do a single bulk load of data into a Hadoop cluster) then Flume will still work, but it is probably overkill for your situation. Flume likes relatively stable topologies. Your topologies do not need to be immutable, because Flume can deal with changes in topology without losing data and can also tolerate periodic reconfiguration due to fail-over or provisioning. It probably won’t work well if you plant to change topologies every day, because reconfiguration takes some thought and overhead.
上面是flume官網的說明，翻譯如下：
Flume是否適合你的問題？
如果你想把可文本化的日志數據提取到HDFS，那么Flume是非常適合的。對於其他場景，有些東西是需要考量的：
Flume被設計用來傳輸、提取定期生成的數據的，這些數據是傳輸在相對穩定的、可能是復雜的拓撲結構上的。每個數據就是一個event。“event data”的概念是非常廣泛的。對於Flume而言，一個event就是一個blob字節數據。這個event的大小是有限制的，例如，不能大於內存或硬盤或單機可以存儲的大小。事實上，flume的event可以是任何東西，從日志文本到圖片文件。Event的關鍵點是不斷生成、流式的。如果你的數據不是的定期生成的（比如一次性的向Hadoop集群導入數據），Flume可以工作，但是有點殺雞用牛刀了。Flume喜歡相對穩定的拓撲結構。你的拓撲結構不必是不可改變的，因為Flume可以在不丟失數據的前提下處理拓撲結構的改變，並且能容忍由於故障轉移導致的周期性的重新配置。但如果你每天都要改變拓撲結構，那么Flume將不能很好的工作，因為重新配置會產生開銷。
簡而言之，有兩點：
1、數據。數據是定期生成的。
2、網絡拓撲相對穩定。
Kafka、Flume都可以實現數據的傳輸，但它們的側重點不同。
Kafka追求的是高吞吐量、高負載（topic下可以有多個partition）
Flume追求的是數據的多樣性：數據來源的多樣性、數據流向的多樣性
如果數據來源很單一、想要高吞吐的話可以使用Kafka
如果數據來源很多、數據流向很多的話可以使用Flume
也可以將Kafka和Flume結合起來使用。