Amazon Redshift 权威指南——数据模型搭建与数据导入

现在你已经搭建好 Amazon Redshift 数据仓库了，接下来就该考虑数据管理策略。

本章我们将讨论几种数据管理策略的选择，以及你是否应该采用“数据湖优先还是数据仓库优先”的路线。接着，我们会进入“定义你的数据模型”，并使用“学生信息学习分析数据集”演示如何建表，以及如何利用存放在 Amazon S3 上的该数据样本来“将批量数据装载到 Amazon Redshift”。不过在当今时代，获取洞察的速度是保持竞争优势的关键，我们也会展示如何“加载实时与准实时数据”。最后，我们将介绍如何“优化你的数据结构”。

数据湖优先 vs. 数据仓库优先（Data Lake First Versus Data Warehouse First Strategy）

在当今数字时代，组织持续地采集并生成海量数据，来源包括用户交互、传感器读数、社交媒体活动等。要想获得洞察并做出明智的业务决策，就必须有效管理这些数据。一个关键挑战是选择合适的数据管理策略。常见的两种策略是数据湖优先与数据仓库优先。当你规划云端数据管理（无论是迁移本地数仓，还是装载新数据）时，都应思考是走数据湖优先，还是数据仓库优先。

数据湖优先（Data Lake First Strategy）

数据湖优先策略会为所有原始数据（不论结构/格式）建立一个集中式存储库。典型做法是基于可扩展的存储平台（如 Amazon S3），以承载海量数据。数据以原始形态摄入数据湖，数据科学家、分析师及其他相关方通过各类数据处理与分析工具从中提取洞察。

此策略的主要优势是灵活与可扩展：可以轻松接入新数据源，数据湖也能扩展以应对数据增长；同时，保持未转换的原始数据更有利于保持数据完整性与沿袭（lineage） ，并可能获得更准确的洞察。

其主要劣势在于治理与管理难度：你需要在桶与分区层面妥善组织与维护文件以获得良好性能；此外，数据科学家与分析师可能要投入较多时间与资源去做数据准备，方能产出洞察。

数据仓库优先（Data Warehouse First Strategy）

数据仓库优先策略会建立一个面向查询与报表优化的集中式数据库。数据从各源抽取，按预定义模式转换后装载进数仓。随后，数据科学家、分析师等可以用 SQL 或其他查询语言提取洞察。若主要关注分析与 BI，并希望以这个中心数据存储向其他服务或用户共享数据，这一方式往往更受青睐。

其主要优势是更好的数据治理与管理：结构化数据更容易理解与发现，便于相关方获取洞察；业务分析师可以用ANSI SQL，学习成本低；数据在装载过程已完成清洗与转换，缩短分析前的数据准备时间与资源投入。

其主要劣势是：为接入新的数据源，在提供给业务决策者之前，往往需要投入更多时间与资源进行抽取与转换；同时，转换与清洗过程可能造成数据丢失或不准确，需要在 ETL 设计时加以权衡。近来的 zero-ETL 创新在源到目标的数据复制方面缓解了部分问题。

策略抉择（Deciding On a Strategy）

两种策略各有利弊，需结合组织的具体需求与目标选择。

• 数据湖优先适合需要处理大量结构化与非结构化数据、并且希望以更灵活、更可扩展的方式通过更广泛的工具来访问数据的组织。
• 数据仓库优先更适合希望对结构化与半结构化数据采用基于 SQL 的数据管理与治理的组织。

策略选择也取决于数据源以及你希望在表层复制，还是在应用层复制。当从源系统抽取数据时，通常会在物理层（表级）复制。但如果源是 Salesforce、SAP、ServiceNow 这类 SaaS 应用，你既可以在数据库表层复制，也可以在应用层复制。此类 SaaS 应用通常包含上千张表，因此它们往往内置抽取逻辑，将业务规则应用在底层表之上。例如 SAP 的 BW 抽取器会基于业务逻辑从多张源表抽取，在逻辑层输出数据。一个销售订单事务可能在 SAP 中分布在 50 张表里，但抽取器会融合这些表，输出一行去范式化后的销售数据，便于消费。

• 若你希望将数据集中存储以支持大数据处理、机器学习或分析等（面向 AWS 原生与非原生分析服务），构建数据湖更合适。
• 若负载纯为分析与 BI，则更宜采用数据仓库优先。

若需求明确为表级复制，你可以将原始数据引入数据湖，或直接摄入数据仓库（如 Amazon Redshift） ；如何选择要看业务与技术需求。在 AWS 云上，若你希望将 S3 数据湖中的原始数据共享给 EMR、Athena、SageMaker 等服务供业务用户与数据科学家使用，走数据湖优先更合理；它允许保留原始格式并在其上建立治理与共享，而不必再经由其他服务。但这意味着你需要在 Amazon S3 上维护原始文件与分区以达到最佳存储与性能；对这些文件的更新可以使用 Apache Hudi。

