Python：AWS Lambda 到 MySQL 错误 catching/handling
Python: AWS Lambda to MySQL error catching/handling
我有两个用 Python 编写的 Lambda 函数：
Lambda 函数 1：从 API 获取 'new' 数据，从 S3 存储桶（如果存在）获取 'old' 数据，比较新旧数据并创建 3 个不同的字典列表：插入、更新和删除。每个列表通过使用 RequestResponse 的 Lambda 调用分批传递给下一个 lambda 函数 (~6MB)。完整数据集的大小可以从数百万条记录到 1 条或 2 条记录不等。
Lambda 函数 2：分别处理每种类型的数据（插入、更新、删除）- 每种类型都会发生特定的事情，但最终每个批次都会使用 pymysql executemany.
我想不出处理错误的最佳方法。例如，假设正在写入的批次之一包含一条记录，该记录的字段值 NULL 在数据库中不允许为 NULL。整个批次都失败了，我无法弄清楚哪些写入了数据库，哪些没有写入该批次。理想情况下，会触发一个通知，并将恶意记录写在可以人工审查的地方——所有其他记录都会被成功写入
理想情况下，我可以使用 Kinesis Firehose 中可用的 Bisect Batch on Function Failure 之类的东西。它将递归地将失败的批次拆分为更小的批次并重试它们，直到它隔离了有问题的记录。如果配置了一个，这些将被发送到 DLQ。但是，我认为 Kenesis Firehose 对我不起作用，因为它不写入 RDS，因此不知道哪些记录失败。
这个来自 S3 的人 suggested using execute if executemany fails. Not sure if that will work for the larger batches. But perhaps if I stream the data 而不是通过 RequestResponse 调用这可行吗？
此 article（AWS Lambda 批处理）讨论了从 Lambda 到 SQS、Lambda 再到 RDS，但我不确定在这种情况下您可以如何具体处理错误。您必须一次发送一条记录吗？
这个 blog 使用了类似的东西，但我仍然不确定如何针对我的用例调整它，或者这是否是最好的解决方案。
以我能得到的任何形式寻求帮助；想法、博客文章、教程、视频等
谢谢！
我确实有一些侧重于组织、调试和弹性的建议 - 请记住正在对您的体系结构做出假设
组织
您目前有多个 dependent lambda 正在处理数据。当您有这样的处理流程时，您尝试处理的内容的复杂性决定了您是否需要使用编排工具。
我建议通过 AWS Step Functions
编排你的 lambda
调试
在应用程序级别 - 记录任何非 PII
现在您正在使用编排工具，如果不满足下一步的条件
，请适当地使用error handling of Step Functions along with any business logic in the application to error
弹性
生活变了，事情变坏了，不正确的代码被推送
设计您的业务流程，将您的 lambda 接收到的失败事件放入处理队列（AWS SQS、Kafka 等）——您可以重新处理您的事件，或者如果事件有问题，则对它们进行 DLQ。
这是一个很好的 article 关于在设计用例中使用编排的文章 - 读一读
我有两个用 Python 编写的 Lambda 函数：
Lambda 函数 1：从 API 获取 'new' 数据，从 S3 存储桶（如果存在）获取 'old' 数据，比较新旧数据并创建 3 个不同的字典列表：插入、更新和删除。每个列表通过使用 RequestResponse 的 Lambda 调用分批传递给下一个 lambda 函数 (~6MB)。完整数据集的大小可以从数百万条记录到 1 条或 2 条记录不等。
Lambda 函数 2：分别处理每种类型的数据（插入、更新、删除）- 每种类型都会发生特定的事情，但最终每个批次都会使用 pymysql executemany.
我想不出处理错误的最佳方法。例如，假设正在写入的批次之一包含一条记录，该记录的字段值 NULL 在数据库中不允许为 NULL。整个批次都失败了，我无法弄清楚哪些写入了数据库，哪些没有写入该批次。理想情况下，会触发一个通知，并将恶意记录写在可以人工审查的地方——所有其他记录都会被成功写入
理想情况下，我可以使用 Kinesis Firehose 中可用的 Bisect Batch on Function Failure 之类的东西。它将递归地将失败的批次拆分为更小的批次并重试它们，直到它隔离了有问题的记录。如果配置了一个，这些将被发送到 DLQ。但是，我认为 Kenesis Firehose 对我不起作用，因为它不写入 RDS，因此不知道哪些记录失败。
这个来自 S3 的人 suggested using execute if executemany fails. Not sure if that will work for the larger batches. But perhaps if I stream the data 而不是通过 RequestResponse 调用这可行吗？
此 article（AWS Lambda 批处理）讨论了从 Lambda 到 SQS、Lambda 再到 RDS，但我不确定在这种情况下您可以如何具体处理错误。您必须一次发送一条记录吗？
这个 blog 使用了类似的东西，但我仍然不确定如何针对我的用例调整它，或者这是否是最好的解决方案。
以我能得到的任何形式寻求帮助；想法、博客文章、教程、视频等
谢谢！
我确实有一些侧重于组织、调试和弹性的建议 - 请记住正在对您的体系结构做出假设
组织
您目前有多个 dependent lambda 正在处理数据。当您有这样的处理流程时，您尝试处理的内容的复杂性决定了您是否需要使用编排工具。
我建议通过 AWS Step Functions
编排你的 lambda调试
在应用程序级别 - 记录任何非 PII
现在您正在使用编排工具，如果不满足下一步的条件
，请适当地使用error handling of Step Functions along with any business logic in the application to error弹性
生活变了，事情变坏了，不正确的代码被推送
设计您的业务流程，将您的 lambda 接收到的失败事件放入处理队列（AWS SQS、Kafka 等）——您可以重新处理您的事件，或者如果事件有问题，则对它们进行 DLQ。
这是一个很好的 article 关于在设计用例中使用编排的文章 - 读一读