適用対象:✅ Warehouse in Microsoft Fabric
エンタープライズのTeradata資産をFabric Data Warehouseに移すには、スキーマやデータ転送以上のものが必要です。 SQLおよびBTEQコード、ロードプロセス、セキュリティ、レポート、運用、パフォーマンスの計画を立ててください。
この記事では、作業を5つの段階に分けて整理しています。 各移行波ごとにステージを繰り返し使えるランブックとして活用してください。 推奨実装については「 テラデータへの移行方法」を参照してください。 コード修復については、Teradata SQLの翻訳を参照してくださいFabric Data Warehouse。
Important
移行の各波の前に、現在のFabric Data Warehouse制限とT-SQLの表面積を確認してください。 すべてのブロックの違いに所有者と修復計画を割り当てましょう。
推奨される方法
ほとんどのワークロードに対して選択的モダナイゼーションを適用します:
- 検証済みのビジネスモデルと論理を維持。
- Migration Assistantを使って、サポートされたメタデータを翻訳・展開してください。
- Teradata固有のSQL、ユーティリティ、操作をFabricネイティブのパターンに置き換えましょう。
- サポートされていない依存関係や既存のアーキテクチャ問題によってブロックされたワークロードのみを再設計してください。
ビジネスドメイン、データマート、またはワークロードクラスターごとにウェーブごとに移行できます。 単一のビッグバン移動を避けましょう。
評価と検証
これらのワークストリームを一緒に評価し、依存を見落とさないようにしましょう:
| 作業ストリーム | Assess |
|---|---|
| 設計と性能 | データモデル、ボリューム、成長、スキュー、テーブル幅、並行性、実行時間、サービス目標 |
| ETLとロード | FastLoad、MultiLoad、Teradataパラレルトランスポーター、BTEQインポート/エクスポート、スケジュール、再起動動作、増分ロード |
| 治安と作戦 | ユーザー、役割、権限、サービスアカウント、監査、復旧、監視、そして所有権のサポート |
| 可視化と報告 | レポート、セマンティックモデル、アプリケーション、エクスポート、更新スケジュール、接続依存関係 |
| SQL互換性 | テーブル、ビュー、マクロ、プロシージャ、関数、データ型、 QUALIFY、ボラタイルテーブル、 PERIOD、BTEQ制御フロー |
| 移行ツール | メタデータ抽出、Migration Assistantの準備、データ移動、ソース管理、デプロイ自動化 |
| 移行を超えて | カットオーバー、ロールバック、最適化、トレーニング、廃止措置、および後続ウェーブ向けの再利用可能なプラクティス |
ビジネス成果、範囲、所有者、成功指標、ロールバックの期待値を定義します。 オブジェクトインベントリ、依存関係マップ、ワークロードベースライン、互換性レジスタ、波状プランを作成します。
計画と設計
評価を実行可能な設計に変換する:
- SQL中心のリレーショナル分析のターゲットとしてWarehouseを確認しましょう。
- 開発、テスト、本番のワークスペース、容量、名称、所有権を定義してください。
- Teradataのオブジェクトやデータ型をFabricターゲットにマッピングします。 サポートされていない項目や承認された代替案を記録しましょう。 メタデータの翻訳にはMigration Assistantを使いましょう。
- 過去のデータ移動と増分データの移動を別々に設計しましょう。
- Microsoft Entra ID、ワークスペースの役割、アイテム権限、Warehouse SQL権限に関するアクセスを再設計しましょう。
- 展開、検証、カットオーバー、ロールバックの基準を定義してください。
ターゲット設計では、次元モデル、バッチ指向のローディング、モジュール式ELT、そしてOneLakeを通じた再利用を推奨します。
Migrate
各ウェーブを次の順番で実行します:
- ターゲットワークスペース、アイデンティティ、接続、デプロイパスをプロビジョニングします。
- 抽出したTeradataのSQLファイルをMigration Assistantにアップロードし、メタデータを翻訳し、注意が必要なオブジェクトを修正します。
- 代表的なデータセットをコピーし、スループット、マッピング、エラー、再起動動作を検証します。
- 履歴ロードを完了し、必要に応じてインクリメンタル同期を確立します。
- セキュリティおよび運用プロセスを再構築すること。
- データ、SQLの挙動、レポート、アプリケーション、代表的なパフォーマンスを検証します。
- 接続を迂回し、受け入れ基準をクリアした後に切り離す。
オブジェクト作成成功だけを完了の合図として使わないでください。 波が完了するのは、データ、挙動、セキュリティ、運用、下流の消費が受理基準を満たしたときだけです。
監視とガバナンス
ワークロードのリスクプロファイルに必要な期間、ソースとターゲットを並行して運用します。
- 環境間でデータの新鮮さ、行数、ビジネス集計、結果の報告を比較します。
- ロード時間、クエリ時間、失敗、再試行、容量消費、アクティブセッション、ユーザー報告の問題を監視します。
- アクセス割り当て、特権識別、倉庫権限、セキュリティテスト結果を確認しましょう。
- 翻訳されたコード、デプロイメントのアセット、マッピングの決定、テスト証拠、例外はソース管理に保持してください。
- 移行準備状況をワークロードや受容ゲートで追跡し、移行オブジェクト数だけでなく追跡できます。
- 繰り返し起こる翻訳および読み込みの問題を、後の波の再利用可能な指針として記録します。
- エスカレーション、リカバリー、ロールバック、ハイパーケアの手順を確立し、生産の切り替えに先立つ。
ガバナンスには系譜、所有権、分類、保持、監査、運用説明責任が含まれます。 これらの管理は最終カットオーバー後ではなく、移行時に適用してください。
最適化と近代化
正確性と安定性が確立されたら、一時的な互換性パターンを削除し、Fabricネイティブ機能を使用してください。
- SQLのリテラル変換をモジュール式のT-SQLにリファクタリングします。
- 深く入れ子になったビューやモノリシックな手続き型ジョブを簡素化しましょう。
- 効率的で再開可能なファイルベースのパターンで高スループットの取り込みを標準化しましょう。
- Fabric Data Warehouseのパフォーマンスガイドラインと代表的な並行性テストを使ってチューニングしてください。
- アーキテクチャに合う範囲でガバネされたOneLakeアクセスを使い、不要なデータコピーを減らしましょう。
- Data Factory、Power BI、ノートブック、その他のFabricワークロードを統合し、重複や運用の複雑さを軽減します。
- 作業負荷の動作が安定した後、容量、セキュリティ、信頼性、コストをレビューします。
- 完成したウェーブを次のドメインの再利用可能なテンプレートに変えます。
移行波受容チェックリスト
切り替え前に以下を確認してください:
- オブジェクトインベントリと依存関係マップは、そのウェーブについて完了しています。
- T-SQLの制限をブロックするものは、承認された対策となっています。
- スキーマとコードはすべてのターゲット環境で繰り返し展開されます。
- 履歴データパスとインクリメンタルデータパスはスケールテストとリカバリーテストを通過します。
- データの照合およびビジネス検証は合意された閾値を満たしています。
- セキュリティは代表的なアイデンティティによって再構築され、検証されます。
- レポート、セマンティックモデル、アプリケーション、運用ジョブはテストに合格します。
- パフォーマンスと同時実行はワークロードの目標を満たしています。
- モニタリング、サポート担当体制、ロールバック、およびハイパーケア計画は有効です。
- 業務担当者および技術担当者がカットオーバーを承認します。