Amazon Redshift 权威指南——面向数据的 AWS数据无处不在，并为我们当下所做的一切提供动力。谁能想到，仅

“在掌握数据之前进行理论推断，是一种严重的错误。”
——夏洛克·福尔摩斯

数据无处不在，并为我们当下所做的一切提供动力。谁能想到，仅仅通过走路你就能产生数据，并且在与朋友通话时还能在手腕上实时查看步数？从手机、智能手表、网页点击到物联网（IoT），我们正以海量方式生成各种类型的数据，组织面临的挑战是如何从这些数据中提炼意义、产出洞察。你必须对这些数据进行分析，用简洁且不带偏见的方式呈现给决策者，从而支持业务决策。数据是支撑洞察与预测的底层力量，推动更优的决策与创新。尽管充满挑战，但你必须驾驭这些数据、重塑业务，以在当下与未来保持相关性。Amazon Redshift 是一项在云端运行、完全托管、PB（拍字节）级的数据仓库服务，它为现代数据架构提供动力，支持将各来源数据存储于集中式或分布式架构中。它让你能够跨数据仓库、数据湖与业务数据库发起查询，从而获得原本无法获得的更快、更深入的洞察。

在本章中，我们将介绍 AWS（Amazon Web Services）数据框架的核心要义，包括是什么成就了“数据驱动型组织”， “现代数据战略”的核心支柱，以及如何构建“现代数据架构”。最后，我们还将深入探讨组织如何运用“数据网格（Data Mesh）与数据织体（Data Fabric）”以可扩展的方式满足各类分析用户群的需求。

数据驱动型组织

数据驱动型组织把数据当作资产；他们不仅让业务用户可用、可达，更让所有需要数据的角色都能获取数据，以便做出更明智的决策。这些组织认可数据的内在价值，也认识到高质量数据给组织带来的价值与经济影响。他们推进数据民主化，使业务决策者能够衡量关键绩效指标（KPI）。彼得·德鲁克的那句名言“无法衡量就无法改进”在今天的商业环境中更显重要。

大多数企业会持续监测一组 KPI 以推动增长、提升生产率。这些 KPI 既包括常见指标，如增长、销量、市场份额、客户数与获客成本，也包括更偏领域的指标，如动销率、产能利用率、邮件退订率、购物车放弃率等。一个好的 KPI 应具体、可衡量、并能对整体业务目标产生实质影响，同时会随企业而异。

尽管员工士气、组织信任度与诚信等某些属性难以量化，但可衡量、可监控以推动改进的方面仍然很多。掌握这些数据后，管理者就能制定策略，引导业务朝期望的方向发展。举例来说，一家制造商在收购一家电动工具公司后，直到 IT 团队把数据整合进核心 ERP 系统之前都像“摸黑前行”。一位高管形容，整合完成的那一刻，就像打开了车灯，看清了这门新业务前方的道路。

在其著作《信息经济学（Infonomics，Gartner 出版）》中，Doug Laney 指出，组织必须不仅仅把“信息是资产”停留在口头或理念层面，而要真正对其进行估值并据此管理。他认为信息应被视作一种新的资产类别：它具有可度量的经济价值，应像其他资产一样被治理。Laney 提供了一个框架，帮助企业把信息作为真实资产来变现、管理与度量。他强调，变现并不等同于“卖数据”或“现金交换”，而是更广义地实现信息价值——从客户需求与兴趣出发，反向对齐业务与运营战略，以满足客户优先级。分析能力帮助组织做出更优决策，也赋能关键战略举措；同时，它还能改善与客户及业务伙伴的关系。

在 2021 年 AWS re:Invent 大会上，Adam Selipsky 提到了佛罗伦萨·南丁格尔如何分析克里米亚战争中的士兵死亡率。作为护士的南丁格尔，通过数据与分析洞察出：多数士兵并非死于战伤，而是死于医院糟糕卫生条件导致的可预防疾病。她将所收集的数据进行分析，并绘制了一个简洁但有力的可视化图（图 1-1）来展示死亡原因。这个玫瑰图（Rose Chart，也称极区图）用一张图就实现了多维比较，显示了各月份因疾病、伤口与其他原因导致的死亡率。借助这个可视化，南丁格尔说服了维多利亚女王与将领们：尤其在冬季，死于疾病的人数多于战伤，从而凸显了医院改革与士兵护理的必要性。这是数据叙事影响力的典型案例——它切实改变了话语与行动，从而拯救生命。

图 1-1 南丁格尔关于死亡原因的玫瑰图

今天，人们往往期待实时洞察，并希望数据“落地即用”。许多数据驱动型企业的励志案例表明，他们通过分析专注并适应客户偏好的变化。比如：全球新闻提供方道琼斯（Dow Jones）通过分析与数据可达性，使邮寄触达的回应率提升了 50%–100%；Magellan Rx 现代化了其数据仓库，通过更快将药物推向市场来改善患者结局，并将运营成本降低了 20%；Moderna 借助 Amazon Redshift 构建简单、具成本效益的数据仓库，打破数据孤岛，在组织内建立单一事实来源（SSOT）；纳斯达克（Nasdaq）将不断增长的数据仓库迁移到更现代的数据湖架构，凭借 Amazon S3 与 Amazon Redshift 的灵活性与可扩展性，把日处理记录从 300 亿条提升到 700 亿条；Netflix 用数据打造了《纸牌屋》等爆款剧集，他们的管理者通过对媒体与娱乐数字化转型过程中产生的数据进行收集与分析，在原本不存在的市场中开辟了利润空间；南美装瓶与分销商 Coca-Cola Andina 构建以 SAP ERP 与其他遗留数据库为源的数据湖，成为单一数据源，使分析团队生产率提升了 80%。