选型前还需评估团队技能结构与长期战略。Amazon Redshift 现已支持原生 Spark 集成，可在 Redshift 上运行 EMR 或 AWS Glue 代码；你可以用 Python/Scala 编写，Redshift 负责将其转换为原生 SQL并在数仓内执行。借助 Redshift ML，你能用 SQL 语法完成机器学习，而不必编写 Python 或 R。随着数据共享、Redshift ML、原生 Spark 集成、AWS Data Exchange（ADX） 等功能完善，“仅为了与其他服务共享数据而构建数据湖”的必要性可能进一步降低。

在数据仓库优先方式中，你将原始数据直接摄入 Redshift。这通常在表级完成，可用 AWS DMS 或你选择的数据集成工具；随后按 ELT 思路在数仓内读取原始数据进行转换与装载，供分析使用。若需要与其他 AWS 原生服务共享数据，可使用 Redshift 数据共享；若需与非原生服务共享，针对其他用例，可使用 UNLOAD 将数据从 Redshift 卸载到 S3。

小结：

• 数据湖优先：当你希望保留原始数据以满足已知与未知需求，从而前瞻性地支撑分析应用——这通常面向组织级决策，初期未必能立刻显性产生业务价值。数据湖只是数据存储库，需要额外的计算服务来产出价值。
• 数据仓库优先：将加工后的数据存入面向场景的存储，通常服务于特定领域/范围；非常适合大数据分析，因为结构清晰、易用、易懂。
  现实中，组织往往两者都需要。数据仓库已存在多年；数据湖因大数据与原始细粒度数据（结构化与非结构化）的需求而生，但面向业务用户的分析依然需要构建数据仓库。

定义你的数据模型（Defining Your Data Model）

启动 Amazon Redshift 时，会默认创建一个数据库。你可以在该默认库下创建数据库对象，也可以再建其他数据库来分门别类。如何组织数据库对象，取决于应用归属、合规与安全、运维便利以及跨库查询等多种因素。

本节将介绍 Redshift 数仓的组织方式，帮助你明确应在何处创建数据库对象；同时也会覆盖常见的数据建模策略。

数据库模式、用户与组（Database Schemas, Users, and Groups）

在 Redshift 中，数据库是对象层级的最高级别；一个数仓内可以有多个数据库。每个数据库内可包含一个或多个 schema；在每个 schema 中，你创建表来以结构化方式存储数据，以及其他对象（视图、存储过程、函数等）。默认情况下，一个数据库包含名为 public 的单一 schema。你可以用 schema 将数据库对象按照一个公共名称进行分组管理。

Redshift 支持跨 schema与跨数据库查询；你可以将与某个应用相关的对象放在不同的 schema，或直接放在不同的数据库。在组织方式上，需要考虑查询是否跨数据库：

• 跨 schema查询发生在同一数据库内，没有限制；
• 跨数据库查询存在一些限制：出于性能考虑，不支持结果缓存，因此重复查询都要真正访问数据库；同时，并发扩展（Concurrency Scaling）也不支持跨数据库查询。在决定是否将对象放到不同数据库前，要评估需要跨库的查询占比。

另一个因素是你的工作负载/业务域所需的schema 或表的数量。如果对象数量有可能超过配额/上限，你就可能需要把数据放在不同的数据库中。

跨数据库查询时，访问当前库外的表使用两点式记法：database.schema.table。你也可以创建一个external schema，从而使用一点式（externalschema.table）访问。关于跨数据库查询的更多细节，可参考“查询跨数据库数据”。

如果是多租户架构，可参考相关博文来组织数据库对象。

星型、去范式化与范式化（Star Schema, Denormalized, Normalized）

传统数仓多采用星型模型（star schema） ：一个或多个中心事实表存放待分析的度量，周围的维表提供业务上下文。其布局形似“星形”，故名。星型维度可以去范式化为单表（包含维度的所有属性列），也可以进一步范式化拆分到多张表，使得模型图呈现“雪花状”，即雪花模型（snowflake schema） （见图 3-1）。

图 3-1 星型模型对象与雪花模型对象对比

星型模型在维表中保留冗余；雪花模型则避免冗余。但雪花模型会带来更复杂的查询，并可能降低性能，因为分析需要连接更多表。在 Amazon Redshift 上，通常推荐星型或去范式化的数据模型。

另一方面，雪花模型的存储需求更低（无冗余），同时数据一致性风险更小。

随着存储介质的进步与 TB 单价下降，相较于存储成本，查询简洁性与执行效率在现代数仓中往往更优先。因此，星型模型成为对超大数据集做分析时的热门架构。

下面用一个简单数据模型说明范式化与去范式星型的差异。销售订单在关系型数据库中一般按范式化模型存储。如图 3-2，SalesHeader 与 SalesLineItem 分别存在两张表（一对多关系），并伴随主数据表 Customer、Product、Currency。

图 3-2 源数据库中的范式化（OLTP）模式数据模型

在图 3-3 的星型模型中，SalesHeader 与 SalesLineItem 被合并为一张 SalesFact 事实表，且数据在订单层级进行了聚合。

图 3-3 数据仓库中的星型数据模型

学生信息学习分析数据集（Student Information Learning Analytics Dataset）

