Flume基本原理

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_34993631/article/details/84403824

Flume入门综述

Flume是一个日志采集工具。具体来说它是一个分布式的能够从不同来源收集、聚集、日志信息用以集中管理的系统。他的核心思想就是从不同的数据源(比如说远程的http请求,监听远程的日志文件,当然也有可能是远程的程序发出的序列化数据)获得数据然后放入数据中转站,然后不同的数据中转站之间可以进行相互连接构成一个中转站网,最后我们可以将一根管子通到中转站上的任何一个节点来接收数据。我们可以先看两张图来感受一下:

他有6大核心组件分别是:

① Source:用来连接数据的源头与中转站的通道。

常见的数据源有:

Avro:(可以理解为序列化)的数据源,它可以接收外部Avro的数据流,同时当前节点也可以写出Avro的数据。

Spooling Directry Source:它会监听客户端存放日志的文件夹然后每当有新的文件夹产生就会自动将这个文件夹发送到Flume的中心服务器上。需要注意的是被监控的文件夹下的文件不能够修改,同时在收集数据的时候收集到同名的文件夹这两种情况都会使得Flume报错。

当然除了这两个数据源还有其它的数据源比如说http的数据源与NetCat的数据源。如果用户有特定的需求还能够自定义数据源。

 

② Sink:用来输出中转站内容的管道。

常见的Sink有:

Logger Sink:以日志的方式输出,这种输出常常用于调试。

File Roll Sink:将数据输出到本地的文件夹中。

HDFS Sink:将数据存储在HDFS中。

Avro Sink:将数据以序列化的形式输出,这种输出通常用于多级流动。

当然用户可以自定义输出的Sink。

 

③ Channel:数据的中转站,可以理解为一个数据的“蓄水池”。

常见的Channel有:

MemoryChannel:整个Channel是基于内存的,断电会丢失数据。这种Channel适用于高吞吐量但是能够容忍极端情况下丢失数据的场景。

File Channel:所有的事件都存储在文件中,通过这种机制Channel可以有很好的恢复性。但是缺点就是性能不够高。

Spillable Memory Channel:当数据量不大的时候先写在内存中,当超过一定的阈值数据就会溢写到硬盘上。这种方式结合了前两种Channel的优点。

最后,用户可以开发自定义的Channel。

 

④ Selector:多路选择器用来在多输出(也叫扇出数据)的时候按照指定的方式分发数据。比如说数据头中含有male的发往1号通道,而在头中含有fmale的发往另2号通道。这不由让我们想到了在网络编程中的多路选择,带有不同的头的请求会转发到不同的机器上。

在默认的配置下Flume采用的是复制模式,就是给它要发送的,每一个节点都赋值一份。

 

⑤ Interceptor:拦截器,由于在生产环境中有的不是所有的数据都是我们想要的,我们要过滤掉一些我们不感兴趣的数据。或者说我们需要将一些数据拦截下来进行一系列的操作然后再放行。而拦截器的作用就是在接收数据时过滤掉哪一些“不合格”的数据,或者是拦截一些数据然后做相应的处理。具体来说就是拦截那些不合格的Event(在Flume中一个Event就代表一条日志,一条日志的通常呈现格式就是一个Json的字符串)。这会让我们想到网络通信中的CDMA(码峰复用)我们只接收和我们的通讯设备通信编码匹配的信息其他的都会被过滤掉。

常见的拦截器有:

TimeStamp Interceptor:它将会把事件拦截下来并且在事件的头中添加一个时间戳信息。

Host Interceptor:它会把事件拦截下来并且在事件的头中添加主机名或者是ip信息。

Static Interceptor:它会把事件拦截下来然后添加指定的头信息(通过key-value的方式来制定)。

UUID Interceptor:它会把事件拦截下来然后在头中添加一个UUID字符串。

Regex Filter Interceptor:它会把事件拦截下来然后看其中的内容是否匹配正则表达式然后决定是否接收这个事件。

当然还有很多其他的拦截器。

 

⑥ Processor:在所有的分布式系统中都会遇到单节点奔溃的问题,所以常常使用多节点来做崩溃恢复与与负载均衡来解决这个问题。所以企业中的中心服务器常常是一个Flume集群。这时客户端Flume与中心服务器集群的通信也就成为了一个问题。Processor就是用来解决数据分配中奔溃恢复与负载均衡的组件。由于客户端会产生大量的日志数据,如果只分配给一个中心服务器的话就可能会导致奔溃,但是如果有了Processor我们在客户端为多个中心服务器分别配置sink之后就能够通过Processor进行调度分配数据,这样的话我们就能够让每个中心服务器的节点更加均匀的分配到数据(当然中间有很多不同的调度算法)。配置直观的如下图所示:

我们给Flume分配了一个sink组,当Processor发现Flume的中心有机器宕机时Processor回将这个节点剔除出当前的sink组然后将本来发送给它的数据发送给别的服务器。从这个角度来说Processor的负载均衡机制自带奔溃恢复的功能。

 

当然除了这些单独的组件之外还有一个组合的概念:Agent。Agent是由Source、Channel与Sink组成。它是Flume中数据收集的基本单元。同时由于Flume的复杂的流动方式我们又可以将多个Source的数据流入一个Agent的动作称作为扇入,一个Agent的数据输出到多个Sink的动作称作是扇出。如下图所示:

这就是Flume的核心组成。

最后感谢朴乾老师:- )

猜你喜欢

转载自blog.csdn.net/qq_34993631/article/details/84403824