次の方法で共有

移行: ​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 の設計によって実現できる高いクエリ パフォーマンスを、ご自身のソリューションで最大限に活用できるように設計を調整することです。 拡張性を考えてデータ ウェアハウスを設計すると独自の設計パターンが導入されるため、従来の手法が常に最適であるとは限りません。 一部の設計の調整は移行後に行うことができますが、プロセスの早い段階で調整することができれば時間と手間を節約できるため、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) 構文の違いがいくつかあります。 詳細については、Microsoft Fabric の T-SQL のセキュリティ、外部からのアクセスに関するページを参照してください。 また、データベース コード (DML) の移行方法を選択する場合は、コード評価することも検討してください。

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

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

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

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

Synapse 専用 SQL プール Fabric Warehouse
金額 decimal(19,4)
smallmoney decimal(10,4)
smalldatetime datetime2
datetime datetime2
nchar char
nvarchar varchar
tinyint smallint
[バイナリ] varbinary
datetimeoffset* datetime2

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

スキーマ、コード、データの移行方法

これらのオプションを確認して、ご自身のシナリオ、従業員のスキル セット、データの特性にどれが適しているかを判断します。 選択するオプションは、ご自身の経験、好み、各ツールの利点によって異なります。 Microsoft の目標は、摩擦と手作業を軽減し、移行エクスペリエンスをシームレスにする移行ツールを開発し続けることです。

次の表は、データ スキーマ (DDL)、データベース コード (DML)、データの移行方法に関する情報をまとめたものです。 各シナリオについては、この記事の後半でさらに詳しく説明します ("オプション" 列にリンクが記載されています)。

オプション番号 オプション できること スキルまたは好み シナリオ
1 Data Factory スキーマ (DDL) 変換
データ抽出
データ インジェスト		 ADF またはパイプライン スキーマ (DDL) とデータ移行をオールインワンに簡略化しました。 ディメンション テーブル に推奨されます。
2 Data Factory (パーティションあり) スキーマ (DDL) 変換
データ抽出
データ インジェスト		 ADF またはパイプライン ファクト テーブル に推奨される、読み取り/書き込みの並列処理を向上させることで、オプション 1 の 10 倍のスループットを提供するパーティション分割オプションの使用。
3 Data Factory で高速コードを使用する スキーマ (DDL) 変換 ADF またはパイプライン スキーマ (DDL) をまず最初に変換して移行してから、CETAS を使用して抽出し、COPY または Data Factory を使用してデータを取り込むことで、全体的なインジェスト パフォーマンスを最適化します。
4 ストアド プロシージャの高速コード スキーマ (DDL) 変換
データ抽出
コード評価		 T-SQL IDE を使用する SQL ユーザーは、どのタスクに着手するかをより細かく制御できます。 COPY または Data Factory を使用してデータを取り込みます。
5 Azure Data Studio の SQL データベース プロジェクトの拡張機能 スキーマ (DDL) 変換
データ抽出
コード評価		 SQL プロジェクト SQL Database プロジェクトをデプロイに使用し、オプション 4 を統合します。 COPY または Data Factory を使用してデータを取り込みます。
6 CREATE EXTERNAL TABLE AS SELECT (CETAS) データ抽出 T-SQL Azure Data Lake Storage (ADLS) Gen2 へのコスト効率とパフォーマンスの高いデータ抽出。 COPY または Data Factory を使用してデータを取り込みます。
7 dbt を使用した移行 スキーマ (DDL) 変換
データベース コード (DML) 変換		 dbt dbt を既に使用しているユーザーは、dbt Fabric アダプターを使用して DDL と DML を変換できます。 その後、この表にある他のオプションを使用してデータを移行する必要があります。

最初に移行するワークロードを選択する

