移行計画: Azure Synapse Analytics の専用 SQL プールから Fabric データウェアハウスへ

適用対象:✅ Microsoft Fabric のウェアハウス

この記事では、Azure Synapse Analytics 専用 SQL プールのデータ ウェアハウスを Microsoft Fabric Warehouse に移行する戦略、考慮事項、方法について詳しく説明します。

移行の概要

Microsoft が発表した Microsoft Fabric は、Data Factory、Data Engineering、データ ウェアハウス、Data Science、Real-Time Intelligence、Power BI などを含む包括的なサービス スイートを提供する、企業向けのオールインワン SaaS 分析ソリューションです。

この記事では、スキーマ (DDL) 移行、データベース コード (DML) 移行、およびデータ移行を行うためのオプションについて説明します。 ここでは、Microsoft が提供している複数のオプションについて詳しく説明し、実際のシナリオでどのオプションを検討すべきかを判断するためのガイダンスを提供します。 この記事では、説明とパフォーマンス テストに TPC-DS の業界ベンチマークを使用しています。 実際の結果は、データの種類、データ型、テーブルの幅、データ ソースの待機時間など、さまざまな要因によって異なる場合があります。

移行を準備する

移行プロジェクトに着手する前に慎重に計画を立て、その際に、移行するスキーマ、コード、データと Fabric Warehouse に互換性があることを確認します。 考慮すべきいくつかの制限事項があります。 互換性のない項目のリファクタリング作業、および移行実施前に必要なその他のリソースを定量化しておきます。

計画のもう 1 つの重要な目的は、Fabric Warehouse の設計によって実現できる高いクエリ パフォーマンスを、ご自身のソリューションで最大限に活用できるように設計を調整することです。 拡張性を考えてデータ ウェアハウスを設計すると独自の設計パターンが導入されるため、従来の手法が常に最適であるとは限りません。 移行後にいくつかの設計調整を行うことができますが、プロセスの早い段階で変更を行うと時間と労力が節約されるため、 パフォーマンスガイドラインを確認してください。 あるテクノロジまたは環境から別のテクノロジまたは環境への移行は、常に大きな労力を要する作業です。

次の図は、移行サイクルの主要な柱である評価と査定、計画と設計、移行、監視と管理、最適化と最新化を一覧で表したものです。それぞれの柱には、円滑な移行の計画と準備に必要な、関連タスクも記載されています。

移行用の運用手順書

次のアクティビティを、Synapse 専用 SQL プールから Fabric Warehouse への移行に関する計画ランブックとして使用することを検討してください。

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

"リフト アンド シフト"すべきか、最新化すべきか

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

リフト アンド シフト

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

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

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

つまり、このアプローチは、ワークロードが現在の Synapse 専用 SQL プール環境において最適化されており、Fabric で大きな変更を加える必要がない場合に最適です。

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

レガシ データ ウェアハウスが長期間にわたって進化している場合、必要なパフォーマンス レベルを維持するために再エンジニアリングが必要なことがあります。

Fabric ワークスペースで使用できる新しいエンジンと機能を利用するために、アーキテクチャを再設計することもできます。

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

次の Azure Synapse と Microsoft Fabric のデータ ウェアハウスの違いを、専用 SQL プールと Fabric Warehouse を比較しながら考えてみましょう。

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

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

インデックス作成といったソース環境でのパフォーマンス最適化は、新しい環境においてどの領域にパフォーマンス最適化を追加するべきかを考慮する判断材料になりますが、Fabric ではこれが自動で処理されます。

T-SQL に関する考慮事項

注意すべきデータ操作言語 (DML) 構文の違いがいくつかあります。 Fabric Data Warehouse の T-SQL サーフェス領域を参照してください。 また、データベース コード (DML) の移行方法を選択する場合は、コード評価することも検討してください。

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

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

Fabric Warehouse のデータ型には、いくつかの違いがあります。 詳細については、「Microsoft Fabric のデータ型」を参照してください。

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

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

関連するコンテンツ

• Microsoft Fabric でウェアハウスを作成する
• Fabric Data Warehouse のパフォーマンス ガイドライン
• Microsoft Fabric のデータ ウェアハウスのセキュリティ
• ブログ:Azure Synapse 専用 SQL プールを Fabric Data ウェアハウス コンピューティングにマッピングする