关于data:关于Amazon-Redshift性能调优的十大Tips

62次阅读

共计 16550 个字符，预计需要花费 42 分钟才能阅读完成。

在 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 table

INSERT 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 view
REFRESH 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 语法，或者收回 S ELECT … 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_a
sortkey (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 source
INSERT 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
亚马逊云科技剖析
业余解决方案架构师

正文完
data
发表至： data
2021-12-21
 0
关于data:专注于最有价值的事情亚马逊云科技首席科学家工作心得分享
关于data:DataOps数据运维指南-数据管理的新时代
关于data:如何将Amazon-RDS与Amazon-Aurora数据库迁移至Graviton2
关于data:重装上阵Graviton2提升Aurora性价比