Redshift导入Data Wrangler触发ValidationException报错问题排查

你遇到的节点报错和系统负载无直接关联，核心触发逻辑如下：

• 核心报错RedshiftQueryExecutionIdValidationError来自SageMaker Data Wrangler对接Redshift的默认缓存机制：Data Wrangler配置Redshift数据源时，默认通过Redshift Data API提交查询，Redshift侧对这类API提交的查询结果仅保留24小时，报错信息里的1655759552就是对应查询结果的过期Unix时间戳。当你间隔超过24小时再次打开数据流时，Data Wrangler不会自动重新提交查询，而是会尝试复用历史查询ID拉取已过期的结果，就会抛出该校验错误。你观察到的“当日未尽早打开就报错”，本质是前一天最后一次运行节点的时间到当日打开的时间差跨过了24小时缓存窗口，和当日系统负载高低没有因果关系。
• 其余节点持续卡在加载/校验状态：Data Wrangler的数据流节点按依赖关系串行校验，上游Redshift节点无法返回有效输出时，所有下游的转换、多表关联节点都会持续等待输入，不会推进执行流程。
• 偶发的too many inflight requests报错：属于API限流错误，节点卡滞时如果反复点击刷新、重跑节点，会短时间内向Redshift Data API、Data Wrangler服务提交大量重复请求，超过账户侧配置的同时间并发请求配额阈值就会触发该报错，和计算资源不足无关。

按优先级排序可采用以下方案解决问题，不需要盲目申请资源：

• 临时恢复操作：打开流遇到红叉报错时不要反复刷新避免触发限流，定位到最上游的Redshift数据源节点，手动触发单节点重跑，重新提交查询生成新的有效结果后，下游所有节点会自动依次完成校验，整个流即可恢复正常。
• 长效优化配置：
  • 开启Redshift节点的S3 staging缓存：配置数据源节点时，开启查询结果自动导出到指定S3路径的选项，首次查询完成后结果会持久化存储在S3，后续打开流会直接读取S3上的缓存数据，完全不受Redshift查询结果24小时过期规则限制，同时也能减少反复查询生产库带来的额外负载。
  • 配置节点定时刷新规则：给所有Redshift数据源节点设置间隔小于24小时的自动重跑策略，保证查询结果始终在有效期内，避免打开流时触发过期报错。
  • 你提到的提前裁剪冗余字段、减少拉取数据量的操作可以执行，但该操作仅能缩短单节点重跑耗时、降低触发限流的概率，无法解决缓存过期导致的核心报错。
  • 不需要额外申请提升Data Wrangler实例的计算、内存配置：该问题属于服务API缓存规则和限流类问题，和实例资源规格无关联，提升配置不会解决报错。

内容的提问来源于stack exchange，提问作者A. White