Amazon Redshift Re-invented

AWS这篇论文太“干”了，都是功能点/技术点的罗列与总结，每个点说一下，其实每个点展开讲都可以至少是一篇短文。所以本文基本都是把论文原本翻译过来，做了很少的调整和总结。

What Is Redshift

Amazon Redshift是第一个完全托管的、PB级别的、企业级云数据仓库。Amazon Redshift使得使用现有商业智能工具高效分析大量数据变得简单且经济。这种云服务与传统的本地数据仓库解决方案相比具有显著的优势，后者昂贵、不具弹性，并且需要大量专业知识进行调优和操作。

• Amazon Redshift通过分层存储、多集群自动扩展、跨集群数据共享和AQUA查询加速层等创新，提高了存储和计算的可扩展性。
• 自主功能使Amazon Redshift更易于使用。亚马逊红移无服务器（Amazon Redshift Serverless）是自主功能的最终成果，使客户无需设置和管理数据仓库基础设施即可运行和扩展分析。
• Amazon Redshift通过与广泛的AWS生态系统集成，超越了传统数据仓库工作负载。例如，通过Spectrum在数据湖中进行查询、使用PartiQL进行半结构化数据摄取和查询、从Kinesis和MSK进行流式摄取、Redshift ML、对Aurora和RDS运营数据库进行联合查询以及联合物化视图等功能。

Why Redshift

Redshift的发展主要集中在满足以下四个主要客户需求。

• 客户要求高性能地执行越来越复杂的分析查询。Redshift通过创新的查询执行提供业界领先的数据仓库性能，即在每个查询片段（query fragment）中通过Codegen混合数据库算子（类似SparkSQL中的Whole Stage Codegen）。先进的技术，比如，预取和向量化执行，进一步提高了其效率。这使得Redshift在处理从几个TB的数据到PB级别时能够线性扩展。

• 随着客户的增长，他们需要处理更多的数据并扩展从数据中获取洞察的用户数量。Redshift将其存储和计算层解耦，以便根据不断变化的工作负载进行扩展。Redshift通过弹性地改变每个集群的大小来实现扩展，并通过多集群自动扩展来提高吞吐量，自动添加和删除计算集群以处理客户工作负载的峰值。用户可以从多个独立集群中消费相同的数据集。

• 客户希望Redshift更易于使用。为此，Redshift采用了基于机器学习的自动调优，根据客户工作负载的独特需求对每个集群进行微调。Redshift自动化了工作负载管理、物理调优和物化视图（MVs）的刷新，以及使用MVs重写查询的预处理。

• 客户希望Redshift能够与AWS生态系统和其他AWS定制服务无缝集成。Redshift为联合查询提供了事务型数据库（例如，DynamoDB和Aurora）、Amazon S3对象存储和Amazon Sagemaker的ML服务。通过Glue Elastic Views，客户可以在Redshift中创建物化视图，这些视图会在DynamoDB或Amazon OpenSearch的基表更新时递增刷新。Redshift还通过SUPER类型和PartiQL提供半结构化数据的摄取和查询。

How Redshift

Achitecture Overview

上图描述了Redshift的架构。Redshift集群由单个协调器（leader）节点和多个工作（worker）节点组成。数据存储在Redshift托管存储中（RMS，Redshift Managed Storage），由Amazon S3支持，并以压缩的列式格式在计算节点上的本地附加SSD上进行缓存。表格要么在每个计算节点上复制，要么分成多个桶，分布在所有计算节点之间。分区可以根据工作负载模式和数据特征自动派生，也可以根据表的分布键显式指定分区样式为轮询或哈希。

Amazon Redshift提供了广泛的性能和易用性功能，使客户能够专注于业务问题。

• 并发缩放（Concurrency Scaling）允许用户在需要更多处理能力以为数百个并发查询提供一致快速性能的情况下动态扩容（scale-out）。
• 数据共享（Data Sharing）允许客户在独立隔离的Amazon Redshift集群之间安全而轻松地共享读取数据。
• AQUA是一个查询加速层，利用FPGA提高性能。
• 编译即服务（Compilation-As-A-Service）是一个缓存微服务，用于优化在Redshift集群中执行的各种查询片段的生成代码。

除了使用JDBC/ODBC连接访问Redshift外，客户还可以使用Data API从任何基于Web服务的应用程序访问Redshift。数据API通过消除配置驱动程序和管理数据库连接的需要，简化了对Redshift的访问。相反，客户可以通过调用Data API提供的安全API端点来运行SQL命令。今天，Data API每天处理数百万个查询。

下图说明了查询通过Redshift的流程：

1. 查询首先由领导节点接收。
2. 然后进行解析、重写和优化。
3. Redshift的基于成本的优化器在其成本模型中包括集群的拓扑和计算节点之间数据移动的成本，以选择最佳计划。规划利用参与表的基础分布键来避免不必要的数据移动。例如，如果参与表的分布键相同，则所选计划通过为每个数据分区本地处理Join来避免任何数据移动。
4. 规划后，工作负载管理（WLM）组件控制对Redshift执行阶段的准入。一旦准入，优化的计划被分成单独的执行单元，这些单元要么以阻塞管道破坏操作结束，要么将最终结果返回给用户。这些单元按顺序执行，每个单元消耗先前执行单元的中间结果。对于每个单元，Redshift生成高度优化的C++代码，使用一个或多个（嵌套）循环交错多个查询运算符在管道中，编译它并将二进制文件发送到计算节点。
5. 列式数据从本地附加的SSD扫描或从Redshift托管存储中提取。

如果执行单元需要通过网络与其他计算节点交换数据，则执行单元由多个生成的二进制文件组成，以管道方式在网络上交换数据。每个Codegen生成的二进制文件都被调度在每个计算节点上，由固定数量的查询进程执行。每个查询进程在不同的数据子集上执行相同的代码。Redshift的执行引擎采用了许多优化来提高查询性能：

• 为了减少需要扫描的块数，Redshift利用zone map与谓词过滤，即包含每个块的最小/最大值的小哈希表，并利用延迟实例化。
• 在zone map过滤后需要扫描的数据被切成共享的工作单元并行执行。扫描利用vectorization和单指令多数据（SIMD）处理，以快速解压Redshift的轻量级压缩格式并有效地计算谓词表达式。
• 在构建哈希表时创建的Bloom过滤器应用于扫描，以进一步减少下游查询运算符需要处理的数据量。
• 预取技术被利用以更有效地利用哈希表。