Synapse 専用 SQL プールから Fabric Warehouse への移行プロジェクトを開始するにあたって、どこから着手すべきかを決める際は、次に該当するワークロード領域を選びます。

  • 新しい環境の利点を迅速に実感でき、Fabric Warehouse への移行が可能であることを証明できるもの。 複数の小規模な移行の準備をするなど、小規模でシンプルなところから始めます。
  • 他の領域に移行するときに使用するプロセスとツールについて、社内の技術スタッフがそれに関連する経験を積む時間を確保します。
  • ソース Synapse 環境に特化した、今後に使える移行テンプレートと、役立つツールやプロセスを作成します。

ヒント

移行する必要があるオブジェクトのインベントリを作成し、移行プロセスを最初から最後まで文書化することで、他の専用 SQL プールまたはワークロードでも同じように繰り返すことができるようにします。

初期移行で移行するデータの量は、Fabric Warehouse 環境の機能と利点を示すために十分な大きさにしつつ、価値をすばやく実感できるよう、大きすぎないようにする必要があります。 1 から 10 テラバイトの範囲のサイズが一般的です。

Fabric Data Factory を使用した移行

このセクションでは、Azure Data Factory と Synapse Pipeline に慣れているローコードまたはコードなしのペルソナ向けの、Data Factory を使用するオプションについて説明します。 ドラッグ アンド ドロップで操作できる UI を用いたこのオプションを使用すると、簡単な手順で DDL を変換してデータを移行することができます。

Fabric Data Factory では、次のタスクを実行できます。

  • スキーマ (DDL) を Fabric Warehouse 構文に変換します。
  • Fabric Warehouse でスキーマ (DDL) を作成します。
  • データを Fabric Warehouse に移行します。

オプション 1. スキーマまたはデータの移行 - コピー ウィザードと ForEach Copy アクティビティ

このメソッドでは Data Factory のコピー アシスタントを使用してソース専用 SQL プールに接続し、専用 SQL プールの DDL 構文を Fabric に変換してから、データを Fabric Warehouse にコピーします。 1 つまたは複数のターゲット テーブルを選択できます (TPC-DS データセットには 22 個のテーブルがあります)。 UI で選択したテーブルの一覧をループ処理する ForEach を生成し、22 個の並列する Copy アクティビティ スレッドが生成されます。

  • 22 個の SELECT クエリ (選択したテーブルごとに 1 つ) が生成され、専用 SQL プールで実行されました。
  • 生成されたクエリを実行できる、適切な DWU とリソース クラスがあることを確認します。 今回のケースでは、送信された 22 個のクエリを最大 32 個のクエリで処理できるようにするために、staticrc10 を持つ DWU1000 が少なくとも 32 個必要です。
  • Data Factory で専用 SQL プールから Fabric Warehouse にデータを直接コピーするには、ステージングが必要です。 インジェスト プロセスは、2 つのフェーズで構成されています。
    • 最初のフェーズはステージングと呼ばれ、専用 SQL プールから ADLS にデータを抽出します。
    • 2 番目のフェーズは、ステージングから Fabric Warehouse にデータを取り込むことです。 データ インジェストが行われるのは、ほとんどがステージング フェーズ中です。 つまり、ステージングは、インジェストのパフォーマンスに大きな影響を与えます。

コピー ウィザードを使用して ForEach を生成すると、シンプルな UI で DDL を変換し、選択したテーブルをワンステップで専用 SQL プールから Fabric Warehouse に取り込むことができます。

ただし、全体的なスループットは最適ではありません。 ステージングを使用しないといけない点、および "ソースからステージへ" のステップにおいて読み取りと書き込みを並列化する必要がある点が、パフォーマンス遅延の主な要因です。 このオプションは、ディメンション テーブルにのみ使用することをお勧めします。

オプション 2. DDL またはデータ移行 - パーティション オプションを使用したデータ パイプライン

Fabric データ パイプラインを使用してより大きなファクト テーブルの読み込みスループットを向上させるには、パーティション オプションを使用する各ファクト テーブルに対して Copy アクティビティを使用することをお勧めします。 これにより、Copy アクティビティのパフォーマンスを最適化できます。

