通過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 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 ）

在更壞的情況下，文件不同步或本地磁盤已滿，但是可以通過始終應使用的監視系統輕松解決這兩個問題。