Redshift的执行模型针对底层的Amazon EC2 Nitro硬件进行了优化，从而实现了业界领先的价格/性能比。图a展示了Redshift在价格/性能方面的竞争优势。它比较了Amazon Redshift和其他三个云数据仓库，并显示Amazon Redshift在未调整的3TB TPC-DS基准测试1上的性能比可以达到3倍。在所有云数据仓库都进行了调整后，Amazon Redshift的价格性能比比第二好的云数据仓库提供商高1.5倍。

客户数据快速增长，使得可扩展性成为首要任务。图b描述了在同时扩展数据集大小和硬件的情况下，调整TPC-DS基准测试的总执行时间。随着数据量从30TB到1PB的变化，Redshift的性能保持几乎不变，因为数据量与硬件的比例给定。这种线性扩展到PB级别使得客户更容易、可预测和成本效益地启动新的数据集和工作负载。

Code Generation

Redshift是一种专注于快速执行大量数据上复杂查询的分析数据库。Redshift生成针对查询计划和正在执行的模式的特定C++代码。然后编译生成的代码，并将二进制文件发送到计算节点以进行执行。每个编译文件称为一个segment，由一系列operators（称为steps）组成。每个segment（以及其中的每个step）都是物理查询计划的一部分。只有step的最后一步可以中断管道。

下面代码显示了查询SELECT sum(R.val) FROM R, S WHERE R.key = S.key AND R.val < 50在单节点集群上生成的简单scan->join->Agg查询的C++代码。该段包含扫描基表R的管道（第3-6行），应用filter（第8行），探测S的哈希表（第10行）和计算聚合sum()（第13行）。为简单起见，省略了从表S构建哈希表的段和最终段，以将计算节点上的部分总和组合并将结果返回给用户。生成的代码遵循将工作集尽可能靠近CPU以最大化性能的原则。因此，由管道中的多个运算符处理的每个tuple通常保留在CPU寄存器中，直到tuple通过网络发送，物化在主存储器中或刷新到磁盘中。

这种代码生成风格的主要特点是避免任何类型的解释代码，因为特定查询的所有运算符都是即时在代码中生成的。这与标准的Volcano执行模型相反，其中每个运算符都实现为迭代器，函数指针或虚函数在每个执行步骤中选择正确的运算符。代码生成模型以每个元组的吞吐量为代价提供了更高的吞吐量，这是由于必须为每个查询生成和编译代码而导致的延迟。Compilation Service节解释了Redshift如何减轻编译成本。

// Loop over the tuples of R.
while (scan_step -> has_next()) {
  // Get next value for R.key.
  auto field1 = fetcher1.get_next();
  // Get next value for R.val.
  auto field2 = fetcher2.get_next();
  // Apply predicate R.val < 50.
  if (field2 < constant1) {
  	// Hash R.key and probe the hashtable.
  	size_t h1 = hash(filed1) & (hashtable1_size - 1);
  	for (auto *p1 = hashtable1[h1]; p1 != nullptr; p1 = p1->next) {
      // Evaluate the join condition R.key = S.key.
      if (field1 == p1->filed1) sum1 += field2;
  	}
  }
}

Vectorized Scans

在图4的第4行和第6行，函数get_next()返回基表R相应字段的下一个值。这些函数是内联的，而不是虚函数，但本质上是基于拉取而不是推送的，因为基表的底层结构过于复杂，无法直接在生成的代码中表示。这种模型相对昂贵，因为它为每个扫描的列保留了大量状态，如果查询访问的列超过几个，就很容易耗尽CPU寄存器。此外，过滤谓词求值（第8行）涉及分支，如果某个谓词的选择性接近50％，则可能会产生分支错误预测成本，从而使管道停滞。最后，每个fetcher可能内联大量解压缩代码，这可能会显著减慢访问大量列的宽表的编译速度。

为了解决这些问题，Redshift在生成的代码中添加了一个SIMD向量化扫描层，该层访问数据块并将谓词求值为函数调用。与其余步骤即时编译代码不同，向量化扫描函数是预编译的，并覆盖所有数据类型及其支持的编码和压缩方案。该层的输出将符合谓词的元组的列值存储到堆栈上的本地数组中，由下游步骤访问。除了由于SIMD而导致的更快的扫描代码外，这还减少了寄存器压力和必须编译的内联代码量，从而使某些宽表上的某些查询编译速度快了数个数量级。

该设计将列按块执行的方式与下游的元组按行执行的方式相结合，用于Join和Aggregate步骤。在扫描步骤期间，按列处理的块的大小是根据正在访问的列的总宽度和线程专用（L2）CPU缓存的大小在代码生成期间动态确定的。

Reducing Memory Stalls with Prefetching

Redshift的流水线执行通过将中间列值保留在CPU寄存器中，避免了外部Join和Aggregate的中间结果的实例化。然而，在作为哈希join的一部分构建或探测哈希表时，或者在作为聚合的一部分探测和更新哈希表时，如果哈希表太大而无法适应CPU缓存，则Redshift会承担完整的缓存未命中开销。在这种基于推送的模型中，内存停顿很突出，可能会抵消join外部流的物化消除的成本。另一种选择是将输入分区，直到分区的哈希表适合于CPU缓存，从而避免任何缓存未命中。然而，这种模型对于执行引擎来说是不可行的，因为它可能无法将大型基表加载到内存中，因此无法使用记录标识符访问有效载荷列。相反，Redshift在流水线中的各个步骤之间传输所有所需的列，并在哈希表大于CPU缓存时承担缓存未命中的延迟。

由于缓存未命中是我们执行引擎设计的固有属性，因此使用预取来缓解停顿。预取机制集成在生成的代码中，并将哈希表或Bloom Filter中的每个探测与预取指令交错。Redshift在最快的（L1）CPU缓存中保留一个循环缓冲区，并为每个到达的元组预取并将其推入缓冲区。然后，较早的元组被弹出并向下推送到其余步骤。一旦缓冲区填满，而不是缓冲多个元组，单个元组通过从缓冲区中一次推送和弹出一个来进行处理。

这种模型将一些物化成本交换为缓存在CPU中的预取缓冲区的好处，以预取哈希表访问并减少内存停顿。如果哈希表大于CPU缓存，则我们发现这种权衡总是有益的。如果已知或预计哈希表足够小，可以适应CPU缓存，则不会生成此附加代码。如果元组太宽，将其存储在缓冲区中的成本比支付缓存未命中停顿更高，则也会发生相同的情况。另一方面，如果在同一流水线中存在多个Join和GroupBy Aggregate，则预取代码可能会在同一嵌套循环中生成多次，同时确保所有预取缓冲区的总大小足够小，以保留在最快的（L1）CPU缓存中。

