亚马孙-Redshift-权威指南-全-

亚马孙 Redshift 权威指南（全）

原文：zh.annas-archive.org/md5/c21b4d7a66ecf910d571f88f5162d065

译者：飞龙

协议：CC BY-NC-SA 4.0

序言

在当今数据驱动的世界中，组织不断寻求从其可用的大量数据中提取可操作的业务洞察，并通过提供无缝的客户体验和优化业务运营来将其转化为竞争优势。高效存储、管理和为组织中的所有用户提供安全和合规的数据访问能力是一项关键要求，这需要重新思考传统的数据架构。在过去十年中，云数据仓库已经成为现代数据架构的核心支柱。

Amazon Redshift 是由 Amazon Web Services（AWS）开发的首个云数据仓库，自 2013 年推出以来一直处于革命前沿，使企业能够以成本效益的方式扩展其数据仓库，释放数据的全部潜力。成千上万的组织已将 Amazon Redshift 作为其现代数据战略的基础数据存储，以满足广泛的分析需求。作为数据领袖，我很高兴为 Amazon Redshift 引入这本全面指南，它既适合经验丰富的数据专业人士，也适合初涉云数据仓库世界的人员。

在《Amazon Redshift: The Definitive Guide》中，作者采用解决方案架构的方法，提供实用的见解、最佳实践和真实世界的示例，帮助您充分利用这项服务的全部功能。作者们在为从初创公司到全球组织的数百个客户构建解决方案方面拥有丰富的经验。特别是，他们帮助了从其他数据仓库迁移到 Amazon Redshift 并在大规模上高性能运行的项目，以及通过 Redshift 流摄入和零 ETL 提供实时分析等新分析用例的实现，还通过 Redshift ML 构建预测分析解决方案，甚至通过 Redshift 数据共享等强大功能提供分析服务。

本书从打下现代数据战略的基础开始，解释了数据仓库的基本概念和 Amazon Redshift 的架构。作者们深入探讨了该服务的关键特性，并配以相关示例，涵盖了数据建模、加载和转换数据（包括流式摄入）、性能优化、扩展和安全最佳实践。您还将找到与 Amazon SageMaker、Amazon Aurora 等 AWS 其他服务的深入整合，确保能够利用更广泛的 AWS 生态系统来构建强大和可扩展的数据应用程序。

这本书与众不同的地方在于其实用性方法。作者们借鉴了他们作为解决方案架构师在亚马逊 Redshift 工作经验，提供了实际应用案例，这些案例将帮助您按最佳实践构建可伸缩的数据架构。从寻求对组织数据战略做出明智决策的高管，到负责策划和管理数据的数据工程师，或者从数据中获取业务洞见的数据分析师，这本书对各类读者都有所帮助。

随着我们继续在日益复杂的数据景观中航行，围绕亚马逊 Redshift 构建数据策略可以帮助您简化数据架构。除了数据管理，亚马逊 Redshift 还可以成为您组织中创新的催化剂，帮助您以规模和速度获得有意义的洞见。我已经看到亚马逊 Redshift 对企业产生的转型性影响，我相信这本书将使您在数据旅程中取得类似的成功。

我赞扬作者们的主动性和努力，创建了这本关于 Amazon Redshift 的全面指南。这本书包含的信息将帮助读者开始他们在云上数据现代化之旅，或者仅仅是想了解数据架构模式的读者。我鼓励您学习并应用本书中提出的原则和技术，推动您的组织成为数据驱动型，并改善客户体验。

Neeraja Rentachintala

亚马逊 Redshift 产品管理总监

前言

欢迎来到数据仓库和亚马逊 Redshift 的世界！在本书中，我们将踏上一段充满挑战和乐趣的旅程，探索亚马逊 Redshift 强大的能力以及其在现代数据仓库中的角色。无论您是数据专业人士、架构师、IT 领导，还是对数据管理和分析感兴趣的普通读者，本书旨在为您提供对使用亚马逊 Redshift 进行现代数据仓库模式的全面见解。

数据在现代业务运营中发挥着关键作用，作为推动增长的宝贵资产，支持基于信息的决策。在当今数字化时代，企业从各种来源生成和收集大量数据，包括客户互动、市场趋势、社交媒体、设备和操作过程。通过利用和分析这些数据，企业可以通过识别模式和相关性来进行基于数据驱动的决策，并推动创新，从而获得竞争优势。随着数据量、速度和多样性的急剧增长，对于企业拥有能够处理当今数据驱动世界需求的高效可扩展数据仓库解决方案变得越来越关键。

亚马逊 Redshift 作为一种完全托管的基于云的数据仓库服务，在行业中已经成为领先解决方案，使组织能够存储、分析并从其庞大数据集中获取可操作见解。凭借其灵活的架构、高性能的处理能力以及与其他亚马逊网络服务（AWS）的集成，亚马逊 Redshift 为构建强大和可扩展的数据仓库提供了平台。

亚马逊 Redshift 一直处于 Gartner 数据库管理系统（DBMS）魔力象限的前沿，本书将进一步深入探讨如何成功地在 AWS 的这一数据仓库服务上实施您的分析解决方案。亚马逊 Redshift 已经从一个独立的分析查询引擎发展为一个利用机器学习作为核心特性的 AI 驱动数据仓库服务，其功能包括自动工作负载管理、Autonomics 和 Query Editor 中的 CodeWhisperer。

在本书中，我们深入探讨了数据仓库的基本概念和原则，涵盖了数据建模、提取、转换和加载过程、性能优化以及数据治理等主题。我们探索了亚马逊 Redshift 的独特功能和优势，并指导您完成设置、配置和管理 Redshift 集群的过程。我们还讨论了数据加载、架构设计、查询优化和安全考虑的最佳实践。

本书同样适用于完全不熟悉数据仓库的人员，或者那些希望通过利用云的力量来现代化当前本地解决方案的人员。各章节首先介绍 Amazon Redshift 服务，重点转向第九章中的迁移。但我们建议对迁移到 Amazon Redshift 感兴趣的读者可以根据需要提前查阅第九章。

我们结合了使用 Amazon Redshift 的个人经验，以及与使用 Amazon Redshift 的客户的互动，这是我们从日常工作中获得的特权。同时，与实际产品团队和工程团队密切合作，帮助我们在整本书中分享一些有趣的内容。

我们花了将近一整年的时间来完成这本书。AWS 根据客户反馈不断发展其服务，每隔几个月推出新功能，我们期待看到这本书很快会“过时”，或者说，我们为此感到骄傲！

随着每一章的进展，您将更深入地了解如何利用 Amazon Redshift 的强大功能构建现代化数据仓库，支持大数据量、复杂分析查询，并促进实时洞察。我们提供实际示例、代码片段和现实场景，帮助您将概念和技术应用到自己的数据仓库项目中。

请注意，本书假设读者对 Amazon Redshift 或数据仓库概念没有先前的了解。我们从基础知识开始，逐步深入，确保各个层次的读者都能从这本全面指南中受益。无论您是刚开始数据仓库之旅，还是希望增强现有知识，本书都将作为宝贵的资源和参考资料。

不多说了，让我们一起踏上这段充满激情的 Amazon Redshift 数据仓库之旅吧。愿本书成为您的忠实伴侣，为您提供构建可扩展、高性能数据仓库所需的知识和工具，将您组织的数据转化为战略资产。

祝阅读愉快，愿您的数据工作取得成功！

本书中使用的约定

本书使用以下排版约定：

斜体

指示新术语、URL、电子邮件地址、文件名和文件扩展名。

常量宽度

用于程序列表以及段落中引用程序元素，例如变量或函数名称、数据库、数据类型、环境变量、语句和关键字。

常量宽度加粗

显示用户应按照字面意义输入的命令或其他文本。

常量宽度斜体

显示应由用户提供值或由上下文确定值的文本。

此元素表示提示或建议。

此元素表示一般说明。

此元素指示警告或注意事项。

使用代码示例

补充资料（代码示例，练习等）可在https://resources.oreilly.com/examples/0636920746867下载。

如果您有技术问题或使用代码示例的问题，请发送电子邮件至bookquestions@oreilly.com。

本书旨在帮助您完成工作。通常情况下，如果本书提供示例代码，您可以在您的程序和文档中使用它。除非您复制了大部分代码，否则无需征得我们的许可。例如，编写一个使用本书多个代码片段的程序不需要许可。销售或分发 O’Reilly 书籍中的示例需要许可。引用本书并引用示例代码来回答问题不需要许可。将本书中大量示例代码整合到产品文档中需要许可。

我们欣赏但通常不需要署名。署名通常包括标题，作者，出版商和 ISBN。例如：“Amazon Redshift: The Definitive Guide by Rajesh Francis, Rajiv Gupta, and Milind Oke (O’Reilly). Copyright 2024 Rajesh Francis, Rajiv Gupta, and Milind Oke, 978-1-098-13530-0.”

如果您认为您对示例代码的使用超出了合理使用范围或上述许可，请随时与我们联系permissions@oreilly.com。

O’Reilly 在线学习

40 多年来，O’Reilly Media提供技术和商业培训，知识和见解，帮助公司取得成功。

我们独特的专家和创新者网络通过书籍、文章和我们的在线学习平台分享他们的知识和专长。O’Reilly 的在线学习平台为您提供按需访问的现场培训课程，深入学习路径，交互式编码环境，以及来自 O’Reilly 和 200 多个其他出版商的大量文本和视频。更多信息，请访问https://oreilly.com。

如何联系我们

请就本书的评论和问题联系出版商：

• O’Reilly Media, Inc.

• 1005 Gravenstein Highway North

• Sebastopol, CA 95472

• 800-889-8969（美国或加拿大）

• 707-829-7019（国际或本地）

• 707-829-0104（传真）

• support@oreilly.com

• https://www.oreilly.com/about/contact.html

我们为本书设有网页，列出勘误、示例和任何额外信息。您可以访问https://oreil.ly/amazon-redshift-definitive-guide。

关于我们的图书和课程的新闻和信息，请访问https://oreilly.com。

在 LinkedIn 上找到我们：https://linkedin.com/company/oreilly-media。

关注我们的 Twitter：https://twitter.com/oreillymedia。

在 YouTube 上观看我们：https://youtube.com/oreillymedia。

致谢

我们要感谢整个亚马逊 Redshift 客户群体，致力于开发这项服务的各个 AWS 团队，产品经理们，工程师们，解决方案架构师团队，以及产品营销团队。没有所有这些团队的支持，这一努力将根本不可能实现！

第一章：AWS 数据

在有数据之前进行理论推测是一个严重的错误。

Sherlock Holmes

数据是无处不在的，驱动着我们今天所做的一切。谁能想到仅通过行走就能生成数据，并在你打电话给朋友时实时监测你的步数？从手机、智能手表和网页点击到物联网（IoT），我们正在大量生成各种类型的数据，组织面临着从所有这些数据中提取意义以提供洞察的挑战。您必须分析这些数据，以简单的方式呈现无偏见的信息，供领导者做出业务决策。数据是推动洞察和预测、促进更好决策和创新的基础力量。尽管具有挑战性，但必须利用这些数据，重塑您的业务，以保持在现在和将来的相关性。Amazon Redshift 是一个完全托管的 PB 级云数据仓库服务，支持现代数据架构，可将来自所有来源的数据存储在集中或分散的架构中。它使您能够在数据仓库、数据湖和操作性数据库之间查询数据，获得其他方式无法实现的更快速和更深入的洞察。

在本章中，我们将涵盖亚马逊网络服务（AWS）数据框架的核心要素，包括是什么让“数据驱动的组织”成功，“现代数据战略”的核心要素，以及构建“现代数据架构”的要点。最后，我们将深入探讨一些流行的方法，组织如何利用“数据网格和数据布局”以可伸缩的方式满足每个分析用户群体的需求。

数据驱动组织

数据驱动的组织将数据视为一种资产；它们不仅使其对业务用户可用和可访问，而且对所有需要数据来做决策的人都可用，以便他们能做出更为明智的决策。这些组织认识到数据的内在价值，并意识到优质数据为组织及其经济影响带来的价值。它们民主化数据，并为业务决策者提供衡量关键绩效指标（KPIs）的数据。彼得·德鲁克归因于的名言“不能提升不可测量的事物”对当今的企业更为相关。

大多数企业都有一系列常规监控以推动增长和提高生产力的 KPI。这些 KPI 可能从常见的增长、销售、市场份额、客户数量和客户获取成本到更多领域特定的指标如销售量、产能利用率、电子邮件退出率或购物车放弃率。一个好的 KPI 是具体的、可测量的，并对整体业务目标有影响，可能会因企业而异。

虽然一些属性，如员工士气、信心和组织的诚信，实际上无法进行真正的衡量，但有很多可以进行测量和监控以实现进展。访问这些数据意味着领导者可以采取策略将企业朝特定方向发展。例如，一家制造商收购了一家电动工具公司后，直到他们的 IT 团队将数据集成到核心企业资源计划（ERP）系统中，他们才像是打开了灯，看清了他们在业务道路上的前进方向。执行官评论说，这对他们来说就像是开启了光明，让他们看到了这个业务的前进方向。

在他的书《信息经济学》（Gartner, Inc.）中，道格·兰尼讨论了组织超越仅仅思考和谈论信息作为资产的重要性，实际上评估和对待它作为一个资产。他认为信息应被视为一种新的资产类别，因为它具有可衡量的经济价值，并应像管理其他类型的资产一样加以管理。兰尼为企业提供了一个框架，以将信息作为实际资产进行货币化、管理和衡量。他谈到，货币化并不仅仅是卖数据或交换现金。它是关于实现信息价值，更广泛地思考影响客户并产生利润的方法。这是关于从客户需求和兴趣出发，逆向思考，将业务和运营策略与客户的优先事项对齐。分析帮助组织做出更好的决策，推动关键战略举措。它还帮助你改善与客户和业务伙伴的关系。

在 AWS re:Invent 2021 上，亚当·塞利普斯基谈到了佛罗伦萨·南丁格尔如何分析克里米亚战争期间士兵的死亡率。护士南丁格尔利用数据和分析得出一个结论，即大多数士兵不是在战斗中死亡，而是在医院因恶劣的卫生条件导致的可预防疾病中死亡。南丁格尔分析了她收集的数据，并创建了一个简单但强大的可视化图表（图 1-1），描述了士兵死亡原因的玫瑰图。这种玫瑰图，也称为极地面积图，允许在一个图表中进行多个比较，展示了每个月因疾病、伤口和其他原因的死亡率。这种可视化帮助南丁格尔说服维多利亚女王和将军们，更多士兵是因疾病而非伤口死亡，尤其是在冬季，突显了对医院改革和对士兵的关爱的需求。这是数据讲述影响的一个很好的例子；它确实改变了对话以帮助挽救生命。

图 1-1. 佛罗伦萨·南丁格尔的死因玫瑰图

今天，您可能期望能够即时获取洞察，并倾向于在数据到达后立即访问数据。有许多激励人心的数据驱动型公司的例子，它们通过使用分析工具专注于并适应客户偏好变化。全球新闻提供商道琼斯通过使用分析工具并使数据可访问，将其邮件沟通的回应率提高了 50%至 100%。Magellan Rx 现代化其数据仓库，能够通过更快地将药物推向市场和减少运营成本 20%，从而改善患者结果。Moderna 使用 Amazon Redshift 进行简单且具有成本效益的数据仓库，以避免信息孤岛并为整个组织建立真正的单一数据来源。纳斯达克将其不断增长的数据仓库迁移到更现代的数据湖架构，并能够通过 Amazon Simple Storage Service (S3) 和 Amazon Redshift 的灵活性和可伸缩性支持每天从 30 亿条记录增加到 70 亿条记录。Netflix 利用数据创造了像《纸牌屋》这样的大热剧集。他们的管理者通过分析媒体和娱乐行业数字化转型的数据，建立了以前不存在的利润市场。可口可乐安迪纳在南美生产和分销可口可乐公司授权的产品，通过创建一个数据湖提高了其分析团队的生产力 80%，该数据湖成为由 SAP ERP 和其他遗留数据库生成的数据的单一来源。

这些成功的数据驱动型公司的共同主题是数据民主化，并将洞察力交给决策者手中。拥有可靠的数据是获取可操作洞察力的基础，良好设计的数据架构和技术堆栈可以增强数据的可靠性。限制数据在组织内的流动是避免数据不一致的一种方式，可以增强数据的完整性和信任度。这并不一定意味着建立一个所有数据的单一存储库。使用 Amazon S3，你可以将来自不同来源的数据以不同格式存储在一个存储库中。但组织也在考虑从源系统或独立数据仓库中直接查询数据。这促使了数据网格和数据布置等新概念的产生，我们将在本章后面看到。那些以数据驱动为核心，并专注于建立与数据的信任和规模的组织，更有利于在市场竞争中获得实时洞察。

业务使用案例

从小企业到全球企业，数据和分析对于获取对业务或组织状态的洞察至关重要。我们挑选了一些常见的使用案例，以展示您如何在本书中使用 AWS 分析服务和特定数据模型获得业务洞察。让我们看看一些最常见的使用案例及分析如何提供业务成果。

供应链管理

随着电子商务对传统实体零售商的影响，公司必须利用分析来转变他们定义和管理供应链的方式。使用数据和定量方法，需求和供应规划者可以在整个供应链周期中改善决策制定。制造商和零售商可以应用统计方法来改善供应链决策，确保产品在适当的时间和地点供应给消费者。他们可以分析库存并根据需求信号计划供应。亚马逊是一个很好的例子，他们通过 Amazon Redshift 每天处理 51,000 个查询，以推动供应链的卓越表现。

金融

金融和银行组织帮助客户进行投资决策，并提供资金管理解决方案。如今，许多银行利用人工智能（AI）和机器学习（ML）来识别欺诈、预测客户流失，并积极参与以预防欺诈或客户流失。例如，您可能在度假或访问新地方时曾经遇到过信用卡被停用的情况。这就是机器学习在幕后工作，检测异常活动并在可能发生欺诈交易之前阻止。正确的数据的可用性和易访问性使这一切成为可能。

客户关系管理（CRM）

实施客户关系管理（CRM）数据仓储数据模型可以帮助企业整合来自多个接触点（如销售、营销和客户支持）的客户数据。通过分析这些数据，企业可以深入了解客户行为、偏好和满意度水平。这些信息可以用来个性化营销活动，改善客户服务，并促进长期客户关系。

教育

教育分析可以在学生的学习体验和结果中产生重大影响。传统的课堂教学方法对今天沉浸在数字世界的孩子们有其挑战。学校面临高辍学率、低效结果和过时的课程大纲等问题。转向个性化学习方法意味着学生可以利用灵活性，按自己的节奏学习。这也意味着采用混合学习，结合在线学习管理解决方案，能够为学习者提供定制内容。来自学生与在线学习环境的互动数据，再加上测试成绩的数据，可以用来分析并提供对学生可能需要额外帮助的见解。借助人工智能和机器学习，教育工作者可以预测个别学生的结果，并采取积极措施，以确保积极的结果和体验。

医疗保健行业

数据在医疗行业中发挥着关键作用，改革了提供患者护理、进行医学研究以及通过运营效率控制成本的方式。医疗组织可以利用数据的力量解锁有价值的洞见，推动基于证据的决策，以改善患者结果并提升整体医疗服务。通过在大型数据集中识别模式、趋势和相关性，医疗专业人员可以更深入地理解疾病和基于患者反应的治疗效果。通过预测分析，这些组织可以早期发现疾病，并为高风险患者群体提供个性化药物治疗。这些组织还可以通过分析索赔数据并识别欺诈活动的模式来检测虚假索赔。

利用生成式 AI 的新商业用例

生成式 AI 和数据仓库可以相辅相成，增强数据分析和决策过程的各个方面。接下来，我们将概述生成式 AI 如何与数据仓库集成的几种方式：

代码生成

生成式 AI 模型可以在广泛的代码仓库和编程语言上进行训练，以生成代码完成和建议。当开发人员编写代码时，AI 模型可以提供实时建议，帮助提高程序员的效率，通过建议或编写代码片段来完成。这也有助于减少错误，并提高整体开发者生产力，以更快地推向市场。

自然语言生成

数据仓库通常涉及从数据中提取洞见并以有意义的方式呈现给利益相关者。生成式 AI 模型可以基于仓库中存储的数据生成人类可读的报告或叙述。这也可以是描述性分析的自动化生成或总结，使决策者更容易理解和解释数据或报告的内容。

合成数据生成

要训练机器学习模型，数据的质量决定了预测的准确性。生成式 AI 模型可用于生成模拟真实数据特征的合成数据。这些合成数据可以与数据仓库中的实际数据结合使用，扩展数据集并为机器学习模型创建更全面和多样化的训练集。它有助于克服数据稀缺问题，提高分析模型的准确性和鲁棒性。

异常检测

生成式 AI 模型，如生成对抗网络（GANs），可以用于数据仓库中的异常检测。通过在正常数据模式上训练 GAN，它可以通过比较生成的数据与仓库中实际数据来学习识别异常。这可以帮助您检测到异常模式和离群值，以识别潜在的欺诈交易或操作。

数据填补和增强

不完整或缺失的数据可能会影响数据分析和决策的准确性。生成式 AI 技术可以通过学习现有数据中的潜在模式来填补缺失值。通过在现有数据上训练生成模型，它可以为缺失的数据点生成合理的值，填补空白并提升数据仓库的完整性。您可以基于现有数据扩充数据仓库中的现有数据集，生成新的合成样本，从而创建一个更大更多样化的数据集，用于训练分析模型。这可以提高机器学习算法的性能和泛化能力，从而实现更好的预测和洞察。

推荐系统

生成式 AI 技术可以通过为用户生成个性化推荐来增强推荐系统。通过利用存储在数据仓库中的用户行为数据，生成模型可以学习用户偏好并生成针对产品、服务或内容的个性化推荐。这有助于企业提升客户参与度，推动销售或用户满意度。

将生成式 AI 与数据仓库集成可以扩展数据分析的能力，增强数据质量，并支持高级分析和决策过程。然而，在生成和利用合成数据时，确保道德考虑、隐私和安全至关重要。

现代数据策略

数据引力的概念最早由 Dave McCrory 在 2010 年提出。在他的类比中，他将数据比作一个行星，并讨论了组织在一个地方收集数据时形成的数据质量。应用程序和服务被吸引到这个数据质量附近，因为接近数据会带来更好的性能和吞吐量。这加速了数据的增长，最终使得数据几乎不可能再移动。由物联网、智能设备、云应用和社交媒体生成的数据正在继续呈指数增长。您需要一种简单且具有成本效益的方法来分析所有这些数据，无论数据的格式或存储位置如何，以在最短时间内获取洞察。

数据位于每个应用程序、流程和业务决策的中心。它几乎是每个组织数字转型的基石。它推动新体验，并带来促进创新的洞见。但要制定一个能够为整个组织释放数据价值的策略并不容易和直接。数据系统通常是庞杂、孤立和复杂的，各种数据集散布在数据湖、数据仓库、云数据库、软件即服务（SaaS）应用程序、物联网设备和本地系统之间。许多组织掌握着丰富的数据宝库，但不知道从何处着手获取其价值。企业难以掌握所有数据的位置，如何有效连接和处理这些数据，并管理对这些数据的访问。随着数据量的增长，这些问题只会变得更加棘手。无法有效利用数据会妨碍快速决策和持续创新。

要挖掘数据的价值，组织需要的不仅仅是单一数据库、数据湖、数据仓库或商业智能服务。事实上，每个组织都有多种用例、数据类型、用户和应用程序，这些需要不同的工具。这些需求会随时间演变。要真正释放数据的价值，驱动及时洞见和创新，您需要实施一个端到端的数据战略，在数据旅程的每一步都让数据处理更加轻松，以满足组织中每个需要数据的人员的需求。端到端数据战略结合了工具、资源和流程，用于数据摄取、存储和查询、分析数据以及构建机器学习模型，最终帮助最终用户开发基于数据驱动的洞见。这种端到端数据战略必须具备：

适用于任何数据用例的全面功能集

一个全面的工具集，考虑到当前和未来使用数据的规模、多样性以及多种目的。

一套集成工具，轻松连接所有数据

整合存储和分析不同工具和系统中的数据能力，以更好地理解您的业务并预测未来发展。

端到端数据治理

管理所有数据的治理，确保在用户需要时在何地安全地提供数据访问权限。

使用这三大支柱（如图 1-2 所示），您可以规模化存储不断增长的数据，无缝访问这些数据，并通过安全和治理控制管理数据访问权限。

图 1-2. 端到端现代数据战略的支柱

AWS 为您提供了一整套数据服务中所需的能力，具备内置智能和自动化功能，助您实施端到端的数据战略。让我们更深入地了解每个支柱及其涵盖的内容。

全面的能力集

要了解您的业务并随着工作负载的变化进行扩展、简化流程并做出更好的决策，您需要构建能够满足现在和未来需求的数据策略。有效利用数据不仅仅需要单一的数据湖、数据仓库或商业智能工具，还需要一套全面的工具集，考虑到数据的规模、多样性以及您希望使用它的多种目的。

您可以在数据旅程的各个阶段现代化您的数据架构，这意味着摆脱遗留数据库并转向完全托管和专为特定用途设计的数据服务。如果您正在运行遗留的本地数据存储或在云中自我管理的数据库，您仍然需要处理诸如数据库配置、补丁管理和备份等管理任务。通过过渡到 AWS 云或其他超大规模云服务提供商的托管服务，您可以受益于云提供商在托管和管理应用程序方面的经验、成熟性、可靠性、安全性和性能。

要实现端到端数据策略，您需要将数据存储在针对您的工作负载优化的数据库中，从多个来源进行集成，并使用他们选择的工具使业务决策者能够访问信息并采取行动。如图 1-3 所示，AWS 提供了一套全面的数据能力，用于存储、集成、执行和管理各种类型的数据工作负载。采用一种适合所有情况的方法来现代化分析平台最终可能会导致妥协，因此 AWS 提供了专为支持各种数据模型设计的目的构建引擎，包括关系型、键值、文档、内存、图形、时间序列、宽列和分类账数据库。这些能力集帮助您在数据存储的任何位置访问数据、分析数据并根据洞察行动。

图 1-3. 端到端数据策略

这些数据服务和分析工具针对特定类型的工作负载进行了优化，AWS 提供了工具来集成和管理存储在专为特定用途设计的数据服务中的数据。

AWS Glue

一个无服务器、可扩展的抽取、转换和加载（ETL）以及数据集成服务，使发现、准备、移动和集成来自多个来源的数据以进行分析和机器学习变得更加容易。

亚马逊 DynamoDB

一个完全托管的、无服务器的键值 NoSQL 数据库，旨在以任意规模运行高性能应用程序。DynamoDB 提供内置安全性、持续备份、自动多区域复制、内存缓存以及数据导入和导出工具。

亚马逊 EMR

一个大数据解决方案，用于在云上处理 PB 级数据，具备交互式分析和机器学习能力，使用诸如 Apache Spark、Apache Hive 和 Presto 等开源框架。

OpenSearch

一个分布式、社区驱动、Apache 2.0 许可的开源搜索和分析套件，用于广泛的用例，如实时应用监控、日志分析和网站搜索。

Amazon Simple Storage Service（Amazon S3）

一种对象存储服务，提供高可扩展性、数据可用性、安全性和性能。您可以存储和保护结构化和非结构化数据，用于数据湖、云原生应用和移动应用等用例。

Amazon QuickSight

一种为用户提供的无服务器服务，通过现代交互式仪表板、分页报告、嵌入式分析和自然语言查询，帮助您从同一真实数据源满足各种分析需求。

Amazon Kinesis

使收集、处理和分析实时流数据变得简单，使您能够及时获取见解并快速对新信息做出反应。Amazon Kinesis 提供能力以成本效益的方式处理规模化的流数据，同时灵活选择最适合应用程序需求的工具。

Amazon Redshift

一个在云中完全托管的 PB 级数据仓库服务。使用 Amazon Redshift，您可以通过符合性、安全性和治理现代化云数据仓库，并利用扩展功能来满足您的可变需求。您可以安全地摄取、组合和运行历史、实时或预测性分析，使用无服务器或预配部署选项处理所有数据。

Amazon SageMaker

一个完全托管的服务，用于准备数据和构建、训练和部署任何用例的机器学习模型，提供完全托管的基础设施、工具和工作流程。

这些服务紧密集成并能相互通信，以利用彼此的数据。

一套集成工具

最有影响力的数据驱动洞见来自于全面了解您的业务和客户的全貌。只有当您在多个部门、服务、本地工具和第三方应用（如商业智能系统或统计建模工具）之间连接数据源时，才能实现这一点。通常，跨不同数据源连接数据需要数据复制或复杂的 ETL 管道，这可能需要数小时，甚至数天的时间。这只是不够快以跟上决策速度。ETL 需要更简单化，甚至在许多情况下需要消除。

伟大的业务领袖看到了在价值链上实现业务转型的机会。但要实现这样的转型，需要数据来帮助决策者全面了解业务并建立真实的单一数据源。这需要打破数据孤岛，以安全的方式使数据可访问和共享，从而释放组织中数据的价值。

要快速做出决策，您需要新的数据存储，这些存储将随着业务需求的变化而扩展和增长。您还希望能够将所有内容连接在一起，包括数据湖、数据仓库和所有目的构建的数据存储，形成一个安全且良好治理的连贯系统。

要实现这种综合视图，有多种方法：联合查询、低代码/无代码数据同步，或传统的使用无服务器或服务器执行的 ETL。Amazon Redshift 为这些方法提供了选择，与其他 AWS 服务紧密集成。Amazon Aurora 与 Amazon Redshift 之间的零 ETL 功能使您能够将事务数据近乎实时地同步到数据仓库中。Amazon Redshift 允许从您的 Amazon S3 数据湖中查询数据，而联合查询功能则允许从操作数据库安全地直接查询数据。对于需要隔离计算的分析工作负载，您可以构建 ETL 管道，将数据提取、转换并加载到目标数据存储中。与 AWS Glue 的紧密集成允许您在 AWS Glue Studio 中轻松创建基于 Spark 的作业，并使用无服务器框架执行。有关 Amazon Redshift 数据转换策略的更多详细信息，请参见第四章，“数据转换策略”。

为了向数据分析师和数据科学家公开您的数据，Amazon Redshift 简化了访问路径。过去，机器学习局限于高技能的数据科学家或具有 Python、R 等编程语言深度技能的程序员。通过与 Amazon SageMaker 的紧密集成，Amazon Redshift 数据分析师可以使用 Amazon Redshift ML 从数据仓库或数据湖内运行机器学习工作负载，而无需选择、构建或训练 ML 模型。有关 Amazon Redshift 机器学习的更多详细信息，请参见第六章，“Amazon Redshift 机器学习”。此外，业务分析师可以使用 Amazon QuickSight 等工具自动发现他们的 Amazon Redshift 数据仓库，并连接到数据存储，快速生成具有业务见解的有影响力的仪表板。有关到达 Amazon Redshift 数据仓库的不同选项的更多详细信息，请参见第二章，“开始使用 Amazon Redshift”。

全流程数据治理

建立正确的治理机制可以帮助您平衡控制与访问权限，并使组织内的人员对数据充满信任和信心。它鼓励创新，而不是限制，因为合适的人员可以在需要时快速找到、访问和共享数据。

为了激发创新，组织应该支持数据安全的概念，意味着如何以安全的方式释放您的数据，而不是意味着如何保护数据并限制用户访问。在 AWS 上进行端到端的数据治理，您可以在数据工作流的每个步骤控制数据的位置、访问者以及可以对其执行的操作。

对于数据工程师和开发人员，AWS 在服务如 AWS Glue 和 AWS Lake Formation 中提供了精细的控制、目录和元数据。AWS Glue 使您能够在数据湖、数据仓库和数据库中对数据进行目录化。AWS Glue 还具有数据质量规则，用于检查数据的新鲜度、准确性和完整性。通过 AWS Lake Formation，您可以管理和审计在 Amazon S3 数据湖上的数据操作以及在 Amazon Redshift 中的数据共享。如果您在 Amazon S3 上拥有数据湖，您还可以使用 Amazon S3 访问点创建唯一的访问控制策略，轻松控制对共享数据集的访问。

数据科学家可以使用 SageMaker 中的治理控制来获得对 ML 模型的端到端可见性，包括训练、版本历史和模型性能，一切尽在一个地方。

最后，Amazon DataZone 是一个数据管理服务，用于目录化、发现、共享和治理数据。它使数据工程师、数据科学家、产品经理、分析师和其他业务用户能够发现、使用和共享数据，从而为您的业务带来洞察。

总结一下，越来越清楚的是，利用数据是数字转型的下一个浪潮。现代化意味着统一数据湖和专用数据存储的最佳方案，并使其易于通过 ML 进行创新。通过全面性、集成性和治理性这三大支柱，AWS 的现代数据战略可以帮助您构建根据需求扩展并降低运营成本的架构。

现代数据架构

当你着手进行现代数据战略时，你必须考虑如何以低成本处理任意数量的数据，并且使用开放的、基于标准的数据格式。该战略还应该让你打破数据孤岛，使团队能够使用他们喜欢的工具或技术进行分析或机器学习，并管理谁可以访问数据，确保适当的安全性和数据治理控制。

要执行现代数据策略，您需要一个现代数据架构。您可能听说过数据仓库、数据湖和数据网格，您可能也在考虑其中一种策略。数据仓库使您能够存储结构化数据并在大量数据上进行快速查询访问。数据湖是一个中央仓库，您可以在其中存储所有结构化和非结构化数据，并轻松访问。数据网格允许您在原地访问数据，同时分散数据的所有权和治理。现代数据架构需要支持所有这些方面，以从不断增长的数据质量中获得业务洞察。

AWS 现代数据架构建立在包括专用数据存储在内的模型之上，以优化规模、可用性、性能和成本。它支持集成数据湖、数据仓库和专用存储，实现统一治理和简化数据移动。Amazon Redshift 和 Amazon S3 构成了您现代数据架构的核心，与其他专用服务紧密集成。

在所示的现代数据架构中（见图 1-4），有三种不同的数据移动模式：内部移动、外部移动和周边移动。

图 1-4. 使用专用服务构建的现代数据架构

内部移动数据

有时会将中央数据存储中的数据子集移动到专用数据存储中，例如用于在线分析处理（OLAP）工作负载的 Amazon Redshift，Amazon OpenSearch Service 集群或 Amazon Neptune 集群，以支持专业分析，如搜索分析、构建知识图谱或两者兼而有之。在 Amazon Redshift 的背景下，您可以使用 Amazon Redshift 作为中央数据存储，其他服务（如 AWS Glue 或其他 Amazon Redshift 数据仓库）可以通过数据共享访问数据。或者，您可以通过COPY命令将 Amazon S3 数据湖中的数据加载到 Amazon Redshift 中，或者直接查询作为外部 Amazon S3 模式的数据。

外部移动数据

组织机构从最适合其应用程序的数据存储开始，随后将这些数据移动到中央数据存储以进行协作。例如，为了卸载不经常访问的历史数据，您可能希望从 Amazon Redshift 将这些数据UNLOAD到您的 Amazon S3 数据湖中。游戏公司可能会选择 Amazon DynamoDB 作为维护游戏状态、玩家数据、会话历史和排行榜的数据存储。这些数据稍后可以导出到 Amazon S3 数据湖中，以进行额外的分析，以改善玩家的游戏体验。

周边移动

也有一些场景，数据从一个专门的数据存储移动到另一个。例如，您可以使用 Amazon Redshift 的联合查询功能直接从操作数据存储（如 Amazon Aurora）查询数据，或者使用 Amazon Redshift ML 功能运行模型，这将触发 Amazon SageMaker 中的流程。

您可以通过避免构建紧密耦合的单块应用程序，而是构建具有独立组件（称为微服务）的模块化应用程序，在现代数据战略的各个阶段进行创新。这些本地的、专为目的而建的集成 AWS 服务非常适合构建模块化应用程序，同时利用 ML 和 AI 等新兴技术。

Amazon Redshift 在现代数据架构中的角色

Amazon Redshift 推动现代数据架构，并使您能够在集中式或分散式架构中存储数据，并通过使组织中的所有数据可访问来打破数据孤岛。借助现代数据架构，您可以在 Amazon S3 数据湖中以结构化列格式和开放文件格式存储和访问数据仓库表中的数据。通过安全和治理能力在数据仓库、数据湖和操作数据库之间查询数据有助于统一并使数据轻松可用于您的业务用户和其他应用程序。

Amazon Redshift 的一些关键功能及与本地服务紧密集成的好处显示在图 1-5 中。

图 1-5. Amazon Redshift 在现代数据架构中

我们将在后续章节详细讨论这些功能，但这里是每个功能的简要摘要：

大规模并行处理（MPP）数据仓库

Amazon Redshift 基于 MPP 架构，通过将查询处理分布到数据仓库中的多个节点和每个节点内的虚拟处理单元来快速运行复杂查询，这使其能够处理大量数据。MPP 架构通过使用分布键将类似数据放置在处理单元中，从而使分析处理更具成本效益。在第二章，“开始使用 Amazon Redshift”，您将了解有关 MPP 架构重要性的更多信息。

存储和计算分离

通过 Redshift 架构第 3 代（RA3），Amazon Redshift 实现了存储和计算的分离，这有助于根据工作负载需求独立扩展存储或计算。在第二章，您将进一步了解 Amazon Redshift 的架构及其如何入门。

无服务器

亚马逊 Redshift 提供了一种无服务器选项，因此您可以在不需要预配和管理数据仓库的情况下运行和扩展分析工作负载。使用亚马逊 Redshift 无服务器，您无需选择特定工作负载所需的节点类型或节点数量；相反，您设置一个计算单元的初始配置，该计算单元以 Redshift 处理单元（RPU）进行衡量。亚马逊 Redshift 自动预配和扩展数据仓库容量，以满足要求严格和不可预测的工作负载的需求，您只需支付所使用的容量费用。亚马逊 Redshift 无服务器兼容预配的集群，因此您可以将应用程序从预配的集群迁移到无服务器，而无需更改现有的分析或 BI 应用程序。在 第二章，“使用亚马逊 Redshift 入门” 中，您将了解如何创建亚马逊 Redshift 无服务器数据仓库。

数据湖分析

亚马逊 Redshift 可以高效地查询和转换存储在亚马逊 S3 中的结构化和半结构化数据，而无需将数据加载到亚马逊 Redshift 表中。亚马逊 Redshift 查询外部 S3 数据，仅将所需数据发送到您的亚马逊 Redshift 数据仓库。在 第三章，“设置数据模型和数据摄入” 中，您将了解如何从亚马逊 S3 查询和转换数据。

安全且一致的数据共享

亚马逊 Redshift 数据共享允许您在组织内部或与外部合作伙伴之间共享实时数据仓库数据。此功能使您能够在多个数据仓库部署中扩展单个数据仓库的好处，而无需复制或移动数据。这使您可以通过跨组织边界和数据领域共享数据来访问和查询存储数据。在 第七章，“数据共享协作” 中，您将了解更多关于亚马逊 Redshift 数据共享的信息，以及如何与内部和外部利益相关者进行协作。

使用 SQL 进行机器学习

亚马逊 Redshift ML 使数据分析师和数据库开发人员能够使用熟悉的标准查询语言（SQL）命令在亚马逊 Redshift 数据仓库中创建、训练和应用机器学习模型变得更加简单。通过亚马逊 Redshift ML，您可以减少使用基于 SQL 的预测模型创建和利用与 Amazon SageMaker 完全托管的机器学习服务集成的 ML 模型开发时间，无需学习新工具或语言。在 第六章，“亚马逊 Redshift 机器学习” 中，您将了解如何使用亚马逊 Redshift ML 解决各种机器学习问题类型。

零 ETL

Amazon Aurora 支持与 Amazon Redshift 的零 ETL 集成，以便使用 Amazon Redshift 对交易数据进行近实时分析。使用基于日志的复制，写入 Aurora 的交易数据在几秒钟内可在 Amazon Redshift 中使用。一旦数据在 Amazon Redshift 中可用，您可以按原样查询数据，或者使用 SQL 或存储过程应用转换规则。在第三章，您将学习如何设置与 Amazon Redshift 的零 ETL 集成。

Spark 应用程序开发

使用Apache Spark 集成，您可以在 Java、Scala 和 Python 等多种语言中构建 Apache Spark 应用程序，并且该连接器原生安装在 Amazon EMR（以前称为 Amazon Elastic MapReduce）、AWS Glue 和 SageMaker 上。这些应用程序可以读取和写入您的 Amazon Redshift 数据仓库，而不会影响应用程序的性能或数据的事务一致性，同时通过推送优化提高性能。在第三章，您将学习如何利用 Spark 连接器进行摄取，在第四章，“数据转换策略”，您将学习如何使用 Spark 连接器进行数据转换。

自动摄取 Amazon S3 文件

您可以设置连续文件摄取规则来跟踪您的 Amazon S3 路径，并自动将新文件加载到 Amazon Redshift 中，无需额外的工具或自定义解决方案。使用COPY命令是将数据摄取到 Amazon Redshift 的最佳实践。您可以将COPY语句存储到复制作业中，该作业会自动加载检测到的指定 Amazon S3 路径中的新文件。在第三章，我们将描述加载数据的不同选项以及如何配置自动摄取。

使用联合查询查询交易数据

使用联合查询，您可以将实时数据作为 BI 和报告应用程序的一部分。通过此功能，您可以从 Amazon Redshift 内部查询来自外部数据库（如 PostgreSQL 或 MySQL）的当前实时数据，并将其与存储在数据仓库中的历史数据结合起来，为业务用户提供综合视图。在第四章，您将学习如何设置联合数据源，并实时查询用于报告和转换的数据。

使用您喜爱的 BI 工具

您可以使用您选择的 BI 工具通过标准的 Java 数据库连接（JDBC）和开放数据库连接（ODBC）连接或使用 API 查询您的 Amazon Redshift 数据仓库，并提供业务洞察。Amazon QuickSight是 AWS 的本地服务，用于创建现代交互式仪表板、分页报告、嵌入式分析和多数据源的自然语言查询，包括 Amazon Redshift。在第二章中，您将了解将客户端工具连接到 Amazon Redshift 的多种方式。

发现和分享数据

Amazon Redshift 还支持与Amazon DataZone集成，使您能够在组织边界内以规模发现和共享数据，并具有治理和访问控制。在第七章，“数据共享协作”中，您将了解 Amazon DataZone 如何为您提供联合数据治理，数据集的数据所有者和主题专家可以对其相关数据资产实施安全和访问控制。

采用现代数据架构的真实世界益处

多位分析师进行的研究结果显示，使数据即使提高几个百分点的组织将会看到净收入显著增加。根据理查德·乔伊斯，Forrester 的高级分析师的说法，“数据可访问性增加 10%将使典型的财富 1000 强公司的净收入增加 6500 万美元以上。”分析可以通过对顶线和运营成本有影响的见解来探索新市场或新业务线。

以下是一些真实世界的例子：

• Intuit 迁移到基于 Amazon Redshift 的解决方案，以使数据更易访问。该解决方案的规模扩展到了公司以前解决方案的 7 倍以上，并提供了 20 倍的性能。这导致团队成本减少了 25%，维护时间减少了 60%至 80%，整体成本节约了 20%至 40%，部署模型的时间减少了 90%。这使团队有更多时间开发下一波创新。

• Nasdaq 通过将公司的数据产品整合到云上的集中位置，将数据访问的上线时间从几个月缩短到几周。他们使用 Amazon S3 构建数据湖，每天可以摄入 700 亿条记录。交易所现在加载金融市场数据比以前快了五个小时，并且 Amazon Redshift 的查询速度提高了 32%。

• Expedia 集团每年通过 AWS 数据服务处理超过 6000 亿次 AI 预测，数据量达到 70PB。三星的 11 亿用户每秒发出 80,000 次请求，Pinterest 在 Amazon S3 上存储超过 1EB 的数据。

• 丰田从本地数据湖迁移到云端，并从车载传感器、运营系统和数据仓库中收集和结合 PB 级别的数据。他们的团队在需要时可以安全地访问这些数据，从而赋予他们快速创新的自主权和灵活性。现在，丰田可以做一些像监控车辆健康状况并在影响客户之前解决问题的事情。飞利浦建立了一个安全和符合 HIPAA 标准的数字云平台，作为应用套件的基础，可以存储、解释、统一和从不同来源提取客户数据的平台。

现代数据架构参考架构

现在您了解了现代数据架构的好处以及将数据存储在数据湖和数据仓库中的价值，让我们来看看使用 AWS 分析服务实现数据仓库工作负载的参考架构。图 1-6 说明了您如何使用 AWS 服务从各种来源和应用程序中收集或提取数据到您的 Amazon S3 数据湖，以及如何利用 Amazon Redshift 摄取和处理数据，以及如何使用 Amazon QuickSight 和 Amazon SageMaker 分析数据。

图 1-6. 现代数据参考架构

数据采集

现代数据架构使您能够从各种来源接收和分析数据。其中许多来源，如业务线（LOB）应用程序、ERP 应用程序和 CRM 应用程序，会定期生成高度结构化的数据批次。除了内部结构化来源外，您还可以从现代来源（如 Web 应用程序、移动设备、传感器、视频流和社交媒体）接收数据。这些现代来源通常生成半结构化和非结构化数据，通常作为连续的数据流。

数据以 Amazon S3 的形式临时或持久存储为数据湖，采用开放文件格式如 Apache Parquet、Avro、CSV、ORC 和 JSON 等。来自您的 Amazon S3 数据湖的相同数据可以作为您的真实数据源，并可用于 Amazon Redshift、Amazon Athena、Amazon EMR 和 Amazon SageMaker 等其他分析服务。数据湖允许您在大多数数据上运行分析的单一位置，而专为目的构建的分析服务提供您所需的速度，例如数据仓库、实时仪表板和日志分析。

提取、转换和加载

ETL 层负责从多个来源提取数据，根据业务规则转换数据，并填充存储层的清理和筛选区域。它可以连接到各种协议的内部和外部数据源。它可以将批处理和实时流数据导入数据仓库以及数据湖中。

为了提供高度精选、符合标准和可信的数据，在存储数据之前，您可以通过预处理、验证和转换处理源数据。对数据仓库数据和模式的更改应受严格控制和验证，以提供高度可信的真实数据集，跨业务领域。

过去可能采用的一种常见架构模式是将需要高性能的频繁访问数据存储在类似 Amazon Redshift 的数据库或数据仓库中，而只偶尔查询的冷数据存储在数据湖中。例如，金融或银行组织可能需要保留超过 10 年的历史交易以符合法律合规要求，但仅需分析 2 或 3 年的数据。现代架构提供了灵活性，可以在本地存储中存储最近三年的数据，并将超过三年的历史数据持久化到数据湖中。

按照这种模式，当使用 RA3 节点类型或服务器无关部署选项时，Amazon Redshift 具有内置的分层存储模型。存储和计算被分离，数据存储在 Amazon Redshift 托管存储（RMS）中，使您能够独立于存储扩展计算。Amazon Redshift 通过将频繁使用的数据块靠近计算来管理热数据和冷数据，替换不经常使用的数据。通过这种架构，虽然您仍然可以将历史数据持久化到数据湖中以在其他分析服务上运行分析，但您不必从数据仓库中卸载太多数据，甚至不需要卸载任何数据。

存储

数据存储层负责提供耐用、可扩展和具有成本效益的组件来存储和管理大量数据。数据仓库和数据湖本地集成，提供一体化的成本效益存储层，支持非结构化、半结构化以及高度结构化和建模数据。存储层可以存储数据在不同消费就绪状态下，包括原始数据、信任-符合数据、丰富数据和建模数据。

数据仓库中的存储

数据仓库源于需要存储和访问大量数据。基于 MPP 架构的系统被设计为在可扩展的一组昂贵且高性能的计算节点上分布处理。

从历史上看，数据仓库存储符合标准且高度可信的数据，结构化成星型、雪花型、数据保险库或非规范化模式，并且通常来自高度结构化的来源，如事务系统、关系数据库和其他结构化操作来源。数据仓库通常是批量加载并执行 OLAP 查询。

Amazon Redshift 是第一个完全托管的基于 MPP 的云数据仓库，支持传统数据仓库的所有功能，但已发展出具有弹性存储、减少所需计算节点数量、存储半结构化数据、访问实时数据并执行预测分析的功能。图 1-7 显示了典型的数据仓库工作流程。

图 1-7. 典型的数据仓库工作流程

数据湖中的存储

数据湖是存储组织所有数据的集中式数据存储库。它支持结构化、半结构化和非结构化格式的数据存储，并能够扩展存储至 Exabytes 级别。通常，数据湖根据数据的消费准备情况被分为落地、原始、可信和策划区域以存储数据。由于数据可以在不需要首先定义模式的情况下被摄取和存储，数据湖可以加速数据摄入并减少数据探索前的准备时间。数据湖支持使用多种方法对多样化的数据集进行分析，包括大数据处理和机器学习。数据湖与数据仓库之间的原生集成还通过允许您访问所需的任何数据湖数据并仅加载最有价值的数据来降低存储成本。构建在 AWS 上的数据湖使用 Amazon S3 作为其主要存储平台，如 图 1-8 所示。

图 1-8. 数据湖的用例

分析

您可以使用查询编辑器进行交互式 SQL 查询，使用 Amazon QuickSight 的可视化仪表板，或者通过运行预测机器学习模型使用 Amazon SageMaker 分析存储在数据湖和数据仓库中的数据。

使用这些服务时，无需不断移动和转换数据，AWS 提供原生且完全集成的核心用例服务，而非来自其他供应商的部分集成服务的集合。

比较事务性数据库、数据仓库和数据湖

尽管事务数据库、数据仓库和数据湖可能都被组织成类似的数据集合，并可以通过简单的 结构化查询语言（SQL）存储和访问电子化数据，但让我们更仔细地看看每个的关键区别特征。

事务性数据库是一种系统，其底层表结构设计用于快速高效地对单个行进行数据插入和更新。数据模型通常高度规范化，并且存储设计为存储大量交易。为了支持特定数据行的高交易量，在磁盘上所有数据行都会物理存储在一起（基于行的存储）。这种类型的数据库用于构建在线事务处理（OLTP）系统。在线购买、销售订单、股票交易以及银行的存款或取款是事务性数据库的一些使用案例。

数据仓库是一种专为分析来自事务系统和 LOB 应用程序的关系数据以及来自移动应用程序、物联网设备和社交媒体的半结构化非关系型数据而优化的数据库。数据经过清洗、增强和转换，以便作为用户可以信任的“单一数据源”。数据结构和模式被优化为快速汇总大量数据或大批处理。结果用于报告和分析。一些分析用例的示例包括分析年度零售和在线销售、客户购买偏好的趋势分析以及确定前 10 个利润最高的产品。

事务性数据库和数据仓库的关键区别特征列在表 1-1 中。

表 1-1. 数据仓库与数据库比较

特征	数据仓库	事务性数据库
适用工作负载	大规模分析、报告、大数据	事务处理、运营报告
数据来源	从多个来源收集并规范化的数据	直接从单一来源（如事务系统）捕获的数据
数据捕获	典型地批量写入操作，通常在预定的批处理时间表上进行	优化为连续写入操作，以便在新数据可用时最大化事务吞吐量
数据规范化	非规范化模式，如星型模式或雪花模式	高度规范化的静态模式
数据存储	优化为简化访问和高速查询性能，使用列存储	优化为对单行物理块进行高吞吐量写操作
数据访问	优化以最小化 I/O 并最大化数据吞吐量	大量小型读操作

数据湖还存储来自 LOB 应用程序和半结构化数据的关系数据，但也可以存储完全非结构化的数据。在捕获数据时，数据的结构或模式未定义。这意味着您可以在没有初始设计的情况下存储数据，并根据业务用户查询需求创建目录。

随着拥有数据仓库的组织看到数据湖的好处，他们需要一个能够支持两种用例的平台。他们正在发展他们的仓库，以包括数据湖，并实现多样化的查询能力。

表 1-2 包含数据仓库和数据湖的关键区别特征。

表 1-2. 数据仓库与数据湖

特征	数据仓库	数据湖
数据	来自事务系统、操作数据库、具有流入功能的 JSON 和业务应用程序的关系数据	所有数据，包括结构化、半结构化和非结构化数据
模式	通常在数据仓库实施之前设计，但也可以在分析时编写（写时模式或读时模式）	在分析时编写（读时模式）
价格/性能	使用本地存储获取最快的查询结果	使用低成本存储和计算与存储的解耦合，查询结果变得更快
数据质量	高度策划的数据，用作真实版本的中心	可能是或可能不是策划的任何数据（即原始数据）
用户	业务分析师、数据科学家、数据架构师和数据工程师	商业分析师（使用策划的数据）、数据科学家、数据开发人员、数据工程师和数据架构师
分析	批量报告、商业智能和可视化、机器学习	机器学习、探索性分析、数据发现、流处理、运营分析、大数据和数据剖析

数据网格和数据织物

数据网格和数据织物是在分布式和复杂环境中实施现代数据架构的两种方法。它们共享一些共同原则，如使用分布式架构和数据质量及治理的重要性。然而，它们在数据管理的目标和方法上有所不同。数据网格专注于数据领域的分散化和自治，而数据织物专注于在不同来源和系统之间实现数据的集成和一致性。数据织物是一种自上而下的技术解决方案，而数据网格是一种自下而上的方法，更注重团队和流程，而不是架构执行。

数据网格

在数据网格架构中，数据围绕业务能力或领域组织，每个领域负责其自身的数据管理、质量和治理。数据被视为产品，数据团队负责创建和维护可供其他团队消费的数据产品。数据网格的目标是通过减少依赖关系和改善团队之间的协作，提高在复杂和快速变化环境中的数据管理的灵活性和可扩展性。

数据网格鼓励分布式团队独立拥有和构建他们认为合适的面向领域的解决方案；参见 图 1-9，展示了销售、营销、财务、研发以及各自团队的领域。然后要求每个团队通过自助式基础设施平台提供数据作为产品，如 图 1-9 的最后一块所示。为了数据网格能够保持全球互操作性，监督责任由联邦治理团队负责，如图的顶部所示。

图 1-9. 数据网格架构

这种面向领域的数据所有权和架构允许生态系统按需扩展。提供数据作为产品能够在多个领域之间轻松发现。自助式基础设施平台使各个领域团队能够通过抽象复杂性创建和消费数据产品。联邦治理团队负责为整个数据网格生态系统的互操作性定义全球标准化规则，更重要的是平衡需要全球标准化的内容和应由面向领域的团队决定的内容。

每个团队都可以自由构建自己的解决方案，Amazon Redshift 数据共享功能可以提供构建数据网格架构所需的数据基础设施平台。通过 Amazon DataZone，您可以构建一个数据网格架构，其中您可以使用去中心化和治理模型与消费者共享数据产品。

数据布局

数据布局 是一种数据集成和编排方法，强调跨不同来源和系统的数据一致性、质量和可访问性。在数据布局架构中，数据组织成统一的虚拟层，为用户提供数据的单一视图，无论其位置或格式如何。数据在通过布局时进行转换、丰富和协调，使用自动化和手动处理的组合。数据布局的目标是简化数据访问和分析，使组织能够基于可信数据做出更快速和更准确的决策。

随着收集到的数据，伴随而来的是与访问、发现、整合、安全性、治理和谱系相关的挑战。数据布局解决方案提供了解决这些挑战的能力。

数据织物是一种基于元数据驱动的方法，用于连接数据管理工具，以实现自助式数据消费。参考图 1-10，中央元素代表数据织物提供的工具。实际数据源或数据孤岛（显示在左侧）仍然分布，但通过数据织物覆盖进行统一管理。在所有数据源上建立单一的数据织物层为人物角色（在顶部显示：报告、分析和数据科学）提供了统一的体验，这些角色既可以提供数据，也可以使用整个组织的数据。各个组件通常通过 API 以 JSON 格式交换数据。

数据织物可以被视为一个生动、具有持续学习能力的元素，它包括 AI 和机器学习组件，帮助自动发现和谱系过程。这里的挑战在于获得各部门和团队对统一管理的一致认可，这些部门和团队负责拥有和维护其各自的数据集。

图 1-10. 数据织物由多个数据管理层组成（图片来源：Eckerson Group）

Amazon Redshift 与AWS Lake Formation的集成可用于提供访问便捷性、安全性和治理。在第八章，“安全和数据治理”中，您将学习如何在使用 AWS Lake Formation 时设置访问控制。此外，Amazon SageMaker可以用来在 AWS 上构建数据织物架构的机器学习能力。在第六章，“Amazon Redshift 机器学习”中，您将了解 Amazon Redshift 如何与 Amazon SageMaker 紧密集成。

摘要

在这一章中，我们探讨了如何通过使用专为数据服务而构建的现代数据架构，使组织变得数据驱动。现代数据策略将帮助您推动迁移数据工作负载到云端的路线图，我们看到了 Amazon Redshift 如何成为现代数据架构的基础。

剩余的章节探讨了如何使用 Amazon Redshift 将数据工作负载转换到云端，民主化数据，并为所有用户提供业务洞见。您还将学习如何使用 Amazon Redshift 实现数据网格等现代架构，并利用其与其他 AWS 原生分析服务的紧密集成。

第二章：开始使用 Amazon Redshift

Amazon Redshift 使您能够运行业务分析，无需预置服务器或基础设施，使得开始变得轻松。它包括 AWS 控制台中的基于 Web 的查询编辑器，可以开始加载和分析数据，无需安装软件。Amazon Redshift 还兼容您喜爱的查询编辑器，如 DBeaver、SQL WorkbenchJ 和 Toad，使用提供的Java 数据库连接（JDBC）或开放数据库连接（ODBC）驱动程序。

在本章中，我们将提供 Amazon Redshift 架构概述，描述平台的关键组件。接下来，我们将提供有关如何“开始使用 Amazon Redshift 无服务器”并开始查询“样本数据”的步骤，只需点击几下按钮。我们还将描述“何时使用预置集群？”以及如何为无服务器和预置数据仓库“估算您的 Amazon Redshift 成本”。然后，我们将讨论“AWS 账户管理”，描述如何在您的组织中创建单个账户或管理多个账户。最后，我们将介绍“连接到您的 Amazon Redshift 数据仓库”的一些选项以及如何管理用户访问。

Amazon Redshift 架构概述

名字有什么关系呢？我们可以用任何其他名字来称呼一朵玫瑰，它依然会一样芳香。

罗密欧与朱丽叶

威廉·莎士比亚在他的剧作罗密欧与朱丽叶中使用这句话来表达，事物的命名是无关紧要的。

关于名为Redshift的原因和含义有许多理论。我们发现这个术语是基于天文学现象红移而创造的，红移是天文学中的一个概念，指的是光的波长在扩展时被拉长，因此光线向红色移动，这是可见光谱中最长波长端的颜色。

因为数据不断扩展，Amazon Redshift 提供了一个平台来存储和分析数据，并实现无缝扩展。作为第一个完全托管的 PB 级云数据仓库，Amazon Redshift 是从本地数据仓库解决方案转型而来的架构，后者需要前期资本投入、扩展工作和全职资源来操作。

Amazon Redshift 数据仓库服务兼容 ANSI SQL，专为 OLAP 工作负载设计，以压缩的列式存储格式存储数据。此服务可作为预置或无服务器数据仓库使用。

图 2-1 展示了一个预置集群。使用最新一代节点类型RA3，您可以根据工作负载独立扩展计算和存储。该节点类型的存储为Amazon Redshift Managed Storage（RMS），由 Amazon S3 支持。

图 2-1。Amazon Redshift 架构

无服务器架构（见 图 2-2）自动化了许多监视和扩展 Amazon Redshift 的操作活动。Amazon Redshift 无服务器利用基于机器学习的工作负载监控系统，自动扩展计算资源以满足工作负载的需求。随着需求随着更多并发用户和新工作负载的进展而变化，您的数据仓库会自动扩展，以提供一致的查询执行时间。最后，使用 Amazon Redshift 无服务器开始的体验也更简单；仅在使用时收费。结合 RMS 的数据共享能力，一个部门可以使用无服务器开始分析隔离的数据仓库中的数据，而不影响共享数据。由于不必支付闲置费用，您的团队无需联系管理员来暂停或恢复数据仓库。

图 2-2. Amazon Redshift 无服务器架构

Amazon Redshift 预置和无服务器都基于包括领导节点和一个或多个计算节点的 MPP 框架。Amazon Redshift 还包括用于代码编译、查询计划缓存、结果缓存、数据湖访问、并发扩展（CS）、机器学习、联合查询和数据共享的额外组件。我们将在随后的章节详细介绍这些内容。

使用 Amazon Redshift，您可以在几分钟内开始分析数据，使用无服务器或预置数据仓库。我们将从如何创建一个无服务器数据仓库并使用样例数据集运行查询开始。

开始使用 Amazon Redshift 无服务器

Amazon Redshift 无服务器和预置两者在功能上有很多相同的能力，比如加载和查询结构化和半结构化数据，向 PostgreSQL 和 MySQL 中的运行数据库联邦化，以及在数据湖中查询数据。此外，无服务器和 RA3 预置数据仓库都构建在 RMS 之上，使两者都能访问其他 Amazon Redshift 数据仓库中生成的数据，无论是预置还是无服务器。尽管在选择工作负载时可能需要考虑某一种方式，但很明显，无服务器是开始使用 Amazon Redshift 的最简单方式。

创建 Amazon Redshift 无服务器数据仓库

亚马逊 Redshift 无服务器分为工作组和命名空间，以单独管理存储和计算资源。命名空间是包含数据库对象的集合，包括数据库、模式、表、用户、用户权限以及用于加密数据的 AWS 密钥管理服务密钥。命名空间下分组的其他资源包括数据共享、恢复点和使用限制。工作组是包含计算资源的集合，包括亚马逊 RPU 基础容量、虚拟私有云（VPC）子网组、安全组和限制。

要开始使用亚马逊 Redshift 无服务器，您可以使用 AWS 控制台、AWS CLI 或亚马逊 Redshift 无服务器 API 配置存储（命名空间）和计算（工作组）属性。

要使用 AWS 控制台部署亚马逊 Redshift 无服务器数据仓库，请导航到 创建工作组 页面，并选择您的配置选项。在第一部分，您将选择工作组名称。接下来，您将通过选择基础 RPU 容量来确定初始计算能力。这是亚马逊 Redshift 无服务器在开始处理您的工作负载时使用的计算能力，但它可以根据您的工作负载需求自动扩展。您可以选择至少 8 个 RPUs 或多达 512 个 RPUs，默认为 128 个。有关确定您用例的最佳 RPU 大小的详细信息，请参阅 “亚马逊 Redshift 无服务器计算成本”。

最后，您将选择安全配置（参见 Figure 2-3）。这将确定数据仓库将在哪个网络配置上部署。默认情况下，无服务器数据仓库将部署在默认 VPC、子网和安全组中。您可以使用默认设置或自定义每个设置。有关网络配置考虑事项的详细讨论，请参阅 “私有/公共 VPC 和安全访问”。

Figure 2-3. 工作组名称和安全配置

接下来，创建一个新的命名空间（参见 Figure 2-4）或将您的工作组附加到现有的命名空间。命名空间将包含您的数据库对象。

Figure 2-4. 命名空间

如果创建新的命名空间，系统将提示您指定权限和管理员凭据（参见 Figure 2-5）。与预配置的集群类似，权限是通过工作组可以假定的身份和访问管理（IAM）角色定义的，以访问 AWS 环境中的其他资源。在下一个示例中，我们创建了一个名为 RedshiftRole 的 IAM 角色，为其分配了 AmazonRedshiftAllCommandsFullAccess 策略，并将其设置为默认角色。

IAM 角色中定义的权限将影响 Amazon Redshift 数据仓库可以访问的 AWS 服务，例如读取和写入 Amazon S3。这不应与分配给数据库用户、数据库组或数据库角色的权限混淆。

图 2-5. 权限和管理员凭据

最后，在您的新命名空间中，指定是否要自定义加密和日志记录（图 2-6）。

图 2-6. 加密和日志记录

完成后，您可以通过导航到 Redshift 工作组 页面来检索您的工作组列表（图 2-7），在该页面上您可以检索工作组端点、JDBC 和 ODBC URL 等信息。有关连接到您的工作组的选项，请参见 “连接到您的 Amazon Redshift 数据仓库”。

图 2-7. 工作组列表

配置为 8 或 16 RPU 支持最多 128 TB 的 Amazon RMS 容量。如果您使用的托管存储超过 128 TB，则无法降级到少于 32 RPU。

示例数据

一旦您启动了 Amazon Redshift，无论是使用无服务器还是预配，您可以开始创建所需的数据模型，以构建数据仓库解决方案。

当您创建 Amazon Redshift 无服务器数据仓库时，您可以开始与三个示例数据集互动。第一个数据集 tickit 包含七张表：两个事实表和五个维度，如 图 2-8 所示。这个示例数据库应用帮助分析人员跟踪虚构的 Tickit 网站上的销售活动，用户在此购买和出售体育赛事、演出和音乐会的门票。特别是，分析人员可以识别随时间变化的票务流动情况，卖家的成功率，以及最畅销的事件、场馆和季节。分析人员可以利用这些信息来激励经常访问该网站的买家和卖家，吸引新用户，并推动广告和促销活动。

图 2-8. Tickit 示例数据模型

激活示例数据模型并使用查询编辑器进行查询

您可以使用亚马逊 Redshift 查询编辑器 V2 来激活示例数据集并开始查询。有关如何开始使用查询编辑器 V2 的详细信息，请参阅“使用查询编辑器 V2 查询数据库”。认证后，展开 sample_data_dev 数据库。然后点击每个模式名称旁边的文件夹图标以打开示例笔记本（参见 Figure 2-9）。这将创建示例数据模型表、数据和与示例数据模型相关的查询。查询编辑器 V2 支持笔记本和编辑器界面。激活数据集后，示例查询也将在笔记本界面中打开，您可以查询数据。

图 2-9. 查询 tickit 示例数据集

一旦激活示例数据集，您可以开始查询数据。从笔记本提供的查询中，尝试使用 tickit 数据的以下示例查询。

第一个查询 (Example 2-1) 查找每个事件的总销售收入。

示例 2-1. 每个事件的总销售收入

SELECT e.eventname, total_price
FROM (
  SELECT eventid, sum(pricepaid) total_price
  FROM   tickit.sales
  GROUP BY eventid) Q, tickit.event E
WHERE Q.eventid = E.eventid
QUALIFY ntile(1000) over(order by total_price desc) = 1
ORDER BY total_price desc;

第二个查询 (Example 2-2) 检索特定日期的总销售数量。

示例 2-2. 特定日期的总销售数量

SELECT sum(qtysold)
FROM   tickit.sales, tickit.date
WHERE  sales.dateid = date.dateid
AND    caldate = '2008-01-05';

您也可以通过点击 + 按钮并选择“编辑器”菜单选项来打开查询编辑器界面（参见 Figure 2-10）。

图 2-10. 在编辑器模式下查询 tickit 示例数据集

尝试在编辑器中输入以下查询并运行以查看结果。这个查询 (Example 2-3) 检索前十个买家的总销售数量。

示例 2-3. 前十大买家的总销售数量

SELECT firstname, lastname, total_quantity
FROM   (SELECT buyerid, sum(qtysold) total_quantity
        FROM  tickit.sales
        GROUP BY buyerid
        ORDER BY total_quantity desc limit 10) Q, tickit.users
WHERE Q.buyerid = userid
ORDER BY Q.total_quantity desc;

这个查询 (Example 2-4) 查找在所有时间总销售中位于 99.9 百分位数的事件。

示例 2-4. 销售额的 99.9%事件

SELECT eventname, total_price
FROM  (SELECT eventid,
        total_price,
        ntile(1000) over(order by total_price desc) as percentile
       FROM (SELECT eventid, sum(pricepaid) total_price
             FROM   tickit.sales
             GROUP BY eventid)) Q, tickit.event E
       WHERE Q.eventid = E.eventid
       AND percentile = 1
ORDER BY total_price desc;

另外两个数据集是 tpch 和 tpcds，这些都是来自 tpc.org 的标准基准数据集。TPC-H 和 TPC-DS 数据集是决策支持基准测试。这些包括一套面向业务的即席查询和并发数据修改。所选的查询和数据库中的数据具有广泛的行业相关性。这些基准测试提供了作为通用决策支持系统性能的代表性评估。

这些数据模型位于 sample_data_dev 数据库中，具有各自的 tpch 和 tpcds 模式。您可以激活这些数据模型，并通过点击模式名称旁边的文件夹图标来访问每个模式的相关对象，就像您之前为 tickit 模式所做的那样。这将在一个笔记本界面中打开所有查询（参见 Figure 2-11）。现在您可以尝试运行示例查询。第一个查询返回已开票、已发货和已退货的业务金额。

图 2-11. 查询 tpch 样本数据集

何时使用预置集群？

亚马逊 Redshift 提供了第二种部署选项，您可以对数据仓库具有更多控制。设置亚马逊 Redshift 数据仓库时的关键考虑因素是选择最适合您工作负载的配置和架构，以获得最佳的开箱即用性能。

根据来自亚马逊创始人杰夫·贝索斯于 2020 年 11 月 23 日的一篇文章：

有两种类型的决策。有些决策是不可逆转且影响深远的；我们称之为单向门 […​] 它们需要慢慢和仔细地作出。在亚马逊，我经常扮演首席减速官的角色：“哇，我想看到这个决策再分析十七种方式，因为它具有高度重大且不可逆的影响。” 问题在于大多数决策不是这样的。大多数决策是双向门。

正如贝索斯所述，选择无服务器和预置之间是一个双向门决策，即使您没有选择最佳配置，因为亚马逊 Redshift 是按使用付费的云解决方案，可以在几分钟内增加或删除容量。您的分析架构设计应基于快速实验和验证。

预置集群提供了调整数据仓库性能的能力。使用预置集群，您可以控制何时以及如何调整集群大小，有能力手动配置工作负载管理，并确定何时暂停/恢复数据仓库。虽然预置集群可能需要更多的管理，但它提供了更多调整可预见工作负载和优化成本的选项。如果您有非常一致和恒定的工作负载，利用预置集群和购买预留实例可能是更为成本优化的选择。

在设计生产数据仓库的架构时，您有许多选择。您需要决定是否有意义在一个亚马逊 Redshift 数据仓库中运行工作负载，还是将工作负载拆分/隔离到多个亚马逊 Redshift 数据仓库中。您还需要决定在一个或多个数据仓库中使用预置还是无服务器是否有意义。在下面的示例中，展示了支持相同工作负载的两种不同策略（图 2-12）。

图 2-12. 亚马逊 Redshift 部署选项

在第一章“用于数据的 AWS”中，您学习了现代数据架构如何鼓励分布式团队独立拥有和设计其面向领域的解决方案。在以下的亚马逊 Redshift 数据网格架构（图 2-13）中，您可以看到一种既利用了配置的数据仓库，又利用了多个无服务器数据仓库的架构。在这种环境中，您使用配置的数据仓库（1）从多个来源进行数据摄取，因为工作负载配置是一致的，并且在大部分时间内运行。您可以购买预留实例，并完全控制可预测的成本。此外，您设置了一个无服务器数据仓库（2），它可以使用数据共享从配置的数据仓库中读取数据。此服务器无服务器数据仓库的用户也从共享数据中读取数据，并通过加载自己的数据、连接到共享数据并根据需要聚合数据来整理新的数据集。这些无服务器数据仓库的用户成为其领域或部门特定数据的管理者。他们可以访问其领域之外的任何数据，但不依赖于该组织的处理需求。最后，您设置了另一个无服务器数据仓库（3），它也使用数据共享从配置的数据仓库中读取来自另一个无服务器数据仓库（2）的整理数据集。这些工作负载在计算需求、运行时间以及活动时间长度等方面各不相同。

图 2-13. Redshift 数据网格架构

无论您选择哪种部署选项，都可以使用快照/恢复过程切换。有关如何将快照从配置的集群恢复到无服务器数据仓库的详细信息，请参阅在线文档。

创建 Amazon Redshift 配置集群

使用配置选项部署 Amazon Redshift 意味着您将部署特定节点类型的一定数量的计算节点，形成一个集群。要部署 Amazon Redshift 配置集群，请导航至创建集群页面并选择您的配置选项。您还可以按照 AWS 文档中描述的步骤来创建样例 Amazon Redshift 集群。

在第一部分中，您将选择集群名称和大小（图 2-14）。有关确定适用于您用例的最佳集群大小的详细信息，请参阅“Amazon Redshift 配置计算成本”。

图 2-14. 集群名称和大小

接下来，您将决定是否加载样例数据（可选）并设置管理员凭据（图 2-15）。

图 2-15. 载入示例数据并设置管理员凭证

接下来，指定集群权限（图 2-16）通过为您的亚马逊 Redshift 集群分配 IAM 角色，以访问 AWS 环境中的其他资源。如果您打算执行诸如从 Amazon S3 批量加载数据到 Amazon Redshift 的操作，则需要这些权限。提供了一个名为 AmazonRedshiftAllCommandsFullAccess 的托管策略，可用于关联到包含您可能使用的常见服务的角色。在下一个示例中，我们创建了一个 IAM 角色 RedshiftRole，分配了 AmazonRedshiftAllCommandsFullAccess 策略，并将其设为默认角色。有关授权亚马逊 Redshift 代表您访问其他亚马逊服务的更多详细信息，请参阅在线文档。

图 2-16. 集群权限

最后，设置集群的附加配置（图 2-17）。这些配置决定了您的集群将在您网络配置的上下文中部署的位置。默认情况下，集群将部署在默认的 VPC、子网和安全组中。您可以使用默认设置或自定义每个设置。有关网络配置考虑事项的详细讨论，请参阅“私有/公共 VPC 和安全访问”。

图 2-17. 集群附加配置

您可以从Redshift 集群页面查看您的集群列表（图 2-18）。单击集群，您可以获取一般信息，如集群终端节点以及 JDBC 和 ODBC URL。有关连接到集群的选项，请参阅“连接到您的亚马逊 Redshift 数据仓库”。

图 2-18. 集群列表

估算您的亚马逊 Redshift 成本

当估算亚马逊 Redshift 的成本时，需要考虑的两个主要因素是存储和计算。对于 RA3 节点类型和无服务器的情况，您必须单独考虑托管存储成本，而不是无服务器计算成本或预置计算成本。然而，如果您使用 DC2 节点类型，则只需考虑预置计算成本，因为所有存储都是局部存储在计算节点上。

亚马逊 Redshift 托管存储

Amazon RMS 是一种压缩且列格式化的数据结构，专为分析工作负载的最佳性能而设计。存储与计算分离，并且具有弹性。您可以将数据从 TB 扩展到 PB。无论 Amazon Redshift 数据仓库是 RA3 预配还是无服务器，它都可以共享。即使 Amazon Redshift 数据仓库处于非活动状态，共享数据也对消费者可用。例如，如果数据的主要所有者是预配集群，则消费者可以访问该数据，即使预配集群暂停。此功能使您可以选择适合工作负载的计算而无需移动或转换数据。它还确保数据不会重复，从而减少维护和存储成本。由于您可以轻松地在不同的计算选项之间移动，并且即使计算未运行，存储也可用，因此存储的定价是独立的。要估算使用 RA3 集群或无服务器数据仓库时的存储成本，您可以估算压缩存储需求乘以每月的存储价格。例如，假设您的存储使用量为 10 TB。基于每 GB 每月$0.024 的定价，您的存储费用将为$240：

$0.024*10*1000 = $240

获取关于亚马逊 Redshift 托管存储定价的最新详细信息，请参阅在线文档。

亚马逊 Redshift 无服务器计算成本

对于亚马逊 Redshift 无服务器，除了 RMS 成本外，还有一个关键成本需要考虑：计算成本。为了便于亚马逊 Redshift 计费，创建了一种称为 RPU 的计量单位（图 2-19），表示在给定时间段内使用的计算能力。设置工作组时，会配置 128 个 RPUs 的基础容量。当亚马逊 Redshift 无服务器从空闲状态唤醒并需要更多计算时，将会扩展此基础。您可以通过编辑亚马逊 Redshift 无服务器配置并修改Limits来修改工作组的基础容量。

图 2-19. 亚马逊 Redshift 无服务器基础容量

每个查询都会在系统中记录，只有在服务器无服务器工作组运行查询的时间段内才会收费（交易的最低计费时间为 60 秒）。例如，假设您使用了默认的 128 RPUs，并且在一个小时内只提交了 1 个运行 90 秒的查询。根据 us-west-2 地区的定价$0.45/RPU 小时，您的查询费用将为$1.44：

rate/sec = $0.45*128/60/60 = $0.016
secs = max(90,60) = 90
rate*secs = $0.016*90 = $1.44

假设这实际上是一个按计划触发执行 3 个同时查询（15 秒、30 秒和 90 秒）的仪表板，其中最长的查询在 90 秒内完成。还假设这是该小时工作组的唯一工作负载。您仍将仅收取$1.44，因为工作组仅在这 90 秒内运行，而无服务器工作组能够使用 128 RPUs 的基本容量完成作业：

rate/sec = $0.45*128/60/60 = $0.016
secs = max(15,30,90,60) = 90
rate*secs = $0.016*90 = $1.44

设置不同的基本容量值

假设您配置工作组的基本容量为 8 RPUs 或 1/16 的计算能力而不是 128 RPUs。很可能，90 秒完成的工作量将需要长达 16 倍的时间（1440 秒），但价格仍将为$1.44：

rate/sec = $0.45*8/60/60 = $0.001
secs = max(1440,60) = 1440
rate*secs = $0.001*1440 = $1.44

如果像 8 RPUs 这样的小基本容量配置，如果查询使用了大量内存，工作负载可能会比 1440 秒更长，因为可用内存更少，您将进行磁盘分页。但是，在某些情况下，工作负载可能需要的时间较短，因为原始 90 秒可能包含了不需要推算的开销。

在选择基本容量时的另一个考虑因素是最低收费 60 秒。如果您有很多少于 60 秒的查询，并且在查询之间有空闲时间，则较小的基本容量配置上的每个查询费用将较低。

在以下示例中，假设您有一个查询，在 128 RPU 基本容量配置上运行 1 秒钟，在 8 RPU 基本容量配置上运行 16 秒钟。如果这是该分钟内唯一运行的查询，则它们各自将按其各自的最低收费标准收费，导致价格相差 16 倍：

8 RPU rate/sec = $0.001
secs = max(1,60) = 60
rate*secs = $0.060

128 RPU rate/sec = $0.016
secs = max(16,60) = 60
rate*secs = $0.960

高/频繁使用

在另一个例子中，假设您有一个流媒体应用程序，每分钟加载到您的数据仓库，但每个加载只需 5 秒钟（图 2-20）。因为无服务器工作组上的每个事务都按照最低 60 秒计费，即使每个查询只需 5 秒完成，也将基于 60 秒的最低收费计费。

图 2-20. 流媒体使用时间轴

在这个例子中，虽然总的查询执行时间是5*60=300秒，但应用了 60 秒的最低收费时，计费使用时间为60*60=3600秒。基于 us-west-2 地区的价格为$0.45/RPU 小时，您的这个工作负载的费用将为$57.60：

rate/sec = $0.45*128/60/60 = $0.016
secs = max(5,60)*60 = 60*60 = 3600
rate*secs = $0.016*3600 = $57.60

在这些情况中，建议在满足查询服务水平协议（SLAs）和预算要求的基本容量配置上进行实验，记住您只需支付您使用的计算费用。

关于 Amazon Redshift 定价的最新详细信息，包括使用预留容量可以节省多少费用，请查看在线文档。

Amazon Redshift 预留计算成本

对于 RA3 预留集群，除了存储成本外，主要额外成本来自集群大小。规划预留数据仓库的第一步是确定节点类型和您所需的节点数。在确定 Amazon Redshift 预留集群大小时，请考虑能够满足您分析处理需求性能 SLA 的稳态计算。每种节点类型由一个计算配置文件定义，并且随着节点类型的选择越来越大和更昂贵，您可以选择最适合满足您需求的节点类型和节点数量。下表（表 2-1）总结了每种节点类型的分配资源，截至 2023 年。您可以获取最新的计算配置文件，并在在线文档中了解更多有关不同节点类型的信息。

表 2-1. RA3 节点类型

节点类型	RMS	内存	vCPU
ra3.xlplus	32 TB	32 GB	4
ra3.4xlarge	128 TB	96 GB	12
ra3.16xlarge	128 TB	384 GB	48

在确定集群中需要的节点大小和节点数时，请考虑您的处理需求。从最大的节点大小开始，当您超出性能 SLA 时考虑更小的节点大小。这种策略有助于减少节点之间数据洗牌时的网络流量。例如，ra3.16xl 的 2 个节点在 vCPU 和内存方面等效于 ra3.4xlarge 的 8 个节点和 ra3.xlplus 节点类型的 24 个节点。如果您从 ra3.16xlarge 节点类型开始，并发现您远远超过了性能 SLA，并且集群 CPU 利用率低，您可以利用调整选项将集群调整为较小的节点类型。有关调整选项的更多信息，请参阅在线文档。

如果您尚未运行工作负载并需要初始集群大小，则 Amazon Redshift 控制台提供了一个工具（图 2-21），帮助您选择集群大小，考虑参数如所需存储量及工作负载。

图 2-21. 帮助我选择

Amazon Redshift 提供的预留集群的关键方面是，可以按需计费，也可以购买预留实例，这样您就可以获得固定成本和深度折扣。在“帮助我选择”工具中，提供了计算成本摘要（图 2-22）。

承诺 1 年预订可获得 33%的折扣，承诺 3 年预订可获得 61%的折扣。

图 2-22. 样本成本估算

对于 Amazon Redshift 提供的集群，有一些功能会导致额外的变动成本，相比之下，在 Amazon Redshift 无服务器中作为 RPUs 打包。首先是名为并发扩展的功能，在高峰活动期间，会自动为您的数据仓库提供临时集群。其次是名为Amazon Redshift Spectrum的功能，利用一个独立的计算机群来查询 Amazon S3 数据湖中的数据。在第五章，“扩展和性能优化”中，我们将详细讨论并发扩展，在第三章，“设置数据模型和数据摄入”和第四章，“数据转换策略”中，我们将详细讨论如何查询外部数据。现在我们提到它们是为了强调您如何能够控制这些功能并拥有更可预测的成本结构。

AWS 账户管理

您需要一个 AWS 账户来启动任何 AWS 服务，包括 Amazon Redshift。AWS 账户由创建该账户的根用户拥有。创建 AWS 账户后，您可以使用身份和访问管理（IAM）服务创建额外的用户并分配权限给 IAM 用户。我们提到 AWS 账户，因为与您启动的任何其他 AWS 服务一样，对于 Amazon Redshift，您可以通过在不同的账户中启动数据仓库来设立边界，例如开发与生产（见图 2-23）。

图 2-23. AWS 控制塔，AWS 组织和 AWS 账户

AWS 组织（AWS Organizations）帮助您集体管理多个 AWS 账户，分配资源，将账户分组为组织单位（OUs），在这些单位上应用治理和安全策略，并通过指定一个管理账户简化您的组织计费，以便利用单一账单的数量折扣。其他 AWS 账户是成员账户。

通过设置一个指定的安全 OU，并为审计单独设置一个隔离账户，将使您的安全团队能够快速审核整个组织中的所有访问。单独的日志记录账户将允许您集中所有日志文件，当您能够将所有数据关联在一起时，可以轻松地排除端到端应用程序问题。请参阅“使用 AWS 组织的最佳实践设置多账户 AWS 环境”观看短视频。

不必手动设计 AWS 组织和 AWS 账户，您可以利用 AWS 控制塔服务。AWS 控制塔是一个独立的服务，提供预设体验，根据最佳实践蓝图自动设置您的 AWS 组织和 AWS 账户。它还使用预打包的服务控制策略（SCP）和治理规则，用于安全、运营和合规性。

无论您是在 AWS 上全新启动还是已有现有的多账户 AWS 环境，都可以使用 AWS Control Tower。AWS Control Tower 自动设置着陆区，以便将外部文件引入到您的分析环境中，为持续治理应用保护栏杆，自动化供应工作流程，并为 OU、账户和保护栏杆提供预打包仪表板以实现可见性。有关更多详情，请参阅短视频“什么是 AWS Control Tower？”。

连接到您的亚马逊 Redshift 数据仓库

一旦确定了部署架构，接下来您应该问自己的问题是如何控制访问以满足安全需求。今天 IT 组织面临的固有挑战是确保数据平台的访问既安全又灵活且易于管理。管理员需要能够为所有需要访问的人提供访问和工具，但必须符合公司政策并通过批准的网络途径进行访问。根据您需要管理的用户数量以及是否已有用于用户管理、身份验证和授权的现有基础设施，您可以选择一种策略而非另一种。一旦连接，用户的身份将存储在 Amazon Redshift 元数据中。该身份可以分配给一个或多个组，并且将为该用户的授权和活动记录日志以进行追踪。Amazon Redshift 包含不同的功能，可以实现安全和灵活的访问，有许多考虑因素可供选择哪些选项进行利用。此外，AWS 提供了多种工具来访问您的 Amazon Redshift 数据仓库，以及如何利用这些安全功能的多种选项。

私有/公有 VPC 和安全访问

无论您选择无服务器或预置，Amazon Redshift 始终部署在 VPC 和子网中。根据这一选择，数据仓库只能由内部资源访问，或者可以由公共互联网上的资源访问。有关为您的组织确定最佳 VPC 策略的更多详细信息，请阅读在线文档中关于 VPC 场景的内容。此外，当您使用基于 JDBC 或 ODBC 驱动程序的工具连接到 Amazon Redshift 数据仓库时，您是通过 TCP/IP 连接到特定的主机名和端口号。与部署到 VPC 的任何 AWS 服务一样，您可以通过自定义入站规则来控制到 Amazon Redshift 的网络流量，以适配与您的数据仓库关联的安全组。有关理解安全组和设置入站规则的更多详细信息，请参阅在线文档。最后，您可能会遇到 Amazon Redshift 需要连接到运行在您的 VPC 外部或另一个 AWS 帐户中的 AWS 服务的情况。对于这些场景，VPC 端点可能是合适的选择。有关 VPC 端点的更多信息，请参阅在线文档。

包含带有 AWS Direct Connect 的私有子网的以下示例架构（图 2-24）通常由企业用户使用，因为它包含限制只允许企业基础设施内部人员或通过 VPN 服务外部访问的控制措施。为确保与 AWS 云的高带宽和安全连接，该架构利用 AWS Direct Connect。虚拟私有网关确保传输的数据安全且加密。正确设置后，AWS 云内的资源（如 Amazon Redshift 数据仓库和分析工具）可通过私有 IP 地址访问，无论用户是否在内部或外部客户端机器上。

在 AWS 中，Amazon Redshift 部署在私有子网中，这意味着它没有直接的互联网连接，对环境的任何访问都必须起源于 VPC 内部或通过虚拟私有网关。然而，有一些 AWS 服务并不在您的 AWS VPC 内运行。Amazon Redshift 中用于 COPY 和 UNLOAD 命令的关键服务是 Amazon S3 服务。为确保从 Amazon S3 传输到 Amazon Redshift 的数据通过您的 VPC，已启用增强型 VPC 路由功能，并配置了私有子网，该子网引用了指向 Amazon S3 的 VPC 端点的路由表。有关如何配置增强型 VPC 路由的详细信息，请参阅在线文档。

图 2-24. 带有 AWS Direct Connect 的私有子网

存储密码

在 Amazon Redshift 数据仓库中维护用户的最简单机制是创建一个本地用户并在 Amazon Redshift 元数据中存储密码。这种策略几乎适用于任何数据库平台，并且可以简单地使用CREATE USER命令来完成。例如：

CREATE USER name PASSWORD 'password';

当您要维护的用户非常少时，通常会使用此策略，但是随着用户群体的增加，可能会产生管理开销。

临时凭证

要考虑的下一个概念，仅适用于 Amazon Redshift 预置集群的是临时凭证。这种策略是基于 API 函数GetClusterCredentials的。API 调用将以DbUser和DbGroups参数作为输入参数，允许您加入一个或多个数据库组进行授权。API 调用还接受一个AutoCreate参数，当设置时，如果数据库中不存在用户，则会创建一个用户。API 将返回一个用户提供的临时密码。一旦检索到临时密码，您可以使用用户名和临时密码组合登录。

要为预置数据仓库使用临时凭证策略，用户需要首先进行身份验证并关联到 IAM 身份，可以是 IAM 用户或作为 IAM 角色登录。该身份需要具有允许用户使用redshift:GetClusterCredentials操作的 IAM 策略。要启用创建新用户和动态加入组等功能，可以添加redshift:CreateUser和redshift:JoinGroup权限。为了确保用户不能为任何用户获取临时密码或加入他们不应该加入的数据库组，建议缩小策略范围并添加一个条件，确保他们获取临时凭证的用户名与其身份匹配。以下是授予用户访问dev数据库和加入marketing组的示例策略。还有一个条件，确保aws:userid与传递给GetClusterCredentials API 命令的DbUser匹配：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "redshift:GetClusterCredentials",
        "redshift:CreateUser",
        "redshift:JoinGroup"
        ],
      "Resource": [
        "arn:aws:redshift:*:123456789012:cluster:rs-cluster",
        "arn:aws:redshift:*:123456789012:dbuser:rs-cluster/${redshift:DbUser}",
        "arn:aws:redshift:*:123456789012:dbname:rs-cluster/dev",
        "arn:aws:redshift:*:123456789012:dbgroup:rs-cluster/marketing"
        ],
      "Condition": {
        "StringLike": {
          "aws:userid": "*:${redshift:DbUser}"
        }
      }
    }
  ]
}

除了允许已通过 IAM 身份登录到 AWS 的用户查询 Amazon Redshift 外，该策略还内置于 JDBC 和 ODBC 驱动程序中。您只需向驱动程序指示将使用 IAM 进行身份验证并将其 IAM 身份传递给它即可。更多关于如何配置 JDBC 或 ODBC 连接以使用 IAM 凭证的信息，请参阅在线文档。

通过传递AccessKeyID和SecretAccessKey来传递 IAM 身份的简单方法。请参阅以下示例 JDBC URL：

jdbc:redshift:iam://examplecluster:us-west-2/dev?
    AccessKeyID=AKIAIOSFODNN7EXAMPLE&
    SecretAccessKey=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

联合用户

下一个需要考虑的概念是联合用户。此策略基于 API 函数GetClusterCredentialsWithIAM（针对预配）和GetCredentials（针对无服务器）实现。类似于 API 调用GetClusterCredentials，这些 API 将获取用户的临时密码；不过，与传递这些 API 的授权参数不同，API 将根据登录的身份读取值。在无服务器情况下，它将从aws:userid检索用户名，并将从主体标签RedshiftDbRoles中检索数据库角色以授权会话。在预配情况下，它仅检索存储在aws:userid中的用户名。在两种情况下，默认情况下，如果用户不存在，将创建用户。一旦获取临时密码，用户可以使用用户名和临时密码组合登录。

类似于GetClusterCredentials，要使用联合用户，用户首先需要进行身份验证，并关联到 IAM 身份，可以是 IAM 用户或作为 IAM 角色登录。该身份需要具有 IAM 策略，允许用户对预配执行redshift:GetClusterCredentialsWithIAM操作和对无服务器执行redshift-serverless:GetCredentials操作。使用联合用户选项时，您无需任何额外权限。在无服务器情况下，如果要启用基于角色的授权，则需要确保使用的 IAM 身份具有设置RedshiftDbRoles主体标签。以下是授予用户访问dev数据库的示例策略：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action":
        "redshift-serverless:GetCredentials",
      "Resource":
        "arn:aws:redshift-serverless:*:123456789012:workgroup/rs-workgroup",
    }
  ]
}

类似于GetClusterCredentials API，联合用户功能已经内置于 JDBC 和 ODBC 驱动程序中，并且在连接到无服务器数据仓库时默认使用，只要在驱动程序中指定将使用 IAM 进行身份验证。了解如何配置 JDBC 或 ODBC 连接以使用 IAM 凭据，请参阅在线文档。

基于身份提供者的基于 SAML 的身份验证

通常情况下，对于企业和大规模的 Amazon Redshift 部署，您的用户身份不会存储在 IAM 中，而是存储在身份提供者（IdP）如 Okta、Azure Ad 或 PingFederate 中。如果是这种情况，将 IAM 或 Amazon Redshift 元数据中的单独目录保持一致并非可扩展的解决方案。此外，用户可能属于多个组，并为每个组合维护单独的 IAM 角色将变得难以管理。AWS 平台本地支持使用AssumeRoleWithSAML API 命令从 IdP 建立 IAM 身份。通过利用这一策略，可以假定包含执行GetClusterCredentials权限的 IAM 角色。此功能已内置于 Amazon Redshift JDBC 和 ODBC 驱动程序中。在图 2-25 中，您可以看到 SQL 客户端如何与 IdP 和 AWS 服务（如 AWS 安全令牌服务（AWS STS）和 IAM）交互，然后才能连接到 Amazon Redshift。

图 2-25. 安全断言标记语言（SAML）认证

查看在线文档以详细了解不同的 IdP 和支持的功能，如多因素身份验证。

想要设置 Okta IdP 的逐步指南，请参阅使用OktaCredentialsProvider插件的博客文章。对于需要多因素身份验证的场景，请参阅同样使用 Okta IdP 但利用BrowserSamlCredentialsProvider插件的博客文章。

无论您使用 Okta 还是其他 IdP，所需的步骤包括：

1. 在您的 IdP 中创建一个供用户访问的 SAML 应用程序。

2. 配置应用程序引用 IAM 角色并传递用户和组信息。

3. 从您的 IdP 下载应用程序元数据。

4. 在 AWS 控制台内使用刚刚下载的元数据建立一个 IdP。

本地 IdP 集成

当应用程序通过 OAuth 令牌建立信任关系时，Amazon Redshift 具有额外的插件，例如BrowserAzureOAuth2CredentialsProvider。与利用 API 命令或 IAM 建立信任关系不同，Amazon Redshift 驱动程序将发起初始请求到身份提供者以验证凭据，并弹出多因素认证提示（如果需要），并接收 OAuth 令牌。接下来，Amazon Redshift 服务将使用 OAuth 令牌向 IdP 发起进一步调用以获取组授权信息。本地 IdP 架构（图 2-26）概述了在使用 Azure Active Directory 作为身份提供者时，Microsoft Power BI 如何集成以及本地集成的工作原理。

图 2-26. 本地 IdP 架构

若要详细了解如何设置与 Power BI 和活动目录的本地 IdP 集成，请参阅此 博客文章。

亚马逊 Redshift 数据 API

连接到亚马逊 Redshift 并查询数据的另一种方法是使用亚马逊 Redshift 数据 API（图 2-27）。使用此策略，用户不直接连接到亚马逊 Redshift，而是连接到安全的 HTTP 端点。您可以使用端点运行 SQL 语句，而无需管理连接。Data API 的调用是异步的。使用此策略，应用程序需要访问互联网，或者如果您正在从私有 VPC 运行应用程序，则可以设置 VPC 端点。有关设置 VPC 端点的详细信息，请参阅此 在线文档。

图 2-27. 亚马逊 Redshift 数据 API

要使用亚马逊 Redshift 数据 API，用户需要首先通过 AWS 进行身份验证，并与 IAM 身份相关联，可以是 IAM 用户或以 IAM 角色身份登录。该角色将需要权限来使用亚马逊 Redshift 数据 API。权限以 redshift-data: 为前缀，包括元数据查询如 ListTables 和 ListSchemas，执行命令如 ExecuteStatement 和 GetStatementResults，以及监控查询如 DescribeStatement。可在 在线文档 中查看详细的命令列表。

在使用亚马逊 Redshift 数据 API 时，您有两种身份验证选项。首先是使用临时凭证，在调用 API 时传递 DbUser 参数，但不传递 SecretArn 参数。要了解更多关于使用临时凭证的信息，请参见 “临时凭证”。相反，您可以通过传递 SecretArn 参数而不传递 DbUser 参数来使用存储的密码进行身份验证。要了解更多关于使用存储密码的信息，请参见 “存储的密码”。

在以下示例中，您可以看到如何利用亚马逊 Redshift 数据 API 执行一个简单的 CREATE SCHEMA 命令，使用存储在密钥中的凭证：

aws redshift-data execute-statement \
     --database <your-db-name>  \
     --cluster-identifier <your-cluster-id> \
     --secret-arn <your-secret-arn> \
     --sql "CREATE SCHEMA demo;" \
     --region <your-region>

要详细了解如何使用亚马逊 Redshift 数据 API，请参阅此 博客文章。

使用查询编辑器 V2 查询数据库

在确定了身份验证策略之后，下一步是查询您的数据。亚马逊 Redshift 提供两个版本的查询编辑器——传统查询编辑器和查询编辑器 V2（图 2-28）。您可以使用它们来编写和运行对亚马逊 Redshift 数据仓库的查询。虽然传统查询编辑器仍然可用，但我们建议使用查询编辑器 V2，因为它具有额外的功能，允许您管理数据库对象、可视化结果，并与团队共享工作，除了编辑和运行查询。它显示数据库、模式和树形视图面板中的所有对象，便于访问数据库对象。

Figure 2-28. 查询编辑器 V2

查询编辑器 V2 有两种标签类型（Figure 2-29）：编辑器标签和笔记本标签。编辑器标签允许您在一个页面中整理所有查询，并同时触发执行。编辑器将按顺序执行所有查询，并在不同的结果标签中生成结果。SQL 笔记本标签包含 SQL 和 Markdown 单元格，您可以在单个文档中组织、注释和共享多个 SQL 命令。编辑器脚本和笔记本均可保存并与团队共享，以便进行协作。在本书中，我们将使用查询编辑器 V2，因为这是在 Amazon Redshift 中查询数据的未来方向。

Figure 2-29. 查询编辑器 V2 标签类型

要在 AWS 控制台内访问查询编辑器 V2，请单击查询数据按钮下方的链接（Figure 2-30）。

Figure 2-30. 查询数据

要允许用户访问查询编辑器 V2，您可以将 AWS 管理的查询编辑器 V2 策略之一（Table 2-2）附加到 IAM 用户或角色上。这些托管策略还提供对其他所需服务的访问。如果您希望为最终用户自定义权限，也可以创建用户管理的策略。

Table 2-2. 查询编辑器 V2 策略

策略	描述
AmazonRedshiftQueryEditorV2FullAccess	授予对查询编辑器 V2 操作和资源的完全访问权限。这主要用于管理员。
AmazonRedshiftQueryEditorV2NoSharing	允许在不共享资源的情况下使用查询编辑器 V2。用户不能与团队成员共享他们的查询。
AmazonRedshiftQueryEditorV2ReadSharing	允许在有限共享资源的情况下使用查询编辑器 V2。授权的主体可以读取与团队共享的保存查询，但不能更新它们。
AmazonRedshiftQueryEditorV2ReadWriteSharing	允许在共享资源的情况下使用查询编辑器 V2。授权的主体可以读取和更新团队共享的资源。

要实现团队成员之间的查询协作，您可以对 IAM 主体进行标记。例如，如果您有一组用户作为marketing_group的一部分，并且希望他们通过共享他们的查询进行协作，您需确保他们的 IAM 角色marketing_role被分配了AmazonRedshiftQueryEditorV2ReadSharing策略。您还可以使用标签sqlworkbench-team为角色打标签，其值为marketing_group。现在，使用marketing_role登录的最终用户可以访问查询编辑器 V2，并具有共享其查询的能力。

当使用查询编辑器连接到您的 Amazon Redshift 数据仓库时，您将看到几个选项。您可以作为“联合用户”连接，使用“临时凭证”，通过“数据库用户名和密码”，或通过“AWS Secrets Manager”连接。

查询编辑器 V2 中的临时凭证选项仅在连接到已配置的集群时可用。

联合用户

当使用查询编辑器 V2 并选择联合用户选项（图 2-31）时，对于已配置与无服务器数据仓库不同。对于已配置，查询编辑器 V2 将依赖于临时凭证认证方法中使用的 GetClusterCredentials。然而，与其要求用户和组信息不同，它将从两个主体标签 RedshiftDbUser 和 RedshiftDbGroups 中查找这些值，并将这些标签中的值传递给 API 调用。这些主体标签可以直接在 IAM 中设置，也可以从 IdP 传递。要使用此策略，从 IdP 传递的 IAM 角色还需要具有使用临时凭证的权限，如前所述。使用此策略既具有可扩展性又易于使用，因为终端用户唯一需要输入的是数据库名称。有关如何设置 Okta 联合用户登录的详细步骤，请参阅此博客文章。

图 2-31. 查询编辑器 V2 联合用户

相反，当选择联合用户（图 2-31）用于无服务器数据仓库时，查询编辑器 V2 将利用联合用户认证方法中使用的 GetCredentials API 调用。类似地，数据库用户名将从 aws:userid 中检索，数据库角色将从 RedshiftDbRoles 主体标签中检索。

临时凭证

临时凭证选项（图 2-32）与联合用户选项类似，即 IAM 身份需要具有使用临时凭证的权限。一个显著的区别是它不依赖于主体标签，因此除了 Database 参数外，用户还必须输入用户名，并且不会自动添加到组中。

图 2-32. 查询编辑器 V2 临时凭证

数据库用户名和密码

使用密码选项（图 2-33）时，除了 Database 和 User name 参数外，用户还必须提供密码。为了在后续会话中更容易使用，密码将保存在 Secrets Manager 服务中，并且使用查询编辑器的 IAM 身份需要具有读写 Secrets Manager 的权限。

图 2-33. 查询编辑器 V2 存储密码

AWS Secrets Manager

使用 AWS Secrets Manager 选项（图 2-34），用户只需指定预定义的 AWS 秘密。在这种情况下，该秘密将由管理员预先创建，因此使用查询编辑器的 IAM 身份不需要权限写入 Secrets Manager。

图 2-34. 查询编辑器 V2 AWS Secrets Manager

若要了解更多有关查询编辑器 V2 的示例，请参阅以下博客文章：

• “使用 Amazon Redshift Query Editor V2 简化数据分析”

• “介绍 Amazon Redshift Query Editor V2，一款供数据分析师使用的免费 Web 查询创作工具”

• “使用 Active Directory 联合服务（AD FS）将 Amazon Redshift Query Editor V2 联合访问”：第三部分

使用 Amazon QuickSight 进行商业智能分析

您可以使用 BI 平台通过 JDBC 和 ODBC 驱动程序连接到 Amazon Redshift，这些驱动程序可以作为这些应用程序的一部分打包或下载。与 Amazon Redshift 集成的流行 BI 平台包括MicroStrategy，Power BI，Tableau和Looker。有关使用这些驱动程序连接到 Amazon Redshift 的更多信息，请参阅“使用 JDBC/ODBC 连接到 Amazon Redshift”。

AWS 还提供一种原生云服务器无服务 BI 服务，Amazon QuickSight，与 Amazon Redshift 紧密集成，无需设置驱动程序。 Amazon QuickSight 采用按用户付费的定价模型，自动扩展，无需维护服务器。您可以在Amazon QuickSight Gallery上探索许多实时示例仪表板，演示该工具中提供的各种功能。

在以下零售分析示例仪表板中（图 2-35），您可以看到 QuickSight 的许多关键功能。其中一些功能包括内置的机器学习算法用于预测和检测异常，定制的叙述内容以及丰富的可视化效果。

图 2-35. QuickSight 示例仪表板

在众多 QuickSight 数据源（图 2-36）中，有两种选项可连接到 Amazon Redshift：Redshift 自动发现和 Redshift 手动连接。一旦建立连接，用户可以通过几次点击开始构建报告和仪表板。

图 2-36. QuickSight 数据源

当您利用 Redshift 自动发现选项时，用户选择要连接的 Redshift 实例 ID，并输入数据库、用户名和密码（图 2-37）。

图 2-37. QuickSight Redshift 自动发现连接

当您使用 Redshift 手动连接选项时，用户除了输入数据库、用户名和密码外，还需输入数据库服务器和端口（图 2-38）。

图 2-38. QuickSight Redshift 手动连接

使用 JDBC/ODBC 连接 Amazon Redshift

许多第三方 BI 和 ETL 工具通过 JDBC 和 ODBC 驱动访问 DB 平台。Amazon Redshift 提供开源驱动程序供您下载，并可能已经打包在您的第三方工具中。这些驱动程序由 AWS 经常更新，以配合产品发布的新功能。虽然 Amazon Redshift 也兼容 Postgres 驱动程序，但这些驱动程序不支持 Amazon Redshift 驱动程序中提供的所有功能，例如 IAM 认证。要配置您的 Amazon Redshift 驱动程序，您可以通过访问 Amazon Redshift 控制台获取连接 URL。

对于预置集群，您可以通过检查集群摘要页面找到 JDBC/ODBC URL（图 2-39）。

图 2-39. Amazon Redshift 预置 JDBC/ODBC URL

对于服务器无服务器工作组，您可以通过检查工作组摘要页面找到 JDBC/ODBC URL（图 2-40）。

图 2-40. Amazon Redshift 无服务器 JDBC/ODBC URL

在以下示例中，使用开源 Java 工具 SQL Workbench/J，我们已经使用收集的信息设置了客户端配置（图 2-41）。使用此工具，您可以利用扩展属性对话框设置用于功能（如基于 SAML 的身份验证）所需的可选参数。

图 2-41. JDBC 客户端配置

还请注意 Autocommit 复选框：这是一个经常被忽视的设置，在大多数情况下应启用。因为 Amazon Redshift 遵循 ACID（原子性、一致性、隔离性、持久性）规范的原子性特性，需要在多个用户事务中维护数据状态。当禁用时，Amazon Redshift 将假定每个连接都是新事务的开始，并且除非执行显式的 commit 语句，否则不会提交事务。如果忽视了此设置，系统可能会不必要地使用资源来跟踪多个事务状态。如果发现自己处于这种情况，请使用 PG_TERMINATE_BACKEND 命令终止空闲连接。

要获取有关配置 JDBC 驱动程序的更多详细信息和选项，请查阅此JDBC 驱动程序文档，要获取有关配置 ODBC 驱动程序的更多详细信息和选项，请查阅此ODBC 在线文档。

总结

在本章中，我们向您展示了 Amazon Redshift 的架构及其入门方式。我们比较了无服务器和预配置的部署选项，展示了如何快速查询示例数据，并展示了不同的认证和连接选项。

在下一章中，我们将向您展示如何从数据湖、操作性源和实时流数据源最佳建模和加载数据。

第三章：设置您的数据模型和摄入数据

现在您已经设置好了 Amazon Redshift 数据仓库，让我们考虑一个数据管理策略。

在本章中，我们将讨论几种数据管理策略选项，以及是否应该采用“数据湖优先与数据仓库优先策略”。接下来，我们将进入“定义您的数据模型”，并使用“学生信息学习分析数据集”来说明如何在 Amazon S3 中创建表格和“批量加载数据到 Amazon Redshift”。然而，在今天的竞争激烈的世界中，洞察力的速度至关重要，我们还将向您展示如何“加载实时和准实时数据”。最后，我们将介绍如何“优化您的数据结构”。

数据湖优先与数据仓库优先策略

在今天的数字时代，组织不断收集和生成大量数据。这些数据可以来自各种来源，如用户互动、传感器读数和社交媒体活动。有效管理这些数据对于组织获取见解并做出明智的业务决策至关重要。在管理这些数据时面临的关键挑战之一是决定适当的数据管理策略。组织常用的两种流行策略是数据湖优先策略和数据仓库优先策略。当您考虑您的基于云的数据管理策略时，无论是迁移本地数据仓库还是加载新数据，您应该考虑的一个问题是是否采用数据湖优先策略还是数据仓库优先策略。

数据湖优先策略

数据湖优先策略涉及创建一个集中的存储库，用于存放所有原始数据，无论其结构或格式如何。这个数据湖通常建立在可扩展的存储平台上，例如亚马逊 S3，并且设计用于处理大量数据。然后将数据以其原始形式摄入到数据湖中，数据科学家、分析师和其他利益相关者可以使用各种数据处理和分析工具从数据中提取见解。

数据湖优先策略的主要优势之一是它允许灵活性和可伸缩性。组织可以轻松摄入新的数据源，并且数据湖可以扩展以处理大量数据。此外，保持原始数据未经转换的格式可以提供更精确的洞察，并保持数据的完整性和数据血统。

然而，数据湖优先策略的主要缺点之一是，管理和有效治理数据可能会很困难。您必须适当地将文件组织和维护在存储桶中，进行分区以获得良好的性能。此外，数据科学家和分析师可能需要花费大量时间和资源准备数据，然后才能提取见解。

数据仓库优先策略

数据仓库优先策略涉及创建为查询和报告优化的集中式数据库。数据从各种来源提取，经过转换以适应预定义的架构，然后加载到数据仓库中。数据科学家、分析师和其他利益相关者随后可以使用 SQL 或其他查询语言从数据中提取见解。当主要关注点是分析和商业智能时，通常偏好这种方法，并且这种中心化的数据存储用于与其他服务或用户共享数据。

数据仓库优先策略的主要优势之一是，它允许更好的数据治理和管理。结构化数据易于理解和查找，这使得利益相关者更容易提取见解。业务分析师可以使用易于使用的 ANSI SQL 查询语言分析数据。数据在加载过程中经过转换和清理，因此减少了为分析准备数据所需的时间和资源。

然而，数据仓库优先策略的主要缺点之一是，组织可能需要花费更多的时间和资源，从新数据源中提取和转换数据，然后才能提供给业务决策者访问。此外，转换和清理过程可能导致数据丢失或不准确，在 ETL 设计过程中需要考虑这些问题。零 ETL 策略的新创新减轻了从源到目标复制数据的一些问题。

制定策略

数据湖优先策略和数据仓库优先策略都有各自的优缺点。组织在选择策略时必须考虑其特定需求和目标。数据湖优先策略最适合需要处理大量结构化和非结构化数据，并需要更灵活性和可扩展性以通过更广泛的工具访问数据的组织。另一方面，数据仓库优先策略最适合希望使用基于 SQL 的数据管理和数据治理来处理结构化和半结构化数据的组织。

选择策略可能取决于数据来源，以及您是希望在表级别还是应用程序层级复制数据从源到目标。当您从源系统提取数据时，通常会在物理层面以表级别复制。但是，如果源系统是像 Salesforce、SAP 或 ServiceNow 这样的 SaaS 应用程序，则可以选择在数据库表层级或应用程序层级复制数据。由于这些 SaaS 应用程序通常涉及数千个表，它们通常内置提取逻辑来应用本地表的业务规则。例如，SAP 拥有数据提取器（SAP Business Warehouse 提取器），用于将业务逻辑应用到源表并在逻辑层面提取数据。例如，销售订单交易可能存储在 SAP 应用程序内的 50 个不同表中，但提取器将应用业务逻辑来合并这些表，以提供一个易于使用的单个去规范化的销售数据行。如果您希望将这些数据集中存储用于各种工作负载，例如大数据处理、机器学习或用于本地和非本地 AWS 分析服务的分析，则构建数据湖是有意义的。如果工作负载纯粹用于分析和 BI，那么最好采用数据仓库优先的方法。

如果需求要求在表级别进行复制，则可以将原始数据带入数据湖，或直接将数据摄入到数据仓库（例如 Amazon Redshift）。您在这种情况下采取的方法将取决于您的业务和技术要求。在 AWS 云中，如果您希望将原始数据与 Amazon S3 数据湖中的其他服务（如 EMR、Athena 或 SageMaker）共享，以供业务用户和数据科学家使用，则采用数据湖优先的方法是有意义的。采用湖优先的方法，您可以灵活地保留数据的原始格式，并在数据上建立治理，无需通过其他服务即可共享数据。这增加了维护 Amazon S3 中原始文件的复杂性，并通过存储和管理存储桶和分区来实现最佳的存储和性能分区。可以使用 Apache Hudi 来更新这些文件。

在选择方法之前，您需要首先评估组织中的技能和长期战略。Amazon Redshift 现在支持本地 Spark 集成，可以在 Amazon Redshift 上运行 EMR 或 AWS Glue 代码。此集成使您可以编写 Python 或 Scala 代码，Amazon Redshift 将负责将代码转换为本地 SQL 代码，并在 Amazon Redshift 数据仓库内运行。借助 Amazon Redshift ML，您可以使用 SQL 语法运行机器学习，而无需使用 Python 或 R 语言进行编码。通过像数据共享、Amazon Redshift ML、本地 Spark 集成和 AWS 数据交换（ADX）集成这样的新功能，构建数据湖仅用于与其他服务共享数据的需求可能进一步减少。

在“数据仓库优先”方法中，您将原始数据直接导入到 Amazon Redshift 数据仓库中。这是通过使用 AWS 数据库迁移服务（DMS）或您选择的数据集成工具在数据库表级别完成的。这将与 ELT 方法一致，其中您随后从数据仓库内部读取原始数据进行转换和加载，以供进一步分析使用。通过这种方法，当您需要将数据共享到其他 AWS 本地服务时，您可以使用 Amazon Redshift 数据共享功能；而对于非本地服务的其他用例，您可以使用UNLOAD命令将数据从 Amazon Redshift 卸载到 Amazon S3。

综上所述，数据湖与数据仓库优先策略中的“数据湖优先”方法在您希望保留原始数据以满足已知和未知未来需求、为您的分析应用未雨绸缪时非常有用。这是为了满足组织层面决策者的需求，最初可能难以提供业务价值。数据湖只是数据的存储库，需要额外的计算服务来产生价值。而“数据仓库优先”方法则是将处理后的数据存储在专门构建的数据存储中，通常适用于特定领域和需求范围。它非常适合分析大数据，因为它结构良好、易于使用和理解。组织通常需要两者兼而有之。数据仓库已存在多年。数据湖则诞生于需要利用大数据并从原始、粒度化的结构化和非结构化数据中获益的需求。但仍然需要创建数据仓库，以供业务用户进行分析使用。

定义您的数据模型

在启动 Amazon Redshift 时，将创建一个默认数据库。您可以在默认数据库下创建您的数据库对象，或创建额外的数据库以便在不同数据库下组织对象。如何组织数据库对象将取决于多个因素，包括应用程序所有权、安全需求、易于管理以及跨数据库查询需求。

本节描述了 Amazon Redshift 数据仓库的组织结构，并提供了理解在哪里创建数据库对象的起点。我们还将涵盖用于管理数据的常见数据建模策略。

数据库架构、用户和组

对于 Amazon Redshift，数据库是数据库对象层次结构中的最高级别，您可以在数据仓库中创建多个数据库。在每个数据库中，您可以有一个或多个模式。在每个模式中，您可以创建以结构化格式存储数据的表，以及包括视图、过程和函数在内的其他对象。默认情况下，数据库有一个名为“public”的单个模式。您可以使用模式将数据库对象分组到一个公共名称下。

Amazon Redshift 支持跨模式和跨数据库查询，您可以选择将与每个应用程序相关的数据库对象组织在单独的模式或单独的数据库中。在组织数据库时，请考虑您的查询是否必须跨数据库。跨模式查询发生在同一个数据库中，并且没有任何限制。但是跨数据库查询有一些限制，您应考虑这些限制。就性能而言，注意跨数据库查询不支持结果缓存，因此重复查询必须针对数据库进行。并发缩放也不支持跨数据库查询。在决定将对象组织到不同数据库之前，请考虑多少百分比的查询必须跨数据库。

另一个要考虑的因素是工作负载或业务领域中模式或表对象的数量。如果所需的模式或表对象数量超过配额或限制，那么您可能希望将数据组织在单独的数据库中。

对于跨数据库查询，您可以使用两点(database.schema.table)表示法访问当前数据库之外的表。您还可以创建外部模式以使用一点(externalschema.table)表示法进行引用。有关跨数据库查询的更多详细信息，请参考跨数据库查询数据。

当您拥有多租户架构时，您可以参考此博客来组织您的数据库对象。

星型模式、去规范化、规范化

数据仓库使用星型模式构建，其中有一个或多个中心事实表包含要分析的度量，周围是提供分析业务背景的维度表。这种布局看起来像一个星星，因此得名。星型模式维度可以是去规范化的单个表，每个维度的属性都有列，也可以进一步规范化为单独的表，这使得模式图看起来像雪花而不是星星，因此称为雪花模式(图 3-1)。

图 3-1. 星型模式对象与雪花模式对象的比较

星型模式数据模型在维表中存储冗余数据，而在雪花模式中，维表避免了冗余。然而，这会增加查询复杂性，并可能影响查询性能，因为分析时需要连接更多的表。在创建 Amazon Redshift 的数据仓库时，推荐使用星型模式数据模型或去规范化数据模型。

另一方面，雪花模式的存储需求较低，因为没有冗余，数据完整性问题的风险也较低。

随着存储介质的进步和每 TB 价格的下降，存储方面不再是问题，查询简单性通常更受现代数据仓库的重视。这使得星型模式成为运行非常大数据集分析的流行架构。

让我们看一个简单的数据模型，以了解标准化和去规范化星型模式之间的区别。销售订单使用标准化模型存储在关系数据库中。如您在图 3-2 中所见，销售头和销售行项目存储在单独的表中，并且与客户、产品和货币的主数据表具有一对多的关系。

图 3-2. 源数据库中的去规范化 OLTP 模式数据模型

对于图 3-3 中的星型模式模型，销售头和销售行项目表合并为一个销售事实表，并且数据还在订单级别进行了聚合。

图 3-3. 数据仓库的星型模式数据模型

学生信息学习分析数据集

在前一章中，您学习了如何创建 Amazon Redshift 无服务器数据仓库，并使用查询编辑器查询示例数据。现在让我们看看如何创建新的数据模型，将数据导入 Amazon Redshift，并使用本地查询编辑器进行分析。

为此，我们选择了一个帮助你了解如何构建星型模式数据模型并将数据导入 Amazon Redshift 以分析、预测和改善学生结果的学生学习分析数据集¹。

Open University 学习分析数据集（OULAD）包含关于课程、学生及其在在线虚拟学习环境（VLE）中互动的数据，适用于七个选定的课程（称为模块）。数据集假设每年有两个学期，课程在每年的二月和十月开始。课程学期由课程表中的 code_presentation 列标识，而代码模块则以字母“B”和“J”后缀，并以四位数年份作为前缀。数据集由使用唯一标识符连接的表组成，所有表均以 CSV 格式存储。

数据模型包括七个表，其中包含与学生、模块和活动相关的数据，如 图 3-4 所示，显示了实体关系。为了本书的目的，我们修改了此数据模型，以存储多个学校的数据，而不仅仅是一个学校。您可以使用所示的数据定义语言（DDL）脚本（参见 示例 3-1）来创建架构和数据库表。

匿名样本数据集可在链接 OULAD 数据集 中获取，了解更多数据集信息，并可以下载并存储在您选择的 S3 存储桶中。我们将其存储在 S3 存储桶 arn:aws:s3:::openlearn-redshift 中，您可以使用此 S3 位置使用 COPY 命令将数据导入 Amazon Redshift。您可以查看 S3 数据集，如 图 3-5 所示。

图 3-4. 学生信息系统数据集

您可以查看 S3 数据集，如 图 3-5 所示，并将其用作源，使用 COPY 命令将样本数据集导入 Amazon Redshift。同样，您可以找到其他公开可用的数据集，并为这些数据集创建数据模型，以探索 Amazon Redshift 的功能。

图 3-5. 在 Amazon S3 中查看原始数据

为学生信息学习分析数据集创建数据模型

接下来，让我们创建数据库表，将数据加载到 Amazon Redshift 中。连接到您的 Amazon Redshift 数据仓库。使用以下脚本为您的样本学生信息数据集创建架构和表（参见 示例 3-1）。

示例 3-1. 加载学生信息数据

/* We'll use a modified version of the Open University Learning Analytics dataset */
/* to store data for multiple schools */
/* https://analyse.kmi.open.ac.uk/open_dataset */
/* https://analyse.kmi.open.ac.uk/open_dataset#rights */
/* Kuzilek J., Hlosta M., Zdrahal Z. Open University Learning Analytics dataset */
/* Sci. Data 4:170171 doi: 10.1038/sdata.2017.171 (2017). */

CREATE SCHEMA openlearn;

CREATE TABLE "openlearn"."assessments"
(
    code_module varchar(5),
    code_presentation varchar(5),
    id_assessment integer,
    assessment_type varchar(5),
    assessment_date bigint,
    weight decimal(10,2)
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearn"."courses"
(
    code_module                varchar(5),
    code_presentation          varchar(5),
    module_presentation_length integer
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearn"."student_assessment"
(
    id_assessment  integer,
    id_student     integer,
    date_submitted bigint,
    is_banked      smallint,
    score          smallint
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearn"."student_info"
(
    code_module           varchar(5),
    code_presentation     varchar(5),
    id_student            integer,
    gender                CHAR(1),
    region                varchar(50),
    highest_education     varchar(50),
    imd_band              varchar(10),
    age_band              varchar(10),
    num_of_prev_atteempts smallint,
    studied_credits       smallint,
    disability            char(1),
    final_result          varchar(20)
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearn"."student_registration"
(
    code_module         varchar(5),
    code_presendation   varchar(5),
    id_student          integer,
    date_registration   bigint ,
    date_unregistration bigint
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearn"."student_lms"
(
    code_module       varchar(5),
    code_presentation varchar(5),
    id_student        integer,
    id_site           integer,
    date              bigint,
    sum_click         integer
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearn"."lms"
(
    id_site           integer,
    code_module       varchar(5),
    code_presentation varchar(5),
    activity_type     varchar(20),
    week_from         smallint,
    week_to           smallint
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

在创建 Amazon Redshift 表时，虽然有多种选项可供选择分发、排序和编码每个表，但在上一个示例中，我们没有指定这些选项，并且使用了 AUTO 的默认设置。在大多数情况下，使用 AUTO 将指示 Amazon Redshift 服务监视表的实际使用情况，并自动调整表。

将批量数据加载到 Amazon Redshift

现在您已创建数据表并在 Amazon S3 中有数据文件可用，您可以将数据加载到 Amazon Redshift 中。有多种选项可用于将数据加载到 Amazon Redshift 中。

• 使用 COPY 命令

• 使用 AWS Glue 或第三方 ETL 工具

• 使用 SQL 命令进行手动加载

• 使用查询编辑器 V2

使用 COPY 命令

COPY命令是将数据加载到 Amazon Redshift 中最简单和最有效的方式。它允许直接从 Amazon S3、Amazon DynamoDB 和 Amazon EMR 加载数据，以及从 CSV 和 JSON 文件等外部数据源加载。COPY命令自动并行加载数据，并可以快速轻松地处理大量数据。该命令读取多个数据文件，并根据目标数据仓库中的切片数量必要时分割文件，以将工作负载分配给所有节点和切片。它还将行排序并分发数据到节点切片之间。存储在 Amazon S3 中时，推荐的最佳做法是压缩文件以提高读取速度。在数据摄入方面，请注意加载压缩文件与未压缩文件之间的差异。

当您将压缩数据作为单个大文件加载时，Amazon Redshift 会串行加载数据。但是，如果您将文件分割成较小的文件，COPY命令会并行加载多个文件。这通过将工作负载分割到数据仓库中的节点之间增加了并行性。我们建议您将数据分割成大约相等大小的较小文件，压缩后大小从 1 MB 到 1 GB。为了实现最佳并行性，根据您的数据仓库中切片的数量将文件数设为 1 到 125 MB 之间的倍数。例如，如果您将 1 GB 文件加载到具有每个节点 4 个切片的双节点 ra3.4xlarge 数据仓库中，则可以将文件分割为 8 个 125 MB 大小的文件，以实现高效加载。

当您从单个大压缩文件加载所有数据时，Amazon Redshift 被迫执行串行加载，速度要慢得多。

相比之下，当您从大型未压缩文件中加载分隔数据时，Amazon Redshift 会利用多个切片。这些切片会自动并行工作。这提供了快速的加载性能。具体来说，当 Amazon Redshift 加载未压缩的分隔数据时，数据会分割成范围，并由每个节点中的切片处理。

当加载压缩文件时，一个好的做法是将数据分割成大约相等大小的较小文件，压缩后大小从 1 MB 到 1 GB。为了实现最佳并行性，理想的文件大小在压缩后为 1 到 125 MB。

摄入学生学习分析数据集

为了摄入示例学生学习分析数据集，我们使用推荐的COPY命令，将样本数据存储在 Amazon S3 桶中。命令列表如示例 3-2 所示，您可以使用这些命令，并替换适当值的 S3 位置和地区。

示例 3-2. 创建学生信息数据的模式和表

COPY "openlearn"."assessments"
FROM 's3://openlearn-redshift/assessments'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearn"."courses"
FROM 's3://openlearn-redshift/courses'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearn"."student_assessment"
FROM 's3://openlearn-redshift/studentAssessment'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearn"."student_info"
FROM 's3://openlearn-redshift/studentInfo'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearn"."student_registration"
FROM 's3://openlearn-redshift/studentRegistration'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearn"."student_lms"
FROM 's3://openlearn-redshift/studentlms'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearn"."lms"
FROM 's3://openlearn-redshift/lms'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

我们使用default关键字来使用与数据仓库关联的默认 IAM 角色。当命令运行时，Amazon Redshift 使用被设定为默认并与数据仓库关联的 IAM 角色。您可以运行DEFAULT_IAM_ROLE命令来检查当前附加到数据仓库的默认 IAM 角色。详细信息请参见 此处设定为默认。

Amazon Redshift 根据排序键顺序对每批记录进行排序。然而，它不会对已存储的每个COPY执行中的现有记录重新排序。如果每批新数据遵循表中现有行的顺序，则您的数据将按排序顺序正确存储，您无需运行真空操作。您不需要在每次加载中对行进行预排序，因为COPY在加载每批传入数据时会对数据进行排序。

构建星型模式

您刚刚将数据导入了一个规范化的学生信息数据模型，用于存储学生的课程选择、成绩、结果和注册的事务记录。然而，业务需求是使学校管理员和教师能够衡量课程成果。如前一章所讨论的，一个由事实和维度表组成的星型模式模型是数据仓库的推荐数据模型。表course_registration、course_outcome和course_schedule包含了测量结果所需的数据，因此这些表可以形成事实表的基础。

有许多方法可以将数据转换为您的去规范化事实表。您可以使用 提取-转换-加载 (ETL) 方法，该方法读取源数据，在外部应用程序中处理转换，并加载结果；或者您可以使用 提取-加载-转换 (ELT) 方法，该方法使用您刚刚加载的数据，并利用 Amazon Redshift 计算的能力在原地转换数据。在 第四章，“数据转换策略” 中，我们将更详细地讨论如何在这些策略之间进行选择。然而，为了完成此示例，我们将展示如何使用您刚刚加载的数据来使用 ELT 方法。

示例 3-3 读取规范化的源表，并构建mv_course_outcomes_fact物化视图。创建物化视图的优点是，当底层表更新时，可以设置增量刷新数据。

示例 3-3. 创建一个物化视图来去规范化

CREATE materialized view mv_course_outcomes_fact AS
SELECT
    co.student_id,
    co.course_id,
    co.semester_id,
    co.score,
    co.letter_grade,
    cr.date_registered,
    cr.date_dropped,
    cr.status,
    cs.staff_id,
    cs.lecture_days,
    cs.lecture_start_hour,
    cs.lecture_duration,
    cs.lab_days,
    cs.lab_start_hour,
    cs.lab_duration
FROM openlearn.course_registration cr
JOIN openlearn.course_outcome co
  ON cr.student_id = co.student_id AND
     cr.course_id = co.course_id AND
     cr.semester_id = co.semester_id
JOIN openlearn.course_schedule cs
  ON cr.course_id = cs.course_id AND
     cr.semester_id = cs.semester_id;

现在可以将学生和教师维度表连接到物化视图，这是事实表，用于创建一个星型模式模型。现在，当您查看完整的星型模式模型时，如 图 3-6 所示。

图 3-6. 完整的星型模式模型

一旦您摄取数据，您可以通过从表格中选择数据来测试结果。由于我们刚刚创建了一个从多个表中整合数据的物化视图，因此可以查询此物化视图以实现高效的查询性能。让我们使用一些查询进行测试（示例 3-4 和 3-5）。

示例 3-4. 查找获得每个等级的学生人数

SELECT semester_id, course_name, letter_grade, count(*)
FROM openlearn.mv_course_outcomes_fact
GROUP BY semester_id, course_name, letter_grade;

示例 3-5. 确定讲座持续时间与成绩之间是否存在相关性

SELECT course_name, letter_grade, sum(lecture_duration), count(*)
FROM openlearn.mv_course_outcomes_fact
GROUP BY course_name, letter_grade
ORDER BY course_name, letter_grade;

为了将学生在学习管理系统上的参与与结果相关联，您可以将 student_lms 表与 student_assessment 进行连接以获取洞察。接下来您将看到一个已物化的视图，mv_student_lmsactivites_and_score，创建于 示例 3-6。

示例 3-6. 学生活动 total_score mean_score

CREATE materialized view openlearn.mv_student_lmsactivites_and_score AS
SELECT student_info.id_student,
  student_info.code_module,
  student_info.code_presentation,
  gender,
  region,
  highest_education,
  imd_band,
  age_band,
  num_of_prev_atteempts,
  studied_credits,
  disability,
  final_result,
  st_lms_clicks.sum_of_clicks,
  scores.total_score,
  scores.mean_score
FROM openlearn.student_info
  LEFT JOIN
    (SELECT code_module,code_presentation,id_student,sum(sum_click) AS sum_of_clicks
    FROM openlearn.student_lms
      GROUP BY code_module,code_presentation,id_student) st_lms_clicks
    ON student_info.code_module=st_lms_clicks.code_module
    AND student_info.code_presentation=st_lms_clicks.code_presentation
    AND student_info.id_student=st_lms_clicks.id_student
    LEFT JOIN
      (SELECT id_student, sum(score) AS total_score, avg(score) AS mean_score
      FROM openlearn.student_assessment
      GROUP BY id_student)  scores
      ON student_info.id_student = scores.id_student;

有了这个物化视图，您可以获得许多关于学生表现的洞察，如 示例 3-7，分析学生在在线学习管理中的点击次数与结果或成绩的影响。在这里，您分析了学生使用在线学习管理与结果或成绩之间的点击次数。

示例 3-7. 点击次数与结果

SELECT code_module, final_result, sum(sum_of_clicks)
FROM  openlearn.mv_student_lmsactivites_and_score
GROUP BY code_module, final_result
ORDER BY code_module, final_result;

在 示例 3-8 中，您看到一个查询以分析按模块的百分比结果，以了解哪些模块学生得分较高或较低，因此学校可以积极设置计划，以增加学生参与度，从而获得更好的结果。

示例 3-8. 按模块的百分比结果

SELECT code_module,
  sum( CASE final_result WHEN 'Pass' THEN 1 ELSE 0 END ) AS PassCount ,
    sum( CASE final_result WHEN 'Distinction' THEN 1 ELSE 0 END ) AS DistCount,
  sum( CASE final_result WHEN 'Fail'  THEN 1 ELSE 0 END ) AS FailCount,
  sum( CASE final_result WHEN 'Withdraws' THEN 1 ELSE 0 END ) AS WithdrawnCount,
    count(*) AS TotalCount,
        round(cast(PassCount AS numeric(10,4))/TotalCount, 2)*100 AS pct_PassCount
FROM  openlearn.mv_student_lmsactivites_and_score
GROUP BY code_module
ORDER BY code_module;

您还可以直接查询表格以获得洞察。示例 3-9 展示了一条查询，以查找完成课程但未通过考试进行任何评估的学生人数。您可以尝试运行此查询。

示例 3-9. 完成课程进行任何评估但未通过考试的学生

select DISTINCT q.code_module, q.code_presentation, final_result
FROM openlearnm.student_info si
INNER JOIN
( SELECT * FROM openlearnm.student_assessment sa
    INNER JOIN openlearnm.assessments a
    ON sa.id_assessment = a.id_assessment) q
ON q.code_module = si.code_module
AND q.code_presentation = si.code_presentation
WHERE q.assessment_type = 'Exam';

从 Amazon S3 进行连续文件摄取

从 Amazon S3 存储桶连续摄取文件到 Amazon Redshift 表允许用户简化其转换管道。当您设置 COPY JOB 时，Amazon Redshift 检测到新的 Amazon S3 文件添加到您 COPY 命令指定的路径时。然后会自动触发 COPY 命令，并且系统会跟踪已加载的文件，并确定每个 COPY 命令批处理在一起的文件数量。您可以使用此功能自动化摄取过程，而无需创建外部数据摄取管道。有关连续摄取的更多详细信息，请参阅 在线文档。

COPY 作业的执行细节（如 示例 3-10）存储在系统表中，供您监视加载，并且您还可以使用此信息来审查历史作业执行和加载细节。sys_copy_job 系统表包含当前定义的每个 COPY JOB 的行。

示例 3-10. 创建 COPY 作业

<copy command>
JOB CREATE <job-name>
[auto on|off]

如 示例 3-11 所示，要查看由 COPY JOB 加载的文件列表，您可以运行以下示例查询，并替换 job_id：

示例 3-11. 查看 COPY 作业

SELECT job_id, job_name, data_source, copy_query,filename,status, curtime
FROM sys_copy_job copyjob
JOIN stl_load_commits loadcommit
ON copyjob.job_id = loadcommit.copy_job_id
WHERE job_id = <job_id>;

用于转换的 AWS Glue

AWS Glue 是一种原生的无服务器数据集成服务，通常用于使用 Python 或 Scala 语言进行数据转换并在数据处理引擎上运行。AWS Glue 使得从多个来源发现、准备、移动和集成数据变得更加简单，用于分析、ML 和应用开发。它提供多个数据集成引擎，包括 AWS Glue for Apache Spark、AWS Glue for Ray 和 AWS Glue for Python Shell。您可以根据工作负载的特征以及开发人员和分析师的偏好，选择适合您工作负载的引擎。Amazon Redshift 支持 Spark 集成，允许您将 Python 或 Scala 转换逻辑的执行推送到 Amazon Redshift 层，通过将 Spark 代码转换为 SQL 代码，而无需移动数据出数据仓库。

自 AWS Glue V4 起，现在有一个带有新 JDBC 驱动程序的 Amazon Redshift Spark 连接器，特色是与 AWS Glue ETL 作业一起使用。您可以使用它来构建 Apache Spark 应用程序，读取和写入 Amazon Redshift 中的数据，作为数据摄取和转换流水线的一部分。有了新的连接器和驱动程序，这些应用程序可以保持其数据的性能和事务一致性。

使用 AWS Glue (图 3-7)，您可以爬取 Amazon S3 数据源以创建目录，应用转换，并将数据摄入 Amazon Redshift 数据仓库。

图 3-7. 使用 AWS Glue 进行 ETL 集成

Amazon Redshift 与 Apache Spark 的集成使得在 Amazon Redshift 上使用 AWS Glue 构建和运行 Spark 应用程序变得更加简单。这种 Apache Spark 的集成功能增加了对排序、聚合、限制、连接和标量函数等操作的推送能力，因此只有相关数据从 Amazon Redshift 数据仓库移动到 AWS 中消费的 Spark 应用程序，以获得更好的性能。您可以参考此 博客获取更多信息。在 第四章，“数据转换策略” 中，您将学习如何使用 AWS Glue Studio 创建 ETL 转换，使用可视化界面。

使用 SQL 命令手动加载数据

使用 SQL 命令手动将数据加载到 Amazon Redshift 是一种可行的选择，但通常不建议用于大型数据集，因为这是耗时且容易出错的。但是，对于小型数据集或测试目的，它可能很有用。如果不能使用 COPY 命令，则可以使用诸如 INSERT 和 CREATE TABLE 等 SQL 命令来加载数据。建议使用多行插入或批量插入操作，而不是单个 INSERT 语句。

多行插入通过批量插入一系列插入来提高性能。以下是 示例 3-12 使用单个 INSERT 语句将两行插入到具有五列的表中。这仍然是一个小插入，简单地展示了多行插入的语法。

示例 3-12. 多行插入

INSERT INTO openlearn.course_outcome values
(1, 1,1, 95,'A'),
(1, 2,2, 96,'B');

当您需要将数据或数据子集从一张表移动到另一张表时，可以使用带有 SELECT 子句的批量插入操作，例如 示例 3-13，用于高性能数据插入。

示例 3-13. 使用数据创建表语句（CTAS）

CREATE TABLE course_outcome_stage AS (SELECT * FROM course_outcome);

如果您想要逐步添加到表中，请先创建表，然后按照条件插入记录，如 示例 3-14 所示。

示例 3-14. 使用数据创建表语句（CTAS）但不包含数据

CREATE TABLE course_outcome_stage AS (SELECT * FROM course_outcome WHERE 1<>1);

INSERT INTO course_outcome_stage
(SELECT * FROM course_outcome);

使用查询编辑器 V2

对于简单快速的数据加载到 Amazon Redshift，您可以使用查询编辑器 V2 的加载数据功能。您可以直接从桌面文件夹上传文件，或将数据文件上传到 Amazon S3 位置，然后在查询编辑器 V2 中选择加载数据选项，如 图 3-8 所示。

查询编辑器 V2 将在后台使用 COPY 命令从您指定的 Amazon S3 位置加载数据。在查询编辑器 V2 的加载数据向导中生成和使用的 COPY 命令支持所有 COPY 命令语法可用的参数，用于通过向导从 Amazon S3 复制。您可以设置数据转换参数以接受无效字符，设置日期和时间格式，截断数据，处理空白行、缺少列、尾随空格等异常情况。在屏幕的“高级设置”部分下选择“数据转换参数”选项，如 图 3-8 所示。此外，您还可以设置加载数据操作，例如分析用于压缩分析的行数、自动更新压缩编码选项、错误处理和统计更新选项。

图 3-8. 将 CSV 文件上传到 Amazon S3 并使用查询编辑器 V2 加载

当您使用 COPY 命令将数据输入空表时，Amazon Redshift 可以分析数据并为每列优化压缩类型。COPY 命令中的 COMPUPDATE 参数确定压缩的操作方式。

加载实时和准实时数据

实时数据指的是生成后立即处理和分析的数据。这种类型的数据对于诸如金融交易、运输和物流等时间敏感的应用至关重要。准实时数据与实时数据类似，但在处理和分析上稍有延迟，通常为几分钟或更少。

将实时和准实时数据加载到数据仓库或 BI 系统是一项具有挑战性的任务，需要高效的数据摄取、处理和存储能力。加载实时和准实时数据的过程涉及多个步骤，包括数据提取、数据转换和数据加载。

数据提取 是从各种来源（如传感器、日志文件和流数据平台）获取数据的过程。数据转换 是在加载到数据仓库或 BI 系统之前清理、验证和规范化数据的过程。数据加载 是将数据导入目标系统并使其可用于分析和报告的过程。

处理实时和准实时数据的几种方法包括批量加载、增量加载和流处理。批量加载 是定期以大块加载数据的过程。增量加载 是仅加载新数据或更改的过程。流处理 是连续处理和分析生成的数据的过程。

为了处理实时和准实时数据的高容量、高速率和多样性，广泛采用各种大数据技术，如 Apache Kafka、Apache Storm、Apache Spark 和 Apache Flink。

使用 AWS 数据库迁移服务进行近实时复制

AWS DMS 是一项完全托管的服务，使得将数据库迁移到 AWS 变得轻松。DMS 可以将您的数据迁移到和从多数广泛使用的商业和开源数据库，如 Oracle、MySQL、MariaDB、PostgreSQL（pgSQL）、Microsoft SQL Server 等。DMS 的常见用例之一是将数据迁移到 Amazon Redshift。

在开始迁移之前，重要的是计划和准备好迁移工作。这包括识别源数据库和目标数据库、需要迁移的数据量以及需要考虑的任何特定要求或约束条件。您还应在非生产环境中测试迁移过程，以确保一切按预期运行。

一旦您计划并准备好迁移工作，您可以创建 DMS 复制实例。复制实例是一个 DMS 资源，用于执行实际的迁移工作。它负责连接源数据库和目标数据库，并将数据从一处移动到另一处。

创建复制实例后，您可以创建迁移任务。迁移任务是 DMS 资源，定义了迁移的具体细节，如源数据库和目标数据库、要迁移的数据以及任何特定的设置或选项。

创建迁移任务时，您可以选择执行完整加载或变更数据捕获（CDC）迁移。完整加载迁移将所有数据从源数据库复制到目标数据库，而 CDC 迁移仅复制自上次迁移以来对源数据库所做的更改。

一旦创建了迁移任务，您可以开始迁移。DMS 将开始从源数据库向目标数据库移动数据。您可以使用 DMS 控制台或 AWS CLI 监视迁移进度。有关更多详细信息，请参阅使用 Amazon Redshift 数据仓库作为目标的文档。

迁移完成后，您可以执行任何必要的迁移后任务，例如创建索引或将数据加载到其他表中。您还应该测试目标数据库，确保所有数据已正确迁移，并且目标数据库按预期工作。

Amazon DMS 为将数据迁移到 Amazon Redshift 提供了一种简单且易用的方法。通过遵循本章中概述的步骤，您可以计划、准备和执行迁移，放心地知道您的数据将快速且安全地移动到您的新数据仓库中。

Amazon Aurora 与 Amazon Redshift 的零 ETL 集成

零 ETL 集成与 Amazon Redshift 结合，实现了一种架构模式，消除了为分析移动数据而需要复杂 ETL 作业的需要。从 Amazon Aurora 到 Amazon Redshift 的零 ETL 集成可以实现几乎实时的分析和 ML 处理，无论数据是否在同一账户或不同账户中。在将事务数据写入 Aurora 数据库几秒钟内，数据就可用于 Amazon Redshift，因此您无需构建和维护复杂的数据流水线来执行抽取和加载操作。

这种零 ETL 集成还使您能够在同一个新的或现有的 Amazon Redshift 数据仓库中分析来自多个 Amazon Aurora 数据库集群的数据，从而跨多个应用程序或分区获取洞见。通过接近实时访问事务数据，您可以利用 Amazon Redshift 的分析能力，如内置 ML、物化视图、数据共享和对多个数据存储和数据湖的联合访问，从事务数据和其他数据中获取洞见。此架构允许更快的洞察时间和降低成本，因为数据在分析之前不需要加载和转换。此外，它允许在数据仓库中接近实时地分析数据，而不会影响您的事务系统的工作负载。

要开始使用零 ETL，您首先需要确保 Amazon Aurora 数据库和 Amazon Redshift 数据仓库已正确配置。例如，对于 Aurora，您需要确保使用最新版本并启用了日志记录。同样，对于 Amazon Redshift，您需要确保使用最新版本并设置了必需的参数。有关所需配置参数的详细信息，请参阅在线文档。

接下来，您将设置所需的权限，以使您的 Amazon Aurora 数据库能够加载 Amazon Redshift 数据仓库的数据。要完成此操作，您需要确保您的用户具有redshift:CreateInboundIntegration权限。

转到 Amazon Redshift 控制台中的数据仓库资源策略，并使用“添加授权集成源”选项指定 Amazon Aurora 数据库的 Amazon 资源名称（ARN）（参见图 3-9）。

图 3-9. 编辑授权集成源

现在，您已经准备好创建零 ETL 集成。要完成此操作，您需要确保您的用户具有rds:CreateIntegration和rds:DescribeIntegration权限。此外，如果您需要删除集成，可能还需要rds:DeleteIntegration权限。

转到 Amazon 关系数据库服务（RDS）控制台，点击“零 ETL 集成”菜单项。接下来，点击“创建零 ETL 集成”（参见图 3-10）。在同一账户中创建集成时，选择预填充列表中的 Amazon Aurora 数据库和 Amazon Redshift 数据仓库，然后提交请求。您可以通过检查 Amazon RDS 控制台中的状态字段来监视零 ETL 集成的创建情况。当状态从“Creating”变为“Active”时，您的集成就准备就绪了。

图 3-10. 创建零 ETL 集成

最后，您可以开始查询加载到 Amazon Redshift 的数据。首先，从 Amazon RDS 控制台或通过在 Amazon Redshift 中执行以下 SQL 语句捕获您的零 ETL 集成的integration_id：

SELECT integration_id FROM svv_integration;

接下来，创建一个引用integration_id的本地数据库：

CREATE DATABASE <local_db_name> FROM INTEGRATION integration_id;

完成后，您可以浏览和查询从您的 Amazon Aurora 数据库同步到 Amazon Redshift 的所有对象，几乎实时显示。源 Amazon Aurora 数据库/模式将作为目标 Amazon Redshift 数据仓库数据库中的不同模式呈现。

要进一步处理数据，您可以考虑物化视图、脚本或存储过程，并可以使用 Amazon Redshift 调度程序或外部编排工具定期运行。

如果您的 Amazon Aurora 数据库与您的 Redshift 数据仓库位于不同的账户中，则需要执行额外的配置步骤，如设置授权主体和启用跨账户访问。有关如何设置跨账户集成的详细信息，请参阅在线文档。

使用 Amazon AppFlow

当今许多组织使用 SaaS 应用来运行其业务操作。一些 SaaS 应用，如 SAP 和 Infor，提供全面的 ERP 模块，而其他一些如 Salesforce、Google Analytics、Facebook Ads 和 ServiceNow 则提供最佳功能来运行业务的特定功能。为了向用户提供业务见解，您可能需要结合来自多个 SaaS 应用的数据，例如来自 Salesforce 的机会和来自 SAP 的实际销售。这些 SaaS 应用提供 API 或提取器，以从应用程序的事务级或应用级提取数据。

Amazon AppFlow 是一种完全托管的集成服务，帮助您安全地在多个点击之间传输数据，例如 Salesforce、SAP、Google Analytics、Facebook Ads 和 ServiceNow 等 SaaS 应用与 AWS 服务，如 Amazon S3 和 Amazon Redshift。

使用 Amazon AppFlow（图 3-11），您可以通过过滤器和验证执行转换和数据增强。它支持与 50 个连接器的数据连接，并可以双向移动数据到 AWS 服务如 Amazon S3 和 Amazon Redshift。您还可以创建自定义连接器，从任何 API 源读取数据流入 Amazon Redshift。要从任何源应用程序将数据传输到 Amazon Redshift，请创建一个 Amazon AppFlow 流，并选择 Amazon Redshift 作为数据目标。有关连接 Amazon Appflow 到您的 Amazon Redshift 数据仓库的详细步骤，请参阅此文档。

图 3-11. 使用 Amazon AppFlow 进行 ETL 集成

在开始数据摄入之前，重要的是规划和准备您的数据流。这包括识别要传输的源和目标应用程序和服务、要传输的数据以及需要考虑的任何特定要求或约束。您还应在非生产环境中测试数据流，以确保一切按预期工作。

一旦您规划并准备好数据流，您可以在 AppFlow 中创建新的流。为此，您需要指定源应用程序和服务、目标应用程序和服务以及要传输的数据。AppFlow 支持许多热门的应用程序和服务，包括 Salesforce、ServiceNow、Slack 等等。

接下来，您需要配置流的设置。这包括指定流的计划，例如数据传输的频率以及源应用程序和目标应用程序和服务的任何特定选项或设置。

完成流的设置后，您可以创建流。创建流时，AppFlow 将创建所有必要的资源，如连接器和触发器，以在源应用程序和目标应用程序和服务之间传输数据。

创建流程后，AppFlow 将自动开始从源应用程序和服务传输数据到目标位置。您可以使用 AppFlow 控制台或 AWS CLI 监视流程的进度。

当数据传输完成后，数据将被摄入到您的亚马逊 Redshift 数据仓库中，您可以使用标准 SQL 对其进行查询和分析。然后，您可以使用现有的 BI 工具基于数据创建报告和可视化。

亚马逊 AppFlow 提供了一种简单易行的方法将数据摄入到亚马逊 Redshift 中。通过按照本章节中概述的步骤进行规划、准备和执行数据摄取，您可以放心地知道您的数据将快速安全地传输到数据仓库中。AppFlow 使您能够自动化不同应用程序和服务之间的数据流程，并提高其效率。要了解使用亚马逊 AppFlow 从 Salesforce 拉取数据到亚马逊 Redshift 的实际用例，请参阅此博客。

流式摄取

流式摄取是将数据连续加载到数据仓库或 BI 系统中的过程，实时或准实时进行。这允许对数据进行实时分析和报告，对于金融交易、交通运输和物流等时间敏感应用程序至关重要。流式摄取通常使用流式数据平台（如 Apache Kafka 或亚马逊 Kinesis）来收集和管理数据流。然后处理并将数据加载到目标数据仓库或 BI 系统中。

使用流式数据摄取有几个好处，包括处理高速和大容量数据的能力，进行实时分析和报告，并实时检测和响应事件。然而，流式数据摄取也带来了一些挑战，如需要高效的数据处理和存储能力、强大的数据集成和管理工具，以及专业的技能和专业知识。

亚马逊 Redshift 流式摄取的用例主要围绕持续生成的数据（流式数据）进行工作，需要在其生成后的短时间内（延迟）进行处理。数据来源可以多种多样，从物联网设备到系统遥测、公用服务使用、设备地理位置等。流式摄取可以有多个用例，包括以下内容：

实时监控设备以获取警报

考虑一组装有传感器的车辆队列，这些传感器收集各种指标数据，如速度、温度和燃料消耗。需要实时分析传感器数据，以提供有关任何异常值的警报，以便能够及时解决问题。

网站上的实时广告投放

分析来自多个平台（如 Twitter 和 Facebook）的社交媒体数据，用于实时广告投放或防止虚假信息或淫秽内容。

改善游戏体验

您可以通过分析游戏玩家的实时数据，专注于游戏内转化率、玩家留存率和优化游戏体验。

流式 POS 数据的实时零售分析

您可以实时访问和可视化所有全球销售点（POS）零售销售交易数据，进行实时分析、报告和可视化。

Amazon Redshift 支持使用流式服务加载实时数据。您可以独立使用 Amazon Kinesis 数据 Firehose 或 Kinesis 数据流，或使用与 Amazon Redshift 的本地集成：

• 第一选项是使用 Kinesis Firehose 或 Kinesis 数据流。这涉及将数据流连接到 Amazon Kinesis 数据 Firehose，并等待 Kinesis 数据 Firehose 将数据暂存在 Amazon S3 中，使用各种大小的批处理和不同长度的缓冲间隔。之后，Kinesis 数据 Firehose 启动COPY命令，从 Amazon S3 加载数据。以前，这通常涉及几分钟的延迟，并且需要在从数据流加载的数据之上构建数据管道。现在，您可以直接从数据流摄入数据。

• 第二个选项是与 Amazon Kinesis 数据流或 Amazon 托管的 Apache Kafka（MSK）数据流的本地集成。通过与 Amazon 流引擎的本地集成，Amazon Redshift 流摄入每秒摄入数百 MB 的数据，因此您可以几乎实时地查询数据。使用 Amazon Redshift 流摄入，您可以连接到多个 Amazon Kinesis 数据流或 Amazon MSK 数据流，并直接将数据拉入 Amazon Redshift，无需将数据暂存在 Amazon S3 中。定义方案或选择使用SUPER数据类型摄入半结构化数据；您还可以使用 SQL 设置和管理 ELT 管道。

本地的 Amazon Redshift 流式摄入功能允许您直接连接到 Kinesis 数据流，无需通过将数据暂存到 Amazon S3 并加载到数据仓库中的延迟和复杂性。您现在可以使用 SQL 连接并访问数据流，并通过直接在数据流之上创建物化视图简化数据流水线。物化视图还可以包括作为 ELT 管道的一部分的 SQL 转换。

定义物化视图后，您可以刷新它们以查询最新的流数据。这意味着您可以使用 SQL 对流数据进行下游处理和转换，而不会产生额外的费用，并可以使用现有的 BI 和分析工具进行实时分析。

Amazon Redshift 流式摄入通过充当流消费者的方式工作。材料化视图是从流中消费的数据的着陆区域。当材料化视图被刷新时，Amazon Redshift 计算节点会将每个数据分片分配给计算片段。每个片段从分配的分片中消费数据，直到材料化视图与流达到一致。材料化视图的第一次刷新从流的TRIM_HORIZON获取数据。后续刷新从前一次刷新的SEQUENCE_NUMBER开始读取数据，直到与流数据达到一致。图 3-12 说明了这个工作流程。

图 3-12. 流摄入工作流

开始使用流摄入的步骤

第一步是设置 Kinesis Data Stream 作为流摄入管道的源。您可以使用 Kinesis Streams 数据生成器设置测试数据，如博客中所述“使用新的 Amazon Kinesis 数据生成器测试您的流数据解决方案”。

设置数据流后，您可以在 Amazon Redshift 中使用CREATE EXTERNAL SCHEMA定义模式，以引用 Kinesis Data Streams 资源。

CREATE EXTERNAL SCHEMA kds
FROM KINESIS
IAM_ROLE { default | 'iam-role-arn' };

创建一个 IAM 角色，如示例 3-15，其中信任策略允许您的 Amazon Redshift 数据仓库扮演该角色。

示例 3-15. 授予访问流的 IAM 策略

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadStream",
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStreamSummary",
                "kinesis:GetShardIterator",
                "kinesis:GetRecords",
                "kinesis:DescribeStream"
            ],
            "Resource": "arn:aws:kinesis:*:0123456789:stream/*"
        },
        {
            "Sid": "ListStream",
            "Effect": "Allow",
            "Action": [
                "kinesis:ListStreams",
                "kinesis:ListShards"
            ],
            "Resource": "*"
        }
    ]
}

要访问流中的数据，您可以创建一个带有流选择的材料化视图。当您查询材料化视图时，返回的记录是流的某一时刻视图：

CREATE MATERIALIZED VIEW my_view AS
SELECT approximate_arrival_timestamp,
JSON_PARSE(kinesis_data) AS Data
FROM schema_one.my_stream_name
WHERE CAN_JSON_PARSE(kinesis_data)
AUTO REFRESH YES;

接下来，您刷新视图以从流到材料化视图进行初始数据加载：

REFRESH MATERIALIZED VIEW my_view;

现在您可以使用标准 SQL 语句从材料化视图查询数据：

SELECT * FROM my_view;

您可以将流记录存储在半结构化的 SUPER 格式中，或者定义一个模式，将数据转换为 Amazon Redshift 数据类型。

有关从 Amazon Kinesis Data Streams 设置流摄入的详细步骤，请参阅“开始使用 Amazon Kinesis Data Streams 进行流摄入”。

重要考虑因素和最佳实践

以下是在设置流摄入环境时性能和计费的重要考虑因素和最佳实践。

自动刷新查询材料化视图或视图被视为任何其他用户工作负载。自动刷新会在数据流到达时加载数据。

自动刷新可以明确地打开用于流入站点创建的物化视图。要做到这一点，请在物化视图定义中指定 AUTO REFRESH。手动刷新是默认设置。要为现有的用于流入站点的物化视图指定自动刷新，可以运行 ALTER MATERIALIZED VIEW 来打开它。有关更多信息，请参阅 CREATE MATERIALIZED VIEW 或 ALTER MATERIALIZED VIEW。

对于亚马逊 Redshift 无服务器，设置和配置说明与在预置集群上设置流入站点相同。非常重要的是，要使用适当级别的 RPUs 大小亚马逊 Redshift 无服务器，以支持带有自动刷新和其他工作负载的流入站点。

在配置流入站点时，如果 Amazon MSK 的机架感知已启用，则 Amazon Redshift 尝试连接到同一可用区（AZ）中的 Amazon MSK 集群。如果您所有的节点都与 Amazon Redshift 数据仓库的不同 AZ 中，您可能会产生跨 AZ 数据传输成本。为了避免这种情况，请至少在 Amazon Redshift 数据仓库相同 AZ 中保留一个 Amazon MSK broker 集群节点。

创建物化视图后，其初始刷新从 Kinesis 流的 TRIM_HORIZON 或 Amazon MSK 主题的偏移 0 开始。

支持的数据格式仅限于可以从 VARBYTE 转换的格式。有关更多信息，请参阅 VARBYTE 类型 和 VARBYTE 运算符。

可以将流入的数据流落入多个物化视图中。例如，一种用例是您接收包含体育数据的流，但将每种体育的数据组织到单独的物化视图中。然而，当您将数据流入并刷新多个物化视图时，可能会导致更高的出站成本，以及对您的流媒体提供商的带宽、吞吐量和性能限制。此外，请考虑读取更多物化视图的高资源使用如何影响其他工作负载。因此，我们建议您将每个流的数据落入单个物化视图中。有关数据流定价的更多信息，请参阅 Kinesis 数据流定价 和 Amazon MSK 定价。

优化您的数据结构

传统上，数据库建立在对称多处理（SMP）架构上，多个 CPU 访问共享内存和磁盘。这种紧密耦合的多处理器系统无法线性扩展以满足数据增长和查询执行吞吐量要求。

这些挑战通过 MPP 架构得以克服。MPP 架构有两种类型：

• 共享磁盘架构：在此，CPU 和内存是并行处理的，但磁盘是共享的。

• 共享无事务架构：在此，CPU、内存以及磁盘都是并行处理的。

正如本书前面提到的，Amazon Redshift 是一种 MPP 共享无共享体系结构，通过在每个节点上使用节点附加的内存和 CPU 来处理数据，实现线性可伸缩性。这种架构通过在每个节点上处理数据，实现了大规模，因为没有单个执行器瓶颈来减慢系统，并且添加或删除节点提供了线性可伸缩性。在单个对象或表的物理存储数据中，意味着 MPP 系统具有分布式或复制表，分布式风格在查询性能中起着关键作用。迈克尔·斯通布雷克（Michael Stonebraker）在他的论文中探讨了共享无共享的情况。

当您创建数据库对象时，某些关键的表设计决策会影响整体查询性能。这些设计选择还会对存储需求产生重大影响，进而可能影响查询性能。关键目标是减少 I/O 操作的数量并最小化处理查询所需的内存。

Amazon Redshift 通过“自动表优化和自动化”的结合为您自动化了许多决策，但是在您希望优化您的环境并设置自己的“分布式风格”、“排序键”或“压缩编码”时，可能需要微调。

自动表优化和自动化

Amazon Redshift 在创建带有AUTO选项的表时使用自动表优化（ATO）来选择正确的分布式风格、排序键和编码。因此，利用自动功能并使用DISTSTYLE AUTO、SORTKEY AUTO和ENCODING AUTO创建表是一个良好的实践。当使用AUTO选项创建表时，Amazon Redshift 最初会根据主键和数据类型等信息创建具有最佳首次查询性能的表。此外，Amazon Redshift 分析数据量和查询使用模式，随着时间的推移演变分布策略和排序键以优化性能。最后，Amazon Redshift 将在您的表上执行减少碎片和确保统计数据最新的表维护活动。我们在第五章，“扩展和性能优化”中进一步讨论了 ATO 主题。

分布式风格

由于亚马逊 Redshift 是基于计算节点的 MPP 数据仓库，因此数据分布的方式对于确保在给定工作负载下充分利用资源至关重要。当执行查询时，查询优化器可能需要将行重新分发到计算节点以执行任何连接操作。在选择表分布样式时的目标是通过将数据定位在查询运行之前的位置来最小化重新分发步骤的影响，以便连接两个或多个表。有四种数据分布策略：AUTO、EVEN、ALL和KEY（见图 3-13）。

图 3-13. 计算节点切片之间的数据分布

AUTO 分布

正如前面提到的，使用 AUTO 关键字意味着亚马逊 Redshift 利用其内置的 AI 和 ML 能力，并根据数据量和查询模式自动执行最佳数据分布。这是许多角色的首选分布策略，特别是那些可能对架构不熟悉但仍需要分析数据集以获取业务洞见的人。

EVEN 分布

在这种分布策略中，数据以轮询方式存储到亚马逊 Redshift 数据仓库的每个切片中，因此数据在切片和节点之间的数据量分布非常均匀，几乎没有倾斜或不平衡。EVEN 分布最适合大型事实表，通常不参与与其他维度表的连接。另一个很好的候选对象是已经执行了所有连接并捕获了结果的物化视图，查询主要只是过滤行。

ALL 分布

在这种分布策略中，整个表的完整副本存储在亚马逊 Redshift 数据仓库每个计算节点的第一个切片上。这最适合维度表，以便在不需要跨节点移动数据的情况下与事实表进行连接。正如您所见，这有助于更快地执行查询，但增加了存储成本。

KEY 分布

在这种分布策略中，事实表基于指定列值生成的哈希进行分布，使得所有产生相同哈希值的值存储在亚马逊 Redshift 数据仓库的同一切片上。当在相同键分布列上连接两个表时应用此策略。这两个表可以是两个事实表，一个事实表和一个维度表，或一个暂存表和一个目标表。

KEY分发允许在联接执行时共同位于同一片的事实表和对应的维度表行。为确保片之间的倾斜最小化，需要使用高基数列作为关键分发。还要注意，Amazon Redshift 仅允许将一列定义为分发键，因此如果您的查询进行多列联接，则应在数据加载过程中通过串联这些单独的列值来创建新列。

您会注意到，在所有三种分发样式中，重点是在执行查询时减少数据移动。这允许 Amazon Redshift 通过将总工作量按节点和片数分割，每个片并行运行，以实现最大吞吐量。

假设您有一个销售数据仓库，fact_sales是最大的事实表，拥有数十亿行，经常与dim_customer（拥有数千万或数亿行）进行联接。然后您还有dim_calendar、dim_product和dim_region，这些表的记录数较少。您还为sales_annual_mv、sales_qtrly_mv和sales_monthly_mv创建了物化视图，用于仪表板和报告的预聚合度量。在分析此数据仓库中的数据后，以下是分发的一些建议：

• fact_sales和dim_customer适合使用KEY分发，但不适合在calendar_key或product_key上使用。

• 其他维度适合使用ALL分发。

• 物化视图适合使用EVEN分发。

由于 Amazon Redshift 只能选择一个列作为分发键，如果您从具有多列主键/外键的源导入数据，可能会看到表在多个列上进行联接。在这种情况下，考虑在您的表中创建一个新列，该列是联接列的串联，并将该新列用作分发键。

排序键

除了如何在计算节点片之间分发数据之外，下一个方面是数据在磁盘上的物理排序方式。Amazon Redshift 没有索引，但排序键和区域映射提供了类似的功能。数据按照排序键的顺序存储在磁盘上，并且查询优化器在确定最佳查询计划时使用排序顺序。由于可以跳过时间范围之外的整个块，因此使用作为数据过滤谓词的列作为排序键列是高效的。

区域映射是每个表中每个列的每个 1 MB 存储块的高和低值。如果列已经排序，则获得非重叠的区域映射。这些区域映射通过允许 Amazon Redshift 仅针对查询需要访问的那些块来进一步减少 I/O。设置排序键时，请参考Create Table命令中的表属性。

图 3-14 说明了销售表的块如何存储在您的 Amazon Redshift 数据仓库中。它还显示了销售 _dt 列的第一个 1 MB 块的区域映射，其中最小值为 20010523，最大值为 20010527。查询处理器首先扫描此头记录，以确定谓词子句或过滤器中的数据是否可能存在于该块中。如果谓词值超出区域映射中的范围，则 Amazon Redshift 将跳过整个块并移动到下一个块。这最小化了 I/O 并提高了查询的性能。

图 3-14. 区域映射

另一个例子是，考虑对course_outcomes_fact表的查询。您可以在特定日期上过滤该表，比如Jun-09-2012：

SELECT count(*)
FROM course_outcomes_fact
WHERE date_registered = '06-09-2017';

如图 3-15 所示，无论表是排序还是未排序，查询处理器都能跳过块。对于未排序表，处理器跳过一个块并根据区域映射中的最小/最大值扫描四个块中的三个。但是对于排序表，处理器只需扫描四个块中的一个。

图 3-15. 排序键和区域映射

如前所述，我们建议您使用SORTKEY AUTO创建表，以便让 Amazon Redshift ATO 选择最佳排序键。对于SORTKEY AUTO，Amazon Redshift 将分析您表的查询模式并应用最常用于查询谓词中的排序键。通过使用自动化来调整表设计，您可以更轻松地开始并快速获得最快的性能，而无需投入时间手动调整和实施表优化。

在选择自己的排序键时，请参考此查询来识别谓词列。建议在排序键中不超过五列，并且建议不对排序键的第一列应用任何压缩，以便能够快速有效地过滤数据块，因为这会减少解压缩的开销。在使用前导列而不是仅在尾随列上进行过滤时，复合排序键非常有效。如果发现用户查询中有不同的前导排序键列同样受欢迎，则利用 Amazon Redshift 材料化视图（MV）。MV 提供自动查询重写，查询优化器将选择适当的 MV 而不是基础表。

如果您频繁执行范围过滤或等值过滤于一列，请将该列指定为排序键。在分析使用情况下，基于日期和时间组件查询数据是常见的，建议将日期或时间戳列作为排序键的主导列创建表格是个不错的主意。

如果您经常连接表格，且通常不会在连接表格上进行过滤，则可以将连接列同时指定为排序键和分布键。这样做可以使查询优化器选择排序合并连接而不是较慢的哈希连接。因为数据已经在连接键上排序，查询优化器可以绕过排序阶段的排序合并连接。

压缩编码

Amazon Redshift 应用列级压缩，也称为编码，以实现比原始数据三到四倍的压缩。这也减少了访问数据时的 I/O 需求。

如前所述，在您的 Amazon Redshift 表上管理编码的最简单方法是利用ENCODING AUTO选项在您的create table语句中。启用后，编码将由列的数据类型和加载数据的启发式确定。

另一种设置表格编码的选择是首次使用COPY命令将数据加载到空表中时。默认情况下，Amazon Redshift 将通过对传入数据进行抽样或使用列的数据类型选择适当的压缩类型。可以在COPY命令中使用COMPUPDATE参数进行控制。使用PRESET选项时，压缩类型将基于数据类型确定，ON选项将对数据集进行抽样，OFF选项将不更改压缩类型。如果您一遍又一遍地重新加载同一表格，您无需每次分析压缩。PRESET快速且在大多数情况下运行良好。这些选项使您能够控制何时以及如何确定压缩，并且可以确保表格的属性在性能满意时不会更改。

在数据概况发生变化的情况下，分析表格中的压缩设置是否最优是个好主意。您可以使用ANALYZE COMPRESSION命令来执行此操作（见示例 3-16）。请注意，该命令可在整个表格或表格中的特定列集上执行。

示例 3-16. ANALYZE COMPRESSION命令

ANALYZE COMPRESSION
[ [ table_name ]
[ ( column_name [, ...] ) ] ]
[COMPROWS numrows]
[Script, SQL]

有几个最佳实践，如果实施，可以确保最大的压缩：

• 如果不使用AUTO，请为您的数据类型使用适当的编码。例如，对于具有高重复度的列，请使用游程编码（RLE），对于行之间具有高相似性的列，请使用增量编码。

• 使用COPY命令加载数据，因为它会自动应用编码参数。

• 使用VACUUM命令通过减少碎片来增加压缩。

• 监控表格大小及其使用的磁盘空间，以寻找应用额外压缩的机会。

• 避免对小维度表进行编码，因为每列的 1 MB 块可以容纳大量数据，在这些情况下，压缩不会带来 I/O 效益。

• 对频繁访问的列使用压缩。

摘要

本章讨论了数据湖优先方法与数据仓库优先方法之间的关键差异，以及可以考虑使用哪种方法的场景。此外，您还创建了样本数据模型和各种类型的转换工具和策略。

下一章将更深入地探讨在 Amazon Redshift 中针对数据库内转换（ELT）和外部转换（ETL）的数据，以及如何在数据仓库中未加载数据的情况下查询和转换所有数据。我们还将讨论编排数据加载的策略。

¹ Kuzilek J., Hlosta M., 和 Zdrahal Z. 开放大学学习分析数据集，Sci. Data 4:170171 (2017)。

第四章：数据转换策略

最近，Forbes 发布的一份报告描述了一些股票经纪商和交易公司能够比竞争对手更快地访问和分析数据。这使他们能够“在众人之前微秒级地以最佳价格执行交易。在时间上稍微占优，但在速度洞察方面却取得了巨大的竞争优势。”

在考虑分析解决方案时，洞察力速度很重要，组织能够快速响应其数据变化，将更具竞争力。在许多情况下，为了获取所需的洞察力，数据需要进行转换。正如在第三章，“设置数据模型和数据摄入”中简要讨论的，您可以使用 ETL 方法，从源数据中读取数据，通过外部应用程序进行转换处理，并加载结果；或者您可以使用 ELT 方法，使用刚刚加载的数据，并使用 Amazon Redshift 计算的能力在原地转换数据。

在本章中，我们将从“比较 ELT 和 ETL 策略”开始，帮助您决定在构建数据仓库时使用哪种数据加载策略。我们还将深入探讨一些为分析使用案例而构建的 Redshift 的独特功能，并支持“数据库内转换”，以及如何利用内置的“调度和编排”功能来运行您的数据管道。然后，我们将介绍亚马逊 Redshift 如何通过允许您即使未加载到 Redshift 中也可以“访问所有数据”来进一步采用 ELT 策略。最后，我们将讨论在何时使用“外部转换”策略以及如何使用 AWS Glue Studio 构建您的 ETL 管道。

比较 ELT 和 ETL 策略

无论是 ELT 还是 ETL 策略，都可以支持数据管理平台的共同目标，这些目标通常涉及为加载到报告数据模型中的数据进行清洗、转换和聚合。这些都是资源密集型的操作，两种策略之间的主要区别在于处理发生的位置：在您的 ETL 服务器计算中或在您的数据仓库平台计算中。ETL 过程涉及从多个来源读取数据，并使用 ETL 引擎的函数和功能对数据进行转换。相反，ELT 过程还涉及从各种来源提取数据，但首先将其加载到数据仓库中。在加载数据之后，使用熟悉的 SQL 语义执行数据转换步骤。在选择两者之间时需要考虑的一些因素包括：

性能和可扩展性

ETL 过程依赖于 ETL 服务器的资源，并要求平台所有者正确管理和调整环境。像 Spark 这样的计算平台可以用于并行化数据转换，AWS Glue 提供了管理 ETL 管道的无服务器选项。ELT 处理是使用数据仓库的计算资源执行的。在 Amazon Redshift 的情况下，使用 MPP 架构的强大性能来执行转换。在历史上，首选在外部进行数据转换，因为处理被卸载到独立计算上。然而，现代数据仓库平台，包括 Amazon Redshift，可以动态扩展并支持混合工作负载，使 ELT 策略更具吸引力。此外，由于数据仓库平台设计用于使用本地数据库函数处理和转换大量数据，ELT 作业往往表现更佳。最后，ELT 策略不受网络瓶颈的限制，而 ETL 需要在处理中移动数据。

灵活性

虽然数据平台中的任何转换代码都应遵循开发生命周期，使用 ETL 策略时，该代码通常由具有外部应用程序专业技能的团队管理。相比之下，ELT 策略中，所有原始数据都可以在数据管理平台中查询和转换。分析师可以使用熟悉的 SQL 函数编写代码，利用他们已有的技能。赋予分析师权力可以缩短开发生命周期，因为他们可以原型化代码并验证业务逻辑。数据平台的所有者将负责优化和调度代码。

元数据管理和编排

数据策略的一个重要考虑因素是如何管理作业元数据和编排。利用 ELT 策略意味着数据平台所有者需要跟踪作业、它们的依赖关系和加载计划。ETL 工具通常具有捕获和组织源、目标和作业特性以及数据血统的功能。它们还可以编排作业并在多个数据平台之间构建依赖关系。

最终，选择 ETL 和 ELT 之间的方式将取决于分析工作负载的具体需求。两种策略各有优势和劣势，使用哪种策略取决于数据源的特性、转换需求以及项目的性能和可扩展性需求。为了减轻每种策略的挑战，许多用户采取混合方法。您可以利用 ETL 工具的元数据管理和编排功能，以及构建将 ETL 代码转换为 SQL 语句的作业来利用 ELT 处理的性能和可扩展性。在“外部转换”中，我们将更详细地讨论这种可能性。

在数据库转换中

面对当今数据的多样性和速度，设计数据平台的挑战在于使其既可扩展又灵活。Amazon Redshift 持续创新并提供功能，以在一个地方处理所有数据，具有其数据库内转换（ELT）能力。作为符合 ANSI SQL 的关系数据库，Amazon Redshift 支持 SQL 命令，使其成为大多数数据库开发人员熟悉的开发环境。Amazon Redshift 还支持现代数据平台中的高级功能，如 窗口函数，HyperLogLog 函数，以及 递归 CTE（通用表达式） 等。除了您熟悉的这些功能外，Amazon Redshift 还支持用于分析处理的独特能力。例如，Amazon Redshift 支持就地查询 “半结构化数据”，为分析人员提供了一种高效访问此类数据的方式，而无需等待其加载到表和列中。此外，如果需要扩展 Amazon Redshift 的功能，您可以利用可以在数据库内运行或调用外部服务的 “用户定义函数”。最后，“存储过程” 允许您打包转换逻辑，可以根据输入参数返回结果集，甚至执行数据加载和管理操作，如加载事实、维度或聚合表。

半结构化数据

半结构化数据属于不符合关系数据库中预期的严格模式的数据类别。半结构化格式在网络日志、传感器数据或 API 消息中常见且通常受欢迎，因为这些应用程序经常需要发送带有嵌套关系的数据，而不是进行多次往返，一次性发送数据更为高效。半结构化数据包含复杂值，如数组和嵌套结构，这些与序列化格式（例如 JSON）相关联。虽然可以使用第三方工具在数据库之外转换数据，但这将需要工程资源来构建和维护该代码，并且可能性能不佳。无论您是访问 “外部亚马逊 S3 数据” 还是本地加载的数据，Amazon Redshift 利用 PartiQL 语法分析和转换半结构化数据。为了以其原生形式存储此数据，特别推出了一个名为 SUPER 的特殊数据类型。然而，当从 Amazon S3 访问时，将使用 struct 或 array 数据类型进行分类。

在以下示例中，我们引用了一个已经存储在 Amazon S3 环境中的文件。您可以通过创建外部模式并将存在于此 Amazon S3 前缀中的任何文件映射到该表定义，对此文件进行目录化并使其在 Amazon Redshift 中可访问。

第一个查询（示例 4-1）查找每个事件的总销售收入。

示例 4-1. 从 JSON 数据创建外部表

CREATE external SCHEMA IF NOT EXISTS nested_json
FROM data catalog DATABASE 'nested_json'
IAM_ROLE default
CREATE EXTERNAL DATABASE IF NOT EXISTS;

DROP TABLE IF EXISTS nested_json.nested_json;
CREATE EXTERNAL TABLE nested_json.nested_json (
    c_name varchar,
    c_address varchar,
    c_nationkey int,
    c_phone varchar,
    c_acctbal float,
    c_mktsegment varchar,
    c_comment varchar,
    orders struct<"order":array<struct<
      o_orderstatus:varchar,
      o_totalprice:float,
      o_orderdate:varchar,
      o_order_priority:varchar,
      o_clerk:varchar,
      o_ship_priority:int,
      o_comment:varchar
      >>> )
row format serde 'org.openx.data.jsonserde.JsonSerDe'
with serdeproperties ('paths'='c_name,c_address,c_nationkey,c_phone,
 c_acctbal,c_mktsegment,c_comment,Orders')
stored as inputformat 'org.apache.hadoop.mapred.TextInputFormat'
outputformat 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
location 's3://redshift-immersionday-labs/data/nested-json/';

此数据文件位于 us-west-2 地区，此示例仅在您的 Amazon Redshift 数据仓库也位于该地区时有效。此外，我们引用了 default IAM 角色。确保修改角色以允许读取此 Amazon S3 位置的权限，并且具有管理 AWS Glue 数据目录的访问权限。

现在表已经可用，可以对其进行查询，您可以在不进行任何特殊处理的情况下访问顶级属性（示例 4-2）。

示例 4-2. 顶级属性

SELECT cust.c_name,
  cust.c_nationkey,
  cust.c_address
FROM nested_json.nested_json cust
WHERE cust.c_nationkey = '-2015'
  AND cust.c_address like '%E12';

使用 PartiQL 语法，您可以访问嵌套的 struct 数据。在 示例 4-3 中，我们将 orders 字段中的数据进行非嵌套化，并展示与客户记录关联的多个订单。

示例 4-3. 非嵌套属性（外部）

SELECT cust.c_name,
   cust_order.o_orderstatus,
   cust_order.o_totalprice,
   cust_order.o_orderdate::date,
   cust_order.o_order_priority,
   cust_order.o_clerk,
   cust_order.o_ship_priority,
   cust_order.o_comment
FROM nested_json.nested_json cust,
     cust.orders.order cust_order
WHERE cust.c_nationkey = '-2015'
  AND cust.c_address like '%E12';

除了访问 S3 中的数据外，此半结构化数据还可以使用 SUPER 数据类型加载到您的 Amazon Redshift 表中。在 示例 4-4 中，同一文件加载到物理表中。在加载到 Amazon Redshift 时，与映射到 SUPER 数据类型的 orders 列的架构相关的信息不需要。这简化了加载和元数据管理过程，并在元数据更改时提供了灵活性。

示例 4-4. 从 JSON 数据创建本地表

DROP TABLE IF EXISTS nested_json_local;
CREATE TABLE nested_json_local (
    c_name varchar,
    c_address varchar,
    c_nationkey int,
    c_phone varchar,
    c_acctbal float,
    c_mktsegment varchar,
    c_comment varchar,
    orders SUPER);

COPY nested_json_local
from 's3://redshift-immersionday-labs/data/nested-json/'
IAM_ROLE default REGION 'us-west-2'
JSON 'auto ignorecase';

我们引用了 default IAM 角色。确保修改角色以授予从此 Amazon S3 位置读取的权限。

现在表已经可用，可以对其进行查询。使用相同的 PartiQL 语法，您可以访问订单详情（示例 4-5）。

示例 4-5. 非嵌套属性（本地）

SET enable_case_sensitive_identifier TO true;
SELECT cust.c_name,
   cust_order.o_orderstatus,
   cust_order.o_totalprice,
   cust_order.o_orderdate::date,
   cust_order.o_order_priority,
   cust_order.o_clerk,
   cust_order.o_ship_priority,
   cust_order.o_comment
FROM nested_json_local cust,
     cust.orders."Order" cust_order
WHERE cust.c_nationkey = '-2015'
  AND cust.c_address like '%E12';

enable_case_sensitive_identifier 是在查询 SUPER 数据时的一个重要参数，如果您的输入具有混合大小写标识符。有关更多信息，请参阅在线文档。

有关查询半结构化数据的更多详细信息和示例，请参阅在线文档。

用户定义函数

如果没有适合您特定转换需求的内置函数，Amazon Redshift 提供了几种选项来扩展平台功能。Amazon Redshift 允许您创建三种类型的 标量用户定义函数（UDF）：SQL、Python 和 Lambda。有关创建每种类型函数的详细文档，请参阅在线文档。

标量函数每次调用将返回一个确切的值。在大多数情况下，您可以将其视为每行返回一个值。

SQL UDF 利用现有的 SQL 语法。它可以用于确保应用一致的逻辑，并简化每个用户需要单独编写的代码量。在 示例 4-6 中，来自 Amazon Redshift UDFs GitHub 仓库 的示例中，您将看到一个 SQL 函数，它接受两个输入参数；第一个 varchar 字段是要掩码的数据，第二个字段是数据的分类。结果是基于数据分类的不同掩码策略。

示例 4-6. SQL UDF 定义

CREATE OR REPLACE function f_mask_varchar (varchar, varchar)
  returns varchar
immutable
AS $$
  SELECT case $2
    WHEN 'ssn' then
      substring($1, 1, 7)||'xxxx'
    WHEN 'email' then
      substring(SPLIT_PART($1, '@', 1), 1, 3) + 'xxxx@' + SPLIT_PART($1, '@', 2)
    ELSE substring($1, 1, 3)||'xxxxx' end
$$ language sql;

用户可以在 SELECT 语句中引用 SQL UDF。在这种情况下，您可能会编写 示例 4-7 中所示的 SELECT 语句。

示例 4-7. SQL UDF 访问

SELECT
 f_mask_varchar (name, NULL) mask_name, name,
 f_mask_varchar (email, 'email') mask_email, email,
 f_mask_varchar (ssn, 'ssn') mask_ssn, ssn
FROM Customer;

示例 4-7 中的 SELECT 语句的结果如下：

mask_name	name	mask_email	email	mask_ssn	ssn
Janxxxxx	Jane Doe	jdoxxxx@org.com	jdoe@org.com	123-45-xxxx	123-45-6789

Python UDF 允许用户利用 Python 代码转换其数据。除了核心 Python 库外，用户还可以导入自己的库，以扩展在 Amazon Redshift 中可用的功能。在 示例 4-8 中，来自 Amazon Redshift UDFs GitHub 仓库 的示例中，您将看到一个利用外部库 ua_parser 的 Python 函数，该函数可以将用户代理字符串解析为 JSON 对象并返回客户端操作系统系列。

示例 4-8. Python UDF 定义

CREATE OR REPLACE FUNCTION f_ua_parser_family (ua VARCHAR)
RETURNS VARCHAR IMMUTABLE AS $$
  FROM ua_parser import user_agent_parser
  RETURN user_agent_parser.ParseUserAgent(ua)['family']
$$ LANGUAGE plpythonu;

类似于 SQL UDF，用户可以在 SELECT 语句中引用 Python UDF。在本例中，您可能会编写 示例 4-9 中所示的 SELECT 语句。

示例 4-9. Python UDF 访问

SELECT f_ua_parser_family (agent) family, agent FROM weblog;

示例 4-9 中的 SELECT 语句的结果如下：

family	agent
Chrome	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.104 Safari/537.36

最后，Lambda UDF 允许用户与 Amazon Redshift 之外的外部组件进行交互和集成。您可以使用任何支持的编程语言编写 Lambda UDF，例如 Java、Go、PowerShell、Node.js、C#、Python、Ruby 或自定义运行时。此功能支持新的 Amazon Redshift 用例，包括从外部数据存储（例如 Amazon DynamoDB、Amazon ElastiCache 等）进行数据丰富、从外部 API（例如 Melissa Global Address Web API 等）进行数据丰富、从外部提供者（例如 Protegrity）进行数据掩码和令牌化，以及将其他语言（如 C、C++和 Java）编写的遗留 UDF 转换为 Lambda UDF。在 示例 4-10 中，从 Amazon Redshift UDFs GitHub Repo 中，您将看到一个 Lambda 函数，利用 AWS 密钥管理服务（KMS）并将传入的字符串返回为加密值。第一个代码块定义了一个 Lambda 函数 f-kms-encrypt，该函数期望传递给函数的参数的嵌套数组。在此示例中，用户将作为输入参数提供 kmskeyid 和 columnValue；argument[0] 和 argument[1]。该函数将使用 boto3 库调用 kms 服务以返回加密的 response。

示例 4-10. Lambda 函数定义

import json, boto3, os, base64
kms = boto3.client('kms')
def handler(event, context):
  ret = dict()
  res = []
  for argument in event['arguments']:
    try:
      kmskeyid = argument[0]
      columnValue = argument[1]
      if (columnValue == None):
          response = None
      else:
          ciphertext = kms.encrypt(KeyId=kmskeyid, Plaintext=columnValue)
          cipherblob = ciphertext["CiphertextBlob"]
          response = base64.b64encode(cipherblob).decode('utf-8')
      res.append(response)
    except Exception as e:
      print (str(e))
      res.append(None)
  ret['success'] = True
  ret['results'] = res
  return json.dumps(ret)

下一个代码块定义了 Amazon Redshift UDF，其中引用了 Lambda 函数（示例 4-11）。

示例 4-11. Lambda UDF 定义

CREATE OR REPLACE EXTERNAL FUNCTION f_kms_encrypt (key varchar, value varchar)
RETURNS varchar(max) STABLE
LAMBDA 'f-kms-encrypt'
IAM_ROLE default;

我们引用了default IAM 角色。请确保修改角色以授予执行先前创建的 Lambda 函数的访问权限。

就像 SQL 和 Python UDF 一样，用户可以在 SELECT 语句中引用 Lambda UDF。在这种场景中，您可能会编写在 示例 4-12 中显示的 SELECT 语句。

示例 4-12. Lambda UDF 访问

SELECT f_kms_encrypt (email) email_encrypt, email FROM customer;

在 示例 4-12 中的 SELECT 语句将产生以下输出：

email_encrypt	email
AQICAHiQbIJ478Gbu8DZyl0frUxOrbgDlP+CyfuWCuF0kHJyWg …​	jdoe@org.com

有关 Python UDF 的更多详细信息，请参阅 “Amazon Redshift 中 Python UDF 的介绍”博文，有关 Lambda UDF 的更多详细信息，请参阅 “使用 Amazon Redshift Lambda UDF 访问外部组件”博文。

存储过程

Amazon Redshift 存储过程是用户创建的对象，用于执行一组 SQL 查询和逻辑操作。该过程存储在数据库中，并可供有执行权限的用户使用。与仅能在表中操作一行数据的标量 UDF 函数不同，存储过程 可以包含数据定义语言（DDL）和数据操作语言（DML），还可以包含循环和条件表达式。此外，存储过程不必返回值。

存储过程通常用于封装数据转换、数据验证和业务特定操作的逻辑，作为替代 Shell 脚本或复杂的 ETL 和编排工具。存储过程允许将 ETL/ELT 的逻辑步骤完全封装在一个过程中。您可以编写过程以便增量提交数据，或者使其完全成功（处理所有行）或完全失败（不处理任何行）。由于所有处理均在数据仓库上进行，因此无需在网络上移动数据，而且您可以利用 Amazon Redshift 的 MPP 架构快速执行大量数据的批量操作。

另外，由于存储过程是用 PL/pgSQL 编程语言实现的，您可能不需要学习新的编程语言来使用它们。实际上，您可能在传统数据平台上已有现有的存储过程，可以通过最少的代码更改迁移到 Amazon Redshift。使用外部编程语言或新的 ETL 平台重新创建现有流程的逻辑可能是一个大项目。AWS 还提供AWS Schema Conversion Tool (SCT)，这是一个迁移助手，可以将其他数据库编程语言中的现有代码转换为 Amazon Redshift 本机的 PL/pgSQL 代码。

在示例 4-13 中，您可以看到一个简单的过程，该过程将从 Amazon S3 加载数据到暂存表，然后将新记录加载到lineitem表中，同时确保删除重复项。该过程利用了MERGE运算符，可以使用一个语句完成任务。在此示例中，l_orderyear和l_ordermonth有常量变量。然而，通过使用date_part函数和current_date变量确定要加载的当前年份和月份，或者通过向过程传递year和month参数，可以轻松地使其动态化。

示例 4-13. 存储过程定义

CREATE OR REPLACE PROCEDURE lineitem_incremental()
AS $$
DECLARE
  yr CONSTANT INTEGER := 1998; --date_part('year',current_date);
  mon CONSTANT INTEGER := 8; --date_part('month', current_date);
  query VARCHAR;
BEGIN
  TRUNCATE stage_lineitem;
  query := 'COPY stage_lineitem ' ||
  	'FROM ''s3://redshift-immersionday-labs/data/lineitem-part/' ||
	  'l_orderyear=' || yr || '/l_ordermonth=' || mon || '/''' ||
    ' IAM_ROLE default REGION ''us-west-2'' gzip delimiter ''|''';
  EXECUTE query;

  MERGE INTO lineitem
  USING stage_lineitem s ON s.l_orderkey=lineitem.l_orderkey
  AND s.l_linenumber = lineitem.l_linenumber
  WHEN MATCHED THEN DELETE
  WHEN NOT MATCHED THEN INSERT
    VALUES ( s.L_ORDERKEY, s.L_PARTKEY, s.L_SUPPKEY, s.L_LINENUMBER,
      s.L_QUANTITY, s.L_EXTENDEDPRICE, s.L_DISCOUNT, s.L_TAX,
      s.L_RETURNFLAG, s.L_LINESTATUS, s.L_SHIPDATE, s.L_COMMITDATE,
      s.L_RECEIPTDATE, s.L_SHIPINSTRUCT, s.L_SHIPMODE, s.L_COMMENT);

END;
$$ LANGUAGE plpgsql;

我们已引用default IAM 角色。请确保修改角色以授予读取此 Amazon S3 位置的访问权限。

您可以使用call关键字执行存储过程（参见示例 4-14）。

示例 4-14. 存储过程访问

CALL lineitem_incremental();

有关 Amazon Redshift 存储过程的更多详细信息，请参阅“将您的存储过程带到 Amazon Redshift” 博客文章。

调度和编排

当您开始考虑编排数据管道时，您需要考虑工作流程的复杂性以及对外部进程的依赖性。一些用户必须管理具有复杂依赖关系的多个系统。如果作业失败或未达到 SLA，您可能需要高级通知要求。如果是这样，您可能要考虑使用第三方调度工具。流行的第三方企业作业调度工具包括Tivoli，Control-M和AutoSys，每个工具都与 Amazon Redshift 集成，允许您建立连接并执行一个或多个 SQL 语句。AWS 还提供基于开源Apache Airflow项目的Amazon 管理的工作流编排（MWAA）服务。如果您已经在运行 Apache Airflow 工作流并希望将其迁移到云端，这将非常有用。

然而，如果您可以基于时间触发您的加载操作，您可以利用查询调度程序。当您使用查询调度程序时，UI 将利用 Amazon Redshift Data API 和 EventBridge 的基础服务。

要使用查询调度程序触发简单的基于时间的查询，请导航至查询编辑器 V2，准备您的查询，然后点击计划按钮（图 4-1）。对于此示例，我们将使用COPY语句加载stage_lineitem表。

设置连接（图 4-2）以及调度程序将用来执行查询的 IAM 角色。在随后的对话框中，从列表中选择适用的 Amazon Redshift 数据仓库以及相应的帐户和区域。在我们的情况下，我们将使用“临时凭证”进行连接。有关其他连接策略的详细信息，请参阅第二章，“Amazon Redshift 入门”。

图 4-1. 计划按钮

图 4-2. 选择连接

接下来，设置将要执行的查询名称以及可选描述（图 4-3）。查询将从编辑器页面复制过来。

图 4-3. 设置查询

接下来，按照 Cron 格式设置基于时间的计划，或者通过选择适用的单选选项（图 4-4）。可选地，选择是否希望将执行事件传递到 Amazon 简单通知服务（SNS）主题，以便接收通知。单击“保存更改”保存计划。

图 4-4. 设置计划

要查看已安排的查询列表，请导航至已安排查询页面的查询编辑器 V2（图 4-5）。

图 4-5. 已安排的查询列表

要管理调度作业，请点击调度查询。在此屏幕上，您可以修改作业、停用它或删除它。您还可以检查历史记录，其中包含开始/停止时间以及作业状态（参见图 4-6）。

图 4-6. 查看调度历史

您还可以查看在 EventBridge 中创建的资源。导航到EventBridge 规则页面，注意已创建一个新的调度规则（图 4-7）。

图 4-7. 调度规则

检查规则目标（图 4-8），您将看到Redshift cluster目标类型以及执行查询所需的参数。

图 4-8. 调度规则目标

访问所有数据

要完成 ELT 故事，Amazon Redshift 支持访问未加载的数据。Amazon Redshift 计算将使用所有已提到的转换能力处理您的数据，无需单独的处理服务器。无论是“外部 Amazon S3 数据”，“外部操作数据”，甚至是“外部 Amazon Redshift 数据”，在您的 Amazon Redshift 数据仓库中使用熟悉的 ANSI SQL 语法提交查询；只有适用的数据由 Amazon Redshift 计算处理。它可以与本地数据进行连接，并用于填充您的 Amazon Redshift 数据仓库本地表。

外部 Amazon S3 数据

Amazon Redshift 使您能够使用简单的 SQL 查询读取和写入存储在 Amazon S3 中的外部数据。访问 Amazon S3 上的数据增强了您的数据的互操作性，因为您可以从 Amazon Redshift 以外的多个计算平台访问相同的 Amazon S3 数据。这些平台包括 Amazon Athena、Amazon EMR、Presto 以及任何其他能够访问 Amazon S3 的计算平台。使用此功能，Amazon Redshift 可以将外部 Amazon S3 表与驻留在 Amazon Redshift 数据仓库本地磁盘上的表进行连接。在使用预置集群时，Amazon Redshift 将利用称为 Amazon Redshift Spectrum 的节点群集，进一步隔离 Amazon S3 处理，并应用优化，如谓词推送和聚合到 Amazon Redshift Spectrum 计算层，提高查询性能。您可以推送到 Amazon Redshift Spectrum 的谓词运算符类型包括：=, LIKE, IS NULL和CASE WHEN。此外，您还可以使用转换逻辑，在 Amazon Redshift Spectrum 层推送许多聚合和字符串函数。聚合函数的类型包括：COUNT, SUM, AVG, MIN和MAX。

Amazon Redshift Spectrum 使用计算资源处理 Amazon S3 数据，计算资源是您的预配集群中切片数量的 10 倍。此外，扫描每 TB 数据的成本为 $5。相比之下，使用 Amazon Redshift 无服务器查询 Amazon S3 数据时，处理发生在您的 Amazon Redshift 计算资源上，并且成本包含在 RPU 定价中。

查询外部 Amazon S3 数据通过利用一个外部 metadata catalog，该目录将数据集组织成 databases 和 tables。然后，您将一个数据库映射到 Amazon Redshift 的 schema，并通过 IAM ROLE 提供凭据，确定您的访问级别。在 示例 4-15 中，您的 metadata catalog 是 AWS Glue data catalog，其中包含一个名为 externaldb 的数据库。如果该数据库不存在，此命令将创建它。我们已将该数据库映射到一个新的架构 externalschema，使用附加到数据仓库的 default IAM 角色。除了 AWS Glue data catalog 外，用户还可以映射到 hive metastore，如果您的数据位于 EMR 集群或自管理的 Apache Hadoop 环境中。有关创建外部架构选项的更多详细信息，请参阅 在线文档。

示例 4-15. 创建外部 S3 架构

CREATE EXTERNAL SCHEMA IF NOT EXISTS externalschema
FROM data catalog DATABASE 'externaldb'
IAM_ROLE default
CREATE EXTERNAL DATABASE IF NOT EXISTS;

我们已经引用了default IAM 角色。请确保修改角色以便访问和管理 AWS Glue 数据目录。

一旦外部架构创建完成，您可以像操作已加载到 Amazon Redshift 中的表一样轻松查询数据。在 示例 4-16 中，您可以查询与本地存储的数据进行关联的外部表数据。

示例 4-16. 外部 S3 表访问

SELECT
 t.returnflag,
 t.linestatus,
 c.zip,
 sum(t.quantity) AS sum_qty,
 sum(t.extendedprice*(1-t.discount)*(1+t.tax)) AS sum_charge
FROM externalschema.transactions t
JOIN public.customers c on c.id = t.customer_id
WHERE t.year = 2022 AND t.month = 1
GROUP BY t.returnflag, t.linestatus, c.zip;

此查询具有一个筛选器，将外部表数据限制为 2022 年 1 月和一个简单的聚合操作。在使用预配集群时，此筛选器和部分聚合将在 Amazon Redshift Spectrum 层处理，从而减少发送到计算节点的数据量，并提高查询性能。

因为在 Amazon Redshift 中查询本地存储的数据时可以获得最佳性能，因此将最近的数据加载到 Amazon Redshift 并从外部来源查询不经常访问的数据是最佳实践。通过遵循这一策略，您可以确保最热的数据存储在计算资源附近，并且以优化了的分析处理格式存在。在 示例 4-17 中，您可能会有一个加载过程，用最新一个月的数据填充交易表，但所有数据都存在于 Amazon S3 中。当用户访问时，他们将看到数据的汇总视图，但当他们访问最热的数据时，Amazon Redshift 将从本地存储中检索它。

示例 4-17. 合并 S3 和本地数据

CREATE VIEW public.transactions_all AS
  SELECT … FROM public.transactions
  UNION ALL
  SELECT … FROM externalschema.transactions
  WHERE year != date_part(YEAR, current_date)
    AND month != date_part(MONTH, current_date);
WITH NO SCHEMA BINDING;

NO SCHEMA BINDING 子句必须用于外部表，以确保数据可以在 Amazon S3 中加载，而不会对 Amazon Redshift 造成任何影响或依赖。

有关 Amazon Redshift Spectrum 优化技术的更多详细信息，请参阅 Amazon Redshift Spectrum 最佳实践博客。

外部运营数据

Amazon Redshift 联合查询允许您直接查询存储在事务性数据库中的数据，实现实时数据集成和简化的 ETL 处理。使用联合查询，您可以为用户提供实时洞察。一个典型的用例是当您向数据仓库批量注入数据时，但您需要实时分析时。您可以提供 Amazon Redshift 批量加载数据和事务性数据库当前实时数据的结合视图。联合查询还将这些源数据库的元数据暴露为外部表，允许像 Tableau 和 Amazon QuickSight 这样的 BI 工具查询联合数据源。这为您提供了无缝查询运营数据、简化 ETL 流水线以及构建数据到绑定视图的新数据仓库用例。截至 2022 年，支持的事务性数据库包括 Amazon Aurora PostgreSQL/MySQL 和 Amazon RDS for PostgreSQL/MySQL。

Amazon Redshift 联合查询通过与您的操作数据存储建立 TCP/IP 连接并将其映射到外部模式来工作。您需要通过 AWS Secrets Manager 密钥提供数据库类型和连接信息以及连接凭据。在 示例 4-18 中，数据库类型为 POSTGRES，连接信息指定了数据库的 DATABASE、SCHEMA 和 URI。有关使用联合查询创建外部模式时的选项的详细信息，请参阅 在线文档。

示例 4-18. 创建外部模式

CREATE EXTERNAL SCHEMA IF NOT EXISTS federatedschema
FROM POSTGRES DATABASE 'db1' SCHEMA 'pgschema'
URI '<rdsname>.<hashkey>.<region>.rds.amazonaws.com'
SECRET_ARN 'arn:aws:secretsmanager:us-east-1:123456789012:secret:pgsecret'
IAM_ROLE default;

我们引用了 default IAM 角色。确保修改角色以授予使用 Secrets Manager 检索名为 pgsecret 的秘密的访问权限。

创建外部模式后，您可以像查询本地 Amazon Redshift 表一样查询这些表。在 示例 4-19 中，您可以查询从外部表获取的数据，与本地存储的数据进行连接，类似于查询外部 Amazon S3 数据时执行的查询。查询还包含一个筛选器，将联合表中的数据限制为 2022 年 1 月。Amazon Redshift 联合查询智能地将谓词推送到联合源以限制扫描的数据量，极大地提高了查询性能。

示例 4-19. 外部表访问

SELECT
 t.returnflag,
 t.linestatus,
 c.zip,
 sum(t.quantity) AS sum_qty,
 sum(t.extendedprice*(1-t.discount)*(1+t.tax)) AS sum_charge
FROM federatedschema.transactions t
JOIN public.customers c ON c.id = t.customer_id
WHERE t.year = 2022 AND t.month = 1
GROUP by t.returnflag, t.linestatus, c.zip;

由于联合查询在事务系统上执行查询，请注意限制查询的数据。一个好的实践是使用 Amazon Redshift 本地表中的历史数据，并仅访问联合数据库中的最新数据。

除了查询实时数据外，联合查询还开辟了简化 ETL 过程的机会。许多组织在构建其数据仓库时使用的常见 ETL 模式是 upsert。 upsert 是指数据工程师任务是扫描数据仓库表的源，确定是否应插入新记录或更新/删除现有记录。过去，通常需要多个步骤来完成此操作：

1. 创建源表的完全抽取，或者如果您的源有变更跟踪，则提取自上次加载处理以来的记录。

2. 将该抽取移动到您数据仓库的本地位置。对于亚马逊 Redshift，这将是 Amazon S3。

3. 使用批量加载器将数据加载到暂存表中。对于亚马逊 Redshift，这将是 COPY 命令。

4. 根据已经暂存的数据执行 MERGE（UPSERT—UPDATE 和 INSERT）命令，以更新目标表。

使用联合查询，您可以绕过在 Amazon S3 中进行增量提取和随后通过 COPY 加载数据的需求，直接在其源数据库中的原地查询数据。在 示例 4-20 中，我们展示了如何通过单个 MERGE 语句从操作源同步客户表。

示例 4-20. 使用 MERGE 进行增量更新

MERGE INTO customer
USING federatedschema.customer p ON p.customer_id = customer.customer_id
  AND p.updatets > current_date-1 and p.updatets < current_date
WHEN MATCHED THEN UPDATE SET customer_id = p.customer_id,
  name = p.name, address = p.address,
  nationkey = p.nationkey, mktsegment = p.mktsegment
WHEN NOT MATCHED THEN INSERT (custkey, name, address, nationkey, mktsegment)
  VALUES ( p.customer_id, p.name, p.address, p.nationkey, p.mktsegment )

欲了解有关联合查询优化技术的更多详细信息，请参阅博文 “亚马逊 Redshift 联合查询的最佳实践”，以及有关简化 ETL 策略的其他方法的更多详细信息，请参阅博文 “使用亚马逊 Redshift 联合查询构建简化的 ETL 和实时数据查询解决方案”。

外部亚马逊 Redshift 数据

亚马逊 Redshift 数据共享使您能够直接查询存储在另一个亚马逊 Redshift 数据仓库的 Amazon RMS 中的实时数据，无论是使用 RA3 节点类型的预配集群还是服务器无数据仓库。此功能使得在另一个亚马逊 Redshift 数据仓库中访问在一个亚马逊 Redshift 数据仓库中生成的数据成为可能。与其他外部数据源类似，数据共享功能还将来自生产者亚马逊 Redshift 数据仓库的元数据作为外部表暴露出来，允许消费者在不必制作本地副本的情况下查询该数据。这使得新的数据仓库用例成为可能，例如分配数据所有权和隔离不同工作负载的执行。在 第七章，“与数据共享协作” 中，我们将更详细地介绍这些用例。在接下来的示例中，您将了解如何使用 SQL 语句配置数据共享以及如何在您的 ETL/ELT 过程中使用它。有关如何从 Redshift 控制台启用和配置数据共享的详细信息，请参阅 在线文档。

数据共享的第一步是了解生产者和消费者数据仓库的命名空间。在每个数据仓库上执行以下操作以检索相应的值（示例 4-21）。

示例 4-21. 当前命名空间

SELECT current_namespace;

接下来，在生产者数据仓库中创建一个数据共享对象，并添加诸如架构和表等数据库对象（示例 4-22）。

示例 4-22. 创建数据共享

CREATE DATASHARE transactions_datashare;
ALTER DATASHARE transactions_datashare
  ADD SCHEMA transactions_schema;
ALTER DATASHARE transactions_datashare
  ADD ALL TABLES IN SCHEMA transactions_schema;

您现在可以通过引用其命名空间（示例 4-23）将数据共享的访问权从生产者授予给消费者。

示例 4-23. 授予数据共享使用权

GRANT USAGE ON DATASHARE transactions_datashare
TO NAMESPACE '1m137c4-1187-4bf3-8ce2-CONSUMER-NAMESPACE';

最后，您在消费者端创建一个数据库，引用数据共享名称以及生产者的命名空间（示例 4-24）。

示例 4-24. 创建数据共享数据库

CREATE DATABASE transactions_database from DATASHARE transactions_datashare
OF NAMESPACE '45b137c4-1287-4vf3-8cw2-PRODUCER-NAMESPACE';

数据共享还可以跨帐户授予。在这种情况下，与数据共享相关的管理员需要执行额外的步骤。有关更多信息，请参阅在线文档。

一旦外部数据库创建完成，您可以像本地 Amazon Redshift 数据仓库中的表一样轻松查询数据。在示例 4-25 中，您正在查询外部表与本地存储的数据联接，类似于使用外部 Amazon S3 和运营数据时执行的查询。同样，该查询包含一个筛选器，将外部表的数据限制为 2022 年 1 月的数据。

示例 4-25. 数据共享访问

SELECT
 t.returnflag,
 t.linestatus,
 c.zip,
 sum(t.quantity) as sum_qty,
 sum(t.extendedprice*(1-t.discount)*(1+t.tax)) as sum_charge
FROM transactions_database.transcations_schema.transactions t
JOIN public.customers c on c.id = t.customer_id
WHERE t.year = 2022 AND t.month = 1
GROUP by t.returnflag, t.linestatus, c.zip;

您可以想象一种设置，其中一个部门可能负责管理销售交易，另一个部门负责客户关系。客户关系部门有兴趣确定他们最好和最差的客户，以便发送定向营销。与其需要维护单一的数据仓库并共享资源，每个部门可以利用自己的 Amazon Redshift 数据仓库，并负责自己的数据。客户关系团队可以直接查询而不是复制交易数据。他们可以构建和维护该数据的聚合，并将其与以前的营销活动数据以及客户情感数据联接，以构建他们的营销活动。

了解更多有关数据共享的信息，请阅读“在 Amazon Redshift 集群之间安全共享 Amazon Redshift 数据”和“Amazon Redshift 数据共享的最佳实践和考虑因素”。

外部转换

在希望使用外部工具进行数据转换的场景中，Amazon Redshift 可以通过 JDBC 和 ODBC 驱动程序连接到您选择的 ETL 平台，这些驱动程序可以是这些应用程序打包的，也可以是可下载的。与 Amazon Redshift 集成的流行 ETL 平台包括第三方工具如Informatica、Matillion和dbt，以及 AWS 本地工具如“AWS Glue”。ETL 工具是管理数据流水线所有组件的宝贵方式。它们提供作业存储库来组织和维护元数据，使组织能够更轻松地管理其代码，而不是将该逻辑存储在 SQL 脚本和存储过程中。它们还具有调度功能，有助于作业编排，这在您没有使用 AWS 本地提供的“调度和编排”时非常有用。

一些 ETL 工具还具有“下推”转换逻辑的能力。在您可能需要从 Amazon Redshift 数据仓库读取和写入数据的情况下，您可以使用 ETL 工具的可视化能力设计作业，但不是将数据实际提取到 ETL 服务器的计算中，而是将代码转换为在 Amazon Redshift 上运行的 SQL 语句。当转换大量数据时，这种策略可以非常高效，但也可能消耗您的最终用户可能需要用于分析数据的大量资源。当您不使用 ETL 工具的下推功能时，无论是因为您的作业不是从 Amazon Redshift 读取和写入数据，还是因为您决定要卸载转换逻辑，都很重要确保您的 ETL 工具以高效的方式从 Amazon Redshift 读取和写入数据。

正如在第三章，“设置数据模型和数据摄入”中讨论的那样，加载数据的最佳性能方式是使用COPY语句。由于 AWS 与 Informatica 和 Matillion 等 ETL 供应商的合作，AWS 确保供应商基于这一策略构建了连接器。例如，在 Informatica Amazon Redshift 架构的图 4-9 中，您可以看到，如果您已指定了 Amazon Redshift 目标和 Amazon S3 中的临时区域，工具将不会直接通过插入加载目标，而是会先将数据写入 Amazon S3，然后使用 Amazon Redshift 的COPY语句加载到目标表中。这种策略对于update和delete语句同样适用，只是 Informatica 会将数据写入临时表，并执行后续的update和delete语句。这种优化得益于 AWS 与多个软件供应商的合作，确保用户轻松利用工具并确保其数据管道的性能。详细的最佳实践指南，请参阅以下已发布的内容：

• Informatica——Amazon Redshift 连接器最佳实践

• Matillion——Amazon Redshift ETL 处理的最佳实践

• dbt——利用 Amazon Redshift 和 dbt 的最佳实践

图 4-9. Informatica Amazon Redshift 架构

AWS Glue

AWS Glue 是常用的本地无服务器数据集成服务之一，可使用 Python 或 Scala 语言进行数据转换，并在数据处理引擎上运行。通过 AWS Glue（图 4-10），您可以读取 Amazon S3 数据，应用转换，并将数据摄入 Amazon Redshift 数据仓库以及其他数据平台。AWS Glue 使发现、准备、移动和集成来自多个来源的数据，以进行分析、机器学习和应用程序开发变得更加简单。它提供多个数据集成引擎，包括 AWS Glue for Apache Spark、AWS Glue for Ray 和 AWS Glue for Python Shell。您可以根据工作负载的特性和开发人员与分析师的偏好选择合适的引擎。

图 4-10. 使用 AWS Glue 进行 ETL 集成

自 AWS Glue V4 起，AWS Glue ETL 作业配备了一个新的 Amazon Redshift Spark 连接器和新的 JDBC 驱动程序。您可以使用它构建 Apache Spark 应用程序，作为数据摄取和转换管道的一部分，读取和写入 Amazon Redshift 中的数据。新的连接器和驱动程序支持将关系操作（如连接、聚合、排序和标量函数）从 Spark 推送到 Amazon Redshift，以减少需要处理的数据量，从而提高作业性能。它还支持基于 IAM 的角色，以实现单点登录功能，并与 AWS Secrets Manager 集成，用于安全管理密钥。

要管理您的 AWS Glue 作业，AWS 提供了一种可视化的创作工具，AWS Glue Studio。该服务遵循已经提到的第三方 ETL 工具的许多最佳实践，但由于集成，构建和管理数据管道所需的步骤更少。

在 示例 4-26 中，我们将构建一个作业，从 Amazon S3 加载增量交易数据，并将其合并到您的 Amazon Redshift 数据仓库中的 lineitem 表中，使用键 (l_orderkey, l⁠_⁠l⁠i⁠n⁠e​n⁠u⁠m⁠b⁠e⁠r)。

示例 4-26. 创建 lineitem 表

CREATE TABLE lineitem (
  L_ORDERKEY varchar(20) NOT NULL,
  L_PARTKEY varchar(20),
  L_SUPPKEY varchar(20),
  L_LINENUMBER integer NOT NULL,
  L_QUANTITY varchar(20),
  L_EXTENDEDPRICE varchar(20),
  L_DISCOUNT varchar(20),
  L_TAX varchar(20),
  L_RETURNFLAG varchar(1),
  L_LINESTATUS varchar(1),
  L_SHIPDATE date,
  L_COMMITDATE date,
  L_RECEIPTDATE date,
  L_SHIPINSTRUCT varchar(25),
  L_SHIPMODE varchar(10),
  L_COMMENT varchar(44));

要构建一个 Glue 作业，请按照接下来的两个部分的说明操作。

注册 Amazon Redshift 目标连接

转到 “创建连接” 创建一个新的 AWS Glue 连接。命名连接并选择 Amazon Redshift 作为连接类型（参见 图 4-11）。

图 4-11. Amazon Redshift 连接名称

接下来，从您的 AWS 帐户和区域的自动发现的 Amazon Redshift 数据仓库列表中选择数据库实例。设置数据库名称和访问凭据。您可以选择设置用户名和密码，或使用 AWS Secrets Manager。最后，点击“创建连接”（参见 图 4-12）。

图 4-12. Amazon Redshift 连接实例

构建并运行您的 AWS Glue 作业

要构建一个 AWS Glue 作业，请导航至 AWS Glue Studio 的 作业页面。您将看到一个对话框，提示您选择作业的选项（参见 图 4-13）。在本例中，我们将选择“可视化，带有源和目标”。将目标修改为 Amazon Redshift，并选择创建。

图 4-13. AWS Glue 创建作业

接下来，您将看到作业的可视化表示。第一步是选择数据源节点并设置 S3 源类型（图 4-14）。对于我们的用例，我们将使用一个 S3 位置，并输入我们数据的位置：s3://redshift-immersionday-labs/data/lineitem-part/。选择解析细节，如数据格式、分隔符、转义字符等。对于我们的用例，文件将采用 CSV 格式，是以管道符（|）分隔的，并且没有列标题。最后，点击“推断模式”按钮。

图 4-14. AWS Glue 设置 Amazon S3 存储桶

如果您已建立了一个数据湖，并且正在使用它来查询其他 AWS 服务，如 Amazon Athena、Amazon EMR，甚至是作为外部表的 Amazon Redshift，您也可以选择使用“数据目录表”选项。

接下来，我们可以转换我们的数据（图 4-15）。该作业建立在一个简单的 ApplyMapping 节点上，但您有许多选项来转换您的数据，如连接、拆分和聚合数据。请参阅“编辑 AWS Glue 管理的数据转换节点” AWS 文档了解更多转换节点信息。选择转换节点，并设置与源键匹配的目标键。在我们的情况下，源数据没有列标题，并且以通用列（col#）注册。将它们映射到您 lineitem 表中的相应列。

图 4-15. AWS Glue 应用映射

现在您可以设置 Amazon Redshift 的详细信息（图 4-16）。选择“直接数据连接”，并选择适用的模式（public）和表（lineitem）。您还可以设置作业如何处理新记录；您可以选择仅插入每条记录或设置一个键，以便作业可以更新需要重新处理的数据。对于我们的用例，我们将选择MERGE，并设置键 l_orderkey 和 l_linenumber。这样做的好处是，当作业运行时，数据将首先加载到暂存表中，然后基于目标中已存在的任何数据运行MERGE语句，然后再使用INSERT语句加载新数据。

图 4-16. AWS Glue 设置 Amazon Redshift 目标

在保存并运行作业之前，您必须设置一些额外的作业详细信息，如 IAM 角色，该角色将用于运行作业，并设置脚本文件名（图 4-17）。该角色应具有访问 Amazon S3 位置中文件的权限，并且还应该能够被 AWS Glue 服务所假定。创建和设置 IAM 角色后，单击“保存并运行”来执行您的作业。

图 4-17. AWS Glue 设置作业详细信息

您可以通过导航到“运行”选项卡来检查作业运行。您将看到有关作业 ID 和运行统计信息的详细信息（图 4-18）。

图 4-18. AWS Glue 作业运行详情

要让 AWS Glue 访问 Amazon S3，如果还没有创建 VPC 终端节点，您需要先创建一个。请参阅在线文档获取更多详细信息。

作业完成后，您可以导航到Amazon Redshift 控制台查看查询和加载情况（图 4-19）。您将看到创建临时表、加载 Amazon S3 文件以及执行合并语句以删除旧数据并插入新数据所需的查询。

图 4-19. Amazon Redshift 查询历史

摘要

本章描述了使用 Amazon Redshift 转换数据的各种方法。借助 Amazon Redshift 能够访问您加载或未加载的所有数据，您可以快速轻松地转换数据湖、运营来源或其他 Amazon Redshift 数据仓库中的数据。此外，我们展示了如何使用 Amazon Redshift 查询调度程序实现基于时间的调度以编排这些作业。最后，我们介绍了 Amazon Redshift 如何与第三方 ETL 和编排供应商合作，以提供最佳执行性能，并与您组织中可能已有的工具集成。

在下一章中，我们将讨论当您对工作负载进行更改时 Amazon Redshift 如何扩展。我们还将介绍 Amazon Redshift 无服务器数据仓库如何自动扩展，以及您如何控制扩展您的预配数据仓库的方式。此外，我们还将讨论如何通过实施最佳实践在 Amazon Redshift 中获得最佳性价比。

第五章：扩展与性能优化

如果我们告诉您唯一不变的是变化，那么很可能我们只是“对牛弹琴”。今天的挑战是您的数据仓库能够多快地适应变化。传统的数据仓库系统，由于资源预配的提前时间，往往很难适应这种变化。通过 Amazon Redshift，适应变化变得容易，无论是存储需求的变化还是计算需求的变化。您可以快速根据需求的增加或减少来进行扩展，而不会产生昂贵的错误决策。

扩展的目标是为了满足工作负载的变化，以维持当前的性能水平和相关的 SLA。如果您向数据仓库添加新的工作负载，则现有的工作负载 SLA 可能会受到影响；这就是扩展发挥作用的地方。如果您分析的数据比以前多，这可能导致工作负载 SLA 显著影响，也可能需要扩展。为了通过 Amazon Redshift 实现您的扩展目标，有两种策略需要考虑：确保您的数据仓库大小正确，并确保您的工作负载经过性能调优。

使用 Amazon Redshift，您可以通过垂直和水平扩展来调整数据仓库的大小（参见 Figure 5-1）。垂直扩展 是指通过在单个查询上运行的额外计算来进行“向上”扩展。向上扩展导致 vCPU 或内存总数增加。如果您需要保持现有工作负载的 SLA 并处理额外的工作负载，则通常会“向上”扩展您的数据仓库。垂直扩展通常用于工作负载变化可预测的情况，允许您运行拉取大量行、处理更多连接并管理更长事务的更大查询。水平扩展 是指通过添加更多副本来处理额外工作负载的“向外”扩展。当您进行水平扩展时，每个查询可能由独立计算提供服务，从共享数据中读取。水平扩展通常用于工作负载变化不可预测的情况，因为每个单独的查询都会接收相同的计算资源，但系统可以处理更多并发工作负载。

在本章中，我们将向您展示，如果您使用无服务器或者 RA3 预配置的数据仓库，Amazon Redshift 将会自动“扩展存储”。此外，我们将看到，对于无服务器数据仓库，Amazon Redshift 将会根据工作负载“自动扩展您的无服务器数据仓库”，可以是向任何方向。而对于预配置的数据仓库，您可以选择何时以及何种方向“扩展您的预配置数据仓库”。

图 5-1. 竖向与横向扩展

确保你的 Amazon Redshift 数据仓库大小设置正确非常重要，同样重要的是确保你的工作负载经过调优以提升性能。这两者的结合将确保你充分利用资源，并获得最佳性价比。为了提升工作负载的性能，Amazon Redshift 提供了许多功能，适用于无服务器和预置数据仓库。在本章中，我们将介绍一些最佳实践。我们将描述“WLM，队列和 QMR”，这是预置数据仓库特有的功能。我们将展示“Materialized Views”如何支持不同的访问模式，“Autonomics”如何确保表的良好维护，以及“Workload Isolation”如何确保混合工作负载获得所需的计算资源。接下来，我们将详细介绍查询的执行方式以及如何考虑“Query Tuning”。最后，我们将描述几种“实现最佳性价比的额外优化”。

扩展存储

在第二章，“开始使用 Amazon Redshift”中，我们描述了在使用无服务器或 RA3 预置数据仓库时，Amazon Redshift 由 RMS 支持的情况。使用 RMS 的好处在于存储弹性，这意味着你不需要简单地调整计算能力来适应额外的历史数据。考虑到你的数据仓库通常仅对最近 12 个月的数据执行分析工作负载。每天都会添加新数据，但你的计算需求仅限于分析最近 12 个月的数据。在这种情况下，无论你的仓库包含两年数据还是五年数据，你的计算成本都将保持不变。由于你的存储需求增加，你只需支付额外的存储费用。这种情况更为常见，数据仓库最终变成长期存储所有数据的库，但仅对最近的数据进行分析查询。

假设你在四月份的前 15 天内使用 RA3 节点类型的托管存储中存储了 100 GB 的数据，并在四月份的最后 15 天内存储了 100 TB 的数据。

让我们来计算四月份的 GB-hours 使用量。

在四月份的前 15 天，你将有如下使用量：100 GB × 15 天 × 24 小时/天 = 36,000 GB-Hours。

在过去的 15 天中，你将会有如下使用量：100 TB × 1024 GB/TB × 15 天 × 24 小时/天 = 36,864,000 GB-hours。

四月份结束时，GB-hours 的总使用量是：36,000 GB-Hours + 36,864,000 GB-hours = 36,900,000 GB-hours。

将其转换为 GB-month：36,900,000 GB-hours / 四月份的 720 小时/月 = 51,250 GB-months。

考虑 us-east-1 区域，在这里托管存储将按照$0.024/GB-Month收费。对于51,250 GB-month的月度存储费用将是：51,250 GB-month × $0.024 每 GB-Month = $1,230。

四月份的总 RMS 费用为$1,230。

我们这里没有展示计算成本，但无论您的数据增长如何，计算成本都将保持不变。如果您暂停了集群并且没有查询在执行，那么只会应用 RMS 成本。请注意，即使没有查询在执行，直到您删除集群，存储费用也会计入账单。

自动缩放您的无服务器数据仓库

Amazon Redshift 无服务器会自动调整您的数据仓库容量，无论您需要扩展还是扩展。在没有活动时，计算资源会在幕后自动关闭，并在加载数据或查询进入时恢复。通过 Amazon Redshift 无服务器，您无需预测工作负载需求或调整计算大小，因为它会根据工作负载变化调整计算资源。在许多情况下，使用无服务器可能会减少执行工作负载所需的总体计算。使用无服务器，Amazon Redshift 将调整计算资源以满足您的工作负载需求。以前因计算资源不足而导致磁盘分页的查询将更快完成，排队等待的查询将不再等待。

计算能力以 RPUs 衡量，并且您按照 RPU-hours 计费，采用每秒计费方式。为了控制成本，您可以指定使用限制，并定义当达到这些限制时 Amazon Redshift 将自动采取的措施。您可以按照 RPU-hours 指定使用限制，并将限制关联到每日、每周或每月的检查。设置更高的使用限制可以提高系统的整体吞吐量，特别是对需要处理高并发同时保持高性能的工作负载而言。详见 第二章，“开始使用 Amazon Redshift”，以了解 Amazon Redshift 无服务器定价示例。

扩展您的预配置数据仓库

当您配置 Amazon Redshift 集群时，您可以选择特定的节点类型和节点数量。何时扩展（通过添加更多节点或更改节点类型）以及何时扩展（通过添加并行计算）完全由您决定。通常情况下，当您面对“进化中的计算需求”或“可预测的工作负载变化”时，您会选择扩展，并且在面对“不可预测的工作负载变化”时也会选择扩展。

进化中的计算需求

要了解进化中计算的情况，让我们假设您的数据仓库项目非常成功，您正在向其中添加新的分析工作负载，但是您的仓库中的数据仍然与以前一样，因为您正在将旧数据转移到数据湖中。因此，在这种情况下，由于有更多用户查询数据仓库以获取业务见解，您的计算需求正在增长。为了保持与业务用户的相同用户体验和服务级别协议，您可以通过添加更多节点或迁移到更大的节点类型来扩展集群。

在扩展您的集群时，您的存储成本保持不变，因为数据量没有变化。

通过增加节点或更改集群的节点类型来扩展是一个快速的过程，可以通过 AWS 控制台、CLI 或 API 完成。例如，如果您从一个 2 节点 ra3.4xl 集群改为一个 2 节点 ra3.16xl 集群，您的节点规模增加了四倍，从 24 个 vCPU 增加到 96 个 vCPU，并且获得了四倍的计算和内存。同样地，如果您将您的集群从一个 2 节点 ra3.4xl 扩展到一个 8 节点 ra3.4xl，您将获得 96 个 vCPU。通过更改节点类型来扩展可以带来益处，如果您已经达到当前节点类型的限制。例如，想象一下您正在运行一个 64 节点 ra3.4xl 集群。将其扩展为一个 16 节点 ra3.16xl 集群将为您提供相同的总计算资源，但有一个更大的领导节点。

更改节点类型需要从一种计算类型到另一种计算类型的物理数据移动。您必须计划停机时间，跨团队协调，并且向系统、应用程序和用户通报日程，以限制影响。

为了说明扩展如何影响定价，假设您从 2 节点 ra3.4xlarge 集群开始，并增加了新项目，需要在月中的第 15 天调整大小到 5 节点集群。

在前 15 天，您的使用情况如下：$3.26 每个节点小时 × 2 节点 × 每天 5 小时 × 15 天 = $489

在后 15 天，您的使用情况如下：$3.26 每个节点小时 × 5 节点 × 每天 10 小时 × 15 天 = $2,445

四月的总计算费用 = $2,934

下列（见示例 5-1）AWS CLI 命令展示如何通过增加节点或选择更大的节点类型来扩展。

示例 5-1. 使用 CLI 扩展预配置集群

# scale up to 4 nodes
aws redshift modify-cluster
  --cluster-identifier mycluster01
  --node-type ra3.4xlarge
  --number-of-nodes 4

# scale up to ra3.16xl cluster
aws redshift modify-cluster
  --cluster-identifier mycluster01
  --node-type ra3.16xlarge
  --number-of-nodes 2

可预测的工作负载变化

可预测的工作负载变化是指您预期的变化，有一些时间线的概念，并且可以制定采纳计划。可预测的变化可以是前面示例中解释的一次性变化，也可以是定期重复的。比如说，您的稳态工作负载每天处理增量文件。但是每月第一天，您还需要处理上个月的对账文件。现在您已经为每日文件处理优化了您的亚马逊 Redshift 数据仓库，但是您需要在每月的第一天额外的计算来继续及时处理每日增量文件，并且还能处理对账文件。

要处理这种情况，您可以将调整大小作为月度处理作业工作流的一部分，或者您可以计划在每月的第一天进行调整大小（最多增加 4 倍），并在月的第三天将节点数调整回原始数量。一旦计划好，亚马逊 Redshift 将根据您建立的日程表进行缩放。

亚马逊 Redshift 计划程序的 cron 表达式格式为：

minute hour dayOfMonth month dayOfWeek year
0 0 1 * ? * # upsize on 1st of every month at midnight
0 0 2 * ? * # downsize on 3rd of every month at midnight

您还可以使用内置调度程序安排调整操作，如 Figure 5-2 所示。

Figure 5-2. 定时调整

亚马逊 Redshift 提供两种 调整集群大小的方法。弹性调整适合周期性调整。对于永久调整，您可以选择经典调整或弹性调整。

可以查询未记录的表 stv_xrestore_alter_queue_state 以监视调整操作的进度。请注意，示例 5-2 中的表仅捕获大于 5 TB 的大规模调整的详细信息。

Example 5-2. 监视调整操作

SELECT db_id, status, count(*)
FROM stv_xrestore_alter_queue_state
GROUP BY 1, 2
ORDER BY 3 desc;

db_id	状态	计数
654321	等待中	456
654321	已完成	23
654321	应用中	1

不可预测的工作负载变化

通过调整您的亚马逊 Redshift 数据仓库大小，可以处理可预测的工作负载变化，但不可预测的工作负载峰值可能会成为挑战，因为它们可能具有间歇性的特性。如果您为满足峰值需求而配置集群，则在非高峰时段浪费资源。另一种选择是为典型工作负载进行大小调整，这可能意味着在意外查询出现时需要更长时间以作出重要的业务决策。这就是并发缩放（CS）发挥作用的地方。

亚马逊 Redshift 自动启动额外的扩展集群，以满足不可预测的工作负载峰值，如 Figure 5-3 所示。亚马逊 Redshift 在其所有节点类型上为读取查询提供 CS，对于 RA3 节点类型，还可以为写入查询提供 CS。后续章节详细介绍如何启用此功能以及其位置。

通过配置工作负载管理（WLM）队列来选择哪些查询利用并发缩放，详情请参阅 “WLM、队列和 QMR”。当所有 CS 启用队列中所有等待查询的总等待时间超过一分钟时，将触发 CS。对于那些需要更积极的 CS 的情况，可以通过与 AWS 支持合作来更改这一分钟设置。一旦启动了 CS 集群，那么任何新的查询进入 CS 启用队列时都不再等待，而是直接发送到 CS 集群。

Figure 5-3. 亚马逊 Redshift 并发缩放

通过访问亚马逊 Redshift 控制台的“工作负载管理”部分来控制并发缩放，如 Figure 5-4 所示。虽然您无法编辑 default.redshift-1.0 参数组，但可以创建新的参数组并修改 max_concurrency_scaling_clusters 参数以控制可以启动的 CS 集群数量。请注意，最多可以为 10 个，但如果您的工作负载需要更多，可以申请增加。我们将在 “参数组” 中深入介绍参数组。

Concurrency Scaling 集群独立运行以执行分配的查询。每个要执行的查询首先需要编译，并且请注意主集群和 CS 集群上的编译缓存是独立的。在查询处理过程中，Amazon Redshift 生成查询段，并检查集群本地缓存中是否有查询段。如果没有，则检查外部代码编译缓存（全局缓存）中是否有查询段。如果有，则从全局缓存下载编译对象到本地缓存；否则，将查询段发送到外部编译农场以使用大规模并行编译，然后存储在外部代码编译缓存和相应的本地编译缓存中。因此，即使 CS 集群在启动时没有查询段，仍然可以利用全局缓存（如果可用），否则将需要从头开始重新编译查询。

图 5-4. 最大并发扩展集群

使用 Concurrency Scaling，用户查询运行在最新数据上，无论其在主集群还是 CS 集群上运行。只要服务查询，Amazon Redshift 就会不断刷新 CS 集群的最新数据。请注意，CS 有相关成本，但 Amazon Redshift 每 24 小时主集群运行时提供一小时免费 CS 信用。

Concurrency Scaling 集群在几分钟内启动，按秒计费，仅在活动查询时计费，而不是在其被提供或释放时。一旦释放 CS 集群，它们将返回到 Amazon EC2 池中，其中这些 EC2 虚拟机在被重新引入 CS 集群前会进行完全清理和重置。这确保没有残留对象从一个 CS 使用到另一个 CS 使用。

Concurrency Scaling 使用按需定价计费，Amazon Redshift 提供预留实例（RI）定价折扣。因此，如果您发现高 Concurrency Scaling 使用率，则应评估是否通过向 RI 集群添加节点来提升效果更佳。

Concurrency Scaling 成本控制可以直接在 Amazon Redshift 控制台中设置。一旦达到定义的限制，Amazon Redshift 可以将日志记录写入系统表，或者完全关闭 Concurrency Scaling 功能。在达到使用限制时正在执行的任何查询将在 Concurrency Scaling 集群中完成执行，但随后的查询将留在主集群中排队，直到执行。

Concurrency Scaling 限制可以动态更改，无需重新启动集群。截至目前，Concurrency Scaling 功能仅在商业地区可用，并且在 AWS GovCloud 地区不可用。

WLM、队列和 QMR

典型的组织可能有多种类型的用户，对性能有不同的期望。亚马逊 Redshift 预配置集群的 工作负载管理（WLM）功能提供了根据业务优先级运行工作负载的能力（见 图 5-5）。WLM 提供了必要的控制来最大化数据仓库的吞吐量，即在给定时间内处理的查询数量。您可以定义最多八个队列来逻辑上分离正在执行的查询。每个队列都有一个唯一的服务类标识符。标识符 1 到 4 保留用于系统使用，5 用于超级用户队列，15 用于亚马逊 Redshift 的日常运维活动。更多详情请参阅 WLM 系统表和视图。

图 5-5. Amazon Redshift WLM 队列

在 图 5-5 中，您可以看到已定义了三个队列，WLM 根据队列分配规则将从左侧进入的查询分配到右侧特定的 WLM 队列。

队列分配

亚马逊 Redshift 的默认配置包含一个队列，即默认队列，除非根据分配规则将查询路由到另一个队列，否则所有查询都将在其中执行。

根据匹配逻辑，WLM 将查询分配给队列，方法如下：

1. 如果具有超级用户特权的用户提交查询，并且查询组已设置为超级用户，则分配到超级用户队列。

2. 如果普通用户提交查询，并且匹配到用户组，则分配到匹配的队列。

3. 如果普通用户提交查询，并且匹配到查询组，则分配到匹配的队列。

4. 如果没有找到匹配项，则分配到默认队列。

请参阅 WLM 队列分配规则 以获取队列分配的流程图和示例。

如果一个查询匹配多个队列，则将其分配给首个匹配的队列。

每个查询被分配一个执行插槽。插槽是您集群内存或 RAM 的一部分。超级用户队列始终具有并发度为一，无论是手动 WLM 还是自动 WLM。您必须手动将查询组设置为超级用户，才能将您的查询运行在超级用户队列中（见 示例 5-3）。

示例 5-3. 超级用户队列

SET query_group TO 'superuser';
RESET query_group;

每个队列可以映射到用户组或查询组。用户组只是用户的逻辑分组，例如，一个名为 etl_group 的用户组，其中包含所有个别应用的 ETL 用户，如 app_1_etl_usr、app_2_etl_usr。查询组是在运行时设置的文本标签（见 示例 5-4）。这通常由使用单个数据库用户 ID 的 BI 工具使用，但希望将某个仪表板查询优先于其他查询。

示例 5-4. 设置查询组

SET query_group TO 'c_level_dashboard';

默认情况下，每个查询被分配一个单独的插槽，如果查询能够在分配的内存内完成执行，那么性能会比查询溢出到磁盘时更快。

使用 示例 5-5 查询来检查磁盘溢出的查询。

示例 5-5. 检查磁盘溢出

WITH q_spill AS
  (
  SELECT
      starttime,
      q.query,
      round(nvl(query_temp_blocks_to_disk,0)::decimal/1000,2) spill
  FROM stl_query q
  LEFT JOIN svl_query_metrics_summary m
  USING (query)
  WHERE q.userid >= 100
  )
SELECT
    date_trunc('d',starttime) AS day,
    count(query) AS queries,
    sum(CASE WHEN spill = 0
      THEN 1 ELSE 0 END) AS no_spill,
    sum(CASE WHEN spill > 0 AND
      spill < 5 THEN 1 ELSE 0 END) AS "<5GB",
    sum(CASE WHEN spill
      BETWEEN 5 AND 200 THEN 1 ELSE 0 END) AS "5-200GB",
    sum(CASE WHEN spill
      BETWEEN 201 AND 500 THEN 1 ELSE 0 END) AS "201-500GB",
    sum(CASE WHEN spill
      BETWEEN 501 AND 1000 THEN 1 ELSE 0 END) AS "501GB-1TB",
    sum(CASE WHEN spill > 1000
      THEN 1 ELSE 0 END) AS ">1TB",
    round(max(spill),2) AS max_spill_gb
FROM
    q_spill
GROUP BY 1
ORDER BY 1;

分配的插槽数量和每个插槽分配的内存量对查询执行性能至关重要。

您可以使用wlm_query_slot_count参数来为大查询（如VACUUM）分配更多的插槽，这会暂时降低集群的并发性，直到重置查询插槽计数。这在手动 WLM 以及自动 WLM 模式下均适用。

您可以选择在手动 WLM 中自行设置这些插槽，或者让 Amazon Redshift 在自动 WLM 模式下管理它们。

短查询加速

还有一个专门用于短时查询的队列，称为短查询加速（SQA）队列。Amazon Redshift 会估计每个查询的执行时间，如果符合条件，则将其发送到 SQA 队列。如果实际查询运行时间超过 SQA 时间，则将查询移到匹配的 WLM 队列之一。只有只读查询符合 SQA 资格。SQA 的服务类标识符为 14。

在手动 WLM 中，您可以指定使查询符合 SQA 资格所需的最大运行时间（秒），但在自动 WLM 中，这将根据您的查询模式由 Amazon Redshift 自动确定。

如果你正在使用手动的 WLM，那么可以使用 SQL 示例 5-6 分析你的工作负载队列，并选择在第 70 到 90 百分位之间设置一个 SQA 阈值。

示例 5-6. SQA 阈值

SELECT
  service_class AS QUEUE,
  count(1) AS queries,
  avg(total_queue_time)/1000000 AS avg_q_sec,
  min(total_queue_time)/1000000 AS min_q_sec,
  max(total_queue_time)/1000000 AS max_q_sec,
  round(percentile_cont(0.7)
    WITHIN group
      (ORDER BY total_queue_time)/1000000,0) AS p70_sec,
  round(percentile_cont(0.9)
    WITHIN group
      (ORDER BY total_queue_time)/1000000,0) AS p90_sec
FROM
  stl_wlm_query
WHERE
  userid >= 100
GROUP BY
  service_class
ORDER BY
  service_class;

队列	查询数	平均查询时间（秒）	最小查询时间（秒）	最大查询时间（秒）	p70 时间（秒）	p90 时间（秒）
5	20103	23	0	95	15	19
6	3421	42	15	32	18	23
7	42	178	109	466	176	261
8	196	398	99	1399	108	206

在前面的例子中，设置 SQA 在 15 到 18 之间将允许大多数查询利用 SQA 的优势。

查询监控规则

在 Amazon Redshift 的两种 WLM 模式中，都提供了查询监控规则（QMR），用于根据某些查询执行规则控制集群行为。您可以使用 16 个系统定义的度量来定义 QMR 条件，Amazon Redshift 还提供了 5 个系统定义的模板，帮助您快速开始使用 QMR。一旦执行中的查询触发了定义的边界，就会触发定义的动作。动作可以是中止、记录、更改查询优先级（仅自动 WLM）、或将查询（仅手动 WLM）跳转到另一个匹配的队列。您可以在所有队列中定义最多 25 个 QMR，每个 QMR 可以评估最多 3 个条件。当规则的所有条件都满足时，WLM 会向STL_WLM_RULE_ACTION系统表写入一行。此行包含触发规则的查询的详细信息及其结果动作。

Amazon Redshift 无服务器没有 WLM，但它确实有查询限制，其遵循与 QMR 相同的规则逻辑。使用这些功能确保用户不会发出运行失控的查询。

QMR 指标每 10 秒进行评估，因此可能会看到一些规则需要一段时间才能触发。

您可以设置 QMR 以获得有关糟糕查询的通知，并主动采取行动，而不是在用户投诉后再处理延迟问题。使用 QMR 还可以识别用户社区的学习领域，并通过记录编写不佳的查询并进行后续讨论和工作坊来帮助他们提升技术技能。

利用系统表和视图来确定定义 QMR 的阈值。表STV_QUERY_METRICS显示当前运行查询的指标，表STL_QUERY_METRICS记录已完成查询的指标，视图SVL_QUERY_METRICS显示已完成查询的指标，视图SVL_QUERY_M⁠E⁠T⁠R⁠I⁠C⁠S⁠_​S⁠U⁠M⁠M⁠A⁠R⁠Y显示已完成查询的指标的最大值。

对于典型的BI 队列，应设置 QMR 以处理嵌套循环连接，这通常由于缺少连接谓词而导致大型笛卡尔积。使用低行数早期查找潜在的运行失控查询。如果专门为简单且运行时间短的查询设置了队列，则包括一个规则，查找返回异常高行数的查询。使用unload选项而不是返回数十亿行。

对于典型的分析师队列，应设置 QMR 以处理行数较多的连接，这可能表明需要更严格的过滤器。或者在写入中间结果时使用高磁盘使用量，这可能是一个恶意查询的结果，通常也是使用最多磁盘空间的查询。

对于严重违规情况，例如仪表板队列，其中查询在 10 秒内完成，应设置 QMR 以在查询执行时间超过 20 秒时中止，这可能表明存在错误查询。

对于典型的数据科学家队列，预期存在长时间运行的查询，请设置 QMR 以限制提交到队列并在队列中等待的查询数量。

要开始使用 QMR，Amazon Redshift 提供了准备好的模板，您只需为每个 QMR 自定义阈值。有关详细信息，请参阅查询监控规则模板。

最初，您可以使用log操作记录各种规则。每周与用户社区进行定期交流，审查已记录的查询并提供调整查询的手段。如果没有改善，然后可以在提醒用户后将操作更改为abort。

使用以下 SQL 示例 5-7 揭示数据仓库过去七天的使用模式，这可以帮助您确定最佳的 WLM 配置设置。该查询将按服务类别（也称为工作负载队列）和每小时数据展示Select、UPDATE、INSERT、DELETE、CURSOR、CACHED、COPY、UNLOAD、VACUUM 和 SYSTEM 在您的数据仓库上执行的查询。

示例 5-7. 工作负载队列详细信息

SELECT
  service_class,
  query_hour,
  TO_CHAR(
    MAX(CASE WHEN query_type = 'SELECT' THEN qry_cnt ELSE NULL END),
      '999,999') AS "select_query_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'SELECT' THEN exec_s ELSE NULL END),
      '999,999') AS "select_exec_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'SELECT' THEN queue_s ELSE NULL END),
      '999,999') AS "select_queue_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'INSERT' THEN qry_cnt ELSE NULL END),
      '999,999') AS "insert_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'INSERT' THEN exec_s ELSE NULL END),
      '999,999') AS "insert_exec_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'INSERT' THEN queue_s ELSE NULL END),
      '999,999') AS "insert_queue_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'UPDATE' THEN qry_cnt ELSE NULL END),
      '999,999') AS "update_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'UPDATE' THEN exec_s ELSE NULL END),
      '999,999') AS "update_exec_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'UPDATE' THEN queue_s ELSE NULL END),
      '999,999') AS "update_queue_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'DELETE' THEN qry_cnt ELSE NULL END),
      '999,999') AS "delete_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'DELETE' THEN exec_s ELSE NULL END),
      '999,999') AS "delete_exec_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'DELETE' THEN queue_s ELSE NULL END),
      '999,999') AS "delete_queue_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'CURSOR' THEN qry_cnt ELSE NULL END),
      '999,999') AS "cursor_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'CURSOR' THEN exec_s ELSE NULL END),
      '999,999') AS "cursor_exec_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'CURSOR' THEN queue_s ELSE NULL END),
      '999,999') AS "cursor_queue_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'CACHED' THEN qry_cnt ELSE NULL END),
      '999,999') AS "cached_query_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'COPY' THEN qry_cnt ELSE NULL END),
      '999,999') AS "copy_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'COPY' THEN exec_s ELSE NULL END),
      '999,999') AS "copy_exec_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'COPY' THEN queue_s ELSE NULL END),
      '999,999') AS "copy_queue_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'UNLOAD' THEN qry_cnt ELSE NULL END),
      '999,999') AS "unload_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'UNLOAD' THEN exec_s ELSE NULL END),
      '999,999') AS "unload_exec_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'UNLOAD' THEN queue_s ELSE NULL END),
      '999,999') AS "unload_queue_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'VACUUM' THEN qry_cnt ELSE NULL END),
      '999,999') AS "vacuum_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'VACUUM' THEN exec_s ELSE NULL END),
      '999,999') AS "vacuum_exec_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'VACUUM' THEN queue_s ELSE NULL END),
      '999,999') AS "vacuum_queue_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'OTHER' THEN qry_cnt ELSE NULL END),
      '999,999') AS "system_query_count",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'OTHER' THEN exec_s ELSE NULL END),
      '999,999') AS "system_exec_seconds",
  TO_CHAR(
    MAX(CASE WHEN query_type = 'OTHER' THEN queue_s ELSE NULL END),
      '999,999') AS "system_queue_seconds"
FROM
    (SELECT
      NVL(w.service_class,14) service_class,
      CASE
        WHEN w.query IS NULL
            THEN 'CACHED'
        WHEN q.userid = 1
            THEN 'OTHER'
        WHEN REGEXP_INSTR("querytxt", '(padb_|pg_internal)')
            THEN 'OTHER'
        WHEN REGEXP_INSTR("querytxt", '[uU][nN][dD][oO][iI][nN][gG]')
            THEN 'OTHER'
        WHEN REGEXP_INSTR("querytxt", '[uU][nN][lL][oO][aA][dD] ')
            THEN 'UNLOAD'
        WHEN REGEXP_INSTR("querytxt", '[cC][uU][rR][sS][oO][rR] ')
            THEN 'CURSOR'
        WHEN REGEXP_INSTR("querytxt", '[fF][eE][tT][cC][hH] ')
            THEN 'CURSOR'
        WHEN REGEXP_INSTR("querytxt", '[dD][eE][lL][eE][tT][eE] ')
            THEN 'DELETE'
        WHEN REGEXP_INSTR("querytxt", '[cC][oO][pP][yY] ')
            THEN 'COPY'
        WHEN REGEXP_INSTR("querytxt", '[uU][pP][dD][aA][tT][eE] ')
            THEN 'UPDATE'
        WHEN REGEXP_INSTR("querytxt", '[iI][nN][sS][eE][rR][tT] ')
            THEN 'INSERT'
        WHEN REGEXP_INSTR("querytxt", '[vV][aA][cC][uU][uU][mM][ :]')
            THEN 'VACUUM'
        WHEN REGEXP_INSTR("querytxt", '[sS][eE][lL][eE][cC][tT] ')
            THEN 'SELECT'
        ELSE 'OTHER'
      END AS query_type,
      DATEPART(hour, q.starttime) AS query_hour,
      COUNT(1) AS qry_cnt,
      ROUND(SUM(w.total_exec_time)::NUMERIC/1000000,0) AS exec_s,
      ROUND(SUM(w.total_queue_time)::NUMERIC/1000000,0) AS queue_s
    FROM
        stl_query     q
    LEFT
    JOIN stl_wlm_query w
      ON q.userid = w.userid
     AND q.query = w.query
    WHERE
      q.endtime >= DATEADD(day, -7, CURRENT_DATE)
    AND q.userid > 1
    AND NVL(w.service_class,14) > 4
    GROUP BY
      service_class,
      query_type,
      query_hour
  )
GROUP BY
  service_class,
  query_hour
ORDER BY
  service_class,
  query_hour;

自动 WLM

自动 WLM 是启动 Amazon Redshift 时启用的默认模式。使用自动 WLM，您让 Amazon Redshift 动态地自动分配总插槽数和内存到每个插槽。您可以创建最多八个队列，服务类别标识符为 100 到 107. 您为每个队列分配从最低到最高的优先级，如果有查询在多个队列之间争夺资源，则优先级较高的查询将优先于优先级较低的查询，以确保最重要的查询不会被较不重要的查询耗尽资源。在执行资源密集型查询时，您希望较低的并发性和每个查询更多的内存，反之，当执行较轻的查询时，您希望更高的并发性以执行更多的查询。自动 WLM 的关键目的是在任何时间点容纳和执行尽可能多的查询。

虽然在 AWS 控制台中未显示，但无服务器数据仓库使用自动 WLM 确保为每个查询分配适合其需求的资源。

自动 WLM 尊重您为队列关联的优先级，并相应地优先处理优先级较高的查询。因此，您必须确保将业务优先级与队列优先级关联起来。例如，假设业务优先级是获取最新数据，那么可以定义 ETL 队列的优先级高于报告队列。Amazon Redshift 将根据正在执行的查询的相对大小需要调节集群并发性。如果正在执行重型 ETL 查询，Amazon Redshift 将检测到每个查询的高资源需求，并减少同时运行的查询数。相反，当执行较轻的仪表板查询时，Amazon Redshift 将检测到每个查询的低资源需求，并增加同时运行的查询数。您还可以为每个队列启用并发扩展，并通过扩展您的集群实现更高的吞吐量。如果您的集群正在执行所有较高优先级查询和新查询，则在没有并发扩展的情况下，这些新查询将必须等待当前查询完成。

Amazon Redshift 提供了六种优先级，如下所列：

1. 最低

2. 低

3. 普通

4. 高

5. 最高

6. 临界

您可以将前五个任意关联到 WLM 队列。关键优先级只能由超级用户在查询或会话级别应用。只有一个查询可以以关键优先级执行。

默认情况下，自动 WLM 定义了五个重型槽和五个轻型槽。重型槽分配了集群内存的 95%，轻型槽获得剩余的 5%内存。随着工作负载查询的到来，这些槽会被利用，并在需要时创建更多槽。较少的槽意味着每个槽的内存增加，这对于重型查询是有利的；而更多的槽意味着减少每个槽的内存，适用于轻型查询。五个轻型槽专门为短时间运行的查询保留，而重型查询无法使用这些槽。但是，如果五个重型槽空闲，轻型查询可以使用这些槽。

您可以查询未记录的视图 stl_wlm_auto_concurrency，以了解有关自动 WLM 并发性的信息。

示例 5-8. 检查自动 WLM 并发性

select
  now,
  heavy_slots AS hs,
  heavy_queries_finished AS hqf,
  heavy_queries_exec_time AS hqe,
  heavy_queries_queued AS hqq,
  light_slots AS ls,
  light_queries_finished AS lqf,
  light_queries_exec_time_sec AS lqe,
  light_queries_queued AS lqq
FROM
  stl_wlm_auto_concurrency
WHERE
  NOW BETWEEN '2023-01-16 21:08:00' AND '2023-01-16 21:33:00'
ORDER BY 1;

now	hs	hqf	hqe	hqq	ls	lqf	lqe	lqq
1/16/23 9:09:53 PM	5	17	1.78	0	5	4	0.03	0
1/16/23 9:11:54 PM	20	411	683.69	12	5	96	14.73	10
1/16/23 9:13:55 PM	20	375	562.20	23	5	113	15.60	16
1/16/23 9:15:58 PM	17	418	552.47	11	5	152	21.61	18
1/16/23 9:19:00 PM	20	352	720.27	63	5	90	15.30	10
1/16/23 9:22:02 PM	20	445	757.10	44	5	119	17.91	38
1/16/23 9:24:03 PM	20	414	719.95	25	5	87	13.24	12
1/16/23 9:26:05 PM	20	356	335.15	13	5	98	6.45	9
1/16/23 9:28:06 PM	13	482	355.50	9	5	130	9.05	9
1/16/23 9:30:07 PM	10	217	183.45	1	5	91	6.33	0
1/16/23 9:31:08 PM	7	131	79.04	0	5	44	3.83	0
1/16/23 9:32:06 PM	5	27	33.81	0	5	8	1.43	0

如果高优先级查询需要资源而没有可用资源，则自动 WLM 有可能终止尚未开始返回数据的低优先级查询。

当您的工作负载动态变化且希望根据不同用户或工作负载的业务优先级来驱动工作负载时，建议使用自动 WLM。自动 WLM 可以最大化集群资源，并尽可能并发执行尽可能多的查询。强烈建议在使用自动 WLM 时设置 QMR，详见“查询监控规则”，以防止某个恶意查询耗尽所有资源。

手动 WLM

使用手动 WLM，你可以更好地控制每个查询的并发性和内存分配。如果你有一个需要 24-7 专用资源的工作负载，那么你可以使用手动 WLM。例如，当你有一个一直进行数据摄取的 ETL 流水线时，你可以设置一个分配了一定百分比内存的队列。与自动 WLM 类似，你可以创建最多八个手动 WLM 队列。主要区别在于你可以手动控制每个队列的槽位数量和分配的内存百分比。你可以创建八个队列，服务类别标识符为 6 至 13。建议在所有手动 WLM 队列中总共使用 15 个槽位。

手动 WLM 仅适用于专用数据仓库。无服务器数据仓库使用自动 WLM。

如果你的仓库有300 GiB内存，并且你已经为ETL队列设置了40%的内存，每个查询将分配300 x 0.40 / 3 = 40 GiB的内存。如果查询需要超过 40 GiB，那么查询将溢出到磁盘并且执行时间会变长。在手动 WLM 模式下，内存为每个队列槽位保留，如果超过定义的槽位的查询进来，它们将排队等待执行。要扩展每个队列分配的内存，你可以启用并发扩展。并发扩展针对每个队列启用，并且只有当特定队列填满时，查询才会路由到扩展集群。

在手动 WLM 模式下，一旦一个队列的所有槽位被占用，后续查询必须等待，即使另一个队列有可用的空闲槽位。

推荐在你非常熟悉工作负载并且希望最大程度控制集群资源时使用手动 WLM。但它可能导致资源利用率不高。具有非常一致和可重复工作负载的实例是手动 WLM 的候选者，但每次引入新的工作负载时，如果工作负载有定义的 SLA，应重新评估手动槽位和内存分配。如果新的工作负载没有严格的 SLA，则可以进入默认队列，并在执行时完成。

当你注意到自动 WLM 大量向磁盘溢出或者大量排队而系统可以使用更多槽位时，你应考虑使用手动 WLM。请注意，虽然手动 WLM 需要更多的管理工作，但它可能会提供更好的成本优化。在大量溢出的情况下，成本更高但更容易管理的选项是扩展集群。在不溢出但排队大量的情况下，一种选择是使用更多的并发扩展，但这可能会变得昂贵，因此手动 WLM 可以提供更好的成本优化。

如果您定义了手动 WLM 并且未分配 100% 的总内存，则 Amazon Redshift 将未分配的部分分配给需要更多内存的任何队列。这可以被视为一种混合 WLM 模式，在此模式下，您从每个队列的最小内存分配开始，并允许 Amazon Redshift 在您的手动设置之上进行一些自动内存分配。

表 5-1 总结了自动 WLM 和手动 WLM 的特性。

表 5-1. 自动 WLM 对比手动 WLM

特性	自动 WLM	手动 WLM	附加信息
定义队列优先级	是	否	队列优先级仅在自动 WLM 中可用。
定义队列并发性	否	是	队列中的槽位数量仅在手动 WLM 中可用。
定义队列内存分配	否	是	队列内存量仅在手动 WLM 中可用。
每个查询过度分配内存	否	是	如果您在手动 WLM 中定义的槽位过少。
每个查询过度分配内存	否	是	如果您在手动 WLM 中定义的槽位过多。
同时执行的最大查询数	动态	固定	在手动 WLM 中，所有队列定义的总槽位数是将执行的最大查询数。
按队列定义查询优先级	是	否	在手动 WLM 中，队列上的更多槽位意味着更低的优先级，而较少的槽位意味着更高的优先级。
查询溢出到磁盘	较低	较高	自动 WLM 通过限制并发性来允许更少的查询，因此更多的内存被分配给每个查询。在手动 WLM 中，您必须基于每个查询分配更多的槽位。
定义短查询时间	自动	是	在手动 WLM 中，您可以选择 1 到 20 秒之间的时间。
QMR 操作：跳跃	否	是	WLM 会根据 WLM 队列分配规则尝试将查询路由到下一个匹配的队列。但是，如果没有匹配到其他队列定义，则查询会被取消，而不会分配到默认队列。
并发扩展 (CS)	CS 集群使用自动 WLM	CS 集群限制为 5 个槽位	如果启用了多个 CS 集群，则可以为主集群创建额外的集群。

WLM 的目标是管理在您的数据仓库上执行的查询的资源。您可以查询 Amazon Redshift 系统表以分析您的工作负载，并相应地设置 WLM 配置。

使用查询 示例 5-9 来查看每小时的查询执行统计信息。

示例 5-9. 每小时查询执行统计

SELECT DATE_TRUNC('hour',starttime) AS start_hour
     , MIN(starttime)               AS first_query_start_time
     , MAX(starttime)               AS last_query_start_time
     , COUNT(*)                     AS query_count
FROM stl_query
WHERE userid > 1
GROUP BY start_hour
ORDER BY start_hour DESC
;

使用查询 示例 5-10 来了解每个队列或服务类的峰值内存。注意，您还可以按 service_class_start_time 列过滤特定日期和时间范围。

示例 5-10. 峰值内存估算

SELECT
    w.service_class,
    COUNT(*) query_count,
    ROUND(PERCENTILE_CONT(0.25)
      WITHIN GROUP
        (ORDER BY est_peak_mem)/1024²,0)::INT AS prcntl25_mb,
    ROUND(PERCENTILE_CONT(0.50)
      WITHIN GROUP
        (ORDER BY est_peak_mem)/1024²,0)::INT AS prcntl50_mb,
    ROUND(PERCENTILE_CONT(0.75)
      WITHIN GROUP
        (ORDER BY est_peak_mem)/1024²,0)::INT AS prcntl75_mb,
    ROUND(PERCENTILE_CONT(0.90)
      WITHIN GROUP
        (ORDER BY est_peak_mem)/1024²,0)::INT AS prcntl90_mb,
    ROUND(PERCENTILE_CONT(0.95)
      WITHIN GROUP
        (ORDER BY est_peak_mem)/1024²,0)::INT AS prcntl95_mb,
    ROUND(PERCENTILE_CONT(0.99)
      WITHIN GROUP
        (ORDER BY est_peak_mem)/1024²,0)::INT AS prcntl99_mb,
    ROUND(MAX(est_peak_mem)/1024²,0)::INT AS p100_mb
FROM stl_wlm_query w
WHERE w.userid > 1
GROUP BY w.service_class
ORDER BY w.service_class
;

如果您需要确保多个工作负载同时执行，并且不能为这些工作负载队列设置不同的优先级，那么您有两个选择。一个选项是使用手动 WLM，第二个选项是创建两个单独的集群，从而隔离这两个工作负载，并在每个集群上使用自动 WLM 进行数据共享。通过第二种方法，您可以最大化每个工作负载在其自己隔离的集群上的吞吐量，并仍然确保资源的充分利用。第七章 对此进行了详细讨论。

参数组

参数 是设置的一个值，例如 auto_mv，可以是 true 或 false。而 参数组 则是这些参数的集合（参见 图 5-4）。参数组仅适用于预置数据仓库。参数组适用于与参数组关联的集群上的所有数据库。Amazon Redshift 自带一个无法编辑的默认参数组，但您可以创建一个新的参数组并自定义数据库设置。

您可以创建多个参数组，每个参数组具有不同的数据库参数设置值。您可以将参数组关联到一个或多个集群。通过修改参数组，您可以更改使用相同参数组的所有集群的配置。某些 WLM 属性是静态的，需要重新启动，而其他属性是动态的，并立即生效。

在 示例 5-11 中，您可以看到如何使用 modify-cluster CLI 命令来更改参数组。

示例 5-11. 修改集群的 AWS CLI 命令

aws redshift modify-cluster
  --cluster-identifier mycluster01
  --cluster-parameter-group-name pg_bi

您可以为写重的 ETL 工作负载设置一个参数组，并为读重的 BI 工作负载设置另一个参数组。如果在这两个参数组中仅仅选择动态属性，则可以有效地在不需要重新启动的情况下将集群从一种配置切换到另一种配置。这种策略被应用于基于 ETL/BI 时间窗口配置您的集群，尽管自动 WLM 会动态地为您执行此操作。

WLM 动态内存分配

在每个队列中，WLM 创建与队列设置的并发限制相同数量的槽。然后，分配给队列的内存会按照每个槽平均分配。如果更改了内存分配或并发性，Amazon Redshift 将动态管理向新 WLM 配置的过渡。活动查询继续使用已经分配的内存直至完成。

工作负载管理器执行以下步骤进行转换：

1. 计算每个槽的新内存分配。

2. 空闲槽释放其先前分配的内存。

3. 活动槽在查询完成并随后释放关联内存时执行。

4. 只要有足够的内存可用，新的槽就会立即添加。

5. 一旦所有先前运行的查询完成，新的 WLM 配置的过渡就完成了，插槽数等于新的并发级别。

实际上，在发生变化时正在运行的查询继续使用原始的内存分配。当变化发生时排队的查询将被路由到新的插槽，随着可用的插槽变多。由于亚马逊 Redshift 的内存分配的动态特性，您可以在参数组中更改 WLM 队列的内存分配百分比，而无需重新启动。

物化视图

物化视图（MV）是加速资源密集型连接查询的强大工具，这些查询具有重复性和可预测性。典型用例包括具有昂贵连接和聚合的仪表板查询。物化视图存储基础查询的结果。这与普通数据库视图不同，后者仅存储查询定义，每次访问视图时执行视图查询。

亚马逊 Redshift 查询优化器会自动识别可以使用的现有物化视图以满足请求。然后透明地重写请求以使用物化视图。查询直接访问物化视图，而不是底层详细表。这种自动查询重写功能意味着一旦编写应用程序查询，就无需更改即可利用新创建的 MV。

MV 可以建立在其他 MV 之上，因此允许您为不同的聚合级别创建不同的 MV，因此可以使用一个或另一个 MV 更快地满足最终用户查询的任何聚合形式。请注意，刷新 MV 不是一个级联过程，因此应从最深的 MV 开始刷新，并保持 MV 向上工作刷新。

MV 保持截至其上次刷新时间戳的数据点。亚马逊 Redshift 支持快速增量刷新，它跟踪基表的变化并仅拉取受影响的记录。如果一个 MV 不符合增量刷新条件，则在刷新时将完全重新计算。您可以在加载基表后立即刷新 MV，以确保 MV 始终具有最新结果，并始终可以使用自动查询重写功能提供查询结果。

以下表提供有关 MV 的关键信息：

STV_MV_INFO 表

每个 MV 的行，无论数据是否过时，以及其状态信息

STL_MV_STATE 视图

每个物化视图的每个状态转换都包含一行

SVL_MV_REFRESH_STATUS 视图

每个物化视图刷新活动的行

当从数据湖中的外部表查询外部表时，执行大表连接可能是一个昂贵的操作。一种优化技术是在 Amazon Redshift 中创建带有外部表聚合数据的物化视图。如果需要更深入的分析的行级数据，则可以通过外部表查询随时访问各个文件。

自主性

Amazon Redshift 的自动调整能力由机器学习赋予。Amazon Redshift 根据最佳实践为其许多架构设置建立智能默认值，并根据启发式自动调整物理数据布局。这些在本节中归入自主性的范畴。

表SVL_AUTO_WORKER_ACTION记录了 Amazon Redshift 执行的所有自动优化活动。

自动表优化器和智能默认值

自动表优化 是一种自动调整能力，通过应用排序和分布键自动优化表的设计，无需管理员干预。自动表优化器（ATO）会自动选择使用AUTO分布样式和排序键来定义您的表的最佳分布样式和排序键。

通过使用自动化调整表的设计，您可以更轻松地开始，并快速获得最快的性能，而无需投入时间手动调整和实施表优化。通常在表上定义的主键（PK）是一个没有重复项的高基数列，因此主键是作为分布键使用的一个良好候选项，并且智能默认算法会将其应用为表的自动分布键。

另外，即使主键尚未参与连接，Amazon Redshift Advisor 也会应用启发式方法来进行推荐。这将确保尽早做出推荐而不是之后。一旦有更多的工作负载数据可用，顾问可以做出更好的建议。具有复合主键的表，通常是事实表，不会基于启发式方法做出推荐，因为事实表的外键通常引用维表的主键，并且当存在多个维表时，根据工作负载中实际的连接来做出推荐更好。一旦可以分析这种工作负载模式，ATO 工作程序可能会选择在连接中最常使用的分布键。

如果选择了自动 DK，ATO 工作程序将实施的另一种优化是从基于 PK 的分布迁移到小表的 ALL 类型分布。这是一种有效的优化，因为通常维表在许多连接中使用，与事实表相比，行数较少。修改小表的分布样式可确保连接共同位置和更好的性能，例如使用 ALL 分布样式的日历维度。

自动真空

自动清理工作者后台进程执行两项任务。首先是自动清理删除，用于回收被前面的更新和删除操作标记为删除的行占用的磁盘空间。其次是自动清理排序，按照表格定义的排序关键列对物理数据块进行排序。如果一个表已经有 95%以上是排序的，那么自动清理工作者将跳过对该表的排序。

示例 5-12 查询提供了样本表格的无序度。

示例 5-12. 表格排序效益

SELECT
  "table",
  unsorted,
  vacuum_sort_benefit,
  tbl_rows,
  estimated_visible_rows
FROM
  svv_table_info
ORDER BY 1;

 table | unsorted | vacuum_sort_benefit | tbl_rows | estimated_visible_rows
-------+----------+---------------------+----------+----------------------
 sales |    85.71 |                   5 | 17686548 | 17601203
 event |    35.24 |                  67 | 27586582 | 27486080
(2 rows)

销售表格非常无序（86%），但从排序清理中获益很少（5%）。event表格相对较少无序（35%），但对查询的排序行为有很大的好处（67%）。

Amazon Redshift 每小时都会继续寻找执行清理的机会，而自动清理工作者的阈值基于用户查询占用的 WLM 槽位数量。只要超过一半的 WLM 槽位可用，自动清理工作者将分配自身 100 MB 的内存，加载表格的 100 个数据块，并开始操作。每次迭代后，它会评估 WLM 状态并继续另一批处理。如果用户查询到达并且超过 50%的 WLM 槽位被用户查询占用，则自动清理工作者将终止。任何部分完成的工作将被丢弃，下次自动清理工作者将重新分配 100 MB，但之前完成的工作将被保存。相比之下，如果用户发出VACUUM命令，则同一清理工作者将开始工作，但这次不会检查 50%的 WLM 槽位，而是会一直执行清理工作直至完成。

recluster选项对部分无序的表格进行排序。已经通过自动清理排序的表格部分将保持不变。该选项不会将新排序的数据与已排序区域合并，也不会回收所有标记为删除的空间。如果你有频繁的数据导入，并且查询只访问最新数据，那么使用recluster选项。

用户查询可以在自动或手动清理过程中访问表格。在表格被清理时，你可以执行select和insert操作，但如果在清理过程中运行update或delete，那么VACUUM和update或delete操作可能会花费更长时间。

如果需要为特定表格优先进行清理，并且有空闲的计算资源，那么使用BOOST选项，它会为清理操作分配多个槽位，以便更快地完成。

如果一个大表格非常无序，那么深拷贝可能比空操作更快，因为深拷贝一次性操作整个表格，而空操作则分块进行。这也意味着在深拷贝操作期间，你的存储空间会加倍。

提供了表格my_tbl的深拷贝示例，详见示例 5-13。

示例 5-13. 深拷贝

CREATE TABLE new_tbl (LIKE my_tbl);
INSERT INTO new_tbl (SELECT * FROM my_tbl);
DROP TABLE my_tbl;
ALTER TABLE new_tbl rename TO my_tbl;

在insert步骤期间对my_tbl进行的任何数据更改对深度复制操作不可见。因此，在深度复制操作期间，您需要跟踪更改并自行应用它们。更好的选择是在最小或无活动期间执行此操作，例如您的计划维护窗口。

自动真空排序

自动真空排序通过表的定义排序键列保持表数据按排序顺序排列。它还检查 50%的 WLM 槽空闲情况，并在可用时从 WLM 借用 3 GB 内存。然后在数据块中执行物理数据排序，并与自动真空工作器协同工作。它通过分析查询模式使用机器学习优先对表的哪些块进行排序。如果明确在给定表上运行真空排序有益处，则 Amazon Redshift Advisor 将提供建议。请参考示例 5-12 获取真空排序的效益。

自动分析

自动分析工作器生成或更新用于选择更好查询性能的最佳查询执行计划的表统计元数据。在数据仓库空闲且超过 10 分钟无活动时运行。自动分析是增量进行的，用户发出的分析命令将自动跳过已经是最新统计数据的表。

典型的数据仓库表具有许多列，这些列主要在SELECT子句中使用，而在JOIN和FILTER中使用的列相对较少。使用分析命令选项PREDICATE COLUMNS来分析仅在查询中用作谓词的列，例如分布键列、排序键列以及在JOIN、FILTER或GROUP BY子句中使用的列。此选项通过收集对查询性能影响最大的列的统计信息提供最大的收益。如果没有列被标记为谓词列，例如因为尚未查询表，则将分析所有列，因此这是一个非常安全的默认使用选项。

Amazon Redshift 会自动在使用CREATE [TEMP] TABLE AS或SELECT INTO命令创建的表上运行分析。默认的分析阈值是更改的行数的 10%。但您可以选择在会话级别设置不同的分析阈值来微调此行为。

您可能希望在 ETL 的一部分明确分析表，当后续步骤可以从最新的统计数据中获益时，或者当 Amazon Redshift 没有自动分析因为您的数据仓库被大量使用且没有空闲时段来运行自动分析后台任务时。

自动物化视图（AutoMV）

我们在 “物化视图” 中介绍了物化视图的用例，AutoMV 功能现在根据其内置的 ML 算法识别查询模式来构建、刷新和删除 MV。您的最终用户查询无需更改，因为 Amazon Redshift 会无缝地从 MV 中获取结果，以提供更快的查询响应时间。

Amazon Redshift 使用一种称为谓词提升的技术来通过将用户查询中的过滤列移动到 AutoMV 的 GROUP BY 子句中，从而创建通用的自动化物化视图。因此，Amazon Redshift 在物化视图中存储完整的数据范围，允许类似的查询使用同一个物化视图。这种方法是由仪表板样式的工作负载驱动的，这些工作负载经常发出具有不同过滤谓词的相同查询。

Amazon Redshift 应用 AI 来计算哪个候选物化视图提供最佳的性能优势和系统范围的性能优化。此外，它还计算创建和维护候选 MV 所需的系统资源成本。现有的手动物化视图也会被考虑在内，如果已经存在一个覆盖相同范围的手动物化视图，则不会创建 AutoMV。手动物化视图具有比 AutoMV 更高的自动刷新优先级。同时，与高优先级队列上的查询相关的 AutoMV 将优先于与低优先级队列上的查询相关的 AutoMV。创建的 AutoMV 然后由后台进程监控其活动，例如它们被查询和刷新的频率。如果 Amazon Redshift 确定一个 AutoMV 没有被使用或刷新，例如由于基表结构的变化或查询模式的变化，则该 AutoMV 会被自动删除。

AutoMV 的刷新由后台自动处理。如果由于某些原因 Amazon Redshift 无法刷新 AutoMV，则将其标记为过时，并且不用来提供查询结果。稍后，当刷新完成后，AutoMV 再次用于查询。

Amazon Redshift 顾问

Amazon Redshift 顾问就像拥有一位全天候的数据库管理员，监视您的工作负载并为您提供与操作和数据仓库设置相关的具体建议，以改善仓库的吞吐量并节省运营成本。它还优先考虑建议并按照对工作负载性能影响的顺序对其进行排名。

亚马逊 Redshift Advisor 的建议是基于对您特定工作负载的性能统计和操作数据的观察。它通过在您的数据仓库上运行测试来生成建议，以确定疑似值是否在指定范围内。如果测试结果超出该范围，Advisor 会为您的数据仓库生成建议。同时，Advisor 提供可行的步骤，帮助将偏离值调整回最佳实践范围。Advisor 仅显示对性能有显著影响的建议。一旦您处理了建议，它还会从您的建议列表中删除建议。

参见亚马逊 Redshift Advisor关于如何处理来自亚马逊 Redshift Advisor 的建议的最佳实践。

目前它涵盖了以下主题：

• 通过COPY压缩亚马逊 S3 文件对象

• 隔离多个活动数据库

• 重新分配工作负载管理（WLM）内存

• 在COPY期间跳过压缩分析

• 通过COPY加载分割亚马逊 S3 对象

• 更新表统计信息

• 启用短查询加速

• 在表上修改分布键

• 在表上修改排序键

• 在列上修改压缩编码

• 数据类型建议

每个建议都附带进行的分析、分析的数据时间范围，以及要实施建议的查询或列出受影响对象的查询。

如果您看不到建议，并不一定意味着您当前的表设置是最合适的。当数据不足或者预期的变更效益较小时，Advisor 不会提供建议。

Advisor 运行的时间不受用户控制。当您的数据仓库不忙时，Amazon Redshift 可以利用一些空闲周期和资源来执行其分析。这类似于您的数据仓库非常繁忙时，自动调整活动如自动清理、自动表优化（ATO）和自动分析可能不会运行。

截至 2022 年，亚马逊 Redshift Advisor 需要在表上执行至少 100 个查询才能提出建议。这一要求将来会放宽，您将更早地看到建议。

工作负载隔离

工作负载 是由团队、部门或群组运行的一组查询。为了能够在单个亚马逊 Redshift 集群上支持多个工作负载，您需要设计工作负载隔离。工作负载隔离 是如何确保一个工作负载不会以影响其他工作负载执行方式消耗资源。您已经看到之前 WLM 队列和相关的 QMR 如何提供控制和工作负载隔离的方法。在这些情况下，一个集群的资源被多个用户工作负载共享。这样的设计可能会导致冲突，特别是如果每个工作负载由不同团队拥有，并且这些团队被迫共享单个集群的资源。您只能定义八个队列，对于复杂的多用户工作负载，八个队列可能不足以进行隔离。

使用数据共享功能，您可以通过将工作负载隔离到其自己的亚马逊 Redshift 数据仓库中，实现更高的工作负载隔离和更紧密的资源分配控制。然后，每个仓库可以实施自己的 WLM 队列并进一步分配计算资源。您甚至可以基于工作负载的持续时间混合和匹配预配和无服务器数据仓库，并且由生产者共享的相同数据可以有多个消费者。请参考第七章了解更多关于如何使用数据共享来进行工作负载隔离的信息。

为实现最佳价格和性能的额外优化

当前的分析环境非常苛刻，工作负载随着时间推移不断演变，数据量也在持续增加。"自动化" 讨论了亚马逊 Redshift 通过自动化更多任务来简化操作。以下是一些考虑因素，您可以优化数据仓库，实现最佳价格和性能的平衡。

数据库与数据仓库

考虑您的数据量，并评估适合 GB 级数据量的亚马逊 Aurora，甚至用于分析工作负载。亚马逊 Redshift 适合处理大数据量，并且对于较小的工作负载来说成本较高。对于对查询响应时间要求较为宽松的工作负载，甚至可以考虑将最终转置的分析数据转移到亚马逊 S3 数据湖中，使用 Parquet 等开放格式，并利用亚马逊 Athena 的查询功能。

亚马逊 Redshift 无服务器

如果您尚未使用亚马逊 Redshift 无服务器，当难以预测计算需求时，这是一个不错的选择，因为您具有可变的工作负载、周期性的工作负载和间歇空闲时间的峰值。亚马逊 Redshift 无服务器会根据查询模式的变化自动扩展，随着更多并发用户和新工作负载的出现。只有在执行用户数据上的用户查询时，您才会收到计算费用；对元数据或系统表执行的查询是不计费的。

如果您正在分析数据集，那么 Amazon Redshift 无服务器提供了一种快速简便的方式，无需选择或配置适当的集群配置即可开始。在无服务器环境下，您的计算设置以 Redshift 处理单元（RPU）为单位，这相当于某种处理器和内存配置。无服务器设置了默认的 RPU，您可以根据工作负载需求更改默认值。无服务器会根据传入的工作负载自动调整 RPU 的规模。与维护调整到性能的预配置集群相比，自动扩展 RPU 的好处可能更胜一筹。

多仓库环境

与试图管理一个巨大的集群相比，将数据仓库环境分解为许多较小的数据仓库可能更有利。除了工作负载隔离外，您还可以获得预算、会计和所有权的细粒度。每个团队、部门和组织单位都可以独立地根据其用例大小和付费计算，并利用数据共享来民主化其数据。

Amazon Redshift 支持使用数据共享功能设置多仓库环境，既可以是预配置的数据仓库，也可以是无服务器数据仓库。生产者和消费者可以是预配置或无服务器的。这种灵活性结合 AWS Lake Formation 集成所有数据目录、数据访问和数据治理，将使您的组织能够轻松快速地在整个组织中构建数据网格架构；详情请参阅AWS 博客。

AWS 数据交换

AWS 数据交换通过统一计费，使您轻松获取所需数据。您可以搜索所有列出产品的目录，并按行业、供应商或交付方式进行过滤。AWS 数据交换（ADX）提供免费和付费订阅选项，供您在订阅之前先尝试数据。它还提供公共定价和私人定价协议，以便您在购买之前就可以协商产品的条款和条件。ADX 将在订阅到期后自动撤销访问权限，因此数据提供者和数据消费者都可以确保只有授权的数据产品可访问。您还可以通过创建 ADX 数据共享并将其列为 AWS 市场上的产品来获取 Amazon Redshift 数据的收益。

如果您的工作负载需要第三方数据，则应利用 ADX 简化数据采购过程。您可以从 Amazon S3 文件、Amazon Redshift 数据共享或通过 API 获取实时数据。详情请参阅AWS 数据交换。

表设计

如果您从其他数据库迁移到 Amazon Redshift，则应特别注意这两种技术之间的技术差异。

在选择关键分布样式时，您仅限于单列。如果您的表在多列上进行连接，则可以创建一个新列，其中包含所有原始连接列的连接数据，并将其用作分布键。如果基础列包含可变长度字符串字段，则对连接结果进行哈希处理以获得固定长度的列作为分布键。这将确保联合连接位于同一位置，最小化节点间数据移动，从而提供最佳性能。

Amazon Redshift 已自动化大部分数据架构方面的工作，因此您无需过多担心表设计。但这是基于机器学习的，并且需要数据来推断，因此在 Amazon Redshift 为您调整表之前会有一定的滞后。遵循表设计最佳实践，以便从数据仓库旅程的最开始就获得良好的性能。

索引与区域映射

Amazon Redshift 不提供索引或表分区。它使用区域映射来定位数据，区域映射是每个数据块的最小和最大列值。当数据排序时，区域映射最为有效。对于小表，您可以跳过定义排序键。对于具有均匀分布样式的大表，选择最频繁过滤的列作为排序键。如果使用关键分布，则可以将连接列指定为排序键和分布键，从而实现更快的排序合并连接。

驱动程序

始终使用最新的驱动程序来自 Amazon Redshift，以便跟上提供的最新功能。如果您的第三方软件为 Amazon Redshift 提供自己的驱动程序，则使用该驱动程序。仅在您的工具需要特定版本的驱动程序时才使用 Amazon Redshift 的先前版本驱动程序。

简化 ETL

利用类似Amazon Redshift 联合查询的功能简化 ETL，直接利用运营数据或将其复制到数据仓库，并实施 ELT 方法。为了减少网络数据传输并提高性能，Amazon Redshift 直接将联合查询的部分计算分布到远程操作数据库中。

Amazon Redshift 与 Apache Spark 集成使得在 Amazon Redshift 上构建和运行 Spark 应用程序变得容易。您的 Spark 应用程序可以读取和写入您的 Amazon Redshift 数据仓库，同时利用 Amazon Redshift 的推送优化，无需牺牲数据的事务一致性或性能。

如果您要加载来自 Amazon Aurora 的整个事务数据到 Amazon Redshift 进行分析，则可以利用Amazon Aurora 与 Amazon Redshift 零 ETL 集成的功能。这种零 ETL 是一种存储级别的复制机制，比从源到目标的导出或复制行更有效率。

查询编辑器 V2

Amazon Redshift 查询编辑器 V2 是一个完全托管的 SQL 编辑器，可以在您的浏览器中使用。随着用户社区的增长，它会自动扩展。无需安装桌面软件，并减少运行第一个查询所需的步骤。作为额外的团队可扩展功能，它通过保存的查询和共享结果以及用户之间的分析来提高协作。

在本章中，您已经学习了如何扩展您的 Amazon Redshift 数据仓库，如何设置工作负载管理，并优化工作负载的最佳价格和性能。

查询调优

Amazon Redshift 使用基于结构化查询语言（SQL）的查询与系统中的数据和对象交互。数据操作语言（DML）是您用来查看、添加、更改和删除数据的 SQL 的子集。数据定义语言（DDL）是您用来添加、更改和删除数据库对象（如表和视图）的 SQL 的子集。在我们深入了解查询写作的最佳实践和优化查询性能之前，让我们先了解一下 Amazon Redshift 如何处理查询。

查询处理

所有提交到 Amazon Redshift 的查询都首先被解析，然后优化器开发查询执行计划（参见 图 5-6）。

每个查询的三个步骤是：

1. 查询规划

2. 查询编译

3. 查询执行

图 5-6. Amazon Redshift 查询处理

查询规划和执行工作流程

Amazon Redshift 领导节点接收查询并解析 SQL 查询。报告任何语法错误，如果解析成功，则解析器生成原始查询的逻辑表示。这个初始查询树被发送给查询优化器。

查询优化器评估查询，分析表统计信息以确定连接顺序和谓词选择性，并重新编写查询以最大化其效率。查询优化器生成描述执行顺序和网络操作以及示例连接类型、连接顺序、聚合选项和数据分布要求的查询计划。优化后的查询计划然后作为输入提交给执行引擎。

执行引擎首先检查编译缓存以查找查询计划匹配项。如果找不到匹配项，则执行引擎将查询计划转换为步骤、段和流。执行引擎基于步骤、段和流生成编译后的 C++ 代码，如 图 5-7 所示。编译后的代码被添加到缓存中，然后广播到计算节点。

图 5-7. Amazon Redshift 查询步骤

计算节点切片并行执行查询段。当计算节点完成执行后，它们将查询结果返回给领导节点进行最终处理。领导节点将从计算节点合并结果到单一结果集，并在返回给查询提交者之前进行任何必要的排序或聚合。

查询阶段和系统表

现在我们将详细查看每个阶段及相关的系统表以捕获具体信息。

第 1 阶段：解析和验证

在查询规划期间，SQL 查询首先被解析和语法验证。如果查询有效，则生成查询树。此时，将在STV_RECENTS系统表中记录条目。此外，在此阶段，如果 Redshift 识别到可以缓存查询，将检查任何现有条目，并且如果找到，则结果将通过领导节点从 Redshift 缓存中获取并发送给客户端，而无需经过后续阶段。关于查询缓存的信息可以在SVL_QLOG系统表中找到。

第 2 阶段：查询请求锁定

然后，查询树被发送以获取锁。可以在STV_LOCKS系统表中找到 Redshift 集群的当前锁定状态。

第 3 阶段：规划器和优化器

获取锁之后，Redshift 优化器将查询重写为适合 Redshift 的最佳形式。此阶段的输出是计划树，与 PostgreSQL 兼容。在此阶段，查询计划将记录在STL_EXPLAIN中，而查询文本则记录在STL_QUERYTEXT系统表中。

第 4 阶段：WLM 调度器

计划生成成功后，查询进入 WLM 调度器。在这里，查询将等待队列槽位，一旦可用，将根据队列分配将其发送到执行。此阶段，查询在STV_WLM_QUERY_STATE系统表中记录详细的查询队列状态，并检查STV_WLM_QUERY_QUEUE_STATE系统表。

第 5 阶段：代码生成器/编译器

执行WLM槽位后，STV_INFLIGHT系统表中会记录一个条目。现在，Redshift 执行计划器将生成的计划树符合 Redshift 的分布式架构，即将查询分成流、段和步骤。完成后，段将被发送进行编译；在这里，我们可以检查SVL_COMPILE系统表，获取编译时间记录及每个查询段的位置。

第 6 阶段：分布

主节点将代码分发到计算节点。由于数据分布在各个片段中，流的所有段通过所有切片进行执行。一旦第一个流的段通过所有切片完成执行，第二个流的段将被执行。

阶段 7: 查询执行

计算节点执行计算并处理查询。在此阶段的查询执行信息可以在 STV_EXEC_STATE（处于运行状态时）和执行后的 SVL_QUERY_REPORT 以及 SVL_QUERY_SUMMARY 系统表中找到。

阶段 8: 最终计算/聚合

在此阶段，计算节点将结果发送给主节点。主节点执行最终计算并将结果发送回客户端。在此阶段之后，您可以在 STL_QUERY 和 STL_WLM_QUERY 系统表中找到查询信息。

阶段 9: 提交队列（如有需要）

查询进入提交队列。对于需要提交操作的查询（例如 DDL 命令），查询在返回结果给客户端之前会经历这个额外的阶段。此信息记录在 STL_COMMIT_STATS 中。在所有计算节点上执行提交操作后，LN 将结果发送给客户端。

要了解查询执行运行时的概述，请使用 SYS_QUERY_HISTORY 系统表。

缓存的编译代码在会话之间共享，因此即使使用不同的参数，对相同查询的后续执行也将更快。查询计划编译和编译代码的执行仅在每个流中执行一次。

理解查询计划

您可以运行 explain 命令来查看查询执行计划，如 示例 5-14 所示。它为执行引擎执行的操作提供信息。阅读计划是从底部到顶部，从内到外的最内步骤开始。您将看到每个操作中使用的表和列，以及每个操作中处理的数据量（以行数和字节的行宽表示）。您还会看到每个操作的成本。需要注意的是，这些成本并不提供关于实际执行时间或内存消耗的精确信息。查询优化器比较各种执行计划的成本，并选择最佳执行计划。每个步骤的成本指示了估计为每个给定查询中的特定操作消耗最多资源的情况。

示例 5-14. 查询执行计划

EXPLAIN
  SELECT AVG(DATEDIFF(day, listtime, saletime)) AS avgwait
  FROM sales, listing
  WHERE sales.listid = listing.listid
;

QUERY PLAN
----------------------------------------------------------------
XN Aggregate (cost=6350.30..6350.31 rows=1 width=16)
-> XN Hash Join DS_DIST_NONE (cost=47.08..6340.89 rows=3766 width=16)
   Hash Cond: ("outer".listid = "inner".listid)
 -> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=12)
 -> XN Hash (cost=37.66..37.66 rows=3766 width=12)
   -> XN Seq Scan on sales (cost=0.00..37.66 rows=3766 width=12)

XN Seq Scan 表示特定表上的顺序扫描操作符。Seq Scan 顺序扫描表中的每个选定列，从开头到结尾依次扫描，并评估在WHERE子句中指定的任何查询谓词，对于每一行扫描的情况。

成本显示为(cost=0.00..37.66 rows=3766 width=12)；这里显示了获取第一行和获取最后一行的成本；还显示了估计的行数和行宽度。

XN Hash 操作符用于创建连接中内表的哈希表。XN Hash Join 操作符用于内连接、左连接和右连接。哈希连接操作符读取外表，对连接列进行哈希处理，并在内部哈希表中查找匹配项。

成本显示为 XN Hash Join DS_DIST_NONE (cost=47.08..6340.89 rows=3766 width=16)；这里的 rows=3766 表示连接操作的预计行数。

请查看计划，以确定连接操作的行数是否在预期范围内。此处的数字过高可能表示缺少统计信息或缺少主键或外键约束。这些信息可以帮助查询规划器生成更好的行估计。

Amazon Redshift 还具有嵌套循环连接，主要用于交叉连接（笛卡尔积）和一些不等连接。

嵌套循环连接是 Amazon Redshift 中最不理想的连接方式。

Amazon Redshift 还具有合并连接（merge join），用于内连接和外连接，但不用于全连接。合并连接通常是最快的连接操作符，用于连接表，其中连接列既是分布键又是排序键，并且连接的表中不超过 20%未排序。

XN Aggregate 操作符用于涉及聚合函数和 GROUP BY 操作的查询。您可以查看聚合函数的查询执行计划，例如 示例 5-15。

示例 5-15。聚合操作符的查询执行计划

explain
SELECT eventname, sum(pricepaid) FROM sales, event
WHERE sales.eventid = event.eventid
GROUP BY eventname
ORDER BY 2 DESC;

QUERY PLAN
----------------------------------------------------------------
XN Merge (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
Merge Key: sum(sales.pricepaid)
-> XN Network (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
 Send to leader
 -> XN Sort (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
  Sort Key: sum(sales.pricepaid)
  -> XN HashAggregate (cost=2815366577.07..2815366578.51 rows=576 width=27)
   -> XN Hash Join DS_BCAST_INNER (cost=109.98..2815365714.80 rows=172456 width=27)
    Hash Cond: ("outer".eventid = "inner".eventid)
    -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=14)
    -> XN Hash (cost=87.98..87.98 rows=8798 width=21)
     -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=21)

图 5-8 显示了前述查询及其相关查询计划。它展示了查询操作如何映射到 Amazon Redshift 用于生成计算节点片段编译代码的步骤。每个查询计划操作映射到多个段内的多个步骤，有时也映射到流内的多个段。

图 5-8。Amazon Redshift 查询流

查询优化器按以下方式运行查询计划：

1. 在 Stream 0 中，查询运行 Segment 0，执行顺序扫描操作以扫描事件表。查询继续到 Segment 1，使用哈希操作创建连接中内表的哈希表。

2. 在 Stream 1 中，查询运行 Segment 2，执行顺序扫描操作以扫描销售表。它继续使用哈希连接操作执行 Segment 2，以连接不同时作为分布键和排序键的表。然后再次使用哈希聚合操作执行 Segment 2，以聚合结果。然后查询运行 Segment 3，使用哈希聚合操作执行无序分组聚合函数，并使用排序操作评估 ORDER BY 子句和其他排序操作。

3. 在流 2 中，查询在 Segment 4 和 Segment 5 中运行网络操作，将中间结果发送到领导节点进行进一步处理。

查询的最后一个段返回数据。如果返回集合是聚合的或排序的，则计算节点各自将它们的中间结果片段发送到领导节点。然后领导节点合并数据并将最终结果返回给查询提交者。

影响查询性能的因素

您的数据仓库和整体数据库操作的以下方面决定了查询执行速度：

节点数量

更多节点意味着更多的处理器和更多的切片，这使得您的查询可以通过在切片之间并行运行查询的部分来更快地处理，但您需要在性能和成本之间找到一个良好的平衡。

节点类型

Amazon Redshift 预置集群提供不同的节点类型，每种节点类型具有不同的大小和限制，帮助您适当扩展集群。这些节点类型确定了集群中每个节点的存储容量、内存、CPU 和价格。

数据分布

当您运行查询时，查询优化器根据需要将数据重新分配给计算节点以执行任何连接和聚合。为表选择合适的分布方式有助于通过将数据放置在连接执行之前的位置来最小化重新分配步骤的影响。

排序顺序

查询优化器和查询处理器使用数据位置信息来减少需要扫描的块数，从而提高查询速度。

数据集的容量

大数据量上的查询可能会影响查询性能，因为需要扫描和重新分配更多的行。定期运行 vacuum 操作、归档不经常查询的数据以及使用谓词限制查询数据集可以改善性能。

WLM 设置

每个查询操作占据一个或多个可用查询队列中的插槽，并使用与这些插槽相关联的内存。如果其他操作正在运行，则可能没有足够的查询队列插槽可用。在这种情况下，查询必须等待插槽开放才能开始处理。

代码编译

Amazon Redshift 为每个查询执行计划生成和编译代码，并为后续调用缓存此信息。首次生成和编译代码会产生一些额外开销。编译的代码段在集群上本地缓存和在一个几乎无限的缓存中。此缓存在集群重新启动后仍然存在。由于可以跳过编译阶段，因此后续执行相同查询的速度更快。

分析查询

如果查询花费的时间比预期长，您需要识别和纠正可能对查询性能产生负面影响的问题。有时候，本应快速运行的查询被迫等待另一个运行时间较长的查询完成。在这种情况下，您可以通过创建和使用不同类型查询的查询队列来提高整体系统性能。

查询警报审查

使用STL_ALERT_EVENT_LOG系统表来识别和纠正查询可能存在的性能问题。此表捕获查询的潜在问题，并提供建议的解决方案以解决警报。

分析查询计划

使用explain命令并分析查询计划。集中优化具有最高成本的步骤。查看正在执行的连接，merge是最好的；hash对于内部表来说是相当常见且可以接受的，而nested loop则应避免，除非是少量行或循环。

Amazon Redshift 选择较小的表进行内连接，并选择较大的表进行外连接。如果情况不同，则可能是表统计数据没有更新。

在连接步骤中，一个切片可能需要处理未本地存储的数据，而对于查询来说，网络传输远远是最昂贵的操作。

表 5-2. 分布连接

连接类型	描述
DS_DIST_NONE	这是理想的情况，表明连接数据位于同一切片上。这是最有效的选项，因为不会发生网络传输。
DS_DIST_ALL_NONE	表示正在使用DISTSTYLE ALL的表进行连接，并且不涉及网络传输。
DS_DIST_ALL_INNER	表示内部连接表由于使用了DISTSTYLE ALL而被发送到单个节点。这种连接在单个节点上执行，可能会很慢。
DS_DIST_INNER, DS_DIST_OUTER	表示在使用外部连接时重新分配哪个表（内部或外部表）；如果其中一个表要小得多或者更新不频繁，请考虑将其更改为DISTSTYLE ALL。
DS_BCAST_INNER	表示内部连接表正在广播到所有节点。
DS_BCAST_BOTH	表示连接中的两个表都正在广播到所有节点。这是最糟糕的选择。

识别性能调整的查询

表 5-2 中的前三个连接是您将看到最小性能下降的地方，因此如果发现频繁运行的查询或业务 SLA 属于最后三个，则这些查询是性能调整的良好候选。

让我们以一个交易公司的数据仓库为例，其主要有两个事实表，fact_executions 用于所有交易执行，fact_allocation 用于所有交易分配，如图 5-9 所示。较粗的线表示由于匹配的分布键而进行的共同分布连接。

图 5-9. 多事实模式

考虑到大多数情况下，您通过安全维度分析执行情况，而通过账户维度分析分配情况。请注意，安全维度仍然加入到分配事实，因为每个分配都是针对特定的交易安全性。

基于此设计，您的大多数执行报告将表现良好，因为您主要与安全维度连接。大多数您的分配报告也将表现良好，因为您主要与账户维度连接。但是，如果您需要对按安全性进行的分配进行一些分析，由于这不是一个共同分布连接，您将看到安全维度数据的重新分配。如果这种分析不经常进行，则其业务影响较小，可以容忍较慢的查询响应。但是，如果这种分析被视为业务关键并且有严格的 SLA 定义，则可能需要将安全维度更改为 ALL 的分布样式，以便分析，按安全性分配和按安全性执行成为共同分布连接。在这种情况下，为了满足性能需求，您可能需要为存储支付更多的费用。

并非所有的查询都需要或者可以为了性能而调优。根据查询的业务优先级，您需要权衡在调优上花费的时间和达到性能所需的成本。

此外，请参考 调优的前几名候选 来确定所有查询中的优先查询，数据倾斜或未排序行的表 来确定考虑不同分布策略和手动抽真空需求的候选表，嵌套循环的查询 来确定可能写得不好的查询和实施特定队列上的查询监控规则的候选者，查询等待时间 来确定更改 WLM 设置和利用并发扩展以减少队列等待的机会，查询警报 来确定表警报和修复查询建议，以及 缺失统计信息的表 来确定手动收集统计信息的表。

摘要

在本章中，我们涵盖了针对可预测需求的扩展以及处理不可预测的尖峰工作负载，介绍了如何设置工作负载管理和查询监控规则，以减少糟糕查询的影响范围，并保护您的亚马逊 Redshift 数据仓库。我们还讨论了如何利用材料化视图、亚马逊 Redshift 提供的各种自动化功能，以及如何使用数据共享功能实现工作负载隔离。本章最后讨论了在平衡价格性能和查询性能调优技术方面的优化，并介绍了如何识别和调优查询。

在下一章中，我们将涵盖机器学习。我们将描述数据科学家需要解决的不同问题集，以及他们应用的算法类型来解决这些问题。最后，我们将展示亚马逊 Redshift 如何通过提供工具来构建、训练和运行预测分析，解密预测分析过程，使数据科学家、数据工程师甚至数据分析师能够使用亚马逊 Redshift 进行预测分析。我们将展示用户如何直接使用 SQL 命令运行整个机器学习生命周期，以及高级用户如何将亚马逊 Redshift 与亚马逊 SageMaker 集成。

第六章：Amazon Redshift 机器学习

机器学习和人工智能已经从科幻概念发展为日常伴侣，无论是在您的移动设备上还是在赋予企业能力以颠覆和增强决策制定的各个领域。

根据 GlobalNewsWire 的研究，AI/ML 市场预计将在 2029 年发展成为一个 1.4 万亿美元的行业。 PwC 2022 AI Business Survey 显示，86% 的受访者表示 AI 技术是公司的主流部分，52% 的受访者正在加速对 AI/ML 的采用。

下面是一个公司利用 Redshift 的 AI/ML 能力改进业务的示例。Jobcase，一家领先的面向求职者的在线求职平台，需要为超过 1.1 亿注册会员进行职位匹配，通过识别强匹配项为其会员推荐优质工作。它还帮助雇主招聘合格的工人。其推荐系统生成特定的职位列表推荐，以及搜索建议和公司推荐。使用 AI/ML，Jobcase 能够在会员参与度指标上实现 5% 的改进，这转化为提升的会员体验、更高的会员保留率和相应的收入增长。他们还能将测试时间从 1 到 2 个月缩短到不到一周，消除了将数据移至单独的 ML 环境的需要，提高了可伸缩性，并能在约 15 分钟内进行数十亿次预测，而不是原来的 4 到 5 小时。详细信息请参阅案例研究 “Jobcase Scales ML Workflows to Support Billions of Daily Predictions Using Amazon Redshift ML”。

这里是另一个例子：Magellan Rx Management，Magellan Health, Inc. 的一个部门，开发并提供预测分析，以预测未来的药品成本，识别将推动未来趋势的药品，并积极识别可能变得不依从其药物治疗的患者，通过他们在 Amazon Redshift ML 上构建的 MRx Predict 解决方案。在使用 Amazon Redshift ML 之前，他们的数据分析师和临床医生需要手动将任何新药物分类到适当的治疗条件中。使用 Amazon Redshift ML，他们现在使用标准 SQL 编程进行预测，以预测适当的药物治疗条件，从而提高了操作效率，同时保持高水平的临床准确性。详细信息请参阅博客文章 “How Magellan Rx Management Used Amazon Redshift ML to Predict Drug Therapeutic Conditions”。

在本章中，我们将涵盖端到端的“机器学习周期”，以及“Amazon Redshift ML”如何为您的组织中的多个角色提供工具，以开始利用“机器学习技术”推动创新。我们还将深入探讨不同的“机器学习算法”，并通过一个示例向您展示如何使用“与 Amazon SageMaker Autopilot 集成”来预测人类与机器之间虚构街头竞赛的结果。我们还将继续使用我们的学生信息系统数据集，并解释“使用 Amazon Redshift ML 预测学生结果”。我们还将描述某些 ML 问题无法通过 Amazon SageMaker Autopilot 解决的情况。在这些情况下，您可以使用“Amazon SageMaker 与 Amazon Redshift 集成”通过 Amazon SageMaker 画布工具访问 Amazon Redshift 数据来构建您的模型。有了您的模型，您可以利用“与 Amazon SageMaker 集成—自带模型 (BYOM)”在 Amazon Redshift 中进行推断。最后，我们将介绍“Amazon Redshift ML 成本”。

机器学习周期

机器学习中涉及的典型步骤（图 6-1）包括以下步骤：数据收集，数据准备和清洗，ML 模型和算法选择，设置训练环境，训练 ML 模型，评估和调整 ML 模型，部署 ML 模型以供生产使用并进行扩展，最后进行预测以驱动业务决策。

您的 ML 模型的质量直接受您使用数据的质量影响。不正确或过时的数据将导致错误的结果或不相关的预测。因此，为构建 ML 模型准备数据涉及数据清理，以删除不需要的数据、缺失值、重复值，甚至转换某些属性的数据类型。您可能需要重新组织数据集并转置行和列或索引行和列。您还需要将数据集分割为用于训练和测试的数据集，以在训练后检查模型的准确性。一个好的训练数据集是相关的，包含最少的缺失和重复值，并提供各种子类/类别的良好表示。通过 Amazon Redshift ML，您可以利用已经清洗和验证的数据仓库数据作为构建 ML 模型的源数据。

图 6-1. 典型 ML 生命周期

一旦你有了用于机器学习的数据集，你需要选择一个用于训练的模型。机器学习模型决定了在收集的数据上运行机器学习算法后得到的输出结果。选择一个与你手头任务相关的模型至关重要。科学家和工程师们开发了各种机器学习模型，比如线性回归、决策树、最近邻、随机森林等等。这些模型适用于不同的任务，比如语音识别、图像识别、预测以及各种不同的用例。除了模型类型，你还需要根据数据是数值型还是分类型来选择适合的模型算法，然后据此进行选择。

一旦确定了模型类型，现在你需要设置模型训练环境。你必须配置构成你的机器学习训练环境的基础设施组件，并决定数据、代码和模型的存储方式。确定最适合你尝试构建的机器学习模型类型的计算资源。安装必要的软件、集成开发环境（IDE）、框架和算法，开始你的机器学习之旅。

在你的训练环境中，你会迭代地训练、调试和调优你的机器学习模型。当准备好时，你需要部署到生产环境，验证预测结果，并监控机器学习模型执行的性能。这一步通常涉及扩展你的基础设施，以实现模型执行的性能期望和业务服务级别协议（SLA）。

我们只是以高层次介绍了机器学习过程，但你可以看到，直到你获得完全调优的适合你特定用例的模型之前，这是一个非常密集和迭代的过程。

Amazon Redshift ML

为了解决业务问题，组织使用监督学习、无监督学习和强化学习等机器学习技术，我们稍后在“机器学习技术”中会详细讨论。但要实施这些技术需要理解不断发展的工具和技术，以获得基于机器学习的洞见。然而，Amazon Redshift ML 使数据分析师、数据科学家或决策者能够使用熟悉的 SQL 命令创建、训练和部署机器学习模型。要创建一个机器学习模型，用户需要编写CREATE MODEL命令，并传递 Amazon Redshift 中可用的必要数据。

当 Amazon Redshift ML 执行CREATE MODEL SQL 命令时，它会安全地将数据从 Amazon Redshift 导出到 Amazon S3，调用 Amazon SageMaker Autopilot 准备数据和训练机器学习模型，最后使用 Amazon SageMaker Neo 将机器学习模型作为 SQL 函数在 Amazon Redshift 中提供（参见 Figure 6-2）。

换句话说，Amazon Redshift ML 在幕后与 Amazon S3、Amazon SageMaker 和 Amazon Redshift 等各种基于云的服务进行通信，以简化使用 SQL 查询进行模型开发。

Figure 6-2. Amazon Redshift ML 架构

Amazon Redshift ML 使用 Amazon SageMaker 构建和训练 ML 模型。Amazon SageMaker 是一个全管理服务，用于准备数据、构建、训练和部署 ML 模型，并使用完全管理的基础设施、工具和工作流来运行预测。

Amazon SageMaker Autopilot 预处理训练数据，例如用不同值替换缺失数据，以保留数据集的大部分信息。它识别分类列的特征，如国家/州/邮政编码，并为训练适当地格式化它们。它选择最佳预处理器，并确定最合适的算法和算法超参数，以提供最准确的预测模型。

模型训练完成后，Amazon Redshift ML 使用 Amazon SageMaker Neo，优化 ML 模型以进行部署，并将其作为 SQL 函数在 Amazon Redshift 中提供。您可以使用 SQL 函数在查询、报告和仪表板中应用 ML 模型。通过执行 CREATE MODEL 命令来实现所有这些功能，详见 “Create Model”。

Amazon Redshift ML 灵活性

Amazon Redshift ML 提供 CREATE MODEL 命令，并默认选项为 AUTO ON。当您使用 AUTO ON 与 Amazon Redshift ML 并运行 SQL 命令创建模型时，Amazon Redshift ML 将指定的数据从 Amazon Redshift 导出到 Amazon S3，并调用 SageMaker Autopilot 自动准备数据，选择适当的预构建算法，并应用算法进行模型训练。Amazon Redshift ML 处理 Amazon Redshift、Amazon S3 和 SageMaker 之间的所有交互，抽象出训练和编译的步骤。模型训练完成后，Amazon Redshift ML 将其作为 SQL 函数提供在您的 Amazon Redshift 数据仓库中使用。

AUTO OFF 选项适用于了解模型类型和训练超参数的高级用户。这会关闭创建模型的自动发现预处理器和超参数的功能，并且相较于 AUTO ON 选项，可以减少创建模型所需的时间。使用 AUTO OFF 选项，您可以更精细地控制 Amazon Redshift 模型的训练。

图 6-3. Amazon Redshift ML 灵活性

在图 6-3 中，您可以看到 Amazon Redshift ML 为不同水平的 ML 知识提供了渠道。任何熟悉 SQL 语言的数据分析师都可以使用自动选项开始使用 Amazon Redshift ML，无需了解 ML 算法的详细信息或 ML 编程语言如Python或R。对于熟悉 ML 算法并希望调整模型特性的数据科学家来说，Amazon Redshift ML 也非常有用。Amazon Redshift ML 还支持一种自带模型（BYOM）的方法，我们在“与 Amazon SageMaker 集成——自带模型（BYOM）”中进行了介绍，通过这种方法，您可以利用 SageMaker 环境选择特定的运行时和计算类型来构建、训练和调整模型。然后，您可以在 Amazon Redshift 中导入模型并运行推理，或者直接从 SageMaker 中使用您的数据进行远程推理。

开始使用 Amazon Redshift ML

Amazon Redshift 需要明确授权才能与其机器学习功能的 Amazon SageMaker 进行交互。通过为 Amazon Redshift ML 配置您的IAM 角色来设置此功能。

作为最佳实践，您应该将创建模型的权限与使用模型进行预测功能的权限分开。示例 6-1 中的查询展示了两个组，model_create_grp具有创建模型的权限，而model_user_grp具有用于推理您的 ML 模型的权限。

示例 6-1. 为 Amazon Redshift ML 授予权限

GRANT CREATE MODEL TO GROUP model_create_grp;
GRANT EXECUTE ON MODEL demo_ml.ml_model TO GROUP model_user_grp;

Amazon Redshift 支持默认的sql语言以及其他不同的语言。您可以查询SVV_LANGUAGE_PRIVILEGES表格以查看用户、角色或组授予的所有语言和权限。Amazon Redshift ML 也是 Amazon Redshift 中的另一种语言，在该表中显示为mlfunc。

当您执行授权语句以允许创建模型时，Amazon Redshift 会向 ML 语言授予权限（参见示例 6-2）。

示例 6-2. 语言权限

SELECT
    language_name,
    privilege_type,
    identity_type,
    identity_name,
    identity_id,
    admin_option
FROM
    svv_language_privileges;

language_name	privilege	identity_type	identity_name	identity_id	admin_option
c	USAGE	public	public	0	false
internal	USAGE	public	public	0	false
mlfunc	USAGE	group	model_create_grp	834679	false
plpgsql	USAGE	public	public	0	false
sql	USAGE	public	public	0	false
plpythonu	USAGE	public	public	0	false

机器学习技术

机器学习模型在您的数据中发现模式，然后将这些模式应用于生成新数据的预测。有许多种类的 ML 技术，但以下是三种常见的方法：

监督机器学习

该算法分析标记数据并学习如何将输入数据映射到输出标签。通常用于分类和预测。

无监督机器学习

不同于监督学习，这种算法不用于预测结果，因此被视为未标记。这种算法通过对数据进行聚类并识别聚类数据中的相似性来找出模式。常见用途包括推荐系统和定向广告。

强化学习

这种技术类似于人类学习的方式，通过试错来学习。强化学习针对一个被置于特定环境中的数字代理，以学习问题解决。类似于我们学习新事物的方式，代理面临着类似游戏的情境，并必须做出一系列决策来尝试达到正确的结果。通过试错，代理将学会该如何做和不该做，并相应地受到奖励或惩罚。每次获得奖励时，都会强化这种行为，并向代理信号使用同样的策略。通过这样的训练，机器学习模型可以被教导遵循指令，进行测试和操作设备，例如。

由于强化学习的复杂性，尽管在亚马逊 SageMaker 中受到支持，但在亚马逊 Redshift ML 中并不支持这种技术。

监督学习技术

监督学习是最常见的机器学习方法，你从具有输入数据列和输出数据列的训练数据集开始。这些输入数据属性到你的机器学习模型被称为“特征”，输出数据属性被称为“标签”。这个训练数据集旨在训练机器学习算法以准确分类数据或预测输出标签。

有两种亚马逊 Redshift ML 支持的监督学习 ML 问题：分类和回归。你的特定用例将只属于这两个不同的问题类型之一：

• 分类问题用于将数据分配到特定类别中。分类有两种类型：

  • 二分类是指预测两种结果的问题，例如在你的收件箱中分类垃圾邮件或预测客户是否会流失。

  • 多类分类是指预测多种结果的问题，例如预测特定客户可能最感兴趣的信用卡类型。

• 回归问题是从输入变量到连续输出变量的映射函数的近似任务。它使用算法来理解依赖变量和独立变量（特征）之间的关系，并定义映射函数来预测输出变量（标签）。连续输出变量是实值，整数或浮点值，通常是数量，例如给定业务的销售收入预测或客户的总支出。

一个特定的回归问题，其中输入变量按时间顺序排列，被称为时间序列预测问题。这个问题由预测模型解决。

Amazon Forecast 是一种完全托管的服务，使用统计和机器学习算法来提供时间序列预测。Amazon Redshift ML 支持使用 Amazon Forecast 构建预测模型。这使您可以使用一段时间内的历史数据来预测未来事件。Amazon Forecast 的常见用例包括使用零售产品数据决定如何定价库存，使用历史订单预测市场需求，使用历史制造和销售数据预测需要订购的某一商品数量，以及使用网站流量数据预测 Web 服务器可能收到的流量量。

Amazon Forecast 的配额限制在 Amazon Redshift 预测模型中执行；例如，最多可以进行 100 次预测，尽管这可以通过支持请求进行更改。

删除预测模型不会自动删除 Amazon Forecast 中关联的资源。

无监督学习技术

无监督学习使用 ML 算法分析数据集，发现数据中的隐藏模式，无需人类干预，因此属于无监督学习类别。与监督学习不同，监督学习具有定义的输入属性和输出属性，无监督学习则是识别数据中的异常或离群值。

Amazon Redshift ML 通过 Amazon SageMaker 支持三种类型的无监督 ML 问题类型：聚类、关联和降维。您的特定用例可能同时属于这些问题类型中的多种。

聚类是一种根据它们的相似性或差异对未标记数据进行分组的技术，然后识别异常值；例如，k-means 聚类算法将相似的数据点分配到组中，其中k值表示组的大小和粒度。它试图在数据中找到离散的分组，其中组的成员彼此尽可能相似，并且与其他组的成员尽可能不同。这种聚类技术对于分割很有帮助，例如，信用卡公司可以根据客户的购买行为将其忠诚卡客户分成不同的组，并启动有针对性的活动或促销产品。

关联使用不同的规则在给定数据集中查找变量之间的关系，例如推荐系统中的“购买了此商品的客户还购买了”类似问题。

降维在给定数据集中特征（或维度或输入列）的数量过高时使用。它减少数据输入的数量到一个可管理的大小，同时保持数据的完整性，例如编码器从视觉数据中去除噪音以改善图片质量。

机器学习算法

我们已经涵盖了问题类型，现在我们将讨论可以用来解决这些问题类型的算法。要深入了解特定的问题类型及可用于解决该特定问题类型的特定算法，请参阅Amazon SageMaker 内置算法的文档。

对于监督学习，Amazon Redshift ML 支持极限梯度增强（XGBoost）、多层感知器（MLP）和线性学习器算法。

XGBoost 算法是梯度增强树算法的优化开源实现。XGBoost 从头开始设计，以高效、灵活、便携和准确的方式处理许多数据科学问题。XGBoost 可用于回归、二分类、多分类和排名问题。排名问题类型用于按相关性顺序查找工件。它为查询中的每个输入关联一个数值分数到最终工件。一旦您有了每个工件的相关性分数，就可以根据这些分数对工件进行排名，并预测排名最高的 N 个最佳匹配值。有关 XGBoost 和 SageMaker 的详细信息，请参阅博文“介绍开源 Amazon SageMaker XGBoost 算法容器”。

MLP 是一种监督深度学习方法，用于训练多层人工神经网络，也称为深度神经网络。MLP 学习线性和非线性数据之间的关系。它是一种前馈人工神经网络，从一组输入生成一组输出。MLP 以几层输入节点连接的方式作为输入和输出层之间的有向图来特征化。MLP 算法的典型应用包括图像分类、语音识别和机器翻译。

线性模型是用于解决分类或回归问题的监督学习算法。你向线性学习模型提供标记数据，算法学习一个线性函数，或者对于分类问题，学习一个线性阈值函数。线性学习算法适用于预测产品销售、确定营销效果或预测客户购买产品或服务的意愿等用例。你可以阅读更多关于SageMaker 线性学习算法的信息，该算法探索不同的训练目标或准确度指标，并从验证集中选择最佳解决方案。

对于无监督学习，Amazon Redshift ML 支持 Amazon SageMaker Random Cut Forest (RCF) 和 k-means 算法。这些必须在 Amazon SageMaker 中构建，并作为 BYOM 导入到 Amazon Redshift。我们将在“Amazon SageMaker 集成——自带模型（BYOM）”中涵盖 BYOM。

RCF 是一种聚类技术，用于检测数据集中与其余结构良好或有模式的数据不符的异常数据点。对于每个数据点，RCF 关联一个异常分数。低分值表示数据点被认为是“正常”的。高值表示数据中存在异常。“低”和“高”的定义取决于应用程序，但通常做法表明，超出均值分数三个标准偏差的分数被视为异常。

如果你使用 k-means，你需要定义算法用来确定 相似性 的属性。它识别出数据中的离散群组，使得每个群组的成员尽可能相似，并尽可能不同于其他群组的成员。数字 k 决定了此算法将生成的群组数。k-means 适用于当你想从随机分布的事物集合中生成相似事物的群组时。

与 Amazon SageMaker Autopilot 的集成

Amazon SageMaker 是一种全面管理的机器学习服务，供数据科学家和开发人员构建、训练并直接部署模型到生产环境中。

Amazon Redshift ML 利用Amazon SageMaker Autopilot功能，基于您的数据训练和调整多个机器学习模型，并保留准确率最高的模型。Amazon SageMaker Autopilot 提供自动数据清理、自动数据预处理、线性回归、二分类和多分类的自动算法选择。它还支持自动超参数调优优化（HPO）、分布式训练、自动实例和集群大小选择。

Amazon SageMaker Autopilot 使得在不需要太多关于机器学习理论的情况下，轻松在 Amazon Redshift 中构建模型成为可能。

创建模型

让我们深入一些实践来创建一个模型。假设您想预测人类和机器之间未来街头赛车的结果。您有先前比赛的历史数据，比赛发生的城市，比赛期间的天气，道路状况，需走的距离以及人类和机器的速度，还有实际的结果—人类是否赢得了比赛。是的，我们支持人类胜利！

你所需的仅仅是用于训练模型的表格和一个 Amazon S3 存储桶来保存训练产物。在示例 6-3 中的代码将为您准备这些表格。您有一个训练表用于训练机器学习模型，并且有一个推断表用于进行机器学习推断。稍后（参见示例 6-4），您将看到创建模型的语法。

示例 6-3. 准备赛车模式

CREATE SCHEMA race;

CREATE TABLE race.speed_training(
  city              varchar(10),
  machine_distance  decimal,
  human_distance    decimal,
  weather           varchar(5),
  road_condition    varchar(5),
  machine_speed     decimal,
  human_speed       decimal,
  human_win_y_n     boolean);

COPY race.speed_training
FROM 's3://redshift-demos/ANT402/training.csv'
region 'us-east-1'
iam_role default
csv delimiter ',';

CREATE TABLE race.speed_inference(
  city              varchar(10),
  machine_distance  decimal,
  human_distance    decimal,
  weather           varchar(5),
  road_condition    varchar(5),
  machine_speed     decimal,
  human_speed       decimal,
  human_win_y_n     boolean);

COPY race.speed_inference
FROM 's3://redshift-demos/ANT402/inference.csv'
region 'us-east-1'
iam_role default
csv delimiter ',';

在示例 6-4 中，Amazon SageMaker Autopilot 将为您处理所有繁重工作，并找出最佳的机器学习模型来预测人类是否会获胜。告诉模型使用标签human_win_y_n，其值可以是True或False，在训练数据上。由于期望的目标human_win_y_n是二元的，Autopilot 将确定这是一个二元分类问题，并选择最准确的算法。

示例 6-4. 创建模型

CREATE MODEL race.human_vs_machine
FROM race.speed_training
TARGET human_win_y_n
FUNCTION fnc_will_human_win
IAM_ROLE default
SETTINGS (
  S3_BUCKET 'my_ml_bucket',
  MAX_RUNTIME 10800);

我们在这个示例中将MAX_RUNTIME设置得比默认的 5400（1.5 小时）要高，以确保在表 6-3 中生成的模型可解释性报告成功。

使用示例 6-5 中的show model命令查看 ML 模型状态。检查模型状态以确定模型是否准备好。当您首次创建模型时，您将看到TRAINING的状态。

示例 6-5. 显示模型

SHOW MODEL race.human_vs_machine;

表 6-1. 显示模型—TRAINING

键	值
模型名称	人类对机器
模式名称	race
所有者	model_create_user
创建时间	星期二, 12.12.2023 05:10:15
模型状态	训练中
…​

当你的模型处于READY状态时，流程已完成，你可以开始使用你的模型。你可以检查objective和相应的validation分数来确定模型的准确性。如表 6-2 所示，目标是f1，得分为 0.93432，即 93.43%的准确率得分。估算成本是推导模型所需的预估SageMaker 处理小时数。准确率高的模型将生成更精确的模型预测，但更高的准确率可能意味着更高的成本。我们将在“Amazon Redshift ML Costs”中介绍成本。

表 6-2. 展示模型—READY

键	值
模型名称	human_vs_machine
模式名称	race
所有者	model_create_user
创建时间	2023 年 12 月 12 日星期二 05:10:15
模型状态	READY
训练作业状态	MaxAutoMLJobRuntimeReached
验证:f1_binary	0.93432
预估成本	20.805736
训练数据:
表	race.speed_training
目标列	HUMAN_WIN_Y_N
参数:
模型类型	xgboost
问题类型	二元分类
目标	F1
AutoML 作业名称	redshiftml-20230114201510598817
函数名称	fnc_will_human_win
	fnc_will_human_win_prob
函数参数	city machine_distance human_distance
	weather road_condition machine_speed
	human_speed
函数参数类型	varchar numeric numeric
	varchar varchar numeric
	numeric
IAM 角色	default-aws-iam-role
S3 存储桶	my_ml_bucket
最大运行时间	3800

准确率超过 80%被认为是一个良好的分数，但根据您的具体用例，您可以选择进一步调整以获得更高的分数。

要运行推断，只需在您的 SQL 查询中使用函数fnc_will_human_win。您需要授予执行模型的权限给将运行推断的标识，如示例 6-6 所示。

示例 6-6. 使用模型进行推断

SELECT
    city,
    machine_distance,
    human_distance,
    weather,
    road_condition,
    machine_speed,
    race.fnc_will_human_win
      (city,
       machine_distance,
       human_distance,
       weather,
       road_condition,
       machine_speed,
       human_speed) AS predicted
FROM
    race.speed_inference;

在验证F1分数时，拥有一组未经训练的数据是个好习惯。运行推断查询并将 ML 模型预测值与未经训练数据中的实际值进行比较。

在前面的示例中，我们展示了如何使用 Amazon SageMaker Autopilot 仅通过提供训练数据表和表中的目标列来创建您的模型。Amazon Redshift ML 还提供了使用用户指导参数创建模型的选项，您可以在CREATE MODEL命令中指定模型类型、问题类型、目标和预处理器，如示例 6-7 所示。如果您知道问题类型和/或模型类型和/或目标，则在CREATE MODEL命令中指定这些值将减少模型创建时间和相关成本。在某些情况下，您需要自定义算法或预处理器。在这些情况下，您需要指定这些参数。

查看创建模型文档以查看示例 6-7 中显示的所有选项的详细信息。

示例 6-7. 完整创建模型

CREATE MODEL model_name
    FROM { table_name | ( select_statement ) }
    TARGET column_name
    FUNCTION function_name
    IAM_ROLE { default }
    [ MODEL_TYPE { XGBOOST | MLP | LINEAR_LEARNER} ]
    [ PROBLEM_TYPE (
      REGRESSION | BINARY_CLASSIFICATION |
      MULTICLASS_CLASSIFICATION ) ]
    [ OBJECTIVE ( 'MSE' | 'Accuracy' | 'F1' | 'F1Macro' | 'AUC') ]
    [ PREPROCESSORS ( TRANSFORMERS ) ]
    SETTINGS (
      S3_BUCKET 'bucket',
      S3_GARBAGE_COLLECT { ON | OFF },
      KMS_KEY_ID 'kms_key_id',
      MAX_CELLS integer,
      MAX_RUNTIME integer (, ...)
    );

设置S3_GARBAGE_COLLECT用于在模型准备就绪后自动清除用于保存训练工件的 Amazon S3 存储桶。但是，如果禁用此设置，您可以使用 Amazon S3 中创建的文件的多种方式，使用 BYOM 策略（参见“与 Amazon SageMaker 集成—Bring Your Own Model (BYOM)”）。如果删除 Amazon Redshift 数据仓库，则可以使用这些文件重新创建推断函数。您还可以使用这些文件实现模型版本控制；例如，在重新训练模型之前，可以使用文件创建旧版本的模型。最后，您可以在一个 Amazon Redshift 数据仓库上创建您的模型，但是在另一个 Amazon Redshift 数据仓库上公开该模型，而无需经过重新训练的过程。

标签概率

标签是您要预测的值或结果。对于human_vs_machine模型，您要预测的是人类是否会获胜，有两种可能的结果或标签：true表示人类获胜，false表示人类未获胜。标签概率度量将概率值分配给每个标签，以指示其发生的可能性。您可以通过使用fnc_will_human_win_prob推断函数访问分配给每个标签的标签概率度量，该函数将输出其发生的百分比可能性。当创建问题类型为二元分类或多类分类的AUTO ON模型时，可以使用标签概率度量。

标签概率是为每一行计算的，而不是实际运行 ML 模型。您可以在推断数据集上运行此功能，以获取预期结果的指示。

概率函数fnc_will_human_win_prob由 Amazon Redshift ML 自动创建，使用您为 ML 模型提供的函数名fnc_will_human_win并添加_prob后缀。

示例 6-8. 标签概率

SELECT
  race.fnc_will_human_win_prob
    (city,
    machine_distance,
    human_distance,
    weather,
    road_condition,
    machine_speed,
    human_speed)
FROM
    race.speed_inference
LIMIT 5;

fnc_will_human_win_prob

在这里，您可以看到在输入数据的前两行中，人类赢得比赛的概率较低，而在接下来的三行中，概率较高。

解释模型

在机器学习中，每个作为模型输入的独立变量称为特征。在 Amazon Redshift ML 中，您用于构建模型的列是该模型的特征。

explain_model 命令 (示例 6-9) 提供了 ML 模型的可解释性报告，其中包含有关所有模型特征的 Shapley 值 的信息。这些 Shapley 值帮助您理解每个特征对模型预测的贡献。Shapley 值是在特征空间中所有可能值的平均边际贡献。较高的 Shapley 值意味着该特征对预测结果有更大的影响。

示例 6-9. 解释模型命令

SELECT explain_model('race.fnc_will_human_win_prob');

您在 表 6-3 中看到，city 和 human_speed 对比 road_condition 的 1.04 和 weather 的 1.46 影响要小得多。您可以从这些数据中推断出，无论是人类还是机器在适应天气和道路条件方面，可能更好。

表 6-3. 解释模型结果

explain_model

{"explanations”:{"kernel_shap”:{"label0”:{ “expected_value”:-0.5694439538988466, “global_shap_values”:{ “city”:0.2865426473431818, “human_distance”:0.8485933955733828, “human_speed”:0.4954490773124456, “machine_distance”:0.8925393014624781, “machine_speed”:0.7125560417928333, “road_condition”:1.0487996886952989, “weather”:1.460974788708901} }}},"version”:"1.0"}

explain_model 命令利用亚马逊 SageMaker Clarify，提供工具来帮助解释 ML 模型如何进行预测。有关详细信息，请参见 Amazon SageMaker Clarify 模型可解释性。

在 ML 模型训练后，模型可解释性报告将自动生成。如果由于 MAX_RUNTIME 参数中断了模型训练，您可能会看到对 explain_model 的错误返回。在这种情况下，您可以增加 MAX_RUNTIME 值并重新运行训练。

使用亚马逊 Redshift ML 预测学生的结果

在 第三章 中，我们讨论了 “学生信息学习分析数据集”。让我们利用我们对亚马逊 Redshift ML 的了解，并使用学生学习数据集构建一个模型，预测学生的表现结果：通过、失败、退出或优异。您还将确定影响学生表现最重要的因素。

首先，您将从历史数据创建训练数据集作为表格。此表将包含学生人口统计信息、从学习管理系统（LMS）收集的数据以及学生评估成绩。您将使用这些输入作为构建 ML 模型的特征，以预测学生的表现结果，即 final_result 列。

表格 tbl_student_lmsactivities_and_score 在 示例 6-10 中通过连接 student_info、student_lms 中的点击总数以及 student_assessment 中的分数总数而创建。这是特征工程的一个重要方面，即数据透视，使所有输入能够进入训练/推断过程。

示例 6-10. Openlearn 机器学习模型特征

CREATE TABLE tbl_student_lmsactivities_and_score AS
SELECT
  st.school_id, st.id_student, st.code_module,
  st.code_presentation, st.gender, st.region,
  st.highest_education, st.imd_band, st.age_band,
  st.num_of_prev_atteempts, st.studied_credits,
  st.disability, st.final_result,
  st_lms_clicks.sum_of_clicks, scores.total_score,
  scores.mean_score
FROM
  openlearnm.student_info st
  LEFT JOIN
    (SELECT school_id, code_module,
      code_presentation, id_student,
      sum(sum_click) AS sum_of_clicks
    FROM
      OPENLEARNM.student_lms
    GROUP BY 1,2,3,4) st_lms_clicks
  ON st.school_id = st_lms_clicks.school_id
  AND st.code_module = st_lms_clicks.code_module
  AND st.code_presentation = st_lms_clicks.code_presentation
  AND st.id_student = st_lms_clicks.id_student
  LEFT JOIN
    (SELECT
      school_id, id_student,
      sum(score) AS total_score,
      avg(score) AS mean_score
    FROM
      openlearnm.student_assessment
    GROUP BY 1,2) scores
  ON st.school_id = scores.school_id
  AND st.id_student = scores.id_student
;

现在，在 tbl_student_lmsactivities_and_score 表上运行 CREATE MODEL 命令以调用 Amazon SageMaker Autopilot。

示例 6-11. Openlearn 创建模型

CREATE MODEL student_result
FROM tbl_student_lmsactivities_and_score
TARGET final_result
FUNCTION fnc_final_result
IAM_ROLE default
SETTINGS (
  S3_BUCKET 'my_ml_bucket',
  MAX_RUNTIME 10800
  )
;

与前面的示例类似，我们将 MAX_RUNTIME 设置得比默认的 5400（1.5 小时）更高，以确保在 表 6-3 中生成模型可解释性报告成功。

现在，您可以执行 show model 命令查看 Amazon SageMaker Autopilot 选择的模型的详细信息。您将在 表 6-4 中看到，它能够选择一个准确率为 87% 的模型，并且由于您确定了多个可能的标签之一（退课、通过、优异 和 不及格），它确定问题类型是多类分类。

示例 6-12. 展示模型

show model student_result;

表 6-4. 展示模型输出

键	值
模型名称	student_result
模式名称	public
所有者	model_create_user
创建时间	日，2024 年 03 月 05 日 18:54:11
模型状态	READY
验证精度	0.870610
预计成本	29.814964
训练数据：
表	tbl_student_lmsactivities_and_score
目标列	FINAL_RESULT
参数：
模型类型	xgboost
问题类型	多类分类
目标	准确性
AutoML 任务名称	redshiftml-20230305185411524819
函数名称	fnc_final_result
	fnc_final_result_prob
函数参数	id_student code_module code_presentation
	性别 地区 最高教育程度 imd_band
	年龄段 前几次尝试次数
	学习学分 残疾 点击总数
	总分 平均分
函数参数类型	int4 varchar varchar
	bpchar varchar varchar varchar
	varchar int2
	int2 bpchar int8
	int8 int8
IAM 角色	default-aws-iam-role
S3 存储桶	my_ml_bucket
最大运行时间	10800

最后，您可以执行explain_model命令以查看 Shapley 值。您可以在示例 6-13 中看到，与年龄段相比，性别、地区、以前的尝试和残疾的影响较小，分别为0.51、最高学历为0.59、学习学分为0.66。具有0.99值的点击次数似乎是决定学生表现最重要的因素。点击次数表示与虚拟学习环境的互动。基于此 ML 模型，您可以预期增加与虚拟学习环境的互动应该会改善学生的成绩—例如，在虚拟课程内容之间增加一场小测验。

示例 6-13. 解释模型student_result

SELECT
  t.r.explanations.kernel_shap.label0.global_shap_values
FROM (SELECT
        explain_model('student_result') AS r
     ) AS t
;

global_shap_values

“年龄段”:0.510843481387332466, “code_module”:0.1775745286500845, “code_presentation”:0.09353407379714834, “残疾”:0.051944180058839748, “性别”:0.05065581722765354, “最高学历”:0.592895528627924518, “id_student”:0.00000483678127755, “imd_band”:0.033637420953443259, “mean_score”:0.2120711173613374, “num_of_prev_attempts”:0.05241636943859941, “地区”:0.13375708054846678, “studied_credits”:0.6551317963150247, “sum_of_clicks”:0.9983975396249064, “total_score”:0.25218934352064467

Amazon SageMaker 与 Amazon Redshift 集成

到目前为止，我们已经描述了用户如何使用 SQL 创建模型并进行推断。对于在 Amazon SageMaker 中构建和训练模型的数据科学家用户，Amazon SageMaker Studio 是一个提供单一基于 Web 的视觉界面的 IDE，您可以访问工具以执行所有机器学习操作。SageMaker 笔记本是一个流行的界面，运行 Jupyter Notebook 应用程序以准备和处理数据，编写代码来训练模型，将模型部署到 SageMaker 托管环境，并测试或验证您的模型。在“Amazon Redshift 数据 API”讨论的 Amazon Redshift 数据 API 简化了连接管理，而 Jupyter Notebook 预加载了访问 Amazon Redshift 数据 API 所需的库。这使得在 Amazon SageMaker 中使用来自 Amazon Redshift 的数据进行高级 ML 训练变得简单。

Amazon SageMaker Canvas 允许业务分析师在不编写代码或需要 ML 专业知识的情况下构建 ML 模型。一旦您授予用户访问 Amazon Redshift 的权限，您可以通过使用 SQL 查询和连接，将 Amazon Redshift 数据导入，并将其推送到 Amazon Redshift 以利用其本地特性。

Amazon SageMaker 集成—自定义模型（BYOM）

对于在 Amazon Redshift 外部创建的高级 ML 模型，如果满足 Redshift ML 的要求，可以将其引入 Amazon Redshift 以进行 ML 推理。您可以导入这些预训练模型，用于本地推理或远程推理。这些模型可以使用 Amazon Redshift 数据创建和训练，详见“Amazon SageMaker 与 Amazon Redshift 集成”，或者可以使用其他数据源创建和训练。

要将自己的 SageMaker 模型引入 Amazon Redshift，必须满足以下条件：

• 模型必须通过文本或 CSV 的内容类型接受 CSV 格式的输入。

• 端点必须由拥有 Amazon Redshift 数据仓库的同一 AWS 账户托管。

• 模型的输出必须是在创建函数时指定类型的单个值。

• 模型必须接受空值作为空字符串处理。

• Amazon SageMaker 端点必须具有足够资源来容纳来自 Amazon Redshift 的推理调用，或者 SageMaker 端点可以进行自动扩展。

BYOM 本地

示例 6-14 是 BYOM 本地推理的查询语法。您可以指定一个 SageMaker 作业名称或者由 SageMaker 作业生成的 .tar.gz 模型工件文件在 Amazon S3 上的位置。ML 模型被存储为本地编译的 Amazon Redshift 函数。

示例 6-14. BYOM 本地

CREATE MODEL public.predict_customer_churn
FROM 'job_customer_churn-xxxxxxxxxx'
FUNCTION fn_customer_churn(int)
RETURNS decimal(8,7)
iam_role 'arn:aws:iam::123456789012:role/myRSMLrole';

在本地运行 BYOM ML 模型推理时，Amazon Redshift SQL 函数会在 Amazon Redshift 中本地调用，并进行预测，因此不涉及 SageMaker。

BYOM 远程

您也可以在 Amazon Redshift 中引用 SageMaker 模型端点进行远程推理。示例 6-15 是 BYOM 远程推理的查询语法。sagemaker 关键字告诉 Amazon Redshift ML 此特定 ML 模型是用于远程推理的 SageMaker 模型。

在 Amazon Redshift 上运行远程 BYOM 模型推理查询时，会调用 SageMaker ML 模型，并直接从 SageMaker 获取预测。

示例 6-15. BYOM 远程

CREATE MODEL public.remote_random_cut_forest
FUNCTION fn_remote_rcf(int)
RETURNS decimal(10,6)
sagemaker 'randomcurforest-xxxxxxxxxx'
iam_role 'arn:aws:iam::123456789012:role/myRSMLrole';

若要查看更多创建模型的用例，请参阅创建模型用例。

Amazon Redshift ML 成本

Amazon Redshift ML 使用 Amazon SageMaker 训练您的模型，因此训练 ML 模型会产生相关费用。启用 Amazon Redshift ML 功能不会产生额外费用。此外，在 Amazon Redshift 中进行本地预测不会产生 Amazon SageMaker 的费用，但远程预测则会额外产生 Amazon SageMaker 费用。

create model 语句提供 MAX_RUNTIME 和 MAX_CELLS 选项，用于控制在 Amazon Redshift 中训练 ML 模型时的成本、时间和潜在模型精度：

MAX_RUNTIME

默认值为5,400秒或90分钟。这是亚马逊 SageMaker 训练的最长时间。降低此值限制了在亚马逊 SageMaker 中的时间和计算开销，从而减少了训练模型的成本。

MAX_CELLS

默认值为1,000,000个单元格，其中一个单元格是您数据集中的单个数据点。因此，如果您的训练数据表具有12 列和20,000 行，那么它有240,000个单元格用于训练 ML 模型。使用较低的最大单元格值会导致亚马逊 Redshift ML 选择减少的数据集进行训练，从而减少成本和训练模型的时间。

训练完成后，亚马逊 Redshift 需要一些时间在本地编译和安装模型，因此您可能会发现您的create model语句执行时间比您指定的max_runtime更长。

如果训练数据集中的实际单元格数超过MAX_CELLS值，则亚马逊 Redshift 将从训练数据集中随机选择较少的记录。这种随机化有助于在减少的训练数据集中防止偏差，同时仍然提供良好的机器学习预测。

设置MAX_CELLS和MAX_RUNTIME的值过低可能导致亚马逊 Redshift ML 无法为您确定机器学习模型，甚至可能选择准确度降低的模型。

大多数机器学习用例都属于默认的一百万个单元格范围内，这可以使大多数用例的训练成本保持在不到$20。然而，如果您的训练数据超过一百万个单元格，那么价格将如下例所示增加。

前 1 千万个单元格的价格为每百万单元格$20。接下来的 9 千万个单元格的价格为每百万单元格$15。超过 1 亿单元格的价格为每百万单元格$7。

下面是一个包含 1.25 亿单元格的定价示例：

First 10 million = 10 x $20 =  $200
 Next 90 million = 90 x $15 = $1350
Over 100 million = 25 x $07 =  $175
-----------------------      ------
TOTAL 125 million cells       $1825
-----------------------      ------

此外，根据使用情况收取亚马逊 S3 存储训练数据和与模型相关的工件的费用。在训练期间，默认的垃圾收集模式会自动删除这些临时的亚马逊 S3 数据，一旦模型创建完成，亚马逊 S3 的费用也因此得到了最小化。

摘要

本章涵盖了一些您可以使用亚马逊 Redshift ML 解决的机器学习用例。我们讨论了如何使用监督学习技术在亚马逊 Redshift 中直接启动CREATE MODEL命令来解决分类和回归问题。我们还详细介绍了如何使用无监督学习技术在亚马逊 SageMaker 中解决聚类、关联和维度问题，以及如何通过内置连接器从亚马逊 Redshift 导入训练这些模型所需的数据，并且如何将这些模型通过自带模型策略返回到亚马逊 Redshift 中用于推理。

在本书中，我们已经讨论了数据共享及其如何通过能够独立隔离和扩展工作负载的能力，从而支持现代数据战略。在下一章中，我们将描述数据共享的不同用例，以及如何设置数据共享，无论它们是在相同的账户和地区，还是在不同的地区，以及如何使用 Amazon DataZone 来管理数据共享访问。

第七章：数据共享的合作

数据共享是加速数字转型的业务必需品。

Gartner

数据共享是为内部和外部利益相关者提供信息访问的能力，他们无法在自己的数据系统中访问。数据共享允许利益相关者访问生产者领域中产生或收集并存储的数据，并共同合作实现共享的业务目标和优先事项。数据组织正在从单一的大型单体部门转变为小型分布式团队，这通常导致数据平台运行缓慢，以创建模块化快速移动的数据产品。

通过构建强大的数据共享架构，数据和分析领导者将能够在适当的时间访问正确的数据，以实现有意义的业务成果。像国家卫生研究院（NIH）这样的组织已经实施了数据管理和共享政策，以确立数据共享是研究过程的基本组成部分，以最大化公众对研究结果的访问。

数据共享鼓励我们利用当前信息和资源，并根据这些信息采取行动。公司越早开始共享数据并将其用于决策，就越有时间交付业务成果。

“数据是新石油”的说法最初由英国数学家和数据科学企业家 Clive Humby 创造，这在过去二十年中被证明是正确的。数据驱动业务决策，支持研究并推动技术发展。组织正在比以往任何时候都更多地收集和存储数据。但随着数据的丰富，如何有效地共享和协作成为了挑战。

在本章中，您将学习如何使用 Amazon Redshift 共享和协作大量数据。我们将从提供“Amazon Redshift 数据共享概述”开始，并描述不同的“数据共享使用案例”。接下来，我们将深入探讨使用 Amazon Redshift 的“数据共享关键概念”，并逐步介绍如何“使用数据共享”。我们将探讨使用跨账户数据共享的“跨账户和跨区域共享数据”的选项，并展示在“使用多租户存储模式进行分析服务用例”中使用 Amazon Redshift 数据共享的不同选项。接下来，我们将讨论如何启用“AWS ADX 集成的外部数据共享”以从您的数据中赚钱，并使用其 Amazon Redshift 计算为客户提供即时数据访问。最后，我们将简要介绍如何通过“从数据湖查询和卸载到数据湖”作为数据共享的机制。最后，我们将介绍如何使用“Amazon DataZone 来发现和共享数据”来对数据分享进行目录化和管理访问权限。

Amazon Redshift 数据共享概述

Amazon Redshift 数据共享无需复制或移动数据即可实现跨数据仓库的即时、细粒度和实时数据访问。这使您能够创建多仓库架构，并为各种工作负载的每个数据仓库进行扩展。Amazon Redshift 数据共享包含在您的无服务器或 RA3 预配的数据仓库中，并提供以下功能：

• 所有消费者之间的数据的实时和事务一致视图

• 安全和受管制的组织内及组织间协作

• 与外部方共享数据以从中获利

数据仓库中的实时访问和事务一致视图确保用户始终看到最新和一致的信息，因为数据仓库中的更新信息已更新。您可以安全地与同一区域或跨区域的同一 AWS 帐户或不同 AWS 帐户的 Amazon Redshift 数据仓库共享数据。在构建用于分析的可扩展架构时，您需要考虑查询和摄入工作负载的性能、弹性和性能价格比，以满足动态工作负载的要求。Amazon Redshift 数据共享功能提供了另一种机制来扩展并满足各种工作负载的需求。

Amazon Redshift RA3 架构支持数据共享功能。在 RA3 架构中，存储在 Amazon RMS 中的数据提交到 Amazon S3，但也可在固态驱动器（SSD）本地缓存中供计算节点快速处理最近使用的数据。来自消费者数据仓库的查询直接从 Amazon RMS 层读取数据。因此，生产者数据仓库的性能不受影响，访问共享数据的工作负载彼此隔离。该架构显示在图 7-1 中，它使您能够设置一个多仓库架构，具有为不同类型的工作负载分别设置的消费者数据仓库。您可以按需自助方式提供符合工作负载特定价格性能要求的灵活计算资源，并进行独立扩展。

图 7-1. Amazon Redshift 数据共享架构

由于 DC2 节点不利用 Redshift Managed Storage（RMS），因此 Amazon Redshift 数据共享在 DC2 节点类型上不可用。有关如何利用数据共享的详细信息，请参阅升级到 RA3 节点类型文档或迁移到 Amazon Redshift 无服务器文档。

数据共享用例

根据Gartner的数据，“与不共享数据的数据和分析领导者相比，外部共享数据的领导者产生的经济效益是后者的三倍。” 数据共享已被证明具有可衡量的经济效益，有数据共享战略的组织表现优于同行。数据共享的用例范围从帮助增强可伸缩性（通过工作负载分离），增加协作，构建 Analytics as a Service（AaaS）解决方案，改善操作效率，数据质量，以及普遍提高数据访问。让我们更详细地看看这些用例：

工作负载分离

当你有大量的 ETL 工作负载时，可以通过多仓库架构将 ETL 工作负载与查询工作负载分离，通过使用一个数据仓库用于数据摄入，另一个数据仓库用于查询来进行扩展。每个仓库可以针对其预期工作负载进行调优和优化。

跨团队协作

公司内不同部门可以共享和访问数据，从而实现更高效和更有效的决策。例如，市场团队可以使用存储在 Amazon Redshift 中的数据更好地定位他们的活动，而财务团队可以使用相同的数据来预测收入。即使跨部门共享数据，但仍然隔离工作负载以使用自己的计算资源，以确保每个团队的处理需求不会相互冲突。参见图 7-2 作为示例。

图 7-2. 数据共享用例工作负载分离和协作

分析即服务

AaaS 提供商可以从各种来源（如社交媒体、网络分析和 ERP 系统）收集和聚合数据到数据仓库，并在与订阅者分享之前添加业务洞察转换。例如，使用在第三章，“设置您的数据模型和数据摄入”中定义的学生数据模型，教育技术 AaaS 提供商可以收集有关学生出勤和成绩的数据，并派生出如何改善学生成绩的见解。然后，他们可以使用订阅模型使用AWS 数据交换（ADX）集成与教育机构分享这些见解，并通过他们的事务系统已经收集的数据进行货币化。数据的生产者还可以使用AWS Clean Rooms与合作伙伴或其他 AWS 用户协作，而不必共享原始数据。

改进软件开发生命周期（SDLC）的灵活性

在应用程序开发生命周期中，大多数组织在 DevOps 领域中没有足够的测试数据而感到困惑。通过数据共享，您可以将生产系统的数据分享到开发系统，通过验证所有测试用例来提高测试质量，并加快应用程序的交付速度。如果您在将生产数据分享到其他环境时有特定的安全策略，您还可以使用动态数据脱敏（DDM）功能在 Amazon Redshift 中屏蔽特定的个人身份信息（PII）数据。有关示例，请参见图 7-3。

图 7-3. 数据共享用例分析即服务和开发灵活性

数据共享的关键概念

数据共享是在 Amazon Redshift 中共享数据的单位（请参见图 7-5）。数据所有者可以将数据库对象添加到数据共享中以与订阅者共享。数据共享充当容器，用于保存对其他数据库对象的引用。生成和共享数据的数据所有者称为生产者，订阅者称为消费者。Amazon Redshift 允许您设置访问控制和权限，确保敏感数据仅与授权人员共享。在与外部合作伙伴或其他具有严格数据治理和安全要求的 AWS 用户分享数据时，这一点尤为重要。每个数据共享都与您 Amazon Redshift 数据仓库中特定的数据库相关联。

数据生产者是拥有数据并从中共享数据的亚马逊 Redshift 数据仓库。生产者数据仓库管理员和数据库所有者可以使用 CREATE DATASHARE 命令创建数据共享。您可以向生产者的数据共享添加数据库对象，例如模式、表、视图和 SQL UDFs，以便与消费者共享。共享数据的亚马逊 Redshift 数据仓库可以位于相同的 AWS 账户中，也可以位于不同的 AWS 账户或 AWS 区域中，因此您可以跨组织共享数据并与其他方进行协作。

数据消费者是接收来自生产者数据仓库的数据共享的亚马逊 Redshift 数据仓库。当生产者授予数据共享访问权限给消费者时，消费者数据仓库管理员可以创建一个引用数据共享的数据库。请注意，这个数据库是对数据共享的引用，而不是消费者端的物理持久存储。然后管理员为数据库中的用户和组分配权限。授予权限后，用户和组可以使用三部分标记 database.schema.object 查询数据共享对象。授权用户还可以使用标准元数据查询列出共享对象并跟踪使用情况。对于跨账户数据共享，生产者需要额外的步骤来授权数据共享，而消费者需要将一个或多个亚马逊 Redshift 数据仓库与数据共享关联起来。

命名空间是标识亚马逊 Redshift 预配置或无服务器数据仓库的标识符。命名空间的全局唯一标识符（GUID）会自动创建并分配给您的亚马逊 Redshift 数据仓库。预配置的命名空间 Amazon 资源名称（ARN）格式为 arn:{partition}:redshift:{region}:{account-id}:namespace:{namespace-guid}，无服务器的为 arn:{partition}:redshift-serverless:{region}:{account-id}:namespace:{namespace-guid}。您可以在亚马逊 Redshift 控制台的一般信息页面上查看数据仓库的命名空间详细信息（参见 图 7-4）。

图 7-4. 数据共享命名空间

在数据共享工作流程中，命名空间 GUID 值和命名空间 ARN 用于与 AWS 账户中的其他亚马逊 Redshift 数据仓库共享数据。您还可以使用 current_namespace 函数查找当前数据仓库的命名空间。对于跨账户数据共享，AWS 账户可以作为数据共享的消费者，并分别由 12 位 AWS 账户 ID 表示。消费者账户可以将一个或多个亚马逊 Redshift 数据仓库与数据共享关联，以读取该数据。

使用 Amazon Redshift，您可以通过不同级别的数据库对象共享数据，并且您可以为给定数据库创建多个数据共享。数据共享可以包含创建共享的数据库中多个模式的对象。但是，您只能向消费者共享数据共享对象，而不能共享单个对象。通过这种数据共享的灵活性，您可以获得细粒度的访问控制。您可以为需要访问 Amazon Redshift 数据的不同用户和企业定制此控制。例如，您可能希望仅向学校管理员共享特定学校的学生详细信息。在企业中，您可能希望控制向供应商共享对应供应的销售详细信息（图 7-5）。

图 7-5. 数据共享的关键概念及其工作原理

如何使用数据共享

要使用数据共享，首先确定要共享的数据以及具有相关数据的相应模式、表和视图。要共享数据，请创建 DATASHARE 元数据对象，并将数据库对象（包括模式、表和视图）添加到此数据共享中。然后，向同一账户内的其他命名空间或另一个 AWS 账户授予访问权限。让我们看一个具体的例子，并走过整个过程。

在同一账户内共享数据

让我们使用来自 示例 3-1 的学生学习数据集来理解如何共享数据。本节展示了如何在同一账户内向组织内的消费者共享学生学习数据集。您可以使用控制台或 SQL 脚本来创建和共享数据共享。示例 7-1 和 7-2 中的以下脚本为您提供了操作步骤。

示例 7-1. 创建数据共享

-- Creating a datashare (producer)
CREATE DATASHARE learnshare SET PUBLICACCESSIBLE TRUE;

在上述语句中，learnshare 是数据共享的名称。数据共享名称在命名空间中必须是唯一的。SET PUBLICACCESSIBLE 是一个子句，用于指定数据共享是否可以共享给公共访问的数据仓库。SET PUBLICACCESSIBLE 的默认值为 FALSE。

示例 7-2. 向数据共享添加对象

-- Add schema to datashare
ALTER DATASHARE learnshare
  ADD SCHEMA openlearn;

-- Add openlearn materialized view to datshares.
ALTER DATASHARE learnshare
  ADD TABLE openlearnm.mv_student_lmsactivities_and_score;

-- View shared objects
SHOW DATASHARES;
SELECT * FROM SVV_DATASHARE_OBJECTS;

share_name	share_owner	source_database	consumer_database	share_type	createdate
learnshare_adx	100	dev	null	OUTBOUND	2023-03-18 19:51:28
learnshare	100	dev	null	OUTBOUND	2023-02-24 18:32:28
is_publicaccessible	share_acl	producer_account	producer_namespace
---	---	---	---
true	null		xxxxc8ee-f6a5-xxxx-xxxx-yyyy66d7zzzz
true	null		xxxxc7ee-xxxx-468f-xxxx-yyyy77d7zzzz

要添加模式中的所有表，请使用以下语法：

ALTER DATASHARE learnshare ADD ALL TABLES IN SCHEMA openlearn;

要获取消费者的命名空间，您可以登录到消费者的 Amazon Redshift 数据仓库，并运行 示例 7-3 中的 SQL 来选择 current_namespace，或者您可以从控制台获取。

示例 7-3. 查看当前用户和命名空间。

SELECT user, current_namespace;

现在，通过您的数据仓库的命名空间 <<consumer namespace>>，您可以使用 GRANT 命令向消费者授予从生产者到消费者的数据共享权限，如 示例 7-4 所示。

示例 7-4. 授予对数据共享的访问权限。

GRANT USAGE ON DATASHARE learnshare TO NAMESPACE '<<consumer namespace>>';

在消费者端，创建一个数据库，引用生产者或无服务器数据仓库上的数据共享。请注意，这个数据库只是指向数据共享的指针，并不保存任何数据。创建数据库后，您可以像在 示例 7-5 中展示的那样，使用 db_name.schema.view 的三部分表示法实时查询数据。

示例 7-5. 从远程数据共享创建本地数据库。

CREATE DATABASE openlearn_db
FROM DATASHARE learnshare
OF NAMESPACE '<producer_namespace>';

SELECT school_id, code_module, code_presentation,
  final_result, sum(sum_of_clicks)
FROM  openlearn_db.openlearnm.mv_student_lmsactivities_and_score
GROUP BY 1,2,3,4
ORDER BY 1,2,3,4;

可选地，您可以在消费者数据仓库中创建一个外部模式，指向生产者数据仓库中的模式。在消费者数据仓库中创建本地外部模式允许在消费者数据仓库内进行模式级访问控制，并允许您在引用共享数据对象时使用两部分表示法（localschema.table 与 external_db.producerschema.table），如 示例 7-6 所示。

示例 7-6. 从本地数据库创建外部模式。

CREATE EXTERNAL SCHEMA openlearn_schema
FROM REDSHIFT DATABASE 'openlearn_db' SCHEMA 'openlearn';

SELECT school_id, code_module, code_presentation,
  final_result, sum(sum_of_clicks)
FROM  openlearn_schema.mv_student_lmsactivities_and_score
GROUP BY 1,2,3,4
ORDER BY 1,2,3,4;

使用跨账户数据共享跨账户共享数据。

除了内部数据共享以打破组织内的数据孤岛外，您还可以使用跨账户数据共享功能安全地向外部组织共享数据。以下是一些常见的使用案例：

• 子公司向其母公司报告财务报表。

• 企业组织或政府机构与另一组织或相关机构共享数据。

• AaaS（作为服务提供者）向其订阅者共享数据。

• 医疗组织与政府机构共享数据。

当您跨账户共享数据时，您将创建一个 datashare 对象，并添加您想要共享的数据库对象，类似于在账户内共享。但是在这里，您将授予消费者 AWS 账户访问该数据共享的权限，如 示例 7-7 所示。在消费者端，管理员可以关联一个或多个数据仓库以能够读取数据共享。

Amazon Redshift 支持具有同质加密配置的数据仓库数据共享。换句话说，您可以在两个或多个加密的 Amazon Redshift 数据仓库之间共享数据。或者，您可以在相同 AWS 账户内的两个或多个未加密的 Amazon Redshift 数据仓库之间共享数据。在加密数据仓库之间共享数据时，您可以为每个数据仓库使用不同的加密密钥。对于跨账户和跨区域的数据共享，生产者和消费者数据仓库必须都加密。

示例 7-7. 授权 AWS 账户访问数据共享

-- Granting access to consumer AWS Account
GRANT USAGE ON DATASHARE learnshare TO ACCOUNT <AWS_Account>;

对于跨账户共享，还需要额外的授权步骤，以便消费者账户能够看到数据共享。此过程允许管理者或数据所有者批准数据共享，如图 7-6 所示。一旦授权完成，数据共享将对消费者账户可见。

图 7-6. 跨账户数据共享的授权步骤

用户可以在不同账户和区域的多个 Amazon Redshift 数据仓库中管理多个数据共享。要集中管理所有账户中的所有数据共享，可以建立一个自定义的 Web 界面，并指定所有者或管理员来授权或关联数据共享。要自动化授权和关联过程，还可以使用 CLI 命令authorize-data-share和associate-data-share-consumer。

在消费者端，您可以将一个或多个 Amazon Redshift 数据仓库与数据共享关联起来。请注意，当您选择数据共享菜单选项时，数据共享将显示在“来自其他账户”选项卡中。您可以选择数据共享，然后点击“关联”按钮将消费者关联到数据共享，如图 7-7 所示。

图 7-7. 将消费者数据仓库关联到生产者数据共享

一旦您将消费者数据仓库关联到数据共享，您可以登录到关联的消费者数据仓库，并只需几个步骤即可查询数据共享中对象的数据。首先，创建到数据共享的数据库引用，然后使用db_name.schema.table的三部分表示法，如示例 7-8 中的 SQL 脚本所示。

示例 7-8. 从远程数据共享创建本地数据库

CREATE DATABASE openlearn_db
FROM DATASHARE learnshare
OF ACCOUNT '<<producer_account>>' NAMESPACE '<<producer_namespace>>';

SELECT * FROM learn_db.learnshare. mv_student_lmsactivities_and_score;

当此查询从消费者传递给生产者时，current_namespace变量将具有此消费者的命名空间。因此，材料化视图将根据学校表的连接条件仅从此消费者过滤记录。正如前面讨论的，您可以创建一个外部模式来使用两部分符号表示法引用共享数据对象（例如external_schema.table），而不是三部分符号表示法（external_db.producer_schema.table）。

有关设置跨 AWS 账户数据共享的详细步骤，请参阅跨 AWS 账户共享数据的文档。

多租户存储模式的分析即服务用例

AaaS 提供商在云中为用户提供基于订阅的分析能力。这些服务提供商通常需要存储多个用户的数据，并安全地为其提供分析服务的订阅者访问权限。采用多租户存储策略可以帮助它们构建成本效益高且能够根据需求进行扩展的架构。多租户意味着一个软件实例及其支持基础设施被共享以服务多个用户。例如，软件服务提供商可以生成存储在单个数据仓库中的数据，但可以安全地被多个用户访问。这种存储策略提供了集中管理数据、简化 ETL 流程和优化成本的机会。没有数据共享，服务提供商很难在多租户环境中找到平衡，因为他们需要在成本和提供更好的用户体验之间权衡。

使用数据共享来扩展您的多租户架构

以前，实施多租户架构的 AaaS 提供商受限于单个数据仓库的资源，以满足所有租户跨计算和并发需求。随着租户数量的增加，您可以选择开启并发缩放或创建额外的数据仓库。然而，增加新的数据仓库意味着额外的数据摄取管道和增加的运营开销。

通过Amazon Redshift 中的数据共享，您可以在简化存储和 ETL 管道的同时满足成本管理和提供一致性性能的双重目标。您可以将数据摄取到指定为生产者的数据仓库，并与一个或多个消费者共享这些实时数据。生产者中摄取的数据与一个或多个消费者共享，从而允许 ETL 和 BI 工作负载的完全分离。访问此共享数据的集群彼此隔离，因此生产者的性能不会受到消费者工作负载的影响。这使得消费者可以根据其各自的计算能力获得一致的性能。

几个消费者可以从生产者的托管存储中读取数据。这使得可以即时、细粒度和高性能地访问数据，无需复制或移动。访问共享数据的工作负载彼此隔离，也与生产者隔离。您可以将工作负载分布在多个数据仓库中，同时简化和整合 ETL 摄取管道到一个主要的生产者数据仓库，提供最佳的性价比。

消费者数据仓库可以反过来成为其拥有的数据集的生产者。您可以通过在同一个消费者上共享多个租户来进一步优化成本。例如，您可以将低容量第三层租户组合到一个单一的消费者中，以提供更低成本的服务，而高容量第一层租户则有他们自己独立的计算数据仓库。消费者数据仓库可以在与生产者相同的账户中创建，也可以在不同的 AWS 账户中创建。通过这种方式，您可以对消费者进行单独计费，可以向使用消费者的业务组收费，甚至允许用户在其账户中使用自己的 Amazon Redshift 数据仓库，这样他们就可以为使用消费者数据仓库的费用付费。图 7-8 展示了在使用数据共享的多租户架构中 ETL 和消费者访问模式与不使用数据共享的单一数据仓库方法之间的差异。

图 7-8. 使用数据共享的多租户架构与单一数据仓库方法的比较

使用数据共享的多租户存储模式

在多租户策略中，数据存储在所有租户共享的位置，从而简化 ETL 摄取管道和数据管理。有几种存储策略支持这种多租户访问模式，如图 7-9 所示。

池模型

数据存储在所有租户的单个数据库模式中，新列（tenant_id）用于限定和控制对各个租户数据的访问。对多租户数据的访问是通过建立在表上的视图进行控制的。

桥接模型

对于每个租户的数据的存储和访问是在同一数据库中的单独模式中维护的。

独立模型

对于每个租户的数据的存储和访问控制是在单独的数据库中维护的。

图 7-9. 多租户存储模式

我们将使用学生分析数据模型来演示利用数据共享实施可扩展的多租户架构的多种策略。我们将详细介绍每种策略涉及的步骤，使用我们在第三章，“设置数据模型和导入数据”中创建的数据模型。在此用例中，生产者是 AaaS 提供商，负责在一个 Amazon Redshift 数据仓库中加载和处理数据。消费者（租户）是订阅了学生洞察数据集的学校，在一个或多个 Amazon Redshift 数据仓库中。

实施跨数据仓库启用数据共享的高级步骤如下：

1. 在生产者中创建数据共享并将数据库对象分配给数据共享。

2. 从生产者那里，授予消费者对数据共享的使用权，通过命名空间或 AWS 账户来识别。

3. 从消费者端，使用生产者的数据共享创建外部数据库。

4. 通过消费者中的外部共享数据库查询数据共享中的表。授予其他用户访问此共享数据库和对象的权限。

在接下来的示例中，我们将使用学校表来识别我们的消费者（租户）。由于所有表都有school_id列，您可以使用此列来区分并安全共享仅授权给相应消费者的数据。

在开始之前，请获取生产者和消费者数据仓库的命名空间。您可以通过使用 AWS 控制台或登录到每个数据仓库并执行SELECT CURRENT_NAMESPACE语句来执行此操作。

在下面的代码示例中，用您环境中的相应命名空间替换producer_namespace和consumer_namespace占位符。

为了演示多租户架构模式，我们将使用 Open University Learning Analytics 数据集的修改版本，并在所有表中包含school_id以存储多个学校的数据。添加了school_id的多租户版本数据集可在Amazon S3中找到。您可以使用这个数据集，在使用示例 7-9 中的脚本创建表后，将其导入到 Amazon Redshift 中。请注意，有一个新的 school 表，用于存储各个学校的详细信息，并在每个表中添加了school_id列。示例数据包括两所不同学校的数据，我们将使用这些数据来演示如何利用 Amazon Redshift 数据共享功能构建多租户存储策略。

示例 7-9. 为学生信息数据创建模式和表

/* We will use a modified version of the Open University Learning Analytics */
/* dataset to demonstrate multi-tenant architecture by storing data */
/* for multiple schools https://analyse.kmi.open.ac.uk/open_dataset */
/* https://analyse.kmi.open.ac.uk/open_dataset#rights */
/* Kuzilek J., Hlosta M., Zdrahal Z. Open University Learning Analytics dataset */
/* Sci. Data 4:170171 doi: 10.1038/sdata.2017.171 (2017). */

CREATE SCHEMA openlearnm;

CREATE TABLE "openlearnm"."school"(
school_id       integer,
school_name     varchar(50),
address         varchar(100),
city            varchar(80),
website_url     varchar(100),
consumer_namespace varchar(100))
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearnm"."assessments"
(
    school_id integer,
    code_module varchar(5),
    code_presentation varchar(5),
    id_assessment integer,
    assessment_type varchar(5),
    assessment_date bigint,
    weight decimal(10,2)
    )
diststyle AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearnm"."courses"
(
    school_id   integer,
    code_module                varchar(5),
    code_presentation          varchar(5),
    module_presentation_length integer
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearnm"."student_assessment"
(
    school_id   integer,
    id_assessment  integer,
    id_student     integer,
    date_submitted bigint,
    is_banked      smallint,
    score          smallint
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearnm"."student_info"
(
    school_id   integer,
    code_module           varchar(5),
    code_presentation     varchar(5),
    id_student            integer,
    gender                CHAR(1),
    region                varchar(50),
    highest_education     varchar(50),
    imd_band              varchar(10),
    age_band              varchar(10),
    num_of_prev_atteempts smallint,
    studied_credits       smallint,
    disability            char(1),
    final_result          varchar(20)
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearnm"."student_registration"
(
    school_id   integer,
    code_module         varchar(5),
    code_presendation   varchar(5),
    id_student          integer,
    date_registration   bigint ,
    date_unregistration bigint
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearnm"."student_lms"
(
    school_id   integer,
    code_module       varchar(5),
    code_presentation varchar(5),
    id_student        integer,
    id_site           integer,
    date              bigint,
    sum_click         integer
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

CREATE TABLE "openlearnm"."lms"
(
    school_id   integer,
    id_site           integer,
    code_module       varchar(5),
    code_presentation varchar(5),
    activity_type     varchar(20),
    week_from         smallint,
    week_to           smallint
    )
DISTSTYLE AUTO
SORTKEY AUTO
ENCODE AUTO;

要导入样本学生信息数据集的多租户版本，请使用如下命令，如示例 7-10 所示。

示例 7-10. 为学生信息数据创建模式和表

COPY "openlearnm"."assessments"
FROM 's3://openlearnm-redshift/assessments'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearnm"."courses"
FROM 's3://openlearnm-redshift/courses'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearnm"."student_assessment"
FROM 's3://openlearnm-redshift/studentAssessment'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearnm"."student_info"
FROM 's3://openlearnm-redshift/studentInfo'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearnm"."student_registration"
FROM 's3://openlearnm-redshift/studentRegistration'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearnm"."student_lms"
FROM 's3://openlearnm-redshift/studentlms'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

COPY "openlearnm"."lms"
FROM 's3://openlearnm-redshift/lms'
iam_role default
delimiter ',' region 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

池模型

池模型代表了一个全面、多租户的模型，其中所有租户共享相同的存储结构，并且在简化 AaaS 解决方案方面提供了最大的好处。通过这种模型，数据存储集中在一个数据库中，所有租户的数据存储在相同的数据模型中。数据安全是使用池模型需要解决的主要方面之一，以防止跨租户访问。您可以实现基于行级过滤，并使用数据库视图提供对数据的安全访问，并根据通过使用current_namespace变量查询数据的租户应用动态过滤。为了限定和控制对租户数据的访问，添加一个列(consumer_namespace)作为每个租户的唯一标识符。

让我们继续通过用例并向学校表添加consumer_namespace来控制从各学校的订阅者通过他们的 Amazon Redshift 数据仓库访问的情况。当您运行示例 7-11 中的查询时，您可以看到consumer_namespace对每所学校都有唯一的值。

示例 7-11. 学校映射到consumer_namespace

SELECT * FROM openlearnm.school;

school_id	school_name	address	city	website_url	consumer_namespace
101	纽约公立学校	null	New York	www.nyps.edu	xxxxc8ee-f6a5-xxxx-xxxx-yyyy66d7zzzz
102	加利福尼亚公立学校	null	Sacramento	www.caps.edu	xxxxc7ee-xxxx-468f-xxxx-yyyy77d7zzzz

图 7-10 说明了池模型架构。

图 7-10. 使用数据共享的池模型多租户架构与单个数据仓库方法进行比较

在生产者中创建数据库视图

对于多租户架构，您可以像我们之前在“构建星型模式”中所做的那样创建一个物化视图。但是在这里，您包括学校表，并在where子句中使用school_id来管理行级安全性。您可以使用示例 7-12 中的脚本为多租户池模型创建物化视图。请注意，我们使用了一个不同的模式openlearnm来存储与多租户模型相关的数据库对象。

示例 7-12. 学生活动：total_score和mean_score

CREATE materialized view openlearnm.mv_student_lmsactivites_and_score AS
SELECT st.school_id, st.id_student, st.code_module,st.code_presentation, st.gender,
  st.region, st.highest_education, st.imd_band,st.age_band,st.num_of_prev_attempts,
  st.studied_credits, st.disability, st.final_result, st_lms_clicks.sum_of_clicks,
  scores.total_score, scores.mean_score
FROM openlearnm.student_info st
  LEFT JOIN
    (SELECT school_id, code_module, code_presentation,
      id_student, sum(sum_click) AS sum_of_clicks
    FROM openlearnm.student_lms
      GROUP BY school_id, code_module,code_presentation,id_student) st_lms_clicks
    ON st.school_id = st_lms_clicks.school_id
    AND st.code_module = st_lms_clicks.code_module
    AND st.code_presentation = st_lms_clicks.code_presentation
    AND st.id_student = st_lms_clicks.id_student
    LEFT JOIN
      (SELECT school_id, id_student, sum(score) AS total_score,
        avg(score) AS mean_score
        FROM openlearnm.STUDENT_ASSESSMENT
        GROUP BY school_id, id_student)  scores
        ON st.school_id = scores.school_id
        AND st.id_student = scores.id_student;

要控制和限制行级访问权限，仅允许学生从其所在学校访问的数据，您可以创建一个视图 v_student_lmsactivites_and_score，并根据查询数据的消费者命名空间过滤记录。示例 7-13 中的视图是 mv_student_lmsactivities_and_score 和表 school 的连接，并且有一个基于 current_namespace 进行值过滤的 where 条件。系统变量 current_namespace 包含了发起查询的消费者数据仓库的命名空间值。

示例 7-13. 创建用于计算学生分数的视图

/* create view to calculate student activities total_score mean_score  */
/* use current_namespace system variable to use the consumer namespace */
/* from where the query is run to filter the selected records for the school */

CREATE VIEW openlearnm.v_student_lmsactivites_and_score AS
SELECT mvs.school_id, mvs.id_student, mvs.code_module,
  mvs.code_presentation, mvs.gender, mvs.region, mvs.highest_education,
  mvs.imd_band, mvs.age_band, mvs.num_of_prev_atteempts,
  mvs.studied_credits, mvs.disability,mvs.final_result,
  mvs.sum_of_clicks, mvs.total_score, mvs.mean_score
FROM openlearnm.mv_student_lmsactivites_and_score mvs
  LEFT JOIN openlearnm.school s
    ON mvs.school_id = s.school_id
WHERE s.consumer_namespace = current_namespace;

生产者中创建数据共享并授予消费者使用权限

现在您可以创建一个数据共享并与消费者共享视图了。连接到您的生产者数据仓库，创建数据共享 learnsharem，添加 openlearn 模式，并添加您创建的视图以与消费者共享，如示例 7-14 中所示。在 GRANT USAGE 语句中，用消费者数据仓库的命名空间替换 consumer namespace。

示例 7-14. 设置生产者数据共享

CREATE DATASHARE learnsharem;

ALTER DATASHARE learnsharem
  ADD SCHEMA openlearnm;

ALTER DATASHARE learnsharem
  ADD TABLE openlearnm.v_student_lmsactivities_and_score;

Grant USAGE ON DATASHARE learnsharem
  TO NAMESPACE '<<consumer namespace>>'

注意数据共享的名称以 m 结尾，这是一个命名约定，用于区分您之前创建的 learnshare 数据共享的多租户模式模式。

现在连接到您的消费者，创建一个引用生产者上数据共享的数据库，如示例 7-15 所示。再次注意，这个数据库只是指向数据共享的指针，并不存储任何数据。

示例 7-15. 从远程数据共享创建本地数据库

CREATE DATABASE openlearnm_db
FROM DATASHARE learnsharem
OF NAMESPACE '<producer_namespace>';

创建数据库后，您可以使用 db_name.schema.view 的三部分表示法实时查询数据，如示例 7-16 所示。当从消费者查询时，请注意，即使没有 where 子句来过滤特定记录，返回的数据也只会是与发起查询的消费者集群对应的学生的数据。这在视图级别进行控制，根据连接到学校表的 consumer namespace 限制数据。

示例 7-16. 查询视图

SELECT *
FROM openlearnm_db.learnsharem.v_student_lmsactivities_and_score;

当您从视图 v_student_lmsactivities_and_score 中选择时，您将只看到与用于查询数据的消费者命名空间相关联的数据。当此查询从消费者传递到生产者时，current_namespace 变量将具有此消费者的命名空间。因此，物化视图将根据与学校表的连接条件仅过滤来自此消费者的记录。

要详细了解如何设置和测试多个消费者，请参考博客 “在 Amazon Redshift 中使用数据共享实现多租户模式”。

使用角色级安全性

而不是使用在生产者上定义的数据库视图，你可以使用建立在 基于角色的访问控制（RBAC） 基础上的行级安全（RLS），以限制每个消费者的行。RLS 允许你控制哪些用户或角色可以根据在数据库对象级别定义的安全策略访问特定记录的数据。Amazon Redshift 中的这种 RLS 能力使你能够动态过滤表格中现有的数据行。

使用之前的示例，假设 school 表仍然具有 consumer_namespace 字段，但所有表格都与所有消费者共享。可以定义如 Example 7-17 中所示的以下 RLS 策略，并强制在与 school 表进行连接时仅返回 consumer_namespace = current_namespace 的学校。

Example 7-17. 创建行级安全策略

CREATE RLS POLICY consumer
WITH (school_id int)
USING (school_id = (
  SELECT school_id
  FROM school
  WHERE consumer_namespace = current_namespace));

GRANT SELECT ON
  student,
  course_outcome,
  course_registration,
  degree_plan
TO RLS POLICY consumer;

接下来，你可以像在 Example 7-18 中展示的那样，将此策略附加到包含 school_id 字段的任何表格，并且任何关联到数据库角色 school 的用户都将应用此策略，并且只能看到他们自己的数据。

Example 7-18. 将策略关联到对象角色

ATTACH RLS POLICY consumer ON student TO ROLE school;
ATTACH RLS POLICY consumer ON course_outcome TO ROLE school;
ATTACH RLS POLICY consumer ON course_registration TO ROLE school;
ATTACH RLS POLICY consumer ON degree_plan TO ROLE school;

桥接模型

在桥接模型中，你可以将每个租户的数据存储在其自己的架构中，这些架构与具有类似表格集合的数据库相似。你为每个架构创建数据共享，并将其与相应的消费者共享，以便将每个架构的查询工作负载路由到消费者。这是在独立模型和池模型之间寻求平衡的一种吸引人方法，既提供了数据隔离，又在不同架构之间复用了 ETL 代码。在 Amazon Redshift 中，你可以创建高达 9,900 个架构，因此，如果你的使用情况需要超过此限制，可以考虑创建更多数据库。有关更多信息，请参阅 Amazon Redshift 中的配额和限制。Figure 7-11 说明了桥接模型。

Figure 7-11. 桥接模型多租户架构与数据共享相比单一数据仓库方法

创建生产者中的数据库架构和表格

让我们继续使用之前的用例。就像在池模型中所做的那样，第一步是在生产者中创建数据库架构和表格。登录到生产者并为每个租户创建单独的架构。例如，你可以创建两个架构，learnschema_school1 和 learnschema_school2，用于存储来自两所不同学校的学生数据，并在每个架构下创建与 Example 3-1 中相同的表格。为了最大化 ETL 代码的复用性，请确保所有架构中的数据模型保持一致。

在生产者中创建数据共享并授予消费者使用权限

要在桥接模型中创建数据共享，创建两个数据共享，learnshare-school1和learnshare-school2，并将学校 1 和学校 2 的各自模式中的所有表添加到各自的数据共享中。然后，为消费者授予访问相同帐户或不同帐户中相应消费者数据的访问权限。

创建两个数据共享，learnshare-school1和learnshare-school2，以共享两个模式下的数据库对象给各自的消费者，如示例 7-19 所示。

示例 7-19。创建数据共享

CREATE DATASHARE learnshare-school1;
CREATE DATASHARE learnshare-school2;

修改数据共享并添加各租户的模式及相应要共享的表，使用示例 7-20 中的脚本。

示例 7-20。向数据共享添加对象

ALTER DATASHARE learnshare-school1
  ADD SCHEMA learnschema_school1;

ALTER DATASHARE learnshare-school2
  ADD SCHEMA learnschema_school2;

ALTER DATASHARE learnshare-school1
  ADD ALL TABLES IN SCHEMA learnschema_school1;

ALTER DATASHARE learnshare-school2
  ADD ALL TABLES IN SCHEMA learnschema_school2;

现在，授予第一个学校learnshare-school1的数据共享使用权限，使其能够访问学校 1 的消费者数据仓库的命名空间，如示例 7-21 所示。

示例 7-21。允许访问数据共享

GRANT USAGE ON DATASHARE learnshare-school1
  TO NAMESPACE '<consumer1_namespace>';

要访问学校 1 的消费者数据，请登录第一个学校的数据仓库，并使用示例 7-22 中的脚本引用数据共享创建数据库。您还可以从SVV_DATASHARES系统视图查看数据共享，或使用SHOW DATASHARES命令。如果要查看每个数据共享中的对象列表，可以通过查询SVV_DATASHARE_OBJECTS系统视图查看详细信息。

示例 7-22。从远程数据共享创建本地数据库

CREATE DATABASE learndb_school1
  FROM DATASHARE learnshare-school1
  OF NAMESPACE '<producer_namespace>';

SELECT *
  FROM learndb_school1.learnschema_school1.v_student_lmsactivities_and_score;

SHOW DATASHARES;

SELECT * FROM SVV_DATASHARES;

SELECT * FROM SVV_DATASHARE_OBJECTS;

在桥接模型中，由于各学校的数据库对象都组织在各自的模式下，并且数据共享只包含各学校的相应模式，因此消费者只能访问与该学校相关的数据库对象。在此示例中，学校 1 将限制仅从learnschema_school1查询数据。

筒仓模型

第三个选项是在数据仓库中为每个租户存储数据于单独的数据库中，如果您希望具有不同的数据模型和单独的监控、管理和安全足迹——筒仓模型。Amazon Redshift 支持跨数据库查询，允许您简化数据组织。您可以将所有租户使用的通用或粒度数据集存储在集中式数据库中，并使用跨数据库查询功能来连接每个租户的相关数据。

创建筒仓模型中的数据共享的步骤与桥接模型类似；但与桥接模型不同（其中数据共享是为每个模式），筒仓模型为每个数据库创建一个数据共享。图 7-12 展示了筒仓模型的架构。

图 7-12。与单一数据仓库方法相比的筒仓模型多租户架构

在生产者中创建数据库和数据共享

继续使用之前的用例。为生产者的 silo 模型创建 datashare，请完成以下步骤：

作为管理员用户登录到生产者并为每个租户创建单独的数据库，如示例 7-23。

示例 7-23. 创建数据库

CREATE DATABASE learndb_school1;
CREATE DATABASE learndb_school2;

再次登录到生产者数据库learndb_school1，使用第一所学校的用户 ID 创建模式learnschema，如示例 7-24。类似地，您可以使用第二所学校的用户 ID 登录到生产者数据库learndb_school2并创建模式learnschema。

示例 7-24. 创建模式

CREATE SCHEMA learnschema;

然后，使用示例 3-1 中的脚本，在每个数据库中为学生信息数据模型创建表，存储各自学校的学生数据。这种策略的一个好处是，因为架构和表名相同，ETL 过程可以仅通过更改数据库名称的连接参数进行重用。

在生产者中创建 datashare 并授予消费者使用权

接下来，创建 datashare，就像在“桥模型”中所做的那样，这次连接到每个数据库单独。对于第一所学校，您可以在示例 7-25 中执行脚本。

示例 7-25. 为第一所学校设置 datashare

CREATE DATASHARE learnshare-school1;
ALTER DATASHARE learnshare-school1 ADD SCHEMA learnschema;
ALTER DATASHARE learnshare-school1 ADD ALL TABLES IN SCHEMA learnschema;
GRANT USAGE ON DATASHARE learnshare-school1 TO NAMESPACE '<consumer1_namespace>';

对于第二所学校，您可以在示例 7-26 中执行此脚本。

示例 7-26. 为第二所学校设置 datashare

CREATE DATASHARE learnshare-school2;
ALTER DATASHARE learnshare-school2 ADD SCHEMA learnschema;
ALTER DATASHARE learnshare-school2 ADD ALL TABLES IN SCHEMA learnschema;
GRANT USAGE ON DATASHARE learnshare-school2 TO NAMESPACE '<consumer2_namespace>';

与 AWS ADX 集成的外部数据共享

对于某些用户来说，在账户内或账户之间共享数据已足够进行组织内协作，但对于跨组织协作和货币化用例，您可以使用 ADX。通过 ADX，您可以通过 datashare 从 Amazon S3 共享数据或直接从 Amazon Redshift 数据仓库查询数据。

AWS 数据交换 (ADX) 是一个数据市场，数据提供者可以在订阅基础上托管其数据产品，供订阅者访问。ADX 托管来自三百多个提供者的数据产品，并为数据提供文件、API 或 Amazon Redshift datashare 的订阅式访问。订阅者可以通过数据湖、应用程序、分析和使用数据的机器学习模型直接访问数据。作为 AWS 服务，ADX 安全合规，与 AWS 和第三方工具和服务集成，提供统一的计费和订阅管理。

通过其与 Amazon Redshift 的集成，您可以通过 ADX 许可访问 Amazon Redshift 数据。当您订阅带有 ADX datashare 的产品时，ADX 会自动将您添加为该产品中包含的所有 datashare 的数据消费者。您可以自动生成发票，并通过 AWS Marketplace Entitlement Service 集中和自动收取支付。

提供者可以在 Amazon Redshift 上以细粒度的级别许可数据，如模式、表、视图和 UDF。您可以在多个 ADX 产品中使用同一 ADX 数据共享。添加到 ADX 数据共享的任何对象都可供消费者使用。生产者可以使用 Amazon Redshift API 操作、SQL 命令和 Amazon Redshift 控制台查看由 ADX 代表其管理的所有 AWS Data Exchange 数据共享。订阅具有 ADX 数据共享产品的消费者对数据共享中的对象具有只读访问权限。

AWS Data Exchange 数据共享 是通过 ADX 分享数据的许可单位。AWS 负责管理与 ADX 订阅和使用 Amazon Redshift 数据共享相关的计费和付款。批准的数据提供者可以将 ADX 数据共享添加到 ADX 产品中。当您订阅具有 ADX 数据共享的产品时，您可以访问产品中的数据共享。我们将更详细地介绍 ADX 与 Amazon Redshift 集成的工作方式在“通过 AWS ADX 集成进行外部数据共享”中。获得批准的 ADX 数据共享提供者可以通过 ADX 将 ADX 数据共享添加并许可为产品。

当您订阅具有 AWS Data Exchange 数据共享的产品时，ADX 会自动将您添加为该产品中包含的所有 ADX 数据共享的数据消费者。当您的订阅结束时，ADX 也会将您从 ADX 数据共享中移除。ADX 与 AWS 计费集成，为具有 ADX 数据共享的付费产品提供统一的计费、发票、付款收集和付款分发。要注册为 ADX 数据提供者，请参阅作为提供者入门。

如果您是具有活动 ADX 订阅（也称为 ADX 订户）的消费者，则无需提取、转换和加载数据即可在 Amazon Redshift 中查找、订阅和查询细粒度、最新的数据。

如果您想使用第三方生产者数据，您可以浏览 AWS Data Exchange 目录，发现并订阅 Amazon Redshift 中的数据集。在您的 ADX 订阅激活后，您可以在他们的数据仓库中从数据共享创建数据库，并在 Amazon Redshift 中查询数据。

作为订阅者，您可以直接使用来自提供者的数据，无需进一步处理，无需 ETL 过程。因为您无需进行任何处理，数据始终是当前的，并可以直接用于您的 Amazon Redshift 查询中。ADX 为 Amazon Redshift 管理所有授权和付款，所有费用都计入您的 AWS 账户。

发布数据产品

要在 Amazon Redshift 中使用 ADX 发布数据产品，您可以创建连接到您的 Amazon Redshift 数据仓库的 ADX 数据共享。要将 ADX 数据共享添加到 ADX 产品中，您必须是注册的 ADX 提供者。

一旦注册为提供者，您可以创建 AWS Data Exchange 数据共享以将 Amazon Redshift 发布为数据交换中的数据产品。当您订阅包含数据共享的产品时，您将被授予只读访问权限，以访问数据提供者添加到数据共享的表、视图、模式和用户定义函数。

让我们来看看如何通过数据交换将学生的材料化视图作为数据产品共享。第一步是创建一个数据交换数据共享，你可以按照图 7-13 中所示使用控制台或脚本创建此数据共享。

图 7-13. 创建数据交换数据共享

然后添加数据共享的数据库对象；在这种情况下，选择mv_student_lmsactivities_and_score（参见图 7-14）。

图 7-14. 添加数据交换数据共享对象

一旦创建了数据共享并添加了数据库对象，你可以选择数据共享learnshare_adx并在 AWS Data Exchange 上创建一个数据集（参见图 7-15）。这个数据共享将在 AWS Data Exchange 上列出，供消费者订阅数据集。

图 7-15. 从 Redshift 数据共享创建 ADX 数据集

按照步骤创建数据集，并完成数据共享版本。现在你可以从数据集创建数据产品（参见图 7-16）。

图 7-16. 从数据集创建产品

欲了解详细步骤，请参阅有关如何发布包含 Amazon Redshift 数据集的数据产品的在线文档。

请注意，您需要注册成为市场销售商才能发布数据产品。如果您希望提供付费产品并且符合条件，必须提交税务和银行信息。

订阅已发布的数据产品

如果你想从第三方生产商那里获取数据产品，可以使用 AWS Data Exchange 订阅来访问数据。如果你是一个有着活跃 ADX 订阅的订阅者，可以在 ADX 控制台上浏览 ADX 目录，发现包含 ADX 数据共享的产品（参见图 7-17）。在 ADX 订阅激活后，可以在他们的数据仓库中从数据共享创建数据库，并在 Amazon Redshift 中查询数据。

图 7-17. 在 ADX 上浏览数据产品

订阅包含 AWS 数据交换数据共享的产品后，在您的数据仓库中创建来自数据共享的数据库。然后，您可以直接在 Amazon Redshift 中查询数据，无需提取、转换和加载数据。将 ADX 数据共享添加到 ADX 产品后，消费者在订阅开始时自动获得对产品数据共享的访问，并在其订阅有效期内保持访问权限。

欲了解更多信息，请参阅关于 作为消费者使用 AWS 数据交换数据共享 的在线文档。

使用 AWS 数据交换服务（AWS Data Exchange）用于 Amazon Redshift 时的注意事项

使用 AWS 数据交换服务（AWS Data Exchange）用于 Amazon Redshift 时，请考虑以下内容：

• 生产者和消费者必须使用 RA3 节点类型才能使用 Amazon Redshift 数据共享（datashares）。生产者必须使用 RA3 节点类型或者使用无服务器方式，同时生产者和消费者数据仓库必须加密。

• 您必须注册为 ADX 提供者才能在 ADX 上列出产品，包括包含 ADX 数据共享的产品。欲了解更多信息，请参阅 作为提供者入门。

• 您不需要注册为 ADX 提供者即可查找、订阅和查询通过 ADX 访问的 Amazon Redshift 数据。

• 要控制通过 ADX 数据共享访问您的数据，必须打开“公开访问”设置。这并不意味着您的数据共享是公开的，或者消费者的数据仓库是公开的，但这意味着他们被允许将其公开。要更改 ADX 数据共享，请使用 ALTER DATASHARE SET PUBLICACCESSIBLE FALSE 命令关闭“公开访问”设置。

• 生产者不能手动添加或移除 ADX 数据共享的消费者，因为对数据共享的访问是基于订阅包含 ADX 数据共享的 ADX 产品而授予的。

• 生产者无法查看消费者运行的 SQL 查询。他们只能通过只有生产者可以访问的 Amazon Redshift 表查看元数据，例如查询的数量或消费者查询的对象。生产者可以利用这些信息了解订阅者如何使用其产品，并根据数据使用模式做出决策。

• 我们建议您不要使用 DROP DATASHARE 语句删除共享给其他 AWS 帐户的 ADX 数据共享（datashare）。如果这样做，可以访问该数据共享的 AWS 帐户将失去访问权限。此操作是不可逆转的。执行此类更改可能违反 ADX 数据产品条款。

• 要进行跨区域数据共享，您可以创建 ADX 数据共享以共享许可的数据。

我们建议您将您的数据共享（datashares）设置为公开访问。如果不这样做，AWS 数据交换的订阅者无法使用您的数据共享，即使他们的消费者数据仓库是公开访问的。

从数据湖（Data Lake）查询并卸载到数据湖

你可能有使用情况，想要将在数据仓库中策划的数据与外部应用程序共享。因为 Amazon Redshift 与数据湖集成，你可以采取数据仓库优先的方法，先将数据存储在你的数据仓库中，根据需要将数据卸载到数据湖中。由于 Amazon Redshift 支持存储和计算的解耦，它可以在数据仓库中每个节点最多存储 128TB 的大容量数据。因此，对于 OLAP 工作负载，你可以将所有数据存储在你的数据仓库中。当你想要与 Amazon Redshift 数据仓库中的其他服务（如 Amazon SageMaker）共享数据时，可以使用UNLOAD选项，将数据从 Amazon Redshift 本地表卸载到 Amazon S3 中。在卸载到 Amazon S3 时，可以直接转换为推荐的格式如 Parquet 或 ORC，并与其他服务共享。

对于UNLOAD命令的一般语法，请参考UNLOAD 命令文档。使用运行示例，如果你想要与使用其他服务访问数据的合作伙伴或用户共享学生学习管理参与情况，那么你可以使用UNLOAD命令卸载学生活动数据，如示例 7-27 所示。

示例 7-27. UNLOAD示例

UNLOAD ('select * from mv_student_lmsactivities_and_score')
TO 's3://openlearn/studentactivities'
IAM_ROLE default
PARQUET
PARTITION BY (school_id);

你还可以使用INSERT INTO SELECT查询将结果加载到现有的外部表中，这些表位于外部目录，如示例 7-28 所示，适用于 AWS Glue、AWS Lake Formation 或 Apache Hive 元存储。使用与CREATE EXTERNAL SCHEMA命令相同的 AWS IAM 角色与外部目录和 Amazon S3 交互。有关使用插入到外部表命令的详细步骤，可以参考将SELECT查询结果插入到外部表中的文档。

示例 7-28. 将数据写入外部表

INSERT INTO external_schema.table_name
{ select_statement }

Amazon DataZone 用于发现和共享数据

数据仓库通常指通过将来自多个来源系统的详细事务数据转移并将数据合并到一个单一的真实数据源来构建集中式数据存储。详细数据通过应用业务规则进行转换，并以聚合的格式存储，以实现快速查询性能。围绕去中心化数据管理和治理，数据管理的相对较新架构已经发展。这就是数据网格架构，你可以在“数据网格”中了解更多。数据网格采纳了数据的去中心化所有权，旨在实现无需移动或复制数据即可轻松访问数据的目标。

数据生产者是专业领域专家，创建数据资产并定义数据目录，为便于使用添加业务定义，并按数据领域组织。然后在数据目录中注册数据产品，以便消费者搜索和访问与其业务需求相关的数据。作为提醒，数据网格架构的四个关键概念是：

• 面向域的数据所有权

• 联合数据治理

• 自助数据基础设施

• 数据作为产品思维

在接下来的部分，您将看到 Amazon DataZone 组件如何实现构成数据网格架构的关键能力。

使用 Amazon DataZone 的数据网格架构用例

数据网格架构有许多用例，特别适用于具有多条业务线或需要跨业务部门共享数据的组织。以下是一些示例。

作为现代化战略的一部分，一家大型金融组织着手将其遗留的本地工作负载迁移到 AWS 云上，包括 Amazon Redshift 和 Amazon S3 等托管服务。他们选择在 AWS 云上构建现代数据平台，作为分析、研究和数据科学的中央数据存储。此外，该平台还用于治理、监管和财务报告。最初设计是将所有业务数据存储在中央数据存储和中央 AWS 账户中，但在使数据可访问方面遇到了限制和复杂性。

为了解决大型数据存储的成长痛点和需求，他们将数据存储和相关管理功能的所有权分散并委托给各自的业务部门。数据网格架构使他们能够在各自的账户中保留各业务部门的数据，同时以安全的方式实现跨业务部门账户的无缝访问。他们重新组织了 AWS 账户结构，为每个业务部门设置了单独的账户，在亚马逊 Redshift 和亚马逊 S3 中的相应 AWS 账户中共同定位了业务数据和依赖应用程序。通过这种分散化模型，业务部门独立管理其数据的水合、策展和安全责任。

一家投资银行组织拥有多个业务部门和公司职能，需要一种架构来在企业内自由共享数据，同时管理未经授权访问的风险。他们采取了双管齐下的方法来解决这一需求。首先，通过定义数据产品，由了解数据及其管理需求、允许使用和限制的人员策展。其次，通过实施数据网格架构，使他们能够将其数据技术与这些数据产品对齐。

医疗机构可以创建一个数据产品，提供实时患者监控数据，各部门如急诊服务、患者护理和研究都可以使用。在学校系统中，学生数据存储在学生信息系统中，IT 部门可以是数据的生产者，各个学校将订阅与其学生相关的数据。您可以构建数据网格架构，使教师、学生和管理员能够安全地协作和共享数据，采用生产者-消费者模型。零售公司可能为销售、库存、客户数据和营销设立单独的领域。每个领域可以有自己的数据团队负责收集、存储和分析特定领域的数据。采用数据网格架构将使每个领域能够拥有和管理自己的数据，从而能够独立做出数据驱动的决策。

这些只是数据网格架构实际应用的几个例子。主要目标是分散数据管理，赋予领域团队权力，并在组织内创建可伸缩和可持续的数据生态系统。

亚马逊数据区的关键能力和使用案例

亚马逊数据区是一项数据管理服务，采用数据网格架构，使数据生产者能够发布数据产品，并通过 Web 界面将其提供给业务数据目录。一旦数据产品发布，用户可以通过简化的方式搜索数据。使用亚马逊数据区目录，您可以使数据在业务背景下可见，快速找到并理解数据。您可以基于团队、分析工具和数据资产的分组创建业务用例，以简化访问 AWS 分析工具。通过自动化的发布/订阅工作流，您可以调整数据所有权以保护生产者和消费者之间的数据。

您可以设置安全策略，确保具有正确权限的人员可以访问您的数据。使用亚马逊数据区，您可以实现联合数据治理，数据集的数据所有者和主题专家可以对其相关数据资产实施安全和访问控制。您可以扩展在 AWS Glue 数据目录、IAM 和 Lake Formation 中设置的治理控制。亚马逊数据区支持通过 Amazon Redshift、Amazon Athena、AWS Glue、AWS Lake Formation 和 Amazon QuickSight 等 AWS 服务进行数据访问和数据共享。

亚马逊数据区与亚马逊 Redshift 及其他 AWS 服务的集成

亚马逊数据区本身不存储任何数据，它作为元数据中心，实现跨数据集的数据访问便利化。为了数据访问，亚马逊数据区必须与存储、访问和控制数据的现有 AWS 服务集成。在编写本书时，它支持与其他 AWS 服务的三种集成类型：

生产者数据源

从生产者的角度看，亚马逊数据区集成了存储在亚马逊 S3 数据湖或亚马逊 Redshift 中的数据。您可以将数据资产发布到亚马逊数据区目录，从存储在亚马逊 S3 和亚马逊 Redshift 表格和视图中的数据。您还可以手动将 AWS Glue 数据目录中的对象发布到亚马逊数据区目录中。

消费者工具

您可以通过亚马逊 Redshift 查询编辑器或亚马逊 Athena 访问数据资产，通过亚马逊 Redshift 中的外部表格。

访问控制和履行

使用亚马逊数据区，您可以授予对由 AWS Lake Formation 管理的 AWS Glue 表格和亚马逊 Redshift 表格和视图的访问权限。此外，亚马逊数据区将与您的操作相关的标准事件连接到亚马逊 EventBridge。您可以使用这些标准事件与其他 AWS 服务或第三方解决方案进行自定义集成。

亚马逊数据区的组件和能力

AWS 引入了“domain”的概念，用于帮助组织与这些资产相关的数据资产和资源。亚马逊数据区域域提供了灵活性，以反映您组织的业务领域和实体，包括数据资产、数据来源、元数据、业务术语表以及关联的 AWS 账户。亚马逊数据区的四个关键组件使得通过发布到中央目录的数据产品来跨业务领域安全访问数据变得可能：

• 商业数据目录

• 项目

• 治理和访问控制

• 数据门户

我们接下来讨论这些组件，它们是您创建的域的一部分，如图 7-18 所示。

图 7-18. 亚马逊数据区组件

要最初设置亚马逊数据区（Amazon DataZone）及其数据门户，您将创建一个作为根域的域。在数据门户内，域管理员可以创建额外的域。这些组件共同工作，提供功能，使您能够构建和操作具有分散数据治理的数据网格架构；这些将在接下来的章节中讨论。

商业数据目录

亚马逊数据区的核心组件是一个带有商业友好描述的元数据目录。当数据生产者发布数据产品时，该目录会被构建，并且随着新产品准备就绪而增长。该目录可以来自不同数据源的数据。数据集发布到目录后，消费者可以通过亚马逊数据区门户（如图 7-24 所示）搜索所需数据。

亚马逊数据区使用机器学习自动在编目数据资产时建议商业术语。此自动化减少了添加可搜索业务术语到技术数据所需的手动工作。

项目

Amazon DataZone 为团队引入数据项目，以便协作并获取访问数据资产。通过项目，组织内的一组用户可以在 Amazon DataZone 目录中发布、发现、订阅和使用涉及的各种业务用例。您使用项目作为身份主体来接收对底层资源的访问授予，而不是依赖于个人用户凭据。每个项目都有一组应用于其的访问控制，以便只有经授权的个人、组和角色可以访问该项目及该项目订阅的数据资产，并且只能使用项目权限定义的工具。项目与具有特定能力的项目配置文件相关联，可作为消费者或生产者或两者行为。您可以使用数据项目通过使用审计能力来管理和监控跨项目的数据资产。

使用数据项目，您可以创建和访问数据、人员和工具的业务用例分组，团队可以使用这些分组协作。项目视图中可用的一些组件包括：

已订阅数据

这包括所有已批准、待处理和已授予的订阅请求。

发布

这包括所有已发布的数据、订阅请求、发布作业和所有协议。

成员

包括此项目的成员及其各自的角色。

设置

提供项目的详细信息，如 ID、账户、VPC 和项目的能力。

项目成员可以安全地协作、交换数据和共享工件，只有明确添加到项目中的人员才能访问其中的数据和分析工具。项目通过数据监管人员施加的策略管理生成的数据资产的所有权，通过联邦治理去中心化数据所有权。

数据治理和访问控制

自动化工作流程允许消费者请求访问他们在业务目录中找到的数据产品。此请求将路由到数据生产者或数据所有者以进行批准。当生产者批准请求时，消费者将收到通知，并可以在无需任何手动干预的情况下访问数据。数据生产者可以简化审计以监控谁正在使用每个数据集，并跨项目和 LOB（业务线）监控使用和成本。您可以在下一节中找到发布和订阅的示例步骤。

数据门户

门户是控制台之外的个性化主页，提供自助服务功能，消费者可以在目录中搜索数据。数据门户是用户访问 Amazon DataZone 的主要方式，是一个基于浏览器的 Web 应用程序，您可以在其中编目、发现、管理、共享和分析数据。这使得用户能够在使用现有身份提供者的凭据时，使用数据和分析工具进行跨部门协作。

使用该门户，你可以访问数据资产的个性化视图。在图 7-19 中，你可以看到工作流程中请求的各种订阅状态。你可以分析数据，无需登录 AWS 管理控制台或了解底层 AWS 分析服务。

图 7-19. 不同订阅状态下的数据产品个性化视图

Amazon DataZone 入门

采用数据网格架构不仅仅是技术问题；它需要一种心态的转变。你必须组织你的团队，并在你的组织中实施流程，向生产者-消费者模型迈进。域通过提供一种机制来为在业务数据目录中产生和编目数据的团队灌输组织纪律，从而实现更简单的过渡。任何数据生产者都可以将数据资产发布到管理数据的特定域的目录中，并控制可以访问该域的消费者的访问权限。一个域可以与每个业务用例相关联，其中人们可以协作和访问数据。

本节将带你创建 Amazon DataZone 的根域，并获取数据门户的 URL。然后，将带你通过数据生产者和数据消费者的基本工作流程。详细设置 Amazon DataZone 的步骤，请参阅“入门文档”。具体步骤如下。

步骤 1: 创建域和数据门户

要开始使用 Amazon DataZone，第一步是创建一个域。域是 Amazon DataZone 对象的集合，如数据资产、项目、相关的 AWS 账户和数据源。域是你和你的团队可以创建所有相关 Amazon DataZone 实体的容器，包括元数据资产。你可以使用特定的域将数据资产发布到目录，并控制可以访问该域的相关 AWS 账户和资源的访问权限。

步骤 2: 创建生产者项目

要作为生产者创建和发布数据产品，你需要创建一个项目，该项目将组织数据产品和相关资产。创建项目时，你需要指定项目配置文件和数据源连接详细信息。项目配置文件确定项目的能力，以及项目是作为生产者、消费者还是两者兼而有之；连接详细信息用于数据源。因此，在创建项目之前，你需要创建一个项目配置文件和一个 AWS Glue 连接。你可以通过选择“目录管理”菜单并选择“项目和账户”选项卡来创建项目配置文件。

对于数据仓库生产者，您需要输入额外的信息，如亚马逊 Redshift 集群名称和 AWS Glue 连接详细信息。如果您还没有 AWS Glue 连接，您可以创建一个 Glue 连接到数据源，并在项目中指定连接详细信息。您将从项目发布您生成的数据到目录，并且消费者也将通过项目访问数据。

要创建项目，请使用数据门户网址导航至亚马逊数据区（Amazon DataZone）数据门户，并使用您的单一登录（SSO）或 AWS 凭据登录。在这里，您可以转到“我的项目”菜单，并点击+号以创建新项目，如图 7-20 所示。如果您是亚马逊数据区管理员，您可以通过访问亚马逊数据区控制台（位于创建亚马逊数据区根域的 AWS 账户中）获取数据门户网址。

图 7-20. 使用特定数据域创建项目

您还可以通过选择“浏览所有项目”查看所有数据项目。项目列表如图 7-21 所示。

图 7-21. 在特定数据域下列出项目

第 3 步：为在亚马逊数据区发布数据而生成数据

在将数据资产发布到数据目录之前，您需要创建要与消费者共享的数据对象和数据。从您在上一步创建的生产者项目中，您点击“分析工具”下的“查询数据 - 亚马逊 Redshift”，如图 7-22 所示，并登录到亚马逊 Redshift 集群以创建数据表并设置数据。这将带您进入亚马逊 Redshift 查询编辑器 V2，并使用“联合用户”选项登录数据仓库。在这里，您可以创建数据库对象和数据。如果已经有表格，您可以选择在发布数据产品时包含这些表格。

图 7-22. 在生产者中创建数据产品

第 4 步：向目录发布数据产品

当生产者准备好数据产品后，他们可以发布到业务数据目录，供消费者搜索和订阅。要发布，您将选择生产者项目并选择“发布数据”。发布通过具有发布协议的作业完成。您可以通过选择发布选项卡并在其中选择发布协议来从希望发布数据产品的项目创建发布协议。发布过程通过作业触发，并且您也可以监控该作业。在我们的学生示例中，当学生绩效数据产品的生产者准备好后，他们可以发布到目录中，如图 7-23 所示。有关发布数据的详细步骤，请参阅在 Amazon DataZone 发布数据的文档。

图 7-23. 发布学生绩效数据产品

步骤 5：创建消费者项目

为了让消费者订阅底层数据产品，项目再次作为一个身份主体，接收对底层资源的访问授权，而不依赖于个人用户凭据。要让消费者订阅生产者生成的数据，您需要创建一个带有消费者配置文件的消费者项目。在消费者配置文件中，您将在创建消费者配置文件时添加数据仓库消费者能力。当用户通过门户在目录中识别数据集时，用户需要在请求数据集访问之前选择消费者项目。Amazon DataZone 将根据访问控制集验证请求，并仅授权能够访问项目和数据资产的个人、组和角色。

步骤 6：在 Amazon DataZone 中发现和消费数据

一旦您将数据资产发布到一个领域，订阅者可以使用 Amazon DataZone 门户发现并请求订阅此数据资产。当消费者想订阅数据产品时，他们首先需要在目录中搜索并浏览他们想要的资产，如图 7-24 所示。消费者选择消费者项目并在搜索框中输入关键词以搜索数据产品。Amazon DataZone 将搜索所有已发布的目录，并返回与关键词匹配的数据产品列表。搜索列表根据编目的数据返回结果。消费者可以选择他们想要的数据集，并在业务词汇表中了解更多信息。确认所选数据集后，您可以请求访问并开始分析。

图 7-24. 在业务数据目录中搜索数据

您可以选择通过提交订阅请求订阅数据资产：按照图 7-25 中显示的订阅按钮，并包括请求的理由和原因。根据发布协议定义的订阅批准人员随后审查访问请求。他们可以批准或拒绝请求。有关详细步骤，请参阅发现和使用数据中的文档。

图 7-25. 订阅学生表现数据产品

步骤 7：作为生产者批准对发布数据资产的访问

生产者可以通过生产者项目批准消费者的请求访问。生产者可以通过导航到生产者项目并在发布选项卡下选择订阅请求选项卡，查看所有待批准的订阅请求。在这里，生产者可以批准并指定批准原因。这些信息将记录下来，以便将来跟踪授予批准的人员和批准请求的详细信息。

步骤 8：作为消费者分析发布的数据资产

一旦获得批准，订阅者可以使用消费者项目查看批准状态，并根据数据源类型和数据所在位置，使用 Amazon Athena 或 Amazon Redshift 查询编辑器查看数据。

在开始设置 Amazon DataZone 用于您的数据网格之前，请完成文档中的设置部分中描述的步骤。如果您使用全新的 AWS 账户，则必须配置 Amazon DataZone 管理控制台的权限。如果您使用具有现有 AWS Glue Data Catalog 对象的 AWS 账户，您还必须将数据湖权限配置为 Amazon DataZone。

Amazon DataZone 中的安全性

与其他 AWS 服务一样，AWS 的责任共享模型适用于 Amazon DataZone 中的数据保护。Amazon DataZone 提供了安全功能，您在制定和实施自己的安全策略时需要考虑这些功能。您可以使用这些最佳实践指南作为您的安全解决方案，但我们鼓励根据您的环境和安全需求采用这些实践。有关详细的安全配置，请参阅Amazon DataZone 安全用户指南中的文档。

使用基于 Lake Formation 的授权

Amazon DataZone 使用 Lake Formation 权限模型来授予访问权限。一旦项目订阅了资产，该资产需要由 Lake Formation 进行管理。将存储数据的 Amazon S3 存储桶添加到 Lake Formation 位置是切换权限模型的一部分。

Amazon DataZone 通过 AWS Lake Formation 抽象化数据生产者和消费者之间的数据共享过程，并自动化这一过程，通常需要手动完成。对于由 Amazon DataZone 管理的资产，根据数据发布者应用的策略来履行对底层表的数据访问，无需管理员或数据迁移即可完成。

加密

Amazon DataZone 默认使用 AWS KMS 密钥对服务元数据进行加密，由 AWS 拥有和管理。您还可以使用 AWS KMS 管理的密钥对存储在 Amazon DataZone 数据目录中的元数据进行加密。Amazon DataZone 在传输中使用传输层安全性（TLS）和客户端端到端加密进行加密。与 Amazon DataZone 的通信始终通过 HTTPS 进行，因此您的数据始终在传输过程中得到加密保护。

实施最小特权访问

Amazon DataZone 的典型用例是在您的组织内跨业务组共享数据。由于 Amazon DataZone 数据网格架构的基本假设是分散治理，因此在授予权限时保持最小特权访问原则更为重要。您需分析数据的生产者和消费者是谁，以及他们对 Amazon DataZone 资源需要哪些权限，并通过管理员相应地分配权限。您应该仅授予执行任务所需的权限。实施最小特权访问是降低安全风险和由错误或恶意意图可能导致的影响的基础。

使用 IAM 角色

Amazon DataZone 中生产者和消费者之间的通信通过 IAM 角色进行，类似于 AWS 服务之间的访问。生产者和客户端应用程序都必须具有有效的凭证，建议使用 IAM 角色来管理您的生产者和客户端应用程序访问 Amazon DataZone 资源的临时凭证。

不建议将 AWS 凭证直接存储在客户端应用程序中或 Amazon S3 存储桶中。这些是长期凭证，不会自动轮换，如果被泄露可能会对业务产生重大影响。

关于安全性的更多细节，请参阅Amazon DataZone 中的数据保护。

总结

本章讨论了如何通过 Amazon Redshift 数据共享在组织边界内和跨组织边界内实现无缝数据共享，并具备内置治理和访问控制。您学习了如何利用数据共享安全地向业务用户提供数据，让他们使用自己选择的工具分析数据以做出及时决策。通过数据共享而无需移动数据，消除了在 ETL 过程中可能出现的错误，保持了源数据的数据完整性，这些数据是您的用户用来做出关键业务决策的基础。

您学习了数据共享的各种用例，包括工作负载隔离、跨部门协作以及作为服务的分析，以及提高开发灵活性。您创建了三种多租户模型，用于学生信息数据集的不同隔离级别。最后，您了解了亚马逊数据区（Amazon DataZone）及如何使用该服务来实现去中心化数据治理模型。

在接下来的章节中，我们将介绍如何在您的分析环境中保护和治理数据。我们将详细讨论您可以应用于 Amazon Redshift 组件的各种访问控制，为您提供广泛和细粒度的控制。最后，我们将介绍如何设置对 Amazon Redshift 中可能使用的外部服务的访问控制，例如数据湖中的数据、运营数据库、流数据，以及 AWS Lambda 和 Amazon SageMaker 等其他 AWS 服务。

第八章：数据保护和管理

对于一家典型的财富 1000 强公司，数据可访问性仅增加 10%就能带来超过 6500 万美元的额外净收入。

Richard Joyce, Forrester¹

在本书中，我们已经讨论了数据的重要性，以及如何通过 Amazon Redshift 访问各种结构化或半结构化数据，无论是本地加载还是从外部源查询。然而，在成本效率的方式下访问和转换数据同样重要的是安全地执行此操作，确保只有合适的人员能够访问他们应该访问的数据。许多组织在使所有数据对用户可访问上存在困难。在数据不断扩展且对数据访问需求如此之高的世界中，实现这种访问性和安全性的平衡至关重要且具有挑战性。

在本章中，我们将讨论用户在 Amazon Redshift 中管理安全性的不同方法，包括“对象级访问控制”和“数据库角色”。我们将探讨用户群体需要细粒度访问控制的使用案例，以及如何通过“行级安全”和“动态数据遮蔽”来实现这一目标。最后，我们将讨论 Amazon Redshift 如何通过“外部对象访问控制”管理安全性。

对象级访问控制

Amazon Redshift 是一个对象层次结构组织的数据库系统，每个对象都由一组权限管理。如在第三章，“设置数据模型和数据导入”中所讨论的，Amazon Redshift 可以包含多个数据库，每个数据库可以包含多个模式（schemas），每个模式可以包含多个对象，例如表、视图、函数和过程。除了这些对象外，Amazon Redshift 还包含跨所有数据库适用的管理对象，如用户、组和角色。

用户是登录到数据库的个体主体。数据库组是用户的集合，用户可以是多个组的成员。最后，“数据库角色”类似于组，但具有额外的功能，我们将在本章后面讨论。用户、数据库组或数据库角色使用GRANT或REVOKE语句分配对象的权限。请参阅表 8-1 以获取权限列表及其适用的对象。有关执行GRANT语句的详细信息，请参阅在线文档。注意，您可以将UPDATE和SELECT权限应用于数据库列。在限制对个人可识别信息（PII）数据访问时，这种授权策略非常有用。

表 8-1. 对象权限

Privilege	Object
INSERT,DELETE,DROP,REFERENCES	TABLE
UPDATE	表,列
SELECT	表,视图,列
EXECUTE	函数,过程
CREATE	数据库,模式
TEMP	数据库
USAGE	语言,模式
CREATE MODEL,EXECUTE	模型
ALTER,SHARE	数据共享

作为最佳实践，将权限授予数据库组或数据库角色，而不是直接授予用户权限。为了进一步扩展权限管理，考虑通过单点登录从公司身份提供者传递用户、组和角色信息，以管理用户与数据库组和角色的分配。使用 SSO 将确保基于组成员资格授予权限，这可以在中央位置进行控制。有关详细信息，请查阅第 2 章，“开始使用 Amazon Redshift”中的连接部分。

对象所有权

除了通过GRANT分配给对象的特权之外，对象的所有者隐含地获得所有对象的特权。除了对象特权之外，对象所有者在对象上还具有管理特权；例如，所有者可以运行ALTER TABLE或REFRESH MATERIALIZED VIEW语句(示例 8-1)。在某些情况下，您可能需要更改对象的所有者。要执行此操作，对象所有者可以执行ALTER语句。

示例 8-1. 对象所有权

ALTER TABLE table1 OWNER TO user1;

如果用户拥有对象，则无法DROP该用户。最佳实践是限制用户可以创建对象的位置，以便轻松识别用户拥有的所有对象。例如，您可以授予与用户关联的模式的CREATE权限，但是共享模式的SELECT权限。

在创建 Amazon Redshift 数据仓库时，您会被提示输入一个具有超级用户特权的管理员用户。超级用户将拥有与对象所有者类似的所有权限。此用户还不受您在对象级别定义的访问控制的约束。此外，超级用户可以创建其他超级用户或通过创建或修改带有CREATEUSER属性的用户来将用户的权限提升为超级用户(示例 8-2)。

示例 8-2. 超级用户特权

CREATE USER adminuser CREATEUSER PASSWORD '1234Admin';
ALTER USER adminuser CREATEUSER;

作为最佳实践，不要将超级用户用于日常活动。应将适当的权限分配给数据库组和/或数据库角色，以清楚地显示授予哪些权限给哪些用户社区。

默认特权

为了使GRANT管理更加方便，您可以设置任何显示在表 8-2 中的默认特权，这样用户或架构中创建的任何对象都将授予另一个用户、组或角色的特权。有关如何授予或撤销默认特权的更多详细信息，请参阅在线文档。

表 8-2. 默认特权

特权	对象
INSERT,UPDATE,DELETE,DROP,REFERENCES	表
SELECT	表,视图
EXECUTE	函数,过程

公共模式和搜索路径

当您启动 Amazon Redshift 数据仓库时，在每个数据库中都会创建一个public模式，并且在 Amazon Redshift 中创建的每个用户将成为PUBLIC组的成员。默认情况下，PUBLIC组将对 Amazon Redshift 数据仓库中每个数据库中的public模式具有读/写访问权限。此策略允许用户在公共空间中进行协作，但要求必须显式授予任何额外模式的权限。此外，创建用户时，默认的search_path参数设置为$user,public。这意味着当引用没有数据库或模式限定符的对象时，Amazon Redshift 将首先在与用户 ID 匹配的模式中搜索，然后在public模式中搜索。该策略允许用户按照首选顺序在本地模式中处理数据集，而不是在公共模式中共享数据。正如在第三章，“设置数据模型和数据导入”中讨论的那样，将数据模型组织成专用模式仍然是最佳实践，这些模式代表一个主题区域，便于元数据管理，也简化了访问授权。这些模式也可以添加到用户的search_path中，以简化对共享数据的访问。

访问控制的实际应用

为了说明这些访问控制，让我们使用来自第三章的学生信息系统学习数据集，并遵循一个使用public模式存储共享数据的访问控制模型。public模式将对所有用户可读，但仅etluser可以写入。

要设置这些访问控制，首先禁用PUBLIC组对public模式的写入权限，以确保没有用户会意外修改共享表。示例 8-3 中的语句将删除任何现有的写入权限，并确保新对象的默认权限也将写入权限被撤销。注意：此语句不会撤销SELECT权限，这意味着PUBLIC组的成员仍然可以从public模式中读取数据。

示例 8-3. 撤销对PUBLIC组的模式写入权限

REVOKE INSERT,UPDATE,DELETE,DROP ON ALL TABLES
  IN SCHEMA public FROM GROUP PUBLIC;
REVOKE CREATE ON SCHEMA public FROM GROUP PUBLIC;
ALTER DEFAULT PRIVILEGES
  IN SCHEMA public REVOKE INSERT,UPDATE,DELETE ON TABLES FROM PUBLIC;

接下来，授予etluser对public模式的所有权限，并确保新对象的默认权限也将拥有所有权限（示例 8-4）。

示例 8-4. 授予用户模式写入权限

GRANT ALL ON ALL TABLES IN SCHEMA public TO etluser;
GRANT ALL ON SCHEMA public TO etluser;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT ALL ON TABLES TO USER etluser;

最后，让我们创建一个名为faculty_bob的用户，该用户将继承对public模式中数据的SELECT访问权限。我们还将创建一个与用户名匹配的模式，允许该用户创建数据的副本进行分析和操作（示例 8-5）。

示例 8-5. 创建用户模式并授予用户所有权限

CREATE USER faculty_bob PASSWORD '<your password>';
CREATE SCHEMA faculty_bob;
GRANT ALL ON SCHEMA faculty_bob TO USER faculty_bob;

具备权限后，假设etluser已加载public模式。查询示例 8-6 将按semester_id和lecture_duration返回student_cnt，并且将从public模式读取，无需显式引用它，无论您是作为faculty_bob还是etluser查询，都因为search_path以及因为这些表都不存在于用户模式中。

示例 8-6. 使用search_path选择共享表

SELECT
    co.semester_id,
    cs.lecture_duration,
    count(distinct co.student_id) student_cnt,
FROM course_registration cr
JOIN course_outcome co
  ON cr.student_id = co.student_id AND
     cr.course_id = co.course_id AND
     cr.semester_id = co.semester_id
JOIN course_schedule cs
  ON cr.course_id = cs.course_id AND
     cr.semester_id = cs.semester_id
GROUP BY 1,2;

现在，想象faculty_bob的任务是扩展course_schedule表，以包括一个新字段lecture_duration_band，以分组不同的lecture_duration值。用户faculty_bob可以创建该表的副本，并扩展该表以包含新字段。请注意，由于search_path，faculty_bob仍然不需要指定模式名称。新的course_schedule表将在faculty_bob模式中创建，他对其具有写权限（示例 8-7）。

示例 8-7. 使用search_path创建用户表

CREATE TABLE course_schedule AS SELECT * FROM course_schedule;
ALTER TABLE course_schedule ADD column lecture_duration_band varchar(100);
UPDATE TABLE course_schedule SET lecture_duration_band = CASE
  WHEN lecture_duration BETWEEN 0 AND 60 THEN '0-1 Hour'
  WHEN lecture_duration BETWEEN 61 AND 120 THEN '1-2 Hour'
  WHEN lecture_duration > 120 THEN '2+ Hour' END;

为了测试结果，faculty_bob可以执行引用新字段的修改后的查询（示例 8-8）。

示例 8-8. 使用search_path选择用户表

SELECT
    co.semester_id,
    cs.lecture_duration_band, -- changed from lecture_duration
    count(distinct co.student_id) student_cnt,
FROM course_registration cr
JOIN course_outcome co
  ON cr.student_id = co.student_id AND
     cr.course_id = co.course_id AND
     cr.semester_id = co.semester_id
JOIN course_schedule cs
  ON cr.course_id = cs.course_id AND
     cr.semester_id = cs.semester_id
GROUP BY 1,2;

如果结果符合目标，用户可以将转换规则传递给etluser，它可以修改public模式。注意，由于search_path，etluser也无需指定模式名称。etluser在search_path中唯一的course_schedule表位于public模式中，etluser对其具有写权限（示例 8-9）。

示例 8-9. 修改共享表

ALTER TABLE course_schedule ADD column lecture_duration_band varchar(100);
UPDATE TABLE course_schedule SET lecture_duration_band = CASE
  WHEN lecture_duration BETWEEN 0 AND 60 THEN '0-1 Hour'
  WHEN lecture_duration BETWEEN 61 AND 120 THEN '1-2 Hour'
  WHEN lecture_duration > 120 THEN '2+ Hour' END;

最后，faculty_bob可以删除他的用户表，并运行修改后的 SQL，该 SQL 将引用更新的共享表（示例 8-10）。

示例 8-10. 删除用户表并查询修改后的共享表

DROP TABLE course_schedule;

SELECT
    co.semester_id,
    cs.lecture_duration_band, -- changed from lecture_duration
    count(distinct co.student_id) student_cnt,
FROM course_registration cr
JOIN course_outcome co
  ON cr.student_id = co.student_id AND
     cr.course_id = co.course_id AND
     cr.semester_id = co.semester_id
JOIN course_schedule cs
  ON cr.course_id = cs.course_id AND
     cr.semester_id = cs.semester_id
GROUP BY 1,2;

数据库角色

数据库角色与数据库组类似，但在管理 Amazon Redshift 安全性时具有两个额外的灵活性功能。

首先，数据库角色允许您委派系统权限以运行先前仅授予对象所有者或超级用户的某些命令，例如更改或删除表，刷新材料化视图或管理用户。有关系统权限的详细列表，请参阅在线文档。

其次，数据库角色支持角色的嵌套，并且 Amazon Redshift 随每个角色授权传播权限。在示例中，授予角色 R1 给角色 R2，然后授予角色 R2 给角色 R3，将授权角色 R3 具有来自这三个角色的所有权限。因此，通过向用户授予角色 R3，该用户具有来自角色 R1、R2 和 R3 的所有权限。

图 8-1. 角色层次结构

Amazon Redshift 不允许创建循环角色授权周期，因此不能将角色 R3 授予角色 R1，因为那将构成循环角色授权。

要开始使用数据库角色，Amazon Redshift 提供了四个系统定义的角色(表 8-3)，您可以根据需要创建额外的更精细的角色。系统定义的角色使用sys:前缀，您不能将此前缀用于您创建的角色。

表 8-3. 系统定义的角色

角色名	权限描述
sys:operator	可以访问目录或系统表，并分析、清空或取消查询。
sys:dba	可以创建模式，创建表，删除模式，删除表，截断表，创建或替换存储过程，删除存储过程，创建或替换函数，创建或替换外部函数，创建视图和删除视图。此外，此角色还继承了 sys:operator 角色的所有权限。
sys:superuser	拥有与 Amazon Redshift 超级用户相同的权限。
sys:secadmin	可以创建用户、更改用户、删除用户、创建角色、删除角色，并授予角色。只有在显式授予角色的情况下，此角色才可以访问用户表。

数据库角色实战

使用系统定义的角色，您可以提升用户的权限。假设您有一个需要管理数据库对象和监视加载过程但不能管理安全对象（如用户、组和角色）的etluser。在示例 8-11 中，您可以看到如何将这些权限授予etluser。

示例 8-11. 将数据库角色授予用户

GRANT ROLE sys:dba TO etluser;
GRANT ROLE sys:operator TO etluser;

类似地，您可以创建角色来限制对系统权限的访问。想象一种情景，用户需要对象管理权限，但不应具有用户管理权限。在示例 8-12 中，您可以看到etluser被提升为superuser，并且可以使用数据库角色revoke_secadmin，该角色取消用户管理权限并分配给etluser。

示例 8-12. 删除用户表和修改共享表查询

ALTER USER etluser CREATEUSER;
CREATE ROLE revoke_secadmin;
REVOKE CREATE USER, DROP USER, ALTER USER,
       CREATE ROLE, GRANT ROLE
FROM ROLE revoke_secadmin;
GRANT ROLE revoke_secadmin TO etluser;

若要了解更多有关基于角色的访问控制的示例，请参阅博客文章“使用基于角色的访问控制简化 Amazon Redshift 数据库权限管理”。

行级安全性

Amazon Redshift 中的 RLS 提供了细粒度的访问控制，确定登录用户是否应该访问表中的记录，仅返回用户有权访问的记录。

RLS 策略通过引用正在查询的表中的零个或多个列并将这些值与静态值或动态值（如current_user或会话配置变量）进行比较来定义。有关如何定义 RLS 策略的详细信息，请参阅CREATE RLS POLICY文档，有关如何设置会话配置变量的详细信息，请参阅SET_CONFIG文档。

RLS 策略随后分配到一个表格中，并且必须与用户、数据库角色或PUBLIC组关联。详见ATTACH RLS POLICY documentation了解如何附加 RLS 策略的详细信息。

博文"通过在 Amazon Redshift 中使用行级访问控制实现细粒度数据安全"展示了在决定您的 RLS 访问控制策略时的多种选项。

行级安全实施

使用在 Chapter 3, "Setting Up Your Data Models and Ingesting Data"中定义的学生数据模型，让我们使用 RLS 确保学生只能看到自己的数据。为实现此任务，您需要创建一个检查current_user的策略。对于这种用例，您可以假设当前用户将与student_id列匹配。还可以假设登录到系统的所有学生都将关联到student角色(Example 8-13)。

Example 8-13. 使用current_user的行级安全

CREATE RLS POLICY student
WITH (student_id int)
USING (student_id = current_user);

GRANT SELECT ON
  student,
  course_outcome,
  course_registration,
  degree_plan
TO RLS POLICY student;

ATTACH RLS POLICY student ON student TO ROLE student;
ATTACH RLS POLICY student ON course_outcome TO ROLE student;
ATTACH RLS POLICY student ON course_registration TO ROLE student;
ATTACH RLS POLICY student ON degree_plan TO ROLE student;

设置好这个配置后，查询任何附加到策略的表都只会返回与用户相关的数据。例如，执行语句SELECT * FROM course_outcome;将仅返回与查询该表的学生相关的记录。

Amazon Redshift 中的 RLS 支持在一个表上附加多个策略。当一个用户在一个表上定义了多个策略时，无论是通过直接关系还是数据库角色，Amazon Redshift 都会应用所有带有AND语法的策略。

在一个有数千名学生的大学场景中，您可能无法为每个学生创建数据库用户，并且需要使用一个共享数据库登录的应用程序。在这种情况下，假设登录名是application_user。之前的 RLS 策略将不起作用，因为student_id与current_user变量不匹配。相反，如果查询数据的应用程序知道是哪个学生发出的请求，它可以设置一个会话配置变量。该配置变量可以在您的 RLS 策略中使用。还可以假设application_user登录关联到student角色(Example 8-14).

Example 8-14. 使用配置变量的行级安全

DROP RLS POLICY student CASCADE;
CREATE RLS POLICY student
WITH (student_id int)
USING (student_id = current_setting('app.student_id', FALSE));

GRANT SELECT ON
  student,
  course_outcome,
  course_registration,
  degree_plan
TO RLS POLICY student;

ATTACH RLS POLICY student ON student TO ROLE student;
ATTACH RLS POLICY student ON course_outcome TO ROLE student;
ATTACH RLS POLICY student ON course_registration TO ROLE student;
ATTACH RLS POLICY student ON degree_plan TO ROLE student;

最后，如果应用程序在查询受影响的表之前执行set_config命令，则 RLS 策略将被应用(Example 8-15).

Example 8-15. 使用set_config

SELECT set_config('app.student_id', '<VALUE>', FALSE);

让我们继续在 Chapter 7, "Collaboration with Data Sharing"中描述的示例中继续工作，多个租户可以访问数据共享并在消费者数据仓库中应用 RLS。您已经在学校表中添加了字段consumer_namespace。在消费者数据共享上建立示例 Example 8-16 中显示的 RLS 策略，将确保只有授权的消费者能够查询其授权访问的学校数据。

示例 8-16. 使用消费者命名空间的行级安全性

CREATE RLS POLICY consumer
WITH (school_id int)
USING (school_id = (
  SELECT school_id
  FROM school
  WHERE consumer_namespace = current_namespace));

GRANT SELECT ON
  student,
  course_outcome,
  course_registration,
  degree_plan
TO RLS POLICY consumer;

ATTACH RLS POLICY consumer ON student TO ROLE school;
ATTACH RLS POLICY consumer ON course_outcome TO ROLE school;
ATTACH RLS POLICY consumer ON course_registration TO ROLE school;
ATTACH RLS POLICY consumer ON degree_plan TO ROLE school;

行级安全性考虑

引入 RLS 后，您可能想知道像视图、物化视图或通过数据共享公开的对象是如何处理的。参见表 8-4 以了解这些行为和解决方法。

表 8-4. 依赖 RLS 的对象行为

依赖性	行为	解决方法
视图	您无法将 RLS 策略附加到视图上。	视图继承组件表的策略，因此不需要将 RLS 策略附加到视图上。
物化视图	您无法附加 RLS 策略到物化视图。此外，您也不能在被物化视图引用的表上创建 RLS 策略。	您可以将 MV 代码转换为管理物理表的存储过程，并在该表上应用 RLS 策略。
数据共享	可以将 RLS 策略附加到通过数据共享向消费者公开的表；但是，消费者不会受到生产者定义的 RLS 策略的约束。	消费者可以在 datashare 对象上定义自己的策略。
数据湖表	您无法将 RLS 策略附加到作为外部表从数据湖公开的表上。	您可以利用 Lake Formation 的cell-level filtering，该过滤可以分配给创建外部架构时使用的 IAM 角色。
联合表	您无法将 RLS 策略附加到作为外部表从联合数据源公开的表上。	您可以利用受限制数据库视图的策略，这些视图授予给外部架构定义中的联合用户。

在使用 RLS 时，还需查看在线文档以获取额外的考虑事项。

动态数据脱敏

DDM 允许您对数据进行脱敏，并通常用于监管或合规要求，或实施内部隐私标准。DDM 允许您根据用户权限在查询时动态地操作敏感数据的显示。DDM 是对静态数据脱敏的可扩展替代方案，需要修改加载和转换过程。通过将策略附加到表和列，您可以控制对数据的访问。策略应用于特定用户、数据库角色或PUBLIC组。DDM 允许您响应不断变化的隐私要求，而无需修改转换代码、底层数据或应用 SQL 查询。

正如在“对象级访问控制”中讨论的那样，可以通过REVOKE语句应用列级安全（CLS）访问控制。然而，在使用 CLS 时，当用户尝试执行select *语句时会导致错误。相比之下，应用 DDM 策略不会导致错误，而是可以混淆数据或返回NULL值。

掩码策略是通过引用用于确定数据掩码方式的列以及用于评估列值并确定掩码输出值的机制来定义的。在大多数情况下，仅对一个被掩码的列进行掩码即可定义掩码策略，但在更复杂的情况下，需要从表中额外的列来满足掩码要求。

支持数据掩码的机制包括静态值、内联 SQL 语句、标量 SQL UDF 或可以引用像current_user或会话配置变量等动态值的 Python UDF。有关如何定义 DDM 策略的详细信息，请参阅在线文档。

然后将 DDM 策略分配给一个表，引用用于掩码策略中使用的输入列，并必须与用户、数据库角色或PUBLIC组关联。有关如何附加 DDM 策略的详细信息，请参阅在线文档。

在同一用户适用多个策略的情况下，因为该用户属于多个数据库角色，PRIORITY 限定符将确定应用哪个策略。

鉴于定义 DDM 策略的灵活性和选项，当确定掩码策略时有许多选择。博文“Amazon Redshift 中动态数据掩码支持如何帮助实现数据隐私和合规性”展示了其中许多选项。

动态数据掩码实施

让我们继续使用在第三章，“设置数据模型和数据摄取”中描述的学生数据模型，探讨如何将 DDM 策略应用到数据上。假设您被要求实施以下掩码规则以保护学生的 PII 数据：

• 默认情况下，PII 数据应显示为NULL。

• birth_date和email_address被分类为 PII。

• 学生应该看到他们的数据未经混淆。

• 教职人员应能看到生日的月份和日期，但不应看到年份。

• 教职人员应能看到被混淆的电子邮件地址。

让我们首先创建一些默认策略。因为 DDM 策略必须根据列的数据类型进行定义，所以您可以为每种数据类型创建一个通用策略。在示例 8-17 中，您可以看到如何创建一个返回varchar字段为 null 和一个返回date字段为 null 的策略。

示例 8-17. 定义默认动态数据掩码策略

CREATE MASKING POLICY null_varchar
WITH (i_varchar varchar) USING (NULL);

CREATE MASKING POLICY null_date
WITH (i_date date) USING (NULL);

接下来，通过将这些策略附加到student.email_address字段和student.birth_date字段，并将策略分配给所有用户都是成员的PUBLIC组，完成要求 1 和 2。请注意，此策略的优先级设置为99（示例 8-18）。稍后，您可以添加优先级较低的策略，如果用户匹配其中一个策略，则会使用该策略而不是默认策略。

示例 8-18. 附加默认动态数据掩码策略

ATTACH MASKING POLICY null_varchar
ON student(email_address) TO PUBLIC PRIORITY 99;

ATTACH MASKING POLICY null_date
ON student(birth_date) TO PUBLIC PRIORITY 99;

可选地，您可以省略短语TO PUBLIC，如果未指定用户或数据库角色，则默认为PUBLIC组。

现在，让我们为具有对数据完全访问权限的用户创建策略。在示例 8-19 中，您可以看到如何创建一个假设有两个输入的策略。第一个是被屏蔽的列，第二个是用于定义策略的任何附加数据。此策略将检查student_id是否与current_user变量匹配，如果匹配，则返回date值或varchar值。如果不匹配，则返回NULL。

示例 8-19. 定义透传动态数据屏蔽策略

CREATE MASKING POLICY passthrough_varchar_student_id
WITH (i_varchar varchar, student_id int) USING (
  CASE student_id WHEN current_user THEN i_varchar ELSE NULL END
  );

CREATE MASKING POLICY passthrough_date_student_id
WITH (i_date date, student_id int) USING (
  CASE student_id WHEN current_user THEN i_date ELSE NULL END
  );

接下来，通过将这些策略附加到student.email_address字段和student.birth_date字段，并将策略分配给student角色，来完成要求 3。请注意，此策略的优先级设置为25，当用户被分配student角色时，此策略将优先于上次创建的策略（示例 8-20）。

示例 8-20. 附加透传动态数据屏蔽策略

ATTACH MASKING POLICY passthrough_varchar_student_id
ON student(email_address)
USING (email_address, student_id) TO ROLE student PRIORITY 25;

ATTACH MASKING POLICY passthrough_date_student_id
ON student(birth_date)
USING (birth_date, student_id) TO ROLE student PRIORITY 25;

现在，让我们创建一个更复杂的屏蔽策略，以满足遮蔽年份的要求 4。在示例 8-21 中，我们将使用 SQL 函数来转换日期字段i_date，并用静态值1900替换年份。

示例 8-21. 定义日期动态数据屏蔽策略

CREATE MASKING POLICY date_noyear
WITH (i_date date) USING (
  (extract('mon' FROM i_date)||'/'||date_part('day', i_date)||'/1900')::date);

要满足邮件部分内容的遮盖要求 5，我们将使用 Python UDF。该函数将含有电子邮件地址的varchar字段的前四个字符替换为静态值。此函数还具有额外的逻辑，以确保字段包含@符号，并处理字符串在@符号之前长度少于四个字符的情况（示例 8-22）。

示例 8-22. 定义电子邮件动态数据屏蔽策略

CREATE OR REPLACE FUNCTION redact_email (i_email TEXT)
RETURNS TEXT IMMUTABLE
AS $$
    md=i_email.find('@')
    ln=len(i_email)
    IF md>0 and ln>0:
      RETURN '####'+i_email[0:md][4:]+i_email[md:]
    ELSE:
      RETURN 'invalid email'
$$ LANGUAGE plpythonu;

CREATE MASKING POLICY email_redact
WITH (i_email varchar) USING (
  redact_email(i_email)
  );

最后，通过将这些策略附加到student.email_address字段和student.birth_date字段，并将策略分配给faculty角色，来完成要求 4 和 5。请注意，此策略的优先级设置为50，当用户被分配faculty角色时，此策略将优先于上次创建的默认策略。然而，如果用户同时是faculty和student角色的成员，由于优先级较低，将应用student策略（示例 8-23）。

示例 8-23. 附加日期和电子邮件动态数据屏蔽策略

ATTACH MASKING POLICY date_noyear
ON openlearn.student(birth_date) TO ROLE faculty PRIORITY 50;

ATTACH MASKING POLICY email_redact
ON openlearn.student(email_address) TO ROLE faculty PRIORITY 50;

动态数据屏蔽注意事项

与 RLS 类似，在引入 DDM 后，您可能会想知道如何处理依赖对象，如其他视图、物化视图和通过数据共享公开的对象。请参阅表 8-5，了解每个对象的行为和解决方法。

表 8-5. DDM 相关对象行为

依赖性	行为	解决方法
视图	你不能将 DDM 策略附加到视图上。	视图继承组件表的策略，因此不需要将 DDM 策略附加到视图上。
材料化视图	你不能将 DDM 策略附加到材料化视图上。此外，你也不能在被材料化视图引用的表上创建 DDM 策略。	相反，你可以将 MV 代码转换为管理物理表的存储过程，并在该表上应用 DDM 策略。
Datashare	可以将 DDM 策略附加到通过数据共享向消费者公开的表上；然而，消费者不会受到生产者定义在 datashare 对象上的 DDM 策略的约束。	消费者将能够在 datashare 对象上定义自己的策略。
数据湖表	你不能将 DDM 策略附加到从数据湖公开为外部表的表上。	您可以在数据湖数据静态时模糊/令牌化，并使用 Amazon Redshift 上的 UDF 解密数据。
联合表	你不能将 DDM 策略附加到从联合数据源作为外部表公开的表上。	您可以在联合数据源数据静态时模糊/令牌化，并使用 Amazon Redshift 上的 UDF 解密数据。

欲了解更多有关使用 DDM 时的考虑，请参阅在线文档。

外部数据访问控制

如在第一章，“AWS 数据”中所讨论的，现代数据架构经常涉及允许用户访问其产生的数据，即使数据存储在亚马逊 Redshift 之外。在第四章，“数据转换策略”中，我们描述了用户如何在使用亚马逊 Redshift 转换数据时直接访问这些外部来源。为了管理这些外部数据访问，亚马逊 Redshift 利用 IAM 角色。在进行 COPY、UNLOAD、EXTERNAL FUNCTIONS 和 CREATE MODEL 操作时，执行查询的用户将直接引用 IAM 角色，并需要有权限来扮演这个角色。对于操作性数据、亚马逊 S3 数据和流数据摄入，IAM 角色用于创建外部架构。针对每种情况，让我们深入探讨如何将“关联 IAM 角色”到您的亚马逊 Redshift 数据仓库，如何“授权 Assume Role 权限”，以及如何使用角色来“建立外部架构”。最后，我们将看看如何使用“Lake Formation 进行细粒度访问控制”来对您的亚马逊 S3 数据湖中的数据进行细粒度访问控制。

关联 IAM 角色

在启动数据仓库时或稍后使用 AWS 控制台或 API 命令，可以将 IAM 角色关联到您的 Amazon Redshift。但是，只有当 IAM 角色具有信任关系，允许 Amazon Redshift 服务 (redshift.amazonaws.com) 或 Amazon Redshift 无服务器服务 (redshift-serverless.amazonaws.com) 执行操作 sts:AssumeRole 时，才能将 IAM 角色附加到 Amazon Redshift 数据仓库。在 示例 8-24 中，您可以看到如何使用 AWS 命令行客户端将 IAM 角色 myRedshiftRole 附加到 Amazon Redshift 数据仓库。

示例 8-24. 集群添加 IAM 角色

> aws redshift modify-cluster-iam-roles \
    --cluster-identifier mycluster \
    --add-iam-roles arn:aws:iam::1234567890:role/myRedshiftRole

在本书的早期多个示例中，您使用 default IAM 角色与 Amazon S3 等外部服务进行交互，使用户能够编写其 SQL 语句，而不必担心 IAM 角色 ARN 的确切语法或要使用的 IAM 角色。在 示例 8-25 中，您可以看到如何使用 AWS 命令行客户端将 IAM 角色 myRedshiftRole 设置为默认角色。

示例 8-25. 集群设置默认 IAM 角色

> aws redshift modify-cluster-iam-roles \
    --cluster-identifier mycluster \
    --default-iam-role-arn arn:aws:iam::1234567890:role/myRedshiftRole

在 示例 8-26（来自 第 3 章）中，您可以看到如何使用默认 IAM 角色将数据加载到您的 Amazon Redshift 数据仓库中，该角色已被授予从 S3 位置 s3://openlearn-redshift/assessments 读取的权限。

示例 8-26. 使用 IAM 角色进行 COPY 操作

COPY "openlearn"."assessments"
FROM 's3://openlearn-redshift/assessments'
IAM_ROLE default
DELIMITER ',' COMPUPDATE ON REGION 'us-east-1'
REMOVEQUOTES IGNOREHEADER 1;

在 示例 8-27（来自 第 7 章）中，如果默认 IAM 角色已被授予写入到 S3 位置 s3://openlearn/studentactivities 的 IAM 权限，您可以看到如何将数据从您的 Amazon Redshift 数据仓库导出到 Amazon S3。

示例 8-27. 使用 IAM 角色进行 UNLOAD 操作

UNLOAD ('select * from mv_student_lmsactivities_and_score')
TO 's3://openlearn/studentactivities'
IAM_ROLE default PARQUET PARTITION BY (school_id);

在 示例 8-28（来自 第 4 章）中，您可以看到如何在 Amazon Redshift 中创建一个指向 AWS Lambda 函数的标量 UDF。在这种情况下，IAM 角色将需要执行 Lambda 函数 f-kms-encrypt 的权限。

示例 8-28. 使用 IAM 角色进行 Lambda UDF

CREATE OR REPLACE EXTERNAL FUNCTION
f_kms_encrypt (key varchar, value varchar)
RETURNS varchar(max) STABLE
LAMBDA 'f-kms-encrypt'
IAM_ROLE default;

最后，在 示例 8-29（来自 第 6 章）中，您可以看到如何使用 SQL 接口创建、训练和开始运行机器学习模型的推理。在这种情况下，IAM 角色将需要权限来使用 SageMaker，并写入到临时的 S3 存储桶 bucketname。

示例 8-29. 使用 IAM 角色进行 Redshift ML

CREATE MODEL demo_ml.customer_churn_model
FROM (SELECT state,
        area_code,
        total_charge/account_length AS average_daily_spend,
        cust_serv_calls/account_length AS average_daily_cases,
        churn
      FROM demo_ml.customer_activity
         WHERE record_date < '2020-01-01')
TARGET churn
FUNCTION predict_customer_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'bucketname');

要启用从不同 AWS 帐户访问资源，您可以使用角色链接策略。这涉及在两个帐户中的 IAM 角色之间建立信任关系。有关此策略的更多信息，请参阅在线文档。

授权假设角色权限

当您将 IAM 角色关联到您的 Amazon Redshift 数据仓库时，默认权限是PUBLIC组中的任何成员都可以承担任何 IAM 角色。对于具有多种类型用户的大规模部署，您可能希望进一步限制用户可以承担的 IAM 角色。为此，您可以执行示例 8-30 中显示的REVOKE命令，该命令将从所有用户中删除默认的ASSUMEROLE权限。

示例 8-30. 撤销 Assume IAM 角色

REVOKE ASSUMEROLE on ALL from PUBLIC for ALL;

随后，您可以执行一个GRANT语句，以确保所需的用户、数据库角色或数据库组具有访问他们所需的角色。通过实施这一策略，您可以为职能或资源定义特定的 IAM 角色。例如，您可以授予faculty数据库角色访问权限，以承担具有调用f_kms_decrypt Lambda 函数的访问权限的 IAM 角色（示例 8-31）。

示例 8-31. 授予 Assume IAM 角色 Lambda

GRANT ASSUMEROLE ON 'arn:aws:iam::1234567890:role/myLambdaRole'
TO ROLE faculty FOR EXTERNAL FUNCTION

如示例 8-32 所示，您可以授予etluser数据库角色访问权限，以承担具有对用于加载数据的原始 Amazon S3 数据的读取权限的 IAM 角色。

示例 8-32. 授予 Assume IAM 角色 S3

GRANT ASSUMEROLE ON 'arn:aws:iam::1234567890:role/myETLRole'
TO ROLE etluser FOR COPY, UNLOAD

您可以将最多 50 个角色关联到您的 Amazon Redshift 数据仓库。在确定 IAM 角色策略时，请记住这一点。

建立外部模式

对于实时查询外部源，如在 Amazon S3 中查询开放格式文件，MySQL 或 PostgreSQL 数据库中的操作数据存储，或从 Kinesis 或托管 Kafka 中流式处理数据，您必须首先建立外部模式。对于每个外部模式，您可以通过管理GRANT USAGE或REVOKE USAGE特权来进一步限制访问到模式。这可以确保正确的用户、组和角色可以查询这些源。

在示例 8-33（来自第 4 章）中，您可以看到如何将 Amazon Redshift 数据仓库中的模式federatedschema映射到 Amazon RDS 中的 PostgreSQL 操作数据存储。

示例 8-33. 使用 IAM 角色的外部联合模式

CREATE EXTERNAL SCHEMA IF NOT EXISTS federatedschema
FROM POSTGRES DATABASE 'db1' SCHEMA 'pgschema'
URI '<rdsname>.<hashkey>.<region>.rds.amazonaws.com'
SECRET_ARN 'arn:aws:secretsmanager:us-east-1:123456789012:secret:pgsecret'
IAM_ROLE default;

在使用联合查询访问操作数据存储时，将会与源数据库建立网络连接，并使用存储在 AWS Secrets Manager 中的凭据建立连接。在 Amazon Redshift 外部模式定义中使用的 IAM 角色需要在 AWS Secrets Manager 秘密上具有读取权限。此外，从 Secret Manager 接收的凭据需要在联合数据库上具有执行查询的数据库权限。最后，在您的 Amazon Redshift 数据仓库和联合数据库之间需要存在 TCP/IP 网络路径。有关如何使用联合查询的详细信息，请参阅在线文档。

在示例 8-34（来自第三章），您可以看到如何将 Amazon Redshift 数据仓库中的模式kds映射到 Kinesis 数据流中。

示例 8-34. 使用 IAM 角色的外部流模式

CREATE EXTERNAL SCHEMA kds
FROM KINESIS
IAM_ROLE default;

与模式关联的 IAM 角色将需要对 Kinesis 流具有读取权限。您需要在 IAM 策略中包含适当的kinesis:Get*，kinesis:List*和kinesis:Describe*操作，可以将其限制和限定为您将访问的流。有关流式摄取的更多详细信息，请参阅在线文档。

在示例 8-35（来自第四章），您可以看到如何将 Amazon Redshift 数据仓库中的EXTERNAL SCHEMA映射到 AWS Glue Data Catalog 中的数据库。

示例 8-35. 使用 IAM 角色的外部 S3 模式

CREATE EXTERNAL SCHEMA IF NOT EXISTS externalschema
FROM data catalog DATABASE 'externaldb'
IAM_ROLE default;

在示例 8-35，您会注意到授权是由default IAM 角色确定的，这意味着只有一个身份主体决定可以访问哪些数据或无法访问。在多种类型的用户访问您的 Amazon Redshift 数据仓库的情况下，每个用户可能需要不同级别的 S3 数据访问控制。满足此要求的一种选项是建立不同的外部模式，并使用不同的 IAM 角色授予用户访问每个角色的权限，使用"授权假定角色权限"技术。但是，如果您正在使用联合访问您的 Amazon Redshift 数据仓库，可以设置每个用户组通过不同的 IAM 角色对 Amazon Redshift 进行身份验证，并且您可以在外部模式定义中使用关键字SESSION来传递 IAM 角色（示例 8-36）。此外，提供与您 AWS 账户 ID 匹配的CATALOG_ID参数允许跨账户访问 S3。在设置外部模式时使用此策略可以消除设置多个外部模式和将多个 IAM 角色附加到 Amazon Redshift 数据仓库的需要。有关更多详细信息，请参阅在线文档。

示例 8-36. 使用SESSION授权的外部 S3 模式

CREATE EXTERNAL SCHEMA IF NOT EXISTS externalschema
FROM data catalog DATABASE 'externaldb'
IAM_ROLE 'SESSION'
CATALOG_ID '123456789012';

AWS Glue Data Catalog 除了被 Amazon Redshift 使用外，还提供对 Amazon Athena、AWS Glue ETL 和 Amazon EMR 的访问。您在 Amazon Redshift 外部模式定义中使用的 IAM 角色将需要对 AWS Glue Data Catalog 中的对象具有读取权限，以及对 AWS Glue Data Catalog 中定义的对象具有读取权限。可选地，您可以授予 AWS Glue Data Catalog 写入权限，这将允许 Amazon Redshift 用户在不离开 SQL 界面的情况下使用CREATE EXTERNAL TABLE命令注册新的外部表。如果启用了 Lake Formation，则对象权限将由 Lake Formation 管理。有关更多详细信息，请参阅下一节。

如果未启用 Lake Formation，则对象权限将受 IAM 角色的 IAM 策略中列出的特权控制。您需要包括适当的s3:Get*和s3:List*操作，可以通过资源限制进行范围限制，以限制对 Amazon S3 数据湖中对象的访问。有关如何查询 Amazon S3 数据的更多详细信息，请参阅在线文档。

Lake Formation 用于细粒度访问控制。

在管理大型数据湖时，仅通过 IAM 策略定义访问控制可能会变得繁琐，特别是当用户群体庞大且不同组的权限开始重叠时。此外，通过 IAM 策略管理权限仅限于您可以强制执行的策略，这些策略要么让用户访问整个表，要么让用户访问表的某些分区，要么根本没有访问权限。

开始使用 AWS Lake Formation 无需对外部模式定义进行任何更改，因为 Lake Formation 与 AWS Glue 数据目录共享。从 IAM 权限迁移到 Lake Formation 是一个过程，需要维护现有的数据结构，首先启用 Lake Formation 来管理访问控制，然后从各个 IAM 角色的 IAM 策略语句中移除，将其迁移到分配给 IAM 角色的 Lake Formation 权限。有关涉及步骤的更多详细信息，请参阅在线文档。完成后，访问管理集中到 AWS Lake Formation 控制台，您可以使用熟悉的概念，如数据库、表和列，以及更高级的选项，如行级和单元级安全性，而不是对象级权限。

为了简化对 Lake Formation 数据权限的管理，您可以直接在 SQL 界面中执行 GRANT 语句，而不必导航到 Lake Formation 界面。例如，如果您想在外部交易表上强制执行列级安全性，您可以执行以下 GRANT 语句，将 Finance IAM 角色授予所有列的访问权限，但限制 Analyst IAM 角色对 customer_id 的访问（参见示例 8-37）。

示例 8-37. 从 Amazon Redshift 授予 Lake Formation 权限

GRANT SELECT (
  returnflag,linestatus,zip,quantity,extendedprice,
  discount,tax,customer_id,year,month)
ON EXTERNAL TABLE  externalschema.transactions
TO IAM_ROLE 'arn:aws:iam::1234567890:role/myFinanceRole'

GRANT SELECT (returnflag,linestatus,zip,quantity,
  extendedprice,discount,tax,year,month)
ON EXTERNAL TABLE  externalschema.transactions
TO IAM_ROLE 'arn:aws:iam::1234567890:role/myAnalystRole'

用于额外阅读的博客文章，查看“通过 AWS Lake Formation 集中管理您的数据湖，同时使用 Amazon Redshift Spectrum 实现现代数据架构”。

摘要

在本章中，我们详细说明了加载到 Amazon Redshift 中的数据的不同访问控制方式，以及 Amazon Redshift 可访问的数据。我们介绍了如何在确保数据安全性的同时，为用户提供分析数据和生成洞察的灵活性。

在下一章中，我们将讨论从当前分析环境迁移到 Amazon Redshift 的考虑因素和策略。我们将详细介绍可用的不同工具和服务，展示迁移的示例过程，并介绍如何利用 Amazon Redshift 加速迁移。

¹ “数字媒体购买的未来”，Forrester Research，2014 年 12 月 2 日，第 10 页。

第九章：迁移到 Amazon Redshift

组织多年来一直在本地数据仓库上运行，并且这些数据仓库对昨天的工作负载非常有用。但今天的数据量、种类和速度要求客户现代化他们的数据仓库，以确保最佳性能。以下是传统数据仓库的一些主要限制或缺陷：

获取速度慢

自己采购服务器并调整它们的大小比在云中配置基础设施要花费更长的时间。

维护成本高昂

它们的结构如此严格，以至于任何修改都意味着成本和项目时间表的急剧增加。

弹性

硬件组件迟早会出现故障。围绕故障设计冗余，并拥有多个数据中心和待命服务器会非常快速地增加成本。

不灵活的架构

每个企业的首要需求是敏捷性和可扩展性。传统数据仓库的不灵活架构几乎无法快速进行变更。

技术进步

每天都有技术进步。您为业务建立的传统数据仓库可能已经是几年前的事情了。因此，您已经落后了。

要解决这些限制，一个选择是为您的分析需求采用 Amazon Redshift，因为它是一个完全托管的、快速、可扩展且成本效益高的服务，使您能够从所有数据中获取洞察。

然而，数据仓库迁移项目可能非常复杂和具有挑战性。很容易低估迁移过程的复杂性，导致对需要迁移的内容、所需时间以及所需资源缺乏清晰的认识。

本章将涵盖“迁移考虑”，然后讨论“迁移策略”以及 AWS 原生的“迁移工具和服务”。这些主题将帮助您清楚地概述迁移的复杂性，并为您提供挑战的明确认识。

然后我们将详细讨论实际的“数据库迁移过程”，最后讨论如何“加速您的 Amazon Redshift 迁移”。

迁移考虑

数据仓库迁移项目在项目复杂性方面可能具有挑战性，并可能暴露与资源、时间和成本相关的风险。在开始数据仓库迁移之前，请考虑应用“现代数据架构”中涵盖的原则，并重新评估您未来状态的数据仓库架构。仅仅因为您当前数据库中有所有这些表并不意味着您必须将它们全部迁移到 Amazon Redshift。评估如何利用此机会并现代化您的整体数据仓库战略。

废弃与保留

迁移到任何新平台都是审视您的数据占用情况的机会，消除冗余或未使用的数据和报告。您可以从分析报告的使用情况开始，并识别是否存在未使用的报告。审查随时间积累的报告，并消除不再使用的报告。除非您的组织有定期的重新认证过程，否则很可能只是生成了报告而实际上并未使用。

这种情况最常见的原因之一是业务流程随时间的演变，一旦发生这种情况，较旧的报告就不再提供它以前提供的价值。满足新流程的紧迫性和推动力更重要，而较旧的报告通常会被搁置。

另一个常见原因是报告老化：报告按照要求构建，非常有用，但其背后的数据已经增长，现在报告占据了太多页面。因此，委托建立了一个新的高级或摘要报告，原始报告仍然被使用，尽管不频繁，最终根本不再使用。如果确定与数据集关联的所有报告都不再需要，则可以彻底从 ETL 过程中删除该数据集。

审查当前数据仓库中积累的数据，并分类需要高性能查询执行与不需要严格执行 SLA 要求的查询数据。考虑现代数据架构，如之前介绍的“现代数据架构参考架构”。

清理掉任何不再需要的现有备份方案或表格，并在可能的情况下删除这些对象。要保留任何必需的备份表格，您可以使用unload命令，如示例 7-27 所示，并将这些表格卸载到您的 Amazon S3 存储桶中。Amazon S3 为您存储的对象提供多种存储类别。根据您的使用情况和性能访问需求选择 S3 存储类别；请查看各种Amazon S3 存储类别。在unload之后，您可以应用S3 生命周期配置策略，并将 S3 备份文件移动到更便宜的存储类别。还需审查将对象过渡到不同 S3 存储类别的考虑因素以制定这些规则。

您可以使用 Amazon S3 Glacier Instant Retrieval 存储类别，Amazon Athena 可以查询。但要使用 S3 Glacier Flexible Retrieval 或 S3 Glacier Deep Archive 存储类别下的对象，您需要将恢复的对象复制回 Amazon S3 以更改其存储类别。

一旦完成所有必要的清理工作，下一步是选择合适的迁移策略。这基于您的源数据仓库景观以及迁移到 Amazon Redshift 所需的转换量。这将减少数据仓库迁移项目的复杂性和风险。

可影响您迁移策略决策的关键因素包括：

• 迁移数据量

• 需要的转换

• 数据波动性和可用性

• 迁移和 ETL 工具

• 数据移动选项

• 使用域名系统

迁移数据大小

要迁移的源数据仓库的总大小取决于数据库的数量、这些数据库中模式的数量以及迁移范围内的这些模式中的对象数量。了解移至 Amazon Redshift 所需的数据源和数据域将有助于优化迁移项目的大小。

例如，您的源数据仓库有五个模式，并不意味着您在单个 Amazon Redshift 数据仓库上必须有五个模式。相反，您应该尝试隔离模式及其工作负载，评估是否可以启动多个 Amazon Redshift 数据仓库，并利用数据共享来提供工作负载隔离，正如我们在“数据共享用例”中详细介绍的那样。

需要平台特定的转换

您现有的数据仓库可能具有某些专有组件，特定于当前供应商。迁移到 Amazon Redshift 可能涉及数据映射和模式更改等转换。需要应用的数据转换复杂性将确定迁移所需的预处理时间。还要考虑您是否已将转换逻辑编码为存储过程并存储在您的模式本身。

利用这个机会现代化，并将 ETL 逻辑放在数据仓库之外。这将未来保护您的整体数据仓库设计，并且如果需要，使您能够独立地更换 ETL 工具或数据仓库技术堆栈。现代 ETL 工具将利用推送功能以基于其连接位置提供最佳性能。我们先前在第四章中讨论过数据转换策略，您可以利用联邦化来现代化转换过程，并且我们介绍了“AWS 模式转换工具”。

数据波动性和可用性要求

请注意您现有数据仓库的上线时间和可用性要求。这些要求可能由摄入速率、更新间隔以及最终用户的数据消费模式所决定。这些要求将影响您在数据仓库迁移项目中的选择。高数据变更率的源数据仓库可能需要严格的过渡窗口。如果迁移需要延长的服务停机时间，可能会导致更高的复杂性。您可以进行迁移测试以确保能够满足严格的过渡窗口。

如果在单源数据仓库上有多个逻辑工作负载，您可能会发现它们都具有相同的上线时间要求，因为它们共享相同的硬件。与各个业务利益相关者确认，讨论在多个目标 Amazon Redshift 数据仓库中的工作负载隔离，并且每个业务利益相关者有机会单独确定其自己的 RTO 和 RPO 目标。我们在“Migration Strategies”中深入探讨不同的过渡选项。

选择迁移和 ETL 工具

选择迁移工具至 ETL 可能会影响迁移项目。当迁移到 Amazon Redshift 时，您可以选择将 ETL 工作流迁移到新的 AWS 本地服务，如AWS Glue ETL，并利用AWS Glue Studio visual editor，或者保留现有的 ETL 工具。您可以根据项目的时间表和预算权衡利弊，并计划 ETL 迁移。您可以采取迭代方法，首先迁移数据仓库，保留现有 ETL 工作流工具，最终迁移 ETL 工作流。在规划迁移项目的时间表时，考虑这些工具的部署和设置所需的额外时间，可以简化执行周期。我们将在“Migration Tools and Services”中介绍 AWS 工具和服务。

数据移动考虑事项

数据仓库迁移涉及源数据仓库服务器与您的 AWS 基础设施之间的数据传输。根据当前网络容量及其现有利用率，您可以通过 Direct Connect 进行网络连接传输，详见“Private/Public VPC and Secure Access”，或选择通过离线服务如AWS Snow Family进行数据传输。

数据仓库大小在 10 TB 以下时可以考虑通过网络传输进行迁移，但通常情况下，更高的数据量会使用 AWS Snowball Edge 设备进行迁移。我们介绍 AWS Snow 系列设备，包括 AWS Snowball Edge，以及在不同网络连接下传输 10 TB 数据的预估时间，详见“AWS Snow Family”。

域名系统（DNS）

您的数据仓库的使用者将使用当前数据仓库名称或 IP 地址来建立到数据仓库的连接。迁移到新的数据仓库将需要应用程序修改其连接设置，指向新的数据仓库。如果您已经使用 DNS 服务，则此迁移项目将最小化对消费者应用程序的影响。如果没有，那么现在是在您的架构中引入 DNS 层的好时机。此 DNS 层还可以在灾难场景中通过自动切换到次要区域来帮助；参考Route 53 故障转移类型了解详情。

迁移策略

根据源数据仓库的数据速率和可用性要求，有三种主要的迁移策略可供选择：

• 单步迁移

• 两步迁移

• 迭代迁移

单步迁移

单步迁移要求您冻结当前数据库并通过停止所有摄入作业来禁止更改。然后，提取时点数据库快照到 CSV 文件或列格式，如 Parquet。然后，根据您的连接选项，您可以使用现有网络或 AWS Snow Family 服务（如 AWS Snowball）将数据集传送到 Amazon S3，以加载到 Amazon Redshift 中。然后，使用源的冻结快照测试目标 Amazon Redshift 数据仓库以确保数据一致性。在所有验证通过后，您将切换现有数据库的使用者到 Amazon Redshift。这对于不需要持续可用性并且具有可接受的时间窗口（如周末或几天）来执行迁移的数据库是一个不错的选择。

如果您现有的数据仓库主要是批处理导向的，那么根据批处理间隔，单步迁移可能是一个很好的选择。

两步迁移

这通常用于需要连续运行的数据库，如连续复制。在迁移过程中，源数据库允许持续的数据变更，并且您需要一个持续的复制过程来保持源数据仓库和 Amazon Redshift 之间数据变更的同步。两步迁移策略的详细步骤如下：

初始数据迁移

初始数据通过之前描述的单步迁移方法迁移到 Amazon Redshift。在最小使用期间从源数据库提取此数据快照，以减少对持续活动的影响。为了捕获初始快照后的变更，您可以同时启用变更日志。如果您的所有表中都有日期时间戳表示的更新时间，您还可以使用日期时间戳来捕获初始快照后的变更。您将通过运行验证脚本和/或业务用户测试报告来进行测试，以确保数据一致性。

变更数据迁移

在初始数据迁移后，在切换之前，将源数据库中发生变化的数据传播到目标数据库。您的迁移工具可以通过持续的复制作业来实现这一点，或者您可以像之前提到的那样使用日期时间戳来识别变更的数据。第二步是通过同步源和目标数据库来验证目的地数据库中的所有已更改数据。在所有验证通过后，可以将现有数据库的使用者切换到 Amazon Redshift。

迭代迁移

此迁移方法适用于大规模数据仓库迁移项目。迭代迁移的原则是将复杂的迁移项目谨慎地划分为多个系统化的迭代。此策略通过将总体风险分解为多个较小的部分，显著降低了迁移项目的复杂性和整体风险。

您从覆盖多个数据源和主题领域的工作负载开始，通常涵盖中等复杂性区域，然后在每个后续迭代中添加更多数据源和主题领域。这种方法的挑战在于能够将整体迁移项目分解为多个逻辑迭代。有关如何使用基于迭代的迁移方法识别和分组从源数据仓库迁移到 Amazon Redshift 的数据源和分析应用程序的更多详细信息，请参阅博客“开发应用迁移方法论，以现代化 Amazon Redshift 数据仓库”。

使用这种策略，您在完全淘汰成功迁移的特定工作负载之前，在一定时间内同时运行源数据仓库和 Amazon Redshift 生产环境。此外，在进入下一迭代时，如果可行，您可以缩小源系统以适应工作负载的减少。

参考图 9-1，以可视化我们讨论的三种迁移策略。

图 9-1. 迁移策略

而且，为了指导您的迁移策略决策，请参考表 9-1，将考虑因素与首选迁移策略进行映射。

表 9-1. 迁移策略决策

迁移策略	单步迁移	两步迁移	迭代迁移
迁移范围中的主题区域数量	小	中等到大	大
数据传输量	小	小到大	大
迁移过程中的数据变更率	无	最小	最小到频繁
数据转换复杂性	小	中等	任意
从源到目标切换的迁移更改窗口	几小时到几天	几天	几分钟
迁移项目持续时间	周	几周到几个月	多个月

迁移工具和服务

您的数据仓库迁移到 Amazon Redshift 将涉及模式对象和数据的迁移。源端的对象包括模式、表、视图、物化视图以及代码对象，如函数、存储过程和包。Amazon Redshift 不支持的某些对象，如序列、触发器和索引，将不会被迁移。

虽然您可以通过 Amazon Redshift 合作伙伴 和 AWS 专业服务 的组合找到实际帮助，但本节重点介绍 AWS 原生工具和服务。这些工具和服务可以用来从多种源数据仓库引擎迁移到 Amazon Redshift，如 表 9-2 所述。

AWS Schema Conversion Tool

AWS SCT 是一个桌面应用程序，提供基于项目的用户界面，自动将源数据库的数据库架构转换为与目标 AWS 本地数据库兼容的格式。它支持多种类型的源和目标数据库。使用 AWS SCT 将现有数据库架构从一个数据库引擎转换为另一个。AWS SCT 支持多个行业标准，包括联邦信息处理标准 (FIPS)，用于连接到 Amazon S3 存储桶或其他 AWS 资源。AWS SCT 还符合联邦风险和授权管理计划 (FedRAMP)。

AWS SCT 支持以下数据仓库架构转换，并提供了必须授予的特定源权限、建立安全连接的详细信息、该源的任何已知限制，以及如何定向 Amazon Redshift 的转换设置和优化设置。

表 9-2. SCT 源支持的 Amazon Redshift 目标

源数据仓库	版本	所需设置
Amazon Redshift	任意	Amazon Redshift 作为源
Azure Synapse	任意	Azure Synapse Analytics 作为源
BigQuery	任意	BigQuery 作为源
Greenplum	4.3 和 6.21	Greenplum 作为源
MS SQL Server	2008 或更高版本	SQL Server 数据仓库作为源
Netezza	7.0.3 或更高版本	Netezza 作为源
Oracle	10.1 或更高版本	Oracle 数据仓库作为源
Snowflake	3 或更高版本	Snowflake 作为源
Vertica	7.2.2 或更高版本	Vertica 作为源
Teradata	13 或更高版本	Teradata 作为源

Table 9-2 在撰写时是最新的，但请参阅最新的数据仓库源。

另外，AWS SCT 还支持将以下 ETL 过程转换为目标 AWS 服务；参考 Table 9-3。

表 9-3. SCT 支持的 ETL 转换

源	目标
Microsoft SQL Server Integration Services (SSIS) ETL 包	AWS Glue 或 AWS Glue Studio
包含 Teradata Basic Teradata Query (BTEQ) 嵌入命令的 Shell 脚本	Amazon Redshift RSQL
Teradata BTEQ ETL 脚本	AWS Glue 或 Amazon Redshift RSQL
Teradata FastExport 作业脚本	Amazon Redshift RSQL
Teradata FastLoad 作业脚本	Amazon Redshift RSQL
Teradata MultiLoad 作业脚本	Amazon Redshift RSQL

SCT 概述

AWS SCT 自动执行大部分模式对象转换。但由于源数据库引擎可能具有多种不同的功能和能力，AWS SCT 尽可能在 Amazon Redshift 中创建等效模式。AWS SCT 允许您提供源数据仓库统计信息，以便优化数据仓库的转换方式。您可以直接从数据库收集统计信息，或者上传现有的统计文件。

AWS SCT 根据源表的主键和外键自动为 Redshift 表分配分发样式和排序键。具有单列主键的源表被分配为键分发样式，并将主键列设置为分发键以及排序键。具有多列主键的源表被分配为键分发样式，第一个主键列被设置为分发键，并将所有源主键列添加为复合排序键。

SCT 迁移评估报告

AWS SCT 提供了一个数据库 迁移评估报告，其中列出了数据库对象及其转换复杂度。该报告包括执行摘要、许可评估、云就绪性（指示源数据库中目标不可用的任何特性）以及有关转换服务器对象、备份建议和链接服务器更改的建议。最重要的是，该报告包括为目标 DB 实例编写等效代码所需的工作复杂度估计，这些代码无法自动转换。

报告将这些模式项转换所需的估计时间分类如下：

简单

可在两小时以内完成的操作。

中等

复杂且需要两至六小时完成的操作。

显著

非常复杂且需要超过六小时完成的操作。

使用 AWS SCT，您可以管理目标 Amazon Redshift 的排序键和分布键，映射数据类型和对象，并创建手动转换。 如果某些对象无法自动转换，则 SCT 会为您提供可能的手动操作列表。 AWS SCT 为您创建转换后模式的本地版本供您审核。 您可以更新源模式并重试，或执行手动转换。 当准备就绪时，您可以将转换后的模式应用于 Amazon Redshift 目标。

SCT 数据提取代理

在某些迁移场景中，源数据库和目标数据库彼此非常不同，需要额外的数据转换。 AWS SCT 是可扩展的，因此您可以使用代理来处理这些情况。 代理是与 AWS SCT 集成的外部程序，但在其他地方执行数据转换（例如在 Amazon EC2 实例上）。 另外，AWS SCT 代理可以代表您与其他 AWS 服务交互，例如为您创建和管理 AWS 数据库迁移服务任务。 它还帮助您增加加载到 Redshift 的任务并行性。 使用 AWS SCT 数据提取代理 从您的本地数据仓库中提取数据并迁移到 Amazon Redshift。 SCT 代理提取您的数据并将数据上传到 Snowball Edge 设备或通过网络直接上传到 Amazon S3。 Snowball Edge 设备被运送到 AWS，一旦接收到，数据将卸载到您指定的 S3 上。 对于大规模迁移，我们推荐使用 Snowball Edge 设备，它不会给您的网络带来额外负担，我们在“AWS Snow Family”中进行了介绍。 然后，您可以使用 AWS SCT 将数据复制到 Amazon Redshift，使用 SCT 复制代理，如图 9-2 所示。

图 9-2. AWS SCT 代理流程

当您的源数据库服务器支持最多 120 个连接，并且您的网络附加了足够的存储时，此配置非常有用。 当您在源数据仓库上有分区表并且可以并行提取大量数据集时，尤其是在数据仓库迁移的初始加载阶段，这种方法也非常有用。

将 AWS SCT 数据提取代理安装在尽可能靠近数据源的位置，以提高数据迁移性能和可靠性。 为了增加数据迁移速度，请并行使用多个 AWS SCT 代理。

或者，您可以使用 AWS DMS，我们在“数据仓库迁移服务”中介绍，将数据迁移到 Amazon Redshift。 AWS DMS 的优点在于能够执行持续的复制（变更数据捕获）任务。 您还可以使用 AWS SCT 和 AWS DMS 的组合方法。 使用 AWS SCT 进行初始加载，使用 AWS DMS 进行持续复制任务。

将 BLOB 迁移到 Amazon Redshift

Amazon Redshift 不支持存储二进制大对象（BLOB）。但是，如果您需要将一个或多个 BLOB 迁移到 Amazon Redshift，AWS SCT 可以执行迁移。AWS SCT 使用 Amazon S3 存储桶来存储 BLOB，并将对象在 Amazon S3 中的 URL 写入目标数据库的表列中。

我们建议对非常大型数据仓库迁移使用 AWS SCT，对小到中型数据仓库迁移使用 AWS DMS。AWS SCT 代理通过数据压缩、支持表分区的并行迁移以及不同的配置设置，比 AWS DMS 快 15%到 35%。

数据仓库迁移服务

AWS DMS 是一个托管的迁移和复制服务，帮助您将数据库工作负载迁移到 AWS。AWS DMS 支持 20 多种数据库引擎和分析引擎之间的迁移。通过 AWS DMS，您可以发现源数据存储，转换源模式并迁移数据。

使用DMS Fleet Advisor来发现您的源数据基础设施。该服务从您的本地数据库和分析服务器收集数据，并构建一个服务器、数据库和模式的清单，您可以将其迁移到 AWS 云上。

使用DMS 模式转换从源数据库引擎迁移到 AWS 数据库引擎。该服务自动评估并转换您的源模式到新的目标引擎。或者，您可以将 AWS SCT 下载到本地机器上，按照“AWS 模式转换工具”中描述的方式转换源模式。

在转换源模式并将转换后的代码应用到您的 Amazon Redshift 后，您可以使用 AWS DMS 迁移数据。您可以执行一次性迁移或复制持续变更以保持源和目标同步。由于 AWS DMS 是 AWS 云的一部分，您可以享受 AWS 服务提供的成本效益、市场速度、安全性和灵活性。

图 9-3. AWS DMS 复制过程

AWS DMS 的工作原理

AWS DMS 是 AWS 云中运行复制软件的服务器（见图 9-3）。您需要创建源和目标连接来告诉 AWS DMS 从哪里提取数据和加载到哪里。然后，您可以调度在此服务器上运行的任务来移动您的数据。AWS DMS 会在目标上创建表和相关的主键（如果它们在目标上不存在）。如果您愿意，您可以自己创建目标表，或者您可以使用 AWS SCT 创建部分或全部目标数据库对象。

AWS DMS 支持初始加载任务以及持续复制或变更数据捕获（CDC）任务，以迁移新进入源数据仓库的数据。值得注意的是，较大的数据仓库迁移可能包括多个 TB 的数据。在现有网络上执行复制过程可能会因网络带宽限制而变得繁琐。AWS DMS 可使用 AWS Snow Family 的一部分 AWS Snowball Edge 和 Amazon S3 来迁移大型数据库。虽然 AWS DMS 允许对没有主键或唯一键的源表进行复制，但 CDC 延迟可能较高，导致性能水平不可接受。因此，始终为每个源表定义主键是一种最佳实践。

如果源表上未定义主键且您不希望更改源表，则可以使用 DMS 转换规则来定义合成主键，通过连接多个源列，然后告诉 DMS 它是该表的主键。但是，这种方法要求在源数据库上增强日志记录，即使只有少数列实际发生变化，也需捕获表的所有列。

在持续复制期间，识别源数据库系统与 AWS DMS 复制实例之间的网络带宽至关重要。确保网络在持续复制过程中不会造成任何瓶颈。还要识别源数据库系统每小时的变更率和归档日志生成率。这样做可以帮助您了解持续复制过程中可能获得的吞吐量。

AWS DMS 使用按使用量付费的模式。您只在使用 AWS DMS 资源时付费，而不是传统许可模型的前期购买成本和持续维护费用。AWS DMS 自动管理迁移所需的所有硬件和软件的部署、管理和监控。

AWS DMS 自动管理支持迁移服务器的所有基础设施，包括硬件和软件、软件打补丁和错误报告。AWS DMS 还提供自动故障转移功能；如果您的主复制服务器由于任何原因发生故障，备用复制服务器可以接管服务而几乎不会中断服务。

将 AWS SCT 和 AWS DMS 代理安装在不同的机器上。确保 AWS DMS 代理安装在与 ODBC 驱动程序和 AWS Snowball Edge 客户端相同的机器上，以实现高效性能，详细信息请参阅 “AWS Snowball Edge 客户端”。

使用 AWS DMS 可创建三种迁移任务之一：

迁移现有数据（仅全量加载）

执行从源端点到目标端点的一次性迁移。

迁移现有数据并复制持续变更（全量加载和 CDC）

执行一次性从源到目标的迁移，然后继续从源到目标复制数据更改。

仅复制数据更改（仅 CDC）

不执行一次性迁移，而是继续从源到目标复制数据更改。

以下是 AWS DMS 加载数据到 Amazon Redshift 目标的步骤：

1. AWS DMS 将数据从源写入 CSV 文件到复制服务器。

2. AWS DMS 使用 AWS SDK 将 CSV 文件上传到您在您的帐户中指定的 S3 存储桶。

3. 然后 AWS DMS 在 Amazon Redshift 中发出COPY命令，将数据从 CSV 文件复制到目标 Amazon Redshift 表中。

4. 对于持续复制，AWS DMS 首先将数据加载到临时表，然后按以下方式运行 DML 语句：

   1. 使用增强日志记录

      1. 插入的源行 → 插入到目标

      2. 删除的源行 → 删除到目标

      3. 更新的源行 → 删除并插入到目标

   2. 使用部分日志记录

      1. 插入的源行 → 插入到目标

      2. 删除的源行 → 删除到目标

      3. 更新的源行 → 更新到目标

如果您在 Amazon Redshift 目标中使用增强 VPC 路由，则所有 Amazon Redshift 集群与数据存储库之间的COPY流量都通过您的 VPC。如果未启用增强 VPC 路由，Amazon Redshift 将通过 Internet 路由流量，包括 AWS 网络内其他服务的流量。如果未启用此功能，则无需配置网络路径。但是，如果启用了此功能，则必须明确创建集群 VPC 与数据资源之间的网络路径。您可以配置VPC 终端节点或VPC 中的网络地址转换（NAT）网关。

您还可以使用 AWS KMS 密钥对推送到 Amazon S3 的数据进行加密，然后加载到 Amazon Redshift 目标。您只需具备适当的 IAM 角色与 AWS 托管策略，并指定带有宽容密钥策略的 KMS 密钥 ARN，即可在 AWS DMS 设置中使用。

AWS DMS 还具有列出的资源配额和约束，请参阅AWS 数据库迁移服务的资源配额。

此外，您可以参考“使用亚马逊 Redshift 优化 AWS 数据库迁移服务性能”白皮书。

DMS 复制实例

对于性能而言，适当大小的复制服务器至关重要。一些较小的亚马逊 EC2 实例类别已足以用于测试服务或小规模迁移。但是，如果您的迁移涉及大量表，或者打算同时运行多个复制任务，请考虑使用具有相对较多内存和 CPU 的较大 EC2 实例之一。

C5 实例类别专为处理计算密集型工作负载而设计。AWS DMS 可能会消耗大量 CPU 资源，特别是在大规模迁移到 Amazon Redshift 时。

R5 实例类别为内存优化，适用于内存密集型工作负载。使用 AWS DMS 进行高吞吐量事务系统的持续复制任务迁移或复制可能会消耗大量 CPU 和内存。建议使用 R5 实例，因为每个 vCPU 包含更多内存。

由于 AWS DMS 服务器是 AWS 云中的计算资源，因此您的 AWS DMS 迁移任务的性能取决于：

• 源端资源可用性

• 可用网络吞吐量

• 复制服务器的资源容量

• 目标端接收更改的能力

• 源数据类型和分布

• 需要迁移的对象数量

您可以通过使用多线程任务设置来提高 Amazon Redshift 目标端点的全量加载和 CDC 任务的性能。它们允许您指定并发线程数和要存储在缓冲区中的记录数。

参考 AWS DMS 最佳实践，其中涵盖了广泛的建议。

DMS 复制验证

AWS DMS 支持数据验证，以确保您的数据从源到 Amazon Redshift 的准确迁移。如果启用验证，则在表的全量加载后立即开始验证。验证会比较正在进行的复制任务的增量变化。当为仅复制任务启用验证时，然后在开始新数据验证之前验证表中所有现有数据。

在数据验证阶段，AWS DMS 将每行源数据与目标数据进行比较，验证它们是否包含相同的数据，并报告任何不匹配。为实现此目的，AWS DMS 发出适当的查询以检索数据。

DMS 验证查询会在源和目标端消耗额外资源，以及额外的网络资源，因此请确保适当调整 DMS 实例的大小。

数据验证需要额外的时间，超出迁移本身所需的时间。额外的时间取决于迁移了多少数据。

将迁移或复制任务的数据验证部分拆分为单独的仅验证任务。这样可以控制验证发生的确切时间，并通过为验证任务使用单独的 DMS 实例减少主复制实例的负载。同时，单独的验证任务允许您在运行该任务时快速确定有多少行不匹配。

源端主键值用于跟踪持续复制变更。在源表上运行更改或删除操作，这些操作会更改或删除主键值，将需要 AWS DMS 运行完整验证扫描。除非用于小型参考数据源表，否则这是一项昂贵且耗时的任务。

表 9-4 总结了我们迄今讨论过的 AWS 迁移工具。

表 9-4. AWS DMS 与 AWS SCT 对比

AWS 数据库迁移服务	AWS 模式转换工具
付费服务（有免费套餐）	免费下载软件
服务器在 AWS 云上运行	安装在本地机器上
支持多个可用区以实现高可用性	一次只能处理一个机器
小于 10 TB 迁移	大于 10 TB 迁移
源数据库或目标数据库必须在 AWS 上	支持本地到本地转换
从源数据库表迁移数据到目标	将架构从一个数据库引擎转换为另一个
支持变更数据捕获（CDC）	主要用于初始数据加载
可直接与目标数据库工作	可与 AWS Snowball Edge 工作
能够读写加密数据库	有限的加密支持，Amazon RDS 或 Amazon Aurora

还有其他数据集成合作伙伴工具，如 Informatica、Matillion、SnapLogic、Talend 和 BryteFlow Ingest，特别是如果你已经对它们有所了解的话，可以考虑使用它们。

AWS Snow Family

AWS Snow Family 设备用于将数据从您的数据中心移动到 AWS 基础设施，而无需依赖可能正在使用的现有网络，用于日常活动。当网络带宽限制不存在时，AWS Storage Gateway 和 AWS Direct Connect 服务是很好的选择。您可以使用 AWS Snow Family 服务进行脱机数据传输。

让我们看看在不同网络链接上传输 10 TB 数据的预估时间（见表 9-5）。所需时间以天/小时/分钟/秒的格式表示，并假设你能获得整个带宽或额定速度。在共享线路上，通常可以获得额定速度的 1/10 至 1/25。

表 9-5. 传输 10 TB 数据的预估时间

网络类型	额定速度	预估时间	共享（1/10）
T3/DS3 线路	45 Mbps	20 天 13 小时 49 分钟 38 秒	205 天 18 小时 16 分钟 18 秒
快速以太网	100 Mbps	9 天 06 小时 13 分钟 20 秒	92 天 14 小时 13 分钟 20 秒
T4/DS4 线路	275 Mbps	3 天 08 小时 48 分钟 29 秒	33 天 16 小时 04 分钟 51 秒
吉比特以太网	1000 Mbps	0 天 22 小时 13 分钟 20 秒	9 天 06 小时 13 分钟 20 秒
10 吉比特以太网	10 Gbps	0 天 02 小时 13 分钟 20 秒	0 天 22 小时 13 分钟 20 秒

在选择使用现有网络进行数据传输还是 AWS Snow 设备时，请考虑以下几点。

AWS Snow Family 关键特性

Snow Family 设备具有计算资源，可在边缘收集和处理数据。这提供了在写入数据到 AWS Snow 设备时，在您的站点上运行预处理数据等转换的能力。

AWS OpsHub 是一个免费的图形界面工具，可帮助您轻松设置和管理 Snow 设备，并快速部署边缘计算工作负载，并将数据迁移到云端。您的本地应用程序可以将 Snow Family 设备作为网络文件系统（NFS）挂载点使用。支持 NFS v3 和 v4.1，因此您可以轻松地将 Snow 设备与现有的本地服务器和基于文件的应用程序配合使用。

每个 Snow 设备使用E Ink航运标签进行防篡改跟踪，并通过 Amazon 简单通知服务（SNS）、短信和 AWS 控制台进行返回运输的自动标签更新。

所有迁移到 AWS Snow Family 设备的数据都会使用 256 位加密密钥自动加密，这些密钥由 AWS 密钥管理服务（KMS）管理。加密密钥永远不会存储在 AWS Snow 设备上，因此您的数据在传输过程中保持安全。

AWS Snow 设备具有可信平台模块（TPM），提供硬件信任根。每个设备在使用后都会进行检查，以确保设备的完整性，并帮助保护您数据的机密性。

AWS Snow Family devices

AWS Snowcone 是 AWS Snow Family 边缘计算和数据传输设备中最小的成员。它提供 22 TB 的存储空间，4 个 vCPU，4 GB 内存，重量不到 5 磅。您可以使用 Snowcone 收集、处理并将数据移动到 AWS，可以通过邮寄设备离线使用，也可以通过AWS DataSync在线使用。

AWS Snowball 是一个手提箱大小的，重 50 磅的数据迁移和边缘计算设备，提供两种设备选项——计算优化设备或存储优化设备：

Snowball Edge 存储优化设备

为本地处理提供 80 TB 硬盘驱动器（HDD）存储空间，1 TB SSD 存储空间，40 vCPU 和 80 GB 内存。非常适合大规模数据传输的大容量本地存储。

Snowball Edge 计算优化设备

为本地处理提供 28 TB SSD 存储空间，104 vCPU 和 416 GB 内存，并提供可选的 GPU，适用于断开连接环境中的高级机器学习和全运动视频分析等用例。

AWS Snowmobile 是一个用于将大规模数据迁移到 AWS 的百亿字节级数据迁移设备。您可以在一个 45 英尺长的强化运输集装箱中迁移高达 100 PB 的数据，由半挂卡车牵引。

当您使用 AWS Snow 设备时，数据迁移过程可以如图 9-4 所示进行可视化。

1. 您可以使用 AWS SCT 在本地提取数据并将其移动到 AWS Snowball Edge 设备中。

2. 您将边缘设备（们）运回 AWS。

3. 在 AWS 收到您的运输后，边缘设备会自动将其数据加载到 Amazon S3 存储桶中。

4. AWS DMS 将 S3 文件应用到目标数据存储中。

图 9-4。AWS Snowball 迁移过程

在 AWS DMS 中，您可以指定特定的时间戳或系统更改号（SCN）来启动 CDC。基于该时间戳或 SCN，将生成 CDC 文件。

您不能使用 AWS DMS 来使用 AWS Snowcone 设备迁移数据。您只能使用 AWS SCT 与 AWS Snowcone 设备一起使用。

AWS Snowball Edge 客户端

Snowball Edge 客户端是一个独立的终端应用程序，您可以在本地服务器上运行它，以解锁 AWS Snow 设备并获取凭据、日志和状态信息。您还可以将多个 AWS Snow 设备集群成 Snowball Edge 集群。您可以使用此 Snowball Edge 客户端进行所有设置，包括设置网络、标签、启动和停止服务以及设置集群。有关 Snowball Edge 客户端命令的完整列表，包括使用示例和样本输出，请参阅Snowball Edge 客户端命令。

数据库迁移过程

在高层次上，迁移过程包括三个步骤。两步迁移策略和迭代迁移策略涵盖了所有三个迁移步骤。但请注意，迭代迁移策略会在多个迭代中运行，每个迭代都必须按照这些迁移过程步骤进行。由于只有不需要连续运行的数据库才适合单步迁移，因此在以下各节中概述的迁移过程中只需要步骤 1 和步骤 2，这是单步迁移策略所需的。

步骤 1：转换模式和主题区域

在这一步中，您需要转换源数据仓库的模式，使其与 Amazon Redshift 兼容（参见 Figure 9-5）。在进行实际转换之前，需要评估此转换的复杂性。您可以利用 AWS SCT 等模式转换工具，AWS 合作伙伴的其他工具，或者您可能已经具有专业知识的第三方提供商的工具。请记住，在某些情况下，您可能还需要使用自定义代码来进行复杂的模式转换，正如我们在“AWS 模式转换工具”中所探讨的那样。

图 9-5. AWS SCT 模式转换

步骤 2：初始数据提取和加载

在这一步中，您完成了初始数据提取，并首次将源数据加载到 Amazon Redshift 中（参见 Figure 9-6）。您可以创建 AWS DMS 加载任务或使用 AWS SCT 数据提取器从源数据仓库提取数据，如“SCT 数据提取代理”所述，并在数据大小和数据传输要求允许在互联网络上传输数据时将数据加载到 Amazon S3。或者，如果存在网络容量限制等限制，则可以将数据加载到 Snowball 以便转移到 Amazon S3。当源数据仓库中的数据在 Amazon S3 上可用时，将其加载到 Amazon Redshift，如“AWS Snow Family”中所述。

图 9-6. AWS SCT 初始加载

第三步：通过数据捕获进行增量加载

这通常被称为 CDC 阶段、增量加载阶段或持续复制阶段。CDC 是一个捕获数据库中更改的过程，并确保这些更改复制到数据仓库等目标。在这一步骤中，您使用 AWS DMS 或 AWS SCT，有时甚至使用源数据仓库的本地工具来捕获和加载这些增量变更，从源到 Amazon Redshift。

图 9-7 显示了可用于数据迁移不同方面的 AWS 服务。

图 9-7. AWS 数据迁移服务

现在您应该有足够的信息来开始为数据仓库制定迁移计划。与之前的部分一样，我们深入探讨了可以帮助您将数据仓库迁移到 Amazon Redshift 的 AWS 服务，并使用这些服务的最佳实践来加速数据仓库迁移项目的成功交付。表 9-6 总结了我们到目前为止所涵盖的内容。

表 9-6. 迁移操作摘要

评估	迁移	验证
淘汰与保留	初始数据迁移	模式验证
迁移范围	持续变更复制	数据验证任务
数据可用性	迭代迁移	持续变更验证
ETL 工具	模式转换	业务验证
数据移动选项	数据库迁移服务	切换
迁移评估报告	AWS Snow 设备

Amazon Redshift 迁移工具考虑事项

为了改善和加速数据仓库向 Amazon Redshift 的迁移，请考虑以下提示和最佳实践：

• 使用 AWS SCT 创建迁移评估报告并确定迁移工作的范围。

• 在可能的情况下使用 AWS SCT 自动化迁移。AWS SCT 可以自动创建大部分 DDL 和 SQL 脚本。

  • 当无法进行自动化模式转换时，使用自定义脚本进行代码转换。

• 尽可能将 AWS SCT 数据抽取代理程序安装在靠近数据源的位置，以提高数据迁移性能和可靠性。

  • 为了提高数据迁移性能，正确调整您的 Amazon EC2 实例及其等效的虚拟机，安装数据抽取代理程序。

  • 配置多个数据抽取代理程序以并行运行多个任务，通过最大化分配的网络带宽使用来提高数据迁移性能。

• 调整 AWS SCT 内存配置以提高模式转换性能。

  • 编辑JavaOptions部分以设置可用内存的最小和最大值。以下示例将最小值设置为4 GB，最大值设置为40 GB：

     [JavaOptions]
     -Xmx40960M
     -Xms4096M
    

• 使用 Amazon S3 存储大对象，例如来自现有数据仓库的图像、PDF 和其他二进制数据。

• 为了迁移大表，使用虚拟分区并创建子任务以提高数据迁移性能。

• 了解 AWS 服务（例如 Direct Connect、AWS Transfer Family 和 AWS Snow Family）的用例。

  • 选择合适的服务或工具以满足您的数据迁移需求。

  • 了解 AWS 服务配额并做出明智的迁移设计决策。

加速您的迁移到亚马逊 Redshift

有几个新功能可自动化您的架构转换，保留您对现有脚本、报告和应用程序的投资，加快查询性能，并降低迁移到亚马逊 Redshift 的总体成本。

AWS SCT 转换专有 SQL 语句，包括：

• TO_DATE()函数

• CURSOR结果集

• IDENTITY列

• 带有不等谓词的ANY和SOME过滤器

• 具有RESET WHEN的分析函数

• TD_NORMALIZE_OVERLAP()函数

• TD_UNPIVOT()函数

• QUANTILE函数

• QUALIFY过滤器

请参阅这篇自动化专有 SQL 语句的博客获取更多详细信息。

在接下来的章节中，我们讨论了一些常见的迁移挑战，包括：

宏转换

宏是一种专有的 SQL 扩展。本质上，宏是 SQL 语句，可以接受参数，并可以从应用程序代码的多个入口点调用。您可以将宏视为不返回任何输出值的存储过程。

大小写不敏感的字符串比较

ANSI 兼容的字符串比较是区分大小写的，而且亚马逊 Redshift 是符合 ANSI 标准的，大写的“A”和小写的“a”是不同的。一些数据库支持大小写不敏感的字符串比较。在这里，“A” = “a”为TRUE，就好像两个操作数都转换为小写（或大写）进行比较。例如，在 Teradata 数据库中，大小写不敏感的排序是运行在BEGIN TRANSACTION和END TRANSACTION语义（BTET 模式）的默认会话模式，这是 Teradata 引擎的默认会话模式。

递归通用表达式

通用表达式（CTEs）是在大型复杂的 SQL 语句中封装查询逻辑的便捷方式。使用WITH子句定义 CTEs，主查询通过在FROM子句中引用它来使用 CTEs。

专有数据类型

截至本文撰写时，亚马逊 Redshift 不原生支持INTERVAL、PERIOD或BLOB数据类型。AWS SCT 包括INTERVAL和PERIOD数据类型的自动化、自动类型转换、二进制数据支持以及其他多个数据类型增强功能。

宏转换

尽管亚马逊 Redshift 本身不支持宏，AWS SCT 可以为您自动执行此转换。AWS SCT 将宏转换为亚马逊 Redshift 存储过程。

示例 9-1 展示了一个为员工加薪的宏示例。

示例 9-1。宏的示例

CREATE MACRO Give_Emp_Raise (
  EmployeeNo  INTEGER,
  RaisePerc   DECIMAL(4,2)
)
AS
  (
  UPDATE
    Employee
  SET
    NetPay = NetPay * :RaisePerc
  WHERE
    EmployeeNo = :EmployeeNo ;
);

此宏将转换为显示在示例 9-2 中的存储过程，并在 Amazon Redshift 数据仓库中执行。

示例 9-2. 宏转换为存储过程

CREATE OR REPLACE PROCEDURE give_emp_raise (
  par_empl_nmbr    INTEGER,
  par_raise_perc   NUMERIC(4,2)
)
AS $BODY$
BEGIN
  UPDATE
    employee
  SET
    netpay = netpay * par_raise_perc
  WHERE
    employeenumber = par_empl_nmbr ;
END;
$BODY$
LANGUAGE plpgsql

AWS SCT 还将任何相应的宏调用转换为对应存储过程的调用，以减少手动转换。

不区分大小写的字符串比较

在 Amazon Redshift 中，区分大小写的比较是默认的语义。Amazon Redshift 默认使用正常的 ANSI 兼容语义。Amazon Redshift 现在作为数据库引擎的特性本地执行不区分大小写的比较。通过这一新特性，您可以在定义新数据库、新列或在表达式中使用列时启用不区分大小写的排序规则，如示例 9-3 所示。

示例 9-3. 不区分大小写的样例

CREATE DATABASE new_db collate case_insensitive;

CREATE TABLE new_db.test_case_sensitive
( default_col1      varchar(20)
, sensitive_col2    varchar(20) collate case_sensitive
, insensitive_col3  varchar(20) collate case_insensitive
)
;

INSERT INTO new_db.test_case_sensitive
VALUES ('Hello', 'hello', 'HELLO')
;

让我们比较默认列和显式声明的不区分大小写列与示例 9-4 中的查询。因为 new_db 的数据库默认值是 C⁠A⁠S⁠E⁠_​I⁠N⁠S⁠E⁠N⁠S⁠I⁠T⁠I⁠V⁠E，所以比较是不区分大小写的，字符串匹配。

示例 9-4. 不区分大小写的测试

SELECT 1 AS tst FROM new_db.test_case_sensitive
WHERE default_col1 = insensitive_col3;

 tst
 ---
  1
(1 row)

同样地，您可以覆盖列的大小写敏感性。在示例 9-5 中，我们将大小写敏感的列覆盖为 CASE_INSENSITIVE，并观察到比较再次匹配。

示例 9-5. 不区分大小写的 test2

SELECT 1 AS tst2 FROM new_db.test_case_sensitive
WHERE default_col1 = collate(sensitive_col2, 'case_insensitive');

 tst2
 ---
  1
(1 row)

请注意，Amazon Redshift 不会允许您直接比较 CASE_SENSITIVE 列与 CASE_INSENSITIVE 列（如示例 9-6）。

示例 9-6. 不区分大小写的测试 3

SELECT 1 AS tst3 FROM new_db.test_case_sensitive
WHERE sensitive_col2 = insensitive_col3;

 ERROR: Query with different collations is not supported yet.
 DETAIL:
 -----------------------------------------------
 error: Query with different collations is not supported yet.
 code: 1020
 context:
 query: 0
 location: parse_expr.c:613
 process: padbmaster [pid=17580]

为了避免这种情况，请确保适当地显式覆盖一个或两个操作数的排序规则。这是 SQL 代码的最佳实践，当显式应用排序规则时，将更容易理解。

递归公共表达式

Amazon Redshift 支持递归公共表达式（CTE）。递归 CTE 在查询层次数据（例如显示员工与经理之间报告关系的组织结构图）时非常有用。还请注意，AWS SCT 会自动转换具有递归 CTE 的查询。如果您创建了一个名为 johns_org 的视图，如示例 9-7 所示，SCT 将转换为 Amazon Redshift 中等效的视图。

示例 9-7. 递归 CTE 示例

WITH recursive
  john_org (id, name, manager_id, level)
AS
  (
    SELECT id, name, manager_id, 1 AS level
      FROM employee
     WHERE name = 'John'
  UNION ALL
    SELECT e.id, e.name, e.manager_id, level + 1 AS next_level
      FROM employee e, john_org j
     WHERE e.manager_id = j.id
       AND level < 4
  )
SELECT distinct id, name, manager_id
  FROM john_org
ORDER BY manager_id
;

私有数据类型

AWS SCT 会自动为您转换 INTERVAL 数据类型。AWS SCT 将 INTERVAL 列转换为 Amazon Redshift 中的 CHARACTER VARYING 列。然后 AWS SCT 将使用该列的应用程序代码转换为模拟 INTERVAL 语义。

考虑以下表格，其中有一个MONTH区间列。该表存储了不同类型的缺席请假以及每种请假类型的允许持续时间。您的应用程序代码使用leave_duration列，如示例 9-8 所示。在这里，INTERVAL MONTH字段被添加到当前日期上，以计算请假从今天开始时的结束日期。

示例 9-8. 区间示例

-- source table with INTERVAL data type
CREATE TABLE src_schema.employee_leaves
(
  leave_type_id INTEGER ,
  leave_name VARCHAR(100) CHARACTER SET LATIN ,
  leave_duration INTERVAL MONTH(2)
)
UNIQUE PRIMARY INDEX ( leave_type_id )
;

-- source view with interval logic implemented
CREATE VIEW src_schema.employee_leaves_projected
AS
SELECT
  leave_type_id,
  leave_name,
  leave_duration,
  current_date AS projected_start_date,
  current_date + leave_duration AS projected_end_date
FROM
  src_schema.employee_leaves
;

当 AWS SCT 将表转换为 Amazon Redshift 时，AWS SCT 会将INTERVAL替换为VARCHAR数据类型，如示例 9-9 中leave_duration列所示。现在由于数据存储为VARCHAR，AWS SCT 会将适当的CAST类型添加到 Amazon Redshift 代码中，以将字符串值解释为MONTH区间。然后，它会转换视图的算术逻辑，使用 Amazon Redshift 日期函数进行dateadd MONTH。

示例 9-9. 区间转换为日期

-- target table with VARCHAR data type
CREATE TABLE rs_schema.employee_leaves(
  leave_type_id INTEGER
, leave_name VARCHAR(100)
, leave_duration VARCHAR(64)
)
DISTSTYLE KEY
DISTKEY ( leave_type_id )
SORTKEY ( leave_type_id )
;

-- target view with interval logic implemented
CREATE OR REPLACE VIEW rs_schema.employee_leaves_projected
SELECT
  leave_type_id,
  leave_name,
  leave_duration,
  current_date AS projected_start_date,
  dateadd
    (MONTH,
     CAST (leave_duration AS INTEGER),
     CURRENT_DATE
     )::DATE AS projected_end_date
FROM
  rs_schema.employee_leaves
;

通过使用VARCHAR数据类型来存储leave_duration列，AWS SCT 减少了表转换失败的机会，从而提高了数据迁移成功的概率。如果需要进行一些手动重写，则很可能是视图中的 SQL 代码。

AWS SCT 会自动将PERIOD数据类型转换为两个相应的DATE（或TIME或TIMESTAMP）列在 Amazon Redshift 上。然后 AWS SCT 会转换使用该列的应用程序代码，以模拟源引擎的语义（见示例 9-10）。

示例 9-10. 期间示例

CREATE SET TABLE src_schema.period_table
(
  id INTEGER ,
  period_col PERIOD(timestamp)
)
UNIQUE PRIMARY INDEX (id);

CREATE VIEW src_schema.period_view_begin_end
AS
SELECT
  BEGIN(period_col) AS period_start ,
  END(period_col) AS period_end
FROM
  src_schema.period_table
;

AWS SCT 将示例 9-10 中CREATE SET TABLE语句中的PERIOD(TIMESTAMP)列转换为两个TIMESTAMP列，如示例 9-11 的CREATE TABLE IF NOT EXISTS命令所示。然后，它会转换视图period_view_begin_end`的应用程序代码，以使用这两个新的TIMESTAMP列：

示例 9-11. 期间转换为时间戳

CREATE TABLE IF NOT EXISTS
rs_schema.period_table
(
  id INTEGER ,
  period_col_begin TIMESTAMP ,
  period_col_end TIMESTAMP
)
DISTSTYLE KEY
DISTKEY ( id )
SORTKEY ( id )
;

CREATE OR REPLACE VIEW rs_schema.period_view_begin_end
AS
SELECT
  period_col_begin AS period_start ,
  period_col_end AS period_end
FROM
  rs_schema.period_table
;

概要

数据量正在以前所未有的速度增长。传统上，这些宝贵的资产仅供分析的一小部分。本地数据仓库具有不适合现代大数据分析用例的严格架构。这些传统数据仓库在软件和硬件方面都需要大量的前期投资。

我们介绍了 Amazon Redshift 如何帮助您分析所有数据，并在任何规模下实现低成本和可预测的性能。要将您的数据仓库迁移到 Amazon Redshift，您需要考虑一系列因素，例如数据仓库的总大小、数据变更速率和数据转换复杂性，在选择适当的迁移策略和过程之前，以减少数据仓库迁移项目的复杂性和成本。

使用 AWS 服务，如 AWS Schema Conversion Tool (SCT) 和 AWS Database Migration Service (DMS)，并采纳这些服务的建议和最佳实践，您可以自动化迁移任务，扩展迁移规模，并加快数据仓库迁移项目的交付。

在下一章中，我们将讨论监控和管理 Amazon Redshift 数据仓库的各个方面。

第十章：监控与管理

你无法改进你不测量的东西。

彼得·德鲁克

作为一个完全托管的云数据仓库，亚马逊 Redshift 不断监控您的数据库，并自动捕获和存储与资源利用率以及您在数据仓库上运行的工作负载相关的数据。作为数据仓库的用户，您可以专注于数据的摄取和分析，无需持续监控或管理。亚马逊 Redshift 使操作数据可供您监控，并处理异常以确保数据仓库的最佳性能。

你可以在亚马逊 Redshift 控制台上查看你的数据仓库操作指标，使用 AWS CloudWatch，并直接查询亚马逊 Redshift 系统表。在本章中，我们将从“亚马逊 Redshift 监控概述”开始，并深入探讨监控亚马逊 Redshift 预配置集群和无服务器的各种选项。我们将从“使用控制台进行监控”开始，并讨论“监控和管理无服务器”以及“使用控制台监控和管理预配置数据仓库”。然后我们将涵盖预配置集群和无服务器“使用亚马逊 CloudWatch 进行监控”和“使用系统表和视图进行监控”。如今，对于数据仓库工作负载来说，弹性和高可用性变得越来越重要。我们将介绍如何设置“高可用性和灾难恢复”以及“快照、备份和恢复”。由于监控细节存储在 Redshift 的表和视图中，您可以创建自定义可视化来监控数据仓库。我们将涵盖“使用自定义可视化工具监控亚马逊 Redshift”，帮助您了解如何使用您选择的工具创建自定义可视化。

亚马逊 Redshift 监控概述

亚马逊 Redshift 提供性能指标和数据，以便您可以跟踪集群和数据库的健康和性能。Amazon CloudWatch 是一个监控服务，从 AWS 中的各种服务捕获日志和指标。亚马逊 Redshift 每分钟记录性能数据，并从 CloudWatch 指标和系统表中提供有关查询和加载数据的性能数据和统计信息。您可以使用控制台、CloudWatch 或系统表和视图来监控您的亚马逊 Redshift 工作负载和资源。通过亚马逊 Redshift 控制台，您可以查看 CloudWatch 指标以及查询/加载性能数据。此外，您可以使用 Amazon CloudWatch 查看系统利用率和性能信息，方法是使用标准仪表板模板或创建自定义模板。

你可以利用这些信息来识别和诊断处理时间长的工作负载，并创建阻碍其他工作负载高效执行的瓶颈。监控和诊断的应用场景源自用户的问题，可以归类为监控、故障排除和优化活动。我们将在以下章节中讨论一些常见问题。

监控

监控 是一种主动的活动，你希望积极寻找数据仓库中的异常情况，以确保可以制定流程来避免因系统故障而导致的停机。这些问题包括：

• 我的数据仓库在查询性能和资源利用率方面表现如何？

• 我的数据仓库吞吐量、并发性和延迟如何？

• 查询是否在我的集群中排队？

• 目前有哪些查询或加载正在运行？

• 哪些查询或加载花费的时间比平时长？

• 最近一小时或最近 24 小时内持续时间最长的查询是什么？

• 哪些查询失败了？

• 我的数据仓库平均查询延迟是随时间增加还是减少？

• 我应该何时考虑扩展或工作负载隔离，以避免资源不足？

故障排除

当发生事件并且你正忙于解决问题时，你处于反应模式，Redshift 控制台为你提供以下选项：

• 有用户在特定时间抱怨性能问题。如何识别那个 SQL 并诊断问题？

• 我的查询运行缓慢时，还有哪些查询在运行？所有查询都运行缓慢吗？

• 我的数据库是否被其他用户的查询过载？我的队列深度是增加还是减少？

• 如何识别特定用户运行的查询？

• 我的数据仓库资源使用率非常高。如何查找正在运行的查询？

优化

当你最初为数据仓库设计数据模型时，你会基于某些关于数据使用方式的假设。然而，用户的查询模式可能与这些假设不同。通过监控，你可以识别出可以优化数据仓库以提升性能和利用率的领域：

• 如何优化我们最终用户编写的 SQL？

• 是否需要优化我的模式设计？

• 我的 WLM 队列是否需要调整？

• 如果启用并发缩放，我能得到什么好处？

• 我可以主动监控工作负载以防止运行失控的查询吗？

使用控制台进行监控

Amazon Redshift 控制台提供监控仪表板和选项，用于创建和管理 Amazon Redshift 数据仓库。控制台利用来自 Amazon CloudWatch 和其他系统表的数据，为您提供有关数据库的整体资源利用率和性能指标的见解。这些指标适用于预配置和无服务器数据仓库，并可在相应的仪表板屏幕中查看。无论是无服务器还是预配置的集群仪表板，都有一个显示所有账户中所有命名空间或集群的指标的主仪表板。您可以查看所有命名空间的指标，也可以选择特定的命名空间或集群以监视特定的数据仓库。使用控制台帮助您通过在一个位置查看数据仓库的健康状况和性能来简化数据仓库的管理。控制台监控指标在控制台的各个部分中组织，我们将在接下来的章节中讨论。

无服务器的监控和管理

这包括命名空间列表、查询指标、RPU 容量和 CloudWatch 中的任何警报，如 Figure 10-1 所示。主无服务器仪表板显示了账户中所有命名空间或工作组的查询和数据库指标的详细信息。通过这个视图，您可以将查询工作负载与使用的 RPU 容量相关联，了解一天中哪个时间段您的利用率较高，以及是否需要增加无服务器的基础 RPU。您还可以查看所有失败的查询，进一步分析失败原因。

Figure 10-1. 无服务器查询和数据库监控

在无服务器仪表板中显示的详细指标列表如 Table 10-1 所示。有关单个无服务器实例级别的指标，请参见下一节。

Table 10-1. 无服务器主面板中的监控指标

指标	详细信息
查询指标	运行中和排队中的查询
	使用的 RPU 容量
完成和失败的查询	时间轴上完成或失败的查询
	使用的 RPU 容量
查询数量	时间轴上的查询计数
	使用的 RPU 容量

还有其他监控选项可用于监控查询、数据库和资源，您可以通过单击左侧菜单按钮进入。在这里，您将看到“查询和数据库监控”以及“资源监控”选项。

无服务器的查询和数据库监控

当你需要监控工作负载时，通常会针对特定的命名空间或工作组进行监控。要过滤特定的无服务器命名空间或工作组的指标，你可以从主仪表板上选择特定的命名空间，要么通过点击链接，要么通过筛选命名空间来进行。这将显示该特定命名空间的查询和数据库资源指标。

无服务器查询和数据库监控

当您选择“查询和数据库监控”时，可以选择无服务器工作组来分析查询和负载工作负载。在这里，您可以选择监控“查询历史记录”或“数据库性能”，如 图 10-1 所示。由于无服务器将根据需要自动缩放并添加 RPU 容量，直至配置的最大 RPU 值，因此无需像在提供的集群中那样监控或管理工作负载或工作负载并发。在“查询历史记录”下，您可以使用“查询运行时间”图来查看在相同时间段内运行的查询，选择一个查询来查看更多的查询执行详细信息。您还可以分析和查看查询的完成状态、持续时间和 SQL 语句的详细信息。

您还可以选择额外的过滤器，选择时间范围、查询类型和使用的 SQL 命令类型，或选择特定的用户或数据库，如 图 10-2 所示。

图 10-2. 无服务器查询和数据库监控的额外过滤器

无服务器查询监控的深入展开查询

您还可以进一步展开查询 ID，查看查询 SQL、查询计划和相关指标的详细信息，如 图 10-3 所示。查询计划将基于重写后的查询，并且相关指标包括使用的 RPU 容量和活动数据库连接。

图 10-3. 无服务器查询监控的深入展开

无服务器查询监控的深入展开查询计划

图 10-4 中的查询计划屏幕显示了查询的详细计划，以及各个流和段的运行时间。此外，您还可以看到输入和输出行，以确定瓶颈所在。

图 10-4. 无服务器查询监控的深入展开

无服务器查询监控的深入展开相关指标

相关指标显示了过去 10 小时内使用的 RPUs 的总体容量，以及活跃数据库连接的数量，帮助您将此时段内的容量使用情况与活跃数据库连接相关联。例如，在图 10-5 中，您可以看到从下午 12:00 到下午 3:00 期间存在活跃的数据库连接，除了下午 1:30 左右的一个短暂时期未执行任何查询。这就是为什么 RPUs 容量在 12:00 到 3:00 之间的某些时间保持为零的原因。

图 10-5. 服务器无服务查询监控详细信息

服务器无服务查询和数据库监控的指标详细信息显示在表 10-2 中。

表 10-2. 服务器无服务查询和数据库监控指标

查询/数据库	查询/资源	指标	详细信息
查询历史	查询列表	查询运行时间	使用此图表查看在同一时间段内运行的查询。选择一个查询以查看更多的查询执行细节。
		查询和负载	开始时间、持续时间的查询和负载统计
	资源指标	查询运行时间	查询查看更多的查询执行细节
		使用的 RPU 容量	RPUs 的总体容量
		数据库连接	活跃数据库连接的数量
数据库性能		每秒完成的查询数	每秒完成的平均查询数
		查询持续时间	完成查询的平均时间
		数据库连接	活跃数据库连接的数量
		正在运行的查询	特定时间正在运行的总查询数
		排队查询	特定时间排队的总查询数
		使用的 RPU 容量	RPUs 的总体容量
		查询运行时间分解	按查询类型运行的查询总时间

资源监控

对于 Amazon Redshift 无服务器，计算容量以 RPU 表示，每个 RPU 对应于相关的 CPU 和内存容量。如无服务器控制台中所示选择“资源监控”，您将看到两个图表；第一个显示 Redshift RPUs 的总容量随时间轴的变化，第二个图表显示了按期间累积使用的 Redshift 无服务器。正如前文讨论的，您可以通过扩展额外的过滤选项选择时间范围。正如您所见，只有当工作负载需要处理时才会配置 RPU 容量；实际计算工作负载的使用量降低后，容量将降至零，并且跟踪计算使用模式。类似地，RPU 容量领先于使用图，仅当查询工作负载开始进入无服务器端点时，RPU 容量才会自动扩展。这表明 RPU 容量会自动扩展以满足传入的工作负载。持续大量的累积使用可能表明您可以为无服务器设置更高的初始 RPU，以更快地执行工作负载，但成本相同。

图 10-6. 无服务器资源监控

无服务器资源监控度量的详细信息如 表 10-3 所示。

表 10-3. 无服务器资源监控

---	---
使用的 RPU 容量	RPUs 的总容量
计算使用量	在所选时间范围内 Redshift 无服务器的累积使用情况

使用控制台监控预置数据仓库

Amazon Redshift 预置数据仓库的主仪表板显示所有集群的度量，并且您可以选择特定的预置数据仓库进行监控。如 图 10-7 所示，您可以在各种度量之间切换以查看查询、数据库连接、磁盘空间和 CPU 利用率。

您可以在 Amazon Redshift 控制台中查看和监控的预置集群的性能数据分为两类：

• 数据仓库性能和资源利用度量

• 查询和数据摄取性能度量

使用数据仓库性能度量，您可以监控系统资源，并分析是否需要扩展或缩小。通过查询和摄取度量，您可以分析在给定资源下某个工作负载的执行情况。

图 10-7. 监控数据仓库性能

如 表 10-4 所示，可以总结主仪表板中的这些度量。

表 10-4. 监控预置集群主仪表板中的度量

指标	详情
集群度量	查询数
	数据库连接数
	使用的磁盘空间
	CPU 利用率
查询概述	查询工作负载（短期、中期和长期）以特定时间为基础

数据仓库性能和资源利用率指标

Amazon CloudWatch 捕获您集群的物理方面，如 CPU 利用率、延迟和吞吐量。这些指标直接显示在 Amazon Redshift 控制台中，与您正在查看的数据仓库上下文相关，如图 10-8 所示，适用于预留的集群。对于监控无服务器，您可以跳转到 “监控和管理无服务器” 了解更多资源监控详情。您还可以通过创建仪表板并选择要分析的指标，在 CloudWatch 控制台中查看相同的指标。这些指标的详细信息在 “使用 Amazon CloudWatch 进行监控” 中涵盖。或者，您可以使用 AWS CLI 或 AWS SDK 之一通过自定义 Web 界面来消耗这些指标。

图 10-8. 监控数据仓库性能

当您为预留数据仓库调整大小或为无服务器实例设置基础 RPU 时，通常从当前数据量的估计和热数据的百分比开始。随着工作负载和数据量的增长，您可以调整数据仓库的大小或增加 RPU。Redshift 控制台中的数据仓库性能指标可让您了解数据仓库资源是过度利用还是未充分利用的指示，并且这些数据帮助您监控数据库活动和性能。Redshift 顾问还分析您的工作负载并为您提供大小建议。

使用 Amazon Redshift 中的数据仓库指标，您可以执行以下常见性能任务：

• 检查数据仓库指标在指定时间范围内的异常活动，如磁盘使用率波动、CPU 使用率和查询队列时间，并识别引起异常的查询。您还可以检查这些查询是否导致系统性能下降。然后，您可以为预留的集群添加相关的 QMR 到参数组 WLM 配置中，或者为无服务器工作组设置查询限制。

• 检查历史或当前查询是否影响数据仓库的性能。如果确定存在问题的查询，您可以设置 QMR 规则，以防止此查询影响其他工作负载。然后，您可以在查询执行期间查看计划和整体数据仓库性能的详细信息，并利用此信息诊断查询为何缓慢以及如何改进其性能。

查看性能数据

要查看性能数据，您可以登录 AWS 管理控制台并打开Amazon Redshift 控制台。在导航菜单中，选择预配置的集群仪表板，然后从列表中选择数据仓库的名称以打开其详细信息。数据仓库的详细信息如图 10-9 所示，包括集群性能、查询监控、数据库、数据共享、调度、维护和属性标签。

图 10-9. 选择预配置的集群仪表板

选择“集群性能”标签以查看性能信息，如表 10-5 所示。

表 10-5. 预配置集群仪表板中的集群性能指标

指标	详情
告警	当满足度量阈值时，CloudWatch 将触发告警。
事件	发生在您的集群上的事件。
CPU 利用率	CPU 利用率百分比。
使用的磁盘空间百分比	使用的磁盘空间百分比。
自动清理释放的空间	自动清理在所有表中回收的空间。
数据库连接	连接到集群的数据库连接数。
健康状态	指示集群的健康状况。
查询持续时间	完成查询的平均时间。
查询吞吐量	每秒完成的平均查询数量。
每个 WLM 队列的查询持续时间	完成 WLM 队列的查询的平均时间长度。
每个 WLM 队列的查询吞吐量	每秒完成的 WLM 队列的平均查询数量。
并发缩放活动	并发缩放使用限制。
Redshift Spectrum 的使用限制	Redshift Spectrum 使用限制。

您可以通过单击“首选项”按钮选择额外的指标并配置仪表板，以显示您需要监控的特定指标，如图 10-10 所示。

图 10-10. 选择额外指标的首选项

让我们看一些可用的数据仓库指标及其相应的图表。有关性能指标的详细信息，请参阅集群性能数据。

CPU 利用率

这个指标显示所有节点（领导节点和计算节点）的 CPU 利用率百分比。在安排数据仓库迁移或其他资源消耗型操作之前，可以监控此图表以查看每个节点的 CPU 利用率，找到数据仓库使用最低的时间点。您可以查看图 10-11 中的 CPU 利用率和磁盘使用百分比。如果您持续看到高 CPU 利用率，这表明您的工作负载可能会受益于调整集群大小。如果 CPU 利用率时断时续并伴有间歇性波动，则这可能是使用无服务器进行成本节约的良好案例。

图 10-11. 监视 CPU 利用率

磁盘空间使用百分比

这个指标显示每个计算节点的磁盘空间使用百分比，而不是整个数据仓库，如图 10-12 所示。您可以查看此图表来监控磁盘利用率，并估算是否需要调整大小。当您使用 RA3 节点时，每个 ra3.4xl 和 ra3.16xl 节点可以存储高达 128 TB，ra3.xlplus 可以存储高达 32 TB。因此，您可以存储大量数据，但在调整大小时，还应考虑您的计算需求。

维护操作如VACUUM和COPY使用中间临时存储空间进行排序操作，因此预期磁盘使用率会出现波动。

图 10-12. 监视磁盘空间使用

数据库连接数

这显示了对群集的数据库连接数，如图 10-13 所示。您可以使用此图表查看连接到数据库的连接数，并找到数据仓库使用最低的时间点。您还可以将数据库连接与查询持续时间和查询吞吐量等查询指标进行关联，并分析数据库连接数是否对查询工作负载产生影响。

图 10-13. 监视数据库连接

查询持续时间

这个指标显示完成查询所需的平均时间（以微秒为单位），如图 10-14 所示。您可以在此图表上的数据进行基准测试，以衡量数据仓库内的 I/O 性能，并在必要时调整最耗时的查询。

图 10-14. 监视查询持续时间

查询吞吐量

这个指标显示每秒完成的平均查询数，如图 10-15 所示。您可以分析此图表上的数据来衡量数据库性能，并评估系统支持多用户工作负载的能力。

图 10-15. 监视查询吞吐量

查询和数据接入性能指标：查询监控选项卡

Amazon Redshift 控制台提供有关在数据仓库中运行的查询性能的信息。当用户投诉查询性能问题时，您可以使用查询监控仪表板来分离查询性能问题的原因。您还可以比较查询运行时指标和数据仓库性能指标以确定它们在相同时间轴上的关联性，以帮助您识别性能不佳的查询、寻找瓶颈查询，并确定是否需要调整数据仓库以适应工作负载。

这些数据在 Amazon Redshift 控制台中聚合，帮助您轻松将性能指标与特定数据库查询和负载事件进行关联，如 图 10-16 所示。对于无服务器，您可以参考 图 10-1 进行查询和数据库监控。

单一区域数据仅在 Amazon Redshift 控制台中显示，并未作为 CloudWatch 指标发布。

图 10-16. 监控查询性能

查询和数据摄取性能指标的详细信息显示在 表 10-6 中。

表格 10-6. 预置集群数据仓库仪表板中的查询监控指标

监控	指标	详情
查询历史记录	查询运行时	时间轴上的查询活动。使用此图表查看在同一时间段内运行的查询。选择一个查询以查看更多查询执行详情。
	查询和负载	查询执行详细信息。
数据库性能	工作负载执行细分	查询处理阶段使用的时间。
	按持续时间范围分类的查询	短、中、长查询的数量。
	查询吞吐量	每秒完成的平均查询数量。
	查询持续时间	完成查询所需的平均时间。
	按优先级平均队列等待时间	查询优先级中查询在 WLM 队列中等待的总时间。
工作负载并发性	集群上排队与运行的查询对比	运行中的查询数量（来自主数据仓库和并发扩展集群）与集群中所有 WLM 队列中等待的查询数量对比。

数据仓库级别的查询历史记录

要显示特定集群的查询历史记录，您可以通过单击特定集群的链接选择数据仓库，然后选择“查询监控”选项卡。您将看到“查询历史记录”、“数据库性能”和“工作负载并发性”三个选项卡，如 图 10-17 所示。在此处选择“查询历史记录”选项卡，并可以使用窗口上的按钮在查询列表和集群指标之间切换。

当您选择“查询列表”时，选项卡中包含以下图表：

查询运行时间

此图显示了时间轴上的查询活动（请参见图 10-17）。使用此图可查看在相同时间段内运行的查询。选择一个查询以查看更多的查询执行详情。X 轴显示了所选周期。您可以通过运行、完成、加载等方式过滤图表中的查询。每个水平条代表一个查询，条的长度表示从条的开始到结束的运行时间。查询可以包括 SQL 数据操作语句（例如SELECT、INSERT、DELETE）和加载（例如COPY）。默认情况下，显示所选时间段内前 100 个运行时间最长的查询。

图 10-17. 查询监控性能

查询和加载

此图显示了在集群上运行的查询和加载的列表（请参见图 10-18），您还可以深入到查询 ID 查看查询计划以进一步分析查询。您还可以选择在此终止查询。

图 10-18. 查询监控加载

当您选择“集群指标”时，选项卡中包含以下图表，如图 10-19 所示：

查询运行时间

此图显示了时间轴上的查询活动。使用此图可查看在相同时间段内运行的查询。选择一个查询以查看更多的查询执行详情。

CPU 利用率

此图显示了数据仓库通过主节点和计算节点的 CPU 利用率的情况及其平均值。

已使用的存储容量

此图显示了已使用的存储容量的百分比。

活跃的数据库连接

此图显示了连接到集群的活跃数据库连接数。

图 10-19. 监控数据库性能

查询的数据库性能

数据库性能指标详细说明了查询时间在计划、等待、提交或执行中的花费位置以及数据库的吞吐量。这些指标在“集群指标”和“WLM 队列指标”两个选项卡下可用，您可以使用 Amazon Redshift 的数据库性能指标执行以下操作：

• 分析查询通过处理阶段花费的时间，并查找异常趋势，例如高查询等待时间、运行时间或执行时间，其中在某个阶段花费的时间较长。

• 基于查询状态进行过滤：正在运行的、已完成的、失败的或停止的查询。

• 分析查询数量、持续时间以及查询通过不同持续时间范围的吞吐量（短：< 10 秒、中等：10 秒至 10 分钟、长：> 10 分钟）。

• 查找按查询优先级（最低、低、普通、高、最高、关键）排序的查询等待时间的趋势。通过工作负载管理（WLM），您可以设置具有不同优先级的多个队列，我们在“WLM、队列和 QMR”中进行了介绍。

• 查找 WLM 队列中查询持续时间、吞吐量或等待时间的趋势。

接下来我们将讨论一些示例图表：

工作负载执行分解

此图显示了查询处理阶段计划、等待、提交和实际执行所用的时间（参见 图 10-20）。您可以确定特定查询或查询是否在等待状态中花费了太多时间。这些细节将帮助您评估是否需要调整集群大小。在这种情况下，打开并发缩放可能会有所帮助。

图 10-20. 工作负载执行分解

查询按持续时间范围

此图表显示了短期、中期和长期查询的数量，如 图 10-21 所示。

图 10-21. 按持续时间范围的查询

查询吞吐量

此图表显示了每秒完成的平均查询数量，如 图 10-22 所示。

图 10-22. 查询吞吐量

查询持续时间

图 10-23 显示了完成查询所需的平均时间。

图 10-23. 查询持续时间

按优先级平均队列等待时间

图 10-24 中的图表显示了查询按查询优先级在 WLM 队列中等待的总时间。

图 10-24. 按优先级平均队列等待时间

按队列查询吞吐量

此图表显示了每个 WLM 队列的查询运行时间和吞吐量，如 图 10-25 所示。

图 10-25. 按队列查询吞吐量

工作负载并发

在 图 5-3 中学习到，您可以使用并发缩放功能自动扩展计算能力，以满足动态工作负载的要求。工作负载并发选项卡提供与并发缩放相关的度量，并帮助您理解以下内容：

• 通过比较所有 WLM 队列中排队与运行查询的数量，分析启用并发缩放是否有助于减少排队查询的数量。

• 查看并发缩放集群中的并发缩放活动，并确定并发缩放是否限制在 max_concurrency_scaling_clusters。这将为您提供是否应选择增加集群参数组中的 max_concurrency_scaling_clusters 的指示。

• 查看所有并发缩放集群中并发缩放的总使用情况，以确定启用并发缩放对成本的影响。

对于无服务器，这是自动发生的，您只需要分析“计算容量”。无服务器中的“查询运行时间分解”具有查询等待指标，您可以使用这些指标来分析是否需要增加基础 RPU。接下来我们将讨论一些用于监视并发缩放影响的图表：

集群中排队与运行的查询

图 10-26 显示了集群中所有 WLM 队列中正在运行的查询数量与等待的查询数量的对比。此指标包括主要集群和并发缩放集群中正在运行的所有查询。

图 10-26. 集群中排队与运行的查询

每个队列中排队与运行的查询

图 10-27 显示了每个 WLM 队列中正在运行的查询数量与等待的查询数量的对比。

图 10-27. 每个队列中排队与运行的查询

并发缩放活动

图 10-28 显示了正在主动处理查询的并发缩放集群的数量。您可以使用此指标来了解是否需要增加并发缩放集群的数量或设置任何使用限制。

图 10-28. 并发缩放活动

并发缩放使用情况

图 10-29 显示了具有活动查询处理活动的并发缩放集群的使用情况。

图 10-29. 并发缩放使用情况

跨集群监控查询和负载

在控制台中，有多种监控查询和负载的方式。要分析跨集群的查询和负载，您可以从主要的 Amazon Redshift 控制台菜单中选择“查询和负载”，如图 10-30 所示。在这里，您可以分析和查看查询详情，包括查询的完成状态、持续时间、SQL 语句以及是否为用户查询或由 Amazon Redshift 重写的查询。

用户查询是从 SQL 客户端提交到 Amazon Redshift 的查询，或由 BI 工具生成的查询。Amazon Redshift 可能会重写查询以对其进行优化，这可能会导致多个重写查询。例如，使用自动 MV 功能时，当您在基本表上编写查询时，Redshift 可能会创建一个物化视图，并重写查询以针对物化视图而不是基本表运行。类似地，如果您已有一个物化视图，并且您在基本表上编写查询，查询处理器将重写查询以从现有的物化视图中读取。您可以在控制台上的查询详情页面上查看重写的查询以及最初的用户查询。

监控查询和负载

在显示中的屏幕中 图 10-30，您可以选择要分析查询工作负载的数据仓库，并可以基于日期/时间范围或查询状态进行过滤。这些过滤器可以包括前 100 个查询、已完成的查询以及失败或停止的查询。过滤器列表也显示在此处。

图 10-30. 监控查询和负载

控制台允许您通过单击查询 ID 链接来深入了解特定查询的详细信息。当查询 ID 和其他属性显示在图表下方的行中时，您可以选择查询以查看诸如查询的 SQL 语句、执行详细信息和查询计划等详细信息，如 图 10-31 所示。 "查询详情" 页面显示了用于分析的读写工作负载的父查询和所有重写查询。

图 10-31. 监控查询计划

监控顶级查询

默认情况下，“查询监控” 页面显示所选时间窗口内按运行时间或持续时间排序的前 100 个最长查询。您可以更改时间窗口以查看该时段内的前查询 (见 图 10-32)。前查询还包括已完成的查询和运行中的查询。已完成的查询按查询运行时间或持续时间的降序排序。

图 10-32. 监控顶级查询

识别系统性查询性能问题

考虑这样一个场景，您的许多用户抱怨查询运行时间比正常情况长。您想诊断集群中发生了什么。您可以自定义时间并切换到图形视图，这有助于您将更长的运行时间与集群中发生的情况相关联。正如 图 10-33 中的甘特图和 CPU 利用率图所示，许多查询在 CPU 利用率几乎达到 25% 的时候运行。

图 10-33. 查询持续时间

使用 Amazon CloudWatch 进行监控

Amazon CloudWatch 是一个监控服务，可监控和捕获来自 AWS 各种服务的警报、日志和事件。您可以使用 Amazon CloudWatch 监控和跟踪集群的各种物理方面，如 CPU 利用率、延迟和资源及应用程序的吞吐量。

您可以使用可用的自动模板创建仪表板，也可以使用您希望监控的指标创建自定义仪表板。Amazon Redshift 还有一个自动仪表板可用作模板。请注意，与控制台相比，CloudWatch 中显示的某些性能指标具有不同的比例单位。例如，WriteThroughput 指标以 GB 为单位显示，而控制台上以字节显示，这是节点的典型存储空间的更相关单位。

您可以创建警报来监控指标，并在达到限制或阈值时发送通知。您还可以设置根据阈值自动更改资源的功能；例如，您可以监控 Amazon Redshift 数据仓库中的 CPU 使用率、查询吞吐量或等待时间，然后使用这些数据来确定是否应该增加或减少集群的大小。您还可以使用这些数据来暂停或调整未充分利用的数据仓库以节省费用。使用 CloudWatch，您可以全面了解资源利用情况、应用程序性能以及所有服务的运行健康情况。您可以使用 CloudWatch 监控控制台中提供的指标以及您希望监控 Amazon Redshift 预置集群和无服务器的其他指标。

使用 CloudWatch 指标监控 Amazon Redshift，您可以获取关于整个集群健康和性能或单个节点级别的信息。在使用这些指标时，请记住每个指标都有一个或多个相关联的维度。这些维度告诉您指标的范围，以及指标是针对数据仓库还是单个节点：

• 具有 NodeID 维度的指标为集群节点提供性能数据。此组指标包括领导节点和计算节点。这些指标的示例包括 CPUUtilization、ReadIOPS 和 WriteIOPS。

• 只具有 ClusterIdentifier 维度的指标为集群提供性能数据。这些指标的示例包括 HealthStatus 和 MaintenanceMode。

Amazon Redshift CloudWatch 指标

在 CloudWatch 控制台上，您可以选择各种仪表板来查看服务仪表板、跨服务仪表板、计费仪表板或最近的警报。Amazon Redshift 指标收集在 AWS/Redshift 命名空间下，每分钟收集一次这些指标。您可以选择“服务仪表板”，然后选择“Redshift”来查看在 CloudWatch 中捕获的指标，如图 10-34 所示。

图 10-34. CloudWatch 监控

如你在 图 10-35 中所见，您也可以在列表中搜索任何其他特定服务。AWS 预先创建了大多数常用指标的自动仪表板。此外，如果您想创建自定义仪表板，可以通过选择“自定义仪表板”选项卡来创建您自己的仪表板。

Figure 10-35. CloudWatch 监控搜索 Redshift

自动仪表板包含如 CPU 利用率、磁盘空间使用百分比、数据库连接数、健康状态等指标。如果要添加新指标，您可以使用“添加到仪表板”按钮，如 图 10-36 所示，将适当的指标添加到此仪表板，或者您可以从头开始创建新的客户仪表板。

Figure 10-36. CloudWatch 监控自动添加到仪表板

您还可以将默认的周期覆盖为从 1 秒到 30 天的任意范围。如果有系统级别的警报，详细信息将在此处捕获，您可以筛选只查看警报。

图 10-37 展示了默认的 CloudWatch 监控仪表板，应该能满足大多数用例。但如果需要，您也可以创建自定义仪表板。

Figure 10-37. CloudWatch 监控自动仪表板

要创建自定义仪表板，请选择“自定义仪表板”选项卡，然后单击“自定义仪表板”，如 图 10-39 所示。您可以首先在小组件中选择图表类型，如 图 10-38，然后创建自定义仪表板。

Figure 10-38. CloudWatch 向自定义仪表板添加小组件

Figure 10-39. CloudWatch 创建自定义仪表板

在这里，您可以筛选与 Redshift 相关的指标，并选择任何适用于创建自己的仪表板的指标，这些指标与您的数据库或组织的监控需求相关。您还可以从默认仪表板开始自定义，通过使用“添加到仪表板”选项向仪表板添加新指标。在 图 10-40 中，您可以看到诸如“按资源类型”、“节点指标”、“按集群聚合”等与 WLM 队列和查询相关的指标。

Figure 10-40. CloudWatch 监控自定义仪表板

在某些情况下，特定集群指标代表节点行为的聚合。例如，健康状态和维护模式，其中指标值的解释是所有计算节点的聚合值。

使用系统表和视图进行监控

Amazon Redshift 将关于数据仓库的各种信息存储在系统表和视图中，这些信息对于理解系统如何运行是有用的。这些表作为以 STL、SVCS、STV 和 SVV 字母为前缀的系统视图存在于pg_catalog模式中，具有权限的用户可以直接查询这些系统视图以分析数据库性能。本节解释了存储在这些系统表中的关键细节，提供了一些示例系统表和查询。它还解释了：

• 如何生成不同类型的系统表和视图

• 您可以从这些表中获取什么类型的信息

• 如何将 Amazon Redshift 系统表与目录表连接

• 如何管理系统表日志文件的增长

一些系统表仅供 AWS 员工用于诊断目的。接下来的部分将讨论系统管理员或其他数据库用户可查询的有用信息系统表。

有几种类型的系统表和视图：

STL 系统视图

这些视图是从已持久化到磁盘的日志生成的，用于提供系统历史记录。这些文件驻留在数据仓库集群中的每个节点上。STL 视图从日志中提取信息，并将其格式化为系统管理员可以使用的视图。STL 系统视图保留七天的日志历史记录。日志保留对所有数据仓库大小和节点类型都是保证的，并且不受数据仓库工作负载变化的影响。日志保留也不受数据仓库状态的影响，例如数据仓库暂停时。只有在数据仓库是新的情况下，日志历史记录少于七天。保留日志不需要任何客户操作，但如果您想将日志数据存储超过七天，您必须定期将其复制到其他表或卸载到 Amazon S3。您可以在STL 视图中找到详细的视图列表。

STV 表

这些是包含当前系统数据快照的虚拟系统表。它们基于瞬态的内存数据，并不持久化到磁盘日志或常规表中。

SVCS 系统视图

前缀SVCS提供了有关主集群和并发扩展集群上查询的详细信息。这些视图类似于带有前缀STL的表，不同之处在于 STL 表仅提供对主集群上运行查询的信息。

SVL 视图

Amazon Redshift 中的这些系统视图包含对 STL 表和日志的引用，用于提供更详细的信息。这些视图为查询这些表中常见数据提供了更快捷、更便利的访问。

SVV 视图

Amazon Redshift 中的这些系统视图包含对 STV 表和快照的引用，以获取更详细的信息。

SYS 视图

这些是用于监控查询和工作负载使用情况的系统监控视图。这些视图位于 pg_catalog 模式中。要显示这些视图提供的信息，请运行 SQL SELECT 语句。SYS_SERVERLESS_USAGE 仅收集 Amazon Redshift Serverless 的使用数据。

系统表不包括在自动化或手动数据仓库备份（快照）中。STL 系统视图和日志历史的保留期为七天。如果要存储超过七天的日志数据，必须定期将其复制到其他表或卸载到 Amazon S3。可以编写存储过程或使用 Amazon Redshift 系统对象持久化实用程序 从系统表归档数据。

系统表和视图中的数据具有两类可见性：对用户可见和对超级用户可见：

超级用户可见视图

只有具有超级用户权限的用户才能查看超级用户可见类别中的表中的数据。常规用户可以查看用户可见表中的数据。要使常规用户可以访问超级用户可见表，请为该表 授予常规用户 SELECT 权限。

对用户可见视图

默认情况下，在大多数用户可见表中，另一个用户生成的行对常规用户是不可见的。如果给予常规用户无限制的 SYSLOG 访问权限，则该用户可以查看所有用户可见表中的所有行，包括由其他用户生成的行。有关更多信息，请参阅如何 更改用户 或 创建用户 的信息。

给用户无限制地访问系统表会使用户能够查看其他用户生成的数据。例如，STL_QUERY 和 STL_QUERY_TEXT 包含可能包含敏感用户生成数据的 INSERT、UPDATE 和 DELETE 语句的完整文本。

使用系统视图监控 Serverless

监控视图是 Amazon Redshift Serverless 中用于监控查询和工作负载使用情况的系统视图。这些视图位于 pg_catalog 模式中。这些系统视图的设计目的是为了提供监控 Amazon Redshift Serverless 所需的信息，比起预置集群更为简单。SYS 系统视图已被设计用于与 Amazon Redshift Serverless 协同工作。要显示这些视图提供的信息，可以在任何这些表或视图上运行 SQL SELECT 语句。要获取完整的视图列表，请参阅 系统视图 文档。

系统视图的定义旨在支持以下监控目标。要获取所有系统视图的详细列表，请参阅 “使用 Amazon Redshift Serverless 监控查询和工作负载”。

其中一个视图是SYS_SERVERLESS_USAGE，提供有关使用的计算能力和存储以及计费秒数的详细信息，以及如果存在跨区域数据传输成本（参见图 10-41）。您可以使用查询编辑器 V2 使用SELECT语句查询数据：

SELECT * FROM SYS_SERVERLESS_USAGE;

图 10-41. Serverless 资源监控

系统视图捕获数据，帮助您监视数据仓库和运行的工作负载的各个方面。这些视图可以按以下方式分类：

工作负载监控

您可以随时间监视查询活动，以了解工作负载模式，从而确定什么是正常的（基线）以及符合业务 SLA 的内容。这将帮助您快速识别与正常情况的偏差，这可能是暂时性问题或需要进一步处理的问题。视图SVL_QUERY_SUMMARY、SYS_QUERY_HISTORY和SYS_QUERY_DETAIL提供有关查询工作负载的详细信息，您可以使用这些信息来监视查询运行时每个步骤的详细信息，包括运行时间、读取的块、返回的行以及查询的任何警报。

数据加载和卸载监控

要在 Amazon Redshift Serverless 中移动数据，您可以使用COPY和UNLOAD命令加载或卸载数据。您可以密切监视数据加载或卸载的进度，以字节/行转移和完成的文件来跟踪业务 SLA 的遵守情况。通常通过频繁运行系统表查询（即每分钟一次）来跟踪进度，并在检测到显著偏差时引发警报以进行调查/纠正措施。视图SYS_LOAD_DETAIL、SYS_LOAD_HISTORY、SYS_LOAD_ERROR_DETAIL和SYS_UNLOAD_HISTORY包含行、字节和任何错误的详细信息。

失败和问题诊断

有些情况下，您必须针对查询或运行时故障采取行动。开发人员依赖系统表自我诊断问题并确定正确的补救措施。视图STL_ALERT_EVENT_LOG提供系统范围警报的详细信息，视图STL_LOAD_ERRORS和SYS_LOAD_ERROR_DETAIL提供使用COPY命令进行数据加载时的错误详细信息。

性能调整

您可能需要调整未满足 SLA 要求的查询，无论是从一开始就未满足还是随时间降低。要进行调整，您必须有包括运行计划、统计信息、持续时间和资源消耗在内的运行时详细信息。您需要基线数据来确定引起偏差的原因，并指导您如何提高性能。一些用于用户对象监视的关键表格包括：

SYS_QUERY_HISTORY和SYS_QUERY_DETAIL

使用这些视图通过检查是否存在长的queue_time、lock_wait_time或planning_time来分析查询并调整性能。您还可以查看返回的行以确定是否可以筛选所选数据。

SVV_TABLE_INFO

此视图包括有关压缩编码、分布键、排序样式、数据分布偏差、表大小以及特定表的统计信息的详细信息。 使用这些信息，您可以诊断和解决像数据分布偏差这样可能影响查询性能的表设计问题。

用户对象事件监视

您需要监视用户对象上的操作和活动，例如刷新物化视图、吸尘和分析。 这包括系统管理的事件，如物化视图的自动刷新。 如果是用户发起的事件，您希望监视事件结束的时间，或者如果是系统发起的，监视最后一次成功运行的时间。 可用于用户对象监视的一些关键表包括：

SVV_VACUUM_SUMMARY, STL_VACUUM, STL_SORT 和 STL_ANALYZE

汇总系统记录的有关吸尘、排序和分析操作的信息。

SVV_MV_INFO, SVL_MV_REFRESH_STATUS 和 STL_MV_STATE

包含有关物化视图和刷新活动的详细信息。

用于计费的使用跟踪

您可以随时间监视您的使用趋势，以进行预算规划和业务扩展估算。 您还可以识别潜在的节省成本的机会，如调整最大 RPU 或归档冷数据。 按所配置的节点类型和数量计费已配置的集群。 对于无服务器，SYS_SERVERLESS_USAGE 系统表跟踪使用情况并获取查询的费用。 要跟踪 Spectrum 的使用情况，您可以使用 SVL_S3QUERY_SUMMARY 视图。

SVL_QUERY_SUMMARY 视图仅包含由 Amazon Redshift 运行的查询的信息，不包括其他实用程序和 DDL 命令。 要获取 Amazon Redshift 运行的所有语句的完整列表和信息，包括 DDL 和实用程序命令，您可以查询 SVL_STATEMENTTEXT 视图。

高可用性和灾难恢复

在一个组织中，一些应用程序被分类为关键任务，而另一些则被认为不是关键任务。 应用程序的关键任务性可以通过一个度量来衡量，您可以使用它来识别工作负载的重要性。

恢复时间目标和恢复点目标考虑事项

您的应用程序或工作负载的关键任务性由两个维度决定，在设计生产应用程序的备份和恢复架构时，您必须考虑这两个因素：

• 灾难恢复场景中恢复的可接受时间是多少？（恢复时间目标 [RTO]）

• 数据库中所有数据摄入的可接受时间点是多少？（恢复点目标 [RPO]）

  恢复时间目标

  使用 Amazon Redshift 时，您的 RTO 取决于快照恢复时间。通常基于数据仓库中的数据量、节点类型、节点数量以及目标恢复数据仓库或无服务器实例来确定。您可以测试从在生产数据仓库上创建的快照进行恢复，以正确确定 RTO。此外，当您调整数据仓库的大小或数据量发生显著变化时，重新测试恢复性能非常重要。这将确定在服务不可用时什么被视为可接受的时间窗口。如果使用多可用区（Multi-AZ）配置，则 RTO 为 0，因为在单区域策略中没有需要恢复的快照。

  恢复点目标（RPO）

  使用 Amazon Redshift，自动备份是基于更改的块（5 GB）的阈值或一定时间（八小时）触发的。对于数据变化较少的数据仓库，大约每八小时会进行一次备份。对于数据量大的数据仓库，备份可以每小时多次进行。如果发现您的数据变化速率没有触发自动备份以满足您的 RPO 频率，那么您需要构建定制解决方案来保证目标 RPO 之间数据的可接受丢失。这将确定在最后一个恢复点和服务中断之间认为什么是可以接受的数据丢失。

Amazon Redshift 支持为预留 RA3 集群进行 Multi-AZ 部署。Multi-AZ 部署支持同时在多个可用区运行您的数据仓库，并且可以在意外故障场景下继续运行。Multi-AZ 部署适用于需要最高可用性和弹性的业务关键分析应用的客户。

Redshift 的 Multi-AZ 部署利用两个可用区的计算资源来扩展数据仓库的工作负载处理。无论是高并发还是低并发，Multi-AZ 功能始终进行轮询以利用所有资源。它会自动利用两个可用区的资源，通过主动-主动处理提供读写请求的弹性。对于 Multi-AZ，AWS 的建议是为了良好的性能，节点数要加倍。因此，这会造成双倍的价格，但对于预期有大量并发/突发情况的客户来说，这可能是一个引人注目的购买 RI 的方式，而且您不必等待突发性集群可用。

Multi-AZ 与 Single-AZ 部署比较

在单区部署中，Amazon Redshift 需要一个数据仓库子网组来在您的 VPC 中创建数据仓库。数据仓库子网组包括有关 VPC ID 的信息以及 VPC 中子网的列表。当您启动集群时，Amazon Redshift 会自动创建一个默认的数据仓库子网组，或者您可以选择自己喜欢的数据仓库子网组，以便 Amazon Redshift 可以在 VPC 的某个子网中为您的数据仓库进行预配。您可以配置数据仓库子网组，以添加来自不同可用区的子网，Amazon Redshift 会在这些子网中用于数据仓库部署。

当前所有 Amazon Redshift 集群都是在 AWS 区域内特定可用区创建和定位，因此称为单区部署。对于单区部署，Amazon Redshift 会从区域内一个可用区中选择子网并部署数据仓库。

另一方面，多区部署同时在多个可用区预配。对于多区部署，Amazon Redshift 会自动从两个不同可用区中选择两个子网，并在每个可用区中部署相同数量的计算节点。所有这些跨可用区的计算节点通过单个端点使用，因为来自两个可用区的节点都用于工作负载处理。

如图 10-42 所示，Amazon Redshift 在单区部署中在一个可用区中部署数据仓库，在多区部署中在多个可用区中部署数据仓库。

图 10-42. 多区部署与单区部署的比较

创建或将预配数据仓库转换为多区配置

您可以在创建新的预配集群时设置 Amazon Redshift 多区部署，或将现有的单区集群迁移到多区配置。本节中，我们涵盖了两种选项：

创建带有多区选项的新数据仓库

您可以通过 Amazon Redshift 控制台轻松创建新的多区部署。对于多区部署，Amazon Redshift 将在两个可用区中部署相同数量的节点。多区部署的所有节点在正常操作期间都可以执行读写工作负载处理。多区部署仅支持配置的 RA3 集群。如图 10-43 所示，在创建新集群时选择“是”以进行多区部署选项。这将在两个可用区中部署该集群，并且节点数量为输入值的两倍。

要了解如何在多个可用区中创建 Amazon Redshift 配置的预配数据仓库的详细步骤，请参考博客文章“为您的 Amazon Redshift 数据仓库启用多区部署”。

对于多可用区，当您选择节点数量时，您将支付四个节点的费用，因为每个可用区将有两个节点可用。您可以为所有四个节点购买预留实例。

在撰写本书时，多可用区功能 处于预览阶段。因此，您可以选择“预览跟踪”，如 图 10-43 所示，以创建具有多可用区配置的集群。当该功能普遍可用时，您可以选择当前跟踪而不是“预览跟踪”来启用此功能。

图 10-43. 创建新的多可用区数据仓库

将现有数据仓库从单可用区迁移到多可用区

如果您的组织已经在运行 Amazon Redshift，并且没有配置为多可用区，那么可以通过从现有数据仓库中恢复快照（参见 图 10-44）并配置多可用区来迁移该现有数据仓库。从现有单可用区部署迁移到多可用区部署时，为了保持单查询性能，可能需要在两个可用区中都配置与当前单可用区部署中使用的节点数量相同的节点。这样在迁移到多可用区时，需要确保提供的数据仓库节点数量加倍。例如，如果在单可用区中有两个节点，在迁移到多可用区时，需要在每个可用区中都维护两个节点以保持相同的性能。

如果一个可用区发生故障，Amazon Redshift 将自动使用剩余可用区中的资源继续运行。但是，用户连接可能会丢失并且必须重新建立。此外，正在运行的位于失败可用区的查询将停止。不过，您可以重新连接到您的集群并立即重新安排查询。Amazon Redshift 将在剩余可用区处理重新安排的查询。如果查询失败或连接关闭，Amazon Redshift 将立即重试失败的查询或重新建立连接。在多可用区数据仓库恢复期间，可能会出现运行时延迟以处理故障发生后或发生时发出的查询。

图 10-44. 将现有单可用区数据仓库转换为多可用区

多可用区部署的自动恢复

在可用区失败的不太可能事件中，亚马逊 Redshift 多可用区部署将继续通过自动使用另一个可用区中的资源为您的工作负载提供服务。在意外中断期间，您无需进行任何应用程序更改以维持业务连续性，因为多可用区部署可以访问单个数据仓库端点。亚马逊 Redshift 多可用区部署旨在确保没有数据丢失，并且可以查询在故障发生点之前提交的所有数据。

如图 Figure 10-45 所示，如果发生不太可能的事件导致 AZ1 中的计算节点失败，多可用区部署将自动恢复以使用 AZ2 的计算资源。亚马逊 Redshift 还将自动在另一个可用区（AZ3）中提供相同的计算节点，以便在两个可用区（AZ2 和 AZ3）中同时运行。

图 10-45. 多可用区自动恢复

亚马逊 Redshift 多可用区部署不仅用于保护免受可用区故障的可能性，还可以通过自动在多个可用区之间分布工作负载处理来最大化数据仓库的性能。多可用区部署将始终仅使用一个可用区的计算资源处理单个查询，但可以自动将多个同时查询的处理分配到两个可用区，以提高高并发工作负载的整体性能。

在 ETL 过程和仪表盘中设置自动重试是一个良好的实践，这样在主要可用区发生不太可能的故障时，可以重新发出并由辅助可用区的数据仓库提供服务。如果连接中断，可以立即重新尝试或重新建立连接。只有在故障发生时正在进行的活动查询或加载会中止，任何新查询将被路由到辅助可用区，而在失败的可用区中的节点则会恢复到另一个可用区。

快照、备份和恢复

通过亚马逊 Redshift 中的快照启用备份和恢复操作。快照是数据仓库或无服务器的备份，可以自动或手动地在某个时间点进行。

用于备份的快照

亚马逊 Redshift 在写入快照时使用加密的安全套接字层（SSL）连接将这些快照内部存储在亚马逊 S3 中，并使用 AWS KMS 加密进行存储。

您可以从快照中恢复到新的数据仓库或无服务器实例。在恢复快照时，Amazon Redshift 会创建一个新的数据仓库，并在加载所有数据之前使新的数据仓库可用，因此您可以立即开始查询新的数据仓库。数据仓库根据活动查询按需从快照流式传输数据，然后在后台加载剩余数据。您可以通过在 AWS 管理控制台中查看快照详细信息或通过 CLI 中的 describe-cluster-snapshots 或 DescribeClusterSnapshots API 操作来监视快照的进度。对于正在进行中的快照，这些信息包括增量快照的大小、传输速率、经过的时间以及估计剩余时间。

Amazon Redshift 将快照存储在由 Amazon Redshift 管理的内部 Amazon S3 存储桶中，因此始终可用。为了管理存储费用，请评估需要保留自动快照的天数，并相应配置其保留期。删除任何不再需要的手动快照。有关备份存储成本的更多信息，请参阅Amazon Redshift 价格页面。

为了管理成本，您可以为自动和手动快照设置保留期。您可以通过修改数据仓库或创建时间来更改自动和手动快照的默认保留期。

自动快照

默认情况下，自动快照已启用，并且 Amazon Redshift 定期每八小时或每个节点的数据变更超过 5 GB 时拍摄快照，以先到者为准。如果您的数据大于 5 GB * 节点数，则自动快照创建之间的最短时间为 15 分钟。或者，您可以创建一个快照计划以控制何时拍摄自动快照。对于自定义计划，自动快照之间的最短时间为一小时。正如您在图 10-46 中所看到的，快照定期拍摄并在八小时内分布，因为总大小没有变化。

图 10-46. 自动快照

自动快照在保留期结束时或删除集群时删除。如果要删除集群，请记得为恢复拍摄手动快照。您还可以安排在每日加载后手动拍摄快照，以在灾难恢复情况下提供恢复点。

手动快照

当您希望对数据库进行完整备份或需要较长的快照保留期时，可以随时创建手动快照。您可以使用控制台或 CLI 命令 create-cluster-snapshot 创建手动快照。在控制台中，选择一个集群，在“操作”菜单下选择“创建快照”以创建手动快照。对于手动快照，您可以选择使用保留期选项无限期保留或特定时间段，如图 10-47 所示。即使删除集群，手动快照也会被保留。您可以为手动快照加上日期时间戳标记，以便将其恢复到先前的状态。

图 10-47。手动快照

要提高还原快照过程的性能，可以创建不需要备份的表，并使用 BACKUP NO 选项。这还将减少快照使用的存储空间。

使用跨区域快照进行灾难恢复

灾难恢复（DR）传统上仅对事务应用程序至关重要。但是最近，随着数据和分析在决策中的重要性增加，数据仓库应用程序变得至关重要。因此，在构建数据仓库应用程序时，灾难恢复必须成为架构和策略的一部分。

DR 是关于为灾难做好准备，并在主要区域出现意外中断时快速从另一区域恢复您的操作的能力。

使用 Amazon Redshift，可以从控制台设置跨区域快照。选择一个集群，您可以使用“操作”菜单，并选择“配置跨区域快照”，如图 10-48 所示，设置跨区域快照以将数据仓库的快照复制到另一个 AWS 区域。您可以配置将快照复制到的位置以及在目标 AWS 区域中保留自动或手动快照的时间长度。当为集群启用跨区域复制时，所有随后创建的手动和自动快照都会复制到指定的 AWS 区域。

在区域性灾难发生时，您可以使用快照快速在另一区域恢复，并确保应用程序的业务连续性，同时保持成本控制。

图 10-48。用于灾难恢复的跨区域快照

对于跨多个区域的 Amazon Redshift 的主动-主动设置，可以使用Amazon Route 53，这是一个完全托管的 DNS 服务，进行基于延迟或任何规则的路由，以确定用户将访问哪个集群。您可以参考这篇博客文章：“构建多 AZ 或多区域 Amazon Redshift 集群”。

使用快照进行简单重播

对于需要全天候可用的业务关键工作负载，可能无法在生产集群上测试不同的数据模型配置或系统配置。在这些场景下，您可以使用来自主生产数据仓库的快照创建一个测试环境，以测试配置更改是否符合您的性能预期。Simple Replay Utility 是一个工具，您可以使用它进行假设分析，评估您的工作负载在不同数据库配置下的性能表现。

使用 CloudTrail 监控 Amazon Redshift

AWS CloudTrail 是一个记录用户、角色或 AWS 服务在 Amazon Redshift 中执行操作的服务。CloudTrail 捕获所有 API 调用，包括从 Redshift 控制台的调用和通过代码执行的 Redshift 操作调用。Amazon Redshift 数据共享、Amazon Redshift 无服务器、Amazon Redshift 数据 API 和查询编辑器 V2 都集成在 AWS CloudTrail 中，并在 CloudTrail 操作类别下提供，例如 “Redshift”、“Redshift-data”、“sqlworkbench” 和 “Redshift-serverless”。

CloudTrail 捕获的 Amazon Redshift 事件持续传送到 Amazon S3 存储桶。如果未配置跟踪，则仍可以在 CloudTrail 控制台的事件历史中查看最近的事件。使用 CloudTrail 收集的信息，您可以确定发送给 Redshift 的请求，请求的来源 IP 地址，请求者身份，请求时间以及请求参数。

要使用 CloudTrail 监控 Amazon Redshift，您可以按照以下步骤操作：

启用 CloudTrail

首先，在您的 AWS 帐户中启用 CloudTrail（如果尚未启用）。CloudTrail 记录 AWS API 调用并捕获相关事件。

配置 Redshift 事件日志记录

启用 Amazon Redshift 集群的事件日志记录。这将确保将与 Redshift 相关的事件记录在 CloudTrail 中。您可以通过 AWS 管理控制台或使用 AWS CLI 启用事件日志记录。

查看 CloudTrail 日志

一旦启用了 CloudTrail 并配置了 Redshift 事件日志记录，您可以查看 CloudTrail 日志。这些日志将包含有关 Redshift API 调用的信息，例如集群创建、修改、删除、用户活动等。

设置监控和警报

使用 AWS CloudWatch 设置监控和警报，以监视特定的 Redshift 事件。CloudWatch 允许您创建自定义指标，并根据日志中的特定阈值或模式定义警报。例如，您可以在修改集群或进行特定 API 调用时设置警报。

分析和响应

定期审查和分析 CloudTrail 日志和 CloudWatch 指标，以识别 Amazon Redshift 环境中的任何可疑活动或性能问题。根据发现，采取适当的措施来应对情况，例如调查潜在的安全漏洞或优化查询性能。

通过使用 CloudTrail 监控 Amazon Redshift，您可以深入了解 Redshift 集群的活动和使用模式，这有助于维护安全性、解决问题和优化性能。除了 Amazon Redshift 数据库审计日志之外，您还应使用 CloudTrail，以获取内外数据仓库中运行的操作命令的完整图像。

自定义可视化工具来监控 Amazon Redshift

除了使用查询、控制台、CloudWatch 或 API 监控您的数据仓库外，您还可以使用您选择的自定义可视化工具来分析 Amazon Redshift 捕获的指标。Amazon Redshift 在系统表中存储有关查询、摄取、用户日志、工作负载管理以及一般系统配置、性能和使用情况的指标，如 “使用系统表和视图进行监控” 中所讨论的那样。您可以像查询任何其他数据库表一样查询这些系统表和视图。

为了更轻松地使用来自系统表的特定见解来监控数据仓库，您可以使用像 Amazon QuickSight 和 Grafana 这样的可视化工具来构建自己的仪表板。您可以使用 JDBC/ODBC 连接从任何前端可视化工具连接到数据库，并基于对组织重要的指标创建您自定义的可视化。我们将介绍如何使用 AWS 原生可视化工具 Amazon QuickSight 和 Amazon 管理的 Grafana 插件来选择您喜欢的工具构建有影响力的仪表板示例。

使用系统表和 Amazon QuickSight 监控运行指标

通过 Amazon QuickSight，您可以通过现代交互式仪表板、分页报告、嵌入式分析和自然语言查询满足不同的分析需求，这些需求都可以从同一真实数据源获得支持。您可以连接到各种数据库，包括 Amazon Redshift，以创建可视化或报告。您可以通过查询系统表来构建自己的监控仪表板，类似于 图 10-49 所示的那样。

图 10-49. 使用 QuickSight 创建自定义可视化

使用 Amazon Redshift 的 Grafana 插件监控运行指标

Grafana 是由 Grafana Labs 提供的交互式开源可视化工具，用于分析和可视化来自一个或多个数据源的数据。它在各种现代监控堆栈中被使用，使您能够拥有一个共同的技术基础，并在不同系统中应用常见的监控实践。由 AWS 开发的 Amazon 托管的 Grafana 是一个完全托管的 Grafana 服务，可帮助您在指标、日志和跟踪上可视化警报，如 图 10-50 所示。

Grafana 报告增强了协作、透明度和问责制，同时提高了操作指标和趋势的可见性和效率。使用类似 Grafana 的工具可以利用 SQL 的灵活性来获取有关工作负载的见解。您可以查询系统表，如 “使用系统表和视图进行监控” 中讨论的内容。

Amazon Redshift 支持一个用于 Grafana 的插件，您可以通过它构建一个可视化一组策划运行指标的集中式仪表板。这建立在 Amazon Redshift Grafana 数据源之上，您可以将其添加到 Amazon 托管的 Grafana 工作区以及任何其他安装了该数据源的 Grafana 部署中。

若要逐步创建 Amazon 托管的 Grafana 工作区，并使用 Grafana 数据源配置 Amazon Redshift 数据仓库的过程，请参阅博文 “使用 Amazon Redshift 插件查询和可视化 Amazon Redshift 运行指标”。

图 10-50. 使用 Grafana 创建自定义可视化

该解决方案包括以下组件：

• Amazon Redshift 数据仓库或无服务器实例用于获取要分析的指标。

• Amazon 托管的 Grafana，附加了 Amazon Redshift 数据源插件。Amazon 托管的 Grafana 通过 Amazon Redshift 数据服务 API 与 Amazon Redshift 数据仓库进行通信。

• Grafana Web UI，使用 Amazon Redshift 数据仓库作为数据源的 Amazon Redshift 仪表板。Web UI 通过 HTTP API 与 Amazon 托管的 Grafana 进行通信。

如 图 10-51 所示，仪表板显示了集群的运行数据。当您添加更多集群并在 Grafana 中为它们创建数据源时，您可以从仪表板上的数据源列表中选择它们。

图 10-51. 使用 Grafana 创建自定义仪表板可视化

由于 Amazon Redshift 数据源插件是一个开源项目，您可以将其安装在任何 Grafana 部署中，无论是在云端、本地，还是甚至在运行在您笔记本电脑上的容器中。这使您能够将 Amazon Redshift 监控无缝集成到几乎所有现有的基于 Grafana 的监控堆栈中。

摘要

本章讨论了监控亚马逊 Redshift 专用数据仓库和无服务器的不同方式。Redshift 控制台使得任何管理员都可以更轻松地查看关于查询、摄入工作负载或整体系统资源的警报。由于这些统计数据存储在物理表中，您可以灵活使用您选择的工具创建警报，并监控对工作负载重要的关键指标。我们还涵盖了快照作为备份和恢复的机制，以及使用快照进行容错和灾难恢复的选项。

这也将我们带到了本书的尾声。我们着重讨论了基于我们的经验的架构模式和真实客户场景，并提供了关于亚马逊 Redshift 特定功能何时能更好地管理您的数据并为您的客户提供更好访问的见解。正如您所见，我们还在整本书中提供了对在线文档和博客的引用，因此您可以参考最新更新的文档和最佳实践，随着增加更多的功能。在需要时，我们深入探讨了某些主题，并解释了这些特性对业务工作负载的相关性及其示例。希望您发现本书及其参考资源对现代化云端数据工作负载有所帮助。

本书探索了使用亚马逊 Redshift 的数据仓库世界，全面理解其概念、方法和实际应用。我们深入研究了数据仓库的基本原理，审视了强大数据仓库架构的基本组成部分，并讨论了 ETL 过程、数据建模和数据治理的关键角色。

我们见证了数据仓库在促进组织有效存储、组织和分析大量数据方面的变革力量，最终推动了基于信息的决策，并促进了战略洞见的实现。通过将来自不同来源的数据集中到一个统一、可靠且可访问的存储库中，数据仓库使企业能够揭示有价值的模式、趋势和关联，从而增强其竞争优势。我们还讨论了尽管集中化具有其优势，但一个称为数据网格的去中心化数据架构已经发展，以在不移动数据的情况下促进数据访问。

此外，本书强调了将数据仓库倡议与业务目标对齐的重要性，突显了明确定义的数据战略、有效的数据治理框架以及健全的数据质量管理实践的重要性。我们探讨了各种数据仓库架构，例如传统的使用星型模式数据模型的集中式数据仓库，以及包括数据湖、数据网格和数据织物在内的新方法，以及如何利用 Amazon Redshift 构建基于云的解决方案。任何数据专业人士都应该意识到不断变化的景观和适应业务决策者需求的必要性。

随着我们结束这段旅程，必须承认数据仓库领域在技术进步、数据来源的增加和业务需求的发展驱动下仍然以快速的速度演变。对从业者来说，了解新兴趋势（如生成式人工智能、实时数据集成、大数据分析以及人工智能和机器学习技术融入数据仓库流程）至关重要。

最终，本书旨在为读者提供数据仓库原理、技术和最佳实践的坚实基础，作为导航数据管理和分析复杂领域的指南。通过理解与数据仓库相关的关键概念、挑战和机会，读者可以启程进行他们自己的转型之旅，在日益数据驱动的世界中利用数据作为战略资产，释放其组织的全部潜力。