Synapse 実装の成功手法: 環境を評価する
注意
この記事は、「設計による Azure Synapse 実装の成功」シリーズの記事の一部です。 このシリーズの概要については、設計による Azure Synapse 実装の成功に関する記事を参照してください。
Azure Synapse Analytics の実装での最初の手順は、環境を評価することです。 評価により、既存の環境、環境要件、プロジェクト要件、制約、タイムライン、問題点に関するすべての利用可能な情報を収集する機会が得られます。 この情報は、後の評価とチェックポイント アクティビティの基礎となります。 計画、設計、開発の際に、プロジェクト ソリューションに対して検証および比較するときになると、非常に重要であると証明されます。 すべての情報を収集し、関連するグループと必要なディスカッションを確実に行うために十分な時間を確保することをお勧めします。 関連するグループには、プロジェクトの利害関係者、ビジネス ユーザー、ソリューション デザイナー、既存のソリューションと環境の領域の専門家 (SME) を含めることができます。
この評価は、ソリューション設計の評価や、Azure Synapse を実装するための情報に基づいたテクノロジの推奨事項の作成に役立つガイドとなります。
ワークロード評価
ワークロード評価は、環境、分析ワークロード ロール、ETL/ELT、ネットワークとセキュリティ、Azure 環境、データ使用量に関係します。
環境
環境について、次の点を評価します。
- 既存の分析ワークロードについて説明します。
- どのようなワークロードですか (データ ウェアハウスやビッグ データなど)?
- このワークロードはビジネスにどのように役立ちますか? どのようなユース ケースのシナリオですか?
- この分析プラットフォームと潜在的な移行のビジネス ドライバーはどのようなものですか?
- 既存のアーキテクチャ、設計、実装の選択肢に関する詳細を収集します。
- 既存のすべてのアップストリームおよびダウンストリーム依存コンポーネントとコンシューマーに関する詳細を収集します。
- 既存のデータ ウェアハウス (Microsoft SQL Server、Microsoft Analytics Platform System (APS)、Netezza、Snowflake、Teradata など) を移行していますか?
- ビッグ データ プラットフォーム (Cloudera や Hortonworks など) を移行していますか?
- 現在の分析環境のアーキテクチャ図とデータフロー図を収集します。
- 計画された分析ワークロードのデータ ソースはどこにありますか (Azure、他のクラウド プロバイダー、またはオンプレミス)?
- 既存のデータセット (履歴および増分) の合計サイズはどのくらいですか? データセットの現在の増加率はどのくらいですか? 今後 2 ~ 5 年間のデータセットの予測成長率はどのくらいですか?
- 既存のデータ レイクはありますか? ファイルの種類 (Parquet や CSV など)、ファイル サイズ、セキュリティ構成について、できるだけ詳しく収集します。
- 処理および分析する半構造化データまたは非構造化データはありますか?
- データ処理 (バッチ処理またはリアルタイム処理) の性質について説明します。
- リレーショナル データ、データ レイク、またはその他のソースから対話式でデータ探索を行う必要がありますか?
- 運用データ ソースからリアルタイムのデータ分析と探索が必要ですか?
- 現在の環境における問題点と制限事項はどのようなものですか?
- 現在どのようなソース管理ツールと DevOps ツールを使用していますか?
- ハイブリッド (クラウドとオンプレミス) 分析ソリューション、クラウドのみ、またはマルチクラウドを構築するためのユース ケースはありますか?
- 既存のクラウド環境に関する情報を収集します。 これはシングルクラウド プロバイダーですか、マルチクラウド プロバイダーですか?
- 将来のクラウド環境に関する計画を収集します。 これはシングルクラウド プロバイダーになりますか、マルチクラウド プロバイダーになりますか?
- 既存の環境での RPO/RTO/HA/SLA の要件はどのようなものですか?
- 計画環境での RPO/RTO/HA/SLA の要件はどのようなものですか?
分析ワークロード ロール
分析ワークロード ロードについて、次の点を評価します。
- さまざまなロール (データ サイエンティスト、データ エンジニア、データ アナリストなど) について説明します。
- これらのロールの分析プラットフォームのアクセス制御要件について説明します。
- コンピューティング リソースをプロビジョニングし、アクセス権を付与する責任を担っているプラットフォーム所有者を特定します。
- 現在、さまざまなデータ ロールがどのように共同作業を行っているかについて説明します。
- 同じ分析プラットフォームで複数のチームが共同作業していますか? その場合、これらの各チームのアクセス制御および分離要件はどのようなものですか?
- エンド ユーザーが分析プラットフォームと対話するためにどのクライアント ツールを使用していますか?
ETL/ELT、変換、オーケストレーション
ETL/ELT、変換、オーケストレーションについて、次の点を評価します。
- データ インジェストに現在どのツールを使用していますか (ETL または ELT)?
- これらのツールは、既存の環境のどこにありますか (オンプレミスまたはクラウド)?
- 現在のデータの読み込みと更新の要件はどれですか (リアルタイム、マイクロ バッチ、毎時間、毎日、毎週、または毎月)?
- 各レイヤー (ビッグ データ、データ レイク、データ ウェアハウス) の変換要件について説明します。
- 現在、データを変換するためにどのようなプログラミング アプローチを使用していますか (コードなし、低コード、プログラミング (SQL、Python、Scala、C# など))?
- データを変換するための優先する計画プログラミング アプローチはどれですか (コードなし、低コード、プログラミング (SQL、Python、Scala、C# など))?
- データ ドリブン プロセスを自動化するためのデータ オーケストレーションにどのようなツールを現在使用していますか?
- 既存の ETL のデータ ソースはどこにありますか (Azure、その他のクラウド プロバイダー、またはオンプレミス)?
- 分析プラットフォームとの統合が必要な既存のデータ消費ツールはどれですか (レポート、BI ツール、オープン ソース ツール)?
- 分析プラットフォームとの統合が必要な計画されているデータ消費ツールはどれですか (レポート、BI ツール、オープン ソース ツール)?
ネットワークとセキュリティ
ネットワークとセキュリティについて、次の点を評価します。
- データに対してどのような規制要件がありますか?
- データに顧客コンテンツ、ペイメント支払いカード業界 (PCI)、または 1996 年の医療保険の携行性と責任に関する法律 (HIPAA) のデータが含まれている場合、セキュリティ グループはこのデータに対して Azure を認定していますか? その場合、どの Azure サービスに対してですか?
- ユーザーの認可と認証の要件について説明します。
- 実装中にデータへのアクセスを制限する可能性があるセキュリティの問題はありますか?
- 開発とテスト中に使用できるテスト データはありますか?
- 分析コンピューティングとストレージに対する組織のネットワーク セキュリティ要件 (プライベート ネットワーク、パブリック ネットワーク、またはファイアウォールの制限) について説明します。
- クライアント ツールが分析コンピューティングとストレージにアクセスするためのネットワーク セキュリティ要件 (ピアリングされたネットワーク、プライベート エンドポイントなど) について説明します。
- オンプレミスと Azure の間の現在のネットワーク セットアップ (Azure ExpressRoute やサイト間など) について説明します。
考えられる要件の次のチェックリストを使用して、評価をガイドします。
- データ保護:
- 転送中の暗号化
- 保存時の暗号化 (既定のキーまたはカスタマー マネージド キー)
- データの検出と分類
- アクセス制御:
- オブジェクト レベルのセキュリティ
- 行レベルのセキュリティ
- 列レベルのセキュリティ
- 動的データ マスク
- 認証:
- SQL ログイン
- Microsoft Entra ID
- 多要素認証 (MFA)
- ネットワークのセキュリティ:
- 仮想ネットワーク
- ファイアウォール
- Azure ExpressRoute
- 脅威に対する保護:
- 脅威の検出
- 監査
- 脆弱性評価
詳細については、Azure Synapse Analytics のセキュリティに関するホワイト ペーパーを参照してください。
Azure 環境
Azure 環境について、次の点を評価します。
- 現在 Azure を使用していますか? 運用ワークロードに使用されていますか?
- Azure を使用している場合、どのサービスを使用していますか? どのリージョンを使用していますか?
- Azure ExpressRoute を使用しますか? その帯域幅はどのくらいですか?
- 必要な Azure サービスをプロビジョニングするための予算は承認されていますか?
- 現在、リソース (Azure Resource Manager (ARM) または Terraform) をどのようにプロビジョニングおよび管理していますか?
- 主要チームは Synapse Analytics に精通していますか? トレーニングは必要ですか?
データの使用
データ消費量について、次の点を評価します。
- 取り込み、探索、準備、データの視覚化などのアクティビティを実行するために、現在どのツールをどのように使用しているかについて説明します。
- 取り込み、探索、準備、データの視覚化などのアクティビティを実行するために使用する予定のツールを特定します。
- 分析プラットフォーム (Microsoft Power BI、Microsoft Excel、Microsoft SQL Server Reporting Services、Tableau など) と対話する予定のアプリケーションはどれですか?
- すべてのデータ コンシューマーを識別します。
- データ エクスポートとデータ共有の要件を特定します。
Azure Synapse サービスの評価
Azure Synapse サービスの評価は、Azure Synapse 内のサービスに関連しています。 Azure Synapse には、コンピューティングとデータ移動用の次のコンポーネントがあります。
- Synapse SQL: データ ウェアハウスとデータ仮想化のシナリオを可能にする Transact-SQL (T-SQL) 用の分散クエリ システムです。 また、T-SQL を拡張して、ストリーミングと機械学習 (ML) のシナリオに対処します。 Synapse SQL では、サーバーレスと専用の両方のリソース モデルが提供されます。
- サーバーレス SQL プール: 大規模なデータとコンピューティング機能を対象として構築された分散データ処理システムです。 セットアップするインフラストラクチャや管理するクラスターはありません。 このサービスは、計画外のワークロードやバースト ワークロードに適しています。 推奨されるシナリオには、データ レイク上のファイルに対する直接のデータ探索、論理データ ウェアハウス、生データのデータ変換などが含まれます。
- 専用 SQL プール: Synapse SQL を使用するときにプロビジョニングされる分析リソースのコレクションを表します。 専用 SQL プール (以前の SQL DW) のサイズは、Data Warehouse ユニット (DWU) によって決まります。 このサービスは、SQL テーブルに格納されているデータに対する予測可能でハイ パフォーマンスの継続的なワークロードを備えたデータ ウェアハウスに適しています。
- Apache Spark プール: Apache Spark と密にシームレスに統合されます。Apache Spark は、データ準備、Data Engineering、ETL、ML に使用される最も人気のあるオープン ソースのビッグ データ エンジンです。
- データ統合パイプライン: Azure Synapse には、Azure Data Factory (ADF) と同じデータ統合エンジンとエクスペリエンスが含まれています。 これにより、Azure Synapse を離れることなく、大規模な ETL パイプラインを豊富に作成できます。
最適な SQL プールの種類 (専用またはサーバーレス) を判断できるように、次の点を評価します。
- SQL テーブルに格納されているデータの処理能力を確保して、従来のリレーショナル データ ウェアハウスを構築しますか?
- ユース ケースでは予測可能なパフォーマンスが必要ですか?
- データ レイクの上に論理データ ウェアハウスを構築しますか?
- 直接データ レイクからデータのクエリを実行しますか?
- データ レイクからデータを探索しますか?
次の表では、2 種類の Synapse SQL プールを比較しています。
比較 | 専用 SQL プール | サーバーレス SQL プール |
---|---|---|
価値提案 | データ ウェアハウスのフル マネージド機能。 継続的なワークロードに対して予測可能なハイ パフォーマンス。 マネージド (読み込まれた) データ用に最適化されています。 | データ レイク データを簡単に使い始めて探索できます。 アドホックおよび間欠的ワークロードに対する総保有コスト (TCO) の向上。 データ レイク内のデータのクエリ用に最適化されています。 |
ワークロード | 継続的なワークロードに最適です。 読み込みによってパフォーマンスが向上し、複雑さが増します。 DWU あたりでの課金により (サイズが適切な場合)、費用対効果がよくなります。 | アドホックまたは間欠的なワークロードに最適です。 データを読み込む必要がないため、開始と実行が簡単です。 使用量あたりの課金により、費用対効果がよくなります。 |
クエリ パフォーマンス | コンカレンシーが高く、待機時間が短くなります。 具体化されたビューなど、豊富なキャッシュ オプションをサポートします。 ワークロード管理 (WLM) とのトレードオフを選択する機能があります。 | ダッシュボード クエリには適していません。 ミリ秒の応答時間は予想されていません。 外部データでのみ機能します。 |
専用 SQL プールの評価
専用 SQL プールの評価では、次のプラットフォーム ポイントを評価します。
- 現在のデータ ウェアハウス プラットフォームはどれですか (Microsoft SQL Server、Netezza、Teradata、Greenplum など)?
- 移行ワークロードについて、環境ごとにアプライアンスの製造元とモデルを特定します。 CPU、GPU、メモリの詳細を含めます。
- アプライアンスの移行の場合、ハードウェアはいつ購入されましたか? アプライアンスは完全に減価償却されましたか? そうでない場合、減価償却はいつ終了しますか? また、資本支出はいくら残っていますか?
- ハードウェアとネットワーク アーキテクチャの図はありますか?
- 計画データ ウェアハウスのデータ ソースはどこにありますか (Azure、その他のクラウド プロバイダー、またはオンプレミス)?
- データ ウェアハウスのデータ ソースのデータ ホスティング プラットフォームはどれですか (Microsoft SQL Server、Azure SQL Database、DB2、Oracle、Azure Blob Storage、AWS、Hadoop など)?
- データ ソースのデータ ウェアハウスはありますか? その場合、どれですか?
- ETL、ELT、データ読み込みシナリオ (Batch Windows、ストリーミング、ほぼリアルタイム) をすべて特定します。 各シナリオの既存のサービス レベル アグリーメント (SLA) を特定し、新しい環境で予想される SLA を文書化します。
- 現在のデータ ウェアハウスのサイズはどれくらいですか?
- どれだけのデータセットの増加率が、専用 SQL プールの対象となりますか?
- 現在使用している環境 (開発、テスト、または運用) について説明します。
- 現在、どのツールが、データ移動に用意されていますか (ADF、Microsoft SQL Server Integration Services (SSIS)、Robocopy、Informatica、SFTP など)?
- リアルタイムまたはほぼリアルタイムのデータを読み込む予定ですか?
次のデータベース ポイントを評価します。
- 各データ ウェアハウス内にオブジェクト (スキーマ、テーブル、ビュー、ストアド プロシージャ、関数) はいくつありますか?
- スター スキーマ、スノーフレーク スキーマ、またはその他のデザインですか?
- レコードのサイズと数に関して最も大きいテーブルはどれですか?
- 列レコードのサイズと数に関して最も広いテーブルはどれですか?
- データ ウェアハウス用に設計されたデータ モデルは既に存在しますか? キンボール、Inmon、スター スキーマのデザインですか?
- 緩やかに変化するディメンション (SCD) は使用されていますか? その場合、どのタイプですか?
- セマンティック レイヤーは、リレーショナル データ マートまたは Analysis Services (表または多次元形式)、あるいは別の製品を使用して実装されますか?
- HA/RPO/RTO/データ アーカイブの要件はどのようなものですか?
- リージョン間レプリケーションの要件はどのようなものですか?
次のワークロード特性を評価します。
- ピーク時間中にデータ ウェアハウスにアクセスする同時ユーザーまたはジョブの推定数はいくつですか?
- オフピーク時間中にデータ ウェアハウスにアクセスする同時ユーザーまたはジョブの推定数はいくつですか?
- ユーザーやジョブが存在しない期間はありますか?
- 対話型クエリに対して、どの程度のクエリ実行のパフォーマンスが予想されますか?
- 毎日/毎週/毎月のデータ読み込みまたは更新に対して、どの程度のデータ読み込みのパフォーマンスが予想されますか?
- レポートと分析クエリに対して、どの程度のクエリ実行が予想されますか?
- 最もよく実行されているクエリはどの程度複雑ですか?
- 合計データセット サイズに対するアクティブなデータセットの割合は何パーセントですか?
- 読み込みまたは更新、バッチ処理またはレポート作成、対話型クエリ、分析処理に対して予想されるワークロードの割合は、おおよそどの程度ですか?
- データ消費パターンおよびプラットフォームを特定します。
- 現在および計画されているレポート作成方法とツール。
- どのアプリケーションまたは分析ツールで、データ ウェアハウスにアクセスしますか?
- 同時クエリの数はいくつですか?
- 任意の時点でのアクティブなクエリの平均数はいくつですか?
- データ アクセスの性質はどのようなものですか (対話型、アドホック、エクスポートなど)?
- データ ロールと、それぞれのデータ要件の完全な説明。
- コンカレント接続の最大数。
- 次の要素別のクエリ パフォーマンス SLA パターン:
- ダッシュボード ユーザー。
- バッチ レポート。
- ML ユーザー。
- ETL プロセス。
- 既存の環境と新しい環境にはそれぞれどのようなセキュリティ要件がありますか (行レベルのセキュリティ、列レベルのセキュリティ、アクセス制御、暗号化など)?
- ML モデル スコアリングを T-SQL と統合するための要件はありますか?
サーバーレス SQL プールの評価
Synapse サーバーレス SQL プールでは、3 つの主要ユース ケースがサポートされています。
- 基本の検出と探索: データ レイク内のさまざまな形式 (Parquet、CSV、JSON) のデータをすばやく把握できるため、そこから分析情報を抽出する方法を計画することができます。
- 論理データ ウェアハウス: データの再配置や変換を行うことなく、生または異種のデータに基づいてリレーショナル抽象化を実現します。これにより、常に現在のデータを表示できます。
- データ変換: T-SQL を使用して、効率性が高くシンプルかつスケーラブルな方法でレイク内のデータを変換できるので、それを BI ツールなどにフィードしたり、リレーショナル データ ストア (Synapse SQL データベース、Azure SQL Database など) に読み込んだりできます。
サーバーレス SQL プールは、さまざまなデータ ロールの役に立ちます。
- データ エンジニアは、このサービスを使用してレイクの探索、データの変換、準備を行えるほか、データ変換パイプラインを簡素化できます。
- データ サイエンティストは、OPENROWSET や自動スキーマ推論などの機能を利用して、データ レイク内のデータの内容と構造を迅速に把握することができます。
- データ アナリストは、使い慣れた T-SQL ステートメントやそれぞれのお気に入りのクエリ ツールを使用して、データ サイエンティストまたはデータ エンジニアによって作成されたデータと Spark 外部テーブルを探索できます。
- BI プロフェッショナルは、データ レイク内のデータおよび Spark テーブルに基づいて Power BI レポートをすばやく作成できます。
注意
T-SQL 言語は、専用 SQL プールとサーバーレス SQL プールの両方で使用されていますが、サポートされている一連の機能にいくつかの違いがあります。 Synapse SQL (専用およびサーバーレス) でサポートされる T-SQL 機能の詳細については、「Azure Synapse SQL でサポートされる Transact-SQL 機能」を参照してください。
サーバーレス SQL プールの評価では、次の点を評価します。
- リレーショナル クエリ (T-SQL) を使用してデータ レイクからデータを検出して探索するユース ケースはありますか?
- データ レイク上に論理データ ウェアハウスを構築するためのユース ケースはありますか?
- データ レイクから最初にデータを移動せずに、データ レイク内のデータを変換するユース ケースがあるかどうかを特定します。
- データは既に Azure Data Lake Storage (ADLS) または Azure Blob Storage に存在していますか?
- データが既に ADLS にある場合、データ レイクに適切なパーティション戦略がありますか?
- Azure Cosmos DB に運用データがありますか? トランザクションに影響を与えずに Azure Cosmos DB でリアルタイム分析を行うユース ケースはありますか?
- データ レイク内のファイルの種類を特定します。
- クエリ パフォーマンス SLA を特定します。 ユース ケースでは予測可能なパフォーマンスとコストが必要ですか?
- 計画外またはバーストの SQL 分析ワークロードはありますか?
- データ消費パターンおよびプラットフォームを特定します。
- 現在および計画されているレポート作成方法とツール。
- どのアプリケーションまたは分析ツールで、サーバーレス SQL プールにアクセスしますか?
- 任意の時点でのアクティブなクエリの平均数。
- データ アクセスの性質はどのようなものですか (対話型、アドホック、エクスポートなど)?
- データ ロールと、それぞれのデータ要件の完全な説明。
- コンカレント接続の最大数。
- クエリの複雑さ?
- どのようなセキュリティ要件がありますか (アクセス制御、暗号化など)?
- 必要な T-SQL 機能はどれですか (ストアド プロシージャまたは関数)?
- サーバーレス SQL プールに送信されるクエリの数と、各クエリの結果セット サイズを特定します。
ヒント
サーバーレス SQL プールを初めて使用する場合は、「Azure Synapse サーバーレス SQL プールを使用して Data Analytics ソリューションを構築する」のラーニング パスに従うことをお勧めします。
Spark プールの評価
Azure Synapse の Spark プールでは、以下に挙げる主なシナリオを実現できます。
- Data engineering/データ準備: Apache Spark には、大量のデータの準備と処理をサポートするための多くの言語機能が含まれています。 準備と処理により、データの価値を高め、他の Azure Synapse サービスで使用できるようになります。 これは、複数の言語 (C#、Scala、PySpark、Spark SQL) と、処理および接続を目的に提供されているライブラリの使用によって実現されています。
- 機械学習: Apache Spark には、Spark を基に作成された ML ライブラリである MLlib が付属し、Spark プールから使用できます。 Spark プールには、ML を含むデータ サイエンス用のさまざまなパッケージを構成する Python ディストリビューションである Anaconda も含まれます。 さらに、Synapse 上の Apache Spark には、フォールト トレラント、エラスティック、RESTful ML フレームワークである Microsoft Machine Learning 用にプレインストールされたライブラリが用意されています。 ノートブックの組み込みサポートを併用すれば、ML アプリケーションを作成するための豊富な環境が得られます。
注意
詳細については、「Azure Synapse Analytics での Apache Spark」を参照してください。
また、Azure Synapse は、Linux Foundation Delta Lake と互換性があります。 Delta Lake は、ACID (原子性、一貫性、分離性、持続性) トランザクションを Apache Spark とビッグ データ ワークロードに導入するオープンソースのストレージ レイヤーです。 詳細については、「Delta Lake とは」を参照してください。
Spark プールの評価では、次の点を評価します。
- Data Engineering またはデータ準備を必要とするワークロードを特定します。
- 変換の種類を明確に定義します。
- 処理する非構造化データがあるかどうかを特定します。
- 既存の Spark/Hadoop ワークロードから移行する場合:
- 既存のビッグ データ プラットフォームはどれですか (Cloudera、Hortonworks、クラウド サービスなど)?
- オンプレミスからの移行の場合、ハードウェアの減価償却やライセンス有効期限は終わっていますか? そうでない場合、減価償却または有効期限はいつ終わりますか?
- 既存のクラスターの種類はどのようなものですか?
- 必要なライブラリと Spark のバージョンはいくつですか?
- Spark への Hadoop 移行ですか?
- 現在のプログラミング言語または推奨のプログラミング言語はどのようなものですか?
- ワークロードはどの種類ですか (ビッグ データや ML など)?
- 既存および計画されているクライアント ツールとレポート作成プラットフォームは、どのようなものですか?
- セキュリティ要件はどのようなものですか?
- 現在の問題点と制限事項はありますか?
- Delta Lake を使用する予定ですか、または現在使用していますか?
- 現在、どのようにしてパッケージを管理していますか?
- 必要なコンピューティング クラスターの種類を特定します。
- クラスターのカスタマイズが必要かどうかを特定します。
ヒント
Spark プールを初めて使用する場合は、「Azure Synapse Apache Spark プールで Data Engineering を実行する」 のラーニング パスに従うことをお勧めします。
次の手順
Azure Synapse の設計上の成功シリーズの次の記事では、Synapse ワークスペース設計を評価し、ガイドラインと要件を満たしているかどうかを確認する方法について説明します。