移行: Azure Synapse Analytics 専用 SQL プールから Fabric へ

[アーティクル]
04/24/2024

適用対象: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. 目的と動機を明らかにします。期待する成果を明確にしておきます。
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 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 個です。

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

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

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

推奨される用途

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

次のコードサンプルでは、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) のみが返されます。

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

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

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

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

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

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

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

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

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

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

推奨される用途

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

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

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

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

SQL Database Project を使用して移行する

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

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

推奨される用途

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

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

スキーマ (DDL) を Fabric Warehouse 構文に変換します。
Fabric Warehouse でスキーマ (DDL) を作成します。
Synapse 専用 SQL プールから ADLS にデータを抽出します。
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 でできることは以下のとおりです。

スキーマ (DDL) を Fabric Warehouse 構文に変換します。
Fabric Warehouse でスキーマ (DDL) を作成します。
データベースコード (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 のワークロード管理では、負荷とクエリに割り当てるリソースは分離されます。クエリとデータの読み込みが同時に実行されても、リソースの競合は発生しません。

Share via

移行: Azure Synapse Analytics 専用 SQL プールから Fabric へ

移行の概要

移行を準備する

移行用のランブック