这些成功组织的共性，是推进数据民主化，把洞察交到决策者手中。可靠的数据是产出可执行洞察的基石，而良好设计的数据架构与技术栈能进一步增强数据的可靠性。尽量减少数据在组织内部的多次搬运，是避免不一致、提升数据完整性与信任度的一种方式。这并不一定意味着把所有数据都放入单一存储。通过 Amazon S3，你可以在一个存储中以不同格式保存来自不同源的数据。但许多组织也希望就地查询源系统或独立数据仓库中的数据。由此催生了数据网格与数据织体等新的理念（稍后将在本章介绍）。重视建立数据信任与规模的数据驱动型组织，更有条件获得实时洞察，从而在市场中竞争。

业务用例

从小型企业到全球公司，数据与分析对洞察业务状态至关重要。本书选取了若干常见用例，展示如何结合特定数据模型，利用 AWS 分析型服务产出业务洞察。下面看看这些典型场景，以及分析如何带来业务价值。

供应链管理

电商对传统线下零售的冲击，迫使企业必须用分析来重塑供应链的定义与管理方式。借助数据与定量方法，供需计划人员可以在供应链全周期内改进决策。制造商与零售商可运用统计方法优化供应链决策，实现“在正确时间将正确产品放到正确地点”。他们可以分析库存，并基于需求信号进行供给计划。一个典型例子是 Amazon：它通过 Amazon Redshift 每日处理 51,000 个查询来驱动供应链卓越。

金融

金融与银行机构帮助客户进行投资决策并提供财富管理方案。如今，许多银行利用人工智能（AI）与机器学习（ML）来识别欺诈、预测流失并主动干预以防止欺诈或流失。比如，你也许在外出旅行时遇到过信用卡被临时停用的情况——这是 ML 在后台识别异常活动、在潜在欺诈发生前进行拦截。要实现这些能力，关键是让相关数据可用且易于访问。

客户关系管理（CRM）

为 CRM 构建数据仓库数据模型，可以整合来自销售、市场与客服等多触点的客户数据。通过分析这些数据，企业可以洞察客户行为、偏好与满意度，据此实现个性化营销活动、改进客服并促进长期客户关系。

教育

教育领域的分析可显著提升学生体验与学习结果。传统课堂教学在数字原住民一代面前面临挑战。学校正在应对高辍学率、效果不理想与课程陈旧等问题。转向个性化学习意味着学生能灵活、按自己的节奏学习；这也意味着采用线上学习管理系统，向学习者提供定制化内容。把学生在线学习交互数据与测评成绩数据结合分析，可以洞察学生在哪些方面需要额外帮助。借助 AI 与 ML，教育者能够预测个体学生的学习结果，并主动采取措施，带来更积极的体验与结局。

医疗健康

数据在医疗行业中至关重要：它正在重塑医疗服务的提供方式、医学研究的开展方式，并通过运营效率控制不断攀升的成本。医疗机构通过挖掘大规模数据集中的模式、趋势与相关性，能够支持循证决策，改善患者结局并提升整体医疗服务水平。利用预测分析，这些机构可以更早发现疾病、向高风险人群实施个性化医疗；通过对理赔数据的分析，也可以识别欺诈模式，发现可疑理赔。

生成式 AI 带来的新业务用例

生成式 AI 与数据仓库相辅相成，可共同提升数据分析与决策流程的方方面面。下面概述几种集成方式：

代码生成

生成式 AI 模型可在海量代码库与编程语言上训练，为开发者提供代码补全与建议，实时提升编程效率，减少错误，进而更快把产品推向市场。

自然语言生成

数据仓库常需要将洞察以利于决策者理解的形式呈现。生成式 AI 模型可基于仓库中的数据生成可读报告或叙述，包括摘要或自动化的描述性分析，使管理层更易理解与解读数据与报告内容。

合成数据生成

在训练 ML 模型时，数据质量决定预测准确度。生成式 AI 模型可生成逼真模拟真实世界特征的合成数据。把这类合成数据与真实数据一并存入数据仓库，可扩充数据集，为 ML 模型提供更全面且多样的训练样本，缓解数据稀缺问题，提高分析模型的准确性与稳健性。

异常检测

生成对抗网络（GAN）等生成式模型可用于数据仓库中的异常检测。将 GAN 训练在“正常”数据模式上后，它可通过将生成数据与实际数据对比来识别异常，帮助发现异常模式与离群点，用于识别潜在欺诈交易或异常操作。

数据插补与增强

不完整或缺失的数据会影响分析与决策的准确性。生成式技术可通过学习已有数据的底层模式来插补缺失值。在现有数据上训练的生成模型能够为缺失点生成合理取值，弥补缺口、提升数据仓库的数据完整性。它还可以基于既有数据生成新的合成样本，扩充训练集，提高机器学习算法的性能与泛化能力，从而获得更好的预测与洞察。

现代数据战略（Modern Data Strategy）

