通过HDFS Sink向S3写入带槽事件确保事务

Question

我们使用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

我想我只是做错了什么，有什么想法吗？

Answer 1

经过一些调查，我发现了一个主要的问题，使用S3与水槽和HDFS水槽。

普通HDFS与S3实现的主要区别之一是，S3不直接支持重命名。在S3中重命名文件时，文件将被复制到新名称中，旧文件将被删除。(见：How to rename files and folder in Amazon S3?)

默认情况下，当文件未满时，可以使用.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)保存所有本地文件和同步/删除完成的文件的更安全的方法。

更糟糕的是，文件没有同步，或者本地磁盘已满，但这两个问题都可以通过监控系统很容易地解决，而监控系统无论如何都应该使用。