Synapse POC プレイブック: Azure Synapse Analytics の専用 SQL プールを使用したデータ ウェアハウス

この記事では、専用 SQL プール用の効果的な Azure Synapse Analytics 概念実証 (POC) プロジェクトを準備して実行するための手法を示します。

POC を準備する

Azure Synapse POC の目標を決定する前に、まず「Azure Synapse SQL アーキテクチャ」の記事を読み、業界をリードするパフォーマンスを提供するために専用 SQL プールでコンピューティングとストレージを分離する方法についてよく理解しておくことをお勧めします。

スポンサーと潜在的なブロッカーを特定する

Azure Synapse についてよく理解したら、POC に必要なサポートがあり、障害がないことを確認します。 次の手順に従います。

• クラウドへのデータの移動と格納に関する組織の制限やポリシーを特定します。
• クラウドベースのデータ ウェアハウス プロジェクトのエグゼクティブおよびビジネス スポンサーシップを特定します。
• ワークロードが Azure Synapse に適していることを確認します。 詳細については、Azure Synapse Analytics の専用 SQL プール アーキテクチャに関するページを参照してください。

タイムラインを設定する

POC は、特定の測定可能な目標と、成功を定義するメトリックを使用するスコープ付きの期限がある演習です。 理想的には、結果が意味を持つようにビジネスの実体に何らかの基礎がある必要があります。

POC では、''タイムボックス化'' されている場合に最適な結果が得られます。 タイムボックス化では、一定の最大時間単位がアクティビティに割り当てられます。 経験上、多すぎるユース ケースや複雑なテスト マトリックスの負担なく、作業を完了するのに 2 週間あれば十分です。 この一定期間内に作業する場合は、次のタイムラインに従うことをお勧めします。

1. データ読み込み: 3 日以内
2. クエリ実行: 5 日以内
3. 付加価値テスト: 2 日以内

いくつかのヒントを次に示します。

緊急の障害がないと判断し、タイムラインを設定したら、大まかなアーキテクチャのスコープを設定できます。

大まかなスコープ付きアーキテクチャを作成する

将来の大まかなアーキテクチャには、多くのデータ ソースとデータ コンシューマー、ビッグ データ コンポーネント、場合によっては機械学習と AI データ コンシューマーが含まれている可能性があります。 POC の目標を達成可能な状態 (および設定したタイムラインの境界内) に保つために、これらのコンポーネントのうちどれが POC の一部を形成し、どれを除外するかを決定します。

さらに、既に Azure を使用している場合は、以下を特定します。

• POC 中に使用できる既存の Azure リソース。 たとえば、リソースには Microsoft Entra ID や Azure ExpressRoute を含めることができます。
• 組織が望む Azure リージョン。
• 非運用 POC 作業に使用できるサブスクリプション。
• Azure へのネットワーク接続のスループット。

  重要

  運用ソリューションに悪影響を及ぼすことなく、POC でそのスループットの一部を使用できることを必ず確認してください。

移行オプションを適用する

従来のデータ ウェアハウス システムから Azure Synapse に移行する場合に、考慮すべきいくつかの質問を以下に示します。

• 移行し、既存の抽出、変換、読み込み (ETL) プロセスとデータ ウェアハウスの使用に対する変更をできるだけ少なくしたいと考えていますか?
• 移行するが、その過程でいくつかの広範な改善を行いたいと考えていますか?
• まったく新しいデータ分析環境 (''グリーンフィールド プロジェクト'' ともいう) を構築しますか?

次に、問題点を考慮する必要があります。

現在の問題点を特定する

POC には、現在の問題点に対処するために考えられる解決策を証明するユース ケースが含まれている必要があります。 考慮すべきいくつかの質問を次に示します。

• Azure Synapse によって埋められることが予想される現在の実装のギャップは何ですか?
• どのような新しいビジネス ニーズをサポートする必要がありますか?
• どのようなサービス レベル アグリーメント (SLA) を満たす必要がありますか?
• ワークロード (ETL、バッチ クエリ、分析、レポート クエリ、対話型クエリなど) は何ですか?

次に、POC の成功基準を設定する必要があります。

POC の成功基準を設定する

POC を行う理由を特定し、必ず明確な目標を定義してください。 また、POC からどのような出力が必要であるかと、その出力に対して何を行う予定なのかを知ることも重要です。

POC は、限られた一連の概念を迅速に証明またはテストするための短く集中した取り組みである必要があることに注意してください。 証明する項目の長いリストがある場合は、それらを複数の POC に分けることができます。 POC の間にゲートを設定できるため、次の POC に進むかどうかを判断できます。

POC の目標の例をいくつか以下に示します。

• 大規模で複雑なレポート クエリのクエリ パフォーマンスが新しい SLA を満たすことを知る必要がある。
• 対話型ユーザーのクエリ パフォーマンスを知る必要がある。
• 既存の ETL プロセスが適切かどうか、および改善が必要な場所を知る必要がある。
• ETL ランタイムを短縮できるかどうか、およびどのくらい短縮できるかを知る必要がある。
• Synapse Analytics には、データを適切にセキュリティで保護するための十分なセキュリティ機能があることを知る必要がある。

