我们使用flume和s3来存储我们的事件。我认识到，只有当hdfs接收器滚动到下一个文件或flume正常关闭时，事件才会传输到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我想我只是做错了什么，有什么想法吗？
1条答案
按热度按时间eyh26e7m1#
经过一些调查，我发现使用s3与Flume和hdfsFlume的主要问题之一。
普通hdfs和s3实现之间的主要区别之一是s3不直接支持重命名。当一个文件在s3中被重命名时，该文件将被复制到新名称，旧文件将被删除(参见：如何在amazons3中重命名文件和文件夹？）
默认情况下，flume在文件未满时使用.tmp扩展文件。旋转后，文件将重命名为最终文件名。在hdfs中，这不会有问题，但在s3中，这可能会根据以下问题导致问题：https://issues.apache.org/jira/browse/flume-2445
因为s3与hdfs不是100%可信，我更喜欢保存所有文件本地和同步/删除完成的文件与aws工具s3同步更安全的方式(http://docs.aws.amazon.com/cli/latest/reference/s3/sync.html)
在更糟糕的情况下，文件没有同步或本地磁盘已满，但这两个问题都可以通过一个无论如何都应该使用的监控系统轻松解决。