編集

次の方法で共有

Azure Synapse Analytics を使用してエンタープライズ BI ソリューションを設計する

Power BI
Azure Synapse Analytics
Azure Data Factory
Microsoft Entra ID
Azure Blob Storage

この記事では、オンプレミスのデータ ウェアハウスからクラウド環境にデータを転送し、ビジネス インテリジェンス (BI) モデルを使用してデータを処理する方法について説明します。 このアプローチは、クラウドベースのコンポーネントを使用した完全な最新化に向けた最終目標または最初のステップとして使用できます。

このガイダンスは、Azure Synapse Analytics のエンド ツー エンド シナリオに基づいています。 このプロセスでは、Azure Synapse Analytics パイプラインを使用して、SQL データベースから SQL プールにデータを取り込みます。 次に、分析のためにデータ変換を実行します。 この記事では、Azure Synapse Analytics パイプラインに焦点を当てていますが、Azure Data Factory パイプラインまたは Fabric Data Factory パイプラインを使用してこれらのタスクを実行することもできます。

このアーキテクチャを使用する場合

エンタープライズ BI のビジネス要件を満たすために、さまざまな方法を使用できます。 現在のテクノロジへの投資、人間のスキル、最新化のタイムライン、将来の目標、サービスとしてのプラットフォーム (PaaS) とサービスとしてのソフトウェア (SaaS) のどちらを優先するかなど、さまざまな側面によってビジネス要件が定義されます。

次の設計方法を検討してください。

この記事のアーキテクチャでは、エンタープライズ セマンティック モデルの永続的レイヤーとして Azure Synapse Analytics データ ウェアハウスを使用し、ビジネス インテリジェンスに Power BI を使用することを前提としています。 この PaaS アプローチでは、さまざまなビジネス要件と好みに柔軟に対応できます。

アーキテクチャ

Azure Synapse Analytics を使用したエンタープライズ BI アーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

データ ソース

  • Azure の SQL Server データベースには、ソース データが含まれています。 オンプレミス環境をシミュレートするために、このシナリオのデプロイ スクリプトによって Azure SQL データベースが構成されます。 AdventureWorks サンプル データベースをソース データ スキーマとサンプル データとして使います。 詳細については、「SQL Serverとの間でデータをコピーおよび変換する」を参照してください。

インジェストとデータ ストレージ

分析とレポート

コンポーネント

このシナリオでは、次のコンポーネントを使用します。

  • azure SQL Database は、Azure でホストされる PaaS SQL サーバーです。 このアーキテクチャでは、SQL Database を使用して、移行シナリオのデータ フローを示します。

  • Data Lake Storage は、中間移行の結果を保持するために使用される非構造化データ用の柔軟なクラウド ストレージを提供します。

  • Azure Synapse Analytics は、データ ウェアハウスとビッグ データ システム用のエンタープライズ分析サービスです。 Azure Synapse Analytics は、エンタープライズ セマンティック モデリングとサービスの主要なコンピューティングおよび永続的ストレージとして機能します。

  • Power BI Premium は、このシナリオでデータを表示および視覚化する BI ツールです。

  • Microsoft Entra ID は、認証と承認のフローをサポートするマルチクラウド ID とネットワーク ソリューション スイートです。

簡略化されたアーキテクチャ

エンタープライズ BI の簡略化されたアーキテクチャを示す図。

シナリオの詳細

このシナリオでは、組織には大規模なオンプレミス データ ウェアハウスを含む SQL データベースがあります。 組織は、Azure Synapse Analytics を使用して分析を実行し、Power BI を介してこれらの分析情報をユーザーと分析に提供したいと考えています。

認証

Microsoft Entra ID は、Power BI ダッシュボードとアプリに接続するユーザーを認証します。 シングル サインオンは、Azure Synapse Analytics プロビジョニング プール内のデータ ソースにユーザーを接続します。 承認はソースで行われます。

段階的な読み込み

