将大规模 pandas DataFrame 写入 Amazon Redshift 时，如果沿用传统数据库逐条插入的思路，往往会遭遇极差的性能和频繁的连接中断。Redshift 本质上是一个基于列存储的 MPP 数据仓库，它的写入路径与普通 OLTP 数据库完全不同，理解其底层加载机制是做对优化的前提。
为什么不能直接用 to_sql 批量写 Redshift
很多同学第一时间会想到用 SQLAlchemy 的 to_sql 方法，把 DataFrame 直接灌进 Redshift。这种做法在数据量小时尚可接受，但一旦达到几十万行以上，就会暴露出两个致命问题。第一，to_sql 默认会生成大量的 INSERT 语句，甚至逐行提交，而 Redshift 的节点间网络和设计初衷并不是处理海量小事务。第二，每一次 INSERT 都会在系统表里留下大量元数据开销，导致负载飙升且导入极慢。
从原理上看，Redshift 的存储引擎针对批量、顺序的列式写入做了高度优化，COPY 命令可以从 S3 并行读取文件并直接分发到计算节点。相比之下，通过 JDBC/ODBC 的 INSERT 流量要先经过 Leader 节点解析，再走内部网络重分布，效率天差地别。因此，任何超过数万行的 DataFrame 导入，都应放弃 to_sql，转向文件加 COPY 的模式。
核心方案：S3 暂存加 COPY 命令
最标准且被官方推荐的做法是，先把 DataFrame 导出为列式存储格式（如 Parquet）或压缩 CSV，上传到 S3 桶，然后执行 Redshift 的 COPY 命令完成加载。这样 Redshift 能以多节点并行方式拉取文件，几乎不占用 Leader 节点的写入带宽。
下面是一段将 DataFrame 以 Parquet 形式落地并借助 boto3 上传，再用 psycopg2 触发 COPY 的完整示例。注意代码中的小于号和大于号都已转义，符合规范。
import pandas as pd
import boto3
import psycopg2
from io import BytesIO
import pyarrow.parquet as pq
import pyarrow as pa
# 假设已有大量数据的 DataFrame
df = pd.DataFrame({
'user_id': range(1000000),
'score': [i * 1.5 for i in range(1000000)]
})
# 转为 pyarrow table 并写入内存字节流
table = pa.Table.from_pandas(df)
buf = BytesIO()
pq.write_table(table, buf, compression='snappy')
buf.seek(0)
# 上传到 S3
s3 = boto3.client('s3', region_name='us-east-1')
bucket = 'my-redshift-bucket'
key = 'load_data/df_parquet.parquet'
s3.put_object(Bucket=bucket, Key=key, Body=buf.read())
# 通过 COPY 命令导入 Redshift
conn = psycopg2.connect(
host='redshift-cluster.ipipp.com',
dbname='dev',
user='awsuser',
password='password',
port=5439
)
cur = conn.cursor()
copy_sql = """
COPY target_table
FROM 's3://my-redshift-bucket/load_data/df_parquet.parquet'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftCopyRole'
FORMAT AS PARQUET;
"""
cur.execute(copy_sql)
conn.commit()
cur.close()
conn.close()
上面的代码展示了端到端流程。使用 Parquet 不仅体积更小，而且列类型信息会被保留，Redshift 在 COPY 时无需做复杂的文本解析。如果出于兼容考虑使用 CSV，也应当开启 GZIP 压缩，并在 COPY 中声明 DELIMITER 和 GZIP 选项。
表结构设计对导入速度的影响
即便使用了 COPY，如果目标表没有合理设计分布键（DISTKEY）和排序键（SORTKEY），数据在加载时仍可能发生大量重分布。例如，将随机生成的 ID 作为 DISTKEY，可以让数据均匀分散到各个切片；而把常用时间字段设为 SORTKEY，则能在写入时按序落盘，减少后续 VACUUM 开销。
另外，建议临时关闭表的备份标记（对于测试数据可使用 BACKUP NO），并选择合适的数据类型以缩减存储。对于超大批量初始导入，还可以先建一个没有约束的临时表，COPY 完成后再 INSERT 到正式表，从而避免约束检查拖慢加载。
分块与并发策略
当 DataFrame 本身大到单机内存吃紧时，可以按行切片导出多个 Parquet 文件，再利用 Redshift 的并行 COPY 能力。每个文件大小控制在 1MB 到 1GB 之间为宜，过多的小文件反而会让 S3 列举和 Redshift 调度变慢。
示例中将 DataFrame 分块保存的写法如下：
chunk_size = 200000
for i, start in enumerate(range(0, len(df), chunk_size)):
sub = df.iloc[start:start + chunk_size]
table = pa.Table.from_pandas(sub)
out_key = f'load_data/df_chunk_{i}.parquet'
buf = BytesIO()
pq.write_table(table, buf, compression='snappy')
buf.seek(0)
s3.put_object(Bucket=bucket, Key=out_key, Body=buf.read())
# COPY 时使用通配符一次加载所有分块
copy_sql = """
COPY target_table
FROM 's3://my-redshift-bucket/load_data/df_chunk_*.parquet'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftCopyRole'
FORMAT AS PARQUET;
"""
这种写法既缓解了内存压力，又通过通配符让 Redshift 自动并行读取多个对象。配合多队列的负载管理（WLM）配置，导入吞吐可以进一步线性提升。
常见误区与避坑要点
一个常见误区是认为提高单条 INSERT 的批次大小就能解决问题。实际上 Redshift 的 INSERT 无论如何都绕不开行存封装，除非你使用官方 COPY，否则难以突破瓶颈。另一个坑是忘记收集统计信息，加载后应当运行 ANALYZE 让优化器感知新数据分布。
此外，网络连通性也常被忽视。如果本地环境到 S3 或 Redshift 的带宽有限，应当把导出与上传步骤放在同一 VPC 内的计算实例上执行，避免公网往返。通过综合应用上述实践，千万级 DataFrame 的导入可以从数小时压缩到分钟级。