在生产中结合使用 Amazon Redshift Spectrum、Amazon Athena 和 AWS Glue 与 Node.js(一)

阅读数:1 2020 年 1 月 13 日 14:52

在生产中结合使用 Amazon Redshift Spectrum、Amazon Athena 和 AWS Glue 与 Node.js(一)

此博文由 NUVIAD 的创始人和 CEO Rafi Ton 特约发表。 NUVIAD 对自己的定 __ 位是:“为专业营销人员机构和本地企业提供一流工具以通过精确定向、大数据分析和高级机器学习工具来推广他们的产品和服务的移动营销平台。__”

在 NUVIAD,我们 3 年多以来一直将 Amazon Redshift 用作我们的主要数据仓库解决方案。

我们存储了大量广告交易数据,我们的用户和合作伙伴对这些数据进行分析,以确定广告活动策略。大规模运行实时竞标 (RTB) 活动时,数据的新鲜度至关重要,因为这样一来,我们的用户就可以对广告效果的变化做出快速反应。我们选择 Amazon Redshift 是因为它的简单性、可扩展性、性能及几乎实时加载新数据的能力。

在过去三年里,我们的客户群大大增加,数据亦是如此。我们发现 Amazon Redshift 集群从 3 个节点增长到 65 个节点。为了平衡成本和分析性能,我们找到了一种方法,以更低的成本存储大量不太频繁分析的数据。然而,我们仍然希望能够立即为用户查询提供数据及满足他们对性能显著提升的期望。我们转向了 Amazon Redshift Spectrum

在此博文中,我们解释了将带 Redshift Spectrum 的 Amazon Redshift 扩展为现代数据仓库的原因。我将介绍我们的数据增长及平衡成本和性能的需求如何促使我们采用 Redshift Spectrum。我还将分享我们的环境中的关键性能指标,并讨论提供可扩展和快速环境的额外 AWS 服务,并提供数据供我们日益增长的用户群进行立即查询。

将 Amazon Redshift 作为基础

能够为客户和合作伙伴提供最新数据一直是我们平台的主要目标。我们发现其他解决方案可提供几个小时前的数据,但这对我们来说还不够好。我们坚持提供最新的数据。对我们而言,这意味着以频繁的微批次加载 Amazon Redshift 并使我们的客户直接查询 Amazon Redshift 将近乎实时的获得结果。

优势是显而易见的。我们的客户可以看到,他们的活动比其他解决方案执行的更快,对不断变化的媒体供应定价和可用性的反应更迅速。他们非常高兴。

然而,这种方法需要 Amazon Redshift 长期存储大量数据,且我们的数据大幅增长。在高峰期时,我们维护了一个运行 65 个 DC1.large 节点的集群。对 Amazon Redshift 集群的影响是显而易见的,而且我们发现 CPU 利用率增长到 90%。

我们为什么将 Amazon Redshift 扩展到 Redshift Spectrum

Redshift Spectrum 使我们能够使用强大的 Amazon Redshift 查询引擎对 Amazon S3 中存储的数据运行 SQL 查询,无需加载数据。利用 Redshift Spectrum,我们可以以我们希望的成本江南数据存储在我们想要的地方。我们可提供数据供用户在需要时进行分析,且数据性能符合用户预期。

无缝可扩展性、高性能和无限并发数

扩展 Redshift Spectrum 是一个简单的过程。首先,它可使我们将 Amazon S3 用作存储引擎并获得近乎无限的数据容量。

其次,如果我们需要更多计算能力,我们可以在数千个节点上利用 Redshift Spectrum 的分布式计算引擎来提供卓越的性能——这对于针对大量数据运行的复杂查询非常适合。

第三,所有的 Redshift Spectrum 集群均可访问相同的数据目录,这样一来,我们不必再担心数据迁移,可以毫不费力进行无缝扩展。

最后,由于 Redshift Spectrum 将查询分布在可能有数千个的节点上,它们不受其他查询的影响,从而能提供更稳定的性能和无限的并发数。

将它保持为 SQL

Redshift Spectrum 使用与 Amazon Redshift 相同的查询引擎。这意味着,我们不需要更改我们的 BI 工具或查询语法,无论我们是在单个表上使用复杂查询还是加入多个表。

最近推出的一项有趣功能是,能够创建同时跨越 Amazon Redshift 和 Redshift Spectrum 外部表的视图。利用此功能,您可以使用一个视图在 Amazon Redshift 集群中查询频繁访问的数据并在 Amazon S3 中查询较少访问的数据。

利用 Parquet 以获得更高性能

Parquet 是一种柱状数据格式,可提供优越的能力并使 Redshift Spectrum(或 Amazon Athena)能够扫描更少的数据。查询使用较少的 I/O 便能更快运行,且每个查询的费用更低。您可以在 https://parquet.apache.org/ https://en.wikipedia.org/wiki/Apache_Parquet 中阅读有关 Parquet 的所有内容。