自動抽出、変換、読み込み (ETL) または抽出、読み込み、変換 (ELT) プロセスを実行する場合は、前回の実行以降に変更されたデータのみを読み込む必要があります。 このプロセスは、増分読み込みと呼ばれます。 逆に、フル ロードではすべてのデータが読み込まれます。 増分読み込みを実行するには、変更されたデータを識別する方法を決定します。 高基準値 値アプローチを使用できます。このアプローチでは、ソース テーブル内の日付/時刻列または一意の整数列の最新の値を追跡します。

SQL Server で テンポラル テーブル を使用できます。 テンポラル テーブルは、データ変更履歴を格納するシステム バージョン管理されたテーブルです。 データベース エンジンは、各変更履歴を別々の履歴テーブルに自動的に記録します。 履歴データに対してクエリを実行するには、FOR SYSTEM_TIME 句をクエリに追加します。 内部的には、データベース エンジンは履歴テーブルのクエリを実行しますが、この処理はアプリケーションにとって透過的です。

テンポラル テーブルではディメンション データがサポートされており、時間の経過と同時に変化する可能性があります。 通常、ファクト テーブルは、販売などの不変トランザクションを表します。この場合、システムのバージョン履歴を保持することは意味がありません。 代わりに、トランザクションには通常、トランザクションの日付を表す列があります。 この列は、基準値として使用できます。 たとえば、AdventureWorks データ ウェアハウスでは、SalesLT.* テーブルには LastModified フィールドがあります。

ELT パイプラインの一般的なフローは次のとおりです。

  1. ソース データベースの各テーブルについて、最後の ELT ジョブが実行されたときのカットオフ時間を追跡します。 この情報をデータ ウェアハウスに格納します 初期設定では、すべての時間が 1-1-1900 に設定されます。

  2. データのエクスポート手順では、カットオフ時間がパラメーターとしてソース データベース内のストアド プロシージャのセットに渡されます。 これらのストアド プロシージャは、カットオフ時間の後に変更または作成されたすべてのレコードに対してクエリを実行します。 例のすべてのテーブルには ModifiedDate 列を使用できます。

  3. データの移行が完了したら、カットオフ時間を格納するテーブルを更新します。

データ パイプライン

このシナリオでは、データソースとして AdventureWorks サンプル データベースを使います。 増分データ読み込みパターンにより、最新のパイプライン実行後に変更または追加されたデータのみが読み込まれます。

メタデータ駆動型のコピー ツール

Azure Synapse Analytics パイプライン内の組み込みの メタデータ駆動型コピー ツール は、リレーショナル データベースに含まれるすべてのテーブルを段階的に読み込みます。

  1. ウィザード インターフェイスを使用して、データのコピー ツールをソース データベースに接続します。

  2. 接続したら、各テーブルの増分読み込みまたは完全読み込みを構成します。

  3. データのコピー ツールは、コントロール テーブルの生成に必要なパイプラインと SQL スクリプトを作成します。 このテーブルには、増分読み込みプロセスの各テーブルの高基準値や列などのデータが格納されます。

  4. これらのスクリプトを実行すると、パイプラインはすべてのソース データ ウェアハウス テーブルを Azure Synapse Analytics 専用プールに読み込みます。

Azure Synapse Analytics のメタデータ駆動型のデータコピー ツールを示すスクリーンショット。

ツールは、データを読み込む前に、データベース内のテーブルを反復処理する 3 つのパイプラインを作成します。

パイプラインは次のタスクを実行します。

  • パイプラインの実行でコピーされるテーブルなどのオブジェクト数をカウントします。

  • 読み込むかコピーする各オブジェクトを反復処理します。

  • パイプラインは、各オブジェクトを反復処理した後、次のタスクを実行します。

    • 差分読み込みが必要かどうかを確認します。 それ以外の場合、パイプラインは通常の完全な読み込みを完了します。

    • コントロール テーブルから高基準値を取得します。

    • ソース テーブルから Data Lake Storage のステージング アカウントにデータをコピーします。

    • PolyBase や Copy コマンドなど、選択したコピー方法を使用して専用 SQL プールにデータを読み込みます。

    • コントロール テーブルの高基準値を更新します。

Azure Synapse Analytics SQL プールにデータを読み込む