ソース テーブルの物理パーティション分割を使用することもできます (使用可能な場合)。 テーブルに物理パーティション分割がない場合は、パーティション列を指定し、動的パーティション分割を使用するために最小値と最大値を指定する必要があります。 次のスクリーンショットでは、データ パイプラインの "ソース" オプションによって、ws_sold_date_sk 列に基づくパーティションの動的範囲を指定しています。

主キーを指定するオプション、または動的パーティション列の日付を示すデータ パイプラインのスクリーンショット。

パーティションを使用するとステージング フェーズのスループットを向上させることができますが、適切な調整を行うには、考慮すべき事項があります。

  • パーティションの範囲によっては、専用 SQL プールで 128 を超えるクエリが生成される可能性があるため、すべてのコンカレンシー スロットが使用される可能性があります。
  • すべてのクエリを実行できるようにするには、最低でも DWU6000 にスケーリングする必要があります。
  • たとえば、TPC-DS web_sales テーブルの場合、163 個のクエリが専用 SQL プールに送信されています。 DWU6000 では、128 個のクエリが実行され、35 個のクエリがキューに登録されました。
  • 動的パーティションを使用すると、範囲パーティションが自動的に選択されます。 今回のケースでは、専用 SQL プールに送信された SELECT クエリごとに 11 日間という範囲です。 次に例を示します：
    WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080')
...
WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')

ファクト テーブルの場合は、Data Factory のパーティション分割オプションを使用してスループットを向上することをお勧めします。

ただし、並列処理する読み取りの数が増えるため、抽出クエリを実行できるようにするには、専用 SQL プールを上位の DWU にスケーリングする必要があります。 パーティション分割を利用すれば、パーティション オプションを使用しない場合と比べて速度は 10 倍に向上します。 DWU を上げてコンピューティング リソース側からスループットを向上させることもできますが、専用 SQL プールで許可されるアクティブなクエリの数は、最大 128 個です。

Note

Synapse DWU から Fabric へのマッピングの詳細については、「 ブログ: Azure Synapse 専用 SQL プールを ファブリック データ ウェアハウス コンピューティングにマッピングする」を参照してください。

方法 3. DDL 移行 - コピー ウィザードの ForEach Copy アクティビティ

上記の 2 つのオプションは、"小規模" なデータベースに適したデータ移行オプションです。 しかし、より高いスループットが必要な場合は、別のオプションをお勧めします。

  1. 専用 SQL プールから ADLS にデータを抽出することで、ステージ パフォーマンスのオーバーヘッドを軽減します。
  2. Data Factory または COPY コマンドを使用して、Fabric Warehouse にデータを取り込みます。

スキーマ (DDL) の変換には、Data Factory を引き続き使用できます。 コピー ウィザードを使用すると、特定のテーブルまたはすべてのテーブルを選択できます。 設計上、これはスキーマとデータをワンステップで移行し、クエリ ステートメントの TOP 0 という false 条件を使用することで行のないスキーマを抽出します。

次のコード サンプルでは、Data Factory を使用したスキーマ (DDL) の移行について説明します。

コード例: Data Factory を使用したスキーマ (DDL) の移行

Fabric Data Pipelines を使用すると、任意のソース Azure SQL Database または専用 SQL プールからテーブル オブジェクトの DDL (スキーマ) を簡単に移行できます。 このデータ パイプラインは、ソース専用 SQL プール テーブルのスキーマ (DDL) を介して Fabric Warehouse に移行します。

Fabric Data Factory における Lookup オブジェクトと For Each オブジェクトの連携を示すスクリーンショット。For Each オブジェクト内には、DDL を移行するアクティビティがあります。

パイプラインの設計: パラメーター

このデータ パイプラインでは、移行するスキーマを指定できるパラメーター SchemaName を使用できます。 既定値は、dbo スキーマです。

"既定値" フィールドに、移行するスキーマを示すテーブル スキーマの一覧をコンマ区切りで入力します。2 つのスキーマ dbo と tpch を指定する場合は、'dbo','tpch' のようにします。

