Flume 官方文档翻译 Flume 1.8.0 User Guide(一)
2018-02-09 14:40
309 查看
Introduction简述
OverView 综述
System Requirements系统要求
Architecture架构
Data flow model数据流动模型
Complex flows复杂流
Reliability可靠性
Recoverability可恢复性
Setup设置
Setting up an agent配置Agent
Configuring individual components配置单个组件
Wiring the pieces together组件配置整合
Starting an agent启动一个agent
A simple example一个简单的例子
Topology Design Considerations 拓扑设计注意事项
Flume是否适合解决您的问题
Flume数据流的可靠性考虑
Flume拓扑设计
调整Flume部署
处理Agent节点宕机
疑问-Flume 的Agent如果宕机后会自动监控重启吗还是需要启动者手动重启
Apache Flume不仅局限于数据的聚集。因为数据是可定制的,所以Flume可以用于运输大量时间数据(包括但不限于网络传输数据,社交媒体产生的数据,电子邮件信息和几乎任何数据源。)
Apache Flume是Apache软件基金会的顶级项目。
目前有两个可用的发布版本,0.9.x和1.x。
我们鼓励新老用户使用1.x发布版本来提高性能和利用新结构的配置灵活性。
内存——足够的内存来配置souuces,channels和sinks
磁盘空间-足够的磁盘空间来配置channels或者sinks
目录权限-代理所使用的目录读/写权限
![](https://img-blog.csdn.net/20180209114339377?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvenVvbG92ZWZ1/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)
Flume源消耗由外部源(如Web服务器)传递给它的事件。外部源以Flume源可识别的格式向Flume发送事件。例如,Avro Source可用于从Avro客户端或其他Flume客户端接收Avro事件。使用Thrift Source可以定义类似的流程,以接收来自Thrift Sink或Flume Thrift Rpc Client的客户端事件或使用Flume Thrift协议生成的任何语言编写的Thrift客户端事件。
党Flume Source接收到事件时,会将其存储到一个或多个Channel中。Channel是被动存储,保存事件,直到它被Sink 消费掉。如File Channel,它把Event保存到本地文件系统的文件中。
Sink 负责从Channel中删除Event并将其放入HDFS之类的外部存储库,或者将其转发到下一个Flume Agent 的Source组件中。
Flume使用事务性的操作来保证Event的可靠传送。Source和Sink分别在交易中封装由Channel提供的交易中放置或提供的事件的存储/检索。这确保了该组Event在传输流程中可靠地传递。
在多层架构的情况下,来自前一层的sink和来自下一层的Source都处于运行状态,以确保数据安全地存储在下一层的Channel中。
现在Agent将开始运行在给定的属性文件中配置的Source和Sink。
该配置定义了一个名为a1的Agent。a1有一个侦听端口44444上的数据的Source,一个缓存事件数据的内存Channel,以及一个将事件数据记录到控制台的Sink。配置文件对各个组件进行命名,然后描述它们的类型并配置相关参数。
给定的配置文件可能会定义几个有各自名字的Agent,当启动给定的Flume进程时,会传递一个标志,告诉它哪个名字的Agent要启动。
根据这个配置文件,我们可以按如下方式启动Flume:
请注意,在生产部署中,我们通常会包含一个选项:–conf = conf-dir。conf-dir目录将包含一个shell脚本:flume-env.sh和一个log4j属性文件。在这个例子中,我们通过一个option强制Flume登录到控制台,而没有一个自定义的环境脚本。
接下来,从另一个终端telnet到端口44444,并发送Event:
原始的Flume终端将在日志消息中输出Event。
恭喜 - 您已经成功配置并部署了Flume Agent!后续部分将更详细地介绍Agent配置。
Flume旨在通过相对稳定,(可能会)复杂的拓扑结构来传输和获取定期生成的事件数据。“事件数据”的概念非常广泛。对于Flume而言,事件只是一个通用的字节数组。这里对事件的大小有一些限制:例如,它不能大于你可以存储在内存中的大小或单个机器上的磁盘大小。但在实践中,Flume事件可以是从文本日志条目到图像文件的所有内容。
事件的关键属性是它们是以连续的,流式的方式生成的。如果您的数据不是经常生成的(即您正试图将一个批量的数据加载到Hadoop集群中),那么Flume仍然可以工作,但对您的情况可能是过度的,大炮打蚊子。
您的拓扑结构不需要一成不变,因为Flume可以在不丢失数据的情况下处理拓扑变化,还可以承受由于故障切换或配置而定期重新配置。但如果您每天都要改变拓扑结构,那么可能会影响正常工作,因为重新配置需要考虑一些思路的实现和开销。
1. 你使用什么类型的Channel。Flume具有持久通道(将数据持久化到磁盘的通道)和非持久通道(如果机器发生故障将丢失数据的通道)。持久通道使用基于磁盘的存储,存储在这些通道中的数据将持续存在于机器重启或非磁盘相关故障之中。
2. 您的Channel是否能充分解决了您对数据及时响应的需求。Flume中的通道充当各种中继的缓冲区。这些缓冲区具有固定的容量,一旦容量已满,您将在流量的早期Agent增加缓存压力。如果这个压力传播到流的源头,Flume将变得不可用并且可能丢失数据。
3. 是否使用冗余拓扑。Flume让您可以通过冗余拓扑复制流。这可以提供非常容易的容错来源,并且可以克服磁盘或机器故障。
在Flume拓扑结构中考虑可靠性的最佳方法是考虑各种故障情况及其结果。如果磁盘失败会发生什么?如果一台机器出现故障会怎样?如果您的终端接收器(如HDFS)停机一段时间,您的Channel又有压力,会发生什么情况?
设计空间是巨大的,但你需要问的基本问题只是少数。
如果您从大量数据来源收集数据,则可以通过聚合层合并数据以简化终端接收器的摄取。聚合层也可以消除Source的突发事件或Sink目标的不可用性,通过充当缓冲区。
如果要在不同位置之间路由数据,则可能还需要在各个点上分流:这会创建本身可能包含聚合点的子拓扑。
首先,您需要量化你产生的数据是多少。这并不总是一个简单的任务!因为大多数数据流是突发的(例如,由于昼夜模式)并且可能不可预测。一个好的起点是考虑每个拓扑结构层的最大吞吐量,无论是每秒事件数还是每秒字节数。一旦知道给定层所需的吞吐量,就可以计算出该层需要多少个节点的下限。为了确定设计的架构可达到的吞吐量,最好使用合成或采样事件数据在硬件上进行Flume实验。一般来说,基于磁盘的通道应该可以达到10 MB / s,基于内存的通道应该达到100 MB / s以上。取决于硬件和操作环境,性能会有很大的不同。
调整聚合吞吐量可以让您在每层需要的节点数量上下限。增加节点有几个原因,例如增加冗余和更好地吸收负载突发的能力。
OverView 综述
System Requirements系统要求
Architecture架构
Data flow model数据流动模型
Complex flows复杂流
Reliability可靠性
Recoverability可恢复性
Setup设置
Setting up an agent配置Agent
Configuring individual components配置单个组件
Wiring the pieces together组件配置整合
Starting an agent启动一个agent
A simple example一个简单的例子
Topology Design Considerations 拓扑设计注意事项
Flume是否适合解决您的问题
Flume数据流的可靠性考虑
Flume拓扑设计
调整Flume部署
处理Agent节点宕机
疑问-Flume 的Agent如果宕机后会自动监控重启吗还是需要启动者手动重启
Introduction(简述)
OverView (综述)
Apache Flume是一个分布式、高可靠和高可用的收集、集合和将大量来自不同来源的日志数据移动到一个中央数据仓库。Apache Flume不仅局限于数据的聚集。因为数据是可定制的,所以Flume可以用于运输大量时间数据(包括但不限于网络传输数据,社交媒体产生的数据,电子邮件信息和几乎任何数据源。)
Apache Flume是Apache软件基金会的顶级项目。
目前有两个可用的发布版本,0.9.x和1.x。
我们鼓励新老用户使用1.x发布版本来提高性能和利用新结构的配置灵活性。
System Requirements(系统要求)
Java RunTime环境 - Java 1.8或更高版本内存——足够的内存来配置souuces,channels和sinks
磁盘空间-足够的磁盘空间来配置channels或者sinks
目录权限-代理所使用的目录读/写权限
Architecture(架构)
Data flow model(数据流动模型)
一个Flume event定义为拥有一个字节有效负载的一个数据流单元,同时拥有一个可选的字符串属性配置。Flume agent其实就是一个JVM进程,该JVM进程控制事件流从外部来源传输到目的地。Flume源消耗由外部源(如Web服务器)传递给它的事件。外部源以Flume源可识别的格式向Flume发送事件。例如,Avro Source可用于从Avro客户端或其他Flume客户端接收Avro事件。使用Thrift Source可以定义类似的流程,以接收来自Thrift Sink或Flume Thrift Rpc Client的客户端事件或使用Flume Thrift协议生成的任何语言编写的Thrift客户端事件。
党Flume Source接收到事件时,会将其存储到一个或多个Channel中。Channel是被动存储,保存事件,直到它被Sink 消费掉。如File Channel,它把Event保存到本地文件系统的文件中。
Sink 负责从Channel中删除Event并将其放入HDFS之类的外部存储库,或者将其转发到下一个Flume Agent 的Source组件中。
Complex flows(复杂流)
Flume允许用户建立multi-hop流,当事件在到达最终目的地时要经过多个Agent。它也支持扇入和扇出流,上下文路由和失效hop的恢复路由。Reliability(可靠性)
Event在每个Agent的Channel上进行缓存,随后Event将会传递到流中的下一个Agent或终端存储库(如HDFS)。只有在存储在下一个代理的通道或终端存储库中后Event才会从Channel中删除。这一步骤实现了单节点架构的可靠性。Flume使用事务性的操作来保证Event的可靠传送。Source和Sink分别在交易中封装由Channel提供的交易中放置或提供的事件的存储/检索。这确保了该组Event在传输流程中可靠地传递。
在多层架构的情况下,来自前一层的sink和来自下一层的Source都处于运行状态,以确保数据安全地存储在下一层的Channel中。
Recoverability(可恢复性)
Event在Channel中进行缓存,提供了从失败中恢复的机制。Flume支持由本地文件系统支持的File Channel。Flume还有一个内存Channel,它将事件简单地存储在内存队列中,这个速度更快,但是当Agent死亡时,仍然留在内存通道中的任何Event都不能被恢复。Setup(设置)
Setting up an agent(配置Agent)
Flume agent配置存储在一个本地配置文件中。这是一个跟Java 属性文件格式一样的文本文件。一个或者多个agent可以指定同一个配置文件来进行配置。配置文件包括每个source的属性,agent中的sink和channel以及它们是如何连接构成数据流。Configuring individual components(配置单个组件)
流中的每个组件(source,sink或者channel)都有名字,类型和用来指定类型的属性集和实例化。例如,一个avro source需要一个主机名(或者IP地址)和端口来接收数据,内存channel有最大队列值(“capacity”),和HDFS sink需要知道文件系统的URI,来创建路径,轮询文件的频率(hdfs.roollInterval)等.组件的所有属性都必须在Flume agetnt的属性文件里配置。Wiring the pieces together(组件配置整合)
agent需要知道每个组件加载什么和它们是怎样连接构成流。这通过列出agent中每个source、sink和channel和指定每个sink和source连接的channel。例如,一个agent流事件从一个称为avroWeb的Avro sources通过一个称为file-channel的文件channel流向一个称为hdfs-cluster1的HDFS sink。配置文档将包含这些组件的名字和avroWeb source和hdfs-cluster1 sink中间共享的file-channel。Starting an agent(启动一个agent)
agent通过一个称为flume-ngshell位于Flume项目中bin目录下的脚本来启动。你必须在命令行中指定一个agent名字,配置目录和配置文档$ bin/flume-ng agent -n $agent_name -c conf -f conf/flume-conf.properties.template
现在Agent将开始运行在给定的属性文件中配置的Source和Sink。
A simple example(一个简单的例子)
这里我们给出一个配置文件的例子,阐述一个单点Flume的部署,这个配置让用户生成事件并随后将它们记录到控制台。# example.conf: A single-node Flume configuration # Name the components on this agent a1.sources = r1 a1.sinks = k1 a1.channels = c1 # Describe/configure the source a1.sources.r1.type = netcat a1.sources.r1.bind = localhost a1.sources.r1.port = 44444 # Describe the sink a1.sinks.k1.type = logger # Use a channel which buffers events in memory a1.channels.c1.type = memory a1.channels.c1.capacity = 1000 a1.channels.c1.transactionCapacity = 100 # Bind the source and sink to the channel a1.sources.r1.channels = c1 a1.sinks.k1.channel = c1
该配置定义了一个名为a1的Agent。a1有一个侦听端口44444上的数据的Source,一个缓存事件数据的内存Channel,以及一个将事件数据记录到控制台的Sink。配置文件对各个组件进行命名,然后描述它们的类型并配置相关参数。
给定的配置文件可能会定义几个有各自名字的Agent,当启动给定的Flume进程时,会传递一个标志,告诉它哪个名字的Agent要启动。
根据这个配置文件,我们可以按如下方式启动Flume:
$ bin/flume-ng agent --conf conf --conf-file example.conf --name a1 -Dflume.root.logger=INFO,console
请注意,在生产部署中,我们通常会包含一个选项:–conf = conf-dir。conf-dir目录将包含一个shell脚本:flume-env.sh和一个log4j属性文件。在这个例子中,我们通过一个option强制Flume登录到控制台,而没有一个自定义的环境脚本。
接下来,从另一个终端telnet到端口44444,并发送Event:
$ telnet localhost 44444 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello world! <ENTER> OK
原始的Flume终端将在日志消息中输出Event。
12/06/19 15:32:19 INFO source.NetcatSource: Source starting 12/06/19 15:32:19 INFO source.NetcatSource: Created serverSocket:sun.nio.ch.ServerSocketChannelImpl[/127.0.0.1:44444] 12/06/19 15:32:34 INFO sink.LoggerSink: Event: { headers:{} body: 48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0D Hello world!. }
恭喜 - 您已经成功配置并部署了Flume Agent!后续部分将更详细地介绍Agent配置。
Topology Design Considerations 拓扑设计注意事项
Flume非常灵活,可以实现大量的部署场景。如果您计划在大规模的生产部署中使用Flume,那么花一些时间思考如何用Flume拓扑来解决您的问题是明智的。本节包含一些注意事项。Flume是否适合解决您的问题?
果您需要将文本日志数据提取到Hadoop / HDFS,则Flume适合您的问题,可以停止寻找其他解决方案了。对于其他用例,这里有一些指导性的原则:Flume旨在通过相对稳定,(可能会)复杂的拓扑结构来传输和获取定期生成的事件数据。“事件数据”的概念非常广泛。对于Flume而言,事件只是一个通用的字节数组。这里对事件的大小有一些限制:例如,它不能大于你可以存储在内存中的大小或单个机器上的磁盘大小。但在实践中,Flume事件可以是从文本日志条目到图像文件的所有内容。
事件的关键属性是它们是以连续的,流式的方式生成的。如果您的数据不是经常生成的(即您正试图将一个批量的数据加载到Hadoop集群中),那么Flume仍然可以工作,但对您的情况可能是过度的,大炮打蚊子。
您的拓扑结构不需要一成不变,因为Flume可以在不丢失数据的情况下处理拓扑变化,还可以承受由于故障切换或配置而定期重新配置。但如果您每天都要改变拓扑结构,那么可能会影响正常工作,因为重新配置需要考虑一些思路的实现和开销。
Flume数据流的可靠性考虑
Flume数据流的可靠性取决于几个因素,通过调整这些因素,您可以使用Flume实现广泛的可靠性选项。1. 你使用什么类型的Channel。Flume具有持久通道(将数据持久化到磁盘的通道)和非持久通道(如果机器发生故障将丢失数据的通道)。持久通道使用基于磁盘的存储,存储在这些通道中的数据将持续存在于机器重启或非磁盘相关故障之中。
2. 您的Channel是否能充分解决了您对数据及时响应的需求。Flume中的通道充当各种中继的缓冲区。这些缓冲区具有固定的容量,一旦容量已满,您将在流量的早期Agent增加缓存压力。如果这个压力传播到流的源头,Flume将变得不可用并且可能丢失数据。
3. 是否使用冗余拓扑。Flume让您可以通过冗余拓扑复制流。这可以提供非常容易的容错来源,并且可以克服磁盘或机器故障。
在Flume拓扑结构中考虑可靠性的最佳方法是考虑各种故障情况及其结果。如果磁盘失败会发生什么?如果一台机器出现故障会怎样?如果您的终端接收器(如HDFS)停机一段时间,您的Channel又有压力,会发生什么情况?
设计空间是巨大的,但你需要问的基本问题只是少数。
Flume拓扑设计
设计Flume拓扑的第一步是枚举数据的所有数据源和Sink目标(终端接收器),这些将定义您的拓扑的边缘点。接下来的考虑是是引入中间聚合层还是事件路由。如果您从大量数据来源收集数据,则可以通过聚合层合并数据以简化终端接收器的摄取。聚合层也可以消除Source的突发事件或Sink目标的不可用性,通过充当缓冲区。
如果要在不同位置之间路由数据,则可能还需要在各个点上分流:这会创建本身可能包含聚合点的子拓扑。
调整Flume部署
一旦你了解了你的拓扑结构,下一个问题是了解需要多少硬件和网络容量。首先,您需要量化你产生的数据是多少。这并不总是一个简单的任务!因为大多数数据流是突发的(例如,由于昼夜模式)并且可能不可预测。一个好的起点是考虑每个拓扑结构层的最大吞吐量,无论是每秒事件数还是每秒字节数。一旦知道给定层所需的吞吐量,就可以计算出该层需要多少个节点的下限。为了确定设计的架构可达到的吞吐量,最好使用合成或采样事件数据在硬件上进行Flume实验。一般来说,基于磁盘的通道应该可以达到10 MB / s,基于内存的通道应该达到100 MB / s以上。取决于硬件和操作环境,性能会有很大的不同。
调整聚合吞吐量可以让您在每层需要的节点数量上下限。增加节点有几个原因,例如增加冗余和更好地吸收负载突发的能力。
处理Agent节点宕机
如果Flume代理发生故障,则该Agent上托管的所有流程都会中止。Agent重新启动后,流程将恢复,使用文件通道或其他稳定通道的流程将恢复处理之前停止的事件。如果代理不能在同一硬件上重新启动,那么可以选择将数据迁移到另一个硬件,并设置一个新的Flume代理,以恢复处理保存在Channel中的事件。可以利用数据库HA futures 来将Flume代理移动到另一个主机。疑问-Flume 的Agent如果宕机后,会自动监控重启吗?还是需要启动者手动重启?
相关文章推荐
- Apache Flume入门指南[翻译自官方文档]
- 【Hadoop】Flume官方文档翻译——Flume 1.7.0 User Guide (unreleased version)(二)
- JUnit 5 User Guide 官方指导文档翻译(1)
- Flume官方文档翻译之(九)
- 【Hadoop】Flume官方文档翻译——Flume 1.7.0 User Guide (unreleased version)中一些知识点
- Flume官方文档翻译之(十)
- Flume官方文档翻译之(十一)
- Flume官方文档翻译之(七)
- Flume官方文档翻译之(五)
- Flume官方文档翻译之(一)
- Flume官方文档翻译之(十二)
- Flume官方文档翻译之(四)
- Flume官方文档翻译之(十三)
- 【Hadoop】Flume官方文档翻译——Flume 1.7.0 User Guide (unreleased version)(一)
- Flume官方文档翻译之(二)
- Flume官方文档翻译之(三)
- Flume官方文档翻译之(八)
- Flume官方文档翻译之(六)
- 使用Android Studio进行NDK开发和调试(gradle-experimental之官方文档的翻译说明)
- Introduction to C++ Programming in UE4——UE4官方文档翻译与理解(二)