大数据的数据采集是大数据技术中非常重要、基础的部分，数据不会平白无故地跑到我们的数据平台中，我们得用什么东西把它从现有的设备（比如服务器，路由器、交换机、防火墙、数据库等）中采集过来，再传输到数据平台中，后面才有更加复杂的高难度的处理技术。
在采集过程中，如何应对数据多样性、数据量大、变化快等特点，如何保证数据采集的可靠性、性能，如何避免重复数据，如何保证数据质量，如何降低资源成本，这些都是大数据采集面临的难点问题，所以，选择一款合适的采集工具至关重要。
目前，Flume和Logstash是比较主流的数据采集工具（主要用于日志采集），以下将对这两款工具进行详细介绍以及对比选型。
首先介绍数据采集的通用模型，如图：
其中，数据采集和存储是必要的环节，其他并不一定需要。但这只是一个粗略的通用模型，不同开源社区或者厂家开发时都会有自己的考虑和目的。Flume和Logstash原则上都属于数据采集这个范畴，但是两者在技术上或多或少都自带了一些缓冲、过滤等功能。
一、历史简介
Logstash：
Logstash诞生于2009年8月，2013年被ElasticSearch公司收购。Logstash是一个分布式日志收集框架，开发语言是JRuby，经常与ElasticSearch，Kibana配合使用组成著名的ELK技术栈，所谓ELK就是ElasticSearch、
Logstash、Kibana这三个组件（ES负责数据的存储和索引，Logstash负责数据采集和过滤转换，Kibana则负责图形界面处理），后来这三个组件又先后被Elastic.co公司收购。
Logstash非常适合做日志数据的采集，可以采用ELK组合使用，也可以作为日志收集软件单独出现，单独出现时可将日志存储到多种存储系统或临时中转系统，如MySQL，redis，kakfa，HDFS, lucene，solr等，并不一定是ElasticSearch。
Flume：
Flume诞生于2010年，最早由Cloudrea开发，是一个高可用，高可靠，的分布式海量日志采集系统，支持定制各类数据发送方，一般和 kafka 订阅消息系统搭配较多。其设计原理也是基于将数据流，如日志数据从各种网站服务器上汇集起来存储到HDFS，HBase等集中存储系统中。Flume目前有两个版本，OG和NG，区别很大，初始的发行版本叫做FlumeOG，后被apache收购，改名为Apache Flume，收购重构后的版本统称为
Flume NG（next generation下一代的意思）；所以现在Flume已经是ApacheETL工具集中的一员。
结论：两者最初的设计目的就不太一样。Flume本身最初设计的目的是为了把数
据传入HDFS中（并不是为了采集日志而设计，这和Logstash有根本的区别），所以理所应当侧重于数据的传输，程序员要非常清楚整个数据的路由，并且比Logstash还多了一个可靠性策略，上文中的channel就是用于持久化目的，数据除非确认传输到下一位置了，否则不会删除，这一步是通过事务来控制的，这样的设计使得可靠性非常好。相反，Logstash则明显侧重对数据的预处理，因为日志的字段需要大量的预处理，为解析做铺垫。
二、系统架构
Logstash：
Logstash的设计非常规范，有三个组件，分工如下：
1、Shipper：负责日志收集。职责是监控本地日志文件的变化，并输出到
Redis 缓存起来；
2、Broker 可以看作是日志集线器，可以连接多个 Shipper 和多个 Indexer；
3、Indexer 负责日志存储。在这个架构中会从 Redis 接收日志，写入到本地文
件。
因为架构比较灵活，所以如果不想用 Logstash 的存储，也可以对接到Elasticsearch，这也就是前面所说的 ELK 的套路了。
如果继续细分，Logstash也可以这么解剖来看
所以Logstash就是这么简约，全部将代码集成，程序员不需要关心里面是如何运转的。
Logstash最值得一提的是，在Filter plugin部分具有比较完备的功能，比如grok，能通过正则解析和结构化任何文本，Grok 目前是Logstash最好的方式对非结构化日志数据解析成结构化和可查询化。此外，Logstash还可以重命名、删除、替换和修改事件字段，当然也包括完全丢弃事件，如debug事件。
还有很多的复杂功能供程序员自己选择，你会发现这些功能Flume是绝对没有（以它的轻量级线程也是不可能做到的）。当然，在input和output两个插件部分也具有非常多类似的可选择性功能，程序员可以自由选择，这一点跟Flume是比较相似的。
Flume：
下图是Flume NG的架构图：
Flume 从原理上看很简单，三段式的结构：源（Source输入）—存储（Channel管道）—出口（Sink目标输出）。但也因为涉及到这三个结构，所以做配置就比较复杂，这里举个例子，看看Flume在一些场景下是如何搭建布置的，如下图是Flume的集群部署：
Flume支持一个Agent中有多个不同类型的channel和sink，我们可以选择把
Source的数据复制，分发给不同的目的端口，如下图（Flume的多重复使用）：
其次，Flume还自带了分区和拦截器功能，所以Flume也是有过滤功能的，只是Flume的过滤功能比较弱。Flume在集群中最擅长的事情就是做路由了，因为每一个Flume Agent相连就构成了一条链路，这也是众多采集工具中Flume非常出色的亮点。但是也正因为如此，如果有一个Flume Agent出了问题，那么整个链路也会出现问题，所以在集群中需要设计分层架构等来实现冗余备份。但这么一来，配置又会变得很麻烦。
结论：我们会惊人的发现，两者是多么的相似！Logstash的Shipper、
Broker、Indexer分别和Flume的Source、Channel、Sink各自对应！只不过是Logstash集成了，Broker可以不需要，而Flume需要单独配置，且缺一不可，但这再一次说明了计算机的设计思想都是通用的！只是实现方式会不同而已。
三、开发配置
从程序员的角度来说，Flume配置比较繁琐，你需要分别作source、channel、sink的手工配置，而且涉及到复杂的数据采集环境，你可能还要做多个配置，而Logstash的配置就非常简洁清晰，三个部分的属性都定义好了，程序员自己去选择就行，就算没有，也可以自行开发插件，非常方便。当然了，Flume的插件也很多，但Channel就只有内存和文件这两种（其实现在不止了，但常用的也就两种）。读者可以看得出来，两者其实配置都是非常灵活的，只不过看场景取舍罢了。
四、性能、可靠性
因为Logstash内部是没有persist queue（打印队列）的机制，所以在异常情况下，可能出现数据丢失的问题。所以选择Logstash一般认为这个日志可能不重要。而Flume在高可用（可靠性）方面做得比较好，有自己的内部机制确保这个问题，所以可以用于一些更重要的业务日志场景下。
性能上Logstash要高于Flume,因为Flume运用了一套安全机制，牺牲了部分性能。
五、插件
Logstash插件丰富，有几十个插件，而且配置灵活，所以在扩展功能上比较全面。Flume没有丰富的插件，主要靠二次开发（其实source和sink的种类也有一二十个，channel就比较少了）；
六、市场占有率级使用平台
logstash是用的最多的，github上有4000+ stars，因为它好在有一套完整的日志收集（logstash）、日志存储（elasticsearch）、日志展示分析（kibana）套件，搭建起来非常方便。
Logstash用户：
Flume用户：美团
七、总结
Logstash：
1、内部没有一个persist queue（打印队列），异常情况可能会丢失部分数据；
2、由ruby编写，需要ruby环境，插件很多；
3、偏重数据的预处理，为数据解析做铺垫；
4、插件丰富，Logstash有几十个插件，配置灵活；
5、Logstash的input和Fillter还有output之间都存在buffer，进行缓冲；
6、有ELK套件，技术成熟，使用场景广泛，但比较重量级
Flume：
1.分布式高可靠高可用的数据采集系统，高效的从不同数据源收集、聚合、迁移数据到一个集中的数据存储；
2、侧重数据传输，使用基于事务的数据传递方式保证事件传递的可靠性，确保不会丢数据，用于重要日志场景；
3、由java开发，没有丰富的插件，主要靠二次开发（source和sink的种类也有一二十个，channel就比较少了）；
4、轻量级线程，轻量级框架，以配置文件为中心，提供了JavaAPI；
5、安装部署比较复杂，配置繁琐，source，channel，sink三大组件都需要配置；
6.三层架构：source、channel、sink，是一个完整的基于插件的架构，有独立开发的第三方插件；
7、Flume直接使用channel做持久化（可以理解为没有filter）最后，flume是apache的，可以使用hadoop的hdfs，后端分析用MapReduce，选择灵活多样，而Logstash其实更有点像通用的模型，让一切都变的简单，所以对新人来说理解起来更简单；Logstash就像是买来的台式机，主板、电源、硬盘，机箱（Logstash）把里面的东西全部装好了，你可以直接用，当然也可以自己组装修改；Flume就像提供给你一套完整的主板，电源、硬盘，Flume没有打包，只是像说明书一样指导你如何组装，才能运行的起来。