Synapse POC プレイブック: Azure Synapse Analytics での Apache Spark プールを使用したビッグ データ分析

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

POC を準備する

Azure Synapse の Apache Spark プールを活用した、ビッグ データと高度な分析のための環境をクラウドベースのプラットフォームに導入する際は、確かな情報に基づく経営判断の拠り所として POC プロジェクトが役立ちます。

POC プロジェクトでは、クラウドベースのビッグ データと高度な分析プラットフォームでサポートする必要がある主要な目標とビジネス ドライバーを特定します。 主要なメトリックをテストして、Data Engineering、機械学習モデルの構築、トレーニング要件の成功に不可欠である主要な動作を実証します。 POC は、運用環境へのデプロイを意図したものではありません。 むしろ、重要な問題に焦点を当てた短期的なプロジェクトであり、その結果は破棄できます。

Spark POC プロジェクトの計画を開始する前に、次の手順を実行します。

POC プロジェクトの準備を開始する前に、まず Apache Spark のドキュメントに目を通しておくことをお勧めします。

ここまでで即時の阻害要因はないと判断しており、続いて POC の準備を始めることができます。 Azure Synapse Analytics で Apache Spark プールを初めて使用する場合は、このドキュメントを参照して、Spark アーキテクチャの概要を確認し、Azure Synapse での動作を把握できます。

次の主要な概念について理解を深めます。

• Apache Spark とその分散アーキテクチャ。
• Resilient Distributed Datasets (RDD) やパーティション (メモリ内および物理) などの Spark の概念。
• Azure Synapse ワークスペース、さまざまなコンピューティング エンジン、パイプライン、監視。
• Spark プールでの計算とストレージの分離。
• Azure Synapse での認証と認可。
• Azure Synapse 専用 SQL プールや Azure Cosmos DB などと統合するネイティブ コネクタ。

Azure Synapse では、データ処理のニーズをより適切に管理し、コストを制御できるように、コンピューティング リソースをストレージから切り離します。 Spark プールのサーバーレス アーキテクチャを使用すると、ストレージに関係なく、Spark クラスターの開始と停止のほか、拡張と縮小を行えます。 Spark クラスターを完全に一時停止 (または自動一時停止) できます。 そうすることで、コンピューティングを使用しているときにのみ料金を支払うことになります。 使用されていないときには、ストレージに対してのみ料金を支払います。 大量のデータ処理ニーズや大きな負荷に対応するために Spark クラスターをスケールアップし、あまり負荷の高くない処理時間中には元どおりスケールダウン (または完全にシャットダウン) できます。 効果的にクラスターをスケーリングおよび一時停止して、コストを削減できます。 Spark POC テストには、さまざまなスケール (小、中、大) でのデータ インジェストとデータ処理が含まれ、さまざまなスケールで価格とパフォーマンスが比較されます。 詳細については、「Azure Synapse Analytics Apache Spark プールの自動スケーリング」を参照してください。

さまざまな Spark API セットの違いを理解して、自分のシナリオに最適に機能するものを特定できるようにすることが重要です。 優れたパフォーマンスや使いやすさを提供するものを選択でき、チームの既存のスキル セットを活かせます。 詳細については、3 つの Apache Spark API (RDD、DataFrame、データセット) の物語に関するページを参照してください。

Spark では、データとファイルのパーティション分割が若干異なって機能します。 違いを理解することは、パフォーマンスの最適化に役立ちます。 詳細については、パーティション検出とパーティション構成オプションに関する Apache Spark のドキュメントを参照してください。

目標を設定する

POC プロジェクトの成功には計画が必要です。 まず、実際の目的を完全に把握するために POC を実施する理由を明らかにしましょう。 最新化、コスト削減、パフォーマンスの向上、統合されたエクスペリエンスなどの目的が考えられます。 POC の明確な目標と、その成功の定義となる基準を必ず文書化してください。 次のことを確認してください。

POC は、限られた一連の概念と機能を迅速に証明するための短く集中した取り組みである必要があることに注意してください。 これらの概念と機能は、全体的なワークロードを代表するものであることが必要です。 証明すべき項目が多い場合は、複数の POC を計画することをお勧めします。 その場合は、次の POC に進むべきかどうかを判断するためのゲートを POC 間に定義してください。 Azure Synapse で Spark プールとノートブックを使用する可能性があるさまざまなプロフェッショナル ロールがある場合、複数の POC を実行することもできます。 たとえば、ある POC では、インジェストや処理など、Data Engineering ロールの要件に焦点を当てることができます。 別の POC では、機械学習 (ML) モデルの開発に重点を置くことができます。

