大数据的数据采集是大数据技术中非常重要、基础的部分,数据不会平白无故地跑到我们的数据平台中,我们得用什么东西把它从现有的设备(比如服务器,路由器、交换机、防火墙、数据库等)中采集过来,再传输到数据平台中,后面才有更加复杂的高难度的处理技术。
在采集过程中,如何应对数据多样性、数据量大、变化快等特点,如何保证数据采集的可靠性、性能,如何避免重复数据,如何保证数据质量,如何降低资源成本,这些都是大数据采集面临的难点问题,所以,选择一款合适的采集工具至关重要。
目前,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没有打包,只是像说明书一样指导你如何组装,才能运行的起来。
网友评论