在上一章中，你已经学习了如何创建 Amazon Redshift 无服务器数据仓库，并用查询编辑器查询示例数据。现在我们来看看，如何创建新的数据模型、将数据摄入 Amazon Redshift，并使用原生查询编辑器进行分析。

为此，我们选用了一个学生学习分析数据集，帮助你理解如何构建星型模式数据模型，并将数据摄入 Amazon Redshift，用于分析、预测并改进学生学习成效。¹

Open University Learning Analytics Dataset（OULAD） 包含关于课程、学生，以及他们在 7 门选定课程（称为 modules）中与在线虚拟学习环境（VLE）的交互数据。该数据集假设每年有两个学期，课程分别在每年 2 月与10 月开始。课程学期通过 courses 表中的 code_presentation 列标识，课程代码的后缀分别使用字母 “B” 与 “J” ，并以前缀四位年份标识。数据集由通过唯一标识符互相关联的多张表组成，所有表均以 CSV 格式存储。

数据模型由 7 张表构成，涵盖与学生、模块与活动相关的数据，实体关系如图 3-4 所示。为便于本书演示，我们对该模型做了修改——可以存储多所学校的数据，而不止一所。你可以使用示例 3-1 中的 DDL 脚本创建 schema 与数据库表。

该样本的匿名化数据集可通过 OULAD 的链接获取（用于进一步了解数据集），你可以下载后存入任意你选择的 S3 存储桶。我们将其存放在 arn:aws:s3:::openlearn-redshift，你也可以使用这个 S3 位置，结合 COPY 命令将数据摄入 Amazon Redshift。图 3-5 展示了该 S3 数据集。

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

你可以像图 3-5 那样查看 S3 数据集，并将其作为数据源，通过 COPY 命令把示例数据集摄入 Amazon Redshift。类似地，你也可以寻找其他公开数据集，为其创建数据模型，以进一步探索 Amazon Redshift 的功能。

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

为学生信息学习分析数据集创建数据模型（Create Data Models for Student Information Learning Analytics Dataset）

接下来，我们创建数据库表，以便将数据加载到 Amazon Redshift。连接到你的 Amazon Redshift 数据仓库，使用以下脚本为示例学生信息数据集创建 schema 与表（见示例 3-1）。

示例 3-1 加载学生信息数据（Load student information data）

