使用AWS Firehose时连接s3文件

Question

我有一个AWS Kinesis Firehose流，使用以下配置将数据放入s3：

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

一切正常。唯一的问题是Firehose为每个数据块创建一个s3文件。 （在我的例子中，每分钟一个文件，如截图中所示）。随着时间的推移，这是很多文件：每天1440个文件，每年525k文件。

这很难管理（例如，如果我想将存储桶复制到另一个存储桶，我需要逐个复制每个文件，这需要时间）。

两个问题：

• 有没有办法告诉Kinesis将旧文件分组/连接在一起。 （例如，超过24小时的文件被分组为一天的块）。
• 如果COPY来自过多的s3文件而不是少数几个，那么COPY红移性能如何受到影响？我没有准确地测量过这个，但根据我的经验，使用大量小文件的表现更糟糕。根据我的记忆，当使用大文件时，大约2M行的COPY约为1分钟。 2M行包含大量小文件（~11k文件），最多需要30分钟。

我的两个主要问题是：

• 更好的红移COPY表现（来自s3）
• 更轻松的整体s3文件管理（备份，操作任何类型）

Answer 1

最简单的解决方法是增加firehose缓冲区大小和时间限制 - 你可以最多15分钟，每天将你的1440个文件减少到每天96个文件（除非你达到文件大小当然有限制。）

除此之外，Kinesis中没有任何内容可以为您连接文件，但是您可以设置一个S3生命周期事件，每次创建新的Kinesis文件时都会触发该事件并添加一些您自己的代码（可能在EC2上运行）或者使用Lambda无服务器）并自己进行连接。

无法对redshift加载性能发表评论，但我怀疑这不是一个大问题，如果是 - 或将成为一个，我怀疑AWS会对性能做些什么，因为这是他们设置的使用模式。 / p>

Answer 2

Kinesis Firehose旨在实现近乎实时的事件处理。它针对此类用例进行了优化，因此您可以将文件设置为更小，更频繁的文件。这样，您可以更快地为Redshift中的查询获取数据，或者在较小的文件上更频繁地调用Lambda函数。

服务的客户也经常为更长的历史查询准备数据。即使可以在Redshift上运行这些长期查询，也可以将EMR用于这些查询。然后，您可以调整Redshift群集以适应更受欢迎的近期事件（例如，在SSD上使用＃34; hot＆＃34;群集3个月，以及在HDD上使用＃34;冷和＃34;群集1年） 。

有意义的是，您将在Firehose输出S3存储桶中获取较小的（未压缩的？）文件，并将它们传输到更多EMR（Hadoop / Spark / Presto）优化格式。您可以使用诸如S3DistCp之类的服务，或者使用较小文件的类似函数，将它们连接起来并将其格式转换为Parquet格式。

关于Redshift COPY的优化，在聚合事件的时间与复制它们所需的时间之间存在平衡。确实，复制到Redshift时最好有更大的文件，因为每个文件的开销很小。但另一方面，如果你每15分钟只复制一次数据，你可能会安静地＃34;您没有利用网络的时间或群集在这些COPY命令之间摄取事件的能力。您应该找到对业务有利的余额（您需要多大的新鲜事件）和技术方面（您可以在一小时/天内向Redshift中摄取多少事件）。

Answer 3

我遇到了类似的问题，文件数太多而无法处理。这是一个有用的解决方案：

i）将大小缓冲区增加到最大值。 （128 MB）

ii）将时间缓冲区增加到最大值。 （900秒）

iii）不是一次发布一条记录，而是将多条记录合二为一（用一条线分隔），制作一张kinesis firehose记录（KF记录的最大大小为：1000 KB）。

iv）此外，俱乐部多个kinesis firehose记录形成一批，然后进行批量投入。 （http://docs.aws.amazon.com/firehose/latest/APIReference/API_PutRecordBatch.html）

这将使一个s3对象发布为：kinesis firehose流可以容纳的批次数。

希望这有帮助。