Inline Expression Functions

虽然上面的示例涵盖了具有简单数据类型的Join和Aggregate的基本情况，但工业级数据库需要支持复杂的数据类型和表达式函数。生成的代码包括预编译的头文件和内联函数，用于所有基本操作，如哈希和字符串比较。出现在查询中的标量函数在生成的代码中转换为内联或常规函数调用，具体取决于查询的复杂性。这些函数中的大多数是标量函数，因为它们处理单个元组，但也可能在内部进行SIMD向量化。

在Redshift中，大多数字符串函数都使用针对特定函数的SIMD代码进行向量化。其中一个例子是使用Intel CPU中的pcmpestri指令的LIKE谓词，该指令允许在单个指令中进行多达16字节模式的子字符串匹配。类似地，诸如UPPER(), LOWER()和不区分大小写的字符串比较之类的函数使用SIMD代码加速ASCII路径，并仅在需要处理更复杂的Unicode字符时回退到（优化的）标量代码。这种优化在表达式函数中是普遍存在的，以最大化吞吐量。代码生成层在有利时内联关键路径上的函数调用。

Compilation Service

当将查询发送到Redshift时，查询处理引擎会编译用于查询执行的优化对象文件。当执行相同或类似的查询时，编译的段从集群代码编译缓存中重复使用，这会导致更快的运行时间，因为没有编译开销。虽然Redshift将查询编译的开销最小化，但第一组查询段仍然会产生额外的延迟。在某些情况下，即使是小的额外延迟也可能影响具有严格服务级别协议（SLA）的关键任务负载，特别是当需要编译大量段时，会增加对集群资源的争用。

编译服务使用超出Redshift集群的计算和内存资源，通过可扩展和安全的架构加速查询编译。编译服务将编译的对象缓存在集群外部的代码缓存中，以为可能需要相同查询段的多个计算集群提供服务。在查询处理期间，Redshift生成查询段，并利用外部编译服务的并行性来处理任何不在集群本地缓存或外部代码缓存中的段。随着编译服务缓存命中率从Amazon Redshift集群中的99.60％增加到99.95％。特别是，在87％的情况下，当集群本地代码缓存中不存在对象文件时，Redshift会在外部代码缓存中找到它。

CPU-Friendly Encoding

性能与CPU和磁盘使用密切相关。自然地，Redshift使用压缩来存储磁盘上的列。Redshift支持通用的面向字节的压缩算法，如LZO和ZSTD，以及优化的类型特定算法。其中一种压缩方案是最近的AZ64算法，它涵盖了数字和日期/时间数据类型。AZ64实现了与ZSTD相当的压缩率（比LZO更好的压缩率但稍微慢一些），但具有更快的解压缩速度。例如，当我们对AZ64支持的所有数据类型使用AZ64而不是LZO时，完整的3TB TPC-H运行可以提高42％。

Adaptive Execution

Redshift的执行引擎根据执行统计信息动态地更改生成的代码或运行时属性，以提高性能。例如，Redshift中的Bloom Filter的实现展示了动态优化的重要性。当在大表进行复制查询时，Join处理可能会在计算节点上传输大量数据造成由于内存有限而溢出到磁盘。这可能会导致网络，I/O瓶颈，从而影响查询性能。Redshift使用BF来提高此类Join的性能。BF可以有效地在源端过滤不符合Join关系的行，从而减少传输到网络或溢出到磁盘的数据量。

在运行时，Join操作根据已处理的确切数据量决定将用于构建BF的内存量。例如，如果Join将数据溢出到磁盘，则Join运算符可以决定构建更大的BF以实现更低的false-positive rates。这个决策增加了BFs的裁剪能力，并可能减少探测阶段的溢出。类似地，引擎在运行时监视每个BF的有效性，并在拒绝比例低时禁用它，因为过滤器会影响性能。执行引擎可以周期性重新启用BF，因为数据的时间模式可能使以前无效的BF变得有效。

AQUA for Amazon Redshift

高级查询加速器（AQUA）是一个多租户服务，作为Redshift RMS的集群外缓存层和complex scans和aggregations的下推加速器。AQUA在本地SSD上缓存热数据，避免从像Amazon S3这样的区域服务拉取数据的延迟，并减少了在Redshift计算节点中填充缓存存储的需求。为了避免引入网络瓶颈，该服务提供了一个功能接口，而不是存储接口。Redshift识别适用的scans和aggregations操作，并将它们推送到AQUA，AQUA根据缓存的数据处理它们并返回结果。本质上，AQUA是数据中心规模的带计算的存储。通过是多租户，AQUA有效地利用昂贵的资源，如SSD，并提供一个缓存服务，不受集群转换（如调整大小和暂停-恢复）的影响。

为了使AQUA尽可能快，我们设计了定制服务器，利用AWS的Nitro ASIC进行硬件加速压缩和加密，并利用FPGA进行高吞吐量的过滤和聚合操作执行。FPGA不是按查询编程的，而是用于实现包含数据库类型和操作的流水线原语的自定义多核VLIW处理器。服务的每个节点中的编译器将操作映射到本地CPU或加速器。这样做可以为可以在FPGA上高效执行的复杂操作提供显着的加速。

Query Rewriting Framework

Redshift具有一种基于DSL的新型查询重写框架（QRF），它具有多种用途：首先，它可以快速引入新的重写和优化，以便Redshift可以快速响应客户需求。特别是，QRF已用于引入重写规则，以优化Union、Join和Aggregate之间的执行顺序。此外，在查询去相关性过程中使用它，这在Redshift中非常重要，其执行模型受益于大规模Join，而不是暴力地重复执行子查询。

其次，QRF用于创建增量物化视图维护脚本并启用使用物化视图加速查询。QRF背后的关键直觉是，重写可以轻松地表示为一对模式匹配器，它匹配并提取查询表示（AST或代数）的部分，以及一个生成器，它使用模式匹配器提取的部分创建新的查询表示。QRF的概念简单性使得即使是实习生也能在几天内开发出复杂的去相关性重写。此外，它使Redshift能够引入与嵌套和半结构化数据处理相关的重写，并加快了物化视图范围的扩展。

SCALING STORAGE

亚马逊Redshift的存储层从内存到本地存储，再到云对象存储（Amazon S3），涵盖了所有数据生命周期操作，即提交（commit）、缓存（caching）、预取（prefetching）、快照/恢复（snapshot/recovery）、复制（replication）和容灾（disaster-recovery）。存储经历了一种有条不紊且谨慎部署的转变，以确保：

