Synapse POC プレイブック: Azure Synapse Analytics のサーバーレス SQL プールを使用したデータ レイク探索
この記事では、サーバーレス SQL プール用の効果的な Azure Synapse Analytics 概念実証 (POC) プロジェクトを準備して実行するための手法を示します。
注意
この記事は、''Azure Synapse 概念実証プレイブック'' シリーズの記事の一部です。 シリーズの概要については、「Azure Synapse 概念実証プレイブック」を参照してください。
POC を準備する
Azure Synapse のサーバーレス SQL プールを活用した、ビッグ データと高度な分析のための環境をクラウドベースのプラットフォームに導入する際は、経営判断の拠り所として POC プロジェクトが役立ちます。 データ レイク内のデータを探索したり、そこから分析情報を得たり、既存のデータ変換パイプラインを最適化したりする必要がある場合は、サーバーレス SQL プールを活用することができます。 これは、次のシナリオに適しています。
- 基本の検出と探索: データ レイク内にさまざまな形式 (Parquet、CSV、JSON) で格納されたデータをすばやく把握し、そこから分析情報を発掘する方法を計画することができます。
- 論理データ ウェアハウス: データの再配置や変換を行うことなく、生の、つまり雑多なデータに基づいてリレーショナル抽象化を行うことで常に最新のデータを表示します。
- データ変換: T-SQL を使用して、単純でスケーラブル、かつハイパフォーマンスのデータ レイク クエリを実行します。 クエリの結果をビジネス インテリジェンス (BI) ツールに取り込んだり、それらをリレーショナル データベースに読み込んだりすることができます。 Azure Synapse 専用 SQL プールや Azure SQL Database などのシステムが対象となります。
サーバーレス SQL プールは、さまざまな職務の役に立ちます。
- データ エンジニアは、サーバーレス SQL プールを使用してレイクの探索、データの変換、準備を行えるほか、データ変換パイプラインを簡素化できます。
- データ科学者は、T-SQL 関数の OPENROWSET やその自動スキーマ推論を利用して、データ レイクに格納されたデータの内容と構造を迅速に把握することができます。
- データ アナリストは好きなクエリ ツールで T-SQL クエリを作成して、サーバーレス SQL プールに接続できます。 データ科学者やデータ エンジニアによって作成された Spark 外部テーブル内のデータを探索できます。
- BI プロフェッショナルは、データ レイクや Spark テーブルに接続する Power BI レポートをすばやく作成できます。
サーバーレス SQL プールの POC プロジェクトでは、サーバーレス SQL プールの設計がサポートする主要な目標とビジネス ドライバーが明らかになります。 また導入の判断を裏付けるために、主な機能がテストされ、メトリックが収集されます。 POC は、運用環境へのデプロイを意図したものではありません。 むしろ、重要な問題に焦点を当てた短期的なプロジェクトであり、その結果は破棄できます。
サーバーレス SQL プールの POC プロジェクト計画に着手する前に、次の作業を行います。
- クラウドへのデータの移動に関して組織が定める制限やガイドラインを明らかにします。
- ビッグ データと高度な分析プラットフォーム プロジェクトを支持する経営幹部やビジネス スポンサーを特定します。 クラウドへの移行に向けてその支持を取り付けてください。
- POC を遂行する過程で自分をサポートしてくれる技術のエキスパートやビジネス ユーザーの有無を確認します。
POC プロジェクトの準備を開始する前に、まずサーバーレス SQL プールのドキュメントに目を通しておくことをお勧めします。
ヒント
サーバーレス SQL プールを初めて使用する場合は、「Azure Synapse サーバーレス SQL プールを使用して Data Analytics ソリューションを構築する」のラーニング パスに従うことをお勧めします。
目標を設定する
POC プロジェクトの成功には計画が必要です。 まず、実際の目的を完全に把握するために POC を実施する理由を明らかにしましょう。 最新化、コスト削減、パフォーマンスの向上、統合されたエクスペリエンスなどの目的が考えられます。 POC の明確な目標と、その成功の定義となる基準を必ず文書化してください。 次のことを確認してください。
- POC の出力として何が必要か。
- それらの出力を使って何をするか。
- その出力をだれが使用するか。
- 何をもって POC の成功とするか。
POC は、限られた一連の概念と機能を迅速に証明するための短く集中した取り組みである必要があることに注意してください。 これらの概念と機能は、全体的なワークロードを代表するものであることが必要です。 証明すべき項目が多い場合は、複数の POC を計画することをお勧めします。 その場合は、次の POC に進むべきかどうかを判断するためのゲートを POC 間に定義してください。 サーバーレス SQL プールを使用する可能性のある専門家の役割が異なる (また、サーバーレス SQL プールでサポートされるシナリオも異なる) ことを踏まえると、複数の POC を実施した方がよいでしょう。 たとえば、ある POC では、形式が異なるデータの検出や探索など、データ科学者ロールの要件に焦点を当てます。 また別の POC では、データ変換や論理データ ウェアハウスの作成など、データ エンジニアリング ロールの要件に重点を置きます。
POC の目標を検討するときは、次のような質問を自分に投げかけ、目標の形成に役立てましょう。
- ビッグ データと高度な分析を行う既存のプラットフォーム (オンプレミスまたはクラウド) から移行するか。
- 移行するが、既存のインジェスト処理やデータ処理への変更は可能な限り少なくしたい、という希望はあるか。
- 移行するが、その過程でいくつかの広範な改善を考えているか。
- ビッグ データと高度な分析のためのまったく新しいプラットフォーム (グリーンフィールド プロジェクト) を構築するか。
- 現在困っていることは何か。 たとえば、スケーラビリティ、パフォーマンス、柔軟性が考えられます。
- 新たにサポートすべきビジネス要件は何か。
- 満たすべき SLA はどのようなものか。
- ワークロードは何か。 たとえば、さまざまなデータ形式を対象としたデータ探索、基本的な探索、論理データ ウェアハウス、データ準備と変換、T-SQL インタラクティブ分析、Spark テーブルの T-SQL クエリ、データ レイクを対象としたレポート クエリが挙げられます。
- プロジェクトを所有するユーザーは、どのようなスキルを備えているか (POC を実施すべきか)。
POC 目標設定の例を次に示します。
- POC を実施する理由
- サーバーレス SQL プールを使用して生のファイル形式をすべて探索できるのかどうかを知る必要がある。
- データ エンジニアが新しいデータ フィードをすばやく評価できるかどうかを知る必要がある。
- サーバーレス SQL プールを使用したデータ レイクのクエリ パフォーマンスが、実際のデータ探索要件を満たすかどうかを知る必要がある。
- 実際の可視化とレポートの要件に対してサーバーレス SQL プールが正しい選択かどうかを知る必要がある。
- 実際のデータ インジェストとデータ処理の要件に対してサーバーレス SQL プールが正しい選択かどうかを知る必要がある。
- Azure Synapse への移行が予算の範囲内で収まるかどうかを知る必要がある。
- この PoC によって次のような成果が得られます。
- サーバーレス SQL プールに適したデータ変換を見極めるためのデータが得られます。
- データを可視化する過程でサーバーレス SQL プールを使用するベストなタイミングを見極めるためのデータが得られます。
- どの程度簡単にデータ エンジニアとデータ科学者が新しいプラットフォームを導入できるかを把握するためのデータが得られます。
- 導入または移行プロジェクトの遂行に必要な作業量の見積もりに役立つ分析情報が得られます。
- さらに詳しいテストが必要な項目のリストが得られます。
- ビッグ データと高度な分析のためのクラウドベースのプラットフォームを、サーバーレス SQL プールがどのようにサポートするかを見極めるために必要なデータが得られ、そして特定されたテストが完了すれば、POC は成功です。
- 次のフェーズに進むことができるのか、または最終的な決断を下すためにさらなる POC テストが必要なのかの判断ができます。
- 具体的なデータ ポイントによって裏付けられた正しい経営判断を下すことができます。
プロジェクトを計画する
実際の目標をもとに具体的なテストを見極め、明確な出力を規定しましょう。 それぞれの目標と期待される出力をサポートするために、必ず少なくとも 1 つのテストを用意することが大切です。 また、データ探索と分析タスク、変換、テストする既存の処理を具体的に特定します。 使用できる具体的なデータセットとコードベースを洗い出してください。
次の例は、計画に際してどの程度の具体性が必要かを示したものです。
- 目標: "Daily Batch Raw File Validation (生ファイルの日次バッチ検証)" という名前の既存の ETL プロセスと同等の処理をデータ エンジニアが必要な SLA 内で達成できるかどうかを把握する。
- 出力: T-SQL クエリを使用し、必要な SLA 内で "Daily Batch Raw File Validation (生ファイルの日次バッチ検証)" ETL プロセスを実行できるかどうかを判断するためのデータを得る。
- テスト: 検証クエリ A、B、C は、データ エンジニアリングによって特定されたもので全体的なデータ処理ニーズを表す。 これらのクエリのパフォーマンスを、既存のシステムから得たベンチマークと比較します。
POC データセットを評価する
実際に洗い出したテストを使用して、それをサポートするデータセットを選択します。 このデータセットは慎重に確認してください。 そのデータセットが内容、複雑さ、規模の点で、将来の処理を適切に表現できることを確かめる必要があります。 小さすぎるデータセットは、代表的なパフォーマンスが得られないため使用しないでください。 逆に、大きすぎるデータセットも、POC が完全なデータ移行になってしまうので使用を避けます。 パフォーマンス比較に使用できるように、必ず既存のシステムから適切なベンチマークを取得してください。
重要
データをクラウドに移動する前に、必ずブロッカーがないか、ビジネス オーナーに確認してください。 クラウドにデータを移動する前に行う必要がある、セキュリティやプライバシーに関する懸念事項またはデータ難読化のニーズを特定します。
アーキテクチャの全体像を形成する
将来どのようなアーキテクチャにするかという計画の全体像に基づいて、POC の構成要素となるコンポーネントを洗い出します。 大まかなアーキテクチャの将来像には、多くのデータ ソースとデータ コンシューマー、ビッグ データ コンポーネント、場合によっては機械学習と人工知能 (AI) データ コンシューマーが含まれていることも考えられます。 POC アーキテクチャでは、POC に属するコンポーネントを具体的に洗い出す必要があります。 特に、POC テストの構成要素ではないコンポーネントを明確にすることが大切です。
既に Azure を使用している場合は、既に導入されているリソースのうち、POC の過程で使用できるリソース (Microsoft Entra ID、ExpressRoute など) を特定してください。 また、自分の組織が使用する Azure リージョンも特定します。 ExpressRoute 接続のスループットを把握し、その一部を POC が使用することによって運用環境のシステムに悪影響が生じることがないか、他のビジネス ユーザーに確認する良い機会です。
POC のリソースを洗い出す
POC をサポートするために必要な技術的リソースと時間的コミットメントを具体的に特定します。 以下はその例です。
- 要件と結果を監督するビジネス代表者。
- POC に使用するデータを調達し、既存のプロセスとロジックに関する知識を提供するアプリケーション データ エキスパート。
- サーバーレス SQL プールのエキスパート。
- POC テストを最適化するエキスパート アドバイザー。
- POC プロジェクトの特定のコンポーネントに必要なリソース (POC の実施期間中、必ずしも必須ではないもの)。 たとえば、ネットワーク管理者、Azure 管理者、Active Directory 管理者、Azure portal 管理者が挙げられます。
- 必要な Azure サービス リソースがすべてプロビジョニングされ、必要なレベルのアクセス権が付与されていること (ストレージ アカウントへのアクセス権など)。
- POC の作業範囲に含まれるすべてのデータ ソースからデータを取得するために必要なデータ アクセス権があるアカウント。
ヒント
エキスパート アドバイザーに POC の支援を依頼することをお勧めします。 Microsoft のパートナー コミュニティには、Azure Synapse の評価や実装に役立つ場合があるグローバル対応のエキスパート コンサルタントが存在します。
タイムラインを設定する
POC にかかる概算時間を見極めるために、POC 計画の詳細とビジネス ニーズを確認します。 POC の目標を達成するために必要な時間は現実的に見積もってください。 POC の所要時間は、POC データセットのサイズ、テストの数と複雑さ、テストするインターフェイスの数に左右されます。 POC の実行時間が 4 週間を超えると思われる場合は、その作業範囲を絞り込んで、優先度が最も高い目標のみに焦点を当てることを検討してください。 必ず主立ったリソースとスポンサー全員から承認と確約を得たうえで続行してください。
POC を実践する
運用プロジェクトの規範と厳格さを備えた POC プロジェクトを遂行することをお勧めします。 POC の作業範囲が拡大して手に負えなくなってしまう事態を防ぐため、プロジェクトは計画に従って実行し、変更要求プロセスを管理してください。
大まかなタスクの例をいくつか次に示します。
- POC 計画で特定した Synapse ワークスペース、ストレージ アカウント、Azure リソースを作成します。
- 要件に応じて、ネットワークとセキュリティを設定します。
- POC チーム メンバーに適切なアクセス権を付与します。 Azure Storage のファイルに直接アクセスするための権限については、こちらの記事を参照してください。
- POC データセットを読み込みます。
- テストを実装して構成するか、既存のコードをサーバーレス SQL プールのスクリプトとビューに移行します。
- テストを実行します。
- 多数のテストを並列に実行できます。
- 利用しやすくわかりやすい形式で結果を記録します。
- トラブルシューティングとパフォーマンスのための監視を行います。
- 結果を評価し、到達した結論を提示します。
- 技術関係者や業者と協力して、プロジェクトの次のステージに備えた計画を立てます。 たとえば、フォローアップ POC や運用環境への導入が次のステージとなります。
POC の結果を解釈する
すべての POC テストが完了したら、その結果を評価します。 まず、POC の目標が満たされ、目的の出力が収集されたかどうかを評価します。 さらに詳しいテストが必要か、または対処すべき問題があるかどうかを判断します。