“数据引力（data gravity）”这一概念最早由 Dave McCrory 在 2010 年提出。他将数据比作一颗行星，谈到当组织把数据集中到一个地方时会形成“数据质量/数据质量体量（data mass）”。应用与服务会被这团“质量”所吸引，因为离数据越近，性能与吞吐就越好。这会进一步加速数据增长，最终几乎让数据变得难以搬移。来自 IoT、智能设备、云应用与社交媒体的数据仍在呈指数级增长。无论数据格式如何、存放在哪里，你都需要能以更低成本、更少取数到洞察（time-to-insight）的方式去分析这些数据。

数据是每个应用、流程与商业决策的中心，它几乎是所有组织数字化转型的基石。数据驱动新体验，并带来推动创新的洞察。但要制定一份能让整个组织释放数据价值的战略，并非一条易行直线。数据系统往往蔓延、割裂且复杂——多样的数据集分散在数据湖、数据仓库、云数据库、SaaS 应用、IoT 设备以及本地系统中。许多组织坐拥“数据金矿”，却不知道从哪里开始挖掘价值。企业难以搞清数据到底分布在哪里、如何高效打通并行动、以及如何管理对数据的访问。随着数据量增长，这些难题只会更棘手。不能有效利用数据，会阻碍快速决策与持续创新。

要驾驭数据价值，组织需要的不止是单一数据库、数据湖、数据仓库或 BI 服务。现实是：每个组织都有多种用例、多样数据类型，以及需要不同工具的用户与应用，并且这些需求会随时间演变。要真正解锁数据价值以驱动及时洞察与创新，你需要实施一套端到端数据战略，让组织内所有需要数据的人在数据旅程的每一步都更轻松地与数据协作。一套端到端数据战略要把采集、存储与查询、分析、以及构建机器学习模型等所需的工具、资源与流程结合起来，最终帮助终端用户产出数据驱动的洞察。该战略必须具备：

面向任何数据用例的“全面能力集”

一套覆盖当下与未来所需规模、数据多样性与多种用途的完整工具。

便于打通所有数据的“集成工具集”

能够整合跨不同工具与系统存放、分析的数据，以更好理解业务并进行预测。

端到端的数据治理

在恰当的时间与位置，安全地为需要的人提供数据访问。

基于这三大支柱（见图 1-2），你可以在规模上存放与不断增长的数据、无缝访问这些数据，并用安全与治理控制来管理谁可以访问哪些数据。

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

AWS 在其数据服务中提供了内建智能与自动化，来支撑你的端到端数据战略。下面分别深入每一支柱。

全面能力集（Comprehensive Set of Capabilities）

为了理解业务、适应变化的负载、梳理流程并做出更优决策，你需要构建既满足当前也能面向未来的数据战略。仅靠一个数据湖、一个数据仓库或一个 BI 工具并不足以有效驾驭数据。你需要一整套工具，以覆盖规模、数据多样性以及你现在与将来打算使用数据的多种目的。

你可以在数据旅程的不同阶段现代化你的数据架构——这意味着摆脱遗留数据库，转向完全托管、面向特定场景构建（purpose-built）的数据服务。如果你仍在本地运行遗留数据存储，或在云上自管数据库，你仍需负责实例供应、打补丁、配置与备份等管理任务。迁移到 AWS 云或其他超大规模云商的托管服务后，你可以借力云提供商在托管与运行应用方面的经验、成熟度、可靠性、安全性与性能。

要实现端到端数据战略，你需要把数据存放在针对你的工作负载类型优化的数据库中，整合来自多源的数据，并让业务决策者可以用他们偏好的工具来对信息采取行动。如图 1-3 所示，AWS 提供了覆盖存储、集成、行动与治理在内的完整数据能力，以支撑多种数据工作负载。对分析平台采取“一刀切”的现代化方案，最终往往要在能力上妥协；因此 AWS 提供了面向多样数据模型的专用引擎，包括关系型、键值、文档、内存型、图、时序、宽列与账本数据库。这些能力帮助你在数据所在之处访问数据、分析它并对洞察采取行动。

图 1-3 端到端数据战略

这些数据服务与分析工具针对特定类型的工作负载进行了优化，AWS 也提供了将这些专用服务中数据进行集成与治理的工具，例如：

AWS Glue
无服务器、可扩展的 ETL 与数据集成服务，便于从多源发现、准备、搬运与整合数据，用于分析与机器学习。
Amazon DynamoDB
完全托管、无服务器的键值 NoSQL 数据库，面向任意规模的高性能应用。提供内建安全性、持续备份、跨区域复制、内存缓存以及数据导入导出工具。
Amazon EMR
面向 PB 级数据处理的云上大数据解决方案，支持使用 Apache Spark、Apache Hive、Presto 等开源框架进行交互式分析与机器学习。
OpenSearch
分布式、社区驱动、Apache 2.0 许可的开源搜索与分析套件，适用于实时应用监控、日志分析与网站搜索等广泛用例。
Amazon Simple Storage Service（Amazon S3）
对象存储服务，具备高可扩展性、可用性、安全性与性能。可存放结构化与非结构化数据，用于数据湖、云原生应用与移动应用等场景。
Amazon QuickSight
面向用户的无服务器分析服务，基于同一事实来源满足多样分析需求，包括交互式仪表板、分页报表、嵌入式分析与自然语言查询。
Amazon Kinesis
便于采集、处理与分析实时流数据，从而及时获取洞察并快速响应新信息；在规模化、性价比与工具灵活性之间取得平衡。
Amazon Redshift
云端完全托管、PB 级数据仓库服务。可在云上现代化你的数仓，具备合规、安全与治理能力，并可按需扩缩以匹配弹性需求；支持以无服务器或预置方式安全摄取、整合并对历史、实时或预测性数据进行分析。
Amazon SageMaker
完全托管的机器学习服务，用于准备数据并构建、训练、部署任意用例的 ML 模型，提供完备的基础设施、工具与流程。

