用Amazon Redshift 强化企业级数据保险库

使用Amazon Redshift构建企业级数据仓库 第一部分

关键要点

在本文中，我们探讨了如何使用Amazon Redshift设计企业级数据仓库Data Vault的最佳实践，重点关注其架构和功能。Amazon Redshift提供了灵活性和高性价比，使其成为构建和维护数据仓库的理想选择。通过理解数据仓库的组成部分和设计原则，用户能够高效组织和管理数据，从而有效支持业务需求。

Amazon Redshift是一款流行的云数据仓库，提供完全托管的云服务，能够无缝集成组织的Amazon简易存储服务Amazon S3数据湖、实时流、机器学习ML工作流、事务性工作流等，同时提供比其他云数据仓库高出多达79倍的性价比。

正如所有AWS服务一样，Amazon Redshift以客户为中心，了解到在数据模型方面并没有一种通用的解决方案，因此其支持多种数据模型，例如星型模式、雪花模式和数据仓库Data Vault。本文讨论了使用Amazon Redshift设计不同规模企业级数据仓库的最佳实践；而第二部分将讨论在设计企业级数据仓库时最紧迫的需求以及Amazon Redshift如何满足这些需求。

无论是为了在数据仓库中轻松保留数据溯源、建立源系统无关的数据模型，还是更容易遵守GDPR法规，实施数据仓库模型的客户将从本文讨论的考虑因素、最佳实践和与构建企业级数据仓库相关的Amazon Redshift功能中受益。构建任何事物的初学者版本通常相对简单，但要构建具备企业级规模、安全性、弹性和性能的系统，通常需要遵循经过验证的最佳实践，并在合适的场景中使用合适的工具和功能。

数据仓库概述

让我们首先简要回顾一下数据仓库的核心理念和概念。数据模型为数据仓库中的数据如何组织到数据库表中提供了框架。Amazon Redshift支持多种数据模型，其中一些最受欢迎的数据模型包括星型模式和数据仓库。

数据仓库不仅是一种建模方法，它还是一个提供针对数据生态系统中某些问题解决方案的框架。一个独立框架提供了一套指导方针和惯例，开发人员期望遵循，而不是将所有决策留给开发人员。这可以与大企业框架如Spring或Micronauts开发企业级应用程序时的做法进行比较。这在大型数据仓库项目中尤为有用，因为它结构化了您的抽取、加载和转换ELT管道，并清晰地告诉您如何在数据和管道上下文中解决某些问题。这也允许高程度的自动化。

数据仓库20允许以下功能：

然而，数据仓库20也存在成本问题，并有一些场景并不适合，例如：

数据仓库通常将组织的数据组织成四个层次的管道：暂存层、原始数据仓库RDV、业务数据仓库BDV和展示层。暂存层代表数据的摄取，以及在数据进入其更永久的存放处原始数据仓库之前发生的轻微数据转换和增强。

原始数据仓库RDV保存来自多个源系统的所有数据的历史副本。之所以称之为原始，是因为在此之前，未进行任何过滤或业务转换，仅将数据存储在无源系统依赖目标中。RDV将数据组织为三种主要类型的表：

RDV用于将数据馈送到业务数据仓库BDV，该 BDV 负责将数据重新组织、去规范化和聚合，以便优化展示层或称为数据集市的消费。展示层进一步调整数据，以优化下游客户端如业务仪表板的消费。展示层可能会将数据重新组织为星型模式。

有关数据仓库的更详细概述以及在非常有趣的用例背景下的适用性讨论，请参阅以下链接：

数据仓库在现代数据架构中的作用

目前，湖仓理念正成为数据仓库设计中的一个主要模式，甚至作为数据网格架构的一部分。这遵循数据湖靠近数据仓库功能的模式，反之亦然。为了与数据湖的灵活性竞争，数据仓库是一个良好的选择。这样，数据仓库不会成为瓶颈，您可以在数据摄取和新数据上载时实现类似的敏捷性、灵活性、可扩展性和适应性。

平台灵活性

在本节中，我们讨论了不同规模的数据仓库的推荐Redshift配置。如前所述，数据仓库平台中的各层是众所周知的。我们通常会看到从暂存层流向RDV、BDV，最后到展示层的流程。

Amazon Redshift对如何结构这些层具有高度灵活性，支持从适度到大规模的数据仓库，提供如下功能：

适度与大规模的数据仓库

Amazon Redshift在您决定如何构建这些层方面非常灵活。对于适度的数据仓库，一个Redshift仓库以及一个包含多个模式的数据库就足够了。

对于拥有更复杂转换的大规模数据仓库，我们会考虑多个仓库，每个仓库都有自己的模式，代表一个或多个层。使用多个仓库的原因是充分利用Amazon Redshift架构的灵活性，以实施大规模的数据仓库实现，例如使用Redshift RA3节点和Redshift Serverless将计算层与数据存储层分离，并使用Redshift数据共享在不同的Redshift仓库之间共享数据。这使您能够根据处理复杂性独立扩展每个层的计算能力。例如，暂存层可以是您数据湖内的一层Amazon S3存储或在Redshift数据库中的一个模式。

