12

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

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

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

在此处输入图像描述

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

两个问题：

  • 有没有办法告诉 Kinesis 将旧文件组合/连接在一起。（例如，超过 24 小时的文件每天被分组为一个块）。
  • COPY从大量 s3 文件而不是少数几个 s3 文件时，COPY redshift 性能有何影响？我没有精确地测量过这个，但根据我的经验，很多小文件的性能要差得多。据我所知，使用大文件时，大约 2M 行的 COPY 大约需要 1 分钟。2M 行包含大量小文件（约 11k 个文件），最多需要 30 分钟。

我的两个主要担忧是：

  • 更好的 redshift COPY 性能（来自 s3）
  • 更轻松的整体 s3 文件管理（备份、任何类型的操作）
4

3 回答 3

7

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

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

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

于 2016-04-28T20:48:10.880 回答
2

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

该服务的客户还为更长的历史查询准备数据是很常见的。即使可以在 Redshift 上运行这些长期查询，对这些查询使用 EMR 也可能有意义。然后，您可以针对最近更受欢迎的事件调整您的 Redshift 集群（例如，SSD 上的“热”集群 3 个月，HDD 上的“冷”集群 1 年）。

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

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

于 2016-05-01T02:59:46.353 回答
1

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

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 流可以容纳的批次数。

希望这可以帮助。

于 2016-05-19T08:35:40.480 回答