Flume怎么保证数据传输的完整性

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/bocai8058/article/details/82954466
@Author  : Spinach | GHB
@Link    : http://blog.csdn.net/bocai8058

Flume的事物机制

Flume使用两个独立的事务分别负责从soucrce到channel,以及从channel到sink的事件传递。

比如:spooling directory source 为文件的每一行创建一个事件,一旦事务中所有的事件全部传递到channel且提交成功,那么source就将该文件标记为完成。同理,事务以类似的方式处理从channel到sink的传递过程,如果因为某种原因使得事件无法记录,那么事务将会回滚。且所有的事件都会保持到channel中,等待重新传递。

# example.conf: A single-node Flume configuration

# Name the components on this agent
a1.sources = r1
a1.channels = c1
a1.sinks = k1

# Describe/configure the source
a1.sources.r1.type = spooldir
a1.sources.r1.spoolDir = /home/ghb/HadoopCluster/Call
a1.sources.r1.fileHeader = true
a1.sources.r1.fileSuffix = .delete
a1.sources.r1.batchSize = 100

# Use file channel
a1.channels.c1.type = file 
a1.channels.c1.checkpointDir=/home/ghb/HadoopCluster/flume-1.6.0/checkpoint 
a1.channels.c1.dataDirs=/home/ghb/HadoopCluster/flume-1.6.0/dataDir

# Describe the sink
a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink
a1.sinks.k1.kafka.topic = CallLog
a1.sinks.k1.kafka.bootstrap.servers =127.0.0.1:6667
a1.sinks.k1.kafka.flumeBatchSize = 20
a1.sinks.k1.kafka.producer.acks=1

Flume的At-least-once提交方式

Flume的事务机制,总的来说,保证了source产生的每个事件都会传送到sink中。但是值得一说的是,实际上Flume作为高容量并行采集系统采用的是At-least-once(传统的企业系统采用的是exactly-once机制)提交方式,这样就造成每个source产生的事件至少到达sink一次,换句话说就是同一事件有可能重复到达。这样虽然看上去是一个缺陷,但是相比为了保证Flume能够可靠地将事件从source,channel传递到sink,这也是一个可以接受的权衡。如spooldir的使用,Flume会对已经处理完的数据进行标记。

Flume的批处理机制

为了提高效率,Flume尽可能的以事务为单位来处理事件,而不是逐一基于事件进行处理。比如上篇博客提到的spooling directory source以100行文本作为一个批次来读取(BatchSize属性来配置,类似数据库的批处理模式)。批处理的设置尤其有利于提高file channle的效率,这样整个事务只需要写入一次本地磁盘,或者调用一次fsync,速度回快很多。

channel配置说明

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

引用:https://blog.csdn.net/qq_26442553/article/details/79037298


猜你喜欢

转载自blog.csdn.net/bocai8058/article/details/82954466