在Amazon Redshift的帮助下，客户得以顺利完成一系列业务指标，例如从减速现有数据库环境，到提取网络日志以进行大数据分析等等。Amazon Redshift是一套全托管PB级大规模并行数据仓库，领有极低的上手难度与杰出的性能体现。Amazon Redshift还提供凋谢的规范JDBC/ODBC驱动程序接口，供您间接对接现有商业智能（BI）工具并复用现有剖析查询方法。

  • Amazon Redshift
    https://aws.amazon.com/cn/red...

Amazon Redshift可能运行任意类型的数据模型，涵盖生产事务处理零碎第三范式模型、星型与雪花型模型、数据仓库以及各类简略的立体表等。

本文将向大家介绍如何在利用Amazon Redshift过程中实现性能优化，并针对各类优化形式做出深刻分析及操作领导。

  想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注2021亚马逊云科技中国峰会！点击图片报名吧～

内容更新

本文更新了2019年初公布的同名文章，旨在纳入一年多以来亚马逊云科技的各项最新进展，并将着重对其中要点做出论述。

查问吞吐量比查问并发性更为重要

配置并发性（如内存治理）能够通过Automatic WLM与Query Priorities队列优先级机制将并发能力引入Amazon Redshift的外部机器学习模型。在大规模生产集群当中，咱们看到自动化流程会为某些工作负载调配更多的流动语句，并对其余类型的用例调配较少流动语句。这种作法是为了最大水平进步吞吐量，保障Amazon Redshift集群可能在特定时段之内实现特定工作总量，例如实现每分钟300条查问，或者每小时解决1500条SQL语句等。本文倡议大家充分利用并发机制进步吞吐量，因为吞吐量正是对集群用户具备间接影响的一类外围性能指标。

除了通过优化Automatic WLM设置实现吞吐量最大化之外，Amazon Redshift中的并发扩大性能还能够将集群的吞吐量扩大至原始集群固有吞吐量的10倍。目前Amazon Redshift将10倍设定为吞吐量的软限度，大家能够依据需要与你的客户团队分割以调整此下限。

关注Amazon Redshift驱动程序

Amazon Web Services倡议大家应用Amazon Redshift JDBC或ODBC驱动程序，借此进步性能体现。每种驱动程序都对应多种可选配置，您能够进一步调整以管制语句使用量以及后果集中的具体行数。

对各类常见数据库治理工作进行自动化，借此升高应用门槛

2018年，咱们曾在文章中通过排序键、编码、表保护、散发以及工作负载治理等角度探讨了性能优化方面的几大要害注意事项。自那时以来，Amazon Redshift先后增加多项自动化性能，为SET DW提供100%信息反对、将表保护纳入Amazon Web Services服务职责（不再由用户方承当），并通过智能化水平更高的默认设置加强了开箱即用性能。即便表工作随时间推移而有所变动，Amazon Redshift Advisor仍会继续监控集群以寻找各类优化机会。Amazon Web Services还公布了用于量化Amazon Redshift性能的基准计划，帮忙大家轻松重现性能测试后果。

  • Amazon Redshift Advisor
    https://docs.aws.amazon.com/r...
  • 基准计划
    https://github.com/awslabs/am...

应用RA3节点与Amazon Redshift Spectrum实现计算与存储资源的独立扩大

除了本来提供的Dense Compute与Dense Storage节点等便捷集群构建块之外，当初大家还能够应用其余工具进一步对计算与存储资源进行独立扩大。Amazon Redshift Managed Storage（即RA3节点家族）将帮忙大家专一于调整计算资源量，而不用分神于存储容量问题。此外，并发扩大则容许咱们依据理论需要，对整个集群内的其余计算资源进行调整。Amazon Redshift Spectrum应用由Amazon Simple Storage Service(Amazon S3)提供的、近乎有限的存储容量以反对按需计算层，其容量可高达主集群容量的10倍，且现已提供配套的物化视图反对选项。

  • Amazon Redshift Spectrum
    https://docs.aws.amazon.com/r...
  • Amazon Simple Storage Service
    https://aws.amazon.com/cn/s3/

利用暂停与还原性能优化应用老本

当初，所有Amazon Redshift集群皆可应用暂停与还原性能。对于按需创立的集群，集群暂停操作将进行按秒计算的服务计费。预留实例集群则可通过暂停与还原性能，定义特定拜访工夫或在特定工夫点上解冻数据集。