这些服务彼此紧密集成，可以互通并复用彼此的数据。

集成工具集（Integrated Set of Tools）

最有影响力的数据驱动洞察，来自于对业务与客户的全景认知。只有把跨部门、跨服务、本地工具与第三方应用（如 BI 系统或统计建模工具）中的不同数据源串联起来，才能实现这一点。传统上，打通这些数据往往需要数据复制或复杂 ETL 流水线，耗时数小时乃至数天——这已经跟不上决策的节奏。ETL 需要更容易，且在许多场景下应尽量“免 ETL”。

优秀的企业领导者会沿价值链发现业务变革的机会。但要促成这样的变革，需要让决策者获得业务全貌与“单一事实来源（SSOT）”。这就要求打破数据孤岛，以安全的方式共享与开放数据，从而在全组织范围释放数据价值。

为了快速决策，你需要能随业务增长而扩展的新型数据存储。同时，你也希望把一切连接起来：数据湖、数据仓库以及所有面向特定场景构建的数据存储，合并成一个安全、治理良好的体系。

这种整合视图可以通过多种方式实现：联邦查询、低/无代码的数据同步，或使用无服务器/有服务器执行的传统 ETL。Amazon Redshift 在这些方面均提供选项，并与其他 AWS 服务紧密集成。比如，Amazon Aurora 与 Amazon Redshift 之间的 Zero-ETL 能力，可将事务型数据近实时同步到数仓；Amazon Redshift 支持直接查询位于 Amazon S3 数据湖中的数据；联邦查询功能可安全、直接查询业务数据库中的数据。对于需要计算隔离的分析型工作负载，你可以构建 ETL 流水线将数据抽取、转换并加载至目标存储。与 AWS Glue 的紧密集成使你可以在 Glue Studio 中轻松创建基于 Spark 的作业，并以无服务器方式执行。关于 Redshift 的数据转换策略，详见第 4 章“数据转换策略”。

在向数据分析师与数据科学家暴露数据方面，Amazon Redshift 也简化了访问路径。过去，机器学习常由精通 Python、R 等语言的高技能数据科学家/程序员来完成；如今，凭借与 Amazon SageMaker 的紧密集成，Redshift 的数据分析师可以使用 Redshift ML 在数仓或数据湖内部直接运行 ML 工作负载，而无需自行选择、构建或训练模型。关于 Redshift 机器学习，详见第 6 章“Amazon Redshift 机器学习”。此外，业务分析师可使用 Amazon QuickSight 自动发现 Redshift 数仓并连接数据存储，迅速产出具有业务洞察的高影响力仪表板。关于连接 Redshift 的不同选项，详见第 2 章“Redshift 入门”。

端到端数据治理（End-to-End Data Governance）

建立恰当的治理，可以在控制与开放之间取得平衡，并让组织内的人对数据建立信任与信心。它鼓励创新而非抑制创新，因为合适的人可以在需要时快速找到、访问并共享数据。

为激发创新，组织应当把“数据安全”的理念从“如何把数据锁住”转变为“如何以安全的方式释放数据”。在 AWS 上的端到端数据治理让你能够在数据流程的每一步，控制数据位于何处、谁可以访问、以及能对数据执行哪些操作。

对于数据工程师与开发者，AWS 在 AWS Glue 与 AWS Lake Formation 等服务中提供细粒度控制、数据目录与元数据。AWS Glue 能够跨数据湖、数据仓库与数据库编目数据，并配套数据质量规则以检查数据的新鲜度、准确性与完整性。借助 AWS Lake Formation，你可以治理并审计在 Amazon S3 数据湖上的数据操作，以及 Amazon Redshift 中的数据共享。如果你在 S3 上构建数据湖，还可以使用 Amazon S3 Access Points 为共享数据集创建独立的访问控制策略，轻松管理访问。

数据科学家可以在 SageMaker 中使用治理控制，获取 ML 模型的端到端可见性，包括训练、版本历史与模型表现，集中于同一位置。

最后，Amazon DataZone 是用于编目、发现、共享与治理数据的数据管理服务。它让数据工程师、数据科学家、产品经理、分析师以及其他业务用户更容易发现、使用并围绕数据协作，从而为业务带来洞察。

总结：越来越清晰的是，驾驭数据正成为下一波数字化浪潮。现代化意味着融合数据湖与面向特定场景的数据存储之长，并让基于 ML 的创新变得容易。基于“全面能力、工具集成、端到端治理”这三大支柱，借助 AWS 的现代数据战略，你可以构建按需扩展的架构并降低运维成本。

现代数据架构（Modern Data Architecture）

当你着手实施现代数据战略时，需要考虑如何以低成本、采用开放且基于标准的文件格式，来处理任意规模的数据。该战略还应帮助你打破数据孤岛，使团队能够用其偏好的工具或技术开展分析或机器学习，并通过适当的安全与数据治理控制来管理数据访问。

要落地现代数据战略，你需要一套现代数据架构。你也许听说过数据仓库（data warehouse）、数据湖（data lake）与数据网格（data mesh），并正在考虑其中一种。数据仓库让你存储结构化数据，并对海量数据实现快速查询；数据湖是集中式存储库，可容纳所有结构化与非结构化数据并便于访问；数据网格允许你在原地访问数据，同时将数据的所有权与治理去中心化。要从不断增长的数据体量中获得业务洞察，现代数据架构需要同时支持上述各方面。

