大数据之Flume原理

听完小吴老师讲的以后，做的笔记~~~

1.Flume定义

Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。

当前Flume有两个版本Flume 0.9X版本的统称Flume-og，Flume1.X版本的统称Flume-ng。由于Flume-ng经过重大重构，与Flume-og有很大不同，使用时请注意区分。（我用的apache-flume-1.7.0-bin.tar.gz~~~~）

2.Flume组成结构

• WebServer代表外界数据来源，可来源于网络、文件、日志等等。

• Agent是一个JVM进程，它以事件的形式将数据从源头送至目的，是Flume数据传输的基本单元。Agent主要有3个部分组成，Source、Channel、Sink。

• Source数据输入端是用于接收外界数据Flume Agent的组件。不同的数据源会用不同的Source进行接收。下面介绍几种常用source：

1. spooling directory source（目标池），可以监控指定文件夹中的新文件变化，如果目录中有文件产生，就会立刻读取其内容。
2. exec source，可以用来执行本地shell命令，并把本地日志文件中的数据封装成Event事件流在Flume NG中流动。最常用的命令就是tail -F命令，可以实时的从本地日志文件中获取新追加的日志。
3. syslog source，用来监听系统日志变化。
4. avro source，常用于接收上一个Flume产生的日志信息。可以监听IP和端口，并不一定是本机的IP，可以监听其他机器的IP和port，用于获取数据，需要指定type，bind，以及port，其他都可以使用默认配置，而且可以配置拦截哪些IP的请求，对其不进行监听。
5. netcat source，监听一个给定的端口，然后把text文件的每一行转换成一个event。
6. Kafka Source，支持从Kafka指定的topic中读取数据。

• Channel是位于Source和Sink之间的缓冲区。Channel允许Source和Sink运作在不同的速率上。Channel是线程安全的，可以同时处理几个Source的写入操作和几个Sink的读取操作。以下两种常用Channel：

1. Memory Channel：基于内存缓存，是一个不稳定的隧道（channel）。优点是处理速度快，但数据已丢失。适用于不关心数据丢失的场景下。
2. File Channel：基于磁盘存储，是一个持久化的隧道（channel），他持久化所有的事件，并将其存储到磁盘中。因此，即使系统宕机或者事件没有在管道中成功地传递到下一个代理（agent），都不会造成数据丢失，但速度相比Memory Channel慢。

• Sink不断地轮询Channel中的事件且批量地移除它们，并将这些事件批量写入到存储或索引系统、或者被发送到另一个Flume Agent。Sink是完全事务性的。在从Channel批量删除数据之前，每个Sink用Channel启动一个事务。批量事件一旦成功写出到存储系统或下一个Flume Agent，Sink就利用Channel提交事务。事务一旦被提交，该Channel从自己的内部缓冲区删除事件。Sink数据输出端常见目的地包括HDFS、Kafka、logger、avro、File等。

1. HDFS Sink:

   此Sink将事件写入到Hadoop分布式文件系统HDFS中。它支持创建文本文件和序列化文件。
   注意:hadoop版本必须支持sync()调用。
   属性说明:
                   !channel    –     
                   !type    –    类型名称，必须是“HDFS”
                   !hdfs.path    –    HDFS 目录路径 (eg hdfs://namenode/flume/webdata/)
                   hdfs.filePrefix    FlumeData    Flume在目录下创建文件的名称前缀
                   hdfs.fileSuffix    –    追加到文件的名称后缀 (eg .avro - 注: 日期时间不会自动添加)
                   hdfs.inUsePrefix    –    Flume正在处理的文件所加的前缀
                          hdfs.inUseSuffix    .tmp    Flume正在处理的文件所加的后缀

2. Kafka Sink:此Sink将事件写入到Kafka中。

3. Logger Sink:记录INFO级别的日志，一般用于调试。前面介绍Source时候用到的Sink都是这个类型的Sink
   必须配置的属性：
   属性说明：
                   !channel    –     
                   !type    –    The component type name, needs to be logger
                   maxBytesToLog    16    Maximum number of bytes of the Event body to log
                   要求必须在 --conf 参数指定的目录下有 log4j的配置文件
                   可以通过-Dflume.root.logger=INFO,console在命令启动时手动指定log4j参数

4. Avro Sink:
   是实现多级流动 和 扇出流(1到多) 扇入流(多到1) 的基础。非常重要 但是需要多台机器
   属性说明:
                   !channel    –     
                   !type    –    The component type name, needs to be avro.
                   !hostname    –    The hostname or IP address to bind to.
                   !port    –    The port # to listen on.

5. File  Roll Sink:在本地文件系统中存储事件。每隔指定时长生成文件保存这段时间内收集到的日志信息。
   属性说明：
                   !channel    –     
                   !type    –    类型，必须是"file_roll"
                   !sink.directory    –    文件被存储的目录
                   sink.rollInterval    30    滚动文件每隔30秒（应该是每隔30秒钟单独切割数据到一个文件的意思）。
                   如果设置为0，则禁止滚动，从而导致所有数据被写入到一个文件。
                   sink.serializer    TEXT    Other possible options include avro_event or the FQCN of an implementation of                    EventSerializer.Builder interface.
                   batchSize    100 

• Put Transaction(事务)流程

1. doPut:将批数据先写入临时缓冲区putlist。
2. doCommit:检查channel内存队列是否有足够空间进行当前的数据合并。
3. doRollback:如果channel中内存队列空间不足时，channel中已接收到的部分数据直接抛弃，靠上一个节点重发数据。同时进行数据回滚。

• Take Transaction(事务)流程

1. doTake:先将数据取到临时缓冲区takelist。
2. doCommit:如果数据完全发送成功，则清除临时缓冲区takelist。
3. doRollback:数据发送过程中如果出现异常，rollback将临时缓冲区takelist中的数据归还给channel内存队列。

• Event(事件)是传输单元，Flume数据传输的基本单元，以事件的形式将数据从源头送至目的地。

3.Flume拓朴结构

点对点连接

• 这种是最简单的方式，两个flume，一个的sink是另一个的source，这种结构有点像链式结构，后面还可以接着加节点 

 

单source，多channel、sink

•  这种结构特点: 一个source，多个channel，而多个channel是同一内容，只不过后面的sink不同，这种场景比如，读取一个日志文件，一份要交给hadoop离线处理，一份相同的交给spark实时处理。

Flume负载均衡

•  常用于大数据领域，使用多个sink进行负载均衡。

 

Flume Agent聚合

• 常用于集群架构，每个集群都会产生日志文件，为了将每个日志文件进行收集，就采用这种聚合模式。