チュートリアル: エンタープライズ データ シナリオを評価する
このチュートリアルでは、エンタープライズ シナリオの例におけるデータのニーズと課題を確認します。 Azure クラウド規模の分析が、最新のデータ プラットフォームを構築するための組織固有のニーズを満たす、スケーラブルで反復可能なフレームワークを提供する方法について説明します。
エンタープライズ データ シナリオを評価するための主要なコンポーネントは以下のとおりです。
- シナリオの理解
- データのニーズを把握する
- アーキテクチャ ソリューションを定義する
- ソリューションの根拠をテストする
- 将来の成長に備えて計画する
- リソースのデプロイ
シナリオの理解
Adatum Corporation は大規模な多国籍企業です。 Adatum では、本社と世界中の子会社に事業部門を集中しています。
Adatum の各子会社には、会計、マーケティング、営業、サポート、運用などの独自の事業部門があります。 これらの異なるグループが、それぞれ独自のデータを生成しています。 Adatum の多くの事業部門には、分析チームが従属しています。
当初は、Adatum の中央 IT 組織が、Adatum とその子会社が使用するデータ プラットフォームを提供しました。 時間の経過と共に、一部の事業部門では、ビジネス ニーズを満たすために独自のソリューションを実装してきました。 現在、エンタープライズ データ プラットフォームは、さまざまなクラウド サービスとオンプレミス ソリューションの組み合わせになっています。
この会社のビジョンは、一元化された分析プラットフォームを用意することです。 Adatum は、すべての企業データに対する単一のソースを必要としています。 しかし、非常に多くのさまざまな利害関係者に対して、1 つのテクノロジを使用することに同意するように説得できていません。 新しいデータが作成され、新しいオプションが使用可能になる速度を考えると、集中化のための計画の初期ドラフトでさえ、すぐに古くなってしまいます。 一方、会社の販売チームにとって、現在のソリューションはすでに役に立たなくなっており、新しい市場セグメントを開拓するために新しい分析を緊急に用意する必要があります。
Adatum は、このデータの問題を解決するために、Azure のクラウド規模の分析アーキテクチャ パターンを実装することに決めました。 会社では、Azure のクラウド規模の分析パターンによって、法人営業チームのデータ プラットフォームの移行をサポートできると確信しています。 このパターンでは、他の事業部門がデータ メッシュに参加する準備ができたときに対応するための十分な柔軟性も実現します。
データのニーズを把握する
Adatum の法人営業グループは、従来のエンタープライズ リソース プランニング (ERP) システムと顧客関係管理 (CRM) システムを使用して、販売トランザクションを処理しています。 これらのシステムのデータは、組織全体の利害関係者がデータにアクセスし、さまざまなプロジェクトのためにデータを強化できるようにするために、分析プラットフォームにエクスポートする必要があります。
アーキテクチャ ソリューションを定義する
この参照アーキテクチャでは、まず、すべての Azure のクラウド規模の分析実装に必要なデータ管理ランディング ゾーンをデプロイします。 次に、法人営業部門が使用する単一のデータ ランディング ゾーンを設定します。
データ管理ランディング ゾーン
Azure のクラウド規模の分析実装すべてにおける重要な点は、単一のデータ管理ランディング ゾーンです。 データ管理ランディング ゾーンには、Azure サブスクリプション内のすべてのデータ ランディング ゾーン間で共有されるリソースが含まれています。 このリソースには、ファイアウォールや Azure プライベート DNS ゾーンなどの共有ネットワーク コンポーネントが含まれます。 また、Azure Policy と Azure Purview を使用したデータとクラウドのガバナンスのためのリソースも含まれます。
データ統合
データ管理ランディング ゾーンでは、2 つのデータ ソースを取り込み、データを 1 つの共有データ ソースに統合します。
最初のデータ ソースは、顧客に関連するものです。 顧客データには、顧客の発注レコードと関連レコード (住所、連絡先、担当地域の割り当て、連絡履歴など) が含まれます。 このデータは、Adatum の CRM システムからインポートされます。
2 つ目の取り込まれるデータ ソースには、販売トランザクションが含まれています。 このデータには、トランザクション ヘッダー、品目の詳細、出荷レコード、支払いが含まれます。 これらのレコードはすべて、Adatum の ERP システムから取り込まれます。
注意
共有データ統合では、データの変換や強化は行われません。 これは単に、ソース システムからデータをコピーし、分析プラットフォームに追加するだけです。 このプロセスにより、多くのデータ製品は、ソース システムに余分な負担をかけることなく、スケーラブルな方法でデータを利用できます。
データ製品
この例では、Adatum に 1 つのデータ製品があります。 この製品は、共有データ統合からの生データを結合し、新しいデータセットに変換します。 そこから、ビジネス ユーザーは、Microsoft Power BI などのツールを使用して、より詳しい分析とレポートのためにデータを取得できます。
前の図で表されているのは Azure サービスの一部です。 この図は、このアーキテクチャでのリソースの編成方法に関する主要な概念を強調するために簡略化されています。
ソリューションの根拠をテストする
以降のセクションでは、企業が Azure のクラウド規模の分析の実装を計画する際に行う主要な決定の根拠について説明します。
販売トランザクションとお客様を独自のデータ ランディング ゾーンに配置しない理由
Azure のクラウド規模の分析の実装について最初に決定する必要があることの 1 つは、データ資産全体をランディング ゾーンに分割する方法です。 頻繁に相互通信するデータ ソリューションは、同じランディング ゾーンに含める強力な候補です。 データ ソリューションをグループ化すると、企業はピアリングされた仮想ネットワーク間でのデータの移動に関連するコストを削減できます。 この例では、販売トランザクション データが顧客データに頻繁にリンクされています。 そのため、これらの関連するデータ統合を同じデータ ランディング ゾーンに保存することが理にかなっています。
ランディング ゾーンに関するもう 1 つの考慮事項は、データを担当するチームを組織内でどのように調整するかです。
営業チームのみを新しいデータ プラットフォームに移行する理由
この例では、法人営業チームが、新しいクラウド規模の分析プラットフォームに最初に移行します。 ソリューションの優先事項はスケーラブルであることです。 他の事業部門を移行する準備が整ったら、さらにランディング ゾーンを追加してそのワークロードに対応できます。
将来の成長に備えて計画する
時間の経過と共にアーキテクチャにランディング ゾーンを追加することでスケーリングできます。 これらのランディング ゾーンは、仮想ネットワーク ピアリングを使用して、データ管理ランディング ゾーンおよび他のすべてのランディング ゾーンに接続します。 このメッシュ パターンにより、データセットとリソースをゾーン間で共有できます。 データセットを異なるゾーンに分割すると、ワークロードは Azure サブスクリプションとリソース全体に分散されます。 企業は Azure サービスの制限に達することを回避でき、データ資産を拡大し続けすることができます。
リソースのデプロイ
Adatum Corporation のデータ管理ランディング ゾーンと販売データ ランディング ゾーンの次のアーキテクチャを参照することで、この顧客シナリオをデプロイできます。
データ管理ランディング ゾーンのデプロイ
販売データ ランディング ゾーンのデプロイ
