大数据系列(五)之 Flume 数据传输

目录

一、Flume简介

二、Flume架构

2.1 Flume基本组件

2.2 Flume常见数据流模型

三、Source,Channel,Sink 详解

3.1 Source

3.2 Channel

3.3 Sink


一、Flume简介

Flume是一个分布式的,可靠的,高可用的海量日志采集,聚合和传输的系统。它也是Hadoop生态圈中的关键组件之一。

Flume通过可扩展,插件化,组合式,高可用,高容错的设计模式,为用户提供了高效准确的轻量化大数据采集工具。

Flume可以通过简单的配置,收集不同数据源的海量数据,并将数据准确,高效的传入到不同中心存储里面。目前Flume可以对接主流的大数据框架有,Hadoop,Kafka,Spark等。

在使用Flume的过程中,通过配置文件就可以实现整个数据收集过程的负载均衡和故障转移,整个流程不需要修改Flume的任何代码。Flume具有的这些优良的特性,得益于它优秀的架构设计。

Apache 官方的简介

Apache Flume是一个分布式,可靠且可用的系统,用于有效地收集,聚合大量日志数据并将其从许多不同的源移动到集中式数据存储中。

Apache Flume的使用不仅限于日志数据聚合。由于数据源是可定制的,因此Flume可用于传输大量事件数据,包括但不限于网络流量数据,社交媒体生成的数据,电子邮件消息以及几乎所有可能的数据源。

Apache Flume是Apache Software Foundation的顶级项目。

二、Flume架构

Flume事件定义为具有字节有效负载和可选字符串属性集的数据流单位。Flume是使用Java开发的,它的代理是一个(JVM)进程,承载了组件,Event通过这些组件从外部源流到下一个目标(hop)。

2.1 Flume基本组件

Event:数据消息的基本单位,有header(键值对)和body(字节数组)组成。

Agent:Flume 运行的核心是 Agent。Flume以agent为最小的独立运行单位。一个agent就是一个JVM。它是一个完整的数据收集工具,含有三个核心组件,分别是source、 channel、 sink。通过这些组件, Event 可以从一个地方流向另一个地方

一个Agent包括Source、Channel和Sink,还有一些可选的组件(稍后会介绍),如下图所示。

Source : 从外部来源读取Event,并写入到Channel当中。

Channel : Event临时存储组件,Source写入后,Event将会一直保存,直到被Sink成功消费。

Sink :从Channel读取Event,并写入目的地。

大数据系列(五)之 Flume 数据传输_第1张图片

其实在Agent里面我们还可以配置三个可选的组件,分别是Interceptor(拦截器),Selector(选择器),SinkProcessor(event处理器)。

Interceptor(拦截器):可以处理Event中的header信息,可以在Header中添加消息处理的时间戳,还可以添加主机名称,还有一些静态值,也可以根据正则表达式对Event进行过滤,选择那些Event可以继续向后进行传输,也可以决定哪些Event被删除,停止向后传输。Interceptor可以配置多个,多个Interceptor可以顺序执行

Selector(多路复用选择器):Interceptor处理完Event之后会传输给Selector(选择器)。选择器的作用是选择哪种方式把Event写入到Channel当中。

SinkProcessor(event处理器):当Sink从Channel中消费消息之前,可以选择SinkProcessor(event处理器),根据配置可以选择使用故障转移处理器或者负载均衡处理器。然后进Sink消费消息。

2.2 Flume常见数据流模型

2.2.1 基本数据流模型

Flume启动一个Agent,通过Source从外部数据源(如Web服务器)对数据消息(Event)进行采集,然后放在Channel当中临时存储,由Sink从Channel里面进行消费消息,写入到HDFS里面进行持久化存储。

大数据系列(五)之 Flume 数据传输_第2张图片

2.2.2 多Agent的复杂流

日志收集中的一种非常常见的情况是,大量的日志生成,客户端将数据发送到连接存储子系统的几个消费者代理。例如,从数百台Web服务器收集的日志发送到许多写入HDFS群集的代理。其中用到的主要架构是多级的Flume流:如下图所示

大数据系列(五)之 Flume 数据传输_第3张图片

下面我们举个例子来说明生产中常见的使用场景:

说明:收集多个节点的服务器数据,然后进行汇总,汇总之后再进行持久化存储。(如下图所示)

有三个WebServer服务器分别产生数据,针对这三台服务器分别启动三个Agent,Agent1,Agent2,Agent3对应三个WebServer,每个Agent负责收集对应服务器产生的数据消息(Event),收集完之后,这三个Agent再Sink阶段,都把数据发送到了Agent4,Agent4的作用是负责收集其他三个Agent输出的数据,并把收集到的所有数据写入到HDFS当中。

这里我们看出,Agent不仅可以和外部的数据源和外部的存储机制进行连接,在多个Agent之间也是可以进行连接的,可以根据不同的使用场景对Agent进行灵活的组合。

