移行計画: SQL Server から Fabric Data Warehouse への

適用対象:✅ Warehouse in Microsoft Fabric

この記事では、SQL ServerからMicrosoft Fabric Data Warehouseへのデータウェアハウス移行の戦略、考慮事項、方法を詳述します。

ヒント

SQL Serverからの移行の自動化体験は、Fabric Migration Assistant for Data Warehouseを利用することで利用可能です。 この記事には、戦略と計画に関する重要な情報が含まれています。

移行の概要

Microsoft Fabricは、データファクトリー、データエンジニアリング、データウェアハウジング、データサイエンス、 Real-Time インテリジェンス、Power BIなど、包括的なサービス群を提供する企業向けのオールインワンSaaS分析ソリューションです。

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

移行を準備する

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

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

以下の図は移行ライフサイクルを示しています。 評価と 評価、 計画と設計、 移行、 監視と統治、 最適化と近代化といった主要な柱を列挙し、それぞれの柱で円滑な移行のための計画と準備のためのタスクが示されています。

移行用の運用手順書

以下の活動を、SQL ServerからFabric Data Warehouseへの移行のための計画的なランブックとして考えてください。

1. 評価と査定
   1. 目的と動機を明らかにします。 期待する成果を明確にしておきます。
   2. 既存のアーキテクチャを発見し、評価し、基準を定めましょう。
   3. 主要な利害関係者とスポンサーを特定します。
   4. 移行範囲を定義してください。
      1. 小さくシンプルに始めて、複数の小さな移動に備えましょう。
      2. プロセスのすべてのステージを監視してドキュメント化し始めます。
      3. 移行のためのデータとプロセスのインベントリを作成しましょう。
      4. データモデルの変更があれば定義してください。
      5. Fabricワークスペースをセットアップします。
   5. チームのスキルセットや好みを評価しましょう。
      1. 可能な限り、処理を自動化します。
      2. 組み込みのツールや機能を活用して移行作業を減らしましょう。
   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 Serverリソースを拡大してください。
   3. セキュリティとアクセス許可を適用します。
   4. 既存のETLやELTプロセスを増分負荷のために移行します。
      1. ETLやELTの増分ロードプロセスを移行またはリファクタリングします。
      2. 並列増分負荷プロセスのテストと比較。
   5. 詳細な移行計画は必要に応じて調整してください。
4. 監視とガバナンス
   1. 並列で実行し、ソース環境と比較してください。
      1. アプリケーション、ビジネス インテリジェンス プラットフォーム、クエリ ツールをテストします。
      2. クエリ パフォーマンスのベンチマークと最適化を行う。
      3. コスト、セキュリティ、パフォーマンスを監視および管理します。
   2. ガバナンスベンチマークと評価を実施しましょう。
5. 最適化と最新化
   1. ビジネス利用に適していると判断したら、アプリケーションと主要なレポーティング プラットフォームを Fabric に移行します。
      1. ワークロードがSQL ServerからMicrosoft Fabricへとシフトするにつれて、リソースを拡大しましょう。
      2. 今回得た経験を元に、将来の移行に役立つ再現可能なテンプレートを作成します。 繰り返します。
      3. コスト最適化、セキュリティ、スケーラビリティ、運用の卓越性の機会を特定しましょう。
      4. Fabric の最新機能を使用して、データ資産を最新化する余地がないかを確認します。

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

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

リフト アンド シフト

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

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

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

まとめると、この方法は現在のSQL Server環境に最適化されたワークロードによく機能し、Fabricの大幅な変更を必要としません。

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

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

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

SQL ServerとFabric Data Warehouseの設計の違い

SQL ServerとFabric Data Warehouseの違いを考えてみましょう。

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

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

ソース環境でのパフォーマンス最適化(インデックスなど)は、新しい環境でどこにパフォーマンス最適化を加えるかを示しますが、Fabricが自動的にそれを処理してくれます。

T-SQL に関する考慮事項

データ操作言語(DML)の構文の違いには注意してください。 Fabric Data Warehouse の T-SQL サーフェス領域を参照してください。 また、 データベースコード(DML)の移行方法を選ぶ際にはコード評価も検討してください。

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

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

Fabric Data Warehouse他のMicrosoft SQLプラットフォームといくつかのデータ型の違いがあります。 詳細については、「Microsoft Fabric のデータ型」を参照してください。

以下の表は、SQL データベース エンジンからFabric Data Warehouseへのサポートデータ型のマッピングを示しています。

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

* datetime2 datetimeoffsetが保存するタイムゾーンのオフセット情報は保存しません。 datetimeoffsetデータ型は現在Fabric Data Warehouseでサポートされていないため、タイムゾーンのオフセットデータを別の列に抽出してください。

ヒント

移行準備完了?

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

手動の移行手順や詳細については、「SQL ServerからFabric Data Warehouseへの移行方法」を参照してください。

関連するコンテンツ

• Microsoft Fabric で倉庫を作成します
• Fabric Data Warehouse のパフォーマンス ガイドライン
• Microsoft Fabric におけるデータウェアハウスのセキュリティ
• Microsoft Fabric の移行の概要