Amazon Redshift并发扩展工作机制及数据一致性相关问题咨询

1. 新增的并发扩展集群是如何创建的？ #

• 当你在主集群开启Concurrency Scaling功能后，Redshift会基于你的主集群节点类型、配置参数预先在后台维护一组暖备计算资源池，无需你手动操作EC2实例配置、存储挂载等底层资源操作。
• 当系统监测到主集群的工作负载队列存在排队等待的查询时，会在数秒内从暖备池分配和主集群配置匹配的计算资源，自动组装为并发扩展集群接入当前工作负载调度体系，不需要额外的集群初始化步骤。
• 并发扩展集群的生命周期完全由Redshift托管，当排队查询处理完成、集群负载回落后，系统会自动回收对应的计算资源，无需手动销毁。

2. 新创建的集群为什么能获取到最新数据？ #

官方文档描述的「用户始终能看到最新数据」基于Redshift的计算存储分离架构实现：

• 所有写入操作（INSERT/UPDATE/DELETE/COPY等）默认仅在主集群执行，写入的目标是Redshift托管的分布式共享持久存储层，而非绑定在单个计算节点的独立EBS磁盘，不存在数据分散在多套集群独立存储的情况。
• 写入操作完成后主集群会实时同步最新的元数据变更给所有在线的并发扩展集群，并发扩展集群处理查询时会直接访问共享存储层的最新数据，不需要做跨集群的数据同步。
• 并发扩展集群本身不绑定独立的持久化存储，所有读取请求都指向同一份共享存储的数据源，天然保证了数据一致性。

3. 该功能是否基于EBS节点快照实现？ #

该功能完全不依赖EBS节点快照机制，原因如下：

• EBS快照是单块EBS磁盘的时间点备份，存在分钟级的创建/恢复延迟，无法满足并发扩展集群数秒内启动、读取实时最新数据的需求。
• 并发扩展集群仅调度计算资源，全程不需要创建、恢复任何快照，也不会额外复制主集群的存储数据，运行成本仅和计算资源的使用时长挂钩。

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