大数据系列(五)之 Flume 数据传输_第4张图片

2.2.3 多路复用流

Flume还支持将Event流复用到一个或多个目的地。这是通过定义一种流多路复用器来实现的,该流多路复用器可以将Event复制或选择性地路由到一个或多个通道。

这个数据流是将不同类型的数据流写入到不同的Channel当中,然后不通的Channel对应的Sink将收集到的数据消息(Event)输出到不同的目的地。

大数据系列(五)之 Flume 数据传输_第5张图片

三、Source,Channel,Sink 详解

3.1 Source

对接各种外部数据源,将收集到的Event发送到Channel中,一个Source可以向多个Channel发送Event,Flume内置非常丰富的Source,同时用户可以自定义Source。

3.1.1 Avro Source

flume可以多级代理,然后代理与代理之间用Avro去连接。也就是Avro Source可以和上一个Agent进行连接。

Avro Source监听Avro端口接收从外部Avro客户端发送来的数据流。如果与上一层Agent的 Avro Sink 配合使用就组成了一个分层的拓扑结构。 必需的参数已用 粗体 标明。

大数据系列(五)之 Flume 数据传输_第6张图片

官网配置举例参考:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html#avro-source

中文翻译版参考:https://flume.liyifeng.org/#avro-source

操作示例:(待完善)

3.1.2 Thrift Source

ThriftSource 与Avro Source 基本一致。只要把source的类型改成thrift即可,例如a1.sources.r1.type = thrift 。

监听Thrift 端口,从外部的Thrift客户端接收数据流。如果从上一层的Flume Agent的 Thrift Sink 串联后就创建了一个多层级的Flume架构(同 Avro Source 一样,只不过是协议不同而已)。Thrift Source可以通过配置让它以安全模式(kerberos authentication)运行,具体的配置看下表。 必需的参数已用 粗体 标明。

大数据系列(五)之 Flume 数据传输_第7张图片

官网配置举例参考:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html#thrift-source

中文翻译版参考:https://flume.liyifeng.org/#thrift-source

操作示例:(待完善)

3.1.3 Exec Source

执行Unix命令,获取标准输出,例如:tail -f 。

这个source在启动时运行给定的Unix命令,并期望该进程在标准输出上连续生成数据(stderr 信息会被丢弃,除非属性 logStdErr 设置为 true )。 如果进程因任何原因退出, 则source也会退出并且不会继续生成数据。 综上来看cat [named pipe]或tail -F [file]这两个命令符合要求可以产生所需的结果,而date这种命令可能不会,因为前两个命令(tail 和 cat)能产生持续的数据流,而后者(date这种命令)只会产生单个Event并退出。

提示:

cat [named pipe]和tail -F [file]都能持续地输出内容,那些不能持续输出内容的命令不可以。这里注意一下cat命令后面接的参数是命名管道(named pipe)不是文件。

必需的参数已用 粗体 标明。

大数据系列(五)之 Flume 数据传输_第8张图片

官网配置举例参考:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html#exec-source

中文翻译版参考:https://flume.liyifeng.org/#exec-source

操作示例:(待完善)

3.1.4 JMS Source

从JMS源获取数据。

JMS Source是一个可以从JMS的队列或者topic中读取消息的组件。按理说JMS Source作为一个JMS的应用应该是能够与任意的JMS消息队列无缝衔接工作的,可事实上目前仅在ActiveMQ上做了测试。 JMS Source支持配置batch size、message selector、user/pass和Event数据的转换器(converter)。 注意所使用的JMS队列的jar包需要在Flume实例的classpath中,建议放在专门的插件目录plugins.d下面,或者启动时候用-classpath指定,或者编辑flume-env.sh文件的FLUME_CLASSPATH来设置。

必需的参数已用 粗体 标明。

大数据系列(五)之 Flume 数据传输_第9张图片

官网配置举例参考:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html#jms-source

中文翻译版参考:https://flume.liyifeng.org/#jms-source

操作示例:(待完善)

3.1.5 Spooling Directory Source

监听目录下的新增文件。

这个Source允许你把要收集的文件放入磁盘上的某个指定目录。它会将监视这个目录中产生的新文件,并在新文件出现时从新文件中解析数据出来。数据解析逻辑是可配置的。在新文件被完全读入Channel之后会重命名该文件以示完成(也可以配置成读完后立即删除)。

与Exec Source不同,Spooling Directory Source是可靠的,即使Flume重新启动或被kill,也不会丢失数据。同时作为这种可靠性的代价,指定目录中的文件必须是不可变的、唯一命名的。Flume会自动检测避免这种情况发生,如果发现问题,则会抛出异常:

  1. 如果文件在写入完成后又被再次写入新内容,Flume将向其日志文件(这是指Flume自己logs目录下的日志文件)打印错误并停止处理。

  2. 如果在以后重新使用以前的文件名,Flume将向其日志文件打印错误并停止处理。

