由于没具体研究过画图，以前在公司每天都用Excel，所以很多图画都是画在了Excel上再剪切的，看着可能不太舒服。
先来看一下数据走向：
这样我们就大致了解了flume是干嘛的，在什么位置了。
Flume简介：
Apache Flume是一个分布式、可信任（事务性）的弹性系统，用于高效收集、汇聚和移动大规模日志信息从多种不同的数据源到一个集中的数据存储中心（HDFS、HBas）
功能：
– 支持在日志系统中定制各类数据发送方，用于收集数据。
– Flume提供对数据进行简单处理，并写到各种数据接收方（可定制）的能力。
多种数据源：
– Console、RPC、Text、Tail、Syslog、Exec等。
数据源哪里来：
1.server log ： tail -n 10000 a.log | grep fatal/warning
2.http ： url
3.netcat ： ip：port
4.Text
5.Exec
6.filesystem：目录下，一旦数据有变化
等......
特点：
1.Flume可以高效率的将多个网站服务器中收集的日志信息存入HDFS/HBase中。
2.使用Flume，我们可以将从多个服务器中获取的数据迅速的移交给Hadoop中。
3.支持各种接入资源数据的类型以及接出数据类型。
4.支持多路径流量，多管道接入流量，多管道接出流量，上下文路由等。
5.可以被水平扩展。
两种机制：
复用机制：指定有效路径，flume可以有区别对待，log1走存储1策略1，log2走存储2策略2。
复制机制：log1来了给后面的存储1和存储2各发一份
外部架构：
数据发生器（websever 如：facebook,twitter）产生的数据被单个的运行在数据发生器所在服务器上的agent所收集，之后数据收容器从各个agent上汇集数据并将采集到的数据存入到HDFS或者HBase中。
Agent：代理模块，用来对消息进行接收和汇集。
通常agent和colector分别部署到不同节点（解耦）。
通常Agent会很多，因为每个日志服务器上都有一个agent，server和agent1：1
通常Agent部署在收集日志的服务器上，虽然flume包含Agent和Collector，但通常部署到不同的节点上。
数据单位：
Storm（tuple），HDFS（block），Flume（Event事件），Kafka（message）
Event有两部分组成：由两部分组成：转载数据的字节数组+可选头部。
Header（分发，可有可无）和body（存数据）。
Header 是 key/value 形式的，可以用来制造路由决策或携带其他结构化信息(如事件的时间戳或事件来源的服务器主机名)。你可以把它想象成和 HTTP 头一样提供相同的功能——通过该方法来传输正文之外的额外信息。Flume提供的不同source会给其生成的event添加不同的header。
Body是一个字节数组，包含了实际的内容。
特殊情况用Header，例如log1，log2那样指定路径了，用key来做分发。
代 理 ( Flume Agent )：
Flume内部有一个或者多个Agent。
每一个Agent是一个独立的守护进程(JVM)。
从客户端哪儿接收收集，或者从其他的Agent那接收，然后迅速的将获取的数据传给下一个目的节点Agent。
Agent主要由source、channel、sink三个组件组成。
source：真正对接数据源，接收数据源，转化成Event格式（输入）。
channel：管道（做一个缓存，可以存在文件里或者内存里，memory更快，但是数据量大，可能会丢失，建议存在file，channel是一个完整的事务,这一点保证了数据在收发的时候的一致性并且它可以和任意数量的source和sink链接）。
可以通过参数设置event的最大个数，Flume通常选择FileChannel，而不使用Memory Channel：
– Memory Channel：内存存储事务，吞吐率极高，但存在丢数据风险。
– File Channel：本地磁盘的事务实现模式，保证数据不会丢失（WAL实现）。
sink：输出（对接各种存储）。
例如：通过Flume HDFS Sink将数据放置到HDFS中，或者放置到下一个Flume的Source，等到下一个Flume处理。
对于缓存在通道中的事件，Source和Sink采用异步处理的方式
Sink成功取出Event后，将Event从Channel中移除。
Sink必须作用于一个确切的Channel。
不同类型的Sink：
– 存储Event到最终目的的终端：HDFS、Hbase。
– 自动消耗：Null Sink。
– 用于Agent之间通信：Avro（两个flume传输数据使用avro）。
agent还有两个组件（可选）：
interceptor：拦截器
用于Source的一组拦截器，按照预设的顺序必要地方对events进行过滤和自定义的处理逻辑实现。
在app(应用程序日志)和 source 之间的，对app日志进行拦截处理的。也即在日志进入到source之前，对日志进行一些包装、清新过滤等动作。
官方上提供的已有的拦截器有：
– Timestamp Interceptor：在event的header中添加一个key叫：timestamp,value为当前的时间戳。
– Host Interceptor：在event的header中添加一个key叫：host,value为当前机器的hostname或者ip。
– Static Interceptor：可以在event的header中添加自定义的key和value。
– Regex Filtering Interceptor：通过正则来清洗或包含匹配的events。
– Regex Extractor Interceptor：通过正则表达式来在header中添加指定的key,value则为正则匹配的部分。
flume的拦截器也是chain形式的，可以对一个source指定多个拦截器，按先后顺序依次处理。
selector：路由选择，看前面的数据是配置到channel1上还是channel2，channel3，或者全部配置。
channel selectors 有两种类型:
– Replicating Channel Selector (default)：将source过来的events发往所有channel。
– Multiplexing Channel Selector：而Multiplexing 可以选择该发往哪些channel。
selector：
复制 Replicating
复用 Multiplexing
可靠性：
*channel缓存可以存储到file中。
1.Flume保证单次跳转可靠性的方式：传送完成后，该事件才会从通道中移除。
2.Flume使用事务性的方法来保证事件交互的可靠性。
3.整个处理过程中，如果因为网络中断或者其他原因，在某一步*结束了，这个数据会在下一次重新传输。
4.Flume可靠性还体现在数据可暂存上面，当目标不可访问后，数据会暂存在Channel中，等目标可访问之后，再进行传输。
5.Source和Sink封装在一个事务的存储和检索中，即事件的放置或者提供由一个事务通过通道来分别提供。这保证了事件集在流中可靠地进行端到端的传递。
– Sink开启事务
– Sink从Channel中获取数据
– Sink把数据传给另一个Flume Agent的Source中
– Source开启事务
– Source把数据传给Channel
– Source关闭事务
– Sink关闭事务
经典的Flume流动图：
