分布式日志收集系统Apache Flume的设计介绍

概述

Flume是Cloudera公司的一款高性能、高可能的分布式日志收集系统。现在已经是Apache Top项目。 Github地址。同Flume相似的日志收集系统还有 Facebook Scribe， Apache Chuwka， Apache Kafka(也是LinkedIn的)。Flume是后起之秀，本文尝试简要分析Flume数据流通过程中提供的组件、可靠性保证来介绍Flume的主要设计，不涉及Flume具体的安装使用，也不涉及代码层面的剖析。写博文来记录这个工具主要是觉得与最近开发的一个流式的数据搬运的工具在设计上有相似之处，想看看有没有可以参考的地方。在博文的基础上，还需要浏览一下源码。

数据流通

Flume传输的数据的基本单位是event，如果是文本文件，通常是一行记录，这也是事务的基本单位。flume运行的核心是agent。它是一个完整的数据收集工具，含有三个核心组件，分别是source、channel、sink。Event从Source，流向Channel，再到Sink，本身为一个byte数组，并可携带headers信息。Event代表着一个数据流的最小完整单元，从外部数据源来，向外部的目的地去。Source:完成对日志数据的收集，分成transtion 和 event 打入到channel之中。Channel:主要提供一个队列的功能，对source提供中的数据进行简单的缓存。Sink:取出Channel中的数据，进行相应的存储文件系统，数据库，或者提交到远程服务器。通过这些组件，event可以从一个地方流向另一个地方，如下图所示。

Source消费从外部流进的Events，如AvroSource接收外部客户端传来的或是从别的agent流出来的Avro Event。Source可以把event送往一个或多个channel。channel是一个队列，持有event等待sink来消费，一种Channel的实现：FileChannel使用本地文件系统来作为它的存储。Sink的作用是把Event从channel里移除，送往外部数据仓库或给下一站agent的Source，如HDFSEventSink送往HDFS。同个agent下的source和sink是异步的。下面再举几个数据流通的例子，说明不同的使用方式。

多agent模式

多对一的合并/Collector场景

一对多路输出模型

Source接入

Client端操作消费数据的来源，Flume支持Avro，log4j，syslog和http post(body为json格式)。可以让应用程序同已有的Source直接打交道，如AvroSource，SyslogTcpSource。也可以写一个Source，以IPC或RPC的方式接入自己的应用，Avro和Thrift都可以(分别有NettyAvroRpcClient和ThriftRpcClient实现了RpcClient接口)，其中Avro是默认的RPC协议。具体代码级别的Client端数据接入，可以参考 官方手册。
对现有程序改动最小的使用方式是使用是直接读取程序原来记录的日志文件，基本可以实现无缝接入，不需要对现有程序进行任何改动。
对于直接读取文件Source,有两种方式：

1. ExecSource:以运行Linux命令的方式，持续的输出最新的数据，如tail -F 文件名指令，在这种方式下，取的文件名必须是指定的。 ExecSource可以实现对日志的实时收集，但是存在Flume不运行或者指令执行出错时，将无法收集到日志数据，无法保证日志数据的完整性。
2. SpoolSource:监测配置的目录下新增的文件，并将文件中的数据读取出来。需要注意两点：拷贝到spool目录下的文件不可以再打开编辑；spool目录下不可包含相应的子目录。SpoolSource虽然无法实现实时的收集数据，但是可以使用以分钟的方式分割文件，趋近于实时。如果应用无法实现以分钟切割日志文件的话，可以两种收集方式结合使用。 在实际使用的过程中，可以结合log4j使用，使用log4j的时候，将log4j的文件分割机制设为1分钟一次，将文件拷贝到spool的监控目录。log4j有一个TimeRolling的插件，可以把log4j分割的文件到spool目录。基本实现了实时的监控。Flume在传完文件之后，将会修改文件的后缀，变为.COMPLETED（后缀也可以在配置文件中灵活指定）

publicclassMySourceextendsAbstractSourceimplementsConfigurable,PollableSource{
privateStringmyProp;

@Override
publicvoidconfigure(Contextcontext){
StringmyProp=context.getString("myProp","defaultValue");

//ProcessthemyPropvalue(e.g.validation,converttoanothertype,...)

//StoremyPropforlaterretrievalbyprocess()method
this.myProp=myProp;
}

@Override
publicvoidstart(){
//Initializetheconnectiontotheexternalclient
}

@Override
publicvoidstop(){
//Disconnectfromexternalclientanddoanyadditionalcleanup
//(e.g.releasingresourcesornulling-outfieldvalues)..
}

@Override
publicStatusprocess()throwsEventDeliveryException{
Statusstatus=null;

//Starttransaction
Channelch=getChannel();
Transactiontxn=ch.getTransaction();
txn.begin();
try{
//ThistryclauseincludeswhateverChanneloperationsyouwanttodo

//Receivenewdata
Evente=getSomeData();

//StoretheEventintothisSource'sassociatedChannel(s)
getChannelProcessor().processEvent(e)

txn.commit();
status=Status.READY;
}catch(Throwablet){
txn.rollback();

//Logexception,handleindividualexceptionsasneeded

status=Status.BACKOFF;

//re-throwallErrors
if(tinstanceofError){
throw(Error)t;
}
}finally{
txn.close();
}
returnstatus;
}}