较低的成本

从成本角度来看,我们为 Amazon S3 中的数据支付标准费率,每个查询只需要少量数据来使用 Redshift Spectrum 分析数据。使用 Parquet 格式,我们可以大大减少扫描的数据量。现在,我们的成本更低,而我们的用户甚至在较大的复杂查询中都能获得快速结果。

我们了解的有关 Amazon Redshift 对 Redshift Spectrum 性能的内容

当我们第一次开始了解 Redshift Spectrum 时,我们希望对其进行测试。我们希望了解它与 Amazon Redshift 相比如何,所以我们考虑了两个关键问题:

  1. Amazon Redshift 与 Redshift Spectrum 在简单和复杂查询方面的性能差异是什么?
  2. 数据格式是否影响性能?

在迁移期间,我们将 Amazon Redshift 和 S3 中存储的数据集设置为 CSV/GZIP 和 Parquet 文件格式。我们对三种配置进行了测试:

  • 带 28 个 DC1.large 节点的 Amazon Redshift 集群
  • 使用 CSV/GZIP 的 Redshift Spectrum
  • 使用 Parquet 的 Redshift Spectrum

我们使用一个月的数据对简单和复杂查询执行了基准测试。我们测试了执行查询所需的时间,以及多次运行同一个查询时,结果的一致性如何。我们用于测试的数据已按照日期和小时进行了分区。对数据进行适当分区将大大提高性能并降低查询时间。

简单查询

首先,我们测试了聚合一个月账单数据的简单查询:

SQL

复制代码
SELECT
user_id,
count(*) AS impressions,
SUM(billing)::decimal /1000000 AS billing
FROM <table_name>
WHERE
date >= '2017-08-01' AND
date <= '2017-08-31'
GROUP BY
user_id;

我们运行了七次同一个查询并测量了反应时间(红色表示最长时间,绿色表示最短时间):

col 1
:-----------:|:-------------------:|:----------------------------:|:-----------------------------:
执行时间(秒)
| Amazon Redshift | Redshift Spectrum
CSV
| Redshift Spectrum Parquet
Run #1 | 39.65 | 45.11 | 11.92
Run #2 | 15.26 | 43.13 | 12.05
Run #3 | 15.27 | 46.47 | 13.38
Run #4 | 21.22 | 51.02 | 12.74
Run #5 | 17.27 | 43.35 | 11.76
Run #6 | 16.67 | 44.23 | 13.67
Run #7 | 25.37 | 40.39 | 12.75
Average | 21.53 | 44.82 | 12.61

对于简单查询,Amazon Redshift 的表现比 Redshift Spectrum 更好,正如我们所想,这是因为数据在 Amazon Redshift 本地。

令人惊讶的是,在 Redshift Spectrum 中使用 Parquet 数据格式明显优于 Amazon Redshift 的“传统”表现。对于我们的查询,使用 Parquet 数据格式与 Redshift Spectrum 产生的平均性能比传统的 Amazon Redshift 高 40%。此外,Redshift Spectrum 在执行时间上表现出很高的一致性,最慢运行和最快运行之间的差异较小。

使用 CSV/GZIP 和 Parquet 时对扫描的数据量进行比较发现,差异也很显著:

复制代码
col 1

:--------------:| ------
扫描的数据 (GB)
CSV (Gzip) | 135.49
Parquet | 2.83

由于我们只为 Redshift Spectrum 扫描的数据付款,使用 Parquet 显然可以大幅节省成本。

复杂的查询

接下来,我们将相同的三种配置与复杂查询进行了比较。

col 1
:-----------:|:-------------------:|:-------------------------:|:-----------------------------:
执行时间(秒)
| Amazon Redshift | Redshift Spectrum CSV | Redshift Spectrum Parquet
Run #1 | 329.80 | 84.20 | 42.40
Run #2 | 167.60 | 65.30 | 35.10
Run #3 | 165.20 | 62.20 | 23.90
Run #4 | 273.90 | 74.90 | 55.90
Run #5 | 167.70 | 69.00 | 58.40
Average | 220.84 | 71.12 | 43.14

此时,使用 Parquet 的 Redshift Spectrum 与传统的 Amazon Redshift 相比,将平均查询时间削减了 80%!

底线:对于复杂查询,Redshift Spectrum 与 Amazon Redshift 相比,将性能提高 67%。使用 Parquet 数据格式后,Redshift Spectrum 与 Amazon Redshift 相比,使性能提高 80%。对我们而言,这一提高巨大。

本文转载自 AWS 技术博客。

原文链接: https://amazonaws-china.com/cn/blogs/china/big-data-using-amazon-redshift-spectrum-amazon-athena-and-aws-glue-with-node-js-in-production/

评论

发布