コピー アクティビティ、SQL データベースから Azure Synapse Analytics SQL プールにデータをコピーします。 この例の SQL データベースは Azure 内にあり、Azure 統合ランタイムを使用して SQL データベースからデータを読み取り、指定されたステージング環境にデータを書き込みます。

その後、copy ステートメントによって、ステージング環境から Azure Synapse Analytics 専用プールにデータが読み込まれます。

Azure Synapse Analytics パイプラインを使用する

Azure Synapse Analytics のパイプラインでは、増分読み込みパターンを完了するために、順序付けられた一連のアクティビティを定義します。 手動トリガーまたは自動トリガーによってパイプラインが開始されます。

データの変換

この参照アーキテクチャのサンプル データベースは小さいため、パーティションのないレプリケート テーブルが作成されます。 運用ワークロードの場合、分散テーブルを使用すると、クエリのパフォーマンスを向上させることができます。 詳細については、Azure Synapse Analytics で分散テーブルを設計するためのガイダンスを参照してください。 サンプル スクリプトは、静的な リソース クラスを使用してクエリを実行します。

運用環境では、ラウンド ロビン分散を持つステージング テーブルを作成することを検討してください。 次に、クラスター化列ストア インデックスを持つ運用テーブルにデータを変換して移動します。これにより、クエリ全体のパフォーマンスが最適になります。 列ストア インデックスは、多数のレコードをスキャンするクエリに最適化されています。

列ストア インデックスは、シングルトン参照や単一行の検索には最適に実行されません。 頻繁なシングルトン参照を実行する必要がある場合は、非クラスター化インデックスをテーブルに追加すると、速度が向上します。 ただし、一般に、シングルトン参照は、オンライン トランザクション処理ワークロードよりもデータ ウェアハウスのシナリオでは一般的ではありません。 詳細については、「Azure Synapse Analytics でのインデックス テーブルの」を参照してください。

Note

クラスター化列ストア テーブルでは、varchar(max)、nvarchar(max)、varbinary(max) の各データ型はサポートしていません。 これらのデータ型を使用する場合は、ヒープまたはクラスター化インデックスを検討してください。 また、これらの列を別のテーブルに配置することも検討してください。

Power BI Premium を使ったデータのアクセス、モデル化、視覚化

Power BI Premium では、Azure 上のデータ ソースに接続するためのいくつかのオプションがサポートされています。 Azure Synapse Analytics のプロビジョニング済みプールを使用して、次のタスクを実行できます。

  • インポート: データは Power BI モデルにインポートされます。
  • DirectQuery: データはリレーショナル ストレージから直接プルされます。
  • 複合モデル: 一部のテーブルには "インポート" を、他のものには DirectQuery を組み合わせて使います。

このシナリオでは、データ量が少なく、モデルの複雑さが少ないため、DirectQuery ダッシュボードを使用します。 DirectQuery は、クエリをその下の強力なコンピューティング エンジンに委任し、ソースで広範なセキュリティ機能を使用します。 DirectQuery により、結果は常に最新のソース データと一致します。

インポート モードでは、最も高速なクエリ応答時間が提供されます。 次の場合は、インポート モードを検討してください。

  • このモデルは、Power BI のメモリ内に完全に収まります。
  • 更新間のデータ待機時間は許容されます。
  • ソース システムと最終的なモデルの間で複雑な変換が必要です。

この場合、エンド ユーザーは、Power BI の更新に遅延なしで最新のデータへのフル アクセスを必要とし、Power BI データセットの容量を超えるすべての履歴データが必要になります。 Power BI データセットは、容量のサイズに応じて 25 から 400 GB を処理できます。 専用 SQL プール内のデータ モデルは既にスター スキーマにあり、変換は必要ないため、DirectQuery が適切な選択肢です。

Power BI のダッシュボードを示すスクリーンショット。

Power BI Premium を使用して、大規模なモデル、ページ分割されたレポート、デプロイ パイプラインを管理します。 組み込みの Azure Analysis Services エンドポイントを利用します。 また、独自の価値提案を備えた専用の容量を持つこともできます。