Channel

Channel有多种方式：有MemoryChannel,JDBC Channel,MemoryRecoverChannel,FileChannel。
MemoryChannel可以实现高速的吞吐，但是无法保证数据的完整性。
MemoryRecoverChannel在官方文档的建议上已经建义使用FileChannel来替换。
FileChannel保证数据的完整性与一致性。在具体配置不现的FileChannel时，建议FileChannel设置的目录和程序日志文件保存的目录设成不同的磁盘，以便提高效率。

Sink

Sink在设置存储数据时，可以向文件系统、数据库、hadoop存数据，在日志数据较少时，可以将数据存储在文件系中，并且设定一定的时间间隔保存数据。在日志数据较多时，可以将相应的日志数据存储到Hadoop中，便于日后进行相应的数据分析。
更多sink的内容可以参考 官方手册。

publicclassMySinkextendsAbstractSinkimplementsConfigurable{
privateStringmyProp;

@Override
publicvoidconfigure(Contextcontext){
StringmyProp=context.getString("myProp","defaultValue");

//ProcessthemyPropvalue(e.g.validation)

//StoremyPropforlaterretrievalbyprocess()method
this.myProp=myProp;
}

@Override
publicvoidstart(){
//Initializetheconnectiontotheexternalrepository(e.g.HDFS)that
//thisSinkwillforwardEventsto..
}

@Override
publicvoidstop(){
//Disconnectfromtheexternalrespositoryanddoany
//additionalcleanup(e.g.releasingresourcesornulling-out
//fieldvalues)..
}

@Override
publicStatusprocess()throwsEventDeliveryException{
Statusstatus=null;

//Starttransaction
Channelch=getChannel();
Transactiontxn=ch.getTransaction();
txn.begin();
try{
//ThistryclauseincludeswhateverChanneloperationsyouwanttodo

Eventevent=ch.take();

//SendtheEventtotheexternalrepository.
//storeSomeData(e);

txn.commit();
status=Status.READY;
}catch(Throwablet){
txn.rollback();

//Logexception,handleindividualexceptionsasneeded

status=Status.BACKOFF;

//re-throwallErrors
if(tinstanceofError){
throw(Error)t;
}
}finally{
txn.close();
}
returnstatus;
}}

可靠性

Flume的核心是把数据从数据源收集过来，再送到目的地。为了保证输送一定成功，在送到目的地之前，会先缓存数据，待数据真正到达目的地后，删除自己缓存的数据。
Flume使用事务性的方式保证传送Event整个过程的可靠性。Sink必须在Event被存入Channel后，或者，已经被传达到下一站agent里，又或者，已经被存入外部数据目的地之后，才能把Event从Channel中remove掉。这样数据流里的event无论是在一个agent里还是多个agent之间流转，都能保证可靠，因为以上的事务保证了event会被成功存储起来。而Channel的多种实现在可恢复性上有不同的保证。也保证了event不同程度的可靠性。比如Flume支持在本地保存一份文件channel作为备份，而memory channel将event存在内存queue里，速度快，但丢失的话无法恢复。
具体看一下Transaction。Source和Sink封装了Channel提供的对Event的事务存、取接口，下图为一个transaction过程：

一个Channel的实现里会包括一个transaction的实现，每个与channel打交道的source和sink都得带有一个transaction对象。下面的例子中可以看到一个Event的状态和变化会在一次transation中完成。transaction的状态也对应了时序图中的各个状态。

Channelch=newMemoryChannel();
Transactiontxn=ch.getTransaction();
txn.begin();
try{
//ThistryclauseincludeswhateverChanneloperationsyouwanttodo

EventeventToStage=EventBuilder.withBody("HelloFlume!",
Charset.forName("UTF-8"));
ch.put(eventToStage);
//EventtakenEvent=ch.take();
//...
txn.commit();
}catch(Throwablet){
txn.rollback();

//Logexception,handleindividualexceptionsasneeded

//re-throwallErrors
if(tinstanceofError){
throw(Error)t;
}
}finally{
txn.close();
}

(全文完)