次に、テスト計画を作成する必要があります。

テスト計画の作成

目標を使用して、それらの目標をサポートし、特定した出力を提供するために実行する特定のテストを特定します。 各目標と予想される出力に対して、少なくとも 1 つのテストがあることを確認することが重要です。 定量化可能な結果を提供するために実行する特定のクエリ、レポート、ETL およびその他のプロセスを特定します。

複数のテスト シナリオを追加してテストを調整し、発生したテーブル構造の質問を明確にします。

適切に計画すれば、通常は効果的な POC 実行を定義することができます。 すべての利害関係者が、各 POC 目標を明確に示された一連のテスト ケースと成功の測定値に結び付ける書面によるテスト計画に同意していることを確認してください。

ほとんどのテスト計画は、パフォーマンスと予想されるユーザー エクスペリエンスを中心に展開されています。 テスト計画の例を以下に示します。 ビジネス要件を満たすようにテスト計画をカスタマイズすることが重要です。 テスト対象を明確に定義しておけば、このプロセスの後半で役立ちます。

次に、POC データセットを特定して検証する必要があります。

POC データセットを特定して検証する

スコープ付きテストを使用して、Azure Synapse でこれらのテストを実行するために必要なデータセットを特定できるようになりました。 次の点を考慮して、データセットを確認します。

• コンテンツ、複雑さ、スケールの観点から、データセットが運用データセットを適切に表していることを確認します。
• 代表的なパフォーマンスが得られない可能性があるため、小さすぎる (1 TB 未満) データセットは使用しないでください。
• POC は完全なデータ移行を完了することを意図していないので、大きすぎるデータセットは使用しないでください。
• 各テーブルの分散パターン、インデックス作成オプション、パーティション分割を特定します。 分散、インデックス作成、またはパーティション分割に関する質問がある場合は、POC にテストを追加して回答します。 一部のテーブルに対して、複数の分散オプションまたはインデックス作成オプションをテストできることに注意してください。
• POC データセットをクラウドに移動する際にブロッカーがないか、ビジネス オーナーに確認します。
• セキュリティやプライバシーに関する懸念事項を特定します。

次に、エキスパートのチームを組む必要があります。

チームを組む

POC をサポートするためのチーム メンバーとそのコミットメントを特定します。 チーム メンバーには以下を含める必要があります。

• POC プロジェクトを実行するプロジェクト マネージャー。
• 要件と結果を監督するビジネス代表者。
• POC データセットのデータをソーシングするアプリケーション データ エキスパート。
• Azure Synapse スペシャリスト。
• POC テストを最適化するエキスパート アドバイザー。
• 特定の POC プロジェクト タスクに必要となるが、その期間全体では必要としない人。 これらのサポート リソースには、ネットワーク管理者、Azure 管理者、または Microsoft Entra 管理者が含まれる場合があります。

これで十分な準備ができたので、次は POC を実践します。

POC を実践する

次の点に注意することが重要です。

• 運用プロジェクトの規範と厳格さを備えた POC プロジェクトを実装します。
• 計画に従って POC を実行します。
• POC スコープの拡大または変更を防ぐために変更要求プロセスを準備しておきます。

テストを開始する前に、テスト環境を設定する必要があります。 これには次の 4 つのステージが含まれます。

1. セットアップ
2. データの読み込み
3. クエリ実行
4. 付加価値テスト

設定

これらの手順に従って、Azure Synapse で POC を設定できます。

1. このクイック スタートを使用して、Synapse ワークスペースをプロビジョニングし、POC テスト計画に従ってストレージとアクセス許可を設定します。
2. このクイック スタートを使用して、Synapse ワークスペースに専用 SQL プールを追加します。
3. 要件に応じて、ネットワークとセキュリティを設定します。
4. POC チーム メンバーに適切なアクセス権を付与します。 専用 SQL プールにアクセスするための認証と承認については、こちらの記事を参照してください。

データの読み込み

専用 SQL プールを設定したら、これらの手順に従ってデータを読み込むことができます。

1. Azure Blob Storage にデータを読み込みます。 POC の場合は、ローカル冗長ストレージ (LRS) で汎用 V2 ストレージ アカウントを使用することをお勧めします。 Azure Blob Storage にデータを移行するためのツールがいくつかありますが、最も簡単な方法は、ストレージ コンテナーにファイルをコピーできる Azure Storage Explorer を使用することです。
2. 専用 SQL プールにデータを読み込みます。 Azure Synapse では、PolyBase と COPY ステートメントという 2 つの T-SQL 読み込み方法がサポートされています。 SSMS を使って専用 SQL プールに接続し、いずれかの方法を使用できます。

専用 SQL プールに初めてデータを読み込む場合は、使用する分散パターンとインデックス オプションを検討する必要があります。 専用 SQL プールではいずれの場合もさまざまな方法がサポートされていますが、既定の設定に依存することをお勧めします。 既定の設定では、ラウンドロビン分散とクラスター化列ストア インデックスが使用されます。 必要に応じて、後でこれらの設定を調整できます。これについては、この記事で後述します。