BI モデルが拡大したり、ダッシュボードの複雑さが増したりすると、複合モデルに切り替えたり、ハイブリッド テーブル 介して参照テーブルの一部をインポートしたり、事前集計データをインポートしたりできます。 インポートされたデータセットに対して Power BI 内で クエリ キャッシュ を有効にしたり、ストレージ モード プロパティ デュアル テーブル を使用したりできます。

複合モデル内では、データセットは仮想パススルー レイヤーとして機能します。 ユーザーが視覚化を操作すると、Power BI によって Azure Synapse Analytics SQL プールに対する SQL クエリが生成されます。 Power BI は、効率に基づいてメモリ内ストレージと DirectQuery ストレージのどちらを使用するかを決定します。 エンジンは、インメモリから DirectQuery に切り替えるタイミングを決定し、ロジックを Azure Synapse Analytics SQL プールにプッシュします。 クエリ テーブルのコンテキストに応じて、キャッシュされた (インポートされた) 複合モデルまたはキャッシュされていない複合モデルとして機能できます。 メモリにキャッシュするテーブルを選択したり、1 つ以上の DirectQuery ソースのデータを結合したり、DirectQuery ソース データとインポートされたデータを結合したりできます。

Azure Synapse Analytics によってプロビジョニングされたプールで DirectQuery を使用する場合:

  • Azure Synapse Analytics 結果セットのキャッシュ を使用して、クエリ結果をユーザー データベースにキャッシュし、繰り返し使用します。 この方法では、クエリのパフォーマンスがミリ秒に向上し、コンピューティング リソースの使用量が削減されます。 キャッシュされた結果セットを使用するクエリは、Azure Synapse Analytics のコンカレンシー スロットを消費しないため、既存のコンカレンシー制限に対してカウントされません。

  • Azure Synapse Analytics 具体化されたビュー を使用して、テーブルなどのデータを事前計算、格納、保守します。 具体化されたビュー内のすべてのデータまたはデータのサブセットを使用するクエリでは、定義されたマテリアライズド ビューを直接参照して使用しなくても、より高速なパフォーマンスを実現できます。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Well-Architected Framework」を参照してください。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティ設計レビューチェックリスト」を参照してください。

クラウドの最新化により、データ侵害、マルウェア感染、悪意のあるコードインジェクションなどのセキュリティ上の問題が発生します。 不十分なセキュリティ対策によって大きな問題が発生する可能性があるため、懸念事項に対処できるクラウド プロバイダーまたはサービス ソリューションが必要です。

このシナリオでは、ネットワーク、ID、プライバシー、承認の制御という階層化されたセキュリティ制御の組み合わせを使用して、最も要求の厳しいセキュリティの問題に対処します。 Azure Synapse Analytics によってプロビジョニングされたプールには、ほとんどのデータが格納されます。 Power BI は、シングル サインオンを使用して DirectQuery 経由でデータにアクセスします。 認証に Microsoft Entra ID を使用できます。 また、プロビジョニングされたプール内のデータ承認に対する広範なセキュリティ制御もあります。

セキュリティに関する一般的な質問には、次のようなものがあります。

  • どのデータを表示できるかを定義します。

    • データ侵害リスクを軽減するために、データが連邦政府、地方、および会社のガイドラインに準拠していることを確認します。 Azure Synapse Analytics には、コンプライアンスを実現するために 複数の データ保護機能が用意されています。

  • ユーザーの ID を確認する方法を決定します。

    • Azure Synapse Analytics を使用して、アクセス制御 と認証 を使用して、どのデータにアクセスできるかを制御します。

  • ネットワークとデータの整合性、機密性、アクセスを保護するネットワーク セキュリティ テクノロジを選択します。

  • 脅威を検出して通知するツールを選択します。

    • Azure Synapse Analytics 脅威検出 機能 (SQL 監査、SQL 脅威検出、脆弱性評価など) を使用して、データベースの監査、保護、監視を行います。

  • ストレージ アカウント内のデータを保護する方法を決定します。

    • 高速で一貫性のある応答時間が必要なワークロード、または 1 秒あたりの入出力操作 (IOPS) の数が多いワークロードには、Azure Storage アカウントを使用します。 ストレージ アカウントは、すべてのデータ オブジェクトを格納でき、ストレージ アカウントのセキュリティ オプション。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コストの最適化設計レビューチェックリスト」を参照してください。

