Apache Flume - File通道设计

原文链接:https://blogs.apache.org/flume/entry/apache_flume_filechannel

说明:翻译在尽量符合原文表达的基础上,尽量保证行文流畅。水平有限,请多指正!

这篇文章是关于Flume FileChannel的。Flume是为高效收集聚合大量日志数据设计的可靠的、可用的分布式系统。它有一个基于流式数据流的简单灵活的体系。它提供了可控的可靠机制和许多故障转移与恢复机制。它使用了一个用于在线分析应用的简单可扩展的数据模型。

FileChannel是一个持久化的Flume channel,支持并行的写到多个磁盘并且支持加密。

概念
        当使用Flume时,每个流程都有一个Source、Channel、Sink。一个典型的例子是一个webserver通过RPC(比如:AvroSource)将events写到一个Source、然后Source将events写到MemoryChannel,最后HDFSSink消费event,将它写到HDFS。
                    
       MemoryChannel能提供很高的吞吐量,但是当系统断电或程序崩溃时会丢失数据。因此人们急需一个能持久化的Channel。FileChannel在FLUME-1085被实现。它的目标是提供一个可靠的高吞吐量的Channel。FileChannel保证当断电或崩溃发生时,事务被提交,没有数据丢失。
       重要的一点是FileChannel不做任何数据的复制,仅依赖于底层磁盘的可靠性,因此,由于持久性需要使用FileChannel的用户在购买和配置硬件时注意这一点。底层的磁盘将要做RAID、SAN或类似的东西。
       许多系统为了高的吞吐率需要拿允许小量数据丢失做交换。Flume组决定FileChannel采用不同的方式。Flume是一个支持事务的系统,多个event可以在单个事务中被put或take。batch size用来控制吞吐率。使用大的batch size,flume可以以高吞吐率移动数据,并且不丢失数据。batch size完全可以通过client控制。这个方法与DBMS
相似。
       一个flume事务包含put或take,一个事务中不能同时有put和take操作。每个事务都要实现put和take方法。source通过put将event放入channel,sink通过take将event从channel拿走。

设计
       FileChannel是基于内存队列和WAL设计的。每次事务都是根据事物类型(Take和Put)写到WAL,队列也做相应的修改。每次事务被commited,都会调用fsync确保events被存储在磁盘文件,同时指向该event的指针被放到队列中。这里的队列服务就像其他队列一样:它管理着什么被sink消费。在Take期间,该event的指针从队列被删除。直接从WAL读这个event。由于今天我们有大量可用的RAM,从操作系统的文件缓存中读取也是经常发生的。
       崩溃后,通过重放WALs,队列位置能恢复到崩溃前同样的状态,而那些没有commited的事务被丢弃。重放WALs相当耗时,因此队列本身会周期性的写到磁盘。将队列写到磁盘称为checkpoint。这样,崩溃后,队列首先从磁盘checkpoint文件加载,然后仅仅重放那些队列被最后一次checkpoint到磁盘后commited的事务,这样明显的减少了读取WAL的数量。
       例如,一个channel有2个event,如下所示:
      
       WALs包含3个重要的属性:事务ID、序列号、event数据。每个事务都有唯一的事务Id,并且每个event都有唯一的序列号。事务Id被用来简单的将event分组到同一事务,而序列号在重放log时使用。上图中,事务ID为1,序列号为1,2,3.
       当队列被checkpoint到磁盘,增加序列号,同时序列号也被保存到磁盘。重启时,队列首先从磁盘加载,然后比队列序列号大的任何WAL实体被重放。checkpoin操作期间,队列是locked,以至于没有Put或Take操作可以更改它的状态。如果checkpoint期间允许队列的修改,将导致磁盘存储的队列快照与实际队列不一致。
       在上面例子中,事务1commited后,checkpoint发生,在队列中的结果带着events被保存到磁盘还有序列号4也被保存。
       之后,在事务2中,从队列take一个event:
        
        如果这个时候崩溃了,重启时队列从checkpoint加载,注意,checkpoint发生在事务2前,2个event“a”和“b”都会被加载到队列,之后任何比4大的已经确认的事务被重放,重放后,“a”event从队列被删除。
       上面的设计2点没有考虑到,Take或Put进行中,同时发生checkpoint,会导致数据丢失。假定checkpoint发生在take“a”之后:
        
        如果此时崩溃,在以上描述的设计下,event“b”被加载进入队列,之后重放比5大的任何WAL实体,事务2被rollback,但是这里的take “a”不会被重放。event “a”被丢失,Put也存在相似的情况。由于这个原因,当队列的checkpoint发生时,仍然在处理中的事务也被写出,以至于可以适当的处理这个问题。
       

实现
       FileChannel在Flume项目的flume-file-channel模块,对应包名为org.apache.flume.channel.file。上面描述的队列对应FlumeEventQueue类,WAL对应Log类。队列本身是一个环形数组,通过内存映射文件支撑;而WAL对应一组文件,可以使用LogFile类和它的子类读写这些文件。
结论
       FileChannel在遇到硬件、软件、环境失败时,给Flume用户提供了持久化的保证,而且具有高的吞吐量。这两个方面对于大多数情况都是比较重要的,因此FileChannel是推荐使用的Channel。

没有更多推荐了,返回首页