Flume 总结（二）flume概念

Flume 总结（二）flume概念

1. agent 代理

1. flume作为分布式日志采集框架，需要从各种分布式集群中进行日志文件采集
2. 这时候，flume就需要在各个节点上运行一个程序进行数据采集，这个程序就叫做agent。（可以理解flume就是一个抽水机系统，agent就是挂在各个池塘，河流中的一个一个抽水机，agent抽水之后，通过管道将水汇聚到一个地方）
3. flume 采集系统就是由agent互相连接组合起来的，和抽水机一样，agent也可以互相连接起来，组合成一个负载的级联网络，就跟大家在生活遇到的一级水泵，二级水泵，三级水泵一样一样的。
   
   
4. agent本身内部又是由source、channel、sink三个模块组成的。

• souce可以看作是水泵的进水口，在这里可以对数据做清洗，过滤等操作。就跟水泵的进水口会有各种滤网是一样一样的。
• channel，可以看做是水泵的中间仓，因为有时候进水口和出水口的水流速度不一样，这时候channel就像一个缓冲器一样，可以对数据流速做缓冲。所以channel可以看成是一个缓冲池，用来缓解数据流入和数据流出之间的速度差异的。极端情况下，还会使用kafka等来做缓存，避免数据流入和数据流出速度相差过大，一般是数据流出速度小于速度流入，例如做活动时，线上用户流量暴增，日志也暴增
• sink，可以看成是出水口。

和水泵一样，一个agent中，可以有多个source进行数据采集，可以有多个channel进行数据缓冲，可以有多个sink进行数据流出。
因为这种灵活性，可以很好适应企业开发中各种日志采集业务需求。

2. event事件

1. 因为日志数据本身会有各种来源，如socket、文件、mysql、kafka。数据来源多种多样，同样的数据形式也多种多样，那如何让这些数据能够很方便在agent内部的source、channel、sink甚至agent之间进行很方便的传输呢？
2. event就应运而生，使用一个对象，将这些数据一份一份包装起来。

• event中包含header和body，header就是一个hashmap，可以使用key value形式对这些数据添加附加信息。
• 因为需要对数据做清洗、过滤、基本数据补齐、分发等操作，所以一定的附加信息可以很方便这些清洗过滤操作。
• event中的body就是一个字节数组，没错，就跟hbase一样，使用字节数组可以模糊掉数据类型，不管存取，都由开发者自己定义，这样灵活性可以有很好的保证，并且字节数组是最基础的数据类型，可以支持做更多数据操作。
• event的组成可以看出，这样是很方便做序列化操作的，也就方便event在agent内部的source、channel、sink模块之间传输，也方便在agent之间，agent和输出目的地之间进行数据传输。

3. transaction事务控制

1. 一个公司最重要的资产之一就是数据，而现在互联网公司都是采取敏捷开发的方式。

• 敏捷开发意味着最小功能开发，然后使用迭代方式对非核心功能进行逐步迭代，核心功能进行规划性迭代。在这个时候，由于互联网受众众多，如何确保自己开发出来的产品能够得到用户喜欢，使用用户行为日志分析就是一个很好的方式。
• 在传统软件开发中，使用问卷调查、试用、内部使用等方式开发软件越来越不适应现有的互联网用户喜好。而且目前很多用户都是身心不一的代表着，嘴里说着不要，身体很诚实的现象很普遍。这时候采用行为日志分析就是一个非常好的方式，因为行为不会说谎，喜欢就是喜欢，不喜欢就是不喜欢，都会体现在用户行为日志中。

2. 事务控制，顾名思义，事务控制可以达到ACID四个特征，这样一来，能够确保日志数据采集时，数据能够不丢失。当然，实际上flume的事务控制并不能像mysql一样做到很精准的数据不丢失也不重复，flume的事务控制考虑了性能，针对不同source，channel，sink类型，可以比较好保证数据不丢失，但无法保证数据不重复。
3. flume的事务控制，体现在2个流程。数据从source到channel，数据从channel到sink。
   

1. 以TailDirSource举例（注意不是所有的source都实现了事务控制，如exec source就没有实现事务控制）。当数据从source中采集好一批，传输给ch