このセクションでは、このソリューションに関連するさまざまなサービスの価格に関する情報を提供し、サンプル データセットを使用してこのシナリオに対して行われた決定について説明します。 Azure 料金計算ツールでこの開始構成を使用し、シナリオに合わせて調整します。

Azure Synapse Analytics

Azure Synapse Analytics は、コンピューティング レベルとストレージ レベルを個別にスケーリングするために使用できるサーバーレス アーキテクチャです。 コンピューティング リソースでは、使用量に基づいてコストが発生します。 これらのリソースは、オンデマンドでスケーリングまたは一時停止できます。 ストレージ リソースではテラバイトあたりのコストが発生するため、データを取り込むにつれてコストが増加します。

Azure Synapse Analytics パイプライン

3 つの主要コンポーネントがパイプラインの価格に影響を与えます。

  • データ パイプラインのアクティビティと統合ランタイム時間
  • データ フロー クラスターのサイズと実装
  • 運用料金

価格の詳細については、Azure Synapse Analytics の価格 の Data Integration タブ参照してください。

価格は、コンポーネントまたはアクティビティ、頻度、統合ランタイム ユニットの数によって異なります。

標準の Azure でホストされる統合ランタイムを使用するサンプル データセットの場合、コピー データ アクティビティ パイプラインの中核として機能します。 ソース データベース内のすべてのエンティティ (テーブル) に対して毎日のスケジュールで実行されます。 このシナリオにはデータ フローが含まれません。 また、パイプラインの実行回数が 1 か月あたり 100 万未満であるため、運用コストは発生しません。

Azure Synapse Analytics 専用プールとストレージ

サンプル データセットでは、500 個のデータ ウェアハウス ユニット (DWU) をプロビジョニングして、分析読み込みのスムーズなエクスペリエンスを提供できます。 レポートの目的で、営業時間中にコンピューティングを維持できます。 ソリューションが運用環境に移行する場合は、コスト効率の高い戦略として予約済みデータ ウェアハウス容量を使用します。 さまざまな手法を使用して、コストとパフォーマンスのメトリックを最大化します。

Azure Synapse Analytics 専用プールの価格の詳細については、Azure Synapse Analytics の価格 の データ ウェアハウス タブ参照してください。 専用の従量課金モデルでは、お客様は、プロビジョニングされた DWU ごとに 1 時間あたりのアップタイムあたりのコストが発生します。 また、保存データのサイズ、スナップショット、geo 冗長性など、データ ストレージコストも考慮してください。

BLOB ストレージ

ストレージ コストを削減するには、Azure Storage の予約容量を使用することを検討してください。 このモデルでは、1 年間または 3 年間固定のストレージ容量の予約した場合に割引が適用されます。 詳細については、「予約容量を使用して BLOB ストレージのコストを最適化する」を参照してください。 このシナリオでは、永続ストレージは使用されません。

Power BI Premium

このシナリオでは、Power BI Premium ワークスペース を使用し、要求の厳しい分析ニーズに対応するために、組み込みのパフォーマンスが強化されています。