データ パイプラインの [パラメーター] タブを示す Data Factory のスクリーンショット。 [名前] フィールドに「SchemaName」と入力します。[既定値] フィールド 'dbo','tpch' で、これら 2 つのスキーマを移行する必要があることを示します。

パイプラインの設計: LookUp アクティビティ

LookUp アクティビティを作成し、接続をソース データベースに指定します。

[設定] タブで、次のようにします。

  • "データ ストアの種類" を [外部] に設定します。

  • "接続" は、使用している Azure Synapse 専用 SQL プールです。 "接続の種類" は、[Azure Synapse Analytics] です。

  • "クエリの使用" は、[クエリ] に設定されています。

  • "クエリ" フィールドは動的な式を使用して作成する必要があります。これにより、ターゲット ソース テーブルの一覧を返すクエリで SchemaName パラメーターを使用できるようになります。 [クエリ] を選択してから、[動的コンテンツの追加] を選択します。

    LookUp アクティビティに含まれるこの式により、システム ビューにクエリを実行してスキーマとテーブルの一覧を取得する SQL ステートメントが生成されます。 SQL スキーマでフィルター処理できるように SchemaName パラメーターを参照します。 出力は、ForEach アクティビティへの入力として使用される SQL スキーマとテーブルの配列です。

    次のコードを使用して、すべてのユーザー テーブルとそのスキーマ名を含むリストを返します。

    @concat('
SELECT s.name AS SchemaName,
t.name  AS TableName
FROM sys.tables AS t
INNER JOIN sys.schemas AS s
ON t.type = ''U''
AND s.schema_id = t.schema_id
AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),')
')

データ パイプラインの [設定] タブを示す Data Factory のスクリーンショット。[クエリ] ボタンが選択され、[クエリ] フィールドにコードが貼り付けられます。

パイプラインの設計: ForEach ループ

ForEach ループについては、[設定] タブで次のオプションを構成します。

  • "順次" をオフにして、複数のイテレーションを同時に実行できるようにします。
  • "バッチ カウント" を 50 に設定して、同時実行するイテレーションの最大数を制限します。
  • "項目" フィールドでは、動的コンテンツを使用して LookUp アクティビティの出力を参照する必要があります。 次のコード スニペットを追加します: @activity('Get List of Source Objects').output.value

ForEach ループ アクティビティの設定タブを示すスクリーンショット。

パイプラインの設計: ForEach ループ内の Copy アクティビティ

ForEach アクティビティ内に Copy アクティビティを追加します。 このメソッドでは、データ パイプライン内で動的な式言語を使用して、データのないスキーマのみを Fabric Warehouse に移行するための SELECT TOP 0 * FROM <TABLE> を構築します。

[ソース] タブで:

  • "データ ストアの種類" を [外部] に設定します。
  • "接続" は、使用している Azure Synapse 専用 SQL プールです。 "接続の種類" は、[Azure Synapse Analytics] です。
  • "クエリの使用" を [クエリ] に設定します。
  • "クエリ" フィールドに動的なコンテンツ クエリを貼り付け、次の式を使用します。この式を使用すると、行は返されず、テーブル スキーマ @concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName) のみが返されます。

ForEach ループ内のコピー アクティビティの [ソース] タブを示す Data Factory のスクリーンショット。

[送信先] タブで、次の手順を実行します。

  • "データ ストアの種類" を [ワークスペース] に設定します。
  • "ワークスペースのデータ ストアの種類"は [Data Warehouse] にし、"データ ウェアハウス" は Fabric Warehouse に設定します。
  • 送信先テーブルのスキーマとテーブル名は、動的コンテンツを使用して定義されます。
    • スキーマは、現在のイテレーションのフィールド SchemaName を、スニペット @item().SchemaName を使用して参照します。
    • テーブルは、スニペット @item().TableName を使用して TableName を参照しています。

各 ForEach ループ内のコピー アクティビティの [配信先] タブを示す Data Factory のスクリーンショット。

