AWS在2026年8月27日宣布，Amazon Redshift流式摄取现在支持来自Kinesis Data Streams的最大10MiB记录。此前单条记录上限为1MiB，这次提升10倍，与Kinesis新的最大记录能力保持一致。
设备遥测、变更数据捕获、机器学习特征和复杂JSON事件有时会超过1MiB。过去需要在生产端拆分消息，进入Redshift后再重新组合；新上限可以简化偶发大记录的传输，但不会把Kinesis变成适合持续发送10MiB消息的无限吞吐通道。
Redshift终于跟上Kinesis的10MiB记录能力
Kinesis已经允许把单条记录上限从默认1MiB调整到最高10MiB，但下游消费者必须逐一具备处理能力。Redshift这次补上直接流式摄取的大记录支持，避免超过1MiB的消息在数据仓库入口被拒绝。
该能力面向所有同时提供Amazon Redshift的商业AWS区域。现有Kinesis流默认最大记录仍是1MiB，需要主动修改流配置后才能发送更大的数据。
上限提高不代表所有消息都应该接近10MiB。小记录仍更容易均匀分布和控制延迟，大记录更适合少量、无法合理拆分的业务事件。
数据可以不经过S3直接进入物化视图
Redshift流式摄取会从Kinesis直接读取数据，写入专门配置的物化视图，不需要先把消息落到S3再执行批量加载。该流程同时适用于预置集群和Redshift Serverless工作组。
物化视图刷新时，Redshift从分配的Kinesis分片持续读取记录，并将JSON等数据映射到查询结构中。开启自动刷新后，流数据可以以较低延迟进入分析查询。
大JSON建议先使用JSON_PARSE转换为SUPER类型，再通过PartiQL提取字段。对每个字段反复调用JSON_EXTRACT_PATH_TEXT会重复解析同一记录，容易放大CPU与延迟开销。
分片持续吞吐并没有扩大10倍
Kinesis分片的持续写入上限仍为1MB/s，读取上限仍为2MB/s。10MiB记录依赖突发能力临时超过基础速率，发送后需要时间补充可用容量。
AWS建议把大于1MiB的记录控制在总体流量的2%以内。频繁发送大记录会消耗突发容量，让后续普通写入更容易被节流。
生产端应使用分布均匀的分区键，并为节流错误加入带随机抖动的指数退避重试。持续存在的大型负载更适合先放入S3，再通过消息传递对象位置，而不是把所有原始内容直接塞进Kinesis。
同一条流的其他消费者也必须兼容大记录
调整Kinesis流的最大记录只会放宽入口限制，不会自动升级Lambda、Firehose、自建消费者和第三方连接器。一个流同时扇出到多个服务时，需要逐项核对负载上限。
例如Lambda事件源映射的有效负载还受到6MiB限制，并且消息会经过Base64编码和附加元数据。超过下游限制的记录即使成功写入Kinesis，也可能在其他消费者处失败。
启用10MiB前必须完成端到端兼容测试。生产者、Kinesis、Redshift物化视图、失败处理和所有旁路消费者都能处理相同大小，才不会出现主数据仓库正常而其他链路静默丢失的情况。
上线后重点监控节流和扫描错误
Redshift会使用流、分片和序列号保证每条流记录只处理一次。无法摄取的记录会在SYS_STREAM_SCAN_ERRORS中留下错误信息，运维团队应为记录尺寸、解析和类型转换错误建立告警。
还应同时观察Kinesis写入节流、分片热点、物化视图刷新延迟、Redshift计算资源和查询等待。记录变大后，单条消息的解析成本和失败影响也会随之增加。
这次更新真正减少的是拆分与重组大事件的工程复杂度。合理控制大记录比例、均匀分区并保留失败重放机制，才能让10MiB上限带来便利，而不是把压力转移到流的下一个环节。
