解决Redshift ActiveStatementsExceededException并发INSERT报错问题

你当前的实现逻辑是每条记录单独调用一次execute_statement提交单条INSERT语句，当Kinesis扩容或开启单分片并发后，Lambda并发实例数上涨，同时发起的Redshift Data API活跃请求数超过了默认200的软配额，因此触发报错。

1. 优化SQL提交逻辑，优先使用批量写入 #

这是成本最低、效果最好的修复方案：

• 不要单条循环提交INSERT，把本次Lambda触发拿到的所有txs拼接成单条多值INSERT语句，单次调用即可完成整批数据写入，大幅降低statement调用量，示例逻辑如下：

# 示例批量拼接逻辑，实际使用时请做好值转义避免SQL注入风险
values = []
for tx in txs:
    # 按实际表字段拼接
    values.append(f"('{tx['col1_val']}', {tx['col2_val']}, '{tx['col3_val']}')")
batch_insert_sql = f"INSERT INTO target_table (col1, col2, col3) VALUES {','.join(values)}"

# 整批仅调用一次execute_statement
resp = client.execute_statement(
    ClusterIdentifier=redshift_cluster_id,
    Database=redshift_db,
    DbUser=redshift_user,
    Sql=batch_insert_sql
)

• 单批次数据量超过1000条的场景，推荐先把批量数据写入S3，再调用Redshift的COPY命令导入，性能比批量INSERT高10倍以上，还能避免SQL语句长度超限问题。

注意：Redshift是列存分析型数据库，天生不适合高频小批量单条写入，批量写入不仅能解决statement配额问题，还能减少小数据块生成，降低后续VACUUM运维压力，是Redshift写入的官方推荐最佳实践。

2. 适配Redshift Data API配额限制 #

• 给redshift-data客户端配置自适应重试策略，将ActiveStatementsExceededException自动纳入重试范围，搭配指数退避逻辑缓解瞬时峰值的配额冲突：

from botocore.config import Config

# 配置自适应重试，最大重试5次
client_config = Config(
    retries = {
        'max_attempts': 5,
        'mode': 'adaptive'
    }
)
client = boto3.client('redshift-data', config=client_config)

• 如果业务并发确实长期高于200，可以提交AWS支持工单申请提升Redshift Data API的活跃statement配额，200是软限制，可按需上调。

3. 调整上游触发配置降低并发 #

• 调大Kinesis触发Lambda的批处理大小（Batch size），默认值为100，最大可调整到10000，让单次Lambda处理更多数据，减少Lambda并发实例数量。
• 降低单分片并发数，可根据Redshift的配额倒推合理的并发上限，比如配额200的场景下，单分片并发建议不超过5，避免同时发起过多请求。

4. 长期架构优化 #

替换自定义Lambda写入逻辑，改用Kinesis Data Firehose直接对接Kinesis数据流和Redshift，Firehose内置批量攒批、重试、容错逻辑，可自动按配置的时间/大小阈值批量写入Redshift，不需要自行维护Data API调用逻辑，稳定性和性能都更高。

你问的「是否只能通过批量聚合实现并发写入」：不是唯一方案，比如你可以改用JDBC/ODBC驱动直连Redshift提交写入，走的是Redshift集群的连接配额，不是Data API的statement配额，但这种方式需要处理VPC访问、连接池管理等额外问题，而且即使换了写入方式，Redshift本身的架构特性也决定了批量写入的性能和稳定性远好于单条小批量写入，所以仍然优先推荐批量聚合的写入方式。

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