ある企業がオンプレミスのデータウェアハウス（Teradata）から Amazon Redshift に移行する計画を立てています。Teradata には数千のテーブルと数百のストアドプロシージャ、マクロ（Teradata 固有の機能）があります。一部の Teradata 固有の SQL 構文（QUALIFY、RESET WHEN、NORMALIZE 等）が使われており、直接 Redshift では動作しません。段階的な移行を最小限の開発コストで実現するには、どのアプローチが最適ですか？
- A. 全てのストアドプロシージャとクエリを手動で Redshift SQL に書き直す
- B. Amazon EMR で Teradata のジョブを Hive/Spark に書き直し、S3 をストレージとして使用する
- C. Teradata から Amazon S3 にデータを全量エクスポートし、Athena でクエリして段階的に移行する
- D. AWS Schema Conversion Tool（SCT）で Teradata から Redshift へのスキーマとコードの変換評価を行い、自動変換できるオブジェクトは SCT で変換する。自動変換できない Teradata 固有のコード（Teradata マクロ等）は SCT の変換レポートを参考に手動変換を優先度付けして対応する。AWS DMS でデータを Redshift にロードし、段階的にワークロードを移行する
解答と解説を見る
正解: D
AWS SCT は Teradata から Redshift への変換に対応しており、自動変換可能なオブジェクトと手動変換が必要なオブジェクトを識別します。変換レポートにより手動作業の優先度付けと工数見積もりが可能です。SCT + DMS の組み合わせは Teradata→Redshift の標準的な移行パターンです。段階的に高優先度のテーブルとクエリから移行し、リスクを分散できます。 A: 数千のテーブルと数百のストアドプロシージャを全て手動変換することは、莫大な開発コストと時間がかかります。SCT の自動変換を活用する方が効率的です。 C: Athena は S3 上のデータの分析には有用ですが、Teradata のストアドプロシージャや複雑な ETL ロジックの移行先としては機能が不足しており、Redshift への段階的移行には対応しません。 B: EMR への移行は Teradata のリレーショナル・データウェアハウスのワークロードを Hive/Spark に全面書き直すことになり、開発コストが非常に高くなります。
📚 関連サービスの解説: Amazon Redshift ・ AWS DMS