次の方法で共有

Center of Excellence での BI ソリューションのアーキテクチャ

  • [アーティクル]

この記事は、IT プロフェッショナルと IT 管理者を対象としています。 COE での BI ソリューション アーキテクチャと、採用されているさまざまなテクノロジについて説明します。 Azure、Power BI、Excel などのテクノロジが含まれます。 これらをまとめて利用して、スケーラブルでデータドリブンのクラウド BI プラットフォームを提供することができます。

堅牢な BI プラットフォームの設計は、橋を造るのに似ています。変換されて強化されたソース データを、データ コンシューマーにつなぐ橋です。 このように複雑な構造を設計するにはエンジニアリング思考が必要ですが、それは設計することができる最もクリエイティブでやりがいのある IT アーキテクチャの 1 つです。 大規模な組織では、BI ソリューション アーキテクチャを次のように構成できます。

  • データ ソース
  • データ インジェスト
  • ビッグ データとデータの準備
  • データ ウェアハウス
  • BI セマンティック モデル
  • Reports

データ ソースからデータ インジェスト、ビッグ データ、ストア、データ ウェアハウス、BI セマンティック モデル、レポート作成、機械学習まで、BI プラットフォームのアーキテクチャを示す図。

プラットフォームでは、特定の要求をサポートする必要があります。 具体的には、そのスケールとパフォーマンスは、ビジネス サービスとデータ コンシューマーの期待を満たしている必要があります。 同時に、全体が完全にセキュリティで保護されている必要があります。 また、いつかは新しいデータやサブジェクト領域をオンラインにしなければらないのは確実なので、変更に適応するための十分な回復力を備えている必要があります。

フレームワーク

Microsoft では、当初からフレームワークの開発に投資することによって、システムと同様のアプローチを採用していました。 技術プロセスとビジネス プロセスのフレームワークにより、設計とロジックの再利用が向上し、一貫性のある結果が得られます。 また、多くのテクノロジを利用するアーキテクチャの柔軟性も提供され、反復可能なプロセスによってエンジニアリングのオーバーヘッドが合理化されて軽減されます。

適切に設計されたフレームワークによって、データ系列、影響分析、ビジネス ロジックのメンテナンス、分類の管理、ガバナンスの合理化についての可視性が向上することを学習しました。 また、開発が迅速化され、大規模なチーム間のコラボレーションの応答性と効率が向上しました。

この記事では、いくつかのフレームワークについて説明します。

データ モデル

データ モデルを使用すると、データの構造化方法やアクセス方法を制御できます。 ビジネス サービスとデータ コンシューマーにとって、データ モデルは BI プラットフォームとのインターフェイスです。

BI プラットフォームでは、次の 3 種類のモデルを提供できます。

  • エンタープライズ モデル
  • BI セマンティック モデル
  • 機械学習 (ML) モデル

エンタープライズ モデル

エンタープライズ モデルは、IT アーキテクトによって構築および保守されます。 それらは、ディメンション モデルまたはデータ マートと呼ばれることもあります。 通常、データは、ディメンション テーブルとファクト テーブルとしてリレーショナル形式で格納されます。 これらのテーブルには、多くのシステムから統合されたクレンジングおよび強化済みのデータが格納され、それらはレポート作成と分析に対する権限のあるソースを表します。

エンタープライズ モデルでは、レポート作成と BI に対して一貫性のある単一のデータ ソースが提供されます。 1 回だけ構築され、企業標準として共有されます。 ガバナンス ポリシーによってデータのセキュリティが確保されるため、顧客情報や財務情報などの機密データ セットへのアクセスは、ニーズに基づいて制限されます。 一貫性を確保する名前付け規則を採用することで、データと品質の信頼性がさらに高まります。

クラウド BI プラットフォームでは、Azure Synapse の Synapse SQL プールにエンタープライズ モデルをデプロイできます。 その後、Synapse SQL プールは、迅速かつ堅牢な分析情報を得るために組織が頼りにできるただ 1 つの真実になります。

BI セマンティック モデル

BI セマンティック モデルでは、エンタープライズ モデルに対するセマンティック レイヤーが表されます。 これらは、BI 開発者やビジネス ユーザーによって構築および保守されます。 BI 開発者は、エンタープライズ モデルからデータを調達するコア BI セマンティック モデルを作成します。 ビジネス ユーザーは、小規模の独立したモデルを作成したり、部署や外部のソースを使用してコア BI セマンティック モデルを拡張したりすることができます。 BI セマンティック モデルは、一般に、1 つのサブジェクト領域を対象とし、広く共有されています。

