Redshift 不会将新加载的数据识别为预排序的

Question

我正在尝试将大量数据加载到 redshift 中，加载到单个表中，一旦加载，这对于 Vacuum 来说成本太高。为了避免清理这个表，我使用 COPY 命令从大量预先排序的 CSV 文件中加载数据。我正在加载的文件是根据表中定义的排序键预先排序的。

然而，在加载前两个文件后，我发现 redshift 将表格报告为 ~50% 未排序。我已验证文件中的数据是否按正确的排序顺序排列。为什么 redshift 不会将新传入的数据识别为已排序？ 我是否需要做一些特别的事情来让复制命令知道这个新数据已经处于正确的排序顺序？

我正在使用 SVV_TABLE_INFO 表来确定排序百分比（使用未排序的字段）。排序键是三个不同字段（平面、x、y）的复合键。

Redshift 支持的官方回答：

这是我们官方所说的： http://docs.aws.amazon.com/redshift/latest/dg/vacuum-load-in-sort-key-order.html

当您的表定义了排序键时，该表分为 2 地区：

• 已排序，并且
• 未分类

只要您按排序键顺序加载数据，即使数据是 在未排序的区域，它仍然是排序键顺序，所以没有 需要 VACUUM 来确保数据已排序。仍然需要一个 VACUUM 将数据从未排序区域移动到已排序区域， 然而，这不太重要，因为未排序区域中的数据是 已经排序了。

Answer 1

在 Amazon Redshift 表中存储排序的数据会在几个方面产生影响：

• 不使用ORDER BY 时数据如何显示
• 使用ORDER BY 时对数据进行排序的速度（例如，如果大部分是预排序的，排序会更快）
• 从磁盘读取数据的速度，基于区域映射

虽然您可能希望选择提高排序速度的SORTKEY（例如Change order of sortkey to descending），但SORTKEY 的主要好处是通过使用区域最小化磁盘访问来使查询运行得更快地图。

我承认似乎没有很多关于区域地图如何工作的文档，所以我会在这里尝试解释一下。

Amazon Redshift 以 1MB 块的形式将数据存储在磁盘上。每个块包含与一个表的一列相关的数据，该列的数据可以占用多个块。块可以被压缩，因此它们通常包含超过 1MB 的数据。

磁盘上的每个块都有一个关联的区域图，用于标识该块中要存储的列的最小值和最大值。这使 Redshift 能够跳过不包含相关数据的块。例如，如果SORTKEY 是时间戳，并且查询具有将数据限制在特定日期的WHERE 子句，则 Redshift 可以跳过所需日期不在该块内的任何块。

一旦 Redshift 找到具有所需数据的块，它会将这些块加载到内存中，然后将对加载的数据执行查询。

当它只需要从磁盘加载尽可能少的块时，查询将在 Redshift 中运行得最快。因此，最好使用通常匹配WHERE 子句的SORTKEY，例如数据通常受日期范围限制的时间戳。有时将SORTKEY 设置为与DISTKEY 相同的列是值得的，即使它们用于不同的目的。

可以通过STV_BLOCKLIST 虚拟系统表查看区域地图。此表中的每一行包括：

• 表 ID
• 列 ID
• 区块编号
• 存储在此块中的字段的最小值
• 此块中存储的字段的最大值
• 已排序/未排序标志

我怀疑在清空表后设置了 Sorted 标志。但是，表不一定需要被清理。例如，如果数据始终按时间戳顺序附加，则数据已经在磁盘上排序，从而使区域地图能够最有效地工作。

您提到您的 SORTKEY 是“使用 3 个字段的复合键”。这可能不是最好的 SORTKEY 使用。可能值得对具有不同 SORTKEY 的表运行一些计时测试，以确定复合 SORTKEY 是否比使用单个 SORTKEY 更好。如果所有 3 个字段都经常在 WHERE 子句中使用，那么复合键可能会表现最好。