对于简单的查询，红移光谱比雅典娜慢40倍以上

我有一个S3数据湖，我可以与雅典娜查询。同样的数据湖也与Amazon Redshift连接在一起。然而，当我在Redshift中运行查询时，与雅典娜相比，我的查询时间要长得多，即使是最简单的查询。

Athena中的查询

CREATE TABLE x as (select p.anonymous_id, p.context_traits_email, p."_timestamp", p.user_id FROM foo.pages p)

查询Redshift

create temp table x as (
select p.anonymous_id, p.context_traits_email, p."_timestamp", p.user_id
FROM external_schema.pages p
)

查询需要17分钟才能运行!

datalake有一个附加的胶水目录，由第三方工具(RudderStack)维护。没有爬虫，RudderStack将parquet文件放在S3桶的特定部分，并在模式发生更改时更新Glue目录，等等。

下面是Glue Table定义的相关部分:

外部模式是这样创建的:

create external schema if not exists external_schema
from data catalog
database 'foo'
region 'us-east-1'
iam_role 'arn:aws:iam::xxxxx';

查询运行时redshift集群上的cpu利用率(单个d2)。大节点)在整个查询运行时中不会超过15%。那么，如果不是红移超载的问题，那么在查询处理中怎么会有如此巨大的差异，特别是在查询中没有任何连接、区别等的情况下?

Redshift的SVL_S3QUERY_SUMMARY为这个查询只列出了一个条目:

你的文件太多了

S3访问的开销是问题所在。

请记住，每个切片最多有10个Spectrum工作者，但在实践中更少，并且您可能有一个更小的集群。您可能会同时访问10个文件，要读取144,000个文件，并且每个S3连接都会产生不可减少的延迟。

您正在物理地将整个表从athena复制到redshift，因此应该预期会花费很长的时间。这可能是由于网络流量瓶颈和缺乏优化(与COPY命令相比)

如果您只是想从s3加载一个表到redshift，那么您应该使用COPY。这将运行得更快。

当你需要下推谓词和连接到athena时，应该使用Redshift Spectrum，这可以提供良好的性能。

此外，似乎您的文件大小在s3中可能非常小。这大大降低了性能。您应该瞄准比当前文件大100倍的文件!