ビジネス機能は、データだけでなく、概念、リレーションシップ、ルール、標準が記述されている BI セマンティック モデルでも有効化されます。 このようにして、データのリレーションシップを定義し、ビジネス ルールを計算としてカプセル化する、直感的でわかりやすい構造が表されます。 また、詳細なデータ アクセス許可が適用されて、適切なユーザーが適切なデータにアクセスできることが保証されます。 重要なのは、クエリのパフォーマンスが向上し、テラバイトを超えるデータでも、非常に応答性の高い対話型分析が可能になることです。 エンタープライズ モデルと同様に、BI セマンティック モデルでは、一貫性を確保する名前付け規則が採用されています。

クラウド BI プラットフォームでは、BI 開発者は Microsoft Fabric 機能の Azure Analysis Services、Power BI Premium 容量に BI セマンティック モデルをデプロイできます。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。 現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。 新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

レポート作成と分析のレイヤーとして使用する場合は、Power BI にデプロイすることをお勧めします。 これらの製品では、さまざまなストレージ モードがサポートされており、データ モデル テーブルで、データをキャッシュしたり、DirectQuery (これは、基になるデータ ソースにクエリを渡すテクノロジです) を使用したりできます。 DirectQuery は、モデル テーブルで大きなデータ ボリュームが表される場合、またはほぼリアルタイムで結果を提供する必要がある場合に最適なストレージ モードです。 2 つのストレージ モードを組み合わせることができます。複合モデルでは、異なるストレージ モードを使用するテーブルが 1 つのモデルに結合されます。

クエリが頻繁に実行されるモデルでは、Azure Load Balancer を使用して、モデル レプリカ間にクエリの負荷を均等に分散できます。 また、アプリケーションをスケーリングし、可用性の高い BI セマンティック モデルを作成することもできます。

機械学習モデル

機械学習 (ML) モデルは、データ サイエンティストが構築および保守します。 それらは、ほとんどの場合、データ レイクの生ソースから開発されます。

トレーニング済みの ML モデルでは、データ内のパターンを明らかにすることができます。 多くの場合、それらのパターンを使用して、データを強化するために使用できる予測を行うことができます。 たとえば、購入行動を使用して顧客離反を予測したり、顧客をセグメント化したりすることができます。 予測結果をエンタープライズ モデルに追加して、顧客セグメント別に分析を行うことができます。

クラウド BI プラットフォームでは、Azure Machine Learning を使用して、ML モデルのトレーニング、デプロイ、自動化、管理、追跡を行うことができます。

データ ウェアハウス

BI プラットフォームの中核となるのは、エンタープライズ モデルがホストされているデータ ウェアハウスです。 それは、記録のシステムおよびハブとして、承認されたデータのソースであり、レポート、BI、データ サイエンスのエンタープライズ モデルを提供します。

基幹業務 (LOB) アプリケーションを含む多くのビジネス サービスでは、データ ウェアハウスを、エンタープライズの知識の権限があり管理されたソースとして利用できます。

Microsoft のデータ ウェアハウスは、Azure Data Lake Storage Gen2 (ADLS Gen2) と Azure Synapse Analytics でホストされています。

画像では、Azure Data Lake Storage Gen2 に接続する Azure Synapse Analytics が示されています。

  • ADLS Gen2 によって、Azure Storage は、Azure 上にエンタープライズ データ レイクを構築するための基盤となります。 それは、数百ギガビットのスループットを維持しながら、数ペタバイトの情報を提供するように設計されています。 また、低コストのストレージ容量とトランザクションも用意されています。 さらに、Hadoop と互換性のあるアクセスがサポートされており、Hadoop 分散ファイル システム (HDFS) の場合と同様に、データの管理とアクセスを行うことができます。 実際、Azure HDInsight、Azure Databricks、Azure Synapse Analytics のすべてで、ADLS Gen2 に格納されているデータにアクセスできます。 そのため、BI プラットフォームでは、生のソース データ、半処理データまたはステージング データ、および運用対応のデータを格納するのがよい方法です。 それを使用して、すべてのビジネス データを格納します。
  • Azure Synapse Analytics は、エンタープライズ データ ウェアハウスとビッグ データ分析がまとめられた分析サービスです。 サーバーレスのオンデマンド リソースまたはプロビジョニング済みのリソースを使用しながら大規模に、各自の条件で自由にデータを照会することができます。 Azure Synapse Analytics のコンポーネントである Synapse SQL は、完全な T-SQL ベースの分析がサポートされているので、ディメンション テーブルとファクトテーブルから成るエンタープライズ モデルをホストするのに理想的です。 簡単な Polybase T-SQL クエリを使用して、ADLS Gen2 からテーブルを効率的に読み込むことができます。 その後は、MPP の機能を利用して、高パフォーマンスの分析を実行できます。

ビジネス ルール エンジン フレームワーク

