“ Flume是一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统。”
01
—
概述
记得我们之前接到的一个需求是,要根据线上的一些客户数据进行报表分析,但这些数据在系统设计时没有进行统一的表结构设计,数据只存在系统日志中,而这些数据只用于汇报报表使用也没有特别“重”的实际业务流程的需要,因此我们当时采用了python来实时抓取日志,过滤之后存储到MySQL数据库中,来进行每日的报表汇报。这种只是日志分析需求的一个业务场景。由于行业的发展,现在很多公司的业务都会有基于日志分析数据的需求。今天要说的Flume正是基于这种场景设计的一个日志采集框架,当然他不仅仅可以从日志文件中提取信息,还可以从多种源(Source)来提取分析需要的信息,再写到不同的目标地(Sink)中,可以是文件,也可以是分布式文件系统(HDFS或者HBase)中,或者通过RPC、HTTP写到网络进程中。
02
—
Flume架构
Flume最简单的部署单元叫做Flume Agent,包括三个主要组件:Source、Channel、Sink;
Source组件提供了针对不同的源接收数据,包括从网络(Avro源、HTTP源)、消息队列等,还可以直接定义Linux的执行命令如tail,cat等命令作为源。Channel也提供持久存储或者内存两种方式,这些选择还需要具体看实际使用场景的需要。Sink也支持多种不同的数据目的地配置,如:HDFS、HBase、网络等。
Flume本身并不限制Agent中的Source、Channel、Sink数量,因此Flume支持将Source中的数据复制到多个目的地。通常,一个Source可以对应多个Channel,一个Channel对应一个Sink,当然允许多个Sink对应一个Channel,Flume可以保证只有一个Sink会从Sink中读取一个特定的事件(这里的事件就是数据)。Sink有组的概念,可以将多个Sink编入同一组内,组内可以设置不同的优先级,根据优先级高低来消费Channel中的数据。
以上是几种Flume的架构方式,在大型的数据处理系统架构内,总会有一些数据采集的系统,通过采集、传输、聚合等方式,使这些数据在这些系统内“流动”起来,当简单方式就是采集完数据直接进入到存储目的地,不过,当系统出现瓶颈时,往往我们需要将数据流先缓冲起来,以匹配下游系统的处理瓶颈,这这里面我们可以用复杂的组合方式来组装数据的流动管道,如Flume的Sink下沉到消息队列等方式,一方面保证数据在管道内不丢失,一方面不会将下游的存储出现性能瓶颈。这样我们就可以通过扩展消息队列,来解决数据缓冲层的瓶颈。而且数据采集支持负载均衡配置方式,来扩展当数据量增加时的压力。
Flume其他可选配置
构建FLume时的几个关键点