移行計画: Azure Synapse Analytics の専用 SQL プールから Fabric Data Warehouse への移行

適用対象:✅ Warehouse in Microsoft Fabric

この記事では、Azure Synapse Analytics の専用 SQL プールから Microsoft Fabric Data Warehouse に移行するための戦略、考慮事項、手法について説明します。

ヒント

Azure Synapse Analytics の専用 SQL プールから自動化された移行を行うには、Fabric Migration Assistant for Data Warehouse を使用してください。この記事には、戦略と計画に関する重要な情報が含まれています。

移行の概要

Microsoft Fabricは、企業向けのオールインワンのSaaS分析ソリューションです。 Data Factory、Data Engineering、Data Warehousing、Data Science、 Real-Time Intelligence、Power BIなど、包括的なサービス群を提供しています。

この記事では、スキーマ(DDL)、データベースコード(DML)、データ移行のオプションについて説明し、シナリオに合った選択肢を選ぶのに役立ちます。イラストレーションと性能テストには TPC-DS 業界ベンチマークを使用しています。データタイプ、テーブル幅、ソースレイテンシなどの要因によって結果が異なる場合があります。

移行を準備する

移行プロジェクトを慎重に計画し、スキーマ、コード、データがFabric Data Warehouseと互換性があることを確認してください。制限を考慮してください。互換性のないアイテムのリファクタリングに必要な作業や、移行を実現するために必要なその他のリソースを定量化してください。

計画のもう一つの重要な目標は、ソリューションが Fabric Data Warehouse のクエリパフォーマンスを最大限に活用できるように設計を調整することです。拡張性を考えてデータウェアハウスを設計すると独自の設計パターンが導入されるため、従来の手法が常に最適であるとは限りません。パフォーマンスガイドラインを見直しましょう。移行後にデザインの調整はできますが、早めに変更することで時間と労力を節約できます。ある技術や環境から別の技術への移行は常に大きな努力です。

以下の図は、移行ライフサイクルとその5つの柱( 評価と評価、 計画と設計、移行、 監視と統治、 最適化と現代化)に関連するタスクを示しています。

移行用の運用手順書

Synapse 専用 SQL プールから Fabric Data Warehouse への移行の計画 Runbook として、次のアクティビティを検討してください。

評価と査定
1. 目的と動機を明らかにします。期待する成果を明確にしておきます。
2. 既存のアーキテクチャを発見し、評価し、基準を定めましょう。
3. 主要な利害関係者とスポンサーを特定します。
4. 移行範囲を定義してください。
  1. 小さくシンプルに始めて、複数の小さな移動に備えましょう。
  2. プロセスのすべてのステージを監視してドキュメント化し始めます。
  3. 移行のためのデータとプロセスのインベントリを作成しましょう。
  4. データモデルの変更があれば定義してください。
  5. Fabricワークスペースをセットアップします。
5. チームのスキルセットや好みを評価しましょう。
  1. 可能な限り、処理を自動化します。
  2. Azure に組み込まれているツールや機能を使用すると、移行にかかる手間を減らすことができます。
6. 新しいプラットフォームのスタッフトレーニングを早期に実施する。
  1. スキルアップの必要性があるかを判断し、Microsoft Learn を含む、トレーニングアセットを確認しておきます。
計画と設計
1. 目的とするアーキテクチャを定義します。
2. 以下の作業を行うために、移行の方法とツールを選択してください:
  1. ソースからのデータ抽出。
  2. テーブルやビューのメタデータを含むスキーマ(DDL)変換。
  3. データインジェスト (履歴データを含む)。
    1. 必要に応じて、新しいプラットフォームのパフォーマンスとスケーラビリティを用いてデータモデルを再設計します。
  4. データベースコード (DML) の移行。
    1. ストアドプロシージャとビジネスプロセスを移行またはリファクタリングする。
3. ソースからセキュリティ機能とオブジェクトのアクセス許可のインベントリを作成して抽出します。
4. 増分負荷に対応する既存のETL/ELTプロセスを設計・変更する計画を立ててください。
  1. 新しい環境への並列 ETL または並列 ELT プロセスを作成します。
5. 移行プランの詳細を詰めます。
  1. 現在の状態を目的の状態にマッピングします。
移行
1. スキーマ、データ、コードの移行を行います。
  1. ソースからのデータ抽出。
  2. スキーマ（DDL）の変換。
  3. データインジェスト
  4. データベースコード (DML) の移行。
2. 必要であれば、専用 SQL プールリソースを一時的にスケールアップし、移行スピードを向上させます。
3. セキュリティとアクセス許可を適用します。
4. 増分読み込みのために、既存の ETL/ELT プロセスを移行します。
  1. ETL/ELT の段階的読み込みプロセスを移行またはリファクタリングする。
  2. 並列増分負荷プロセスのテストと比較。