• 可持久性（durability）和可用性（availability），存储层基于Amazon S3，并在每次提交时将所有数据持久化到Amazon S3。基于Amazon S3使Redshift能够将数据与操作数据的计算集群解耦。这也使得数据具有持久性，并在其基础上构建架构以提高可用性。
• 可伸缩性（scalability），使用Amazon S3作为基础，可以实现几乎无限的扩展。Redshift托管存储（RMS）利用诸如数据块热度、数据块年龄和工作负载模式等优化功能，以自动优化性能并管理各存储层次之间的数据放置。
• 性能（performance），存储层扩展到内存和算法优化。它动态地预取和调整内存中的大小缓存，并将提交协议优化为增量。

Redshift Managed Storage

RMS的设计目标是在多个可用区（AZs）中实现年度的99.999999999%的可持久性和99.99%的可用性。RMS既管理用户数据，也管理事务元数据。RMS建立在AWS Nitro系统之上，该系统具有高带宽网络和与物理机（bare metal）性能无差别的特点。计算节点使用大型高性能SSD作为本地缓存。Redshift利用工作负载模式和技术，如自动细粒度数据驱逐（eviction）和智能数据预取，实现本地SSD的性能，同时将存储自动扩展到Amazon S3。

上图显示了从内存缓存到Amazon S3上已提交数据的RMS的关键组件。Amazon S3上的数据快照充当客户的逻辑还原点。Redshift支持从任何可用还原点恢复整个集群以及特定表。Amazon S3还是数据共享和机器学习的数据传输管道和真实源（source of truth）。RMS通过使用预取方案将数据块拉入内存并将其缓存到本地SSD来加速从S3访问数据。RMS调整缓存替换以通过跟踪对每个块的访问来保持相关块在本地可用。此信息还用于帮助客户决定扩展其集群是否有益。由于计算节点实际上是无状态的并且始终可以访问RMS中的数据块，因此RMS使原地集群调整大小成为纯元数据操作。由于数据可以直接摄入到Amazon S3，因此RMS具有元数据绑定和易于扩展的特点。RMS的分层特性使得SSD充当缓存，便于硬件更换。RMS支持的Redshift RA3实例今天可提供高达16PB的容量。可以动态更改内存磁盘缓存大小，以平衡查询的性能和内存需求。

表的数据被分区为数据切片，并存储为逻辑块链。每个数据块由其块头描述（例如，标识、表所有权和切片信息），并通过内存构造索引，称为超级块。超级块是一种类似于许多文件系统的索引结构。通过使用区域映射扫描超级块，查询可以访问相关的数据块。超级块还包含由活动查询拥有的数据块的查询跟踪信息。

RMS将事务同步提交到Amazon S3。这使得多个集群可以访问实时和事务一致的数据。通过数据批量写入并在同步屏障（synchronization barriers）下隐藏延迟，可以在不同的AZ之间写入Amazon S3。状态由一个集群拥有和管理，而并发读写在RMS之上提供了计算扩展。按需启动的并发集群依赖于快照隔离和按需获取数据的优先级，以满足查询请求。从主集群中删除的数据在所有读取引用清除后从Amazon S3中被垃圾回收。RMS使用TTL（time-to-live）和on-demand删除的组合来确保数据在事务回滚时不会泄漏。

由于数据始终在Amazon S3中备份，因此可以容忍本地SSD的丢失，确保数据的可持久性。Redshift提供了RPO=0的灾难恢复，其中在集群丢失或数据中心故障的情况下，可以将集群重新定位到相同或不同的AZ。

Decoupling Metadata from Data

将元数据与数据分离可以实现弹性调整和跨实例还原。这两个功能将元数据从一个集群配置shuffle到另一个集群配置，因此将元数据与数据分离可以实现高效的实现。弹性调整允许客户通过添加节点来在几分钟内重新配置其集群，以获得更好的性能和更多的存储空间，以满足要求高的工作负载，或通过删除节点来节省成本。跨实例还原允许用户将从一个实例类型的集群中的快照还原到不同实例类型或不同节点数的集群中。

Redshift实现了上述功能。首先，它确保数据的副本在Amazon S3中。这允许从真正罕见的事件（如多个硬件故障）中恢复。在任何重新配置之前，Redshift考虑集群中的数据，并生成一个计划，以最小化数据移动并产生平衡的集群。在重新配置之前，Redshift记录数据的计数和校验和，并在完成后验证正确性。在还原的情况下，Redshift记录表的数量、块的数量、行的数量、使用的字节数和数据分布，以及快照。它在接受新查询之前验证计数和校验和。

跨实例还原和调整利用弹性调整技术，在几分钟内提供迁移。弹性调整和跨实例还原都是广泛使用的功能，客户每月使用它们进行重新配置超过15,000次。故障率低于0.0001%。

Expand Beyond Local Capacity

Redshift通过使用Amazon S3扩展集群的存储容量并利用本地内存和SSD作为缓存来增强可扩展性。为了实现这一转变，进行了许多更改：升级超级块以支持更大的容量，修改本地布局以支持更多的元数据，修改快照的获取方式，转换如何重新填充和驱逐数据等。

• 层级存储

层级跟踪数据块的访问次数，以便每个集群在本地维护其工作集。它构建了一个two-level clock-based缓存替换策略，以跟踪存储在每个计算节点本地磁盘中的数据块。缓存策略将冷数据块B（即由客户查询首次访问）放置在low-level-clock缓存中，并在每次访问时增加B的引用计数。当B变热（即被多次访问）时，缓存策略将其提升到high-level-clock缓存中。在驱逐期间，时钟指针指向的每个块的引用计数都会减少。当B的引用计数为零时，B要么从high-level-clock降级到low-level-clock，要么从缓存中驱逐。

RMS使用分层存储缓存来驱动重新填充（即在本地SSD上缓存哪些数据）集群重新配置（例如，弹性调整、集群还原、硬件故障）后。在所有这些情况下，计算节点使用最有可能被客户查询访问的数据块来重新填充其本地磁盘。通过这种优化，客户的查询在20％重新填充完成时实现了超过80％的本地磁盘命中率。

• 动态磁盘缓存
  最后，为了提高性能，Redshift在分层存储缓存之上利用动态磁盘缓存来维护内存中最热门的块。此外，磁盘缓存还保留由查询创建的其他块，例如新数据块和特定查询的临时块。当有可用内存时，磁盘缓存会自动扩展，并在系统接近内存耗尽时主动缩小。这些变化导致基准测试和客户工作负载的性能提高了30％。

