Storm基本概念
storm简介
- 场景
伴随着信息科技日新月异的发展，信息呈现出爆发式的膨胀，人们获取信息的途径也更加多样、更加便捷，同时对于信息的时效性要求也越来越高。举个搜索场景中的例子，当一个卖家发布了一条宝贝信息时，他希望的当然是这个宝贝马上就可以被卖家搜索出来、点击、购买啦，相反，如果这个宝贝要等到第二天或者更久才可以被搜出来，估计这个大哥就要骂娘了。再举一个推荐的例子，如果用户昨天在淘宝上买了一双袜子，今天想买一副泳镜去游泳，但是却发现系统在不遗余力地给他推荐袜子、鞋子，根本对他今天寻找泳镜的行为视而不见，估计这哥们心里就会想推荐你妹呀。其实稍微了解点背景知识的码农们都知道，这是因为后台系统做的是每天一次的全量处理，而且大多是在夜深人静之时做的，那么你今天白天做的事情当然要明天才能反映出来啦。
- 实现一个实时计算系统
全量数据处理使用的大多是鼎鼎大名的hadoop或者hive，作为一个批处理系统，hadoop以其吞吐量大、自动容错等优点，在海量数据处理上得到了广泛的使用。但是，hadoop不擅长实时计算，因为它天然就是为批处理而生的，这也是业界一致的共识。否则最近这两年也不会有s4,storm,puma这些实时计算系统如雨后春笋般冒出来啦。先抛开s4,storm,puma这些系统不谈，我们首先来看一下，如果让我们自己设计一个实时计算系统，我们要解决哪些问题。
- 低延迟。都说了是实时计算系统了，延迟是一定要低的。
- 高性能。性能不高就是浪费机器，浪费机器是要受批评的哦。
- 分布式。系统都是为应用场景而生的，如果你的应用场景、你的数据和计算单机就能搞定，那么不用考虑这些复杂的问题了。我们所说的是单机搞不定的情况。
- 可扩展。伴随着业务的发展，我们的数据量、计算量可能会越来越大，所以希望这个系统是可扩展的。
- 容错。这是分布式系统中通用问题。一个节点挂了不能影响我的应用。
好，如果仅仅需要解决这5个问题，可能会有无数种方案，而且各有千秋，随便举一种方案，使用消息队列+分布在各个机器上的工作进程就ok啦。我们再继续往下看。
- 容易在上面开发应用程序。亲，你设计的系统需要应用程序开发人员考虑各个处理组件的分布、消息的传递吗？如果是，那有点麻烦啊，开发人员可能会用不好，也不会想去用。
- 消息不丢失。用户发布的一个宝贝消息不能在实时处理的时候给丢了，对吧？更严格一点，如果是一个精确数据统计的应用，那么它处理的消息要不多不少才行。这个要求有点高哦。
- 消息严格有序。有些消息之间是有强相关性的，比如同一个宝贝的更新和删除操作消息，如果处理时搞乱顺序完全是不一样的效果了。
不知道大家对这些问题是否都有了自己的答案，下面让我们带着这些问题，一起来看一看storm的解决方案吧。
- Storm是什么
如果只用一句话来描述storm的话，可能会是这样：分布式实时计算系统。按照storm作者的说法，storm对于实时计算的意义类似于hadoop对于批处理的意义。我们都知道，根据google mapreduce来实现的hadoop为我们提供了map, reduce原语，使我们的批处理程序变得非常地简单和优美。同样，storm也为实时计算提供了一些简单优美的原语。我们会在第三节中详细介绍。
我们来看一下storm的适用场景。
- 流数据处理。Storm可以用来处理源源不断流进来的消息，处理之后将结果写入到某个存储中去。
- 分布式rpc。由于storm的处理组件是分布式的，而且处理延迟极低，所以可以作为一个通用的分布式rpc框架来使用。当然，其实我们的搜索引擎本身也是一个分布式rpc系统。
说了半天，好像都是很玄乎的东西，下面我们开始具体讲解storm的基本概念和它内部的一些实现原理吧。
- Storm的基本概念
首先我们通过一个 storm 和hadoop的对比来了解storm中的基本概念。
| Hadoop | Storm | |
| 系统角色 | JobTracker | Nimbus |
| TaskTracker | Supervisor | |
| Child | Worker | |
| 应用名称 | Job | Topology |
| 组件接口 | Mapper/Reducer | Spout/Bolt |
表3-1
接下来我们再来具体看一下这些概念。
- Nimbus：负责资源分配和任务调度。
- Supervisor：负责接受nimbus分配的任务，启动和停止属于自己管理的worker进程。
- Worker：运行具体处理组件逻辑的进程。
- Task：worker中每一个spout/bolt的线程称为一个task. 在storm0.8之后，task不再与物理线程对应，同一个spout/bolt的task可能会共享一个物理线程，该线程称为executor。
- Topology：storm中运行的一个实时应用程序，因为各个组件间的消息流动形成逻辑上的一个拓扑结构。
- Spout：在一个topology中产生源数据流的组件。通常情况下spout会从外部数据源中读取数据，然后转换为topology内部的源数据。Spout是一个主动的角色，其接口中有个nextTuple()函数，storm框架会不停地调用此函数，用户只要在其中生成源数据即可。
- Bolt：在一个topology中接受数据然后执行处理的组件。Bolt可以执行过滤、函数操作、合并、写数据库等任何操作。Bolt是一个被动的角色，其接口中有个execute(Tuple input)函数,在接受到消息后会调用此函数，用户可以在其中执行自己想要的操作。
- Tuple：一次消息传递的基本单元。本来应该是一个key-value的map，但是由于各个组件间传递的tuple的字段名称已经事先定义好，所以tuple中只要按序填入各个value就行了，所以就是一个value list.
- Stream：源源不断传递的tuple就组成了stream。
10. stream grouping：即消息的partition方法。Storm中提供若干种实用的grouping方式，包括shuffle, fields hash, all, global, none, direct和localOrShuffle等
相比于s4, puma等其他实时计算系统，storm最大的亮点在于其记录级容错和能够保证消息精确处理的事务功能。下面就重点来看一下这两个亮点的实现原理。
- Storm记录级容错的基本原理
首先来看一下什么叫做记录级容错？storm允许用户在spout中发射一个新的源tuple时为其指定一个message id, 这个message id可以是任意的object对象。多个源tuple可以共用一个message id，表示这多个源 tuple对用户来说是同一个消息单元。storm中记录级容错的意思是说，storm会告知用户每一个消息单元是否在指定时间内被完全处理了。那什么叫做完全处理呢，就是该message id绑定的源tuple及由该源tuple后续生成的tuple经过了topology中每一个应该到达的bolt的处理。举个例子。在图4-1中，在spout由message 1绑定的tuple1和tuple2经过了bolt1和bolt2的处理生成两个新的tuple，并最终都流向了bolt3。当这个过程完成处理完时，称message 1被完全处理了。
在storm的topology中有一个系统级组件，叫做acker。这个acker的任务就是追踪从spout中流出来的每一个message id绑定的若干tuple的处理路径，如果在用户设置的最大超时时间内这些tuple没有被完全处理，那么acker就会告知spout该消息处理失败了，相反则会告知spout该消息处理成功了。在刚才的描述中，我们提到了”记录tuple的处理路径”，如果曾经尝试过这么做的同学可以仔细地思考一下这件事的复杂程度。但是storm中却是使用了一种非常巧妙的方法做到了。在说明这个方法之前，我们来复习一个数学定理。
A xor A = 0.
A xor B…xor B xor A = 0，其中每一个操作数出现且仅出现两次。
storm中使用的巧妙方法就是基于这个定理。具体过程是这样的：在spout中系统会为用户指定的message id生成一个对应的64位整数，作为一个root id。root id会传递给acker及后续的bolt作为该消息单元的唯一标识。同时无论是spout还是bolt每次新生成一个tuple的时候，都会赋予该tuple一个64位的整数的id。Spout发射完某个message id对应的源tuple之后，会告知acker自己发射的root id及生成的那些源tuple的id。而bolt呢，每次接受到一个输入tuple处理完之后，也会告知acker自己处理的输入tuple的id及新生成的那些tuple的id。Acker只需要对这些id做一个简单的异或运算，就能判断出该root id对应的消息单元是否处理完成了。下面通过一个图示来说明这个过程。
可能有些细心的同学会发现，容错过程存在一个可能出错的地方，那就是，如果生成的tuple id并不是完全各异的，acker可能会在消息单元完全处理完成之前就错误的计算为0。这个错误在理论上的确是存在的，但是在实际中其概率是极低极低的，完全可以忽略。
- Storm的事务拓扑
事务拓扑(transactional topology)是storm0.7引入的特性，在最近发布的0.8版本中已经被封装为Trident，提供了更加便利和直观的接口。因为篇幅所限，在此对事务拓扑做一个简单的介绍。
事务拓扑的目的是为了满足对消息处理有着极其严格要求的场景，例如实时计算某个用户的成交笔数，要求结果完全精确，不能多也不能少。Storm的事务拓扑是完全基于它底层的spout/bolt/acker原语实现的，通过一层巧妙的封装得出一个优雅的实现。个人觉得这也是storm最大的魅力之一。
事务拓扑简单来说就是将消息分为一个个的批(batch)，同一批内的消息以及批与批之间的消息可以并行处理，另一方面，用户可以设置某些bolt为committer，storm可以保证committer的finishBatch()操作是按严格不降序的顺序执行的。用户可以利用这个特性通过简单的编程技巧实现消息处理的精确。
- Storm在淘宝
由于storm的内核是clojure编写的(不过大部分的拓展工作都是java编写的)，为我们理解它的实现带来了一定的困难，好在大部分情况下storm都比较稳定，当然我们也在尽力熟悉clojure的世界。我们在使用storm时通常都是选择java语言开发应用程序。
在淘宝，storm被广泛用来进行实时日志处理，出现在实时统计、实时风控、实时推荐等场景中。一般来说，我们从类kafka的metaQ或者基于hbase的timetunnel中读取实时日志消息，经过一系列处理，最终将处理结果写入到一个分布式存储中，提供给应用程序访问。我们每天的实时消息量从几百万到几十亿不等，数据总量达到TB级。对于我们来说，storm往往会配合分布式存储服务一起使用。在我们正在进行的个性化搜索实时分析项目中，就使用了timetunnel + hbase + storm + ups的架构，每天处理几十亿的用户日志信息，从用户行为发生到完成分析延迟在秒级。
- Storm的未来
Storm0.7系列的版本已经在各大公司得到了广泛使用，最近发布的0.8版本中引入了State，使得其从一个纯计算框架演变成了一个包含存储和计算的实时计算新利器，还有刚才提到的Trident，提供更加友好的接口，同时可定制scheduler的特性也为其针对不同的应用场景做优化提供了更便利的手段，也有人已经在基于storm的实时ql(query language)上迈出了脚本。在服务化方面，storm一直在朝着融入mesos框架的方向努力。同时，storm也在实现细节上不断地优化，使用很多优秀的开源产品，包括kryo, Disruptor, curator等等。可以想象，当storm发展到1.0版本时，一定是一款无比杰出的产品，让我们拭目以待，当然，最好还是参与到其中去吧，同学们。
Storm基本概念
Storm是一个开源的实时计算系统，它提供了一系列的基本元素用于进行计算：Topology、Stream、Spout、Bolt等等。
在Storm中，一个实时应用的计算任务被打包作为Topology发布，这同Hadoop的MapReduce任务相似。但是有一点不同的是：在Hadoop中，MapReduce任务最终会执行完成后结束；而在Storm中，Topology任务一旦提交后永远不会结束，除非你显示去停止任务。
计算任务Topology是由不同的Spouts和Bolts，通过数据流（Stream）连接起来的图。下面是一个Topology的结构示意图：
其中包含有：
Spout：Storm中的消息源，用于为Topology生产消息（数据），一般是从外部数据源（如Message Queue、RDBMS、NoSQL、Realtime Log）不间断地读取数据并发送给Topology消息（tuple元组）。
Bolt：Storm中的消息处理者，用于为Topology进行消息的处理，Bolt可以执行过滤， 聚合， 查询数据库等操作，而且可以一级一级的进行处理。
最终，Topology会被提交到storm集群中运行；也可以通过命令停止Topology的运行，将Topology占用的计算资源归还给Storm集群。
Storm数据流模型
数据流（Stream）是Storm中对数据进行的抽象，它是时间上无界的tuple元组序列。在Topology中，Spout是Stream的源头，负责为Topology从特定数据源发射Stream；Bolt可以接收任意多个Stream作为输入，然后进行数据的加工处理过程，如果需要，Bolt还可以发射出新的Stream给下级Bolt进行处理。
下面是一个Topology内部Spout和Bolt之间的数据流关系：
Topology中每一个计算组件（Spout和Bolt）都有一个并行执行度，在创建Topology时可以进行指定，Storm会在集群内分配对应并行度个数的线程来同时执行这一组件。
那么，有一个问题：既然对于一个Spout或Bolt，都会有多个task线程来运行，那么如何在两个组件（Spout和Bolt）之间发送tuple元组呢？
Storm提供了若干种数据流分发（Stream Grouping）策略用来解决这一问题。在Topology定义时，需要为每个Bolt指定接收什么样的Stream作为其输入（注：Spout并不需要接收Stream，只会发射Stream）。
目前Storm中提供了以下7种Stream Grouping策略：Shuffle Grouping、Fields Grouping、All Grouping、Global Grouping、Non Grouping、Direct Grouping、Local or shuffle grouping，具体策略可以参考这里。
一种Storm不能支持的场景
以上介绍了一些Storm中的基本概念，可以看出，Storm中Stream的概念是Topology内唯一的，只能在Topology内按照“发布-订阅”方式在不同的计算组件（Spout和Bolt）之间进行数据的流动，而Stream在Topology之间是无法流动的。
这一点限制了Storm在一些场景下的应用，下面通过一个简单的实例来说明。
假设现在有一个Topology1的结构如下：通过Spout产生数据流后，依次需要经过Filter Bolt，Join Bolt，Business1 Bolt。其中，Filter Bolt用于对数据进行过滤，Join Bolt用于数据流的聚合，Business1 Bolt用于进行一个实际业务的计算逻辑。
目前这个Topology1已经被提交到Storm集群运行，而现在我们又有了新的需求，需要计算一个新的业务逻辑，而这个Topology的特点是和Topology1公用同样的数据源，而且前期的预处理过程完全一样（依次经历Filter Bolt和Join Bolt），那么这时候Storm怎么来满足这一需求？据个人了解，有以下几种“曲折”的实现方式：
1） 第一种方式：首先kill掉已经在集群中运行的Topology1计算任务，然后实现Business2 Bolt的计算逻辑，并重新打包形成一个新的Topology计算任务jar包后，提交到Storm集群中重新运行，这时候Storm内的整体Topology结构如下：
这种方式的缺点在于：由于要重启Topology，所以如果Spout或Bolt有状态则会丢失掉；同时由于Topology结构发生了变化，因此重新运行Topology前需要对程序的稳定性、正确性进行验证；另外Topology结构的变化也会带来额外的运维开销。
2） 第二种方式：完全开发部署一套新的Topology，其中前面的公共部分的Spout和Bolt可以直接复用，只需要重新开发新的计算逻辑Business2 Bolt来替换原有的Business1 Bolt即可。然后重新提交新的Topology运行。这时候Storm内的整体Topology结构如下：
这种方式的缺点在于：由于两个Topology都会从External Data Source读取同一份数据，无疑增加了External Data Source的负载压力；而且会导致同样的数据在Storm集群内被传输相同的两份，被同样的计算单元Bolt进行处理，浪费了Storm的计算资源和网络传输带宽。假设现在不止有两个这样的Topology计算任务，而是有N个，那么对Storm的计算Slot的浪费很严重。
注意：上述两种方式还有一个公共的缺点——系统可扩展性不好，这意味着不管哪种方式，只要以后有这种新增业务逻辑的需求，都需要进行复杂的人工操作或线性的资源浪费现象。
3） 第三种方式：OK，看了以上两种方式后，也许你会提出下面的解决方案：通过Kafka这样的消息中间件，实现不同Topology的Spout共享数据源，而且这样可以做到消息可靠传输、消息rewind回传等，好处是对于Storm来说，已经有了storm-kafka插件的支持。这时候Storm内的整体Topology结构如下：
这种实现方式可以通过引入一层消息中间件减少对External Data Source的重复访问的压力，而且可以通过消息中间件层，屏蔽掉External Data Source的细节，如果需要扩展新的业务逻辑，只需要重新部署运行新的Topology，应该说是现有Storm版本下很好的实现方式了。不过消息中间件的引入，无疑将给系统带来了一定的复杂性，这对于Storm上的应用开发来说提高了门槛。
值得注意的是，方案三中仍遗留有一点问题没有解决：对于Storm集群来说，这种方式还是没有能够从根本上避免数据在Storm不同Topology内的重复发送与处理。这是由于Storm的数据流模型上的限制所导致的，如果Storm实现了不同Topology之间Stream的共享，那么这一问题也就迎刃而解了。
一个流处理系统的数据流模型
个人工作中有幸参与过一个流处理框架的开发与应用。下面我们来简单看看其中所采用的数据流模型：
其中：
1）数据流（data stream）：时间分布和数量上无限的一系列数据记录的集合体；
2）数据记录（data record）：数据流的最小组成单元，每条数据记录包括 3 类数据：所属数据流名称（stream name）、用于路由的数据（keys）和具体数据处理逻辑所需的数据（value）；
3）数据处理任务定义（task definition）：定义一个数据处理任务的基本属性，无法直接被执行，必须特化为具体的任务实例。其基本属性包括：
- （可选）输入流（input stream）：描述该任务依赖哪些数据流作为输入，是一个数据流名称列表；数据流产生源不会依赖其他数据流，可忽略该配置；
- 数据处理逻辑（process logic）：描述该任务具体的处理逻辑，例如由独立进程进行的外部处理逻辑；
- （可选）输出流（output stream）：描述该任务产生哪个数据流，是一个数据流名称；数据流处理链末级任务不会产生新的数据流，可忽略该配置；
4）数据处理任务实例（task instance）：对一个数据处理任务定义进行具体约束后，可推送到某个处理结点上运行的逻辑实体。附加下列属性：
- 数据处理任务定义：指向该任务实例对应的数据处理任务定义实体；
- 输入流过滤条件（input filting condition）：一个 boolean 表达式列表，描述每个输入流中符合什么条件的数据记录可以作为有效数据交给处理逻辑；若某个输入流中所有数据记录都是有效数据，则可直接用 true 表示；
- （可选）强制输出周期（output interval）：描述以什么频率强制该任务实例产生输出流记录，可以用输入流记录个数或间隔时间作为周期；忽略该配置时，输出流记录产生周期完全由处理逻辑自身决定，不受框架约束；
5）数据处理结点（node）：可容纳多个数据处理任务实例运行的实体机器，每个数据处理结点的IPv4地址必须保证唯一。
该分布式流处理系统由多个数据处理结点（node）组成；每个数据处理结点（node）上运行有多个数据任务实例（task instance）；每个数据任务实例（task instance）属于一个数据任务定义（task definition），任务实例是在任务定义的基础上，添加了输入流过滤条件和强制输出周期属性后，可实际推送到数据处理结点（node）上运行的逻辑实体；数据任务定义（task definition）包含输入数据流、数据处理逻辑以及输出数据流属性。
该系统中，通过分布式应用程序协调服务ZooKeeper集群存储以上数据流模型中的所有配置信息；不同的数据处理节点统一通过ZooKeeper集群获取数据流的配置信息后进行任务实例的运行与停止、数据流的流入和流出。
同时，每个数据处理任务可以接受流系统中已存在的任意数据流（data stream）作为输入，并产出新的任意名称的数据流（data stream），被其他结点上运行的任务实例订阅。不同结点之间对于各个数据流（data stream）的订阅关系，通过ZooKeeper集群来动态感知并负责通知流系统做出变化。
二者在数据流模型上的不同之处
至于两个系统的实现细节，我们先不去做具体比较，下面仅列出二者在数据流模型上的一些不同之处（这里并不是为了全面对比二者的不同之处，只是列出其中的关键部分）：
1） 在Storm中，数据流Stream是在Topology内进行定义，并在Topology内进行传输的；而在上面提到的流处理系统中，数据流Stream是在整个系统内全局唯一的，可以在整个集群内被订阅。
2） 在Storm中，数据流Stream的发布和订阅都是静态的，所谓静态是指数据流的发布与订阅关系在向Storm集群提交Topology计算任务时，被一次性生成的，这一关系在Topology的运行过程中是不能被改变的；而在上面提到的流处理系统中，数据流Stream的发布和订阅都是动态的，即数据处理任务task可以动态的发布Stream，也可以动态的订阅系统内已经生成的任意Stream，数据流的订阅关于通过分布式应用程序协调服务ZooKeeper集群的动态节点来维护管理。
有了以上的对比，我们不难发现，对于本文所举的应用场景实例，Storm的数据流模式尚不能很方便的支持，而在这里提到的这个流处理系统的全局数据流模型下，这一应用场景的需求可以很方便的满足。
利用flume+kafka+storm+mysql构建大数据实时系统
架构图
数据流向图
1.Flume 的一些核心概念：
2.数据流模型
Flume以agent为最小的独立运行单位。一个agent就是一个JVM。单agent由Source、Sink和Channel三大组件构成，如下图：
Flume的数据流由事件(Event)贯穿始终。事件是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有头信息，这些Event由Agent外部的Source，比如上图中的Web Server生成。当Source捕获事件后会进行特定的格式化，然后Source会把事件推入(单个或多个)Channel中。你可以把Channel看作是一个缓冲区，它将保存事件直到Sink处理完该事件。Sink负责持久化日志或者把事件推向另一个Source。
很直白的设计，其中值得注意的是，Flume提供了大量内置的Source、Channel和Sink类型。不同类型的Source,Channel和Sink可以自由组合。组合方式基于用户设置的配置文件，非常灵活。比如：Channel可以把事件暂存在内存里，也可以持久化到本地硬盘上。Sink可以把日志写入HDFS, HBase，甚至是另外一个Source等等。
如果你以为Flume就这些能耐那就大错特错了。Flume支持用户建立多级流，也就是说，多个agent可以协同工作，并且支持Fan-in、Fan-out、Contextual Routing、Backup Routes。如下图所示：
3.高可靠性
作为生产环境运行的软件，高可靠性是必须的。从单agent来看，Flume使用基于事务的数据传递方式来保证事件传递的可靠性。Source和Sink被封装进一个事务。事件被存放在Channel中直到该事件被处理，Channel中的事件才会被移除。这是Flume提供的点到点的可靠机制。从多级流来看，前一个agent的sink和后一个agent的source同样有它们的事务来保障数据的可靠性
4.可恢复性
还是靠Channel。推荐使用FileChannel，事件持久化在本地文件系统里(性能较差)。
5.Flume 整体架构介绍
Flume架构整体上看就是 source-->channel-->sink 的三层架构（参见最上面的 图一），类似生成者和消费者的架构，他们之间通过queue（channel）传输，解耦。
Source:完成对日志数据的收集，分成 transtion 和 event 打入到channel之中。
Channel:主要提供一个队列的功能，对source提供中的数据进行简单的缓存。
Sink:取出Channel中的数据，进行相应的存储文件系统，数据库，或者提交到远程服务器。
对现有程序改动最小的使用方式是使用是直接读取程序原来记录的日志文件，基本可以实现无缝接入，不需要对现有程序进行任何改动。
对于直接读取文件Source, 主要有两种方式：
2.1 Exec source
可通过写Unix command的方式组织数据，最常用的就是tail -F [file]。
可以实现实时传输，但在flume不运行和脚本错误时，会丢数据，也不支持断点续传功能。因为没有记录上次文件读到的位置，从而没办法知道，下次再读时，从什么地方开始读。特别是在日志文件一直在增加的时候。flume的source挂了。等flume的source再次开启的这段时间内，增加的日志内容，就没办法被source读取到了。不过flume有一个execStream的扩展，可以自己写一个监控日志增加情况，把增加的日志，通过自己写的工具把增加的内容，传送给flume的node。再传送给sink的node。要是能在tail类的source中能支持，在node挂掉这段时间的内容，等下次node开启后在继续传送，那就更完美了。
2.2 Spooling Directory Source
SpoolSource:是监测配置的目录下新增的文件，并将文件中的数据读取出来，可实现准实时。需要注意两点：1、拷贝到spool目录下的文件不可以再打开编辑。2、spool目录下不可包含相应的子目录。在实际使用的过程中，可以结合log4j使用，使用log4j的时候，将log4j的文件分割机制设为1分钟一次，将文件拷贝到spool的监控目录。log4j有一个TimeRolling的插件，可以把log4j分割的文件到spool目录。基本实现了实时的监控。Flume在传完文件之后，将会修改文件的后缀，变为.COMPLETED（后缀也可以在配置文件中灵活指定）
ExecSource，SpoolSource对比：ExecSource可以实现对日志的实时收集，但是存在Flume不运行或者指令执行出错时，将无法收集到日志数据，无法何证日志数据的完整性。SpoolSource虽然无法实现实时的收集数据，但是可以使用以分钟的方式分割文件，趋近于实时。如果应用无法实现以分钟切割日志文件的话，可以两种收集方式结合使用。
Channel有多种方式：有MemoryChannel, JDBC Channel, MemoryRecoverChannel, FileChannel。MemoryChannel可以实现高速的吞吐，但是无法保证数据的完整性。MemoryRecoverChannel在官方文档的建议上已经建义使用FileChannel来替换。FileChannel保证数据的完整性与一致性。在具体配置FileChannel时，建议FileChannel设置的目录和程序日志文件保存的目录设成不同的磁盘，以便提高效率。
Sink在设置存储数据时，可以向文件系统中，数据库中，hadoop中储数据，在日志数据较少时，可以将数据存储在文件系中，并且设定一定的时间间隔保存数据。在日志数据较多时，可以将相应的日志数据存储到Hadoop中，便于日后进行相应的数据分析。