パイプラインの設計: シンク

シンクについては、ポイント先をウェアハウスに指定し、ソース スキーマとテーブル名を参照します。

このパイプラインを実行すると、Data Warehouse にソース内の各テーブルが入力され、適切なスキーマが設定された状態で表示されます。

Synapse 専用 SQL プールのストアド プロシージャを使用して移行する

このオプションでは、ストアド プロシージャを使用して Fabric への移行を実行します。

コード サンプルは、microsoft/fabric-migration on GitHub.com で入手できます。 このコードはオープン ソースとして公開されているため、ぜひ貢献してコミュニティを支援してください。

移行ストアド プロシージャで実行できることは以下のとおりです。

  1. スキーマ (DDL) を Fabric Warehouse 構文に変換します。
  2. Fabric Warehouse でスキーマ (DDL) を作成します。
  3. Synapse 専用 SQL プールから ADLS にデータを抽出します。
  4. T-SQL コードでサポートされていない Fabric 構文 (ストアド プロシージャ、関数、ビュー) にフラグを設定します。

これは、次のようなユーザーに最適なオプションです。

  • T-SQL に慣れている場合。
  • SQL Server Management Studio (SSMS) などの統合開発環境を使用する場合。
  • 作業するタスクをより細かく制御する必要がある場合。

スキーマ (DDL) 変換、データ抽出、または T-SQL コード評価用の特定のストアド プロシージャを実行できます。

データ移行については、COPY INTO または Data Factory を使用して、Fabric Warehouse にデータを取り込む必要があります。

SQL データベース プロジェクトを使用して移行する

Microsoft Fabric Data Warehouse は、Azure Data Studio と Visual Studio Code 内で使用できる SQL Database Projects 拡張機能でサポートされています。

この拡張機能は、Azure Data Studio と Visual Studio Code 内で使用できます。 この機能により、ソース管理、データベース テスト、スキーマ検証の機能が利用できるようになります。

Git 統合パイプラインや展開パイプラインなど、Microsoft Fabric の倉庫のソース管理の詳細については、「Warehouse を使用したソース管理」を参照してください。

これは、デプロイに SQL Database Project を使用したい場合に最適なオプションです。 このオプションは、基本的に Fabric 移行のストアド プロシージャを SQL Database プロジェクトに統合することで、シームレスな移行エクスペリエンスを提供するものです。

SQL Database Project を使用すると、以下を行うことができます。

  1. スキーマ (DDL) を Fabric Warehouse 構文に変換します。
  2. Fabric Warehouse でスキーマ (DDL) を作成します。
  3. Synapse 専用 SQL プールから ADLS にデータを抽出します。
  4. T-SQL コードでサポートされていない構文 (ストアド プロシージャ、関数、ビュー) にフラグを設定します。

データ移行については、その後に COPY INTO または Data Factory を使用して、Fabric Warehouse にデータを取り込みます。

Fabric で Azure Data Studio を利用できるようになる事に加え、Microsoft Fabric CAT チームは、SQL Database プロジェクトでスキーマ (DDL) とデータベース コード (DML) の抽出、作成、デプロイを処理できるようにする、一連の PowerShell スクリプトを提供しました。 便利な PowerShell スクリプトを使用して SQL Database プロジェクトを使用するチュートリアルについては、GitHub.com の microsoft/fabric-migration を参照してください。

SQL Database プロジェクトの詳細については、「SQL Database プロジェクトの拡張機能をお使いになる前に」および「プロジェクトをビルドして公開する」を参照してください。

CETAS を使用してデータを移行する

T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) コマンドは、Synapse 専用 SQL プールから Azure Data Lake Storage (ADLS) Gen2 にデータを抽出するための、最もコスト効率が良い最適な方法を提供します。

CETAS でできることは以下のとおりです。

  • ADLS にデータを抽出します。
    • このオプションを使用するには、データを取り込む前に、Fabric Warehouse でスキーマ (DDL) を作成する必要があります。 スキーマ (DDL) を移行するには、この記事のオプションを検討してください。