Incremental Commits

要将Amazon S3用作主要存储，需要进行增量提交以减少数据占用和成本。 RMS仅捕获自上次提交以来的确切数据更改，并相应地更新提交日志。持久数据结构也是增量更新的。Redshift的基于日志的提交协议取代了早期的写入重定向协议，将内存结构与持久化结构分离，其中持久化的超级块仅记录更改日志。基于日志的提交通过将一系列随机I/O转换为少量顺序日志附加，将提交性能提高了40％。由于RMS在多个AZ和区域提供持久且高可用的数据访问，因此元数据可以在全球分布式计算上共享和重放。这种基于日志的元数据降低了并发扩展和数据共享等功能的成本；这两个功能通过将日志应用于本地超级块来访问事务一致的数据。

Concurrency Control

Redshift实现了多版本并发控制（MVCC），其中读者既不阻塞也不被阻塞，而写者只能被其他并发写者阻塞。每个事务在其开始之前由所有已提交事务建立的数据库的一致快照中看到。Redshift强制执行可串行化隔离，从而避免数据异常，例如丢失更新和读写偏差[5,19]。因此，Redshift提供了业界领先的性能，而不会牺牲数据正确性，我们的客户无需分析工作负载是否应在较低的事务隔离级别上运行。

我们的旧版实现使用基于图形的机制来跟踪事务之间的依赖关系，以避免循环并强制执行串行化。这需要跟踪每个事务的单个状态，直到所有其他并发事务也提交为止。我们最近采用了一种基于序列安全网（SSN）的新设计，作为快照隔离的认证器[23]。这种基于启发式的设计允许我们以更节省内存的方式保证严格的串行化，仅使用先前提交的事务的摘要信息。如[23]所分析的那样，SSN算法是比可串行化快照隔离（SSI）[19]等可比算法更好的改进。对基础SSN算法进行了优化和增强，主要是为了向后兼容我们的旧认证器。这些增强包括在执行操作时中止某些事务，而不是像原始SSN设计一样在提交时执行计算。与旧设计相比，资源利用率显著降低。特别是，这个组件的内存占用量根据工作负载的不同可以减少多达8GB。

SCALING COMPUTE

每周，Redshift处理数十亿个查询，为具有不同性能要求的各种工作负载提供服务。ETL工作负载具有严格的延迟SLA，下游报告依赖于此。另一方面，交互式仪表板具有高并发要求，并且对响应时间非常敏感。最近，Redshift接入了一个客户工作负载，其中90％分位响应时间要求小于1秒。Redshift的工作负载模式已经发生了变化，我们的客户选择以下一个或多个计算扩展选项，以获得最佳的价格/性能来满足他们的需求。

Cluster Size Scaling

弹性调整允许客户根据当前的计算需求快速添加或删除计算节点。它是一种轻量级的元数据操作，不需要重新分配底层数据分布。相反，弹性调整重新组织数据分区分配，以确保调整大小后，所有计算节点在数据分区数量方面保持平衡。调整大小后，已移动的数据分区会在后台从S3重新填充；优先处理按需请求和热数据。由于数据分区重新分配，弹性调整后每个节点的数据分区数量与未调整大小的Redshift集群不同。为了在弹性调整后提供一致的查询性能，Redshift将计算并行性与数据分区分离。当计算并行性大于数据分区时，多个计算进程能够共享来自单个数据分区的工作。当数据分区多于计算并行性时，单个计算进程能够处理多个数据分区。Redshift通过生成可共享的工作单元[16,20]扫描Redshift表，并采用以计算节点为中心的查询操作符视图，在该视图中，计算节点的所有查询进程协作处理该节点上的所有数据分区。

Concurrency Scaling

并发扩展允许Redshift在用户需要比单个Redshift集群提供更多并发性时动态扩展。随着并发查询数量的增加，并发扩展会透明地处理工作负载的增加。使用并发扩展，客户维护一个单一的集群端点，向该端点提交查询。当分配的计算资源被充分利用并且新的查询开始排队时，Redshift会自动附加额外的并发扩展计算集群，并将排队的查询路由到它们。并发扩展集群从RMS重新填充数据。图6显示了Redshift在一年内在查询吞吐量与并发客户端数量方面实现的并发改进。使用的工作负载是3TB TPC-DS。Redshift为数百个并发客户端实现了线性查询吞吐量。

Compute Isolation

Redshift允许客户在不同的Redshift计算集群和AWS帐户之间安全、轻松地共享实时数据。这使得不同的计算集群可以在单个数据源上运行，并消除了维护数据副本的管道的复杂性。数据可以在许多级别上共享，例如模式、表、视图和用户定义的函数。为了访问生产者的数据，生产者集群必须首先创建一个数据共享，然后授予消费者访问权限。Redshift管理生成的元数据和IAM策略，以便在生产者和消费者之间进行共享的身份验证和授权。数据共享可以有任意数量的消费者集群。

当消费者集群查询共享对象时，会发出一个或多个元数据请求。只有在消费者集群被授权访问数据共享后，才能进行元数据请求。每个元数据请求都通过目录服务和代理层流动，这形成了生产者和数据共享的消费者之间的网络网格。代理在低延迟下执行请求的身份验证和授权，并将消费者元数据请求路由到适当的生产者，即使生产者已暂停也可以处理请求。消费者集群接收到元数据后，从RMS读取所需的数据块并执行查询。数据块在消费者集群上本地缓存。如果后续查询访问相同的数据块，则只要这些块尚未从消费者集群中删除，这些读取就会在本地提供服务。

AUTOMATED TUNING AND OPERATIONS

自从推出以来，Redshift的一个关键前提就是简单易用[13]。从早期开始，Redshift简化了传统数据仓库的许多方面，包括集群维护、修补、监控、调整大小、备份和加密。然而，仍然有一些例行维护任务和性能调节参数需要数据库管理员的专业知识。例如，客户必须安排维护任务（例如，vacuum）并决定性能参数，如分布键。为了缓解这种痛苦，Redshift大力投资于维护自动化和基于机器学习的自主性。