AWS 的现代数据架构建立在“面向特定场景构建（purpose-built）”的数据存储之上，以优化规模、可用性、性能与成本。它能够将数据湖、数据仓库与专用数据存储整合起来，实现统一治理与便捷的数据流动。Amazon Redshift 与 Amazon S3 构成现代数据架构的核心，并与其他专用服务紧密集成。

在图 1-4 所示的现代数据架构中，数据流动有三种不同模式：由内向外（inside-out）、由外向内（outside-in）与“环周”（around the perimeter）。

图 1-4 使用面向特定场景服务的现代数据架构

由内向外的数据流动（Inside-out data movement）

有时会把中央数据存储中的一部分数据迁移到某个专用数据存储，例如用于 OLAP 工作负载的 Amazon Redshift、Amazon OpenSearch Service 集群或 Amazon Neptune 集群，以支持搜索分析、构建知识图谱，或二者兼有。在 Amazon Redshift 语境下，你可以把 Redshift 作为中央数据存储，其他服务（如 AWS Glue 或其他 Redshift 数仓）可通过数据共享访问这些数据。或者，你也可将 Amazon S3 数据湖中的数据导入 Redshift（使用 COPY 命令），或将其作为外部 S3 schema 直接查询。

由外向内的数据流动（Outside-in data movement）

组织通常先选择最契合各自应用的数据存储，随后将数据迁入中央数据存储以开展协作。比如，为卸载不常访问的历史数据，你可以将这些数据从 Amazon Redshift UNLOAD 至 Amazon S3 数据湖。某游戏公司可能选择 Amazon DynamoDB 来存放游戏状态、玩家数据、会话历史与排行榜；稍后再把这些数据导出至 Amazon S3 数据湖，用于进一步分析以改善玩家体验。

环周流动（Around the perimeter）

在一些场景中，数据会在不同的专用数据存储之间流转。例如，你可以使用 Amazon Redshift 的联邦查询能力，直接查询诸如 Amazon Aurora 之类的业务型数据存储；或者使用 Redshift ML 运行模型，以触发 Amazon SageMaker 中的流程。

通过从“紧耦合单体应用”转向“由独立组件构成的模块化微服务”，你可以在现代数据战略的各个阶段进行创新。这些原生、专用且可集成的 AWS 服务，非常适合构建模块化应用，同时可利用诸如机器学习与人工智能等新兴技术。

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

Amazon Redshift 为现代数据架构提供动力，使你能够在集中式或去中心化架构中存放数据，并通过为组织中的所有人提供数据访问，来打破数据孤岛。在现代数据架构下，你既可以在数据仓库表中以列式结构化格式存取数据，也可以在 Amazon S3 数据湖中以开放文件格式存取数据。借助跨数据仓库、数据湖与业务数据库进行安全且受治理的查询能力，你可以实现统一视图，并让业务用户与其他应用更容易获取数据。

图 1-5 展示了 Amazon Redshift 的部分关键能力及其与原生服务紧密集成所带来的好处。

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

下面对这些特性做简要概述（后续章节将详细展开）：

海量并行处理（MPP）数据仓库

Amazon Redshift 基于 MPP 架构，通过将查询处理分布到多个节点以及节点内的虚拟处理单元上，加速对海量数据的复杂查询。MPP 还可通过分布键将同类数据共置到处理单元，进一步提升分析的性价比。第 2 章“Redshift 入门”将介绍 MPP 的重要性。

存储与计算分离

自 RA3 代架构起，Amazon Redshift 实现了存储与计算分离，可根据工作负载需求独立弹性伸缩。第 2 章将进一步介绍 Redshift 架构与上手方式。

无服务器（Serverless）

Amazon Redshift 提供无服务器选项，让你无需预置与管理集群即可运行与扩展分析。你只需设定初始的计算配置（以 RPU 计量），Redshift 会自动按需配置与伸缩以应对高要求且不可预测的负载，并按使用付费。无服务器与预置集群兼容，可在不改动既有分析与 BI 应用的情况下迁移。第 2 章将介绍如何创建无服务器数仓。

数据湖分析

Amazon Redshift 可高效查询与转换存放在 Amazon S3 文件中的结构化与半结构化数据，而无需先将数据装载至 Redshift 表。对外部 S3 数据的查询只会把所需数据传回 Redshift。第 3 章“数据建模与数据摄取”将介绍如何从 S3 查询与转换数据。

安全且一致的数据共享

Redshift 数据共享允许在组织内部不同数仓之间，或与外部伙伴共享实时数据。无需复制或移动数据，即可把一个数仓的价值扩展到多套数仓部署；这使你能够在数据所在之处进行访问与查询，在跨组织边界与不同数据域之间共享已经形成“数据质量”的数据体量。第 7 章“数据共享协作”将详细介绍。

以 SQL 使用机器学习

Redshift ML 让数据分析师与数据库开发者使用熟悉的 SQL 在 Redshift 中创建、训练并应用 ML 模型。借助与 Amazon SageMaker 的集成，你无需学习新工具或语言即可缩短模型开发时间。第 6 章“Redshift 机器学习”将说明可用的 ML 问题类型与用法。

Zero-ETL