次の例は COPY 読み込み方法を示しています。

--Note when specifying the column list, input field numbers start from 1
COPY INTO
    test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
    'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
    FILE_TYPE = 'CSV',
    CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
    FIELDQUOTE = '"',
    FIELDTERMINATOR = ',',
    ROWTERMINATOR = '0x0A',
    ENCODING = 'UTF8',
    FIRSTROW = 2
);

クエリ実行

データ ウェアハウスの主な目的は、データ ウェアハウスのクエリを実行する必要がある分析を行うことです。 ほとんどの POC ではまず、データ ウェアハウスに対して少数の代表的なクエリを最初に順番に実行してから同時に実行します。 両方の方法をテスト計画で定義する必要があります。

シーケンシャル クエリ テスト

SSMS でシーケンシャル クエリ テストを簡単に実行できます。 十分に大きなリソース クラスを持つユーザーを使用して、これらのテストを実行することが重要です。 リソース クラスは、クエリ実行のためにコンピューティング リソースとコンカレンシーを制御する専用 Synapse SQL プールの事前に決定されたリソース制限です。 単純なクエリの場合は、定義済みの staticrc20 リソース クラスを使用することをお勧めします。 より複雑なクエリの場合は、定義済みの staticrc40 リソース クラスを使用することをお勧めします。

次の最初のクエリではクエリ ラベルを使用して、クエリを追跡するためのメカニズムが提供されることに注目してください。 2 番目のクエリでは、sys.dm_pdw_exec_requests 動的管理ビューを使用して、ラベルごとに検索が行われます。

/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
    *
FROM
    [dbo].[Date]
OPTION (LABEL = 'Test1');

/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
    Total_elapsed_time AS [Elapsed_Time_ms],
    [label]
FROM
    sys.dm_pdw_exec_requests
WHERE
    [label] = 'Test1';

同時実行クエリ テスト

シーケンシャル クエリのパフォーマンスを記録した後、複数のクエリを同時に実行できます。 これにより、専用 SQL プールに対して実行されているビジネス インテリジェンス ワークロードをシミュレートできます。 このテストを実行する最も簡単な方法は、ストレス テスト ツールをダウンロードすることです。 最も一般的なツールは、サードパーティのオープンソース ツールである Apache JMeter です。

このツールでは、特定のコンカレンシー レベルの最小、最大、中央値のクエリ期間が報告されます。 たとえば、100 個の同時クエリを生成するビジネス インテリジェンス ワークロードをシミュレートするとします。 JMeter を設定して、ループ内で 100 個の同時実行クエリを実行してから、安定した状態の実行を確認できます。 結果セットのキャッシュをオンまたはオフにして、その機能の適合性を評価できます。

必ず結果を文書化してください。 いくつかの結果の例を以下に示します。

混合ワークロード テスト

混合ワークロード テストは、同時クエリ テストを拡張したものです。 混合ワークロードにデータ読み込みプロセスを追加することで、ワークロードでは実際の運用ワークロードがより適切にシミュレートされます。

データを最適化する

Azure Synapse で実行されているクエリ ワークロードによっては、データ ウェアハウスの分散とインデックスを最適化し、テストを再実行することが必要な場合があります。 詳細については、「Azure Synapse Analytics での専用 SQL プールのベスト プラクティス」を参照してください。

設定中に見られる最も一般的な間違いは次のとおりです。

• 低すぎるリソース クラスで大規模なクエリが実行されています。
• 専用 SQL プール サービス レベルの DWU がワークロードに対して低すぎます。
• 大きなテーブルにはハッシュ分散が必要です。

クエリのパフォーマンスを向上させるために、次のことを行うことができます。

• 具体化されたビューを作成します。これによって、一般的な集計を含むクエリを高速化できます。
• 特に小さなディメンション テーブルの場合は、テーブルをレプリケートします。
• 結合または集計される大きなファクト テーブルをハッシュ分散します。

付加価値テスト

クエリのパフォーマンス テストが完了したら、特定の機能をテストして、目的のユース ケースを満たしているかどうかを確認することをお勧めします。 次のような機能が含まれています。

• 行レベルのセキュリティ
• 列レベルのセキュリティ
• 動的データ マスク
• ワークロードの分離によるクラスター内スケーリング

最後に、POC の結果を解釈する必要があります。

POC の結果を解釈する

データ ウェアハウスのテスト結果が得られたら、そのデータを解釈することが重要です。 実行できる一般的な方法は、''価格/パフォーマンス'' の観点から実行を比較することです。 簡単に言えば、価格/パフォーマンスの場合、DWU またはサービス ハードウェアあたりの価格の差がなくなり、パフォーマンス テストごとに単一の同等の数が提供されます。

次に例を示します。

この例では、DWU1000 でのテスト 1 の場合、テスト実行あたり $3 と比較して、テスト実行あたり $2 の方がコスト効率が高いことがわかります。

つまり、すべての POC テストを完了すると、結果を評価する準備が整います。 まず、POC の目標が満たされ、目的の出力が収集されたかどうかを評価します。 追加のテストが保証される場所と、発生した追加の質問をメモしておいてください。

次の手順