5. 詳細な移行計画は必要に応じて調整してください。
監視とガバナンス
1. 並列で実行し、ソース環境と比較してください。
  1. アプリケーション、ビジネスインテリジェンスプラットフォーム、クエリツールをテストします。
  2. クエリパフォーマンスのベンチマークと最適化を行う。
  3. コスト、セキュリティ、パフォーマンスを監視および管理します。
2. ガバナンスベンチマークと評価を実施しましょう。
最適化と最新化
1. ビジネス利用に適していると判断したら、アプリケーションと主要なレポーティングプラットフォームを Fabric に移行します。
  1. ワークロードがAzure Synapse AnalyticsからMicrosoft Fabricに移行するにつれて、リソースを増減できます。
  2. 今回得た経験を元に、将来の移行に役立つ再現可能なテンプレートを作成します。繰り返します。
  3. コスト最適化、セキュリティ、スケーラビリティ、運用の卓越性の機会を特定しましょう。
  4. Fabric の最新機能を使用して、データ資産を最新化する余地がないかを確認します。

リフトアンドシフトか、それともモダナイズするか?

一般的に、計画する移行シナリオの目的と範囲に関係なく、移行には 2 種類あります。これは、そのままリフトアンドシフトすることと、アーキテクチャとコードの変更を組み込む段階的なアプローチを取ることです。

リフトアンドシフト

リフト&シフト移行では、既存のデータモデルを新しいFabric Data Warehouseにわずかな変更を加えて移行します。このアプローチでは、移行の利点を実感するために必要となる新しい作業が少ないため、リスクと移行時間を最小限に抑えることができます。

リフトアンドシフト移行は、次のシナリオに適しています。

移行するウェアハウスの数が少ない既存の環境がある。
適切に設計されたスタースキーマまたはスノーフレークスキーマに既にデータが含まれている、既存の環境がある場合。
Fabric Data Warehouse に移行する時間とコストが不足しています。

まとめると、このアプローチは現在のAzure Synapse専用SQLプール環境に最適化されたワークロードによく機能し、Fabricの大幅な変更を必要としません。

アーキテクチャを変更し、段階的なアプローチで最新化する

もしレガシーデータウェアハウスが長期間にわたって進化してきた場合、必要なパフォーマンスレベルを維持するために再設計が必要になるかもしれません。

また、Fabricワークスペースで利用可能な新しいエンジンや機能を活用するためにアーキテクチャを再設計することも検討してください。

設計上の違い: Synapse 専用 SQL プールと Fabric Data Warehouse

専用 SQL プールと Fabric Data Warehouse を比較して、次の Azure Synapse と Microsoft Fabric のデータウェアハウスの違いを検討してください。

テーブルに関する考慮事項

異なる環境間でテーブルを移行するとき、通常は生データとメタデータのみが物理的に移行されます。インデックスなど他のデータベース要素は、新しい環境では不要だったり、異なる実装をしている可能性があるため、ソースシステムから移行することは通常ありません。

インデックスなどのソース環境でのパフォーマンス最適化は、新しい環境で最適化が必要になる場所を示します。 Fabricはこれらの最適化を自動的に管理します。

T-SQL に関する考慮事項

データ操作言語(DML)の構文には考慮すべきいくつかの違いがあります。 Fabric Data WarehouseのT-SQL表面積を確認し、データベースコードの移行方法を選択する際にコード評価を行いましょう。

移行時のパリティの差によっては、T-SQL DML コードの一部を書き換える必要がある場合があります。

データ型のマッピングの違い

Fabric Data WarehouseはAzure Synapse Analytics専用SQLプールといくつかのデータ型の違いがあります。詳細については、「Microsoft Fabric のデータ型」を参照してください。

次の表は、Azure Synapse 専用 SQL プールから Fabric Data Warehouse への、サポートされているデータ型のマッピングを示しています。

Synapse 専用 SQL プール	ファブリックデータウェアハウス
money	decimal(19,4)
smallmoney	decimal(10,4)
smalldatetime	datetime2
datetime	datetime2
nchar	char
nvarchar	varchar
tinyint	smallint
binary	varbinary
Datetimeoffset*	datetime2

* Datetime2 は datetimeoffset が保存する追加のタイムゾーンオフセット情報を保存しません。 Fabric Data Warehouse現在datetimeoffsetデータ型をサポートしていないため、タイムゾーンのオフセットデータを別の列に抽出する必要があります。

ヒント

移行準備完了?

自動移行エクスペリエンスの使用を開始するには、「Fabric Migration Assistant for Data Warehouse」を参照してください。

より詳細な手動移行手順や詳細については、「Fabric Data Warehouseへの専用SQLプールの移行方法Azure Synapse Analytics」をご覧ください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-29