POC の目標を検討するときは、次のような質問を自分に投げかけ、目標の形成に役立てましょう。

POC 目標設定の例を次に示します。

• POC を実施する理由
  • ビッグ データ ワークロードのデータ インジェストと処理パフォーマンスが新しい SLA を満たすかどうかを把握する必要があります。
  • ほぼリアルタイムのストリーム処理が可能かどうか、およびどれくらいのスループットをサポートできるかを把握する必要があります。 (ビジネス要件をサポートしますか)。
  • 既存のデータ インジェストと変換プロセスが適切かどうか、およびどこで改善が必要かを把握する必要があります。
  • データ統合の実行時間を短縮できるかどうか、およびどのくらいの時間短縮できるかを把握する必要があります。
  • データ サイエンティストが機械学習モデルを構築してトレーニングし、必要に応じて Spark プールで AI/ML ライブラリを活用できるかどうかを把握する必要があります。
  • クラウドベースの Synapse Analytics への移行によって、コスト目標は達成されますか?
• この POC によって次のような成果が得られます。
  • データ処理のパフォーマンス要件をバッチ ストリーミングとリアルタイム ストリーミングの両方で満たすことができるかどうかを判断するデータが得られます。
  • ユース ケースをサポートするさまざまなデータ型 (構造化、半構造化、非構造化) のすべてのインジェストおよび処理がテストされます。
  • 既存の複雑なデータ処理の一部がテストされ、データ統合のポートフォリオを新しい環境に移行するために完了する必要がある作業を特定できます。
  • データ インジェストと処理がテストされ、履歴データの初期移行と読み込みに必要な労力を見積もり、データ インジェスト (Azure Data Factory (ADF)、Distcp、Databox など) の移行に必要な労力を見積もるためのデータ ポイントが得られます。
  • データ インジェストと処理がテストされ、ETL/ELT 処理要件を満たすことができるかどうかを判断できます。
  • 導入プロジェクトの遂行に必要な作業量の見積もりに役立つ分析情報が得られます。
  • スケールとスケーリングのオプションがテストされ、より良い価格 - パフォーマンス設定のためにプラットフォームをより適切に構成するためのデータ ポイントが得られます。
  • さらに詳しいテストが必要な項目のリストが得られます。

プロジェクトを計画する

実際の目標をもとに具体的なテストを見極め、明確な出力を規定しましょう。 それぞれの目標と期待される出力をサポートするために、必ず少なくとも 1 つのテストを用意することが大切です。 また、非常に限定的なデータセットとコードベースを識別できるように、特定のデータ インジェスト、バッチ処理またはストリーム処理、および実行されるその他すべてのプロセスを識別します。 この特定のデータセットとコードベースによって、POC のスコープが定義されます。

次の例は、計画に際してどの程度の具体性が必要かを示したものです。

• 目標 A: 定義された SLA の下で、バッチ データのデータ インジェストと処理に関する要件を満たすことができるかどうかを把握する必要があります。
• 出力 A: バッチ データ インジェストおよび処理がデータ処理要件と SLA を満たすことができるかどうかを判断するデータが得られます。
  • テスト A1: クエリ A、B、C の処理は、通常 Data Engineering チームによって実行されるため、優れたパフォーマンス テストとみなされます。 また、これらは全体的なデータ処理のニーズを表します。
  • テスト A2: クエリ X、Y、Z の処理は、ほぼリアルタイムのストリーム処理要件を含んでいるため、優れたパフォーマンス テストとみなされます。 また、これらは全体的なイベントベースのストリーム処理のニーズを表します。
  • テスト A3: Spark クラスターのさまざまなスケール (ワーカー ノードの数、ワーカー ノードのサイズ (小、中、大など)、Executor の数とサイズが異なる) でのこれらのクエリのパフォーマンスと、既存のシステムから取得したベンチマークとを比較します。 収穫逓減の法則に留意してください。リソースの追加 (スケールアップによるかスケールアウトによる) は並列処理の実現に役立ちますが、並列処理を実現する各シナリオには固有の制限があります。 テストでは識別されたユース ケースごとに最適な構成を検出します。
