migrating-to-amazon-redshift

迁移到 Amazon Redshift

此技能是什么

此技能提供的是 AI 指导，而非执行框架。它完全由 Markdown 知识（规则、映射、模式、最佳实践）组成——不包含可执行代码。所有执行工作——转换、发现／迁移／验证运行器、依赖项和基础设施——都由你（AI）根据这些知识在运行时生成，并针对客户的环境进行定制。

原则：知识优于随附代码 → 减少偏差，无需客户运行或依赖任何内容，首次执行即可获得可靠结果。 不要查找 pyproject、tools 包、orchestrator 引擎或随附脚本——按设计，这些都不存在；执行内容由你生成。

运行时：此技能可在有或没有 AWS MCP 服务的情况下使用——步骤指南采用 AWS CLI 语法。建议搭配 AWS MCP 服务使用，以便在沙盒中执行并记录审计日志；若不使用，AI 会在主机 Shell 中运行生成的脚本（假定有 Bash、Python 3、AWS CLI 和凭证）。不要假定 MCP 专用工具可用。

源系统路由

此技能将受支持的源数据仓库迁移到 Amazon Redshift。首先识别源系统，然后加载该源系统在 references/<source>/ 下的知识：

• Teradata (Vantage) → references/teradata/ — 已支持（包括以下所有参考资料）。
• 其他源系统（例如 Snowflake、Oracle）——暂不支持；准备就绪后，会为每个源系统单独添加一组 references/<source>/ 资料。

工作流与源系统无关（发现 → 转换 → 迁移 → 验证 → 性能 → 报告）；只有转换知识与源系统相关。以下内容全部适用于 Teradata。

适用场景

• 将 Teradata 系统（Vantage）迁移到 Amazon Redshift。
• 将 Teradata DDL、SQL、存储过程、宏或 BTEQ 转换为 Redshift/RSQL。
• 评估 Teradata → Redshift 迁移的复杂度／工作量。

操作原则

• 发现阶段对源系统严格只读（仅 SELECT）。 绝不更改生产状态：不执行 DDL/DML，也绝不启用日志记录（BEGIN/REPLACE QUERY LOGGING）。如果 DBQL 为空，将其标记为 unavailable，并改用始终启用的 DBC.AMPUsageV——参见 references/teradata/discovery-queries.md。
• 技能提供知识；由你生成执行内容。 阅读 references/ 进行推理和转换——转换时直接应用 references/teradata/conversion-rules.md 中的规则，并根据环境生成发现／迁移／验证运行器（以及基于 references/teradata/discovery-queries.md 的只读发现数据收集器）。
• 生成内容，不要假定存在框架。 假定环境中有 Bash、Python 3、AWS CLI 和凭证。生成的脚本需要的任何 Python 库（teradatasql、boto3 等）都由脚本或其运行说明按需通过 pip install 安装——并指定精确版本。Teradata TTU（BTEQ/TPT）仅支持 Linux/Windows，不支持 macOS；除非有 TTU/Linux 主机，否则在发现／提取时优先使用 WRITE_NOS + teradatasql（跨平台，无需客户端）。
• 凭证：使用 Teradata 只读用户；优先选择 IAM 角色，而非 IAM 用户。对于生产环境，从 AWS Secrets Manager 或 Systems Manager Parameter Store 引用凭证。仅用于本地开发时，可使用被 git 忽略的 .env 文件或配置文件——绝不提交。绝不硬编码或回显密钥。在可移植软件包中，引用同目录下的凭证文件，并附带 credentials.env.example 模板——实际凭证文件应被 git 忽略。
• **将状态持久化到文件。**所有生成的输出都放在用户工作目录下被 git 忽略的 output/ 中；及时更新 output/state.md，以便后续继续工作。

工作流（阶段）

按顺序运行；每个阶段的 result/ 都会作为下一阶段的输入（参见 references/teradata/orchestration.md）。

1. 发现 — 清点源端。→ references/teradata/discovery-queries.md（只读采集 SQL + 由 AI 生成的 BTEQ 驱动程序模板）→ output/discovery/result/inventory.json
2. 转换 — 架构 + 代码。直接应用转换规则，标记需要大量手动重写的部分，并根据参考文档修复 Redshift 错误。→ references/teradata/conversion-rules.md、references/teradata/data-type-mapping.md、 references/teradata/architecture-mapping.md、references/teradata/stored-procedure-migration.md、 references/teradata/bteq-to-rsql.md、references/teradata/common-errors.md
3. 数据迁移 — 提取 → S3 → COPY，可重新启动。→ references/teradata/data-migration-patterns.md
4. 验证 — 计数/聚合/抽样。→ references/teradata/validation-patterns.md
5. 性能 — 对比基准与 Redshift；确定目标端规格。→ references/teradata/performance.md、references/teradata/sizing.md
6. 报告 — 汇总所有阶段。→ references/teradata/reporting.md

