采集采集系统(IBM的这篇文章：FlumeOG上的第一次革命(组图))

　　采集采集系统(IBM的这篇文章：FlumeOG上的第一次革命(组图))

　　Flume 是一个分布式的、可靠的、高可用的海量日志采集、聚合和传输系统。支持自定义系统中各种数据发送方采集数据；同时，Flume 提供了简单处理数据和写入各种数据接收者（可定制）的能力。Flume的初始发布版本目前统称为Flume OG（原代），属于cloudera。但是随着Flume功能的扩展，Flume OG代码工程的缺点变得臃肿，核心组件设计不合理，核心配置不规范等，尤其是Flume OG的最新发布版本0.9< @4. 在0中，日志传输不稳定的现象特别严重。为了解决这些问题，cloudera于2011年10月22日完成了Flume-728，并对Flume进行了里程碑式的改变：重构核心组件、核心配置、代码架构。重构后的版本统称为Flume NG（下一代）；更改的另一个原因是将 Flume 收录在 Apache 的旗帜下，cloudera Flume 更名为 Apache Flume。IBM的文章：Flume NG：Flume历史上的第一次革命，从基础组件和用户体验的角度阐述了从Flume OG到Flume NG的革命性变化。cloudera Flume 更名为 Apache Flume。IBM的文章：Flume NG：Flume历史上的第一次革命，从基础组件和用户体验的角度阐述了从Flume OG到Flume NG的革命性变化。cloudera Flume 更名为 Apache Flume。IBM的文章：Flume NG：Flume历史上的第一次革命，从基础组件和用户体验的角度阐述了从Flume OG到Flume NG的革命性变化。

　　一、Flume OG

　　Flume OG的设计目标：

　　可靠性：当一个节点发生故障时，日志可以无损地转移到其他节点。Flume提供了三个级别的可靠性保证，从强到弱：端到端（agent收到数据，先把事件写到磁盘，数据传输成功后删除；如果数据失败已发送，可以重新发送。），失败时存储（这也是scribe采用的策略，当数据接收端崩溃时，将数据写入本地，恢复后继续发送），尽力而为（经过数据发送到接收方，没有将被确认）。可扩展性：Flume 采用三层架构，即代理、采集器和存储，每一层都可以水平扩展。其中所有的agent和collector都由master统一管理，便于系统监控和维护，并且允许多个master（使用ZooKeeper进行管理和负载均衡），避免了单点故障的问题。可管理性：所有代理和采集器均由Master统一管理，便于系统维护。在多master的情况下，Flume使用ZooKeeper和gossip来保证动态配置数据的一致性。用户可以在master上查看各个数据源或数据流的执行情况，可以配置和动态加载各个数据源。Flume 提供了两种形式的 web 和 shell 脚本命令来管理数据流。功能扩展性：用户可以根据需要添加自己的代理、采集器或存储。此外，Flume 自带很多组件，包括各种代理（文件、系统日志等）、采集器和存储（文件、HDFS 等）。

　　Flume OG的架构：

　　在 Flume 中，最重要的抽象是数据流，它描述了数据生成、传输、处理并最终写入目标的路径。

　　Flume框架对hadoop和zookeeper的依赖只在jar包上，不需要在Flume启动的时候也必须启动hadoop和zookeeper服务。

　　如前所述，Flume 使用分层架构：分别为 Agent、Collector 和 Storage。Agent用于采集数据，Agent是Flume中数据流产生的地方。同时，Agent 将生成的数据流传输给 Collector。Collector 用于聚合数据，通常会生成更大的流，然后传输到 Storage。其中，Agent和Collector都由两部分组成：source和sink，其中source是数据源，sink是数据的目的地。Flume 使用两个组件：Master 和 Node。Node 根据 Master shell 或 web 中的动态配置来确定它是 Agent 还是 Collector。

　　1、代理

　　代理的作用是将数据从数据源发送到采集器。Flume 自带了很多直接可用的数据源（source），比如：

　　更多信息请参考这位朋友的整理：

　　同时提供了很多sink，比如：

　　更多信息请参考这位朋友的整理：

　　2、采集器

　　Collector的作用是聚合多个agent的数据并加载到Storage中。它的源和汇类似于代理。

　　数据源（source），如：

　　水槽，例如：

　　3、存储

　　Storage是一个存储系统，可以是普通文件、HDFS、HIVE、HBase、分布式存储等。