• 目標 B: データ サイエンティストがこのプラットフォームで機械学習モデルを構築してトレーニングできるかどうかを把握する必要があります。
• 出力 B: Spark プールまたは SQL プール内のデータに関するトレーニングを行い、さまざまな機械学習ライブラリを利用することで、機械学習モデルの一部をテストします。 これらのテストは、新しい環境に移行できる機械学習モデルの特定に役立ちます
  • テスト B1: 特定の機械学習モデルがテストされます。
  • テスト B2: Spark に付属する基本機械学習ライブラリ (Spark MLLib) と、要件を満たすために Spark にインストールできる追加のライブラリ (scikit-learn など) をテストします。
• 目標 C: データ インジェストがテストされ、次のためのデータ ポイントが得られます。
  • データ レイクまたは Spark プール、あるいはその両方に初期履歴データを移行する作業を見積もる。
  • 履歴データを移行する方法を計画する。
• 出力 C: 環境で達成可能なデータ インジェスト レートがテストされ決定されると、使用可能な時間枠の間に履歴データを移行するのにデータ インジェスト レートが十分かどうかを判断できます。
  • テスト C1: 履歴データ移行のさまざまな方法をテストします。 詳細については、「Azure との間でのデータの転送」を参照してください。
  • テスト C2: ExpressRoute の割り当てられた帯域幅と、インフラストラクチャ チームにより帯域幅調整がセットアップされているかどうかを特定します。 詳細については、「Azure ExpressRoute とは (帯域幅のオプション)」を参照してください。
  • テスト C3: オンラインとオフラインの両方のデータ移行のデータ転送速度をテストします。 詳細については、コピー アクティビティのパフォーマンスとスケーラビリティに関するガイドを参照してください。
  • テスト C4: ADF、Polybase、または COPY コマンドを使用して、データ レイクから SQL プールへのデータ転送をテストします。 詳細については、「Azure Synapse Analytics の専用 SQL プールのデータ読み込み戦略」を参照してください。
• 目標 D: 増分データ読み込みのデータ インジェスト率をテストし、データ レイクや専用の SQL プールへのデータ インジェストおよび処理の時間枠を推定するためのデータ ポイントが得られます。
• 出力 D: データ インジェスト率をテストし、特定されたアプローチでデータ インジェストと処理の要件を満たすことができるかどうかを判断できます。
  • テスト D1: 毎日の更新データ インジェストと処理をテストします。
  • テスト D2: Spark プールから専用の SQL プール テーブルへの処理済みデータの読み込みをテストします。 詳細については、「Apache Spark 用の Azure Synapse 専用 SQL プール コネクタ」を参照してください。
  • テスト D3: エンド ユーザー クエリの実行中に、毎日の更新読み込みプロセスを同時に実行します。

必ず複数のテスト シナリオを追加して、テストを調整してください。 Azure Synapse を使用すると、さまざまなスケール (ワーカー ノードの数、小、中、大などのワーカー ノードのサイズが異なる) を簡単にテストして、パフォーマンスと動作を比較できます。

次にテスト シナリオをいくつか示します。

• Spark プールのテスト A: 複数のノード タイプ (小、中、大) と、さまざまな数のワーカー ノードにわたりデータ処理を実行します。
• Spark プールのテスト B:コネクタを使用して、処理されたデータを Spark プールから専用の SQL プールに読み込んだり取得したりします。
• Spark プールのテスト C: Azure Synapse Link を使用して、処理されたデータを Spark プールから Azure Cosmos DB に読み込んだり取得したりします。

POC データセットを評価する

実際に洗い出したテストを使用して、それをサポートするデータセットを選択します。 このデータセットは慎重に確認してください。 そのデータセットが内容、複雑さ、規模の点で、将来の処理を適切に表現できることを確かめる必要があります。 小さすぎるデータセット (1 TB 未満) は、代表的なパフォーマンスが得られないため使用しないでください。 逆に、大きすぎるデータセットも、POC が完全なデータ移行になってしまうので使用を避けます。 パフォーマンス比較に使用できるように、必ず既存のシステムから適切なベンチマークを取得してください。

アーキテクチャの全体像を形成する

将来どのようなアーキテクチャにするかという計画の全体像に基づいて、POC の構成要素となるコンポーネントを洗い出します。 大まかなアーキテクチャの将来像には、多くのデータ ソースとデータ コンシューマー、ビッグ データ コンポーネント、場合によっては機械学習と人工知能 (AI) データ コンシューマーが含まれていることも考えられます。 POC アーキテクチャでは、POC に属するコンポーネントを具体的に洗い出す必要があります。 特に、POC テストの構成要素ではないコンポーネントを明確にすることが大切です。

