何时为您的 Redshift 数据仓库使用 Redshift Spectrum

Rya*_*yan 3 spectrum amazon-web-services amazon-redshift amazon-redshift-spectrum delta-lake

我对 Redshift 服务还很陌生,并且对何时使用或将哪些数据放入 Spectrum 感到非常困惑。

假设我在 Redshift 上有星型模式数据仓库,我应该将事实表或暗表放入 Spectrum(来自 s3 的外部表)中以进行存储优化吗?或者通常数据仓库具有不同的层,例如:登陆、暂存或数据仓库。我们是否应该将其他层的数据放入 Spectrum,只将星型模式数据放入 Redshift。

由于 S3 中的数据仅被附加,我们是否需要安装 apachi hudi 或 delta Lake 才能与 Redshift Spectrum 配合使用?

我找到了一篇 aws 文章:https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/,如下所述,但仍然不清楚。

一些好的用例如下:

  • 数据量大但访问频率较低的数据 大量扫描和
  • 聚合密集型查询 可以使用的选择性查询
  • 分区剪枝和谓词下推,因此输出相当小

任何人都可以提供现实世界的例子来解释吗?谢谢

Bil*_*ner 6

这是一个广泛的话题,但我会给出一些想法。

首先,Spectrum 是嵌入在 S3 中的一组(通常很大)计算元素,可以执行查询计划的某些方面。这些部分集中于应用 WHERE 条件和执行聚合 (GROUP BY)。查询计划的某些方面无法在 S3 层中执行,例如 JOIN 和窗口函数等高级功能。

接下来要了解的是,虽然这些嵌入式计算元素在访问速度方面接近 S3,但 S3 服务与 Redshift 集群(网络距离)相距甚远。如果存储在 S3 中的大量数据可以减少为一小部分并运送到 Redshift,那么 Spectrum 可以带来巨大的性能提升。但是,如果需要将存储在 S3 中的大量数据完全移动到 Redshift 集群来执行查询,那么性能可能会受到很大影响。

频谱可以带来巨大的好处;允许通过一组小型计算元素快速过滤大量数据。这可以在性能和可处理的数据量方面带来巨大的胜利。

考虑到这些,您将希望在 Spectrum 中拥有您的查询计划希望将子集从 S3 传输到 Redshift 的数据。这通常适用于您的事实表,而不适用于您的暗淡表。但是,如果您的查询不打算将 WHERE 子句应用于事实表或聚合数据,那么您将看不到优势。此外,为了使其正常工作,WHERE 子句需要应用于事实表中的列,因为 JOIN 无法在 S3 中完成,因此对暗淡列进行过滤将无济于事。同样,GROUP BY 仅需要应用于事实表列,否则这不会减少从 S3 传入 Redshift 的数据。

所以事实表。

数据通常通过 S3 进入 Redshift,这可以使用 COPY 命令来完成。您还可以使用 Spectrum 将数据从 S3 获取到 Redshift。如果其他工具也使用 S3 来存储此共享数据,那么这可能是一个有用的工具。S3 看起来像是独立数据系统的通用数据存储。这对于某些数据解决方案很有用。

您还可以调出非常大的、不常用的数据。就像通常需要但有时需要的旧历史数据一样。这很有帮助,因为可以从 Redshift 集群卸载较旧的数据,并且该数据的访问时间并不重要,因为它很少使用。有一个潜在的问题 - Redshift 集群只能处理特定大小的数据(考虑到磁盘空间和内存)。因此,如果历史数据量太大,您可能会堵塞集群。这可能意味着在一个查询中查看完整的历史数据集可能是不可能的。同样,如果数据在 S3 中聚合或过滤,那么这个问题就不是问题。

底线 - Spectrum 是一个很棒的工具,但并不是解决所有问题的正确工具。