Firehose 数据管道限制

Question

我的用例如下：我有 JSON 数据需要以 parquet 格式存储在 S3 中。到目前为止一切顺利，我可以在 Glue 中创建一个架构并将“DataFormatConversionConfiguration”附加到我的 Firehose 流。但数据来自不同的“主题”。每个主题都有一个特定的“模式”。根据我的理解，我将必须创建多个消防流，因为一个流只能有一个模式。但我有数千个这样的主题，其中有大量高吞吐量的数据传入。创建如此多的 Firehose 资源看起来并不可行（https://docs.aws.amazon.com/firehose/latest/dev/limits.html）

我应该如何构建我的管道。

Answer 1

海事组织你可以：

• 要求升级您的 Firehose 限制，并使用 1 个 Firehose/流 + 添加 Lambda 转换来将数据转换为通用模式 - IMO 不具有成本效益，但您应该看到您的负载。

• 为每个 Kinesis 数据流创建一个 Lambda，将每个事件转换为由单个 Firehose 管理的架构，最后可以使用 Firehose API 将事件直接发送到您的 Firehose 流https://docs.aws.amazon.com/firehose/ latest/APIReference/API_PutRecord.html（请参阅“问：如何将数据添加到我的 Amazon Kinesis Data Firehose 传输流？”此处https://aws.amazon.com/kinesis/data-firehose/faqs/） - 而且，之前检查一下成本，因为即使您的 Lambda 是“按需”调用的，您也可能会在很长一段时间内调用很多它们。

• 使用其中一种数据处理框架（Apache Spark、Apache Flink 等）并以 1 小时为单位从 Kinesis 中批量读取数据，每次从上次终止时开始 --> 使用可用的接收器来转换数据并将其写入采用镶木地板格式。该框架使用检查点的概念并将最后处理的偏移量存储在外部存储中。现在，如果您每小时重新启动它们，它们将开始直接从上次看到的条目读取数据。- 它可能具有成本效益，特别是如果您考虑使用竞价实例。另一方面，与之前的两个解决方案相比，它需要更多的编码，并且显然可能具有更高的延迟。

希望有帮助。您可以对所选解决方案提供反馈吗？