Amazon Aurora 支持与 Amazon Redshift 的 Zero-ETL 集成，使你可以在 Redshift 上对事务数据进行近实时分析。借助基于日志的复制，写入 Aurora 的事务数据在数秒内即可在 Redshift 中可用；随后你可以直接查询，或用 SQL/存储过程应用转换规则。第 3 章将介绍配置方法。

Spark 应用开发

通过与 Apache Spark 集成，你可使用 Java、Scala、Python 等语言编写 Spark 应用；连接器已原生安装在 Amazon EMR、AWS Glue 与 SageMaker 上。这些应用可在不牺牲应用性能与数据事务一致性的前提下读写 Redshift，并通过下推优化获得性能提升。第 3 章介绍用于摄取的连接器，第 4 章“数据转换策略”介绍其在转换中的用法。

自动摄取 Amazon S3 文件

你可以设置持续的文件摄取规则，跟踪 S3 路径并自动将新文件加载入 Redshift，而无需额外工具或自研方案。使用 COPY 命令是装载 Redshift 的最佳实践；可将 COPY 语句保存为“copy 作业”，自动装载指定 S3 路径中新检测到的文件。第 3 章会介绍装载选项与自动摄取配置。

使用联邦查询访问事务数据

通过联邦查询，你可以在 BI 与报表应用中纳入最新的实时数据：在 Redshift 内直接查询外部 PostgreSQL、MySQL 等数据库中的当前数据，并与仓库中的历史数据合并，为业务用户提供综合视图。第 4 章将介绍如何配置联邦源并实时查询以用于报表与转换。

使用你偏好的 BI 工具

你可通过标准 JDBC/ODBC 或 API，使用任意 BI 工具查询 Redshift，并产出业务洞察。Amazon QuickSight 作为 AWS 原生服务，支持在包括 Redshift 在内的多数据源上创建现代交互式仪表板、分页报表、嵌入式分析与自然语言查询。第 2 章将介绍多种客户端连接方式。

数据发现与共享

Redshift 还支持与 Amazon DataZone 集成，可在治理与访问控制下，跨组织边界进行大规模数据编目、发现与共享。第 7 章将介绍 DataZone 如何实现联邦式数据治理，使数据所有者与主题专家对其数据资产实施安全与访问控制。

采用现代数据架构的真实收益

多家分析机构的研究显示：即便仅提升几个百分点的数据可达性，组织的净收益也会显著增加。Forrester 高级分析师 Richard Joyce 指出：“对于一家典型的《财富》1000 强企业，数据可达性每提高 10%，净收益将增加 6,500 万美元以上。”通过洞察，分析可以开拓新市场或新的业务线，影响营收与运营成本。

一些真实案例：

Intuit 迁移至基于 Amazon Redshift 的方案以提升数据可达性，数据规模扩大 7 倍以上、性能提升 20 倍；团队成本下降 25%，运维时间减少 60%–80%，总体成本节省 20%–40%，模型部署时间缩短 90%，从而把更多时间投入到下一波创新。
Nasdaq 将公司的数据产品整合到云端的集中位置，使数据访问的上市时间从数月缩短到数周；使用 Amazon S3 构建数据湖，每日摄入 700 亿条记录，金融市场数据装载加速 5 小时，Redshift 查询提速 32%。
Expedia Group 依托 70 PB 数据的 AWS 数据服务，每年处理 6,000 亿次 AI 预测。Samsung 的 11 亿用户每秒发出 80,000 次请求；Pinterest 在 Amazon S3 上存放超过 1 EB 的数据。
Toyota 从本地数据湖迁移后，在 PB 级规模上汇集来自车载传感器、运营系统与数据仓库的数据；团队在需要时安全访问，从而具备快速创新的自主权与敏捷性——例如监测车辆健康并在影响客户之前解决问题。Philips 构建了安全且符合 HIPAA 的数字云平台，作为应用套件的基础，用于存储、解析、统一与抽取来自不同来源的客户数据洞察。

现代数据参考架构（Reference Architecture for Modern Data Architecture）

理解现代数据架构的优势，以及在数据湖与数据仓库中同时存储数据的价值之后，来看一套基于 AWS 分析服务的数据仓库工作负载参考架构。图 1-6 展示了如何利用 AWS 服务实现现代数据架构的各个环节：从采集/抽取多源数据到 S3 数据湖、到用 Redshift 摄取与处理数据、再到用 QuickSight 与 SageMaker 进行分析。

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

数据来源（Data Sourcing）

现代数据架构支持从多种来源摄取与分析数据。许多来源（如业务线应用、ERP、CRM）会以固定周期输出高度结构化的批量数据。除了内部结构化来源之外，你还会接收来自 Web 应用、移动设备、传感器、视频流与社交媒体等现代来源的数据；这些来源通常产生半结构化与非结构化数据，并且往往是连续流式的。

数据会以临时或持久方式存放在 Amazon S3 上的数据湖中，使用开放文件格式（如 Apache Parquet、Avro、CSV、ORC、JSON 等）。来自 S3 数据湖的同一份数据既可作为“单一事实来源”，也可被 Amazon Redshift、Amazon Athena、Amazon EMR、Amazon SageMaker 等分析服务复用。数据湖使你能在一个地方对大多数数据开展分析，而专用分析服务则为特定用例（数仓、实时看板、日志分析等）提供所需速度。

抽取、转换与加载（ETL）

ETL 层负责从多源抽取数据、按业务规则进行转换，并将其填充到存储层中经清洗与治理的区域。它能够通过多种协议连接内外部数据源，并以批处理或实时流的方式将数据送入数据仓库与数据湖。