既に Azure を使用している場合は、既に導入されているリソースのうち、POC の期間中に使用することができるリソース (Microsoft Entra ID、ExpressRoute など) を特定します。 また、自分の組織が使用する Azure リージョンも特定します。 ExpressRoute 接続のスループットを把握し、その一部を POC が使用することによって運用環境のシステムに悪影響が生じることがないか、他のビジネス ユーザーに確認する良い機会です。

詳細については、「ビッグ データ アーキテクチャ」を参照してください。

POC のリソースを洗い出す

POC をサポートするために必要な技術的リソースと時間的コミットメントを具体的に特定します。 以下はその例です。

• 要件と結果を監督するビジネス代表者。
• POC に使用するデータを調達し、既存のプロセスとロジックに関する知識を提供するアプリケーション データ エキスパート。
• Apache Spark と Spark プールのエキスパート。
• POC テストを最適化するエキスパート アドバイザー。
• POC プロジェクトの特定のコンポーネントに必要なリソース (POC の実施期間中、必ずしも必須ではないもの)。 たとえば、ネットワーク管理者、Azure 管理者、Active Directory 管理者、Azure portal 管理者が挙げられます。
• 必要な Azure サービス リソースがすべてプロビジョニングされ、必要なレベルのアクセス権が付与されていること (ストレージ アカウントへのアクセス権など)。
• POC の作業範囲に含まれるすべてのデータ ソースからデータを取得するために必要なデータ アクセス権があるアカウント。

タイムラインを設定する

POC にかかる概算時間を見極めるために、POC 計画の詳細とビジネス ニーズを確認します。 POC の目標を達成するために必要な時間は現実的に見積もってください。 POC の所要時間は、POC データセットのサイズ、テストの数と複雑さ、テストするインターフェイスの数に左右されます。 POC の実行時間が 4 週間を超えると思われる場合は、その作業範囲を絞り込んで、優先度が最も高い目標のみに焦点を当てることを検討してください。 必ず主立ったリソースとスポンサー全員から承認と確約を得たうえで続行してください。

POC を実践する

運用プロジェクトの規範と厳格さを備えた POC プロジェクトを遂行することをお勧めします。 POC の作業範囲が拡大して手に負えなくなってしまう事態を防ぐため、プロジェクトは計画に従って実行し、変更要求プロセスを管理してください。

大まかなタスクの例をいくつか次に示します。

1. Synapse ワークスペース、Spark プールおよび専用 SQL プール、ストレージ アカウント、POC プランで識別されたすべての Azure リソースを作成します。

2. POC データセットを読み込みます。

   • ソースから抽出するか、Azure でサンプル データを作成して、データを Azure で使用できるようにします。 詳細については、次を参照してください。
     • Azure との間のデータ転送
     • Azure Data Box
     • コピー アクティビティのパフォーマンスとスケーラビリティに関するガイド
     • Azure Synapse Analytics の専用 SQL プールのデータ読み込み戦略
     • COPY ステートメントを使用してデータを一括読み込みする
   • Spark プールと専用 SQL プールの専用コネクタをテストします。

3. 既存のコードを Spark プールに移行します。

   • Spark から移行する場合、Spark プールでオープンソースの Spark ディストリビューションを利用していれば移行作業はおそらく簡単になります。 ただし、Spark のコア機能に加えてベンダー固有の機能を使用している場合は、これらの機能を Spark プールの機能に正しくマップする必要があります。
   • Spark 以外のシステムから移行する場合、移行作業は関与する複雑さに応じて異なります。

4. テストを実行します。

   • 多くのテストは、複数の Spark プール クラスター間で並列して実行できます。
   • 利用しやすくわかりやすい形式で結果を記録します。

5. トラブルシューティングとパフォーマンスのための監視を行います。 詳細については、次を参照してください。

   • Apache Spark アクティビティを監視する
   • Web ユーザー インターフェイスを使用した監視 - Spark の履歴サーバー
   • Azure Synapse Analytics でのリソース使用状況とクエリ アクティビティの監視

6. Spark の履歴サーバーの [診断] タブを開いて、データの歪度、時間の歪度、Executor の使用率を監視します。

   

POC の結果を解釈する

すべての POC テストが完了したら、その結果を評価します。 まず、POC の目標が満たされ、目的の出力が収集されたかどうかを評価します。 さらに詳しいテストが必要か、または対処すべき問題があるかどうかを判断します。

次の手順