串連S3文件使用AWS流水

Question

時，我有一個AWS Kinesis流水流將數據放入S3具有以下配置：

S3 buffer size (MB)*  2 
S3 buffer interval (sec)* 60 

，一切工作正常。唯一的問題是Firehose爲每個數據塊創建一個s3文件。 （在我的情況下，每分鐘一個文件，如截圖中所示）。隨着時間的推移，這是很多文件：每天1440個文件，每年525k個文件。

這是很難管理（例如，如果我想水桶複製到另外一個我需要一個到每一個文件一個副本，這將需要時間）。

兩個問題：

• 有沒有辦法告訴室壁運動到組/串連舊文件一起。 （例如，超過24小時的文件會在一天內分組爲一塊）。
• 當從s3文件過多而不是幾個COPY的紅移性能受到影響？我還沒有精確地衡量這一點，但根據我的經驗，很多小文件的表現都非常糟糕。從我記得的情況來看，使用大文件時，大約2M行的COPY約爲1分鐘左右。 2M行有很多小文件（大約11k文件），需要長達30分鐘。

我的兩個主要問題是：

• 更好的紅移COPY演奏（S3）
• 更容易整體S3文件管理（備份，任何形式的操縱）

Answer 1

最簡單的爲您修復會增加firehose緩衝區大小和時間限制 - 您可以上升到15分鐘，這將每天將1440個文件減少到每天96個文件（除非您達到文件大小限制）。除此之外，Kinesis中沒有任何內容可以爲您爲您的文件進行連接，但您可以設置一個S3生命週期事件，每次創建一個新的Kinesis文件時觸發它，並將一些自己的代碼添加到（可能正在運行） EC2或者與Lambda一起無服務器）並自己進行連接。

無法評論紅移加載性能，但我懷疑這不是一個巨大的交易，如果它是 - 或將成爲一個，我懷疑AWS會做一些有關性能，因爲這是他們設置的使用模式。

Answer 2

Kinesis Firehose旨在允許近乎實時地處理事件。它針對這種使用情況進行了優化，因此您可以設置更小更頻繁的文件。通過這種方式，您可以更快地獲取Redshift中的查詢數據，或者更頻繁地調用小文件上的Lambda函數。

對於服務的客戶來說，爲較長的歷史查詢準備數據也很常見。即使可以在Redshift上運行這些長期查詢，對於這些查詢使用EMR也許是有意義的。然後，您可以保留Redshift羣集以適應最近流行的最新事件（例如，SSD上的「熱」羣集3個月，硬盤上的「冷」羣集1年）。

它是有道理的，你會採取較小（未壓縮？）文件存儲在Firehose輸出S3存儲桶中，並將它們轉移到更多的EMR（Hadoop/Spark/Presto）優化格式。您可以使用服務，如S3DistCp或類似的功能，將採取較小的文件，連接它們並將其格式轉換爲Parquet格式。

關於Redshift COPY的優化，您在聚合事件的時間和複製它們所花費的時間之間保持平衡。的確，在複製到Redshift時最好有更大的文件，因爲每個文件的開銷都很小。但另一方面，如果您每隔15分鐘複製一次數據，則可能會有「安靜」的時間表示您沒有利用網絡或集羣在這些COPY命令之間攝取事件的能力。你應該找到對業務有利的平衡點（你需要多少新鮮的事情）和技術方面（你每天可以攝取多少次事件給你的Redshift）。

Answer 3

我遇到了類似的問題，其中文件數量太多，無法處理。這裏有一個有用的解決方案：

i）將緩衝區大小增加到最大值。 （128 MB）

ii）將時間緩衝區增加到最大值。 （900秒）

iii）不是一次發佈一個記錄，而是一個俱樂部多個記錄（通過一條線分隔），製作一個kinesis消防記錄（KF記錄的最大尺寸爲：1000 KB ）。

iv）此外，俱樂部多重kinesis firehose記錄形成一個批次，然後做批處理。 （http://docs.aws.amazon.com/firehose/latest/APIReference/API_PutRecordBatch.html）

這將使一個s3對象發佈爲：kinesis流水線可容納的批處理數量。

希望這會有所幫助。