为提供高度治理、统一且可信的数据，你可能在入库前对源数据进行预处理、校验与转换。对仓库数据与 schema 的变更应有严格的治理与验证，以在跨业务域提供可信的“单一事实来源”。

过去常见的架构模式是：把高频访问、需高性能的数据放入数据库或数仓（如 Redshift），把偶尔查询的冷数据存入数据湖。比如，金融机构可能出于合规要保留 10+ 年的历史交易，但分析只需要最近 2–3 年。现代架构提供灵活性：可将最近三年的数据置于本地高性能存储，把更久远的数据持久化到数据湖。

遵循这一模式，使用 RA3 节点类型或无服务器部署时，Redshift 具备内建分层存储模型：存储与计算分离，数据保存在 Redshift Managed Storage（RMS） 中，计算可独立于存储扩缩。Redshift 会将常用数据块“水化”到更靠近计算的位置，并替换较少使用的数据。采用该架构时，你仍然可以把历史数据保存在数据湖中，以便与其他分析服务协同运行分析，但无需（或极少需要）再从数仓卸载大量数据。

存储（Storage）

数据存储层负责提供持久、可扩展、具性价比的组件，用于存放与管理海量数据。数据仓库与数据湖原生集成，形成一体化且具成本效益的存储层，既支持非结构化与半结构化数据，也支持高度结构化与建模后的数据。存储层可按“可消费就绪”状态存放数据，包括原始（raw） 、可信/一致（trusted-conformed） 、**富化（enriched）与建模（modeled）**等层次。

数据仓库中的存储（Storage in the data warehouse）

数据仓库起源于对大体量数据的存取需求。早期基于 MPP 的架构通过在一组可扩展但昂贵且高性能的计算节点上分布处理来实现。

历史上，数据仓库存放一致（conformed）、高度可信的数据，采用星型、雪花、数据金库或反规范化等模式，数据通常来自高度结构化的来源，如事务系统、关系型数据库及其他结构化业务源。数据仓库通常以批量装载，并执行 OLAP 查询。

Amazon Redshift 是首个完全托管、基于 MPP 的云数据仓库，它支持传统数据仓库的全部功能，并逐步演进为具备弹性存储（减少所需计算节点数量）、可存放半结构化数据、可访问实时数据并执行预测分析的系统。图 1-7 展示了典型的数据仓库工作流。

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

数据湖中的存储（Storage in the data lake）

数据湖是组织数据的集中式存储库。它支持以结构化、半结构化与非结构化格式存储数据，并可扩展到 EB 级。通常，数据湖会根据数据的可消费就绪程度划分为落地（landing） 、原始（raw） 、可信（trusted）与治理/精选（curated）等分区。由于在摄取与存储前无需先定义模式，数据湖可加速摄取，减少在数据可被探索前的准备时间。数据湖支持用多样方法分析多样数据集，包括大数据处理与机器学习。与数据仓库的原生集成还能降低存储成本：你可以按需访问数据湖中的任意数据，只加载最有价值的部分。基于 AWS 的数据湖以 Amazon S3 为主存储平台，如图 1-8 所示。

图 1-8 数据湖的使用场景

分析（Analysis）

你可以使用交互式 SQL 查询编辑器、借助 Amazon QuickSight 的可视化仪表板，或利用 Amazon SageMaker 运行预测类机器学习模型，来分析存放在数据湖与数据仓库中的数据。

使用这些服务时，无需持续地搬移与转换数据；AWS 为核心用例提供原生且深度集成的服务，而非来自多厂商的“半集成”拼装。

事务型数据库、数据仓库与数据湖的比较

（Comparing transactional databases, data warehouses, and data lakes）

虽然事务数据库、数据仓库与数据湖都可能以电子化方式存放与访问并可用 SQL 查询，但三者在关键特性上差异明显：

事务型数据库（OLTP） ：底层表结构为单行级的快速插入与更新而设计，模型通常高度规范化，存储面向大量事务；为支撑特定行的高并发事务，采用行式存储（把一行数据物理上放在一起）。典型用例：在线购物、销售订单、股票交易、银行借贷记等。
数据仓库：面向分析来自事务系统与 LOB 应用的关系型数据，以及来自移动应用、IoT 与社交媒体的半结构化非关系数据。数据会被清洗、富化与转换，以形成可信的单一事实来源（SSOT） 。结构与模式针对大规模汇总或大批量处理优化，结果用于报表与分析。示例用例：年度零售/线上销售对比、客户购买偏好趋势分析、Top 10 高利润产品等。

表 1-1 数据仓库 vs. 事务型数据库

特性	数据仓库	事务型数据库
适用负载	大规模分析、报表、大数据	事务处理、运营报表
数据来源	来自多源的数据采集并（常）规范化	来自单一源（如事务系统）的原样采集
数据写入	预定批量写入	新数据到来即持续写入，最大化事务吞吐
数据规范化	反规范化（星型/雪花等）	高度规范化、相对静态的模式
数据存储	为列式存储下的简易访问与高速查询优化	为行式物理块上的高吞吐写入优化
数据访问	最小化 I/O、最大化数据吞吐	大量小型读操作

数据湖同样可存放来自 LOB 应用的关系数据与半结构化数据，且还能存放完全非结构化数据。其数据结构/模式在采集时不预先定义，可先存后编目，并按业务查询需求在其上构建目录与视图。