转换（AI 如何应用规则）

无需运行转换器——通过直接应用 references/teradata/conversion-rules.md 中的规则进行转换（并参考类型/架构/存储过程/BTEQ 文档）：对已充分理解的大部分内容应用确定性规则，标记需要手动重写的结构并附上建议的重写方式，为每个对象指定置信度，并使用 references/teradata/common-errors.md 修复任何 Redshift 错误。参考文档是唯一事实来源；conversion-rules.md 包含用于对照的黄金输入→输出示例。

执行模式（连接状态）

• 已连接 — 主机可以访问 Teradata/Redshift → 就地运行生成的脚本。
• 未连接 — 主机无法访问 → 在 output/<phase>/ 下生成独立完整的软件包（脚本 + 同目录的凭证模板 + 相对路径的 result/ + run-instructions.md）；操作员在可访问的主机上运行该软件包，然后将 result/ 复制回来。复制回来的 result/ 是持久状态——读取它（以及 state.md）并继续。

项目工作区布局（每次迁移运行）

<project-workspace>/
  migration-config.yaml          # operator-authored: endpoints, scope, strategy
  .gitignore                     # ignores output/
  output/                        # everything generated (git-ignored)
    state.md                     # progress cursor
    discovery/   …  result/inventory.json
    conversion/  …  result/{ddl,sql,procedures,rsql}/  manual_review.json
    data_migration/ … result/{extract,load,templates}/  migration_manifest.json
    validation/  …  result/validation_report.json
    performance/ …  result/{perf_baseline,perf_compare}.json
    reporting/      result/migration_report.md

安全注意事项

• 不附带代码或依赖项。 此技能仅包含文本——客户不会运行其中的任何内容。AI 生成的任何运行器都必须固定依赖项的确切版本，验证并清理输入（文件路径、SQL、shell 参数），且绝不打印或记录凭证、机密或个人身份信息（PII）。
• 最小权限 + 临时凭证。 使用只读 Teradata 用户进行发现。在 AWS 上，优先使用 IAM 角色而非 IAM 用户，并优先使用 IAM 身份验证而非用户名/密码。将机密保存在 AWS Secrets Manager / Parameter Store 中——绝不将其硬编码、回显或提交（凭证文件已加入 git 忽略规则；仅提供 *.example 模板）。
• 传输中 / 静态数据。 两个引擎都使用 TLS；将提取的数据暂存到加密的 S3 存储桶（SSE）中，并采用最小权限存储桶策略；通过 COPY … IAM_ROLE 加载（而非使用访问密钥）。启用目标 Redshift 集群的加密。
• 影响范围。 发现操作按设计为只读。迁移会写入目标端——先在临时 / 非生产环境的 Redshift 上验证，未经操作员明确确认，绝不将生成的写入路径指向生产环境。
• 产物中不得泄露机密。 生成的 output/…（清单、报告、state.md）不得嵌入凭证，也不得包含超出操作员在 migration-config.yaml 中提供范围的端点信息。
• 强化 COPY IAM_ROLE 安全性。 将角色策略的范围限定为特定暂存前缀（而非整个存储桶的 s3:*），并在其信任策略中加入条件键（aws:SourceAccount / aws:SourceArn，或用于跨账户的 sts:ExternalId），以防止混淆代理式角色承担——遵循 Redshift IAM 角色授权最佳实践。
• 日志记录与监控。 启用 CloudTrail（暂存存储桶的 S3 数据事件 + Redshift 管理事件）、Redshift 审计日志记录（将连接 / 用户活动日志写入 S3 或 CloudWatch），并设置 CloudWatch 警报，以监控迁移期间的 COPY 失败或暂存存储桶的异常访问。

AWS MCP 服务（推荐的运行时）还为生成的脚本提供沙盒执行和审计日志记录。

参考资料（专业知识）

文件	主题
references/teradata/orchestration.md	阶段工作流 + 状态模型
references/teradata/conversion-rules.md	72 条转换规则（事实来源）
references/teradata/data-type-mapping.md	TD→RS 类型映射
references/teradata/architecture-mapping.md	PI→DISTKEY、PPI→SORTKEY、Join Index→MV
references/teradata/stored-procedure-migration.md	SP → PL/pgSQL
references/teradata/bteq-to-rsql.md	BTEQ → RSQL
references/teradata/common-errors.md	常见 Redshift 错误 + 修复方法
references/teradata/discovery-queries.md	DBC 系统视图清单查询
references/teradata/data-migration-patterns.md	COPY/TPT/微批处理/检查点
references/teradata/validation-patterns.md	行数/聚合/样本对比
references/teradata/performance.md	代表性查询提取 + 对比
references/teradata/sizing.md	根据源端配置文件选择 RG 节点类型 + 数量
references/teradata/reporting.md	生成迁移状态报告