2023年7月17日发(作者：)

数据采集：Flume和Logstash的⼯作原理和应⽤场景在某个Logstash的场景下，我产⽣了为什么不能⽤Flume代替Logstash的疑问，因此查阅了不少材料在这⾥总结，⼤部分都是前⼈的⼯作经验下，加了⼀些我⾃⼰的思考在⾥⾯，希望对⼤家有帮助。⼤数据的数据采集⼯作是⼤数据技术中⾮常重要、基础的部分，数据不会平⽩⽆故地跑到你的数据平台软件中，你得⽤什么东西把它从现有的设备（⽐如服务器，路由器、交换机、防⽕墙、数据库等）采集过来，再传输到你的平台中，然后才会有后⾯更加复杂⾼难度的处理技术。⽬前，Flume和Logstash是⽐较主流的数据采集⼯具（主要⽤于⽇志采集），但是很多⼈还不太明⽩两者的区别，特别是对⽤户来说，具体场景使⽤合适的采集⼯具，可以⼤⼤提⾼效率和可靠性，并降低资源成本。通⽤的数据采集模型⾸先我们给出⼀个通⽤的数据采集模型，主要是让不太懂计算机或者通信的读者们了解⼀下。

其中，数据采集和存储是必要的环节，其他并不⼀定需要。是不是很简单？本来编程其实就是模块化的东西，没有那么难。但是这毕竟只是⼀个粗略的通⽤模型，不同开源社区或者商业⼚家开发的时候都会有⾃⼰的考虑和⽬的。我们在本⽂要讨论的Flume和Logstash原则上都属于数据采集这个范畴，尽管两者在技术上或多或少都⾃带了⼀些缓冲、过滤等等功能。好，我们先来看Logstash，然后看Flume，等你全部看完你就知道我为什么这么安排了。

LogstashLogstash是ELK组件中的⼀个。所谓ELK就是指，ElasticSearch、Logstash、Kibana这三个组件。那么为什么这三个组件要合在⼀起说呢？第⼀，这三个组件往往是配合使⽤的（ES负责数据的存储和索引，Logstash负责数据采集和过滤转换，Kibana则负责图形界⾯处理）；第⼆，这三个组件⼜先后被收购于公司名下。是不是很巧合？这⾥说个题外话，原ELK Stack在5.0版本加⼊Beats（⼀种代理）套件后改称为Elastic Stack，这两个词是⼀个意思，只不过因为增加了Beats代理⼯具，改了个名字。Logstash诞⽣于2009年8有2⽇，其作者是世界著名的虚拟主机托管商DreamHost的运维⼯程师乔丹 西塞（Jordan Sissel）。Logstash的开发很早，对⽐⼀下，Scribed诞⽣于2008年，Flume诞⽣于2010年，Graylog2诞⽣于2010年，Fluentd诞⽣于2011年。2013年，Logstash被ElasticSearch公司收购。这⾥顺便提⼀句，Logstash是乔丹的作品，所以带着独特的个⼈性格，这⼀点不像Facebook的Scribe，Apache的Flume开源基⾦项⽬。你说的没错，以上都是废话。（⼿动滑稽→_→）Logstash的设计⾮常规范，有三个组件，其分⼯如下：1、Shipper 负责⽇志收集。职责是监控本地⽇志⽂件的变化，并输出到 Redis 缓存起来；2、Broker 可以看作是⽇志集线器，可以连接多个 Shipper 和多个 Indexer；3、Indexer 负责⽇志存储。在这个架构中会从 Redis 接收⽇志，写⼊到本地⽂件。这⾥要说明，因为架构⽐较灵活，如果不想⽤ Logstash 的存储，也可以对接到 Elasticsearch，这也就是前⾯所说的 ELK 的套路了。

Logstash结构图

如果继续细分，Logstash也可以这么解剖来看

Logstash三个⼯作阶段

貌似到这⾥。。。好像就讲完了。。。读者朋友们不要骂我，因为Logstash就是这么简约，全部将代码集成，程序员不需要关⼼⾥⾯是如何运转的。Logstash最值得⼀提的是，在Filter plugin部分具有⽐较完备的功能，⽐如grok，能通过正则解析和结构化任何⽂本，Grok ⽬前是Logstash最好的⽅式对⾮结构化⽇志数据解析成结构化和可查询化。此外，Logstash还可以重命名、删除、替换和修改事件字段，当然也包括完全丢弃事件，如debug事件。还有很多的复杂功能供程序员⾃⼰选择，你会发现这些功能Flume是绝对没有（以它的轻量级线程也是不可能做到的）。当然，在input和output两个插件部分也具有⾮常多类似的可选择性功能，程序员可以⾃由选择，这⼀点跟Flume是⽐较相似的。FlumeLogstash因为集成化设计，所以理解起来其实不难。现在我们讲讲Flume，这块内容就有点多了。最早Flume是由Cloudrea开发的⽇志收集系统，初始的发⾏版本叫做Flume OG（就是original generation的意思），作为开源⼯具，⼀经公布，其实是很受关注的⼀套⼯具，但是后⾯随着功能的拓展，暴露出代码⼯程臃肿、核⼼组件设计不合理、核⼼配置不标准等各种缺点。尤其是在Flume OG的最后⼀个发⾏版本0.94.0中，⽇志传输不稳定的现象特别严重。我们来看看Flume OG到底有什么问题。