随着已构建数据仓库的组织认识到数据湖的价值，他们需要一套同时支持两类用例的平台，因而正把仓库演进为同时纳入数据湖并支持多样查询能力的体系。

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

特性	数据仓库	数据湖
数据类型	关系数据（事务系统、运营库）、以及通过流式摄取的 JSON、各类 LOB 应用数据	所有数据：结构化、半结构化、非结构化
模式（Schema）	常在实施前设计（写时定模），也可在分析时定义（读时定模）	主要为读时定模（schema-on-read）
价效比	使用本地/近端存储获得最快查询	依托低成本存储与算存分离，查询正持续加速
数据质量	高度治理与精选，充当“中心真相版本”	任意数据，可能未治理（原始数据）
用户	业务分析师、数据科学家、数据架构师、数据工程师	业务分析师（用精选数据）、数据科学家、数据开发者、数据工程师、数据架构师
分析类型	批量报表、BI 与可视化、机器学习	机器学习、探索式分析、数据发现、流式/运营分析、大数据、画像/剖析

数据网格与数据织体（Data Mesh and Data Fabric）

数据网格与数据织体是在分布式、复杂环境中实现现代数据架构的两种路径。二者共享一些共通原则，例如采用分布式架构、强调数据质量与治理。然而，它们的目标与数据管理方法不同：数据网格聚焦按域去中心化与自治；数据织体聚焦在不同来源与系统间的一体化与一致性。总体上，数据织体更像自上而下的技术方案；数据网格更像自下而上的方法，更关注团队与流程，而较少强调统一的架构强制。

数据网格（Data Mesh）

在数据网格架构中，数据围绕业务能力或领域（domain）进行组织，每个领域对自身的数据管理、质量与治理负责。数据被视为产品（data as a product） ，领域数据团队负责创建与维护可被其他团队消费的数据产品。数据网格的目标，是在复杂且快速变化的环境中，通过减少依赖、提升团队协作，来提高数据管理的敏捷性与可扩展性。

数据网格鼓励分布式团队独立拥有并设计其面向领域的解决方案（如图 1-9 所示：销售、市场、财务、研发等领域及其团队）。该架构要求每个团队通过自助式基础设施平台对外提供“数据即产品”（见图 1-9 最下层）。为保持全局的可互操作性，图中最上层显示由联邦治理团队负责监督。

图 1-9 数据网格架构

这种面向领域的数据所有权与架构方式，使生态系统能够按需扩展；“数据即产品”使跨多领域的数据易于发现；自助式基础设施平台通过抽象底层复杂度，使各领域团队能够生产与消费数据产品。联邦治理团队负责定义全局的标准化规则，以保障整个数据网格生态的互通性；更重要的是，在哪些需要全局统一与哪些应交由领域团队自主决定之间取得平衡。

在各团队可自由设计其方案的前提下，Amazon Redshift 的数据共享（data sharing）能力可提供搭建数据网格所需的数据基础设施平台。借助 Amazon DataZone，你可以在去中心化且受治理的模型下，将数据产品分享给消费方，从而构建数据网格架构。

数据织体（Data Fabric）

数据织体是一种强调一致性、质量与可达性的数据集成与编排方法，面向跨不同来源与系统的数据。在数据织体架构中，数据被组织为一个统一的虚拟层，无论其位置或格式如何，向用户提供单一视图。数据在通过织体的过程中，会通过自动化与人工流程的组合被转换、富化与对齐（harmonize） 。其目标是简化数据访问与分析，并让组织基于可信数据更快速、准确地做决策。

随数据汇聚而来的，是关于访问、发现、集成、安全、治理与血缘的一系列挑战；数据织体的解决方案即提供能力来应对这些挑战。

数据织体是以元数据驱动的，把各类数据管理工具连接起来以实现自助式数据消费。参考图 1-10，中部元素代表数据织体提供的工具；实际的数据源或孤岛（左侧）仍然分布式存在，但其管理被织体这层叠加层统一起来。统一的数据织体层为组织内的各类角色（上部：报表、分析、数据科学）提供一致体验，使其既能供数也能用数。各组件通常通过 API 以 JSON 交换数据。

通过引入 AI/ML 组件以辅助自动发现与血缘，数据织体可被视为一个持续学习、不断演进的实体。其挑战在于：如何促成统一管理的共识，尤其当各部门/团队分别拥有并维护其各自数据集时。

图 1-10 数据织体由多层数据管理能力构成（图片来源：Eckerson Group）

在 AWS 上，Amazon Redshift 与 AWS Lake Formation 的集成可提供便捷访问、安全与治理能力（第 8 章“数据安全与治理”将介绍在 Lake Formation 中进行访问控制的设置）。同时，可借助 Amazon SageMaker 在 AWS 上构建数据织体架构中的机器学习能力（第 6 章“Amazon Redshift 机器学习”将介绍 Redshift 与 SageMaker 的紧密集成）。

小结（Summary）

本章介绍了组织如何通过使用面向数据的 AWS 专用服务构建现代数据架构，从而实现数据驱动。现代数据战略将帮助你规划将数据工作负载迁移至云端的路线图，并说明了 Amazon Redshift 是现代数据架构的基础。

后续章节将探讨如何利用 Amazon Redshift 将你的数据工作负载迁移到云上、推进数据民主化，并为所有用户提供业务洞察。你还将学习如何借助 Amazon Redshift 实施诸如数据网格等现代架构，并利用其与其他 AWS 原生分析服务的深度集成。

Amazon Redshift 权威指南——面向数据的 AWS