如何借助Lambda实现AWS Kinesis Firehose数据写入DynamoDB

你提到的通过挂载Lambda实现Kinesis Firehose写入DynamoDB的方案完全可行，属于Firehose对接非原生支持目的地的标准实现方式，生产环境可用性有充分保障。

配置Firehose投递流时，目的地类型直接选择 Amazon S3 即可，不需要选择其他官方预置的目的地类型。

注意：不要误选目的地分类里的第三方服务或者其他分析类引擎选项，S3是所有自定义投递逻辑的基础兜底目的地，Firehose的数据转换、自定义处理能力都可以在S3目的地的配置链路中开启。

• 开启S3目的地配置页中的「数据转换」开关，绑定你自行开发的负责DynamoDB写入逻辑的Lambda函数，所有流入Firehose的数据会先批量传给该Lambda处理，再执行后续投递动作。
• Lambda的IAM角色需要提前配置两类权限：一是允许Firehose调用该函数的基础触发权限，二是目标DynamoDB表的写入权限，优先授予dynamodb:BatchWriteItem权限适配批量写入场景。
• 写入逻辑建议优先用批量写入接口降低请求成本：Firehose单批传给Lambda的记录最多可达1000条/6MB，注意DynamoDB单批写入最多支持25条记录的限制，需要在代码里做批次拆分，同时加入限流重试、异常捕获逻辑，应对DynamoDB的预置吞吐量突增、临时不可用等场景。
• 必须开启S3侧的失败记录备份配置：当Lambda执行超时、DynamoDB写入失败、权限配置异常时，Firehose会自动把处理失败的原始记录存到绑定的S3桶里，避免数据丢失。如果你不需要在S3留存全量业务数据，可以在Lambda代码中将处理完成的记录返回空内容，同时给S3桶配置1天过期的生命周期规则，几乎不会产生额外存储成本。
• Lambda超时时间建议配置为1分钟以上，和你设置的Firehose批处理窗口匹配，最长不要超过Firehose允许的5分钟函数执行上限，避免因函数超时导致投递链路阻塞。

内容的提问来源于stack exchange，提问作者Ronnie