Flume OG架构图

直到现在，你在⽹络上搜索Flume相关资料的时候还会经常出现Flume OG的结构图，这对新⼈来说是很不友好的，很容易引起误导，请读者朋友们⼀定要注意！我们可以看到Flume OG有三种⾓⾊的节点：代理节点（agent）、收集节点（collector）、主节点（master）。流程理解起来也并不困难：agent 从各个数据源收集⽇志数据，将收集到的数据集中到 collector，然后由收集节点汇总存⼊ hdfs。master 负责管理 agent，collector 的活动。agent、collector 都称为 node，node 的⾓⾊根据配置的不同分为 logical node（逻辑节点）、physical node（物理节点）。对logical nodes和physical nodes的区分、配置、使⽤⼀直以来都是使⽤者最头疼的地⽅。

Flume OG中节点的构成

agent、collector 由 source、sink 组成，代表在当前节点数据是从 source 传送到 sink。就算是外⾏⼈，看到这⾥也觉得很头⼤，这尼玛是谁设计出来的破玩意？各种问题的暴露，迫使开发者痛下决⼼，抛弃原有的设计理念，彻底重写Flume。于是在2011 年 10 ⽉ 22 号，Cloudera 完成了Flume-728，对 Flume 进⾏了⾥程碑式的改动：重构核⼼组件、核⼼配置以及代码架构，重构后的版本统称为 Flume NG（nextgeneration下⼀代的意思）；改动的另⼀原因是将 Flume 纳⼊ apache 旗下，Cloudera Flume 改名为 Apache Flume，所以现在Flume已经是Apache ETL⼯具集中的⼀员。这⾥说个题外话，⼤家都知道，通常情况下⼤公司，特别是⼤型IT公司是⽐较排斥使⽤⼀些不稳定的新技术的，也不喜欢频繁变换技术，这很简单，因为变化很容易导致意外。举个例⼦，Linux发展了⼆⼗多年了，⼤部分公司都在使⽤RedHat、CentOS和Ubuntu这类旨在提供稳定、兼容好的版本，如果你看到⼀家公司⽤的是Linux新内核，那多半是⼀家新公司，需要⽤⼀些新技术在竞争中处于上风。好，了解了⼀些历史背景，现在我们可以放上Flume NG的结构图了

Flume NG结构图

卧槽，是不是很简单？！对⽐⼀下OG的结构，外⾏⼈都会惊叹：so easy！这次开发者吸取了OG的⾎淋林教训，将最核⼼的⼏块部分做了改动：1、NG 只有⼀种⾓⾊的节点：代理节点（agent），⽽不是像OG那么多⾓⾊；2、没有collector，master节点。这是核⼼组件最核⼼的变化；3、去除了physical nodes、logical nodes的概念和相关内容；4、agent 节点的组成也发⽣了变化，NG agent由source、sink、channel组成。那么这么做有什么好处呢？简单概括有这么三点：1、NG 简化核⼼组件，移除了 OG 版本代码⼯程臃肿、核⼼组件设计不合理、核⼼配置不标准等缺点，使得数据流的配置变得更简单合理，这是⽐较直观的⼀个改进点；2、NG 脱离了 Flume 稳定性对 zookeeper 的依赖。在早期的OG版本中，Flume 的使⽤稳定性依赖 zookeeper。它需要zookeeper 对其多类节点（agent、collector、master）的⼯作进⾏管理，尤其是在集群中配置多个 master 的情况下。当然，OG也可以⽤内存的⽅式管理各类节点的配置信息，但是需要⽤户能够忍受在机器出现故障时配置信息出现丢失。所以说 OG 的稳定⾏使⽤是依赖 zookeeper 的。3、NG 版本对⽤户要求⼤⼤降低：安装过程除了java⽆需配置复杂的Flume相关属性，也⽆需搭建zookeeper集群，安装过程⼏乎零⼯作量。有⼈很不解，怎么突然冒出来⼀个Zookeeper这个概念，这是个啥玩意？简单的说，Zookeeper 是针对⼤型分布式系统的可靠协调系统，适⽤于有多类⾓⾊集群管理。你可以把它理解为整个Hadoop的总管家，负责整个系统所有组件之间的协调⼯作管理。这个组件平时很不起眼，但⾮常重要。好⽐⼀⽀篮球队，五个队员个个都是巨星，所以我们平时都习惯关注这五个⼈，但是整个球队的获胜缺不了教练的协调组织、战术安排，Zookeeper就好⽐是整个Hadoop系统的教练。⽐喻虽然有些⽣硬，只是想说明Zookeeper的重要性，也侧⾯说明NG在摆脱了Zookeeper的依赖后变得更加轻便，灵活。说个题外话，OG版本的使⽤⽂档有90多页，⽽NG只⽤ 20 多页的内容就完成了新版 Flume 的使⽤说明。可见在科学研究领域，⼈类总是在追求真理，⽽真理总是可以⽤最简单的语⾔描述出来。到这⾥差不多Flume就讲的差不多了，因为这个线程⼯具从原理上讲真的很简单，三段式的结构：源（Source输⼊）——存储（Channel管道）——出⼝（Sink⽬标输出）。但也因为涉及到这三个结构，所以做配置就⽐较复杂，这⾥举个例⼦，我们看看Flume在⼀些场景下是如何搭建布置的。