データ ウェアハウス レイヤーで実装できるビジネス ロジックをカタログ化するために、ビジネス ルール エンジン (BRE) フレームワークが開発されています。 BRE では多くのことを意味することができますが、データ ウェアハウスのコンテキストでは、リレーショナル テーブルで計算列を作成する場合に便利です。 これらの計算列は、通常、数学的計算または条件ステートメントを使用する式として表されます。

その目的は、ビジネス ロジックをコア BI コードから分離することです。 従来、ビジネス ルールは SQL ストアド プロシージャにハードコーディングされているので、ビジネス ニーズが変化した場合、それらの保守作業が必要になることがよくあります。 BRE では、ビジネス ルールは一度定義され、異なるデータ ウェアハウス エンティティに適用されるときに複数回使用されます。 計算ロジックの変更が必要な場合、更新する必要があるのは 1 か所だけであり、多数のストアド プロシージャを変更する必要はありません。 副次的な効果もあります。BRE フレームワークでは、実装されたビジネス ロジックに対する透明性と可視性が向上し、自己更新ドキュメントを作成する一連のレポートを通じて公開できます。

データ ソース

データ ウェアハウスを使用すると、実質的にはどのようなデータ ソースからでもデータを統合できます。 ほとんどの場合は、LOB データ ソースから構築されます。これは、通常、営業、マーケティング、財務などのサブジェクト固有のデータを格納するリレーショナル データベースです。これらのデータベースは、クラウドでホストすることも、オンプレミスに置くこともできます。 その他のデータ ソースはファイル ベースにすることができ、特に Web ログや IoT データはデバイスから供給できます。 さらに、サービスとしてのソフトウェア (SaaS) ベンダーからデータを供給することもできます。

Microsoft の一部の内部システムでは、生ファイル形式を使用して運用データが ADLS Gen2 に直接出力されます。 データ レイクに加えて、他のソース システムは、リレーショナル LOB アプリケーション、Excel ブック、他のファイルベースのソース、マスター データ管理 (MDM) とカスタム データ リポジトリで構成されています。 MDM リポジトリを使用すると、マスター データを管理して、データを権限のある標準化された検証済みのバージョンにすることができます。

データ インジェスト

定期的に、ビジネスの周期にしたがって、データがソース システムから取り込まれ、データ ウェアハウスに読み込まれます。 1 日に 1 回でも、さらに短い間隔でも可能です。 データ インジェストは、データの抽出、変換、読み込みに関係しています。 または、データの抽出、読み込み、変換のように逆になることもあります。 この違いにより、変換が行われる場所が異なります。 変換は、データのクレンジング、準拠、統合、標準化のために適用されます。 詳細については、「抽出、変換、読み込み (ETL)」を参照してください。

最終的な目標は、可能な限り迅速かつ効率的に、適切なデータをエンタープライズ モデルに読み込むことです。

Microsoft では、Azure Data Factory (ADF) が使用されています。 そのサービスを使用して、データの検証、変換、および外部ソース システムからデータ レイクへの一括読み込みが、スケジュールおよび調整されます。 カスタム フレームワークによって管理されることで、データは並列かつ大規模に処理されます。 さらに、トラブルシューティング、パフォーマンスの監視、特定の条件が満たされたときのアラート通知のトリガーをサポートするために、包括的なログ記録が行われます。

一方、Azure Databricks (Azure Cloud Services プラットフォーム用に最適化された Apache Spark ベースの分析プラットフォーム) では、データ サイエンスに固有の変換が実行されます。 また、Python ノートブックを使用して ML モデルの構築と実行も行われます。 これらの ML モデルからのスコアはデータ ウェアハウスに読み込まれて、予測がエンタープライズのアプリケーションやレポートと統合されます。 Azure Databricks では、データ レイク ファイルに直接アクセスするため、データをコピーまたは取得する必要がなくなります。

図では、Azure Data Factory によるデータのソーシングと、Azure Data Lake Storage Gen2 を介した Azure Databricks とのデータ パイプラインの調整が示されています。

インジェスト フレームワーク

構成のテーブルとプロシージャのセットとして、インジェスト フレームワークが開発されています。 高速かつ最小限のコードで大量のデータを取得するために、データドリブン アプローチがサポートされています。 つまり、このフレームワークにより、データ ウェアハウスに読み込むためのデータ取得プロセスが簡略化されます。

フレームワークは、ソースの種類、サーバー、データベース、スキーマ、テーブルに関連する詳細など、データの取り込み元とデータの取り込み先に関連する情報が格納されている構成テーブルに依存します。 この設計アプローチは、特定の ADF パイプラインまたは SQL Server Integration Services (SSIS) パッケージを開発する必要がないことを意味します。 代わりに、任意の言語で手順を記述し、実行時に動的に生成されて実行される ADF パイプラインを作成します。 したがって、データの取得は、簡単に運用化できる構成の作業になります。 従来は、ハードコーディングされた ADF または SSIS パッケージを作成するために、広範な開発リソースが必要でした。

