《Flume日志收集与MapReduce模式》一第2章 Flume快速起步

1.5 Flume事件 Flume传输的基本的数据负载叫作事件.事件由0个或多个头与体组成. 头是一些键值对,可用于路由判定或是承载其他的结构化信息(比如说事件的时间戳或是发出事件的服务器主机名).你可以将其看作是与HTTP头完成相同的功能--传递与体不同的额外信息的方式. 体是个字节数组,包含了实际的负载.如果输入由日志文件组成,那么该数组就非常类似于包含了单行文本的UTF-8编码的字符串. Flume可能会自动添加头(比如,源添加了数据来自的主机名或是创建了事件时间戳),不过体基本上是不受影

第1章 概览与架构 如果在阅读本书,那就说明你正在数据的海洋中遨游.创建大量的数据是非常简单的事情,这要归功于Facebook.Twitter.Amazon.数码相机与相机照片.YouTube.Google,以及你能想得到的能够连接到互联网上的任何东西.作为网站的提供者,10年前的应用日志只是用来帮助你解决网站的问题.时至今日,如果你知道如何从大量的数据中浪里淘金,那么相同的数据就会提供关于业务与客户的有价值的信息. 此外,既然在阅读本书,那么你肯定知道创建Hadoop的目的在一定程度上就是为了

2.3 从"Hello World"开始 每一本技术图书都会有一个"Hello World"示例.下面是我们将会使用的配置文件: 这里定义了一个名为agent的代理,它有一个名为s1的源.一个名为c1的通道,以及一个名为k1的接收器.源s1的类型为netcat,它只是打开一个Socket监听事件(每个事件一行文本).它需要两个参数,分别是一个绑定IP与一个端口号.该示例使用0.0.0.0作为绑定地址(表示监听任何地址的Java约定)以及端口号12345.源配置还有一

3.2 文件通道 文件通道指的是将事件存储到代理本地文件系统中的通道.虽然要比内存通道慢一些,不过它却提供了持久化的存储路径,可以应对大多数情况,它应该用在数据流中不允许出现缺口的场合.这种持久化能力是由Write Ahead Log(WAL)以及一个或多个文件存储目录联合提供的.WAL用于以一种原子且安全的方式追踪来自于通道的所有输入与输出.通过这种方式,如果代理重启,那么WAL可以重放,从而确保在清理本地文件系统的数据存储前进入到通道中的所有事件都会被写出.此外,如果数据处理策略要求磁盘上的

3.3 小结 本章介绍了在数据处理管道中常用的两类通道.内存通道提供了更快的速度,这是以故障事件出现时数据丢失为代价的.此外,文件通道提供了更可靠的传输,因为它能容忍代理故障与重启,这是以牺牲性能为代价的.你需要确定哪种通道更适合于你的使用场景.在确定内存通道是否适合时,请问问自己丢失一些数据的经济上的代价如何.在考虑是否使用持久化通道时请衡量它与添加更多的硬件以弥补性能上的差异时的代价相比如何.另一个考虑就是数据问题了.写入到Hadoop中的数据不一定都来自于流式应用日志.如果接收的是每天的数

1.1 Flume 0.9 Flume是在2011年被首次引入到Cloudera的CDH3分发中的.它由一套工作守护进程(代理)构成,这些守护进程是通过Zookeeper(一个配置与协调系统)根据一个或多个集中的Master配置而成的.在Master上,你可以在Web UI中查看代理状态,也可以以集中的方式在UI或是通过命令行Shell的方式取出配置(这两种方式都是通过Zookeeper与工作代理进行通信的).可以通过3种模式发送数据,分别叫作Best Effort(BE).Disk Failo

2.2 Flume配置文件概览 既然已经下载好了Flume,下面来花点时间看看如何配置代理.Flume代理的默认配置提供者使用了一个简单的键值对的Java属性文件,你需要在启动时向代理传递一个参数.由于可以在单个文件中配置多个代理,因此还需要额外传递一个代理标识符(叫作名字),这样它就知道该使用哪个代理了.在给出的示例中,我只指定了一个代理,使用agent这个名字.每个代理的配置都以下面这3个参数开始: 每个源.通道与接收器在该代理的上下文中也有一个唯一的名字.比如,如果不打算传递Apache访

1.3 HDFS与流式数据/日志的问题 HDFS并不是真正的文件系统,至少从传统的认识来说不是这样,对于通常的文件系统来说,很多我们认为理所当然的东西并不适合于HDFS,比如挂载.这使得将流式数据装载进Hadoop中变得有些复杂.在通常的Portable Operating System Interface(POSIX)风格的文件系统中,如果打开文件并写入数据,那么在文件关闭前它会一直存在于磁盘上.也就是说,如果另一个程序打开了相同的文件并开始读取,那么它会读取到写入器写到磁盘上的数据.此外,如

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的目标范围.取代中心化配置的是一个简单的磁盘上