このオプションの利点は次のとおりです。

  • ソース Synapse 専用 SQL プールに対して送信されるクエリは、テーブルごとに 1 つだけです。 これによってコンカレンシー スロットが使い切られることがなくなるため、同時実行している顧客運用の ETL やクエリがブロックされることがありません。
  • テーブルごとに使用されるコンカレンシー スロットの数は 1 つのみであるため、DWU6000 へのスケーリングは必要ありません。そのため、ユーザーは低い DWU を使用することができます。
  • 抽出はすべてのコンピューティング ノードで並列に実行されるため、これがパフォーマンス向上の鍵となっています。

CETAS を使用して、Parquet ファイルとしてデータを ADLS に抽出します。 Parquet ファイルは列圧縮による効率的なデータ ストレージが可能なため、ネットワーク間の送受信に必要な帯域幅が少なくなるという利点があります。 さらに、Fabric のデータは Delta Parquet 形式として格納されるため、インジェスト中に Delta 形式に変換するためのオーバーヘッドがかからず、データ インジェストにかかる時間はテキスト ファイル形式に比べて 2.5 倍高速になります。

CETAS スループットを向上させるには、以下のようにします。

  • 並列 CETAS 操作を追加することで、コンカレンシー スロットの使用を増やしつつ、スループットを向上させます。
  • Synapse 専用 SQL プールの DWU をスケーリングします。

dbt を使用して移行する

このセクションでは、現在使用している Synapse 専用 SQL プール環境で既に dbt を使用しているユーザー向けの dbt オプションについて説明します。

dbt でできることは以下のとおりです。

  1. スキーマ (DDL) を Fabric Warehouse 構文に変換します。
  2. Fabric Warehouse でスキーマ (DDL) を作成します。
  3. データベース コード (DML) を Fabric 構文に変換します。

dbt フレームワークを使用することで、実行のたびに DDL と DML (SQL スクリプト) を即座に生成できます。 SELECT ステートメントで表されるモデル ファイルの場合、プロファイル (接続文字列) とアダプターの型を変更することで、DDL/DML を任意のターゲット プラットフォームに即座に変換できます。

dbt フレームワークは、コードファースト アプローチです。 データは、CETAS や COPY または Data Factory など、このドキュメントに記載されているオプションを使用して移行する必要があります。

Microsoft Fabric Synapse Data Warehouse 用の dbt アダプターを使用すると、Synapse 専用 SQL プール、Snowflake、Databricks、Google Big Query、Amazon Redshift などのさまざまなプラットフォームを対象とした既存の dbt プロジェクトを、簡単な構成変更で Fabric Warehouse に移行できます。

Fabric Warehouse を対象とする dbt プロジェクトを開始するには、「チュートリアル: dbt を Fabric Data Warehouse 用に設定する」を参照してください。 このドキュメントでは、異なるウェアハウスやプラットフォーム間を移動するオプションも示します。

Fabric Warehouse へのデータ インジェスト

Fabric Warehouse へのインジェストには、好みに応じて COPY INTO または Fabric Data Factory を使用します。 どちらの方法も、ファイルが既に Azure Data Lake Storage (ADLS) Gen2 に抽出されているという前提条件があれば、パフォーマンス スループットは同程度であるため、推奨される最適なオプションです。

プロセスを設計する際、パフォーマンスを最大限に高めるには、次のいくつかの要因に注意してください。

  • Fabric では、ADLS から Fabric Warehouse に複数のテーブルを同時に読み込んでも、リソース競合は発生しません。 そのため、並列スレッドを読み込んでも、パフォーマンスは低下しません。 インジェストの最大スループットは、Fabric の容量のコンピューティング能力によってのみ制限されます。
  • Fabric のワークロード管理では、負荷とクエリに割り当てるリソースは分離されます。 クエリとデータの読み込みが同時に実行されても、リソースの競合は発生しません。

関連するコンテンツ