Q52 — AWS SAA-C03 第17章

第 52/89 题 | ← 返回第17章

Q1352. 一家公司使用 Amazon Kinesis Data Streams 和 AWS Lambda 函数处理流数据。这些流数据来自连接到互联网的设备。该公司正面临扩展性问题，需要实施分片级控制和自定义检查点机制。哪种解决方案能在满足这些要求的同时，将延迟降到最低?

• A. 将 Kinesis Data Streams 连接到 Amazon Data Firehose，以将传入数据导入 Amazon S3 存储桶。配置 S3 事件通知以调用 Lambda 函数。
• B. 公司处理 Lambda 函数的预置并发设置。将数据从 Kinesis Data Streams 流式传输到 Amazon SQS 标准队列。调用 Lambda 函数处理消息。
• C. 在运行于 AWS Fargate 上的 Amazon ECS 容器中运行 Lambda 函数代码。修改代码以使用 Kinesis 客户端库 (KCL)。 ✓
• D. 增加 Lambda 函数的内存和预置并发设置。将数据从 Kinesis Data Streams 流式传输到 Amazon SQS FIFO 队列。配置 Lambda 函数以由 SQS 队列调用。

正确答案: C. 在运行于 AWS Fargate 上的 Amazon ECS 容器中运行 Lambda 函数代码。修改代码以使用 Kinesis 客户端库 (KCL)。

解析

正确答案是 C。在运行于 AWS Fargate 上的 Amazon ECS 容器中运行 Lambda 函数代码。修改代码以使用 Kinesis 客户端库 (KCL)。解释:要求如下:分片级控制（能够管理每个分片的数据处理方式）。自定义检查点（手动控制流中的进度跟踪）。最低延迟（处理流式数据时的延迟最小）。为什么选项 C 正确:Kinesis客户端库（KCL）提供:分片级控制:KCL 允许应用程序处理来自各个分片的数据，从而实现对并行性和负载分配的细粒度控制。自定义检查点:KCL 允许您手动提交检查点（而不是依赖 Lambda 的自动检查点机制），从而确保精确一次处理语义。低延迟:在 AWS Fargate（无服务器容器）中运行基于 KCL 的应用程序，避免了 Lambda 冷启动的开销，并提供稳定的性能。其他选项错误的原因:A. 将 Kinesis 数据流连接到 Amazon Kinesis Data Firehose S3 Lambda（S3 事件通知）错误:高延迟:Firehose 会先将数据分批处理，然后再将其发送到 S3，从而引入延迟。缺乏分片级控制:Firehose 抽象化了分片管理。无需自定义检查点:Firehose 会自动处理检查点。B. 在 Kinesis 和 Lambda 之间使用 SQS 标准队列错误:无法进行分片级控制:SQS 将消息与 Kinesis 分片解耦，导致分片上下文丢失。无法进行自定义检查点:Lambda 的 SQS 集成会自动处理检查点。延迟更高:引入了额外的跳转（Kinesis、SQS 和 Lambda）。D. 在 Kinesis 和 Lambda 之间使用 SQS FIFO 队列（并配置并发）错误:无法进行分片级控制:FIFO 队列不保留分片信息。无法自定义检查点:Lambda 的 SQS 集成会自动处理检查点。延迟较高:FIFO 队列强制执行顺序，会增加延迟（即使比 Firehose 的延迟小）。关键考虑因素:Lambda 的局限性:Lambda 自动进行检查点设置（无需自定义控制）。没有直接的分片级处理（Lambda 从分片读取数据，但不能管理分片）。冷启动可能会引入延迟。KCL的优势:以长时间运行的进程运行（无需冷启动）。对分片分配和检查点进行显式控制。最适合低延迟、精确一次处理需求。正确架构（选项 C）:Kinesis Data Streams (KCL) 应用程序在 Fargate 上运行KCL 工作进程处理来自分配分片的数据。自定义检查点确保手动跟踪进度。Fargate 提供可扩展、低延迟的执行。结论:选项C是唯一满足所有要求的方案:分片级控制（通过 KCL）。自定义检查点（手动 KCL 检查点）。延迟最低（Fargate 避免了 Lambda 冷启动）。其他选项由于延迟较高、缺乏分片控制或没有自定义检查点而失败。