移行方法 Azure Synapse Analytics の専用 SQL プールを Fabric の Data Warehouse へ

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

この記事では、専用のSQLプールからデータウェアハウジングをAzure Synapse Analytics移行する方法をMicrosoft Fabric Data Warehouseに説明します。

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

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

Synapse専用SQLプールの移行プロジェクトFabric Data Warehouseどこから始めるか決める際は、以下の作業範囲を選んでください:

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

初期の移行で移行されたデータの量は、Fabric Data Warehouse環境の機能と利点を示すのに十分な量であるべきですが、価値を迅速に示すには大きすぎてはいけません。 1 から 10 テラバイトの範囲のサイズが一般的です。

Fabric Data Factory を使用した移行

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

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

• スキーマ(DDL)をFabric Data Warehouse構文に変換します。
• Fabric Data Warehouse上でスキーマ(DDL)を作成します。
• データをFabric Data Warehouseに移行してください。

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

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

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

推奨される使用方法

コピーウィザードを使ってForEachを生成することで、DDLを変換し、専用SQLプールから選択したテーブルを一歩で取り込みFabric Data WarehouseするシンプルなUIを提供します。

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

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

Fabric パイプラインを使用して大規模なファクト テーブルを読み込むためのスループットの向上に対処するには、パーティション オプションを持つ各ファクト テーブルに対してコピー アクティビティを使用することをお勧めします。 これにより、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のアクティブクエリしか許されません。

Synapse DWU から Fabric へのマッピングの詳細については、「 ブログ: Azure Synapse 専用 SQL プールを Fabric Data Warehouse コンピューティングにマッピングする」を参照してください。

オプション 3。 DDL 移行 - コピー ウィザードの ForEach Copy アクティビティ

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

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

推奨される使用方法

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

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

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

Fabric Pipelinesを使えば、Azure SQL Databaseや専用SQLプールなど任意のソースからテーブルオブジェクトのDDL(スキーマ)を簡単に移行できます。 このパイプラインは、元の専用SQLプールテーブルのスキーマ(DDL)をFabric Data Warehouseに移行します。

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

このパイプラインはパラメーター SchemaNameを受け取ります。これにより、移行するスキーマを指定できます。 既定値は、dbo スキーマです。

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

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

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'),')
  ')
  

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

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

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

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

ForEach アクティビティ内に Copy アクティビティを追加します。 この方法はパイプライン内の動的表現言語を用いて、データなしでスキーマのみをウェアハウスに移行する SELECT TOP 0 * FROM <TABLE> を構築します。

[ソース] タブで:

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

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

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

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

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

このパイプラインを実行すると、ソース内の各テーブルが適切なスキーマとともにデータウェアハウスに入力されます。

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

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

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

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

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

推奨される使用方法

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

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

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

データ移行には、COPY INTOまたはFabric Data Factoryを使ってウェアハウスにデータを取り込む必要があります。

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

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

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

ソース管理の詳細については、「 開発および展開の概要」をご覧ください。

推奨される使用方法

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

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

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

データ移行は COPY INTO かData Factoryのいずれかでウェアハウスに取り込みます。

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

SQL Database プロジェクトの詳細については、「 SQL Database Projects 拡張機能の概要 」および 「コマンド ラインからデータベース プロジェクトをビルドする」を参照してください。

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

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

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

• ADLS にデータを抽出します。
  • このオプションでは、ユーザーがデータを取り込む前に倉庫内でスキーマ(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 でできることは以下のとおりです。

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

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

推奨される使用方法

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

Microsoft Fabric Data Warehouseのdbtアダプターは、Synapse専用SQLプール、Snowflake、Databricks、Google Big Query、Amazon Redshiftなど異なるプラットフォームを対象にしていた既存のdbtプロジェクトを、単純な設定変更でウェアハウスに移行できるようにします。

Fabric Data WarehouseをターゲットにしたDBTプロジェクトの始め方は、「チュートリアル:Fabric Data WarehouseのためのDBTを設定する」をご覧ください。 このドキュメントでは、異なるウェアハウスやプラットフォーム間を移動するオプションも示します。

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