今天，Redshift在后台运行常见的维护任务，如vacuum、analyze或刷新材料化视图，而不会对客户工作负载产生任何性能影响。自动工作负载管理根据工作负载特征动态选择查询并发性和内存分配。此外，Redshift监视和分析客户工作负载，并识别性能改进的机会，例如通过自动应用分布和排序键建议来实现。此外，Redshift采用最先进的预测技术，以尽快为节点故障、集群恢复和并发扩展提供额外的节点，从而进一步提高查询延迟并减少停机时间。最后，Amazon Redshift提供了一种基于算法的无服务器选项，可以在几秒钟内运行和扩展分析，无需设置和管理数据仓库基础架构。

Automatic Table Optimizations

表属性，如分布键和排序键，允许Redshift客户优化其工作负载的性能。分布键有助于有效的联接和聚合；它们增加了并行性，并在查询所需的数据分布与底层表的物理分布匹配时，最小化了网络上的数据重分配。排序键有助于优化，如区域映射，并提高基于排序的操作（如合并联接）的效率。选择适当的分布和排序键并不总是容易的，通常需要详细的工作负载知识。此外，不断发展的工作负载可能需要重新配置物理布局。

现在，Redshift通过自动表优化（ATO）完全自动化了分布和排序键的选择和应用过程。ATO分析集群工作负载以生成分布和排序键建议，并提供工具，以便在用户表上无缝应用它们。ATO定期收集查询执行元数据，如优化的查询计划、基数和谓词选择性，以生成建议。此外，它估计每个建议的预期收益，并仅提供高度有益的建议。

分布键顾问专注于最小化给定工作负载的总网络成本。分布键不能孤立选择，而需要全面考虑参与工作负载的所有表。因此，ATO从工作负载中的所有联接构建加权联接图，然后选择最小化总网络分布成本的分布键[18]。类似地，排序键顾问专注于减少需要从磁盘检索的数据量。给定查询工作负载，ATO分析所有范围限制扫描操作的选择性，并推荐可以改善区域映射过滤（即数据块修剪）效果的排序键。

为了应用这些建议，Redshift向客户提供两个选项。首先，通过控制台，用户可以通过简单的DDL检查和手动应用建议。其次，自动后台工作程序定期应用有益的建议，而不影响客户工作负载的性能；这些工作程序在集群不繁忙时运行，并逐步应用建议，每当集群负载增加时就会减少。

上图(a)展示了ATO在一个5节点RA3.16xlarge实例上的有效性，该实例是从一个没有任何表中的分布或排序键的开箱即用的TPC-H 30TB数据集中派生出来的。TPC-H基准工作负载每30分钟在此实例上运行，我们测量端到端运行时间。随着时间的推移，越来越多的优化自动应用，减少了总的工作负载运行时间。在应用了所有建议之后，工作负载运行时间减少了23%（不包括由于编译而较高的第一次执行）。

AutomaticWorkload Management

允许查询执行对于同时执行的查询有广泛的影响。允许的查询过少会导致排队查询的高延迟和执行查询的资源利用率（例如CPU、I/O或内存）不佳。允许的查询过多会减少排队查询的数量，但会对资源利用率产生负面影响，因为资源过度饱和。例如，每个查询的内存过少会导致更多的查询溢出到磁盘，这对查询延迟产生负面影响。Redshift用于各种快速变化的工作负载，具有不同的资源需求。为了提高响应时间和吞吐量，Redshift采用机器学习技术来预测查询资源需求，并使用排队理论模型来调整同时执行的查询数量。

Redshift的自动工作负载管理器（AutoWLM）负责准入控制、调度和资源分配。当一个查询到达时，AutoWLM将其执行计划和优化器导出的统计信息转换为特征向量，该向量根据机器学习模型进行评估，以估计执行时间、内存消耗和编译时间等指标。基于这些特征，查询在执行队列中找到其位置。Redshift使用执行时间预测来安排短查询在长查询之前执行。如果查询的预估内存占用可以从查询内存池中分配，查询就可以继续执行。随着更多的查询被允许执行，AutoWLM使用基于排队理论的反馈机制监视集群资源的利用率。当利用率过高时，AutoWLM会限制并发级别，以防止由于过度饱和的查询资源而导致查询延迟增加。

上图(b)展示了AutoWLM在实际客户工作负载中的运行情况。AutoWLM能够根据查询到达的数量调整并发级别，从而实现最小排队和执行时间。在时间545，AutoWLM检测到当前并发级别的工作负载导致IO/CPU饱和，因此它降低了并发级别。这导致排队增加，因为新到达的查询不允许执行。为了避免这种排队，客户可以选择并发扩展（第4.2节）或定义查询优先级，以允许更重要的查询优先处理。

在准入控制期间，AutoWLM采用加权轮询方案，更频繁地调度高优先级查询而不是低优先级查询。此外，高优先级查询获得更大的硬件资源份额。当具有不同优先级的查询同时运行时，Redshift将CPU和I/O按指数递减的块进行划分，以降低优先级级别。这使得高优先级查询的加速程度呈指数级别，相对于低优先级查询而言。如果高优先级查询在低优先级查询开始执行后到达，AutoWLM会抢占（即中止和重新启动）低优先级查询以腾出空间。在存在多个低优先级查询的情况下，AutoWLM使用查询的预估执行时间抢占距离完成最远的查询。为了防止低优先级查询饥饿，每次抢占时降低查询被抢占的概率。即使如此，如果抢占太多查询，吞吐量也会受到影响。为了解决这个问题，如果浪费的工作比率（即由于抢占而失去的时间占总时间的比率）超过阈值，AutoWLM会防止抢占。由于查询优先级，当集群资源耗尽时，大多数低优先级查询将排队，以让更高优先级的工作负载满足其SLA。

Query Predictor Framework

AutoWLM依赖于机器学习模型来预测查询的内存消耗和执行时间。这些模型由Redshift的查询预测器框架维护。该框架在每个Redshift集群内运行。它收集训练数据，训练一个XGBOOST模型，并在需要时允许推理。这使得Redshift能够从工作负载中学习并自我调整以提高性能。在集群本身上拥有预测器有助于快速响应不断变化的工作负载，如果模型在集群外进行训练并仅在集群上用于推理，则不可能实现这一点。代码编译子系统也利用查询预测器框架在优化编译和调试编译之间进行选择，以提高整体查询响应时间。

Materialized Views

在数据仓库环境中，应用程序通常需要在大型表上执行复杂查询。处理这些查询可能会消耗大量的系统资源，以及计算结果所需的时间。物化视图（MVs）特别适用于加速可预测和重复的查询。Redshift通过三种方式自动化高效维护和使用MVs。首先，它增量维护物化视图中的过滤、投影、分组和联接，以反映基表上的更改。由于Redshift擅长批量操作，因此MV以延迟的方式维护，以确保事务工作负载不会减慢。

