我如何使用 DynamoDB TTL 和 AWS Lambda 设计零浪费的事件驱动分析管道

Source: Dev.to

问题陈述

是时候获取 Barx 生成的数据并把它交给理发师们了。我的第一个方案是创建一个每周一凌晨 3 点 UTC 运行的 cron 任务。当我的 Lambda 被触发时，我会在 DynamoDB 中搜索所有理发店，并为每一家开始分析计算。

基于 cron 的方法存在的问题

• 扫描整个 DynamoDB 表资源消耗大，成本高。
• 单个 Lambda 函数承担沉重工作负载，可能影响性能和可扩展性。
• 每周一，过程都会尝试检索所有理发店，无论它们是否有活动。
• 分析计算会对所有理发店执行，即使它们在上一周没有任何活动，导致不必要的资源消耗。

目标是 仅 对上周有活动的理发店消耗资源，并重新计算它们最近 7、30、60、90 天的分析数据。

架构方案

思考后，我构建了如下架构：

看起来很简单，但它让我只为那些有活动的理发店安排作业。我在 DynamoDB 中创建一条记录，该记录将在下周一凌晨 3 点 UTC 过期。当 TTL 规则删除该记录时，会触发另一个 Lambda，将该理发店的数据传递给专门用于其分析计算的 Lambda。

这种方式确保资源仅在产生数据的用户上消耗，而不是在闲置用户上浪费。

好处

• 分析计算仅针对最近有活动的理发店执行，优化资源使用。
• DynamoDB 中的计划记录会通过 TTL 自动清理，减少人工维护。
• 架构能够高效扩展，支持任意数量的用户而无需额外复杂性。

关注点

• 如果大量记录同时过期，可能会同时触发大量 Lambda，导致并发执行峰值。（可以通过配置 DynamoDB Stream 批量大小和并行因子来缓解。）
• 根据 DynamoDB Streams 服务的负载情况，计划的过期时间与实际触发 Lambda 之间可能会有延迟。（对我的使用场景来说是可以接受的，因为分析并不需要实时性。）

---

我分享这个想法是想获得社区的反馈。如果你有改进建议或替代方案，请在评论中告诉我！