从高层查看我们的查询管道告诉我们

barikulislam014

然后，我们启动数据产品管道并启动 Integrate.io 仪表板来定量监控两个集群的性能和特征。 数据产品管道特征 我们的主要 Redshift 数据产品管道由批量 ETL 作业组成，这些作业可减少从 （又名“ELT”）加载的原始数据。ETL 转换从大约 50 个主表开始，经过多次转换以生成大约 30 个下游表。然后将这 30 个表组合起来并加载到服务数据库（例如 Elasticsearch）中进行服务。因此，这一切都转化为一组繁重的读/写 ETL 作业，并结合定期读取将数据加载到外部数据库中。 虽然我们的管道还包括在 Redshift 之外的平台中发生的一些外部作业，但我们已从本文中排除了这些作业的性能，因为它与 ra3.16xlarge 与 的比较无关。



整体查询性能 首先，我们查看了在 ds2.8xlarge 集群和集群上的相同数据上运行的管道的整体查询性能。我们的 Integrate.io 仪表板报告 ds2.8xlarge 集群的 P95 延迟为 1.1 秒，延迟为 秒： 集群整体性 沙特阿拉伯电报号码数据 能显着提升： P95 延迟快了 36%，为 0.7 秒，P99 延迟快了 这是一个显着的改进。 深入细节 集群的平均吞吐量显着提高。但数据产品管道的性能通常受到管道中性能最差的查询的限制。接下来我们查看集群中最慢查询的性能。 由于我们使用SQL 查询注释标记数据管道中的所有查询，因此通过绘制给定时间范围内的最大查询执行时间并按 SQL 查询注释分组来快速识别管道中最慢的步骤是很简单的： 执行时间 ra3 基准测试 此报告中的每个系列都对应一个任务。





该任务作为 ETL DAG（在本例中是我们称为 sheperd 的内部转换过程）的一部分运行。 在此时间范围内，两个集群上最慢的任务是 get_samples-query，这是一个相当复杂的 SQL 转换，用于连接、处理和聚合 11 个表。在 4 节点，此任务平均耗时 38 分 51 秒： 在 2 节点 ra3.16xlarge 上运行相同的任务平均需要 32 分 15 秒，提高了 18%！ 这个结果非常令人兴奋：以与更大的 ds2.8xlarge 集群大致相同的价格，我们可以获得数据产品管道性能的显着提升，同时获得两倍的存储容量。 转到管道中下一个最慢的查询，我们发现平均查询执行时间从 ds2.8xlarge 上的 2 分钟缩短到 ra3.16xlarge 上的 1 分 20 秒，提高了 33%！ 存储与计算分离 新 RA3 实例的推出解决了客户在管理 Amazon Redshift 集群时遇到的最大痛点之一：管理存储。