詳細については、Power BI の価格 を参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「オペレーショナル エクセレンス設計レビュー チェックリスト」を参照してください。

  • Azure DevOps リリース パイプラインと GitHub Actions を使用して、複数の環境にわたる Azure Synapse Analytics ワークスペースのデプロイを自動化します。 詳細については、Azure Synapse Analytics ワークスペース の継続的インテグレーションと継続的デリバリーのに関するページを参照してください。

  • 各ワークロードを個別のデプロイ テンプレートに配置し、ソース管理システムにリソースを格納します。 テンプレートは、継続的インテグレーションおよび継続的デリバリー (CI/CD) プロセスの一部としてまとめて、または個別にデプロイできます。 この方法により、自動化プロセスが簡略化されます。 このアーキテクチャには、主に次の 4 つのワークロードがあります。

    • データ ウェアハウス サーバーと関連リソース
    • Azure Synapse Analytics パイプライン
    • ダッシュボード、アプリ、データセットなどの Power BI 資産
    • オンプレミスからクラウドへのシミュレートされたシナリオ

  • ワークロードをステージングすることを検討します。 ワークロードをさまざまなステージにデプロイします。 次のステージに進む前に、各ステージで検証チェックを実行します。 この方法では、制御された方法で運用環境に更新プログラムをプッシュし、予期しないデプロイの問題を最小限に抑えます。 ブルーグリーンデプロイ 使用し、カナリアリリース 戦略を して、ライブ運用環境を更新します。

  • ロールバック戦略を使用して、失敗したデプロイを処理します。 たとえば、デプロイ履歴から以前に成功したデプロイを自動的に再デプロイすることができます。 Azure CLI で --rollback-on-error フラグを使用します。

  • Azure Monitor を使用して、統合された監視エクスペリエンスのためにデータ ウェアハウスと Azure 分析プラットフォーム全体のパフォーマンスを分析します。 Azure Synapse Analytics を使うと、Azure portal 内で監視エクスペリエンスが提供され、データ ウェアハウスのワークロードに関する分析情報が表示されます。 Azure portal を使用してデータ ウェアハウスを監視します。 構成可能な保持期間、アラート、推奨事項、メトリックとログのカスタマイズ可能なグラフとダッシュボードが提供されます。

詳細については、次のリソースを参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率設計レビュー チェックリスト」を参照してください。

このセクションでは、このデータセットに対応するためのサイズ決定について詳しく説明します。

Azure Synapse Analytics のプロビジョニング済みプール

さまざまな データ ウェアハウス構成使用できます。

DWU コンピューティング ノードの数 ノードあたりのディストリビューションの数
DW100c 1 60
-- TO --
DW30000c 60 1

スケールアウトのパフォーマンス上の利点 (特に大規模な DWU の場合) を確認するには、少なくとも 1 TB のデータセットを使用します。 専用 SQL プールに最適な DWU の数を見つけるには、スケールアップとスケールダウンを試してください。 データを読み込んだ後、異なる数の DWU を持つクエリを実行します。 スケーリングはすばやく行うことができるため、さまざまなパフォーマンス レベルを簡単に試すことができます。

DWU の最適な数を見つける

開発中の専用 SQL プールの場合は、DW400c 、DW200c など、少数の DWU を開始点として選択します。 DWU の数ごとにアプリケーションのパフォーマンスを監視します。 線形スケールを想定し、DWU の増減に必要な量を決定します。 ビジネス要件に応じた最適なパフォーマンス レベルに到達するまで調整を行います。

Azure Synapse Analytics SQL プールのスケーリング

Azure Synapse Analytics のパイプラインと、使用するコピー アクティビティのスケーラビリティとパフォーマンスの最適化機能については、コピー アクティビティのパフォーマンスとスケーラビリティに関するガイドを参照してください。

詳細については、次のリソースを参照してください。

  • Azure portal を使用して Azure Synapse Analytics SQL プールのコンピューティングをスケーリングする
  • Azure PowerShell を使用して専用 SQL プールのコンピューティングをスケーリングする
  • T-SQL を使用して Azure Synapse Analytics の専用 SQL プールのコンピューティングをスケーリングする
  • 専用 SQL プール のコンピューティングを管理する

Power BI Premium と Fabric

この記事では、Power BI Premium F64 容量 を使用して、BI 機能を示します。 Fabric の専用 Power BI 容量は、F64 (8 仮想コア) から F1024 (128 仮想コア) の範囲です。

必要な容量を決定するには:

共同作成者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

プリンシパルの作成者:

  • Galina Polyakova |シニア クラウド ソリューション アーキテクト
  • Noah Costar | クラウド ソリューション アーキテクト
  • George Stevens | クラウド ソリューション アーキテクト

その他の共同作成者:

  • Jim McLeod | クラウド ソリューション アーキテクト
  • Miguel Myers | シニア プログラム マネージャー

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