为了避免上述问题,生成新文件的时候文件名加上时间戳是个不错的办法。

尽管有这个Source的可靠性保证,但是仍然存在这样的情况,某些下游故障发生时会出现重复Event的情况。这与其他Flume组件提供的保证是一致的。

大数据系列(五)之 Flume 数据传输_第10张图片

官网配置举例参考:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html#spooling-directory-source

中文翻译版参考:https://flume.liyifeng.org/#spooling-directory-source

操作示例:(待完善)

3.1.6 Taildir Source

用于监听目录或文件。

Taildir Source监控指定的一些文件,并在检测到新的一行数据产生的时候几乎实时地读取它们,如果新的一行数据还没写完,Taildir Source会等到这行写完后再读取。

Taildir Source是可靠的,即使发生文件轮换(译者注1)也不会丢失数据。它会定期地以JSON格式在一个专门用于定位的文件上记录每个文件的最后读取位置。如果Flume由于某种原因停止或挂掉,它可以从文件的标记位置重新开始读取。

Taildir Source还可以从任意指定的位置开始读取文件。默认情况下,它将从每个文件的第一行开始读取。

文件按照修改时间的顺序来读取。修改时间最早的文件将最先被读取(简单记成:先来先走)。

Taildir Source不重命名、删除或修改它监控的文件。当前不支持读取二进制文件。只能逐行读取文本文件。

需要注意的是:Taildir Source目前只是个预览版本,还不能运行在windows系统上。

大数据系列(五)之 Flume 数据传输_第11张图片

官网配置举例参考:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html#taildir-source

中文翻译版参考:https://flume.liyifeng.org/#taildir-source

操作示例:(待完善)

3.1.7 Kafka Source

读取Kafka数据。

Kafka Source就是一个Apache Kafka消费者,它从Kafka的topic中读取消息。 如果运行了多个Kafka Source,则可以把它们配置到同一个消费者组,以便每个source都读取一组唯一的topic分区。

大数据系列(五)之 Flume 数据传输_第12张图片

官网配置举例参考:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html#kafka-source

中文翻译版参考:https://flume.liyifeng.org/#kafka-source

操作示例:(待完善)

3.1.8 HTTP Source

启动一个HTTPServer。

这个Source从HTTP POST 和 GET请求里面解析 Event,GET方式目前还只是实验性的。把HTTP请求解析成Event是通过配置一个“handler”来实现的,这个“handler”必须实现 HTTPSourceHandler 接口, 这个接口其实就一个方法,收到一个HttpServletRequest后解析出一个 Event 的List。从一次请求解析出来的若干个Event会以一个事务提交到channel, 从而在诸如『文件channel』的一些channel上提高效率。如果handler抛出异常,这个HTTP的响应状态码是400。如果channel满了或者无法发送Event到channel,此时会返回HTTP状态码503(服务暂时不可用)。

在一个POST请求中发送的所有 Event 视为一个批处理,并在一个事务中插入到 channel。

大数据系列(五)之 Flume 数据传输_第13张图片

官网配置举例参考:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html#http-source

中文翻译版参考:https://flume.liyifeng.org/#http-source

操作示例:(待完善)

3.1.9 其他 Source

除了以上介绍的,Flume还提供了很多类型的Source,比如NetCat TCP Source,NetCat UDP Source,Sequence Generator Source,Syslog Sources,Stress Source,Custom Source,Scribe Source等这里就不逐一介绍了,其他source 可以去官网自行查看:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html#flume-sources

中文翻译版参考:https://flume.liyifeng.org/#flume-sources

3.2 Channel

3.2.1 Memory Channel

3.2.2 JDBC Channel

3.2.3 Kafka Channel

3.2.4 File Channel

3.2.5 Spillable Memory Channel

3.2.6 Pseudo Transaction Channel

3.2.7 Custom Channel

3.3 Sink

3.3.1 HDFS Sink

3.3.2 Hive Sink

3.3.3 Logger Sink

3.3.4 Avro Sink

3.3.5 Thrift Sink

3.3.6 IRC Sink

3.3.7 File Roll Sink

3.3.8 Null Sink

3.3.9 HBaseSinks

3.3.10 MorphlineSolrSink

3.3.11 ElasticSearchSink

3.3.12 Kite Dataset Sink

3.3.13 Kafka Sink

3.3.14 HTTP Sink

3.3.15 Custom Sink

 

大数据系列的其他文章:

大数据系列(一)之 ZooKeeper 分布式协调服务

大数据系列(二)之 hdfs 分布式文件系统详解

大数据系列(三)之 Yarn 资源调度框架详解

大数据系列(四)之 MapReduce过程及shuffle详解

大数据系列(五)之 Flume 数据传输

 


附上:Flume官方文档:http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html

 

你可能感兴趣的:(大数据系列详解)