含Python脚本调用Process Task的本地SSIS项目迁移AWS的方案咨询

你的方案完全可行 #

这套基于Lambda+数据库标志位轮询的方案，是不重构现有SSIS核心逻辑前提下，替代Process Task的合理选择，能满足后续任务依赖Python执行结果的需求。落地时需要注意几个关键细节：

• 轮询间隔设置：避免过于频繁的轮询增加数据库负载，建议根据Python任务的平均执行时长设置合理间隔（比如5-10分钟），同时在SSIS的循环容器中加入Delay任务控制轮询频率。
• 标志位的原子性设计：要确保Lambda设置标志位和SSIS读取标志位的操作不会出现竞态，比如用带UPDLOCK的SQL语句查询标志位，或者设置标志位时使用原子更新操作（如UPDATE ... SET flag = 1 WHERE task_id = ? AND flag = 0）。
• Lambda超时与异常处理：如果机器学习任务执行时间超过15分钟（Lambda最长运行时长），需要拆分任务或者改用AWS Batch；同时要在Lambda中添加异常捕获逻辑，执行失败时设置错误标志位，避免SSIS无限轮询。
• SSIS的错误分支处理：在循环容器中增加判断逻辑，当轮询次数超过阈值或检测到错误标志位时，触发SSIS的错误处理流程，避免任务挂起。

更优替代方案 #

1. 使用SSIS Script Task直接调用Lambda并同步等待 #

在SSIS中添加Script Task，通过AWS SDK（比如.NET版的AWSSDK.Lambda）调用Lambda的Invoke接口，并设置调用模式为同步（RequestResponse），这样Script Task会一直等待Lambda执行完成后再继续后续任务，省去轮询数据库的步骤：

• 优点：流程更简洁，无需额外维护数据库标志位，减少潜在的一致性问题。
• 注意：同样要考虑Lambda的超时限制，若任务超时长，需结合AWS Batch使用。

2. 改用AWS Batch执行Python任务 #

如果机器学习任务运行时间较长（超过15分钟），或者需要更多计算资源，AWS Batch比Lambda更适合：

• 在SSIS中通过Script Task或Execute SQL Task触发Batch作业，然后同样可以用轮询数据库标志位的方式等待作业完成（Batch作业完成后可以通过CloudWatch Events触发Lambda来更新标志位）。
• 优点：支持长时间运行的任务，可灵活配置计算资源，适合资源密集型的机器学习任务。

3. 将Python脚本整合到SSIS的Script Component（若适用） #

如果Python脚本的逻辑不依赖复杂的第三方库或大量计算资源，可以考虑将Python代码移植到SSIS的Script Component中（通过IronPython或在Script Task中调用本地Python环境），但这种方式仅适用于轻量级任务，且需要确保AWS上的SSIS运行环境支持Python。

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