Flume集群部署

这⾥要纠正⼏个很多初学Flume朋友们的误区。⾸先，Flume已经可以⽀持⼀个Agent中有多个不同类型的channel和sink，我们可以选择把Source的数据复制，分发给不同的⽬的端⼝，⽐如：

Flume的多重复⽤ 其次，Flume还⾃带了分区和拦截器功能，因此不是像很多实验者认为的没有过滤功能（当然我承认Flume的过滤功能⽐较弱）。读者可能会隐约感觉到，Flume在集群中最擅长的事情就是做路由了，因为每⼀个Flume Agent相连就构成了⼀条链路，这也是众多采集⼯具中Flume⾮常出⾊的亮点。但是也正因为如此，如果有⼀个Flume Agent出了问题，那么整个链路也会出现问题，所以在集群中需要设计分层架构等来实现冗余备份。但这么⼀来，配置⼜会变得很⿇烦。最后⼀个⼤⼤的分隔线Logstash和Flume对⽐把Logstash和Flume都讲完了，我们最后可以对⽐总结⼀下了。⾸先从结构对⽐，我们会惊⼈的发现，两者是多么的相似！Logstash的Shipper、Broker、Indexer分别和Flume的Source、Channel、Sink各⾃对应！只不过是Logstash集成了，Broker可以不需要，⽽Flume需要单独配置，且缺⼀不可，但这再⼀次说明了计算机的设计思想都是通⽤的！只是实现⽅式会不同⽽已。从程序员的⾓度来说，上⽂也提到过了，Flume是真的很繁琐，你需要分别作source、channel、sink的⼿⼯配置，⽽且涉及到复杂的数据采集环境，你可能还要做多个配置，这在上⾯提过了，反过来说Logstash的配置就⾮常简洁清晰，三个部分的属性都定义好了，程序员⾃⼰去选择就⾏，就算没有，也可以⾃⾏开发插件，⾮常⽅便。当然了，Flume的插件也很多，但Channel就只有内存和⽂件这两种（其实现在不⽌了，但常⽤的也就两种）。读者可以看得出来，两者其实配置都是⾮常灵活的，只不过看场景取舍罢了。其实从作者和历史背景来看，两者最初的设计⽬的就不太⼀样。Flume本⾝最初设计的⽬的是为了把数据传⼊HDFS中（并不是为了采集⽇志⽽设计，这和Logstash有根本的区别），所以理所应当侧重于数据的传输，程序员要⾮常清楚整个数据的路由，并且⽐Logstash还多了⼀个可靠性策略，上⽂中的channel就是⽤于持久化⽬的，数据除⾮确认传输到下⼀位置了，否则不会删除，这⼀步是通过事务来控制的，这样的设计使得可靠性⾮常好。相反，Logstash则明显侧重对数据的预处理，因为⽇志的字段需要⼤量的预处理，为解析做铺垫。回过来看我当初为什么先讲Logstash然后讲Flume？这⾥⾯有⼏个考虑，其⼀：Logstash其实更有点像通⽤的模型，所以对新⼈来说理解起来更简单，⽽Flume这样轻量级的线程，可能有⼀定的计算机编程基础理解起来更好；其⼆：⽬前⼤部分的情况下，Logstash⽤的更加多，这个数据我⾃⼰没有统计过，但是根据经验判断，Logstash可以和ELK其他组件配合使⽤，开发、应⽤都会简单很多，技术成熟，使⽤场景⼴泛。相反Flume组件就需要和其他很多⼯具配合使⽤，场景的针对性会⽐较强，更不⽤提Flume的配置过于繁琐复杂了。最后总结下来，我们可以这么理解他们的区别：Logstash就像是买来的台式机，主板、电源、硬盘，机箱（Logstash）把⾥⾯的东西全部装好了，你可以直接⽤，当然也可以⾃⼰组装修改；Flume就像提供给你⼀套完整的主板，电源、硬盘，Flume没有打包，只是像说明书⼀样指导你如何组装，才能运⾏的起来。讲完，收⼯。参考⽂献：《Flume⽇志收集与Map Reduce模式》张龙 译《ELK stack权威指南》 饶琛琳 编著 Flume综述与实例 Flume⽇志收集 Flume NG Flume⽇志收集分层架构应⽤实践 Flume⽇志采集系统 Logstash指南 Logstash讲解与实战应⽤