使用Amazon Aurora零ETL集成与Amazon Redshift，您可以创建一个具有暂存层的数据库数据仓库，该数据库在Amazon Aurora中实时处理交易数据，并将数据自动迁移到Amazon Redshift，以便在数据仓库实现中进一步处理，而无需创建复杂的ETL管道。这样，您可以使用Amazon Aurora进行事务处理，并使用Amazon Redshift进行分析。计算资源针对相同数据进行了隔离，并且您正在使用最有效的工具进行处理。

大规模数据仓库

对于大规模数据仓库平台，并发与计算能力成为处理数据加载和任何业务转换的重要因素。Amazon Redshift提供灵活性，使您能够在不同的数据仓库层级中以并发扩展和集群缩放以及对每一层采用不同架构的方式来增加计算能力。

暂存层

您可以为暂存层创建一个数据仓库，在这里执行严格的业务规则处理，包括计算哈希键、哈希差异以及添加技术元数据列。如果数据不是24/7加载，考虑使用暂停/恢复或Redshift Serverless工作组。

原始数据仓库层

对于原始数据仓库RDV，建议要么创建一个Redshift仓库来处理整个RDV，要么为RDV中的一个或多个主题区域创建一个Redshift仓库。例如，如果某个主题区域中的数据量和规范化表的数量很大要么原始数据层有太多表，以至于达到Amazon Redshift的最大表限制要么单个Redshift仓库的工作负载隔离优势超过了性能和管理的开销，那么RDV中的这个主题区域可以在自己的Redshift仓库中运行和管理。

RDV通常是24/7加载，因此，托管的Redshift数据仓库可能最适合在这里利用保留实例定价。

业务数据仓库层

创建业务数据仓库BDV层的数据仓库时，由于BDV处理的性质，这可能会比之前的数据仓库大，通常要从大量源RDV表中对数据进行去规范化。

一些客户使用每天运行BDV处理，因此，对于Redshift托管集群，暂停/恢复窗口可能在这里更具成本效益。您也可以在Amazon Redshift Serverless仓库上运行BDV处理，这会在工作负载完成时自动暂停，并在再次开始处理工作负载时重新启动。

展示数据集市层

为一个或多个数据集市创建Redshift托管或无服务器仓库时，这些集市中的模式通常包含视图或物化视图，因此将在数据集市和前面层之间建立一个Redshift数据共享。

我们需要确保在这个层级有足够的并发性来应对增加的读取流量。这通过使用多个只读仓库和数据共享或通过使用并发扩展进行自动扩展来实现。

示例架构

下图展示了适度的数据仓库模型的示例平台。

下图展示了大规模数据仓库模型的架构。

数据仓库数据模型设计原则

在本节中，我们讨论了加入和过滤数据表访问时的推荐设计原则。这些指导原则针对不同的实体类型访问组合，但应根据每个客户的特定用例进行测试以确保适用性。

首先，让我们简要回顾一下Amazon Redshift中的表分布样式。表的数据可以在Redshift集群中的不同计算节点之间分布，有四种方式：ALL、KEY、EVEN和AUTO。

中心与卫星表

中心表和卫星表通常是一起连接的，因此最好根据中心表的主键共同定位这些数据集，主键也将成为每个卫星的复合键。对于较小的数据量通常少于500700万行，使用ALL分布样式；对于较大的数据量，使用KEY分布样式主要键列为分布KEY列。

链接与卫星表

链接表和卫星表通常也会一起连接，因此最好根据链接的主键联合定位这些数据集。这通常涉及较大的数据量，因此应考虑使用KEY分布样式主键列为分布KEY列。

时间点与卫星表

您可能决定通过将关键卫星属性加入时间点PIT表来去规范化，以减少或消除运行时的连接。由于去规范化数据有助于减少或消除运行时连接的需求，去规范化的PIT表可以定义为使用EVEN分布样式以优化表扫描。

如果您选择不去规范化，则较小的数据量应使用ALL分布样式，较大的数据量应使用KEY分布样式主键列为分布KEY列。同时，务必将业务主键列定义为PIT表的排序键，以优化过滤。

桥接和链接卫星

与PIT表类似，您也许希望通过将关键卫星属性添加到桥接表中进行去规范化，目的是减少或消除运行时连接。虽然去规范化数据有助于减少或消除运行时连接的需求，但去规范化的桥接表通常在数据量上仍然较大，并涉及频繁连接，因此推荐使用KEY分布样式主键列为分布KEY列。还要确保将主业务键列定义为桥接表的排序键，以优化过滤。

关键绩效指标KPI与报告表

KPI和报告表旨在满足每个客户的特定需求，因此其结构的灵活性至关重要。这些表通常是独立的，表现出多种类型的交互，因此EVEN分布样式可能是最好的选择，以平均分配扫描工作负载。

确保选择一个基于常见WHERE条件的排序键，例如date[time]元素或常见业务键。此外，可以为非常大的数据集创建时间序列表，通常使用时间属性进行切片以优化与时间片段交互的工作负载。我们将在后面的文章中对这一主题进行更深入的讨论。

非功能设计原则

在本节中，我们讨论了通常与业务数据结合以满足非功能性要求的潜在附加数据维度。在物理数据模型中，这些附加数据维度以技术列的形式出现，添加到每一行以实现对非功能性要求的跟踪。这些技术列中的许多将由数据仓库框架填充。下表列出了常见技术列，但您可以根据需要扩展此列表。