作者：(美)霍夫曼(Hoffman,S.),(美)佩雷拉(Perera,S.)
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Flume日志收集与MapReduce模式试读：
前言
Hadoop是个非常优秀的开源工具，可以将海量的非结构化数据转换为易于管理的内容，从而更好地洞察客户需求。它很便宜（几乎是免费的），只要数据中心有空间和电源，它就能够水平扩展，并且可以处理传统数据仓库难以解决的问题。需要注意的是，你得将数据填入Hadoop集群中，否则你所得到的只不过是昂贵的热量产生器而已。你很快就会发现，一旦对Hadoop的使用经过“试验性”阶段后，你就需要工具来自动化地将数据填充到集群中。过去，你需要自己找到该问题的解决方案，但现在则不必如此！Flume一开始是Cloudera的项目，当时它们的集成工程师需要一次又一次地为客户编写工具来实现数据的自动化导入。时至今日，Flume已经成为Apache软件基金会的项目，并且处于活跃开发状态中，很多用户已经将其用于产品环境多年。
本书将会通过Flume的架构概览与快速起步指南帮助你迅速掌握Flume。接下来将会深入介绍Flume众多更加有用的组件的细节信息，包括用于即时数据记录持久化的重要的文件通道、用于缓存并将数据写到HDFS中的HDFS接收器，以及Hadoop分布式文件系统。由于Flume内置很多模块，因此上手Flume时你所需要的唯一工具就是一个用于编写配置文件的文本编辑器而已。
通过阅读上篇，你将掌握构建高可用、容错、流式数据管道（用于填充Hadoop集群）所需的一切知识。
虽然网上关于Hadoop的资料已经汗牛充栋，但大多数都止步于表面或是仅针对某个具体问题给出解决方案。下篇则对Hadoop以及MapReduce编程进行了简明介绍，旨在让你快速起步并对Hadoop编程有个总体印象，打好基础才能深入探索每一类MapReduce问题。
本书主要内容
第1章介绍了Flume及其将会解决的问题空间（特别是与Hadoop相关的部分），架构概览介绍了将会在后续章节中讨论的各个组件。
第2章帮助你尽快上手Flume，包括下载Flume、创建“Hello World”配置并运行。
第3章介绍了大多数人都会用到的两个主要通道以及每个通道可用的配置选项。
第4章详细介绍了如何使用HDFS Flume输出，包括压缩选项以及数据格式化选项。此外还介绍了故障恢复选项以创建更为健壮的数据管道。
第5章介绍了几种Flume输入机制及其配置选项。此外，还介绍了如何根据数据内容在不同的通道间切换，这样就可以创建复杂的数据流了。
第6章介绍了如何即时转换数据以及如何从负载中抽取信息来与通道选择器搭配以进行路由判定。还介绍了如何通过Avro序列化对Flume代理进行分层，如何将Flume命令行作为独立的Avro客户端进行测试以及手工导入数据。
第7章介绍了内外部用于监控Flume的各种方式，包括Monit、Nagios、Ganglia以及自定义钩子。
第8章超越了Flume配置与使用本身，对实时分布式数据收集的各个方面进行了讨论。
第9章介绍了如何使用Java（不使用MapReduce）编写一个单词统计应用。我们会将其与MapReduce模型进行比对。
第10章介绍了如何使用MapReduce编写单词统计应用以及如何使用Hadoop本地模式运行。
第11章介绍了如何在分布式环境中安装Hadoop并运行之前的Wordcount job。
第12章介绍了如何编写一个Hadoop数据格式化器来读取Amazon数据格式以作为记录而非逐行读取数据。
第13章介绍了如何通过MapReduce处理Amazon数据，生成直方图数据以及使用gnuplot来绘制结果。
第14章介绍了如何通过MapReduce连接两个数据集。
第15章介绍了如何处理Amazon数据以及通过MapReduce实现差集。此外还介绍了如何通过类似的方法实现其他的集合操作。
第16章介绍了如何通过MapReduce统计两个条目同时出现的次数（交叉相关）。
第17章介绍了如何处理Amazon数据以及通过反向索引实现简单的搜索。
第18章介绍了如何通过MapReduce实现图的遍历。
第19章介绍了如何通过Kmeans算法建立数据集的集群。集群会将数据划分为各个小组，这样每个分组中的条目都是类似的，根据不同的距离度量方法，不同分组中的条目是不同的。
学习本书的前提
你需要一台安装有Java虚拟机的Linux或Mac电脑，并安装有JDK1.6，因为Flume是用Java编写的。如果电脑上没有安装Java，那么可以从http://java.com/下载。
还需要网络连接，这样才能下载Flume并运行快速入门示例。
上篇主要讲解了Apache Flume1.3.0，此外还对Cloudera的Flume CDH4进行了介绍。
本书面向的读者
本书面向需要将来自各种系统的数据自动化地移动到Hadoop集群中的人。如果需要定期将数据加载到Hadoop中，那么本书就是为你准备的，它将使你从手工工作中解脱出来，也无需再继续维护一些自己编写的工具。
阅读本书只需要对基本的Hadoop HDFS知识有一定了解。我们提供了一些自定义的实现，如果需要可以使用。对于这种级别的实现，你需要了解如何使用Java进行编程。
最后，你需要使用一款自己喜欢的文本编辑器，因为本书的大部分内容都涉及如何通过代理的文本配置文件来配置各种Flume组件。上篇Flume日志收集
·第1章 概览与架构
·第2章 Flume快速起步
·第3章 通道
·第4章 接收器与接收处理器
·第5章 源与通道选择器
·第6章 拦截器、ETL与路由
·第7章 监控Flume
·第8章 万法皆空——实时分布式数据收集的现状第1章概览与架构
如果在阅读本书，那就说明你正在数据的海洋中遨游。创建大量的数据是非常简单的事情，这要归功于Facebook、Twitter、Amazon、数码相机与相机照片、YouTube、Google，以及你能想得到的能够连接到互联网上的任何东西。作为网站的提供者，10年前的应用日志只是用来帮助你解决网站的问题。时至今日，如果你知道如何从大量的数据中浪里淘金，那么相同的数据就会提供关于业务与客户的有价值的信息。
此外，既然在阅读本书，那么你肯定知道创建Hadoop的目的在一定程度上就是为了解决大量数据的筛选问题。当然了，只有可靠地加载Hadoop集群数据并供数据科学家从中选择，这一切才能达成所愿。
将数据存储到Hadoop以及从Hadoop中获取数据（即Hadoop文件系统，HDFS）并不是什么难事——只需要如下一条命令即可：
将数据打包好并准备上传时，使用上面这条命令就可以轻松将数据存储到Hadoop文件系统中。
不过，网站一直在创建着数据，批量将数据加载到HDFS中的频率是多少呢？每天？每小时？无论选择何种处理周期，最终还是会有人问“能否尽快给我数据呢”？你真正需要的是能够处理流式日志/数据的解决方案。
并不是只有你才有这种需求。Cloudera（专业的Hadoop服务提供商，拥有自己的Hadoop分发版本）在与客户的协作过程中不断发现了这种需求。创建Flume的目的就在于满足这种需求，它创建了一个标准、简单、健壮、灵活且可扩展的工具，用于将数据存储到Hadoop中。1.1 Flume 0.9
Flume是在2011年被首次引入到Cloudera的CDH3分发中的。它由一套工作守护进程（代理）构成，这些守护进程是通过Zookeeper（一个配置与协调系统）根据一个或多个集中的Master配置而成的。在Master上，你可以在Web UI中查看代理状态，也可以以集中的方式在UI或是通过命令行Shell的方式取出配置（这两种方式都是通过Zookeeper与工作代理进行通信的）。
可以通过3种模式发送数据，分别叫作Best Effort（BE）、Disk Failover（DFO）以及End-to-End（E2E）。Masters用于E2E模式，而多个Master配置尚不成熟，因此通常情况下只会使用一个Master，这使得其成为了E2E数据流失败的主要原因。Best Effort见名知意，代理会尝试并发送数据，如果无法发送，那么数据就会被丢弃。这种模式非常适合于度量等场景，一些差异是可以被接受的，因为新数据很快就会到来。DiskFailover模式会将无法发送的数据存储到本地磁盘上（有时也存储到本地数据库中），并且会不断重试，直到可以将数据发送到数据流中的下一个接受者为止。这对于计划好（或计划外）的断电场景很方便，只要有足够的本地磁盘能够缓存负载即可。
2011年6月，Cloudera将Flume项目的控制权交给了Apache基金会。2012年，Flume项目就从孵化状态变成了顶级项目。在孵化的这一年中，开发人员就已经开始基于Star Trek Themed标签对Flume进行重构，并创建了Flume-NG（Flume the Next Generation）。1.2 Flume 1.X（Flume-NG）
Flume之所以会重构有很多原因，如果对细节感兴趣可以参考https://issues.apache.org/jira/browse/FLUME-728。一开始的重构分支最后变成了Flume 1.X的开发主线。
Flume 1.X最为明显的变化是不再使用中心化的配置Master/Masters与Zookeeper。Flume 0.9的配置有些过度烦琐，并且极易出错。此外，中心化的配置已经超出了Flume的目标范围。取代中心化配置的是一个简单的磁盘上的配置文件（不过配置文件是可插拔的，因此可以替换）。这些配置文件很容易通过诸如cf-engine、chef及puppet等工具分发。如果使用的是Cloudera分发包，那么可以通过Cloudera管理器来管理配置——最近其许可发生了变化，增加了节点限制，因此增加了吸引力。请确保不要手工管理这些配置，否则就要一直采用手工方式编辑这些文件了。
Flume 1.X的另一个主要差别是输入数据的读取与输出数据的写入现在由不同的工作线程（称为运行器）来处理了。在Flume 0.9中，输入线程也执行对输出的写入（故障恢复重试除外）。如果输出写入器很慢（而不仅仅是完全失败），那么它会阻塞Flume接收数据的能力。这种新的异步设计使得输入线程完全意识不到任何下游的问题。
本书介绍的Flume版本是1.3.1（也是本书撰写之际Flume的当前版本）。1.3 HDFS与流式数据/日志的问题
HDFS并不是真正的文件系统，至少从传统的认识来说不是这样，对于通常的文件系统来说，很多我们认为理所当然的东西并不适合于HDFS，比如挂载。这使得将流式数据装载进Hadoop中变得有些复杂。
在通常的Portable Operating System Interface（POSIX）风格的文件系统中，如果打开文件并写入数据，那么在文件关闭前它会一直存在于磁盘上。也就是说，如果另一个程序打开了相同的文件并开始读取，那么它会读取到写入器写到磁盘上的数据。此外，如果该写入进程中断，那么写到磁盘上的任何部分都是可用的（有可能不完整，但确实是存在的）。
在HDFS中，文件只作为目录项存在，在文件关闭前，其长度一直显示为0。这意味着如果在一段时间内将数据写到文件中但却没有将其关闭，那么一旦客户端出现网络中断，你就什么都得不到了，只有一个空白文件而已。你会得出这样一个结论，即最好编写小文件，这样就能尽快将其关闭了。
问题在于Hadoop并不喜欢过多的小文件。由于HDFS元数据保存在NameNode的内存中，因此创建的文件越多，所需的RAM就越多。从MapReduce的角度来看，小文件会导致效率低下。通常情况下，每个Mapper都会被分配单个文件块作为输入（除非使用了某些压缩编码）。如果有过多的小文件，那么与待处理的数据相比，启动工作进程的代价就过高了。这种碎片还会导致更多的Mapper任务，使得总的Job运行时间增加。
在决定写入到HDFS的周期时需要考虑这些因素。如果计划保留数据较短的时间，那么可以使用较小的文件。然而，如果计划保留数据较长的时间，那么可以使用较大的文件或是做一些周期性的清理工作，将小文件压缩为少量的大文件，使得它们更加适合于MapReduce。毕竟，你只是写入一次数据，但却要在这些数据上运行MapReduce任务成百上千次。1.4 源、通道与接收器
Flume代理的架构可以通过下面这张简单的图呈现出来。输入叫作源，输出叫作接收器。通道提供了源与接收器之间的胶水。它们都运行在叫作代理的守护进程中。请记住如下概念：
源将事件写到一个或多个通道中。
通道作为事件从源到接收器传递的保留区。
接收器只从一个通道接收事件。
代理可能会有多个源、通道与接收器。1.5 Flume事件
Flume传输的基本的数据负载叫作事件。事件由0个或多个头与体组成。
头是一些键值对，可用于路由判定或是承载其他的结构化信息（比如说事件的时间戳或是发出事件的服务器主机名）。你可以将其看作是与HTTP头完成相同的功能——传递与体不同的额外信息的方式。
体是个字节数组，包含了实际的负载。如果输入由日志文件组成，那么该数组就非常类似于包含了单行文本的UTF-8编码的字符串。
Flume可能会自动添加头（比如，源添加了数据来自的主机名或是创建了事件时间戳），不过体基本上是不受影响的，除非你在中途使用拦截器对其进行了编辑。1.5.1 拦截器、通道选择器与选择处理器
拦截器指的是数据流中的一个点，你可以在这里检查和修改Flume事件。你可以在源创建事件后或是接收器发送事件前链接0个或多个拦截器。如果熟悉AOP Spring框架，那么它非常类似于MethodInterceptor。在Java Servlets中，它类似于ServletFilter。在一个源上链接了4个拦截器，如下图所示。
通道选择器负责将数据从一个源转向一个或多个通道上。Flume自带了两个通道选择器，这涵盖了你可能会遇到的大多数场景。不过如果需要你也可以编写自己的选择器。复制通道选择器（默认的）只是将事件的副本放到每个通道中，前提是你已经配置好了多个通道。相反，多路通道选择器会根据某些头信息将事件写到不同的通道中。搭配上拦截器逻辑，这两种选择器构成了将输入路由到不同通道的基础。
最后，输入处理器指的是这样一种机制，你可以通过它为输入器创建故障恢复路径，或是跨越一个通道的多个输入器创建负载均衡事件。1.5.2 分层数据收集（多数据流与代理）
你可以根据特定的需求链接Flume代理。比如，你可以以分层的方式插入代理来限制想要直接连接到Hadoop的客户端数量。很多时候，源机器没有足够的磁盘空间来处理长期停机或是维护窗口，这样就可以在源与Hadoop集群之间创建一个拥有大量磁盘空间的层次。
从下图中可以看到，数据在两个地方被创建（位于左侧），并且有两个最终目的地（位于右侧的HDFS与ElasticSearch云气泡）。下面增加点儿趣味性，假设有一台机器生成了两种数据（我们将其称作正方形数据与三角形数据）。我们在左下角的代理中使用了多路通道选择器将这两种数据划分到了不同的通道中。接下来，矩形通道被路由到了右上角的代理（以及来自于左上角的数据）。合并后的总数据被一同写到了数据中心1的HDFS中。与此同时，三角形数据被发送到了代理，该代理将其写到数据中心2的ElasticSearch中。请记住，数据转换可能发生在任何源之后以及任何接收器之前。随后将会介绍如何通过这些组件构建复杂的数据流。1.6 小结
本章介绍了Flume尝试解决的问题，如何以一种易于配置且可靠的方式将数据加载进Hadoop集群中以进行数据处理。本章还介绍了Flume代理及其逻辑组件，包括事件、源、通道选择器、通道、接收处理器和接收器。
下一章将会更加详细地介绍这些主题，特别是每个组件最为常用的实现。就像其他优秀的开源项目一样，几乎所有这些组件都是可扩展的，如果它们无法满足你的需求，那么你可以自行对其进行扩展。第2章Flume快速起步
上一章已经介绍了关于Flume的一些基础知识，本章将会帮助你上手Flume。首先从第一步开始，即下载和配置Flume。2.1 下载Flume
请从http://flume.apache.org/下载Flume。在侧边导航栏找到下载链接，你会看到有两个压缩的tar归档，此外还有校验和与gpg签名文件，它们用于验证归档文件。网站上已经提供了验证下载文件的说明，因此这里就不再赘述了。针对实际的校验和检查校验和文件，以此验证下载的文件没有损坏。检查签名文件来验证下载的所有文件（包括校验和与签名）都来自于Apache而不是其他地方。你真的需要验证下载的文件么？一般来说，这是个好做法，也是Apache推荐的方式。如果不验证，那我也没什么好说的。
二进制分发包中有个bin目录，源文件则位于src目录中。源文件只包含了Flume源代码。二进制分发包体积要更大一些，这是因为它不仅包含了Flume源代码与编译后的Flume组件（JARs、javadocs等），还包含了所有Flume依赖的Java库。二进制包包含了与源文件相同的Maven POM文件，因此如果从二进制分发包开始，那么你可以重新编译源代码。
继续，下载（并验证）二进制分发包，这样可以在起步时节省一些时间。
Hadoop分发包中的Flume
某些Hadoop分发包中自带了Flume。这些分发包可能提供了Hadoop核心组件包与相关项目（比如Flume），他们会考虑诸如版本兼容性与额外的Bug修复等问题。这些分发包没什么好坏之分，只是有些不同而已。
使用分发包有一些好处。因为之前已经有人将所有版本兼容的组件放到了一起。现在，这已经不是什么问题了，因为Apache Bigtop项目（http://bigtop.apache.org/）已经开始了。不过，预先构建好的标准OS包（如RPMs和DEBs等）省却了安装以及提供启动/关闭脚本的麻烦。每个分发包都提供了不同程度的付费选项，如果遇到了无法解决的问题，那么你可以购买付费的专业服务。
当然了，缺点还是有的。分发包自带的Flume版本常常落后于Apache发布的版本。如果有你想要使用的新特性，那要么等待分发包提供者进行移植，要么自己打补丁。此外，虽然分发包提供者做了大量的测试（就像任何通用平台一样），但你还是有可能会遇到测试没有覆盖的问题。在这种情况下，你就得采取一些变通方式或是深入研究源代码了，还可以将补丁提交到开源社区（这样分发包就会在未来进行更新或是在下一个版本中将补丁纳入进来）。
因此，在Hadoop分发包中，Flume版本会有些老。这种事情的好坏就见仁见智了。通常情况下，大公司不喜欢不稳定的新技术，也不喜欢频繁变化，因为变化可能是导致意外的最常见的原因。你很难找到使用最新Linux内核的公司，大部分使用的还是Red Hat Enterprise Linux（RHEL）、CentOS、Ubuntu LTS等旨在提供稳定性与兼容性的分发包。如果你是一家初创公司，构建下一代的互联网时尚圈，那么你可能需要这些新技术以在竞争中处于上风。
如果考虑使用分发包，那么请搜索一下，看看每一种分发包都提供了什么。记住，每一个分发包其实都希望你最后需要它们的企业服务，而这种服务并不便宜。自己好好想想吧。下面是一个简短且不权威的列表，列出了现有的一些厂商，你可以了解一下：
·Cloudera：http://cloudera.com/
·Hortonworks：http://hortonworks.com/
·MapR：http://mapr.com/2.2 Flume配置文件概览
既然已经下载好了Flume，下面来花点时间看看如何配置代理。
Flume代理的默认配置提供者使用了一个简单的键值对的Java属性文件，你需要在启动时向代理传递一个参数。由于可以在单个文件中配置多个代理，因此还需要额外传递一个代理标识符（叫作名字），这样它就知道该使用哪个代理了。在给出的示例中，我只指定了一个代理，使用agent这个名字。
每个代理的配置都以下面这3个参数开始：
每个源、通道与接收器在该代理的上下文中也有一个唯一的名字。比如，如果不打算传递Apache访问日志，我就可以定义一个名为access的通道。该通道的配置都以前缀agent.channels.access开头。每个配置项都有一个type属性，告诉Flume是哪种源、通道还是接收器。在该示例中，我们使用一个内存通道，其类型为memory。名为agent的代理中的名为access的通道的完整配置如下所示：
为源、通道与接收器指定的任何参数都会使用相同的前缀以额外属性的方式添加进来。memory通道有一个capacity参数，标识它能持有的最大的Flume事件数量。假如我们不想使用100这个默认值，那么配置文件将会如下所示：
最后，我们需要将access通道名添加到agent.channels属性中，这样代理就会加载它了：
下面来看看使用标准“Hello World”的完整示例。2.3 从“Hello World”开始
每一本技术图书都会有一个“Hello World”示例。下面是我们将会使用的配置文件：
这里定义了一个名为agent的代理，它有一个名为s1的源、一个名为c1的通道，以及一个名为k1的接收器。
源s1的类型为netcat，它只是打开一个Socket监听事件（每个事件一行文本）。它需要两个参数，分别是一个绑定IP与一个端口号。该示例使用0.0.0.0作为绑定地址（表示监听任何地址的Java约定）以及端口号12345。源配置还有一个名为channels的参数，它是源将事件附加到的通道名。在该示例中使用的是c1。这里使用了复数，因为你可以配置将一个源写到多个通道中，不过在这个简单的示例中我们并没有这么做。
名为c1的通道是个内存通道，使用了默认配置。
名为k1的接收器的类型是logger。该接收器主要用于调试与测试。它会使用log4j将所有INFO级别的日志记录下来，这些日志来自于配置好的通道，在该示例中就是c1。这里所用的通道是单数的，因为一个接收器只能从一个通道接收数据。
使用该配置，我们运行代理并使用Linux netcat工具连接到代理来发送事件。
首先，解压缩之前下载的二进制分发包：
接下来，简单看看help命令。使用help命令运行flume-ng命令：注意，如果指定了
如你所见，可以通过两种方式调用命令（除了烦琐的help与version命令外）。我们将使用agent命令，avro-client的使用将在后面进行介绍。
agent命令有两个必填参数，分别是使用的配置文件与代理名（如果配置包含了多个代理）。下面来看看我们的示例配置，打开一个编辑器（我使用的是vi，你可以使用自己喜欢的任何编辑器）：
接下来，将vi配置的内容放到编辑器中，保存并退回到shell。
现在可以启动代理了：
-Dflume.root.logger属性覆盖了conf/log4j.properties中的root logger，使用console追加器。如果没有覆盖root logger，那么一切也都正常，只不过输出将会被写到log/flume.log文件中。当然了，你还可以编辑conf/log4j.properties文件，修改flume.root.logger属性（或是其他想要修改的任何属性）。
你可能会问，既然-f参数包含了配置的完整相对路径，那为何还要指定-c参数呢。原因在于log4j配置文件需要放到classpath中。如果命令没有指定-c参数，那就会报如下错误：
不过你并没有这么做，因此会看到如下关键的日志输出：
这行日志告诉你名为agent的代理已经启动了。通常情况下，如果在配置文件中有多个配置，你只需要这一行日志就可以断定启动了正确的配置。
下面是另一个检查，确保加载了正确的文件，在该示例中就是hw.conf文件：
当所有的配置都被解析完毕后，你会看到下面这条消息，它展示了配置好的一切内容。你会看到s1、c1、k1，以及哪些Java类完成了实际的工作。你可能会猜想，netcat其实是org.apache.flume.source.NetcatSource的便捷方式。如果需要，我们也可以使用类名。事实上，如果编写了自定义的源，那么我会使用其类名来作为源的type参数。如果不对Flume分发包打补丁，就无法定义自己的短名字：
我们看到源现在正在监听端口12345的输入，接下来向其发送一些数据。
最后，再打开一个终端。我们使用nc命令（也可以使用telnet或是其他类似的命令）发送字符串“Hello World”并敲入
上述日志消息表明该Flume事件不包含头（netcat源自己也没有添加任何头）。体以十六进制的形式呈现，并且还有一个字符串表示（便于阅读，该示例中就是Hello World消息）。
如果像下面这样再发送一行：
你会在代理的日志中看到如下内容：
事件似乎被截断了。根据设计，logger sink将体内容限制为16字节，从而避免屏幕充斥着过多的内容。如果想要查看调试的完整内容，那么你应该使用其他的sink，也许可以使用file_roll sink，它会将日志写到本地文件系统中。2.4 小结
本章介绍了如何下载Flume二进制分发包。我们创建了一个简单的配置文件，里面包含了一个源，它会将内容写到一个通道中，后者又会将其写到一个接收器中。源监听着一个Socket，等待网络客户端的连接，并向其发送事件数据。这些事件被写到一个内存通道中，然后被写到一个log4j接收器中，从而成为输出。接下来，我们使用Linux netcat工具连接到监听代理上，向Flume代理的源发送一些字符串事件。最后，我们验证基于log4j的接收器成功将事件写出。
下一章将会详细介绍在数据处理工作流中会用到的两个主要通道类型：
·内存通道
·文件通道
对于每一种类型的通道，我们都会介绍所有相关的配置，何时以及为何要覆盖默认值，更为重要的是，我们会介绍在何种场景下该使用哪一种通道。第3章通道
在Flume中，通道指的是位于源与接收器之间的构件。它为流动的事件提供了一个中间区域，从源中读取并且被写到数据处理管道中的接收器的事件处于这个区域中。
本章将要介绍的两类通道分别是内存/非持久化通道与本地文件系统/持久化通道。持久化文件通道会在发送者接收到事件前将所有变化写到磁盘上。它要比非持久化的内存通道慢一些，不过可以在出现系统事件或是Flume代理重启时进行恢复。与之相反，内存通道要更快一些，不过在出现失败时会导致数据丢失，并且与拥有大量磁盘空间的文件通道相比，它的存储能力要低很多。到底使用哪个通道取决于特定的用例、失败场景以及磁盘容忍度。
也就是说，无论选择哪一种通道，如果从源到通道的数据存储率大于接收器所能写出的数据率，那就会超出通道的处理能力，并且会抛出ChannelException异常。源到底能对该ChannelException异常做什么以及不能做什么是特定于源本身的，不过在某些情况下，数据丢失是可能的，因此你需要恰当地规划好数据大小以避免填满通道。事实上，你总是希望接收器的写入速度要快于源的输入速度。否则就会出现这样一种情况，即一旦接收器失败了，那么你就再也追不上了。如果数据追踪的是站点使用情况，那么在白天时数据量就会很大，而在晚上时则会低一些，这样通道就有时间将数据传输出去了。事实上，你希望保持通道的深度（当前通道中的事件数量）尽可能低一些，这是因为在到达最终目的地之前，通道中所花费的时间会变成延迟时间。3.1 内存通道
见名知意，内存通道指的是事件存储在内存中的通道。由于通常情况下，内存的速度要比磁盘快几个数量级，因此事件的接收速度也会更快，这降低了对硬件的需求量。使用这种通道的弊端在于代理失败（如硬件问题、断电、JVM崩溃、Flume重启等）会导致数据丢失。根据使用场景的不同，这可能是非常不错的解决方案。系统度量通常属于这一类，因为少量的数据丢失并不会造成什么影响。然而，如果事件表示的是网站的购买情况，那么内存通道就是一种非常差劲的选择了。
要想使用内存通道，请将通道的type参数设定为memory。
上面为名为agent的代理定义了一个名为c1的内存通道。
下面是一个配置参数表格，你可以据此调整默认值：
该通道的默认容量是100个事件，这可以通过设置capacity属性来达成：
记住一点，如果增加了这个值，那么你还需要增加Java堆空间大小，方式是使用-Xmx以及可选的-Xms参数实现。
你可以设定的另一个与容量相关的设置是transactionCapacity。它指的是源的ChannelProcessor（负责在单个事务中将数据从源移动到通道中的组件）可以写入的最大的事件数量。它也指的是SinkProcessor（负责将数据从通道移动到接收器的组件）在单个事务中所能读取的最大的事件数量。你可以将这个值设得大一些，从而降低事务包装器的代价，这会提升速度。对于失败事件来说，增加这个值的弊端在于源需要回滚更多的数据。
试读结束[说明：试读内容隐藏了图片]