技巧一：应用Amazon Redshift物化视图获取预计算后果

物化视图可能极大改善高反复度、可预测型剖析工作负载的查问性能，包含仪表板、商业智能工具中的查问，以及提取、加载与转换（ELT）等数据处理操作。数据工程师可能轻松轻松创立并保护一套蕴含物化视图的高效数据处理管道，同时将性能劣势无缝扩大至各类数据分析与商业智能工具当中。

物化视图实用于须要反复执行、且后果具备肯定可预测性的查问操作。应用程序能够查问物化视图中保留的事后计算数据，而不用对大型表重复执行资源密集型查问。

当基表中的数据产生变更时，您能够收回Amazon Redshift SQL语句“refresh materialized view”以刷新物化视图。在收回刷新语句之后，您的物化视图将蕴含与惯例视图雷同的数据内容。刷新能够采取增量刷新与齐全刷新（从新计算）两种具体模式。Amazon Redshift还会在实现上一次物化视图刷新之后，尽可能通过增量形式刷新基表中的已变更数据。

为了演示其工作原理，咱们能够创立一套示例schema以存储销售信息，包含每一项销售交易以及销售流动所在商店的详细信息。

要查看各城市的销售总额，咱们应用create materialized view SQL语句(city_sales）将来自两份表中的记录join起来，借此建设起物化视图，进而汇总各个城市(group by city)的具体销售额(sum(sales.amount))：

CREATE MATERIALIZED VIEW city_sales AS   (  SELECT st.city, SUM(sa.amount) as total_sales  FROM sales sa, store st  WHERE sa.store_id = st.id  GROUP BY st.city  );

当初，咱们能够像查问惯例视图或表那样查问这套物化视图，并收回“SELECT city, total_sales FROM city_sales”这类语句以得出以下后果。两份表单的join与聚合(sum与group by)曾经预计算实现，从而大大减少了须要扫描的理论数据量。

当底层基表中的数据产生变更时，物化视图无奈主动反映这些更改。您能够依据需要应用refresh materialized view SQL命令，将基表中的更改体现在物化视图中的数据处。具体参见以下代码：

!-- let's add a row in the sales base tableINSERT INTO sales (id, item, store_id, customer_id, amount) VALUES(8, 'Gaming PC Super ProXXL', 1, 1, 3000);SELECT city, total_sales FROM city_sales WHERE city = 'Paris'|city |total_sales||-----|-----------||Paris|        690|!-- the new sale is not taken into account !!-- let's refresh the materialized viewREFRESH MATERIALIZED VIEW city_sales;SELECT city, total_sales FROM city_sales WHERE city = 'Paris'|city |total_sales||-----|-----------||Paris|       3690|!-- now the view has the latest sales data

对于此用例的残缺代码，请参阅GitHub。

  • GitHub
    https://github.com

您也能够将物化视图的劣势扩大到Amazon S3数据湖以及其余联结数据源中的内部数据当中。应用物化视图，咱们能够轻松存储并治理由SELECT语句援用自内部表及Amazon Redshift表的预计算后果。以此为根底，所有援用物化视图的后续查问都将取得更快的运行速度，因为其应用的是存储在Amazon Redshift中的预计算后果，而不用理论拜访各内部表。您也能够借此缩小反复拜访内部数据源带来的经营老本，保障仅在明确须要刷新物化视图时才执行此类高老本拜访。

技巧二：通过并发扩大与弹性调整解决突发工作负载

传统的本地模型要求咱们对系统将来三到四年之内的资源需要作出预估，借此保障在设施洽购时预留短缺的容量。相比之下，Amazon Web Services容许您间接调整集群大小，从而得心应手地管制总体资源规模。具体到Amazon Redshift，咱们能够通过弹性调整与并发扩大实现这一突出劣势。

  • 弹性调整
    https://docs.aws.amazon.com/r...

弹性调整的实质，在于疾速减少或缩小计算节点的数量（最大可将原始集群的节点数量增加一倍或者缩小一半），甚至能够灵便调整节点类型。您能够扩大集群规模以获取额定的解决能力，借此适应忽然增长的工作负载，例如每年大型购物季、或者反对企业外部组织的网络业务挑战赛。如果某项配置无奈适配弹性调整，您还能够抉择经典调整计划。经典调整的执行速度较慢，但容许您更改节点类型和节点的理论规模伸缩范畴将超出弹性调整的加倍或减半限度。

弹性调整操作只须要几分钟即可实现，且无需重启集群。对于按可预测时间表呈现的预期内工作负载峰值，您能够应用Amazon Redshift控制台、Amazon Web Services命令行界面（Amazon CLI）或者API中的弹性调整调度性能，实现规模调整的主动执行。

并发扩大则容许您为Amazon Redshift集群动静增加容量，借此响应以后集群中的理论工作负载程度。

在默认状况下，并发扩大选项处于禁用状态。您能够针对任意工作负载治理（WLM）队列启用并发扩大，将并发查问数量扩大至近乎无穷的程度，且放弃高度一致的疾速查问性能。通过将“max_concurrency_scaling_clusters”参数值从1（默认）设定为10（零碎设定的软下限，您可分割反对团队以调整这一下限），大家可能疾速操控集群的最大并发扩大数量。更重要的，Amazon Web Services提供的收费并发扩大配额曾经足以满足大多数客户的需要，应用此项性能的用户个别不须要为此额定承担费用。对于并发扩大计费模型的更多详细信息，请参阅并发扩大费率规范。

  • 并发扩大费率规范
    https://aws.amazon.com/cn/red...

大家能够创立每日、每周或每月资源应用下限，借此监督并管制并发扩大性能的应用状况与应用老本，并要求Amazon Redshift在使用量达到下限时主动采取措施（例如记录日志、公布警报或禁止后续操作等）。对于更多详细信息，请参阅在Amazon Redshift中治理使用量限度。

  • 在Amazon Redshift中治理使用量限度
    https://docs.aws.amazon.com/r...

通过这些选项，亚马逊云科技为您带来一种对平台进行灵便调整以随时适应理论需要的全新办法。在应用这些选项之前，您须要预先确定WLM队列乃至整个Amazon Redshift集群的大小，并以此为根底为可能呈现的需要峰值做好筹备。

技巧三：应用Amazon Redshift Advisor升高管理负担

Amazon Redshift Advisor负责为您的Amazon Redshift集群提供优化倡议，借此改善集群性能体现并升高经营老本。

Advisor提出的优化倡议，以性能统计信息或对经营数据的察看后果为根底。Advisor会在集群上运行测试，借此确定察看值是否处于正当范畴之内，进而整顿出察看后果。一旦测试后果超出正当范畴，Advisor将为以后集群生成一项察看值。此外，Advisor还将针对如何将察看值疏导至正当范畴内提供相应倡议。Advisor只提供可能对性能及经营老本产生重大影响的倡议。在确定相干倡议已被驳回、问题失去解决之后，Advisor会将其从倡议列表中删除。在本节中，咱们将分享几个Advisor倡议示例：

调配键相干倡议

Advisor会剖析您的集群工作负载，为各表确定最合适的调配键形式，借此晋升性能体现。Advisor提供ALTER TABLE语句，依据剖析后果更改表的DISTSTYLE与DISTKEY。要显著晋升现有性能，请保障在倡议组内应用全副SQL语句。

  • ALTER TABLE
    https://docs.aws.amazon.com/r...

以下截屏所示，为对于调配键的倡议示例。

如果您没有收到倡议，也并不代表以后调配形式曾经达到最优成果。这可能意味着剖析数据有余或重新分配的预期收益过低，因而Advisor决定暂不提供相干倡议。

排序键相干倡议

通过应用适当的排序键对表进行排序，咱们能够缩小须要从磁盘处读取的表数据块，借此进步查问性能。这种办法特地实用于特定范畴之内的查问操作。

Advisor会剖析过来几天内集群的工作负载状况，据此为表选定适合的排序键，详见以下截屏。

如果您没有收到倡议，也并不代表以后配置形式曾经达到最优成果。这可能意味着剖析数据有余或从新排序的预期收益过低，因而Advisor决定暂不提供相干倡议。

表压缩相干倡议

Amazon Redshift通过优化，可通过压缩编码缩小存储空间占用，同时进步查问性能。如果不应用压缩，数据将占用更多空间，且产生额定的磁盘I/O需要。对大规模未经压缩的列执行压缩解决，可能对您的集群产生显著影响。

Advisor中的压缩剖析可能跟踪被调配给不可变用户表的未压缩数据，并对不属于排序键列的大型未压缩列进行元数据调配审查。

以下截屏所示，为表压缩的倡议示例。

表统计相干倡议

保留以后统计信息，往往有助于后续简单查问取得更快的执行速度。Advisor剖析会跟踪表中已过期或者存在缺失的统计信息，同时查看与简单查问相关联的表拜访元数据。一旦发现拜访频率较高、且拜访模式较为简单的表短少统计信息，Amazon Redshift Advisor就会创立一项重要倡议以运行ANALYZE。如果此类表上的统计信息曾经过期，则Advisor同样会创立对应倡议以运行ANALYZE。

以下截屏所示，为表统计的示例倡议。

技巧四：应用Auto WLM配合优先级机制晋升吞吐量

Auto WLM应用机器学习技术对内存及并发机制进行动静治理，保障集群资源的应用形式失去充沛优化，并借此简化工作负载治理流程并晋升查问吞吐量。

  • 工作负载治理流程
    https://docs.aws.amazon.com/r...

Amazon Redshift应用队列零碎（WLM）运行查问，您能够最多定义八个队列、借此将不同工作负载彼此辨别开来。

Amazon Redshift Advisor可能主动剖析以后WLM应用状况，并提出倡议以领导您通过以后集群获取更高的吞吐量。定期查看Advisor倡议，将帮忙您实现集群最佳性能。

查问优先级是Auto WLM中的一项性能，可帮忙您为不同用户组或查问组调配对应优先级，保障即便是在忙碌时段，高优先级工作负载仍能取得更多解决资源，借此实现对立的查问性能。本文强烈建议大家设置查问监控规定（QMR），借此监控并治理资源密集型查问或者与预期运行状态不符的失控查问。在QMR的帮忙下，您还能够依据查问的运行时性能与您所定义的指标性规定，动静调整各项查问操作的优先级程度。

  • 查问优先级
    https://docs.aws.amazon.com/r...
  • 查问监控规定
    https://docs.aws.amazon.com/r...

对于将手动WLM查问优先级转换为主动模式的更多详细信息，请参阅批改WLM配置。

  • 批改WLM配置
    https://docs.aws.amazon.com/r...

这里倡议大家应用Amazon Redshift提供的短查问减速（SQA）性能。SQA应用机器学习技术在自有队列中运行生命周期较短的作业，借此保障小型作业得以疾速实现，而不用在队列中期待运行耗时更长的其余SQL语句。在默认状况下，默认的参数组与全副新参数组均已启用SQA。您能够通过Amazon Redshift管制台上的复选框或应用Amazon Redshift CLI，对SQA进行启用或禁用。

  • 短查问减速
    https://docs.aws.amazon.com/r...

如果您启用了并发扩大机制，那么在工作负载开始备份时，Amazon Redshift可能主动疾速配置附加集群。在确定集群的具体WLM配置方面，咱们倡议大家认真思考这项因素。

一种常见的模式是对WLM配置进行优化，在无需增加内存的前提下运行更多SQL语句，借此为短查问作业保留额定的解决能力。当然，正当范畴内的队列也齐全能够承受，因为一旦您的需要忽然减少，零碎会随之增加更多附加集群。要在WLM队列上启用并发规模伸缩，请将并发扩大模式的值设定为AUTO。对于具体架构设计决策，建议您参阅并发扩大费率规范。大家也能够应用Amazon Redshift中的限度性能，监督并管制并发扩大性能的应用状况与应用老本。

  • 并发扩大费率规范
    https://aws.amazon.com/cn/red...
  • Amazon Redshift中的限度性能
    https://docs.aws.amazon.com/r...

在某些状况下，对于未启用并发扩大性能的集群，其中的用户或查问调配队列可能长时间处于繁忙状态，必须期待队列中腾出新的空位。在此期间，零碎将无奈运行任何新的查问。一旦经常出现此类情况，大家可能必须上调并发程度。

首先，应用queuing_queries.sql管理员脚本以确定以后是否存在查问队列。应用wlm_apex.sql以查看集群以往所须要的最大并发性，或者应用wlm_apex_hourly.sql进行每小时运行记录剖析。请留神，尽管上调并发行可能减少同时运行的查问总量，但每项查问所取得的内存配额也将对应缩小。在理论应用中，您可能发现在上调并发性之后，某些查问必须借助长期磁盘存储能力实现，而这同样不合乎性能最优化准则。

  • queuing_queries.sql
    https://github.com/awslabs/am...
  • wlm_apex.sql
    https://github.com/awslabs/am...
  • wlm_apex_hourly.sql
    https://github.com/awslabs/am...

技巧五：充分发挥Amazon Redshift数据湖的集成劣势

Amazon Redshift可能与Amazon S3等其余Amazon Web Services原生服务严密集成，帮忙用户以多种形式实现Amazon Redshift集群与数据湖间的交互。

Amazon Redshift Spectrum可能通过可独立进行弹性调整的计算层，从Amazon S3中的文件处间接查问数据。独自应用这些模式，或者将多种模式组合应用，可能将工作负载转移至Amazon Redshift Spectrum计算层，借此实现数据集的疾速创立、转换或聚合，同时打消传统ETL流程中的繁琐操作步骤。

  • 应用Amazon Redshift Spectrum计算层分担主集群上的局部工作负载，并为特定SQL语句提供更多解决能力。Amazon Redshift Spectrum可能主动调配算力，最高可达主集群解决能力的10倍，借此帮忙用户显著晋升大型转换或聚合作业的执行效率。
  • 跳过ETL流程中的负载，间接面向Amazon S3上的数据执行转换。您能够应用INSERT…SELECT语句对Amazon S3上的分区、列式数据反对转换逻辑。这种解决形式显著要比暂存以后数据集，将其join至其余表而后再行转换的流程简略得多。
  • 应用Amazon Redshift Spectrum对Amazon S3中的数据运行查问，借此跳过向主集群加载数据的步骤，真正实现实时剖析。
  • 以分区、列式格局将分段或转换集群的输入后果引入Amazon S3。主集群或报告集群可能间接从该Amazon S3数据集内查问后果，并通过INSERT…SELECT语句进行疾速加载。

在Amazon Redshift当中，咱们能够应用UNLOAD命令或写入内部表的形式，将数据导出至数据湖内。这两种形式都可能以并发模式将SQL语句的输入后果导入Amazon S3。具体操作步骤如下：

  • 应用您所相熟的CREATE EXTERNAL TABLE AS SELECT与INSERT INTO SQL语句在Amazon S3上创立并填充内部表，以供Amazon Redshift或者甚至退出数据湖的服务后续应用，这种形式可能打消对分区的手动保护操作。物化视图亦可笼罩内部表，由此进一步加强对数据湖的拜访及利用能力。
  • 应用UNLOAD命令，Amazon Redshift可能以大规模并发形式将SQL语句的输入后果导出至Amazon S3。这项技术极大进步了导出性能，同时也加重了经由主节点进行数据传输造成的性能影响。咱们能够在导出数据传出Amazon Redshift集群的过程中对其进行压缩。输入数据的体积越小，这项导出性能的劣势也就越显著。在将列式数据写入至数据湖的过程中，UNLOAD还可能同时写入分区感知型Parquet数据。
  • CREATE EXTERNAL TABLE AS SELECT
    https://docs.aws.amazon.com/r...
  • INSERT INTO
    https://docs.aws.amazon.com/r...

技巧六：进步长期表的效率

Amazon Redshift还提供长期表性能，其作用与一般表相似，但生命周期与繁多SQL会话相关联。正确应用长期表可能显著晋升某些ETL操作的性能体现。与惯例的永恒表不同，指向长期表的数据更改不会触发Amazon S3中的主动增量备份——换言之，无需同步数据块镜像，咱们即可将数据的冗余正本存储在其余计算节点之上。在此基础之上，长期表上的数据提取老本更低，执行速度也更快。也正因为如此，长期表成为承载长期存储（例如分段表）的现实选项。

大家能够应用CREATE TEMPORARY TABLE语法，或者收回SELECT … INTO #TEMP_TABLE查问以创立长期表。CREATE TABLE语句容许用户全面管制长期表的定义。SELECT … INTO and C(T)TAS命令则应用输出数据以确定列名称、大小与数据类型，并应用默认存储属性。这里要揭示大家认真思考是否应应用默认存储属性，以防引起意外影响。在默认状况下，Amazon Redshift会在长期表内以非列编码（例如RAW压缩）的形式全面执行EVEN表调配，而这一数据结构理论并不适宜很多常见的查问类型。

  • CREATE TEMPORARY TABLE
    https://docs.aws.amazon.com/r...
  • SELECT … INTO #TEMP_TABLE查问
    https://docs.aws.amazon.com/r...

如果您应用SELECT…INTO语法，则无奈设置列编码、列调配或者排序键。相同，您只能应用CREATE TABLE AS(CTAS)语法以指定调配款式与排序键，这时Amazon Redshift会主动在除排序键、布尔值、实数以及双精度数以外的所有内容中利用LZO编码。当然，大家也能够间接应用CREASTE TABLE语法（不包含CTAS）以实现其余管制。

如果须要创立长期表，请留神将所有SELECT…INTO语法转换为CREATE语句，借此保障您的长期表内蕴含列编码，且不致在工作流中引发调配谬误。例如，您能够应用以下语法进行语句转换：

SELECT column_a, column_b INTO #my_temp_table FROM my_table;

您须要剖析长期表以实现列编码优化：

Master=# analyze compression #my_temp_table;Table | Column | Encoding----------------+----------+---------#my_temp_table | columb_a | lzo#my_temp_table | columb_b | bytedict(2 rows)

接下来，您能够将SELECT INTO语句转换为以下模式：

BEGIN;CREATE TEMPORARY TABLE my_temp_table(column_a varchar(128) encode lzo,column_b char(4) encode bytedict)distkey (column_a) -- Assuming you intend to join this table on column_asortkey (column_b) -- Assuming you are sorting or grouping by column_b;INSERT INTO my_temp_table SELECT column_a, column_b FROM my_table;COMMIT;

如果您应用CREATE TABLE LIKE语句创立一个长期分段表，则该分段表将从父指标表处继承调配键、排序键与列编码。在这种状况下，因为各行被join合并，因而分段与指标表将被join至同一调配键上，执行速度也由此放慢。若要验证查问是否应用合并join，请应用EXPLAIN运行查问，并查看所有joins上的DS_DIST_NONE。

大家可能还须要剖析长期表上的统计信息，特地是在将长期表作为join表以供后续查问的状况下。详见以下代码：

ANALYZE my_temp_table;

应用此项技巧，您能够保留长期表的性能，同时通过调配键控制数据在集群上的搁置地位。此外，您还能够通过列编码施展Amazon Redshift的列属性劣势。

技巧七：应用QMR与Amazon CloudWatch指标以驱动其余性能改良

除了Amazon Redshift Advisor倡议之外，大家也能够通过其余渠道获取性能洞见论断。

无论大家是否在集群上制订有规定，Amazon Redshift集群都会继续主动为查问监控规定收集指标。通过这一便捷的设定，您能够轻松查看以下属性：

  • 某一SQL语句的CPU工夫 (query_cpu_time)
  • 某一作业可能“溢出至磁盘”的长期空间占用量(query_temp_blocks_to_disk)
  • 读取的最大数据块数量与平均值之比 (io_skew)

这项设定还提供Amazon Redshift Spectrum指标，例如某项查问中波及的Amazon Redshift Spectrum行数以及MB数（别离为spectrum_scan_row_count和spectrum_scan_size_mb、respectively）。Amazon Redshift零碎的SVL_QUERY_METRICS_SUMMARY视图会显示已实现各查问的指标最大值，STL_QUERY_METRICS与STV_QUERY_METRICS视图则以1秒为距离显示已实现以及正在运行中的查问信息。

  • SVL_QUERY_METRICS_SUMMARY
    https://docs.aws.amazon.com/r...
  • STL_QUERY_METRICS
    https://docs.aws.amazon.com/r...
  • STV_QUERY_METRICS
    https://docs.aws.amazon.com/r...

Amazon Redshift CloudWatch指标作为Amazon CloudWatch监控性能所应用的数据点。CloudWatch指标可笼罩集群范畴，例如运行状况、读取/写入、IOPS、提早或吞吐量；也能够提供计算节点层级的数据，例如网络发送/接管吞吐量以及读取/写入提早。在WLM队列这一监控力度下，咱们还可查看每秒实现的查问数量、队列长度等。CloudWatch还会通过ConcurrencyScalingSeconds与ConcurrencyScalingActiveClusters等指标帮助用户监控并发扩大性能的应用状况。

在投入工夫创立新内容前，咱们倡议大家首先认真核查各项CloudWatch指标（及以这些指标为根底建设的现有告诉架构）。同样的，QMR指标也能涵盖大部分指标用例，少数用户能够间接应用，无需独自编写自定义指标。

  • Amazon Redshift CloudWatch
    https://docs.aws.amazon.com/r...

技巧八：串连OLAP、OLTP与数据湖执行联结查问

Amazon Redshift中新增的联结查问性能，容许您间接针对OLTP源零碎数据库与Amazon S3数据湖上的实时数据执行剖析操作，整个过程无需执行任何ETL、也不须要将源数据库提取至Amazon Redshift表内。作为一项快捷高效的选项，这项性能可能在经营报告上提供实时数据可见性，从而代替将大量ETL批处理实时数据导入数据仓库的传统办法。通过将数据仓库中的历史趋势数据，与源零碎中的实时应用趋势相结合，咱们能够整顿出有价值洞见，据此驱动实时业务决策。

例如，咱们假设销售数据别离存储在三套不同的数据存储体系当中：

实时销售数据存储在Amazon RDS for PostgreSQL数据库上（在以下内部schema中示意为“ext_postgres”）。

历史销售数据存储在本地Amazon Redshift数据库上（示意为“local_dwh”）。

5年以上的已归档“冷”销售数据存储在Amazon S3上（示意为“ext_spectrum”）。

  • Amazon RDS for PostgreSQL
    https://aws.amazon.com/rds/po...

咱们能够在Amazon Redshift上创立前期绑定视图，借此合并及查问来自所有三个起源处的数据。具体参见以下代码：

CREATE VIEW store_sales_integrated AS SELECT * FROM ext_postgres.store_sales_live UNION ALL SELECT * FROM local_dwh.store_sales_current UNION ALL SELECT ss_sold_date_sk, ss_sold_time_sk, ss_item_sk, ss_customer_sk, ss_cdemo_sk, ss_hdemo_sk, ss_addr_sk, ss_store_sk, ss_promo_sk, ss_ticket_number, ss_quantity, ss_wholesale_cost, ss_list_price, ss_sales_price, ss_ext_discount_amt, ss_ext_sales_price, ss_ext_wholesale_cost, ss_ext_list_price, ss_ext_tax, ss_coupon_amt, ss_net_paid, ss_net_paid_inc_tax, ss_net_profit FROM ext_spectrum.store_sales_historical WITH NO SCHEMA BINDING

目前，对于存储在Amazon Aurora PostgreSQL与Amazon RDS for PostgreSQL数据库内的数据，咱们能够间接进行联结查问。后续Amazon Web Services还将推出面向其余次要RDS引擎的反对性能。大家还能够应用联结查问性能，简化ETL与数据输出过程。联结查问将帮忙您在CTAS/INSERT SQL联结查问当中通过一步操作，将数据间接摄取至Amazon Redshift表当中，而不再须要将数据暂存在Amazon S3上再执行COPY操作。

  • Amazon Aurora PostgreSQL
    https://aws.amazon.com/cn/rds...

例如，以下代码所示为一项upsert/merge操作，其中将由Amazon S3到Amazon Redshift的COPY操作间接替换为以PostgreSQL为源的联结查问：

BEGIN;CREATE TEMP TABLE staging (LIKE ods.store_sales);-- replace the following COPY from S3:    /*COPY staging FROM 's3://yourETLbucket/daily_store_sales/'    IAM_ROLE 'arn:aws:iam::<account_id>:role/<s3_reader_role>'    DELIMITER '|' COMPUPDATE OFF; */-- with this federated query to load staging data directly from PostgreSQL sourceINSERT INTO staging SELECT * FROM pg.store_sales p    WHERE p.last_updated_date > (SELECT MAX(last_updated_date) FROM ods.store_sales);DELETE FROM ods.store_sales USING staging s WHERE ods.store_sales.id = s.id;INSERT INTO ods.store_sales SELECT * FROM staging;DROP TABLE staging;COMMIT;

对于设置以上联结查问的更多详细信息，请参阅应用Amazon Redshift联结查问简化ETL与实时数据查问解决方案。对于联结查问的其余技巧与最佳实际，请参阅Amazon Redshift联结查问最佳实际。

  • 应用Amazon Redshift联结查问简化ETL与实时数据查问解决方案
    https://aws.amazon.com/cn/blo...
  • Amazon Redshift联结查问最佳实际
    https://aws.amazon.com/cn/blo...

技巧九：放弃高效的数据加载

Amazon Redshift最佳实际倡议大家应用COPY命令执行基于文件的数据加载。但单行INSERT属于反模式用例。COPY操作可能应用集群中的所有计算节点，从Amazon S3、Amazon DyanmoDB、Amazon EMR HDFS文件系统或者任意SSH连贯等起源实现数据的并行加载。

在执行数据加载时，请尽可能对数据文件进行压缩。对于面向行（CSV）的数据，Amazon Redshift反对GZIP与LZO压缩。加载大量小文件的执行效率，要高于加载繁多大型文件，因而最现实的文件数量应是集群总分片数量的整数倍。此外，Amazon Redshift还反对Pqrquet及ORC等列式数据。当压缩文件的大小在1 MB到1 GB之间时，即可实现最佳加载性能。

每个节点的分片数量，取决于集群中的理论节点大小（以及可能的弹性调整历史记录）。通过保障各个分片上的文件数量相等，即可疏导COPY命令均匀应用集群资源并尽快实现加载操作。您能够应用SELECT COUNT(*)AS number_of_slices FROM stv_slices;查问集群的以后分片数量。

由amazon-redshift-utils GitHub repo提供的另一个脚本，CopyPerformance，可能计算每项加载操作的统计信息。Amazon Redshift Advisor还会依据理论分片数量，就压缩缺失或文件数量过低问题收回警报（详见以下截屏）：

  • amazon-redshift-utils
    https://github.com/awslabs/am...
  • CopyPerformance
    https://github.com/awslabs/am...

执行COPY操作可能无效缩小上游用户获取后果的期待时长，并最大水平缩小用于执行加载操作的集群资源。

技巧十：应用亚马逊云科技提供的最新Amazon Redshift驱动程序

因为Amazon Redshift以PostgreSQL为根底设计而来，因而咱们之前倡议大家应用JDBC4 PostgreSQL驱动程序8.4.703版本以及psql ODBC 9.x版本驱动程序。但如果您目前仍在应用这些驱动程序，咱们建议您降级至Amazon Redshift的新型专用驱动程序。对于驱动程序与连贯配置的更多详细信息，请参阅《Amazon Redshift集群治理指南》中的用于Amazon Redshift的JDBC与ODBC驱动程序局部。

  • Amazon Redshift集群治理指南
    https://docs.aws.amazon.com/r...
  • JDBC
    https://docs.aws.amazon.com/r...
  • ODBC
    https://docs.aws.amazon.com/r...

只管几率很低，但大家偶然可能须要对Amazon Redshift驱动程序中的某些参数做出调整。上游第三方应用程序通常也制订有本人的驱动程序优化最佳实际，可能进一步晋升零碎的整体性能。

对于JDBC，请参考以下最佳实际：

1.为了防止在应用JDBC检索大型数据集时，呈现客户端外在有余的谬误，咱们能够设置JDBC fetch size参数或BlockingRowsMode的形式，让客户端批量获取数据。

2.Amazon Redshift无奈辨认JDBC maxRows参数。相同，请指定LIMIT子句以限度后果集。大家还能够应用OFFSET子句跳转至后果集中的特定终点。

  • 设置JDBC fetch size参数
    https://docs.aws.amazon.com/r...
  • LIMIT
    https://docs.aws.amazon.com/r...
  • OFFSET
    https://docs.aws.amazon.com/r...

对于ODBC，请参考以下最佳实际：

1.在启用useDelareFetch时，会在集群的主节点上启用一个指针。该指针将提取fetchsize/cursorsize，并在应用程序申请更多行时协助执行提取操作。

2.CURSOR命令是一条用于操纵主节点上指针行为的显式指令。与JDBC驱动程序不同，ODBC驱动程序不提供BlockingRowsMode机制。

除非您有明确需要，否则请不要调整驱动程序。Amazon Web Services Support将为您提供与此相关的更多帮忙信息。

总结

Amazon Redshift是一套功能强大的全托管数据仓库，可能在云端提供更好的性能体现与更低的经营老本。随着Amazon Redshift在寰球数以万计沉闷客户的应用与反馈下一直发展壮大，其易用性、扩展性以及性价比也失去继续加强。通过这些改良，您可能从这项外围亚马逊云科技服务当中取得更多价值，并一直升高工夫与精力投入。

心愿本文可能为大家在充分发挥Amazon Redshift各项劣势的尝试中，带来一点指引与启发。

如果您有任何疑难或倡议，请在评论区中与咱们交换。

本篇作者


Matt Scaer
亚马逊云科技首席数据仓库
业余解决方案架构师

他在亚马逊云科技与Amazon.com领有超过11年的从业教训。


Manish Vaziran
亚马逊云科技剖析
业余解决方案架构师


Tarun Chaudhary
亚马逊云科技剖析
业余解决方案架构师