其次，Redshift可以自动化维护的时间。特别是，Redshift检测哪些MV已过时，并维护一个优先级队列，选择在后台维护哪些MV。刷新的优先级基于（1）查询工作负载中物化视图的效用和（2）刷新物化视图的成本。目标是最大化物化视图的整体性能收益。对于95%的MVs，Redshift在基表更改后的15分钟内使视图保持最新状态。

第三，Redshift用户可以直接查询MV，但他们也可以依赖Redshift的复杂基于MV的自动重写来重写基表上的查询，以使用最佳的合格物化视图来最优地回答查询。基于MV的自动重写是基于成本的，仅在重写后的查询预计比原始查询更快时才进行。对于聚合MV，自动重写查询对于50%的集群速度提高了2倍，对于25%的集群速度提高了5倍。MV增量维护和自动重写都在内部使用Redshift的新型基于DSL的查询重写框架，这使得Redshift团队能够不断扩展增量视图维护和自动重写的SQL范围。

SmartWarmpools, Gray Failure Detection and Auto-Remediation

在Redshift运行的规模下，硬件故障是常态，操作健康状况至关重要。多年来，Redshift团队已经开发了复杂的监控、遥测和自动修复机制。

Redshift使用智能暖池架构，可以快速替换故障节点，快速恢复暂停的集群，自动并发扩展，故障转移和许多其他关键操作。暖池是一组预先安装了软件和网络配置的EC2实例。Redshift为每个区域的每个AWS可用区维护一个独立的暖池。为了保证最佳的节点间通信，集群配置为来自相同可用区的计算节点。

保持所有上述操作的低延迟需要在从暖池获取节点时具有高命中率。为了保证高命中率，Redshift构建了一个机器学习模型，以预测任何时候给定暖池需要多少EC2实例。该系统动态调整每个区域和可用区的暖池，以节省基础设施成本而不影响延迟。

虽然故障停止故障相对容易检测，但灰色故障要困难得多[14]。对于灰色故障，Redshift开发了异常检测算法，可以自信地识别出表现不佳的组件（例如，慢磁盘、NIC等），并自动触发相应的修复操作。

Serverless Compute Experience

在自主性工作的基础上，我们推出了Redshift Serverless。Serverless依赖于自动化的算法来自动提供、调整和扩展Redshift计算资源。传统的Redshift为客户提供了许多调优选项，以优化他们的数据仓库环境（例如，实例类型、计算集群中的节点数、工作负载管理队列、扩展策略），而Serverless提供了接近零触碰的界面。客户只需支付查询运行的秒数。同时，Serverless保持了丰富的分析功能，如与广泛的AWS服务集成，我们将在下一节中讨论。

USING THE BEST TOOL FOR THE JOB

AWS提供多个专为特定目的构建的服务，即在其目标方面表现出色的服务。这些专为特定目的构建的服务包括可扩展的对象存储服务Amazon S3、事务性数据库服务（例如DynamoDB和Aurora）以及Amazon Sagemaker的ML服务。AWS和Redshift使其用户可以轻松地为每个作业使用最佳服务，并与Redshift无缝集成。本节介绍Redshift的主要集成点。

Data in Open File Formats in Amazon S3

除了RMS中的数据外，Redshift还可以通过名为Spectrum [8]的功能访问Amazon S3中的开放文件格式中的数据。Redshift Spectrum便于对数据湖进行百亿级别的分析，并且具有基于扫描数据量的按需计费，非常具有成本效益。Spectrum提供了大规模的扩展处理，可以在Parquet、Text、ORC和AVRO格式中执行数据扫描和聚合。Amazon维护了一组多租户Spectrum节点，并利用1:10的扇出比率从Redshift计算切片到Spectrum实例。这些节点在查询执行期间获取并随后释放。

为了利用Spectrum，Redshift客户在Hive Metastore、AWS Glue或AWS Lake Formation目录中注册其外部表。在查询计划期间，Spectrum表被本地化为临时表，以内部表示外部表。随后，查询被重写并隔离到Spectrum子查询中，以推送过滤器和聚合。通过S3列表或属于分区的清单，领导节点生成扫描范围。随着序列化计划，扫描范围被发送到计算节点。使用预签名的S3 URL向Spectrum实例发出异步Thrift请求以检索S3对象。为了加速重复的Spectrum查询，Redshift外部化了结果缓存，并增加了对外部表的物化视图支持，以进行完全刷新。

Redshift ML with Amazon Sagemaker

Redshift ML使数据分析师可以使用SQL轻松训练机器学习模型并执行预测（推理）。例如，用户可以使用Redshift中存在的客户保留数据训练流失检测模型，然后使用该模型进行预测，以便营销团队可以向有流失风险的客户提供激励措施。在内部，Redshift ML使用Amazon SageMaker，这是一个完全托管的机器学习服务。在模型训练完成后，Redshift提供了一个执行推理的SQL函数，可以直接在SQL查询中使用。

Redshift ML通过利用两个服务的优势来补充Sagemaker的提供。Redshift ML将模型带到数据而不是相反。这简化了机器学习流程，同时实现了大规模、成本效益高、基于数据库的预测。

图8说明了在Redshift中创建ML模型的流程。当客户初始化该过程时，Redshift ML使用抽样从Redshift集群中卸载适当数量的数据到S3文件夹中。随后，在Redshift AUTO训练模式下，Sagemaker Autopilot作业在幕后启动。它发现了最佳的预处理器、模型和超参数组合。为了使用此模型在本地执行ML推理，Redshift调用Amazon Sagemaker Neo服务来编译模型。Neo将Scikit-Learn库中的经典机器学习模型转换为推理代码。

OLTP Sources with Federated Query and Glue Elastic Views

Neo将多个步骤（预处理器、推理算法和后处理器）抽象为一个管道，用于执行完整的序列。Redshift将编译后的工件本地化并注册与创建的模型相对应的推理函数。在调用推理函数时，Redshift生成C++代码，加载并调用本地化模型。所有这些活动（发现最佳的预处理器、算法和超参数调整以及推理本地化）都是自动完成的。因此，用户可以在Redshift中获得专为特定目的构建的ML工具的好处。Redshift ML还可以在AUTO OFF模式下运行，其中用户控制预处理和算法/模型选择。首先，Redshift ML在AUTO OFF路径中引入了XGBoost和多层感知器。

为了保持使用最佳工具的真实性，Redshift还可以将推理委托给Sagemaker。这种能力对于垂直AI（例如情感分析）是必要的，并在需要时打开了使用专用GPU硬件的大门。