　　4、大师

　　Master管理和协调Agent和Collector的配置等信息，是flume集群的控制器。

　　二、Flume NG

　　对于Flume OG来说，可以说是一个分布式的日志采集系统。它有Mater的概念。这取决于 Zookeeper。Agent 用于 采集 数据。Agent 是 Fl​​ume 中生成数据流的地方。同时，Agent 将生成的数据流传输到 Collector。相应地，采集器用于聚合数据，通常会产生更大的流。对于 Flume NG，它丢弃了 Master 和 Zookeeper，采集器没有了，Web 配置控制台也没有了。只剩下 source、sink 和 channel。此时Agent的概念包括source、channel、sink，完全由一个分布。类型系统成为一种传输工具。不同机器之间的数据传输不再像OG那样从agent->collector，

　　Flume NG 的核心概念：

　　Flume NG相对于Flume OG的主要变化：

　　Flume OG节点组成图：

　　Flume NG节点组成图：

　　对应OG的特点，FLUM NG的特点是：

　　Flume NG 以代理为最小的独立运行单元。代理是一个 JVM。单个代理由三个组件组成：Source、Sink 和 Channel。

　　Flume 的数据流是通过事件来贯穿的。Event是Flume的基本数据单元。它携带日志数据（以字节数组的形式）和头信息。这些事件由代理外部的源生成，例如上图中的 Web 服务器。当Source捕获到事件时，会进行特定的格式化，然后Source将事件推送到（单个或多个）Channel中。您可以将 Channel 视为缓冲区，它将保存事件，直到*敏*感*词*处理完事件。Sink 负责持久化日志或将事件推送到另一个 Source。值得注意的是，Flume 提供了大量内置的 Source、Channel 和 Sink 类型。不同类型的Source、Channel和Sink可以自由组合。组合方式基于用户设置的配置文件，非常灵活。例如：Channel 可以将事件临时存储在内存中或持久化到本地硬盘。Sink可以将日志写入HDFS、HBase，甚至是另一个Source等。Flume支持用户建立多级流，即多个agent可以协同工作，支持Fan-in、Fan-out、Contextual Routing、Backup路线。如下所示：

　　Flume 允许多个代理连接在一起，形成连接的多级跳转：

　　1、来源

　　Flume 支持 Avro、log4j、syslog 和 http post（json 格式的正文）。允许应用程序直接处理现有的Source，例如AvroSource、SyslogTcpSource。也可以写一个Source通过IPC或者RPC访问自己的应用，Avro和Thrift（NettyAvroRpcClient和ThriftRpcClient分别实现了RpcClient接口），其中Avro是默认的RPC协议。具体代码级别的客户端数据访问请参考官方手册。对现有程序的最小改动就是直接使用程序原来记录的日志文件，基本可以在不改动现有程序的情况下实现无缝访问。直接读取文件Source，有两种方式：

　　2、频道

　　目前有几种通道可供选择，分别是Memory Channel、JDBC Channel、File Channel和Psuedo Transaction Channel。前三个通道更常见。

　　File Channel 是一个持久化隧道（channel），它将所有事件持久化并存储到磁盘。因此，即使Java虚拟机崩溃，或者操作系统崩溃或重启，或者事件没有成功传递到管道中的下一个代理，这些都不会导致数据丢失。内存通道是一个不稳定的隧道，因为它将所有事件存储在内存中。如果 java 进程终止，则存储在内存中的任何事件都将丢失。另外，内存空间受限于RAM大小，File Channel是它的优势。只要磁盘空间足够，它就可以将所有的事件数据存储在磁盘上。

　　3、水槽

　　Sink在设置存储数据时可以将数据存储在文件系统、数据库、hadoop中。当日志数据较小时，可以将数据存储在文件系统中，并设置一定的时间间隔来保存数据。当日志数据较多时，可以将相应的日志数据存储在Hadoop中，方便日后进行相应的数据分析。更多sink内容可以参考。

　　整体来看NG对核心组件进行了*敏*感*词*的调整，核心组件的数量从7个减少到4个。 由于Flume的使用涉及到很多因素，比如avro、thrift、hdfs、jdbc、zookeeper、等等，这些组件和Flume的集成需要关联所有组件。因此，核心组件的改革对Flume的整个使用有着深远的影响：

　　参考链接：