[英]Write event with flume to S3 via HDFS Sink ensure transaction
我们正在使用flume和S3来存储事件。 我认识到,仅当HDFS接收器滚动到下一个文件或水槽正常关闭时,事件才会转移到S3。
在我看来,这可能导致潜在的数据丢失。 Flume文档写道:
... Flume使用事务性方法来确保事件的可靠传递...
这是我的配置:
agent.sinks.defaultSink.type = HDFSEventSink
agent.sinks.defaultSink.hdfs.fileType = DataStream
agent.sinks.defaultSink.channel = fileChannel
agent.sinks.defaultSink.serializer = avro_event
agent.sinks.defaultSink.serializer.compressionCodec = snappy
agent.sinks.defaultSink.hdfs.path = s3n://testS3Bucket/%Y/%m/%d
agent.sinks.defaultSink.hdfs.filePrefix = events
agent.sinks.defaultSink.hdfs.rollInterval = 3600
agent.sinks.defaultSink.hdfs.rollCount = 0
agent.sinks.defaultSink.hdfs.rollSize = 262144000
agent.sinks.defaultSink.hdfs.batchSize = 10000
agent.sinks.defaultSink.hdfs.useLocalTimeStamp = true
#### CHANNELS ####
agent.channels.fileChannel.type = file
agent.channels.fileChannel.capacity = 1000000
agent.channels.fileChannel.transactionCapacity = 10000
我认为我做错了什么,有什么想法吗?
经过一番调查,我发现将S3与水槽和HDFS Sink一起使用是主要问题之一。
普通HDFS与S3实现之间的主要区别之一是S3不直接支持重命名。 在S3中重命名文件后,该文件将被复制并更改为新名称,而旧文件将被删除。 (请参阅: 如何在Amazon S3中重命名文件和文件夹? )
默认情况下,当文件未满时,Flume使用.tmp扩展文件。 旋转后,文件将重命名为最终文件名。 在HDFS中这不会有问题,但是在S3中会根据此问题导致问题: https : //issues.apache.org/jira/browse/FLUME-2445
因为具有HDFS接收器接缝的S3并非100%可信赖,所以我更倾向于使用更安全的方式将所有文件保存在本地,并使用aws工具s3 sync同步/删除完成的文件( http://docs.aws.amazon.com/cli/latest /reference/s3/sync.html )
在更坏的情况下,文件不同步或本地磁盘已满,但是可以通过始终应使用的监视系统轻松解决这两个问题。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.