インジェスト フレームワークは、アップストリーム ソース スキーマの変更を処理するプロセスが簡略化されるようにも設計されています。 ソース システムに新しく追加された属性を取得するためのスキーマの変更が検出された場合、構成データを手動または自動で簡単に更新できます。

オーケストレーション フレームワーク

データ パイプラインを運用化して調整するためのオーケストレーション フレームワークが開発されました。 そこでは、構成テーブルのセットに依存するデータドリブン デザインが使用されています。 これらのテーブルには、パイプラインの依存関係を記述するメタデータと、ソース データをターゲット データ構造にマップする方法が格納されます。 このアダプティブ フレームワークの開発にへの投資は、元が取れています。各データの移動をハードコーディングする必要がなくなりました。

データ ストレージ

データ レイクを使用すると、後でステージング データ変換と共に使用するために、大量の生データを格納できます。

Microsoft では、単一の正しい情報源として ADLS Gen2 が使用されています。 これには、ステージング済みデータおよび運用対応データと共に生データが格納されます。 それにより、スケーラビリティが高く、コスト効率に優れたビッグ データ分析用のデータ レイク ソリューションが提供されます。 高パフォーマンスのファイル システムの機能を大規模に組み合わせることで、データ分析ワークロード用に最適化され、分析情報までの時間が短縮されます。

ADLS Gen2 では、BLOB ストレージと高パフォーマンス ファイル システム名前空間の長所が提供され、それをきめ細かなアクセス許可を使用して構成します。

調整されたデータは、セキュリティ、ガバナンス、管理性を備えた、エンタープライズ モデル用の高パフォーマンスで拡張性の高いデータ ストアを提供するため、リレーショナル データベースに格納されます。 サブジェクト固有のデータ マートは、Azure Databricks または Polybase T-SQL クエリによって読み込まれる Azure Synapse Analytics に格納されます。

データの使用

レポート層では、データ ウェアハウスから供給されるエンタープライズ データがビジネス サービスによって使用されます。 また、アドホック分析やデータ サイエンス タスクのためには、データ レイク内のデータも直接アクセスされます。

データ レイク、エンタープライズ モデル、BI セマンティック モデルのすべてのレイヤーで、きめ細かいアクセス許可が適用されます。 アクセス許可により、データ コンシューマーはアクセスする権限を持つデータのみを表示できます。

Microsoft では、Power BI のレポートとダッシュボード、および Power BI のページ分割されたレポートが使用されています。 一部のレポート作成とアドホック分析は、Excel で行われます (特に財務報告の場合)。

データ モデルに関する参照情報を提供するデータ ディクショナリが公開されています。 ユーザーは、それらを使用して、BI プラットフォームに関する情報を入手できます。 ディクショナリではモデルの設計が文書化され、エンティティ、形式、構造体、データ系列、リレーションシップ、および計算に関する説明が提供されます。 データ ソースを容易に検出および理解できるように、Azure Data Catalog が使用されています。

通常、データ消費パターンは、ロールによって異なります。

  • データ アナリストは、コア BI セマンティック モデルに直接接続します。 コア BI セマンティック モデルに必要なデータとロジックがすべて含まれている場合は、ライブ接続を使用して Power BI のレポートとダッシュボードを作成します。 部門データでモデルを拡張する必要がある場合は、Power BI の複合モデルを作成します。 スプレッドシート形式のレポートが必要な場合は、コア BI セマンティック モデルまたは部門 BI セマンティック モデルを基にし、Excel を使用してレポートを生成します。
  • BI 開発者および運用レポート作成者は、エンタープライズ モデルに直接接続します。 Power BI Desktop を使用してライブ接続分析レポートを作成します。 また、運用タイプの BI レポートを Power BI のページ分割されたレポートとして作成したり、T-SQL を使用して Azure Synapse Analytics エンタープライズ モデルからのデータにアクセスするネイティブ SQL クエリを記述したり、DAX または MDX を使用して Power BI セマンティック モデルを作成したりすることもできます。
  • データ サイエンティストは、データ レイク内のデータに直接接続します。 Azure Databricks と Python ノートブックを使用して ML モデルを開発します。多くの場合、これは実験的であり、運用環境で使用するには専門的な知識が必要です。

図では、Power BI、Excel、Azure Machine Learning による Azure Synapse Analytics の使用が示されています。

関連するコンテンツ

この記事に関する詳細については、次のリソースを参照してください。

プロフェッショナル サービス

認定 Power BI パートナーによる、COE をセットアップする組織に対する支援を活用できます。 コスト効果の高いトレーニングやデータの監査が提供されます。 Power BI パートナーを手配するには、Power BI パートナー ポータルにアクセスしてください。

また、経験豊富なコンサルティング パートナーと仕事をすることができます。 Power BI の査定、評価、実装が支援されます。