Amazon web services 使用AWS Firehose时连接s3文件

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

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

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

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

两个问题：

• 有没有办法告诉Kinesis将旧文件分组/连接在一起。（例如，超过24小时的文件在一天内被分组成块）
• 当从过多的s3文件而不是仅从少数s3文件进行复制时，如何影响复制红移性能？我没有精确地衡量这一点，但根据我的经验，使用大量小文件的性能相当差。据我回忆，当使用大文件时，大约200万行的副本大约需要1分钟。200万行，包含大量小文件（~11k个文件），最多需要30分钟

我关注的两个主要问题是：

• 更好的红移复制性能（来自s3）
• 更方便的总体s3文件管理（备份、任何类型的操作）

---

对您来说，最简单的解决方法是增加消防软管缓冲区的大小和时间限制-您最多可以延长15分钟，这将把您每天1440个文件减少到每天96个文件（当然，除非您达到文件大小限制）

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

---

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

Kinesis Firehose旨在允许近实时处理事件。它针对这样的用例进行了优化，因此您可以设置更小、更频繁的文件。通过这种方式，您可以更快地获得红移查询的数据，或者更频繁地调用较小文件上的Lambda函数

服务的客户通常也会为较长的历史查询准备数据。即使可以在红移上运行这些长期查询，也可以使用EMR进行这些查询。然后，您可以针对最近更流行的事件调整红移群集（例如，SSD上的“热”群集持续3个月，HDD上的“冷”群集持续1年）

您可以在Firehose输出S3存储桶中获取较小（未压缩？）的文件，并将其传输到更为EMR（Hadoop/Spark/Presto）优化的格式。您可以使用服务，例如，或类似的函数，将较小的文件连接起来，并将其格式转换为一种格式

---

关于红移复制的优化，在聚合事件的时间和复制事件所需的时间之间有一个平衡。的确，当您复制到Redshift时，最好有更大的文件，因为每个文件的开销都很小。但另一方面，如果您仅每15分钟复制一次数据，则可能会有“安静”时间，您没有利用网络或集群的能力来接收这些复制命令之间的事件。你应该找到对业务有利的平衡点（你需要多新鲜的活动）和技术方面的平衡点（你可以在一小时/一天的红移时间内接收多少事件）。

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

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

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

iii）不是一次发布一条记录，而是将多条记录合并在一条记录中（通过一行分隔），以制作一条kinesis firehose记录（KF记录的最大大小为：1000 KB）

iv）此外，俱乐部多个动静消防水带记录形成一个批次，然后进行批量投放。（）

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

---

希望这有帮助。

是的。不幸的是，在我的情况下，我希望这些记录能尽快送达。我不能等待900秒，因为我需要半实时的新数据。因此，我正在考虑一种解决方案，将所有数据加载到redshift中，然后在单个（或仅几个）s3文件中一次性卸载所有数据。ii）根据需要保持AWS kinesis消防水带流设置。iii）因此，如问题所述，将有太多的文件。iv）现在，每当发布到bucket时，Lambda函数都会触发，将多个文件合并到一个bucket中，并将其放入另一个bucket中。如果您不想将其放入另一个bucket，可以将其放入具有不同前缀的同一个bucket中，这样它就不会再次触发lambda函数。这将更加简单。