flume概念介绍及工作机制（twenty-nine day first ）

先理解一下flume 数据采集

业务系统产生的日志等需要分析的数据存在了HDFS上，或KAFKA上，或MYSQL里，这种各种的数据源里，然后分析以后将结果文件放到目标文件中。

接着框架flume出现了，它定义了一个数据采集的流程，1、读数据，2、缓存数据，3、写数据

为避免读数据和写数据的速度不匹配（写数据是恒定的，但业务系统因为各种原因产生数据有时候是不确定的，所以读数据是不确定的），所以需要缓存数据，缓存在内存或本地磁盘.

读数据的时候在读完各种数据源需要内部流转，将数据格式统统封装成event（hashmap的），event内部数据流传有（head【描述信息】，body【数据】），读数据的时候会指定一个source接口，都来返回event，而source的实现类需要用户实现，读数据会去读数据源的source实现类，

同样的，写文件的时候也会有一个类似source的sink接口，来供写数据到各种目标存储系统，附图（借的）

 

Flume

　　flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。支持在日志系统中定制各类数据发送方，用于收集数据;同时，Flume提供对数据进行简单处理，并写到各种数据接收方(比如文本、HDFS、Hbase、mysql等)的能力 。
　　flume的数据流由事件(Event)贯穿始终。事件是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有头信息，这些Event由Agent外部的Source生成，当Source捕获事件后会进行特定的格式化，然后Source会把事件推入(单个或多个)Channel中。你可以把Channel看作是一个缓冲区，它将保存事件直到Sink处理完该事件。

　　Sink负责持久化日志或者把事件推向另一个Source。
 
　　1）flume的可靠性 
　　　　当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先将event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Store on failure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Besteffort（数据发送到接收方后，不会进行确认）。

　　2）flume的可恢复性
　　　　还是靠Channel。推荐使用FileChannel，事件持久化在本地文件系统里(性能较差)。

Flume的一些核心概念

　　Client：Client生产数据，运行在一个独立的线程。

　　Event： 一个数据单元，消息头和消息体组成。（Events可以是日志记录、 avro 对象等。）
　　Flow： Event从源点到达目的点的迁移的抽象。
　　Agent： 一个独立的Flume进程，包含组件Source、 Channel、 Sink。（Agent使用JVM 运行Flume。每台机器运行一个agent，但是可以在一个agent中包含多个sources和sinks。）
　　Source： 数据收集组件。（source从Client收集数据，传递给Channel）
　　Channel： 中转Event的一个临时存储，保存由Source组件传递过来的Event。（Channel连接 sources 和 sinks ，这个有点像一个队列。）
　　Sink： 从Channel中读取并移除Event， 将Event传递到FlowPipeline中的下一个Agent（如果有的话）（Sink从Channel收集数据，运行在一个独立线程。）