OLTP Sources with Federated Query and Glue Elastic Views

AWS提供专为OLTP定向的数据库服务，例如DynamoDB [10]、Aurora Postgres和Aurora MySQL [22]。AWS用户通过这些服务获得了顶级的OLTP性能，但通常需要使用Redshift分析收集的数据。Redshift通过使用Redshift的联合查询来促进在OLTP服务中发现的数据的原地查询，以及使用Glue Elastic Views将数据无缝复制和同步到Redshift。

用户从其OLTP数据库服务中摄取和/或查询实时数据的流行方法是通过Redshift联合查询，其中Redshift直接连接到客户的Postgres或MySQL实例并获取实时数据。联合查询实现了实时报告和分析以及简化的ETL处理，无需将数据从OLTP服务中提取到Amazon S3并在之后加载。

能够在单个查询中访问Redshift表和Postgres或MySQL表是有效的。它允许用户在其业务智能（BI）和报告应用程序中拥有新鲜的“union all”数据视图，包括空间数据[7]。此外，Redshift联合查询包括一个查询优化组件，用于确定执行联合查询的最有效方法，将带有过滤器和聚合的子查询发送到OLTP源数据库以加速查询性能并减少网络数据传输。请注意，这些子查询通常需要进行增强/转换，以确保它们在语义上是正确的，因为不同的DBMS系统可能具有略微不同的查询运算符语义。查询优化器还考虑了OLTP存储中可用的表和列统计信息，以进行查询计划。

Glue Elastic Views（GEV）与Redshift的集成促进并加速了从OLTP源到Redshift的数据摄取。GEV使得可以在AWS源上定义视图（从DynamoDB开始，稍后将添加其他源）。这些视图在PartiQL中定义，这是一种向后兼容SQL的语言，可以在有模式和无模式源上操作。GEV提供了视图更改的日志，即插入和删除更改的流。因此，用户可以定义反映GEV视图数据的Redshift物化视图；也就是说，在刷新时，Redshift物化视图会消耗从日志中接收到的插入和删除更改流。GEV视图解决了源和Redshift目标之间的类型不匹配和数据组织不匹配。GEV还通过将小型、高频事务缓冲到适合摄取到Redshift的较大批次中，解决了源和Redshift目标之间不同摄取强度之间的阻抗不匹配。

Redshift’s SUPER Schemaless Processing

Redshift通过推出SUPER半结构化类型提供了另一种高效、灵活且易于使用的摄取路径。SUPER类型可以包含无模式、嵌套数据。从技术上讲，SUPER类型的值通常由Redshift字符串和数字标量、数组和结构（也称为元组和对象）组成。该值上没有强制执行模式。例如，它可以是一个数组，其第一个元素是一个字符串，而第二个元素是一个双精度浮点数。SUPER的第一个用例是低延迟和灵活的JSON数据插入。Redshift INSERT支持快速解析JSON并将其存储为SUPER值。这些插入事务的操作速度比将SUPER属性分解为传统列的表中执行相同的插入操作快五倍。例如，假设传入的JSON的格式为{“a”:..，“b”:..，…}。用户可以通过将传入的JSON存储到具有单个SUPER列S的表TJ中，而不是存储到具有列‘a’、‘b’等的传统表TR中，来加速插入性能。当JSON中有数百个属性时，SUPER数据类型的性能优势变得非常显著，因为避免了写入放大。

此外，SUPER数据类型不需要常规模式，因此将无模式数据带入ELT处理不需要任何努力：用户无需在存储之前检查和清理传入的JSON。例如，假设传入的JSON包含一个具有字符串值和数字值的属性“c”。如果将“c”声明为varchar或decimal，数据摄取将失败。相反，使用SUPER数据类型，在摄取期间存储所有JSON数据而不会丢失信息。稍后，用户可以利用SQL的PartiQL扩展来分析信息。在用户将半结构化数据存储到SUPER数据值中之后，他们可以在不强制执行模式的情况下查询它。Redshift的动态类型提供了发现深度嵌套数据的能力，无需在查询之前强制执行模式。动态类型使得过滤、连接和聚合即使它们的参数没有统一的单一类型也成为可能。

最后，在无模式和半结构化数据进入SUPER后，用户可以创建PartiQL物化视图来检查数据并将其分解为物化视图。当函数接收到错误类型的参数时，Redshift PartiQL不会失败；它只是将特定函数调用的结果置为空。这与其作为清理半结构化数据的语言的角色相一致。使用分解数据的物化视图可以为经典分析案例提供性能和可用性优势。在对分解数据执行分析时，Amazon Redshift物化视图的列式组织提供更好的性能。此外，需要传统模式的用户和商业智能（BI）工具可以使用视图（物化或虚拟）作为数据的传统模式呈现。

Redshift with Lambda

Redshift支持创建由AWS Lambda代码支持的用户定义函数（UDF）。这使得客户可以与Redshift之外的外部组件集成，并实现以下用例：i）从外部数据存储或外部API进行数据增强，ii）使用外部提供程序进行数据屏蔽和标记化，iii）迁移使用C、C ++或Java编写的传统UDF。Redshift Lambda UDF旨在高效且安全地执行。Redshift集群中的每个数据切片批处理相关元组并并行调用Lambda函数。数据传输发生在一个单独的隔离网络上，客户端无法访问该网络。

CONCLUSION

总之，Amazon Redshift通过多项创新，如托管存储、并发缩放、数据共享和AQUA等，持续提高其行业领先的性能和可扩展性。同时，Amazon Redshift在易用性方面也有所提高：自动化工作负载管理、自动化表优化和使用物化视图的自动化查询重写使得其具有卓越的开箱即用的查询性能。此外，Redshift现在可以与其他数据（半结构化、空间）和多个专为AWS服务构建的服务进行接口交互。凭借不同的执行核心、能够扩展到数十PB的数据和数千个并发用户、基于ML的自动化使其易于使用以及与广泛的AWS生态系统的紧密集成，Amazon Redshift是云数据仓库的最佳解决方案；产品的创新正在以加速的速度继续进行。

References

• https://www.amazon.science/publications/amazon-redshift-re-invented
• https://aws.amazon.com/cn/blogs/aws/new-aqua-advanced-query-accelerator-for-amazon-redshift/
• https://docs.aws.amazon.com/redshift/latest/dg/c-using-spectrum.html#c-spectrum-overview
• https://www.techtarget.com/searchaws/definition/Amazon-Redshift-Spectrum