/* 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 中建表时，针对每张表有多种可选的分布（distribution） 、排序（sorting）与编码（encoding）设置。在上述示例里，我们未显式指定这些选项，而是使用了默认的 AUTO。在大多数情况下，使用 AUTO 意味着 Redshift 服务会根据实际使用情况进行监控，并自动为你调优这些表。

将批量数据加载到 Amazon Redshift（Load Batch Data into Amazon Redshift）

现在你已经在 Amazon S3 中准备好了数据文件，也创建了数据表，就可以把数据加载进 Amazon Redshift 了。加载方式有多种：

• 使用 COPY 命令
• 使用 AWS Glue 或第三方 ETL 工具
• 使用 SQL 命令手动加载
• 使用 Query Editor V2

使用 COPY 命令（Using the COPY Command）

COPY 命令是将数据加载到 Amazon Redshift 最简单、最高效的方式。它支持直接从 Amazon S3、Amazon DynamoDB、Amazon EMR 加载数据，也可从外部数据源（如 CSV、JSON 文件）加载。COPY 会自动并行化装载过程，能够快速、轻松地处理海量数据。该命令可读取多个数据文件，并可根据目标数仓的 slice 数量拆分文件以把工作负载分配给所有节点与切片；它还会对行进行排序，并把数据分布到各切片上。最佳实践：将文件以压缩形式存入 S3，以加快读取速度。请注意装载压缩文件与非压缩文件时的差异：

• 若把压缩数据作为单个大文件加载，Redshift 会以串行方式装载。若将大文件拆成多个小文件，COPY 会并行装载多个文件，从而提高并行度，把工作负载分散到集群各节点。建议把数据拆成大小大致相等的小文件，压缩后 1 MB–1 GB。为了获得最佳并行度，经验法则是：文件数量设为数仓 slice 数的倍数，并使压缩后文件大小在 1–125 MB。例如：向一套两节点 ra3.4xlarge（每节点 4 slices，共 8 slices）的集群加载一个 1 GB 文件，应将其拆成 8 个 125 MB 的文件以高效加载。
• 若从单个大型压缩文件加载全部数据，Redshift 被迫串行加载，速度更慢。
• 相反地，从大型非压缩的定界文本加载时，Redshift 会自动利用多个 slice 并行处理：按范围拆分数据并分派给各 slice，从而获得较快的装载性能。
• 对于压缩文件，良好做法同样是拆成大小大致相等的文件（压缩后 1 MB–1 GB；理想 1–125 MB）。

为学生学习分析数据集进行数据摄入（Ingest Data for the Student Learning Analytics Dataset）

要摄入本书的示例学生学习分析数据集，我们采用推荐的 COPY 命令，并指向存放样例数据的 Amazon S3 存储桶。命令列表如下（见示例 3-2），你可以将其中的 S3 位置与区域替换为你的环境值。

示例 3-2 创建 schema 与表并加载学生信息数据

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 角色。命令执行时，Redshift 会使用设为默认并与该数仓关联的 IAM 角色。你可以运行 DEFAULT_IAM_ROLE 命令查看当前附加到数仓的默认 IAM 角色。

Redshift 会按排序键顺序对每批装载的记录进行排序；但它不会在每次 COPY 执行时对已存记录重新排序。若每批新增数据按表中现有行的顺序追加，你的数据会保持良好的排序有序性，就无需 VACUUM。同样，你也不必在每批装载前预排序行，因为 COPY 在装载时会对每批入库数据进行排序。

构建星型模型（Building a Star Schema）

你刚刚把数据以规范化的学生信息数据模型摄入，用于存储学生的选课、成绩、结果、注册等事务性记录。但业务需求是让校方管理与教师能够衡量课程学习成效。如上一章所述，包含事实表与维表的星型模型是数仓推荐的数据模型。course_registration、course_outcome、course_schedule 表包含了衡量成效所需的数据，因而可作为事实表的基础。

将数据转换成去范式化事实表的方法有很多：

• ETL：读取源数据，在外部应用中完成转换，再装载结果；
• ELT：在数仓中对刚装载的数据就地转换，利用 Redshift 的计算能力。

第 4 章“数据转换策略”会更详细讨论如何抉择。为完成本示例，我们用ELT 的方式处理已加载的数据。

示例 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;

若要将**学习管理系统（LMS）**上的学生参与度与学习结果关联起来，你可以把 student_lms 与 student_assessment 连接以获取洞察。下面的示例 3-6 创建了物化视图 mv_student_lmsactivites_and_score。

示例 3-6 学生活动、总分与均分（Student activities 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 点击次数 vs. 结果

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 各模块的结果占比（Percentage results by MODULE）

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 持续文件摄入（Continuous File Ingestion from Amazon S3）

将落入 S3 存储桶的新文件持续摄入 Redshift 表，能简化你的转换流水线。设置 COPY JOB 后，Redshift 会侦测 COPY 命令指定路径中新增加的文件，并自动触发 COPY；系统会跟踪已加载的文件，并决定每次 COPY 批量处理的文件数。利用该功能，你无需额外的外部数据摄入管道就可自动化摄入流程。更多细节参见在线文档。

COPY 作业执行详情（见示例 3-10）存放在系统表中，便于你监控装载、回看历史执行与装载细节。系统表 sys_copy_job 为每个当前定义的 COPY 作业保存一行记录。

示例 3-10 创建 COPY 作业

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

如示例 3-11 所示，要查看某个 COPY 作业加载过的文件列表，可以运行如下查询并替换 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 进行转换（Using AWS Glue for Transformations）

AWS Glue 是原生的无服务器数据集成服务，常用于用 Python/Scala 在数据处理引擎上进行转换。它让你更容易发现、准备、移动与集成来自多源的数据，用于分析、ML 与应用开发。Glue 提供多种引擎：Glue for Apache Spark、Glue for Ray、Glue for Python Shell。你可以根据工作负载特点与开发/分析人员偏好选择合适的引擎。Redshift 支持 Spark 集成，能够将 Python/Scala 的转换逻辑下推到 Redshift 层，通过把 Spark 代码翻译成 SQL 并在数仓内执行，无需把数据移出数仓。

自 AWS Glue V4 起，提供了带新 JDBC 驱动的 Amazon Redshift Spark 连接器，可用于构建读写 Redshift 的 Spark 应用，把它们纳入你的数据摄入与转换管道。借助新连接器与驱动，应用可保持性能与事务一致性。

使用 Glue（见图 3-7），你可以爬取 S3 数据源以创建目录、应用转换，并把数据摄入 Redshift 数仓。

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

Redshift 对 Apache Spark 的集成让你能在 Glue 中更轻松地构建与运行面向 Redshift 的 Spark 应用。该集成提供了 pushdown 能力（如 sort、aggregate、limit、join、标量函数等），只把相关数据从 Redshift 移到 AWS 中的 Spark 应用，从而获得更好的性能。更多信息可参见相关博文。第 4 章将介绍如何用 AWS Glue Studio 以可视化界面创建 ETL 转换。

使用 SQL 命令手动加载（Manual Loading Using SQL Commands）

用 SQL 命令手动将数据加载进 Redshift 是一种可行方案，但不推荐用于大数据量，因为耗时且易错。不过，它在小数据集或测试场景中很有用。若不能使用 COPY，你可以用 INSERT 与 CREATE TABLE 等命令加载数据。建议使用多行插入或批量插入，而不要逐条 INSERT。

多行插入通过批量提交多行来提升性能。下面示例 3-12 使用单条 INSERT 向 5 列表中插入两行（仅为演示多行插入的语法）：

示例 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 as statement）

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);

使用 Query Editor V2（Using the Query Editor V2）

对于简单且快速的数据加载，你可以使用 Query Editor V2 的加载数据功能。你既可以直接从本地桌面上传文件，也可以先将数据文件上传至 S3，然后在 Query Editor V2 中选择加载数据（见图 3-8）。

Query Editor V2 会在后台使用 COPY 命令从你指定的 S3 位置装载数据。向导生成并使用的 COPY 命令支持从 S3 装载所需的全部参数。你可以在高级设置中的“数据转换参数（Data conversion parameters） ”配置：接受无效字符、设定日期/时间格式、截断数据、处理空行、缺失列、尾随空格等；还可设置压缩分析所需的采样行数、自动更新压缩编码、错误处理与统计信息更新等选项。

图 3-8 将 CSV 上传至 Amazon S3 并使用 Query Editor V2 装载

当你用 COPY 向空表摄入数据时，Redshift 能分析数据并为每列优化压缩类型。COPY 命令中的 COMPUPDATE 参数用于控制压缩策略。

加载实时与准实时数据（Load Real-Time and Near Real-Time Data）

实时（real-time）数据指的是一经产生就立刻被处理与分析的数据。这类数据对金融交易、交通运输、物流等对时效极为敏感的应用至关重要。准实时（near real-time）数据与实时类似，但其处理与分析会有轻微延迟，通常在几分钟以内。

将实时与准实时数据加载到数据仓库或 BI 系统是一项具有挑战性的任务，需要高效的数据采集（ingestion） 、处理与存储能力。整个过程通常包括：数据抽取、数据转换与数据装载。

• 数据抽取：从各类来源获取数据，如传感器、日志文件、流式平台。
• 数据转换：在装载到数仓/BI 系统前对数据进行清洗、校验、规范化。
• 数据装载：将数据导入目标系统，并供分析与报表使用。

加载实时与准实时数据的常见方式包括：批量装载（batch） 、增量装载（incremental）与流处理（stream processing） 。

• 批量装载：按固定时间间隔将大块数据装入。
• 增量装载：只加载新增或变更的数据。
• 流处理：数据持续生成即持续处理与分析。

为应对实时/准实时数据在规模、速度与多样性上的挑战，业界广泛采用Apache Kafka、Apache Storm、Apache Spark、Apache Flink 等大数据技术。

使用 AWS Database Migration Service 的准实时复制（Near Real-Time Replication Using AWS DMS）

AWS DMS 是全托管的数据库迁移服务，可在多种主流商业与开源数据库之间迁移数据（如 Oracle、MySQL、MariaDB、PostgreSQL、SQL Server 等），其中一个常见场景是迁移到 Amazon Redshift。

迁移前请充分规划与准备：明确源与目标数据库、数据规模以及特定需求或约束，并在非生产环境中进行测试验证。

步骤概览：

1. 创建复制实例（replication instance） ：由 DMS 负责连接源与目标并执行数据迁移。

2. 创建迁移任务（migration task） ：定义源/目标、迁移对象与具体设置。

3. 任务类型可选：

   • 全量装载（full load） ：复制源库全部数据；
   • 变更数据捕获（CDC） ：只复制自上次迁移以来的变更。

4. 启动迁移并通过 DMS 控制台或 AWS CLI 监控进度。

5. 迁移完成后，执行必要的后置步骤（建索引、加载至附加表等），并校验目标库数据与行为。

DMS 为迁移到 Redshift 提供了简单可靠的路径。按本章步骤规划、准备与执行，你可以快速、安全地将数据迁移至新的数据仓库。更多细节见“将 Amazon Redshift 作为目标的数据仓库”的官方文档。

Amazon Aurora 与 Amazon Redshift 的 Zero-ETL 集成（Amazon Aurora Zero-ETL Integration with Amazon Redshift）

Zero-ETL 集成提供一种无需构建复杂 ETL 作业即可用于分析的架构范式。通过从 Amazon Aurora 到 Amazon Redshift 的 Zero-ETL，你可以在几秒内将写入 Aurora 的事务数据在 Redshift 中近实时可用，减少抽取与装载管道的构建与维护。

该集成还支持在同一或不同账户中，将多个 Aurora 集群的数据汇入同一个（新建或既有）Redshift 数仓，从而跨应用/分区进行洞察。借助这种近实时访问，你可结合 Redshift 的内置 ML、物化视图、数据共享、跨数据存储联合访问等能力，对事务与其他数据进行分析，缩短洞察时延并降低成本（分析前无需预加载与转换），同时对事务系统的影响更小。

启用步骤概述：

1. 前置检查：Aurora 与 Redshift 均需满足最新版本/参数要求（Aurora 开启日志等），详见在线文档。

2. 权限：确保用户具备 redshift:CreateInboundIntegration。

   • 在 Redshift 控制台的目标数仓资源策略里，使用“Add authorized integration sources”配置 Aurora 数据库的 ARN（见图 3-9）。

图 3-9 Edit authorized integration sources

1. 创建 Zero-ETL 集成：需要 rds:CreateIntegration、rds:DescribeIntegration（删除时还需 rds:DeleteIntegration）。

   • 在 RDS 控制台选择“Zero-ETL integrations”→“Create zero-ETL integration”（见图 3-10）。
   • 同账号场景下，从下拉列表选择 Aurora 源与 Redshift 目标并提交。
   • 在 RDS 控制台查看状态，从 Creating 变为 Active 即就绪。

图 3-10 Create zero-ETL integration

1. 查询数据：在 Redshift 执行：

   SELECT integration_id FROM svv_integration;
   

   然后创建本地数据库引用该 integration：

   CREATE DATABASE <local_db_name> FROM INTEGRATION integration_id;
   

   之后即可浏览并查询从 Aurora 近实时同步过来的对象。源端每个 Aurora 数据库/模式会在目标 Redshift 数据库中以不同 schema 呈现。你可以进一步通过物化视图、脚本或存储过程进行处理，并用 Redshift 调度器或外部编排工具定时运行。

2. 跨账户：若 Aurora 与 Redshift 分属不同账户，还需配置授权主体与跨账户访问等，详见官方文档。

使用 Amazon AppFlow（Using Amazon AppFlow）

许多组织使用 SaaS 应用支撑业务（如 SAP/Infor 的 ERP、Salesforce/Google Analytics/Facebook Ads/ServiceNow 等特定功能系统）。为产出统一的业务洞察，常需合并多套 SaaS 的数据（如 Salesforce 线索机会 + SAP 实际销售）。

Amazon AppFlow 是全托管的集成服务，可在SaaS 应用与 AWS 服务（如 S3 与 Redshift）之间安全传输数据，只需几次点击即可完成。AppFlow 支持约 50 个连接器，可双向搬运数据到 S3/Redshift，并能通过过滤与校验做转换/富化。还可编写自定义连接器，从任意 API 源流式写入 Redshift。要把任意源应用的数据传到 Redshift，只需创建一个 Flow，将 Redshift 设为目标。详见对接步骤的官方文档。

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

实施要点：

1. 规划与准备：明确来源/目标应用与服务、传输的数据范围与约束；先在非生产环境测试。
2. 创建 Flow：指定源与目标，选择要传输的数据。
3. 配置调度与源/目标特定设置（传输频率与选项）。
4. 创建后，AppFlow 会生成所需的连接器与触发器以搬运数据。
5. 运行与监控：Flow 创建后会自动开始传输，可在控制台或 CLI 监控。
6. 落地到 Redshift 后即可用 SQL 查询分析，并用现有 BI 工具制作报表与可视化。

AppFlow 让向 Redshift 的数据摄入简单易行，可自动化多应用间的数据流，提高效率。关于使用 AppFlow 从 Salesforce 拉取数据到 Redshift 的实际案例，可参考相应博文。

流式摄入（Streaming Ingestion）

流式摄入指以实时或准实时的方式持续向数据仓库/BI 系统加载数据，从而实现实时分析与报表，对金融、交通、物流等场景尤为关键。典型实现是使用 Apache Kafka 或 Amazon Kinesis 收集与管理数据流，再将其处理后装载到目标系统。

优势：处理高速度/高吞吐数据，进行实时分析/报表，并实时检测/响应事件。
挑战：需要高效的数据处理与存储能力、健壮的集成与管理工具以及相应的专门技能。

Redshift 的流式摄入通常适用于持续产生且需在较短延迟内处理的数据：从 IoT、系统遥测、公用事业用量、设备地理位置等，到多种实时业务。

典型用例包括：

• 实时设备监控与告警：例如车队传感器上报速度、温度、油耗等，需实时识别离群并告警。
• 实时广告投放/内容风控：聚合多平台社交数据以进行广告竞价或不良信息防控。
• 游戏体验优化：围绕转化、留存、体验进行实时洞察与优化。
• 实时零售分析（POS 流） ：聚合全球 POS 交易流进行实时分析与可视化。

在 Redshift 中的两种路径：

1. Kinesis Firehose / Kinesis Data Streams（间接 S3 分段 + COPY）
   传统做法：由 Firehose 将流数据按批量/缓冲落地到 S3，再触发 COPY 装载到 Redshift。此前延迟通常以分钟计，且常需要额外管道。现在也可以直接从数据流摄入。
2. 与 Kinesis Data Streams 或 Amazon MSK 的原生集成（Native Integration）
   原生对接 Kinesis 或 Amazon MSK，Redshift 以每秒数百 MB的速率进行摄入，并无需经 S3 中转。可连接多个流并直接拉取到 Redshift；既可定义模式，也可将半结构化数据以 SUPER 类型写入；并可用 SQL 构建与管理 ELT 管道。

原生流式摄入允许直接对接 Kinesis，减少延迟与复杂度。你可以用 SQL 访问流数据，并在流之上直接创建物化视图来简化管道，视图中还可内嵌 SQL 转换逻辑。定义好物化视图后即可刷新以获取最新流数据，从而用现有 BI/分析工具做实时分析。

工作原理（简述） ：Redshift 作为流消费者，以物化视图作为流数据的落地区。当执行刷新时，计算节点把各个分片（shard）分配给切片（slice） ，各 slice 读取对应分片直至与流达到一致性。首次刷新从流的 TRIM_HORIZON（Kinesis）开始；后续刷新从前一次的 SEQUENCE_NUMBER 继续前进（见图 3-12）。

图 3-12 流式摄入工作流

入门步骤（Steps to get started with streaming ingestion）

1. 创建 Kinesis Data Stream 作为数据源。可用 Kinesis Streams Data Generator 生成测试数据（详见相关博文）。

2. 在 Redshift 中定义外部 schema 指向 Kinesis 资源：

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

3. 创建 IAM 角色，其信任策略允许 Redshift assume 该角色，并授予访问流的权限（示例 3-15）。

示例 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": "*"
    }
  ]
}

4. 创建物化视图从流中选择数据；查询该视图即可获得某一时点的流快照：

    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;

5. 初次刷新以加载数据：

    REFRESH MATERIALIZED VIEW my_view;

6. 查询：

    SELECT * FROM my_view;

你可以将记录以**SUPER** 半结构化格式落地，或定义模式将其转换为 Redshift 数据类型。\
更详细的 Kinesis → Redshift 流式摄入步骤，参见“Getting Started with Streaming Ingestion from Amazon Kinesis Data Streams”。

重要考量与最佳实践（Important considerations and best practices）

• 自动刷新的物化视图会被视为普通用户工作负载；自动刷新会在数据到达时加载数据。
• 创建视图时可显式指定 AUTO REFRESH（默认是手动）。对已存在视图可用 ALTER MATERIALIZED VIEW 开启。
• 对于 Redshift Serverless，与预置集群的配置步骤相同；需按需配置 RPU 以承载自动刷新与其它工作负载。
• 配置流式摄入时，若 MSK 启用 rack awareness，Redshift 会尝试连接同可用区（AZ）的 MSK broker；若所有 MSK broker 都与 Redshift 不在同一 AZ，可能产生跨 AZ 流量成本。至少保证一个 broker 与数仓在同一 AZ。
• 物化视图的首次刷新从 Kinesis 的 TRIM_HORIZON 或 MSK 主题 offset 0 开始。
• 仅支持可自 VARBYTE 转换的数据格式（详见 VARBYTE 类型与操作符）。
• 可以把同一条流落地到多个物化视图（例如按不同运动项目分表），但这会增加带宽/吞吐/成本压力并可能影响其他工作负载。建议每条流先落地到单个物化视图，再下游分发。定价参见 Kinesis Data Streams Pricing 与 Amazon MSK Pricing。

优化你的数据结构（Optimize Your Data Structures）

传统上，数据库多建立在 SMP（对称多处理） 架构之上：多颗 CPU 访问共享内存与共享磁盘。这种紧耦合的多处理系统难以线性扩展，以应对数据增长并满足查询吞吐需求。

MPP（大规模并行处理） 架构克服了这些挑战。常见两类：

• 共享磁盘（Shared-disk） ：CPU 与内存并行处理，但磁盘共享。
• 共享无（Shared-nothing） ：CPU、内存与磁盘全部并行处理。

正如本书前文所述，Amazon Redshift 采用 MPP 的 shared-nothing 架构：每个节点用自己挂载的内存与 CPU 处理本地数据。由于不存在“单一执行器瓶颈”，此架构可通过增删节点获得近线性扩展。同一对象/表的数据在各个节点上分布式或复制式存放，因此分布策略对查询性能至关重要。加州大学伯克利分校的 Michael Stonebraker 在论文 The Case for Shared Nothing 中对此有深入论述。

创建数据库对象时，一些关键的表设计决策会显著影响整体查询性能，并且也会影响存储需求，进而间接影响性能。核心目标是减少 I/O 次数并最小化执行查询所需的内存。

Amazon Redshift 通过“自动表优化（ATO）与自治能力”自动完成许多决策，但在需要精细调优时，你也可以自行设置 Distribution Style（分布方式） 、Sort Key（排序键）与Compression Encoding（压缩编码） 。

自动表优化与自治（Automatic Table Optimization and Autonomics）

当你以 AUTO 选项创建表时，Redshift 会通过 ATO 自动选择分布方式、排序键与编码。因此，推荐使用：

• DISTSTYLE AUTO
• SORTKEY AUTO
• ENCODE AUTO

在使用 AUTO 选项创建表时，Redshift 会基于主键、数据类型等，为首次查询提供尽可能好的初始键设计。随后，Redshift 会根据数据量与查询使用模式，演进分布策略与排序键以持续优化性能，并对表执行维护（减少碎片、更新统计信息）。第 5 章将进一步讨论 ATO。

分布方式（Distribution Style）

作为基于计算节点的 MPP 数仓，数据如何分布决定了是否能最优利用资源。执行查询时，优化器可能需要重分布行到其他计算节点以完成 Join。选择分布方式的目标是：把需要连接的数据预先放在一起，从而减少重分布的代价。共有四种分布策略：AUTO、EVEN、ALL、KEY（见图 3-13）。

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

AUTO 分布

如前所述，AUTO 让 Redshift 用其内建 AI/ML 能力，依据数据量与查询模式自动做出最佳分布选择。这是多数用户的首选，尤其适合不关注底层架构细节、但需要快速获得洞察的场景。

EVEN 分布

数据以轮询（round-robin）方式均匀写入到每个切片，使各切片/节点的数据量极少倾斜。适合大型事实表（通常不会与维表频繁 Join），以及物化视图（Join 已在生成阶段完成，查询多为过滤）。

ALL 分布

在每个计算节点的第一个切片存放整表副本。适合维表，以便与事实表 Join 时无需跨节点搬移数据，以增加存储换取更快查询。

KEY 分布

基于指定列的 hash 值分布：相同 hash 的行被放到同一切片。当两张表在相同的分布键上 Join 时适用（事实对事实、事实对维、暂存对目标等）。

KEY 分布支持同位连接（co-located join） ：事实表和对应维表的行总在同一切片上。为减少切片间倾斜，应选择高基数列做分布键。注意 Redshift 每表仅能设定一个分布键列，若查询经常在多个列上联合 Join，可在装载流程中拼接多个列生成新列作为分布键。

三种分布策略的核心都是减少查询时的数据移动，让每个切片并行处理，最大化吞吐。

示例建议（销售数仓场景）：

• fact_sales（数十亿行）与经常 Join 的 dim_customer（千万级）→ KEY 分布于 customer_key（不选 calendar_key 或 product_key）。
• 其他维表 → ALL 分布。
• 预聚合的物化视图 sales_annual_mv / sales_qtrly_mv / sales_monthly_mv → EVEN 分布。

若源系统是复合主外键导致多列 Join，考虑在表中新增拼接列作分布键。

排序键（Sort Key）

除了跨节点如何分布，另一关键是磁盘上物理排序。Redshift 没有索引，但排序键 + 区域映射（zone maps）提供了近似的效果。数据按排序键顺序写盘，优化器据此选择执行计划。若查询常以时间范围过滤，排序键能让查询跳过整块数据，显著减少 I/O。作为过滤谓词的列通常是排序键的良好候选。

Zone Map 为每个表每列的每个 1MB 块记录最小/最大值。若该列是排序键，区间不重叠，进一步减少 I/O：引擎仅扫描可能命中的块。参见 CREATE TABLE 的表属性设置排序键。

图 3-14 Zone maps

例如对 course_outcomes_fact 的查询（按某天过滤）：

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

图 3-15 展示：

• 未排序表：根据 zone map 的 MIN/MAX，可跳过 1 块，仍需扫 4 块中的 3 块；
• 已排序表：仅需扫 1 块。

图 3-15 排序键与 zone maps

我们建议使用 SORTKEY AUTO，让 ATO 基于实际查询模式选择排序键，从而快速获得良好性能、降低手工调优成本。

若需自行选择排序键，可用系统查询识别常用谓词列。建议：

• 排序键不超过 5 列；
• 排序键的首列不使用压缩，便于快速过滤、减少解压开销；
• 复合排序键在使用前导列过滤时更有效；若另一个前导列同样常用，可建立物化视图（MV） ，依赖自动查询改写让优化器选择合适的 MV。
• 若频繁按范围或等值过滤某列，将其设为排序键。分析场景常按日期/时间检索，使用日期/时间作为前导排序列是好实践。
• 若两表常 Join 且很少按其过滤，可将Join 列同时设为排序键与分布键，使优化器选择**排序合并连接（sort-merge join）**并跳过排序阶段。

压缩编码（Compression Encoding）

Redshift 对列进行列级压缩（编码） ，相较原始数据可达3–4 倍压缩，同时减少 I/O。

管理编码的最简方式是：在 CREATE TABLE 中使用 ENCODING AUTO。启用后，编码会依据列类型与加载数据的启发式特征自动确定。

另一种方式是在空表首次 COPY 时让 Redshift 自动选择压缩类型：

• COMPUPDATE PRESET：按数据类型决定（快，多数场景表现良好）；
• COMPUPDATE ON：采样数据决定；
• COMPUPDATE OFF：不改动现有编码。

若频繁重复装载同一表，无需每次都分析压缩。对性能满意时，用 PRESET 可保持表属性稳定。

当数据画像变化明显时，建议复核当前编码是否最优，可使用 ANALYZE COMPRESSION（示例 3-16）。可对整表或指定列执行。

示例 3-16 ANALYZE COMPRESSION 命令

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

最佳实践：

• 若不使用 AUTO，请为不同数据类型选择合适编码：如RLE 适合高重复度列，DELTA 适合行间相似度高的列。
• 使用 COPY 装载，让系统自动应用编码参数。
• 定期 VACUUM，通过减少碎片提高压缩效果。
• 监控表大小与磁盘占用，寻找进一步压缩空间。
• 小型维表通常无需编码：每列 1MB 块可容纳大量数据，此时压缩对 I/O 收益有限。
• 对高频访问列启用压缩收益更大。

小结（Summary）

本章讨论了 Data Lake First 与 Data Warehouse First 的关键差异与适用场景，并基于样例数据模型介绍了多种转换工具与策略。

下一章将更深入地讲解 库内转换（ELT） 与 外部转换（ETL） 在 Redshift 中的实现，以及如何在数据未加载入数仓时对其进行查询与转换，并讨论数据装载的编排策略。