我们正在考虑使用 Amazon Redshift 来实施我们的数据仓库，我想要一些关于如何在 Redshift 中正确设计架构的建议。
我对 Redshift 完全陌生。过去在使用“传统”数据仓库时，我习惯于创建“Source”、“Stage”、“Final”等模式，以根据数据所处的阶段对所有数据库对象进行分组。
默认情况下，Redshift 中的数据库有一个名为 PUBLIC 的模式。那么，我想问那些使用过 Redshift 的人，我上面概述的方法是否适用于这里？如果没有，我会喜欢一些建议。
谢谢。
【问题讨论】：
标签： amazon-web-services amazon-redshift data-warehouse
您可以在一个 Redshift 集群中拥有多个数据库，但我会坚持使用一个。您是正确的，模式（本质上是名称空间）是划分事物的好方法。您可以跨架构查询，但不能跨数据库查询。
我会避免使用公共架构，因为管理某些权限可能很困难（例如，拒绝某人访问公共权限比阻止他们创建表更容易）。
如果您有时间，为了获得最佳效果，请提前了解权限系统。您想create groups that have access to schemas or tables 并从组中添加/删除用户以控制他们可以做什么。一旦你做到了，它就会变得很容易管理。
【讨论】：
凭借我使用 Redshift 的经验，我可以自信地断言以下几点：
多个架构：您应该创建多个架构并相应地创建表。当您进行缩放时，您可以更轻松地确定表格的确切位置。假设您有 3 个架构，分别名为 production、aggregates 和 rough。现在，您知道表 production 将包含不应更改的表（主要是 OLTP 数据） - 例如 user, order, transactions 表。表 aggregates 将具有基于原始表构建的聚合数据 - 例如 number of orders placed per user per day per category。最后，rough 将包含任何不包含业务逻辑但需要一些临时工作的表 - 让我们检查电影类型以获取 10 万用户的列表，其中在 Excel 文件中与您共享。只需在rough 模式中创建一个表，执行您的操作并删除该表。现在，您可以根据它们是原始表、聚合表还是临时表，非常清楚地知道在哪里可以找到这些表。
公共架构：忘记它的存在。任何没有以模式名称开头的表都会在那里创建。很多混乱 - 在那里存储任何重要数据毫无意义。
花一些时间来设计架构和基础表结构。当您扩展时，您可以更轻松地根据访问控制对事物进行更好的分类。如果我遗漏了一些明显的要点，请告诉我。
【讨论】：
除了其他响应之外，这里还有一些提高架构性能的建议。
首先：使用 COPY 命令自动压缩编码
使用 COPY 命令提高 Amazon Redshift 的性能。它将数据输入 Redshift 数据库。 COPY 命令足够聪明。它会自动为其上传的数据选择最合适的编码设置。你不必考虑它。但是，它仅适用于第一次将数据上传到空表中。
因此，请确保在首次上传数据时使用重要的数据集，Redshift 可以评估该数据集以最佳方式设置列编码。上传几行测试数据会使 Redshift 搞不清楚如何最好地优化压缩以处理实际工作负载。
第二：使用最佳的分发方式和密钥
分布风格决定了数据如何在节点之间分布。在表级别应用分布样式会告诉 Redshift 您希望如何分布表和密钥。因此，如何指定分布样式对于使用 Redshift 获得良好的查询性能很重要。您选择的样式可能会影响对数据存储和集群的要求。它还会影响 COPY 命令执行的时间。
我建议将分布样式设置为所有尺寸较小的表格。对于大维度，将维度和关联的事实都分布在它们的连接列上。要优化第二个大维度，请获取存储命中并分发 ALL。您甚至可以将维度列设计成事实。
第三：使用最佳排序键
Redshift 数据库在表中维护数据，如果指定了排序键列的排列方式。因为它是在每个分区中排序的；每个集群节点都以预定义的顺序维护其分区。 （在设计 Redshift 架构时，还要考虑对预算的影响。根据存储的数据量和节点数量，Redshift 为 priced。）
排序键显着优化了 Amazon Redshift 性能。您可以通过多种方式做到这一点。首先，使用数据过滤。如果 where-clause 过滤排序键列，它会跳过整个数据块。这是因为 Redshift 以块的形式保存数据。每个区块头记录最小和最大排序键值。过滤超出该范围，可能会跳过整个块。
或者，当连接两个表时，按照它们的联合键排序，数据以匹配的顺序读取。此外，您可以合并加入而无需单独的排序步骤。使用这种方法将大维度连接到大事实表将很容易，因为它们都不适合哈希表。
【讨论】：