データ・プラットフォーム- 分散型データ・プラットフォーム
データレイクハウスを使用して、デバイスからイベントおよびストリーミング・データをリアルタイムで収集および分析し、それを幅広いエンタープライズ・データ・リソースに関連付けて、必要なインサイトを得ます。
マーケティング、財務、ロジスティクスなど、組織のさまざまなチームをサポートし、強化するのに最適な方法。ドメイン固有のデータと柔軟に連携しながら、データを複製したり、データサイロを作成したりすることなく、ドメイン間の安全なデータ共有と消費を実現するにはどうすればよいでしょうか。
ドメイン主導のデータ・アーキテクチャを採用し、組織全体のチームや部門に、データを効率的に使用してビジネスに不可欠なデータ製品を開発するために必要な俊敏性と柔軟性を提供します。
このリファレンス・アーキテクチャは、戦略的な意図が測定可能な戦略的成果の創出を推進する、ビジネス・コンテキスト全体の中にテクノロジ・ソリューションを配置します。これらの結果は、新しい戦略的意図を生み出し、データ主導型の継続的なビジネス改善を効果的に実現します。
各ドメインは、上に示した上位レベルのプロセスに従って、ドメイン・データ製品を作成します。ドメイン主導のデータ・アーキテクチャは、完全に一元化されたデータ・プラットフォームやITチームなどの単一の競合点への依存を回避し、俊敏なイノベーションを促進し、各ドメイン内で信頼できるデータ製品を生成することで、組織が必要とする柔軟性を提供します。
各ドメインの目的は、ドメイン関連データを取得してから、他のドメインまたは最終データ・コンシューマによって消費されるデータ製品を生成することです。
次のドメインを指定できます。
- ソース連携: エンタープライズ・アプリケーションなどの関連するドメイン・データ・ソースからデータを直接ソーシングし、集約ドメインまたはコンシューマ連携ドメインによって消費されるデータ製品を生成します。これらのデータ製品は、特定のドメインの信頼できるソースを表します。データは、ドメイン内およびドメイン間で詳細でキュレートされ、基盤となります。
- 集計: ソース・アライメント・データを消費および結合し、再利用を促進し、重複を減らし、コンシューマ・アライメント・ドメインに必要な基本的なビジネス・ロジックを構成する、集計および付加価値のデータ製品を作成します。
- コンシューマ連携: ソース連携ドメインおよび集計ドメインからデータを消費して、特定のユース・ケースを提供するデータ製品を作成し、特定のドメイン内のデータ・コンシューマのニーズに対応します。
データ・ドメイン・チームとその主題の専門家(SME)は、データ製品のキュレーションに必要な技術を柔軟に選択し、長いテクノロジ選択プロセスの摩擦と複雑さを軽減し、データ製品の提供時間を短縮できます。
選択したテクノロジは、通常、セキュリティ、スケーラビリティ、自己回復性および高可用性要件に準拠するようにエンタープライズ・レベルで決定されます。このアーキテクチャでは、データ・レイクハウスで使用されるOracle Cloud Infrastructure (OCI)サービスを任意のドメインで活用できることを前提としています。
データ・ドメイン・チームは、多くの場合、自動化を使用してドメイン・アーキタイプをデプロイし、事前構成済のテクノロジを使用して新しいドメインを迅速にオンボーディングできるようにすると同時に、セキュリティなどのエンタープライズ・レベルの要件が強制されるようにします。
作成後は、データ製品が他のドメインまたはエンド・ユーザーおよびアプリケーションに提供されます。データ製品は、情報とインサイトを提供するために継続的にキュレートされます。
- データ・セット
- API
- ダッシュボード
- Streams
- 特定のニーズに対応するAIおよび機械学習(ML)モデル
このリファレンス・アーキテクチャでは、主にデータ共有を基盤となるメカニズムとして使用して、ドメイン間でデータ製品を提供および消費します。
Oracle Autonomous Data Warehouseは、データ共有を可能にし、Autonomous Data Warehouseインスタンス間またはDelta Sharingオープン・プロトコルに準拠したテクノロジからのバージョン管理されたデータとのライブ共有を可能にします。
機能アーキテクチャ
このアーキテクチャは、各ドメインがデータ・プラットフォーム全体のサブセットであり、各ドメインが使用するテクノロジとサービスを選択できる分散型プラットフォームを示しています。
このアーキテクチャでは、データレイクハウスを使用して、形状や形式に関係なくデータを格納および提供します。簡潔にするために、このアーキテクチャでは、使用可能なデータ・レイクハウス・サービスのサブセットを使用するいくつかのドメインが示されます。
データレイクハウス・アーキテクチャを使用する分散型データ・プラットフォームは、次のものを提供します。
- データ・ドメインがあらゆるユース・ケースのあらゆるタイプのデータを取り込んでキュレートできる、相互運用可能でモジュール型のレイクハウス・アーキテクチャ
- データ製品の作成をサポートするために必要なOracle Cloud Infrastructure (OCI)サービスを使用する各データ・ドメインの柔軟性
- データ共有、ストリーミング、API、ダッシュボード、またはアプリケーションを使用して安全に共有できるデータ製品のキュレーション
- データ製品の作成に俊敏性を持ち、データ製品の交換に必要なものを除き、ドメイン間の依存関係を軽減
- 受け入れられたデータ交換メカニズムと契約を使用してドメイン間でデータを交換することで、データ・ドメインの分離とデータ交換の複雑さを軽減
- 知識豊富なサブジェクト・エキスパート(SME)がドメインのデータとデータ製品をキュレートするため、データ・ガバナンスとデータの信頼性が向上
- Infrastructure as Code(IaC)を使用して新しいデータ・ドメインを簡単にオンボーディングし、事前構築およびテスト済のTerraformスタックを使用してデプロイメントを自動化
- データ・ドメイン・チームがデータ製品の作成に使用する特定のサービスを適切なサイズにするため、リソースとコスト効率が向上
- 特定のドメイン内のきめ細かなコスト管理オプションにより、データ・ドメインごとに適切なコスト・アカウンタビリティを実現
次の図は、機能アーキテクチャを示しています。簡潔にするために、データ・ドメインは4つのみ表示され、データ・ドメインで使用できるデータ・レイクハウス機能の一部のみが表示されます。
分散型データ・プラットフォームをデプロイする特定の業界および組織はデータ・ドメインを決定するため、このリファレンス・アーキテクチャではデータ・ドメインの定義方法は規定されません。記載されているデータドメインは一例にすぎません。
アーキテクチャは、すべてのドメインで使用される次の論理区分に重点を置いています。
- 接続、取込み、変換
データ・ソースに接続し、アーキテクチャの各データ・レイヤーで使用するためにデータを取り込み、調整します。
ソース・アライメント・データ・ドメインは、内部および外部のデータ・ソース、およびデータ製品を使用する他のドメインからデータを取得します。集計データ・ドメインおよびコンシューマ連携データ・ドメインは通常、他のドメイン・データ製品からデータをソーシングします。すべてのドメインで、関連するドメイン・データを外部ソースからソーシングできます。
- 永続化、キュレーション、作成
データのアクセスおよびナビゲーションを容易にし、現在のビジネス・ビューを表示します。リレーショナル・テクノロジの場合、データは、単純なリレーショナル、縦方向、ディメンションまたはOLAP形式で論理的または物理的に構造化できます。非リレーショナル・データの場合、このレイヤーには、分析プロセスからの出力、または特定の分析タスク用に最適化されたデータのいずれか1つ以上のデータ・プールが含まれます。
このレイヤーでは、各データ・ドメインが、データ製品の作成および公開に使用するデータをキュレーションします。通常、データは、青銅、銀、金に、その価値と品質に従ってデータを促進するメダリオン・アーキテクチャを使用してキュレーションおよび編成されます。
データ製品は、多くの場合、金または銀の層にあるデータを提供します。データ製品が粒度の細かいデータを提供する場合、そのデータは銀層から提供されます。データ製品が集計されたデータを提供する場合、またはすでにさらに拡張されたデータ・セットである場合は、通常、そのデータはゴールド・レイヤーから提供されます。
- 分析、学習、予測
コンシューマのデータの論理的なビジネス・ビューを抽象化します。この抽象化により、開発へのアジャイルなアプローチ、ターゲット・アーキテクチャへの移行、および複数のデータ・ソースからの単一のレポート・レイヤーのプロビジョニングが容易になります。
通常、各データ・ドメインには、ダッシュボード、データ・アプリケーション、ストリーミングまたはAPIの形式でキュレートされたデータを消費するドメイン・ユーザー、アプリケーション、システムなどの独自のデータ・コンシューマがあります。
データ・ドメインは、プロジェクト間データ共有を編成する方法として、他のデータ・ドメインおよび独自のドメイン内のデータ製品を提供できます。
アーキテクチャには、次の機能特性があります。
- 4つのデータ・ドメインが示されています。各ドメインは、そのドメインに固有のデータをキュレートし、そのキュレートされたデータに基づいてデータ製品を作成し、そのデータ製品を組織内の他のドメインまたは外部エンティティと共有します。
- ドメインは、内部データソース、他のドメインでキュレートされたデータ製品、または外部エンティティで共有されたデータからデータを取得できます。
- 顧客および財務ドメインは、内部システムからデータを取り込んでキュレーションし、独自のユーザーを持ち、他のドメインにサービスを提供するデータ製品をキュレートする、ソース・アライメント・ドメインです。
- リスク・ドメインは、顧客プロファイルと財務拡張トランザクションをそれぞれ取得するために、顧客ドメインと財務ドメインからデータを取得する集計ドメインです。このデータは、ダッシュボードで使用され、マーケティング・ドメインと共有される機械学習(ML)リスク・モデルおよびキー・パフォーマンス・インジケータ(KPI)を構築およびトレーニングするために使用されます。
- マーケティング・ドメインは、顧客プロファイルおよびリスク傾向データを顧客ドメインおよびリスク・ドメインから排他的に取得するコンシューマ連携ドメインです。このドメインは、最適なパーソナライズされたオファーを決定するセグメンテーションMLモデルを作成します。これらは、推論APIを使用して内部アプリケーションで使用できるようになり、バッチ推論結果は、アウトバウンド・キャンペーンを実行するパートナにデータ製品として共有されます。
- すべてのドメインは、データ・アセット、データ・エンティティおよびビジネス用語集に関する情報を含む共通のデータ・カタログを共有します。
- 各データ・ドメイン・チームとそのデータ製品所有者は、特定のデータ・カタログ・オブジェクトを保守します。セキュリティの分離は、どのチームがどのデータ・カタログ・エンティティを管理できるかを定義するOracle Cloud Infrastructure Identity and Access Managementポリシーを使用して保証されます。
- 組織全体で使用されるビジネス用語集用語などの一般的なデータ・カタログ・エンティティは、すべてのドメイン製品所有者で構成されるデータ・ガバナンス機関によって保守されます。
- データ製品は、検索可能であり、独自のセマンティクスを含み、ビジネス用語集に関連するように、データ・カタログでマークされます。
- データ共有は、ドメイン間でライブまたはバージョン管理されたデータ製品を共有するために使用されます。ライブ・データ製品またはバージョン管理データ製品の使用の選択は、各データ製品およびユース・ケースによって異なります。
アーキテクチャの主な機能コンポーネントは次のとおりです。
- ソース連携ドメイン: 顧客と財務
これらのドメインは、構造化データおよび非構造化データから導出された顧客および財務データのキュレーションに重点を置いています。
顧客ドメインでは、次の機能を使用して顧客プロファイル・データ製品を作成します。
- バッチ取込み(Oracle Cloud Infrastructure Data Integration): CRM、Webサイトおよび顧客対応アプリケーションからデータを取り込みます。
- バッチ処理(Oracle Cloud Infrastructure Data Integration、Oracle Cloud Infrastructure Data Flow): ロー・コードELTまたはコード中心ETL(あるいはその両方)を使用して構造化データおよび非構造化データを処理し、顧客プロファイル・データ製品を作成します。
- Serving (Oracle Autonomous Data Warehouse): リスクおよびマーケティング・ドメインに顧客プロファイル・データをキュレーションして提供します。
- Cloud Storage/Data Lake (Oracle Cloud Infrastructure Object Storage): 顧客のドキュメント、契約またはフォームを格納します。
- ビジュアル化/学習(Oracle Analytics Cloud): ドメイン・エンド・ユーザーが、ライフ・タイム・バリュー(LTV)、リテンション・レート、顧客満足度スコア(CSAT)、ネット・プロモータ・スコア(NPS)など、顧客関連のKPIを含む拡張分析を提供します。
- AIおよび生成AIサービス: Oracle Cloud Infrastructure Document Understandingは、お客様のフォームやドキュメントからデータを抽出し、Oracle Cloud Infrastructure Languageはテキスト・データを処理して、センチメント分析、名前付きエンティティ認識、またはテキスト分類でエンリッチします。
財務ドメインでは、次の機能を使用して、拡張財務トランザクション・データ製品を作成します。
- リアルタイム収集(Oracle Cloud Infrastructure GoldenGate): コア・バンキング・システムから財務トランザクションをほぼリアルタイムで非侵入的な方法で取得します。
- バッチ処理(Oracle Cloud Infrastructure Data Transforms): ローコードELTを使用して、支出カテゴリ、業者詳細または場所データで財務トランザクション・データを分類および拡張することにより、生データを検証、形成し、キュレートされたデータ製品に変換します。
- サービング(Oracle Autonomous Data Warehouse): キュレートされたデータを保持し、リスク・ドメインに拡張トランザクションを提供します。
- クラウド・ストレージ/データ・レイク(Oracle Cloud Infrastructure Object Storage): Oracle Autonomous Data Warehouseに格納されている財務トランザクション・レコードで参照される財務関連のフォームを格納します。
- 集計ドメイン: リスク
このドメインでは、機械学習モデルの構築、トレーニング、実行に重点を置き、顧客プロファイルや拡張トランザクションなどの内部データ、および経済データやマクロ経済データなどの外部データに基づいてリスクを検出します。
このドメインは、リスク分析と予防に特化した中小企業を擁し、そのデータ製品を必要とする他のすべてのドメインを提供します。ドメインには、拡張分析を使用する内部ユーザーがいますが、その作業の大部分は、機械学習バッチ推論結果を共有することです。たとえば、バッチ推論では、ライフスタイルと支出に基づいて金融サービスを購読している顧客のリスク傾向、および経済成長、インフレ、失業率などのマクロ経済的な要因を計算できます。
このドメインでは、次の機能を使用してリスク傾向データ製品を作成します。
- サービング(Oracle Autonomous Data Warehouse): MLモデルにフィードするだけでなく、バッチ推論結果を保存し、リスク関連のKPIを生成するために、変換と機能エンジニアリングを処理します。リスク集計ドメインは、顧客プロファイルおよび拡張トランザクション・データのコンシューマであり、それぞれ顧客ドメインと財務ドメインで共有されます。リスク傾向データをマーケティング・ドメインに提供します。
- 学習と予測(Oracle Cloud Infrastructure Data Science): 探索的データ分析、モデル開発、実行から継続的な改善まで、機械学習運用のライフサイクル全体をカバーします。これにより、リスク傾向の共有データの基礎となるバッチ推論結果が生成されます。
- 消費者連携ドメイン: マーケティング
このドメインは、パーソナライズされたターゲットを絞ったキャンペーンをサポートするためのデータのキュレーションに重点を置いています。他のドメインから共有されるデータを入力として使用し、API主導の推論を使用し、キャンペーンを実行してキャンペーン実行結果を共有するサードパーティ・マーケティング・パートナとデータを共有することで、セグメンテーションおよび次善のオファー・データをリアルタイムで提供します。
このドメインでは、次の機能を使用してキャンペーン・セグメンテーション・データ製品を作成します。
- バッチ処理(Oracle Cloud Infrastructure Data Transforms): データ共有から消費されるデータを処理およびシェイプします。また、データ共有からOracle Autonomous Data Warehouseへのデータのレプリケートにも使用できます。
- サービング(Oracle Autonomous Data Warehouse): 特定のキャンペーンのキュレートされたデータ、キャンペーン情報、セグメントおよびターゲット・オファーを格納します。
- クラウド・ストレージ/データ・レイク(Oracle Cloud Infrastructure Object Storage): ドメインで使用される非構造化データを格納します。
- ビジュアル化/学習(Oracle Analytics Cloud): ドメイン・エンド・ユーザーに、キャンペーン・ターゲットや実行KPIなどの拡張分析を提供します。
- 学習と予測(Oracle Machine Learning): 探索的データ分析からモデル・デプロイメントまで、機械学習操作のライフサイクル全体をカバーします。ユーザーは、AutoMLを使用して、モデルの構築とトレーニングを高速化します。キャンペーンに応じて、バッチ推論モデルの結果は、キャンペーンを実行する外部パートナへのデータ共有を使用するか、顧客対応アプリケーションによって呼び出されるリアルタイム推論のためにOracle Machine Learningデプロイメントを介して提供されることによって提供されます。
- API (Oracle Cloud Infrastructure API Gateway): Oracle Machine LearningデプロイメントAPIエンドポイントを保護および管理します。
- 共有サービス
データ・ガバナンスとセキュリティのためにすべてのドメインで使用されるサービスは次のとおりです。
- データ・ガバナンス(Oracle Cloud Infrastructure Data Catalog): ビジネス用語集およびすべてのドメイン・データ・エンティティをカタログ化し、データ製品であるものを分類して検出できるようにします。
- データ・セキュリティ(Oracle Data Safe、OCI Audit、OCI Logging、OCI Vault): すべてのドメインのセキュリティ状態を高めます。
アーキテクチャ・バリアント: 共有デプロイメント
分散型プラットフォームを共有データ・プラットフォームで実行できます。このプラットフォームでは、共通のサービス・インスタンス・セットで様々なデータ・ドメイン・チームがサポートされます。
プライマリ・アーキテクチャは、ドメインごとに最高レベルの分離と柔軟性を実現し、多数のドメインを持つ分散型データ・プラットフォームに対応するために高いスケーラビリティを備えています。分散型データ・プラットフォームの要件は異なる場合があり、特定のユース・ケースでは、異なるアーキテクチャ・パターン・バリアントが適している場合があります。
次の図は、分散プラットフォーム・パターンの共有デプロイメントのバリエーションを示しています。
単一のOracle Autonomous Data Warehouseインスタンスは、すべてのドメイン間で共有され、ロールベースのアクセス(RBAC)と異なるスキーマを使用して分離されます。レイクに存在するデータも、Oracle Cloud Infrastructure Identity and Access Managementポリシーおよび個別のコンパートメントを使用してドメインごとに分離されます。データ製品はそれぞれのスキーマ内でキュレートされ、カタログ化され、ライブおよびバージョン管理された共有を使用して共有されます。
データの取込みと処理のために、ドメインAとドメインBは同じOracle Cloud Infrastructure Data IntegrationとOracle Cloud Infrastructure Data Flowのインスタンスとアプリケーションを使用します。ドメインCおよびDには、データの取込みおよび処理に関する非常に固有の要件があるため、別々のインスタンスがあります。
ドメインAとBが単一の分析クラウド・インスタンスを共有し、RBACを使用して分離し、ドメインCとDが独自のサービス・インスタンスを使用する消費レイヤーにも同じロジックが適用されます。
ハイブリッド・ソリューションを使用することもできます。ドメインによっては、すべてのドメインに対して単一のインスタンスを使用するか、ドメインごとに1つのインスタンスを使用するかわりに、共有インスタンスを使用しているドメインもあれば、専用インスタンスを持っているドメインもあります。
このようなハイブリッド・ソリューションは、通常、一部のドメインでより要求の厳しいパフォーマンス要件、セキュリティ要件、高可用性要件、ディザスタ・リカバリ要件など、機能要件以外の要件によって実現され、他のドメインのワークロードに悪影響を及ぼすことなく、これらの要件に対処するために個別のインスタンスが必要です。
アーキテクチャ・バリアント: ハブとスポーク
多くの場合、さまざまな地域や国に子会社がある大企業は、すべての子会社のワークロードに対応する一元化されたデータ・プラットフォームを使用せずに、データ・プラットフォームを独立して実行する必要がありますが、グローバルな可視性とキー・パフォーマンス・インジケータ(KPI)のために本社とデータを共有する必要があります。
分散型データ・プラットフォームは、このシナリオに適したソリューションです。ハブ(本社)と複数のスポーク(子会社)があり、データを安全かつ効率的に交換する必要があります。
このバリアントは、ハブおよびスポーク・パターンの例として地理を使用しますが、持株会社とその子会社などの他の例にも同じパターンを適用できます。
スポークは、ハブと同じテナンシまたは異なるテナンシにデプロイできます。
次の図は、異なるリージョンにデプロイされ、Delta Sharingプロトコルで有効になっているバージョン管理されたシェアを使用してデータを交換するハブといくつかのスポークを示しています。この図は、サービング・エンジンの機能コンポーネントのみを示しています。残りの機能アーキテクチャは、主要な機能アーキテクチャに示されているものと似ています。
データは安全に交換され、インターネットを介してリージョン間で転送されるため、レイテンシを考慮する必要があります。スポークとハブの間で共有されるデータ製品が、大量の粒度の細かいデータではなく、集計されたデータ・セットとKPIである場合、このパターンは簡単にデプロイ、メンテナンスおよび操作できます。
別の方法として、Oracle Autonomous Databaseのクラウド・リンクを使用すると、他のリージョンにある場合でも、インスタンス間でシームレスなデータ共有が可能になります。
リージョン間のデータ共有では、ハブAutonomous Data Warehouseインスタンスによってシームレスにアクセスできるように、ソースOracle Autonomous Data Warehouseインスタンスを宛先リージョンにクローニングする必要があります。クローンは、手動または自動で定期的にリフレッシュできるため、ハブAutonomous Data Warehouseはスポークで共有されている最新のデータ製品を消費できます。
ハブは、スポークキュレートのデータ・セット全体のサブセットであるデータ製品を消費する可能性が高いため、スポークは、ハブと共有するデータ製品を保持する専用のAutonomous Data Warehouseインスタンスのみを持ち、リフレッシュ可能クローンを最適化できます。
リフレッシュ可能クローンのネットワーク・トラフィックは、Oracleバックボーンを介してルーティングされ、スポークAutonomous Data Warehouseインスタンスに存在する大規模なデータ製品を移動する際のレイテンシが低く、帯域幅が高くなります。
バージョン管理されたシェアまたはクラウドリンクの使用の選択は、主に機能要件ではなくパフォーマンスとコストの影響を受けます。
使用するオプションに関係なく、ハブとスポークには独自のローカル・データ・プラットフォームがあり、このアーキテクチャで示される分散型アプローチを使用できます。
アーキテクチャ・バリアント: 異種データ・エコシステム
ただし、同じアーキテクチャを使用して、異なるテクノロジを使用して異なる目的でデータを共有する異なる組織を持つ異種データ・エコシステムをサポートできます。
ユースケースには、研究目的で匿名化されたデータを大学と共有する病院や、自動車メーカーと部品データを共有するサプライヤーなどがあります。
Oracle Autonomous Data Warehouseをサービング・エンジンとして使用する組織は、Delta Sharingオープン・プロトコルをサポートする他のテクノロジから共有データを提供および使用できます。
デルタ共有は、幅広いサポートと、データを安全に提供して消費するシンプルさのために、データ・エコシステムをサポートするのに適しています。
また、APIやデータ・ストリーミングなどの他のメカニズムを使用してデータを共有することもできます。
物理アーキテクチャ
この分散型データ・プラットフォームの物理アーキテクチャでは、次のものがサポートされます。
- Oracle Cloud Infrastructure Identity and Access Managementコンパートメントおよびポリシーを使用したドメインの分離。各チームがコンパートメント内のクラウド・リソースのみを使用およびデプロイする権限を持っている場合
- より高い分離レベルとセキュリティ体制の強化を実現する、それぞれのワークロードVCNsでのドメイン・デプロイメント
- 自分のコンパートメントおよびVCNsにデプロイされたクラウド・リソースを使用して、ドメイン・チームによって管理されるデータの取込み、ストレージ、処理および処理プロセス
- スケーラビリティ、高可用性、ディザスタ・リカバリ、セキュリティ、サービス・レベル目標(SLO)などの非機能要件のサポート。各ドメイン・チームは、固有のドメイン要件に応じて個別のクラウド・リソースを使用するためです。
- ドメイン・クラウド・リソースの使用量ごとにきめ細かいコスト制御を実現
- プライベート・サブネットにデプロイされたプライベート・エンドポイントとインスタンスを使用して、完全にセキュアでプライベートなエンドツーエンドのトラフィック
また、一部のサービスは、企業のセキュリティ・ルールに準拠しながら、ドメインごとにパブリック・エンドポイントとともにデプロイすることもできます。
- Oracle Autonomous Data Warehouseで有効にされるデータ共有は、ライブ共有またはバージョン管理された共有のいずれかを使用し、ユースケースに応じて最新データまたはバージョン管理されたデータを提供するかどうかを使用します
- Oracle Cloud Infrastructure Identity and Access Managementポリシーを使用してドメインごとに分離されたデータ・カタログ・サブ・エンティティを使用して、すべてのドメインの一元化されたデータ・カタログ(検出可能なデータ製品を除く)
- 既存のデータ・ドメインに影響を与えずにInfrastructure as Code(IaC)の自動化を使用することで、新しいドメインごとにオンボーディングできるため、拡張性の高い導入が可能
次の図は、このリファレンス・アーキテクチャを示しています。
物理アーキテクチャの図は、ドメインごとにクラウド・ネットワーキングおよびサービスがどのようにレイアウトされるかを示す2つのドメインを示しています。通常、特定の非機能要件によって例外が発生しないかぎり、すべてのドメイン・ネットワーキングおよびコンパートメントは同じです。
物理アーキテクチャの設計:
- ハブVCNと、そのドメインのワークロードを含むデータ・ドメインごとに1つのVCNを利用します。
- Oracle Cloud Infrastructure FastConnectとサイト間VPNの両方を使用してオンプレミス接続を活用し、冗長性を実現
- オンプレミスおよびインターネットからのすべての受信トラフィックを、最初にハブVCNにルーティングし、次にデータ・ドメイン・ワークロードVCNsにルーティングします
- 転送中および保存中のすべてのデータを保護します。
- プライベート・エンドポイントを使用してサービスをデプロイし、セキュリティ体制を強化します
- VCNsを複数のプライベート・サブネットに分離して、セキュリティ・ポスチャを高めます
- リソース分離のための各ドメインのコンパートメントを提供します。
- クラウド・リソースが他のドメインVCNsへのインバウンドおよびアウトバウンド・トラフィックをサポートするように、動的ルーティング・ゲートウェイ(DRG)を使用します
- セキュリティを強化するためにAutonomous Data Warehouseインスタンスをデータ・プライベート・サブネットに配置しますが、そのトラフィックを有効にするためにルートが確立されている場合、他のドメインAutonomous Data Warehouseインスタンスからライブおよびバージョニングされた共有を提供および消費できます
シンプルさのために、このデプロイメントでは説明されていない潜在的な設計の改善には、次のものがあります。
- 完全なCIS準拠ランディング・ゾーンの活用
- ハブVCNにネットワーク・ファイアウォールをデプロイして、すべてのトラフィックを検査し、ポリシーを適用することで、全体的なセキュリティ状態を改善します
レコメンデーション
データを安全に共有するには、次の推奨事項を開始点として使用します。実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。
Oracle Autonomous Data Warehouse
このアーキテクチャでは、共有インフラストラクチャ上でOracle Autonomous Data Warehouseを使用します。
- レイクハウスのメダリオン・アーキテクチャを使用し、シルバー(粒状、拡張)およびゴールド(エンリッチ、集約)レイヤーに基づいてデータ製品を作成します。
- Autonomous Data Warehouseを異機種間データ共有のネイティブ・サポートとともに使用して、よりシンプルで安全で信頼性の高いアーキテクチャを提供することで、データ製品の共有を検討してください。
- Autonomous Data Warehouseで公開されている外部データを外部表またはハイブリッド表として共有して、バージョン管理された共有またはライブ共有のセキュリティ機能を活用することを検討してください。
- データ製品表のビューを作成して、ベース・オブジェクト(表)を共有オブジェクト(ビュー)と区別することを検討してください。
- ライブ共有でデータを共有する際のセキュリティを強化するには、基礎となるスキーマおよび表とは異なる名前空間および名前値を使用して内部オブジェクト名を非表示にすることを検討してください。
- クラウド・リンクとのライブ共有を使用する際のセキュリティを強化するには、データ・セット登録管理者に、ユース・ケースに対して最も制限の多いデータ・セット範囲を定義してもらいます。
- クラウド・リンクとのライブ共有を使用する場合は、データ・コンシューマ問合せのパフォーマンスを向上させるためにキャッシュを有効にすることを検討してください。
- 大量のデータ製品を含むクラウド・リンクとのライブ共有を使用する場合は、データ・コンシューマのパフォーマンスとワークロードの分離を向上させるために、問合せをリフレッシュ可能なクローンにオフロードすることを検討してください。
- 多数のドメインAutonomous Data Warehouseインスタンスがある場合、またはインスタンスのコンピュート要件が高い場合は、エラスティック・プールに統合することを検討してください。
OCIオブジェクト・ストレージ
このアーキテクチャでは、高スケーラビリティで耐久性のあるOracle Cloud Infrastructure Object Storageをレイク・ストレージとして使用します。
Oracle Cloud Infrastructure Identity and Access Managementポリシーを使用してワークロードを分離するために、データ・ドメインとデータ・ドメイン内のチームを編成するために、複数の粒度の細かいコンパートメントを使用することを検討してください。
Oracle Cloud Infrastructure Data Catalog
このアーキテクチャでは、Oracle Cloud Infrastructure Data Catalogを使用して、データ製品の技術メタデータ、ビジネス・メタデータおよび運用メタデータを管理し、自己検出できるようにします。
- すべてのドメインに対して単一のデータ・カタログ・インスタンスを使用して、メタデータおよびデータ製品ガバナンスを一元化することを検討してください
- ドメイン・ユーザーにデータ・アセットのみの管理アクセス権を付与することを検討します。
- 組織全体で保守されているデータ製品を検索できるように、すべてのユーザーに読取りアクセス権を付与することを検討します。
- カスタム・プロパティを使用して、データ製品の所有者、可用性、最終更新日、バージョンなどのプロパティで運用メタデータをエンリッチすることを検討してください。
データ・ドメインのデプロイメント
このアーキテクチャでは、データレイクハウスのパターンと利用可能なOCIサービスを使用して、エンドツーエンドのデータ、分析、AIワークロードをサポートします。
- ドメインごとに個別のVCNsを使用してドメインを分離することを検討し、クラウド・リソースのデプロイ時にセキュリティ・ポスチャとドメインの柔軟性を高めます。
- コンパートメントとIAMポリシーを利用して、各ドメインが使用する様々なOCIサービスを分離することを検討してください。
データ製品共有
- APIを使用してデータ製品を提供する必要がある場合は、Oracle REST Data Servicesの使用を検討してください。
- Oracle REST Data Servicesを使用してデータ製品を共有する場合は、Oracle Cloud Infrastructure API Gatewayを使用してAPIを保護することを検討してください。
- データ製品をストリーミングする必要がある場合は、Oracle Cloud Infrastructure GoldenGateおよびOracle Cloud Infrastructure Streamingの使用を検討してください。
詳細の参照
このアーキテクチャの機能および関連するアーキテクチャについてさらに学習します。