Plate-forme de données - Plate-forme de données décentralisée
Utilisez un data lakehouse pour collecter et analyser des données d'événements et de diffusion en continu à partir d'appareils en temps réel et les mettre en corrélation avec un large éventail de ressources de données d'entreprise pour obtenir les informations dont vous avez besoin.
Comment mieux soutenir et responsabiliser les différentes équipes de votre entreprise, telles que le marketing, la finance ou la logistique, avec la flexibilité de travailler avec leurs données spécifiques au domaine tout en permettant le partage et la consommation de données interdomaines sécurisés sans dupliquer les données et créer des silos de données ?
Adoptez une architecture de données orientée domaine qui fournit aux équipes et aux services de toute l'entreprise l'agilité et la flexibilité nécessaires pour utiliser efficacement leurs données et développer les produits de données essentiels à leur activité.
Cette architecture de référence positionne la solution technologique dans le contexte commercial global, où les intentions stratégiques favorisent la création de résultats stratégiques mesurables. Ces résultats génèrent de nouvelles intentions stratégiques, apportant ainsi des améliorations continues et basées sur les données.
Chaque domaine suit indépendamment le processus de haut niveau indiqué ci-dessus pour créer ses produits de données de domaine. Les architectures de données orientées domaine offrent la flexibilité dont les entreprises ont besoin en évitant de se fier à un point de contention unique, tel qu'une plate-forme de données entièrement centralisée et une équipe informatique, et en favorisant l'innovation agile pour produire des produits de données fiables dans chaque domaine.
plate-forme de données décentralisée-présentation-oracle.zip
L'objectif de chaque domaine est d'acquérir des données relatives au domaine, puis de produire des produits de données qui sont consommés par d'autres domaines ou des consommateurs de données finaux.
Les domaines peuvent être :
- Aligné sur la source : Il extrait les données directement à partir des sources de données de domaine pertinentes, telles que les applications d'entreprise, et produit des produits de données qui sont utilisés par des domaines agrégés ou alignés sur le consommateur. Ces produits de données représentent la source d'informations pour un domaine particulier. Les données sont granulaires, organisées et fondamentales dans et entre les domaines.
- Agrégation : Consomme et combine des données alignées sur la source, créant des produits de données agrégés et à valeur ajoutée qui favorisent la réutilisation, réduisent les doublons et comprennent la logique métier fondamentale nécessaire aux domaines alignés sur le consommateur.
- Aligné sur le consommateur : Consomme des données provenant de domaines alignés sur la source et agrégés pour créer des produits de données qui répondent à des cas d'utilisation spécifiques et aux besoins du consommateur de données au sein d'un domaine donné.
Les équipes de domaine de données et leurs experts en la matière (PME) ont la flexibilité de choisir la technologie nécessaire pour organiser leurs produits de données, ce qui réduit la friction et la complexité des longs processus de sélection de technologies et le temps de livraison des produits de données.
La technologie choisie est généralement déterminée au niveau de l'entreprise de sorte qu'elle respecte les exigences de sécurité, d'évolutivité, de résilience et de haute disponibilité. Cette architecture suppose que tout service Oracle Cloud Infrastructure (OCI) utilisé avec un data lakehouse peut être exploité par n'importe quel domaine.
Les équipes de domaine de données utilisent souvent l'automatisation pour déployer des archétypes de domaine, ce qui rend les technologies préconfigurées disponibles pour intégrer rapidement de nouveaux domaines tout en veillant à ce que les exigences au niveau de l'entreprise, telles que la sécurité, soient appliquées.
Une fois créés, les produits de données sont ensuite distribués à d'autres domaines ou utilisateurs finaux et applications. Les produits de données sont continuellement organisés pour fournir des informations et des informations.
- Ensembles de données
- API
- Tableaux de bord
- Flux
- Modèles d'IA et de machine learning (ML) répondant à un besoin spécifique
Cette architecture de référence utilise principalement le partage de données comme mécanisme sous-jacent pour fournir et consommer des produits de données entre les domaines.
Oracle Autonomous Data Warehouse permet le partage de données et le partage en direct de données entre les instances Autonomous Data Warehouse ou avec des données avec numéro de version de toute technologie conforme au protocole ouvert Partage Delta.
Architecture fonctionnelle
Cette architecture représente une plate-forme décentralisée où chaque domaine est un sous-ensemble de la plate-forme de données globale et où chaque domaine peut choisir les technologies et les services utilisés.
L'architecture utilise un data lakehouse pour stocker et fournir des données, quelle que soit leur forme. Par souci de simplicité, l'architecture représentera quelques domaines qui utilisent un sous-ensemble des services de data lakehouse disponibles.
Une plate-forme de données décentralisée qui utilise une architecture de data lakehouse offre les avantages suivants :
- Architecture de lakehouse interopérable et modulaire dans laquelle les domaines de données peuvent ingérer et organiser n'importe quel type de données pour n'importe quel cas d'utilisation
- Flexibilité pour chaque domaine de données afin d'utiliser les services Oracle Cloud Infrastructure (OCI) nécessaires pour prendre en charge la création de leurs produits de données
- Curation des produits de données pouvant être partagés en toute sécurité à l'aide du partage de données, de la diffusion en continu, des API, des tableaux de bord ou des applications
- Agilité dans la création de produits de données, réduisant les dépendances interdomaines à l'exception de celles requises pour l'échange de produits de données
- Isolation accrue des domaines de données et complexité réduite de l'échange de données grâce à l'utilisation de mécanismes et de contrats d'échange de données acceptés pour échanger des données entre domaines
- Amélioration de la gouvernance des données et de la confiance dans les données, car des experts compétents organisent les données et les produits de données pour leurs domaines
- Facilité d'intégration de nouveaux domaines de données à l'aide de l'infrastructure en tant que code (IaC) pour automatiser le déploiement à l'aide de piles Terraform prédéfinies et testées
- Efficacité des ressources et des coûts en tant qu'équipes de domaine de données pour dimensionner correctement les services spécifiques qu'elles utilisent pour créer des produits de données
- Responsabilité des coûts appropriée pour chaque domaine de données avec la possibilité d'un contrôle affiné des coûts dans les domaines spécifiques
Le schéma suivant illustre l'architecture fonctionnelle. Pour plus de simplicité, seuls quatre domaines de données sont affichés et seules certaines des fonctionnalités de data lakehouse pouvant être utilisées par les domaines de données sont affichées.
décentralisé-plateforme-données-logique-oracle.zip
Etant donné que le secteur et l'organisation qui déploie une plate-forme de données décentralisée déterminent les domaines de données, cette architecture de référence ne prescrit pas comment les domaines de données doivent être définis. Les domaines de données représentés ne sont qu'un exemple.
L'architecture se concentre sur les divisions logiques suivantes utilisées par tous les domaines :
- Connexion, ingestion et transformation
Se connecte aux sources de données, ingère et affine leurs données pour les utiliser dans chacune des couches de données de l'architecture.
Les domaines de données alignés sur les sources s'appuient sur des sources de données internes et externes, ainsi que sur d'autres domaines qui utilisent leurs produits de données. Les domaines de données agrégés et alignés sur le consommateur extraient généralement leurs données d'autres produits de données de domaines. Tous les domaines peuvent obtenir des données de domaine pertinentes à partir de sources externes.
- Conserver, organiser, créer
Facilite l'accès aux données et leur navigation pour afficher la vue métier actuelle. Pour les technologies relationnelles, les données peuvent être structurées logiquement ou physiquement sous des formes relationnelles, longitudinales, dimensionnelles ou OLAP simples. Pour les données non relationnelles, cette couche contient un ou plusieurs pools de données, soit issus d'un processus analytique, soit optimisés pour une tâche analytique spécifique.
Dans cette couche, chaque domaine de données organise les données qu'il utilise pour créer et exposer des produits de données. Habituellement, les données sont organisées et organisées en utilisant une architecture de médaillon qui favorise les données du bronze, à l'argent, à l'or, en fonction de sa valeur et de sa qualité.
Les produits de données servent souvent des données qui se trouvent dans la couche d'or ou d'argent. Si le produit de données fournit des données granulaires, ces données sont fournies à partir de la couche d'argent. Si le produit de données sert des données qui sont agrégées ou qui constituent déjà un autre ensemble de données augmenté, ces données sont généralement fournies à partir de la couche d'or.
- Analyser, apprendre, prévoir
Abstraction de la vue logique métier des données pour les destinataires. Cette abstraction facilite les approches agiles du développement, de la migration vers l'architecture cible et de la fourniture d'une seule couche de reporting à partir de plusieurs sources de données.
Chaque domaine de données a généralement ses propres consommateurs de données, tels que les utilisateurs de domaine, les applications ou les systèmes qui utilisent des données organisées sous forme de tableaux de bord, d'applications de données, de flux en continu ou d'API.
Les domaines de données peuvent servir de produits de données à d'autres domaines de données et au sein de leur propre domaine comme moyen d'organiser le partage de données entre projets.
L'architecture présente les caractéristiques fonctionnelles suivantes :
- Quatre domaines de données sont représentés. Chaque domaine organise les données propres à ce domaine, crée des produits de données basés sur ces données organisées, puis partage ces produits de données avec d'autres domaines au sein de l'organisation ou avec des entités externes.
- Les domaines peuvent s'approvisionner en données à partir de sources de données internes, de produits de données organisés par d'autres domaines ou de données partagées par des entités externes.
- Les domaines Client et Finances sont des domaines alignés sur la source qui assimilent et organisent des données à partir de systèmes internes, ont leurs propres utilisateurs et organisent des produits de données pour servir à d'autres domaines.
- Le domaine Risque est un domaine agrégé qui extrait des données des domaines Client et Finances pour obtenir des profils Client et des transactions financières augmentées, respectivement. Ces données sont utilisées pour créer et entraîner des modèles de risque de machine learning (ML) et des indicateurs clés de performance (KPI) utilisés par les tableaux de bord et partagés avec le domaine Marketing.
- Le domaine Marketing est un domaine aligné sur le consommateur qui extrait exclusivement les profils client et les données de propension au risque des domaines Client et Risque. Ce domaine crée des modèles de segmentation ML qui déterminent les meilleures offres personnalisées. Elles sont mises à la disposition des applications internes à l'aide d'API d'inférencement et les résultats d'inférencement par lots sont partagés en tant que produit de données aux partenaires qui exécutent des campagnes sortantes.
- Tous les domaines partagent un catalogue de données commun qui contient des informations sur leurs ressources de données, leurs entités de données et leurs glossaires métier.
- Chaque équipe de domaine de données et leurs propriétaires de produit de données gèrent leurs objets de catalogue de données spécifiques. L'isolement de la sécurité est garanti par l'utilisation de stratégies Oracle Cloud Infrastructure Identity and Access Management qui définissent l'équipe pouvant gérer les entités de catalogue de données.
- Les entités de catalogue de données communes, telles que les termes de glossaire métier utilisés dans l'ensemble de l'organisation, sont gérées par un organisme de gouvernance des données composé de tous les propriétaires de produits de domaine.
- Les produits de données sont marqués dans le catalogue de données afin qu'ils puissent faire l'objet d'une recherche, qu'ils contiennent leur propre sémantique et qu'ils soient liés au glossaire métier.
- Le partage de données est utilisé pour partager des produits de données en direct ou avec numéro de version entre des domaines. Le choix d'utiliser des produits de données en direct ou avec numéro de version dépend de chaque produit de données et cas d'emploi.
Les principaux composants fonctionnels de l'architecture sont les suivants :
- Domaines alignés sur la source : Client et Finance
Ces domaines se concentrent sur la conservation des données clients et financières dérivées de données structurées et non structurées.
Le domaine Customer utilise les fonctionnalités suivantes pour créer un produit de données Customer Profiles :
- Assimilation par lots (Oracle Cloud Infrastructure Data Integration) : ingère les données des applications CRM, de site Web et orientées client.
- Traitement par lots (Oracle Cloud Infrastructure Data Integration, Oracle Cloud Infrastructure Data Flow) : traite les données structurées et non structurées à l'aide d'ELT low code, d'ETL centré sur le code ou des deux pour créer les produits de données Profils client.
- Service (Oracle Autonomous Data Warehouse) : organise et fournit des données de profils client aux domaines de risque et de marketing.
- Cloud Storage/Data Lake (Oracle Cloud Infrastructure Object Storage) : stocke les documents, les contrats ou les formulaires client.
- Visualize/Learn (Oracle Analytics Cloud) : fournit aux utilisateurs finaux du domaine des analyses augmentées, y compris des indicateurs clés de performance liés aux clients, tels que la durée de vie, le taux de rétention, le score de satisfaction client et le score de promoteur net.
- Services d'IA et d'IA générative : Oracle Cloud Infrastructure Document Understanding extrait des données à partir de formulaires et de documents client et Oracle Cloud Infrastructure Language traite des données texte et les enrichit avec une analyse des sentiments, une reconnaissance d'entité nommée ou une classification de texte.
Le domaine Finance utilise les fonctionnalités suivantes pour créer un produit de données Transactions financières augmentées :
- Assimilation en temps réel (Oracle Cloud Infrastructure GoldenGate) : capture les transactions financières à partir du système bancaire central quasiment en temps réel et de manière non intrusive.
- Traitement par lots (transformations de données Oracle Cloud Infrastructure) : à l'aide d'ELT low code, il valide, façonne et transforme les données brutes en un produit de données organisé en catégorisant et en enrichissant les données de transactions financières avec des catégories de dépenses, des détails sur les commerçants ou des données de localisation.
- Service (Oracle Autonomous Data Warehouse) : contient des données organisées et fournit des transactions augmentées au domaine de risque.
- Cloud Storage/Data Lake (Oracle Cloud Infrastructure Object Storage) : stocke les formulaires liés aux finances qui sont référencés dans les enregistrements de transaction financière stockés dans Oracle Autonomous Data Warehouse.
- Domaine agrégé : Risque
Ce domaine se concentre sur la création, la formation et l'exécution de modèles de machine learning pour détecter les risques en fonction de données internes, telles que les profils client et les transactions augmentées, et de données externes telles que les données économiques et macroéconomiques.
Ce domaine a des PME spécialisées dans l'analyse et la prévention des risques et dessert tous les autres domaines qui ont besoin de ses produits de données. Le domaine a des utilisateurs internes qui utilisent l'analyse augmentée, mais la majorité de leur travail consiste à partager les résultats d'inférence de batch de machine learning. Par exemple, l'inférence par lots peut calculer la propension au risque des clients souscrivant à des services financiers en fonction de leur mode de vie et de leurs dépenses, ainsi que de facteurs macroéconomiques, tels que la croissance économique, l'inflation ou le taux de chômage.
Ce domaine utilise les fonctionnalités suivantes pour créer un produit de données de propension au risque :
- Service (Oracle Autonomous Data Warehouse) : traite les transformations et l'ingénierie des fonctionnalités pour alimenter les modèles d'apprentissage automatique, ainsi que pour stocker les résultats d'inférence par lots et produire des KPI liés aux risques. Le domaine d'agrégation Risque est un consommateur des profils client et des données de transactions augmentées, partagées respectivement par les domaines Client et Finances. Il fournit des données de propension au risque au domaine Marketing.
- Learn and Predict (Oracle Cloud Infrastructure Data Science) : couvre l'intégralité du cycle de vie des opérations d'apprentissage automatique, de l'analyse exploratoire des données au développement, en passant par l'exécution et l'amélioration continue des modèles. Il produit des résultats d'inférence par lots qui constituent la base des données partagées sur la propension au risque.
- Domaine aligné sur le consommateur : Marketing
Ce domaine se concentre sur la conservation des données pour prendre en charge des campagnes personnalisées et ciblées. Il utilise les données partagées à partir d'autres domaines en entrée et fournit la segmentation et les données de la meilleure offre suivante en temps réel en utilisant l'inférence basée sur les API et en partageant des données avec des partenaires marketing 3rd parties qui exécutent des campagnes et partagent les résultats d'exécution de la campagne.
Ce domaine utilise les fonctionnalités suivantes pour créer des produits de données de segmentation de campagne :
- Traitement par lots (transformations de données Oracle Cloud Infrastructure) : traite et forme les données consommées à partir des partages de données. Il peut également être utilisé pour répliquer des données des partages de données dans Oracle Autonomous Data Warehouse.
- Service (Oracle Autonomous Data Warehouse) : stocke les données organisées, les informations sur les campagnes, les segments et les offres ciblées pour une campagne donnée.
- Cloud Storage/Data Lake (Oracle Cloud Infrastructure Object Storage) : stocke toutes les données non structurées utilisées par le domaine.
- Visualisation/apprentissage (Oracle Analytics Cloud) : sert les analyses augmentées des utilisateurs finaux du domaine, telles que les cibles de campagne et les indicateurs clés de performance d'exécution.
- Learn and Predict (Oracle Machine Learning) : couvre le cycle de vie complet des opérations de machine learning, de l'analyse exploratoire des données au déploiement de modèles. Les utilisateurs tirent parti de AutoML pour accélérer la création et l'entraînement de modèles. Selon les campagnes, les résultats du modèle d'inférence de batch sont servis en utilisant le partage de données vers des partenaires externes qui exécutent les campagnes ou servis via les déploiements Oracle Machine Learning pour l'inférence en temps réel appelée par les applications côté client.
- API (Oracle Cloud Infrastructure API Gateway) : sécurise et régit les adresses d'API de déploiement Oracle Machine Learning.
- Shared Services
Les services utilisés par tous les domaines pour la gouvernance et la sécurité des données sont les suivants :
- Gouvernance des données (Oracle Cloud Infrastructure Data Catalog) : catalogue le glossaire métier et toutes les entités de données de domaine, en classant les produits de données par catégorie afin qu'ils puissent être repérés.
- Sécurité des données (Oracle Data Safe, OCI Audit, OCI Logging, OCI Vault) : augmente l'état de sécurité de tous les domaines.
Variante d'architecture : Déploiement partagé
Il est possible d'avoir une plate-forme décentralisée exécutée sur une plate-forme de données partagée, où un ensemble commun d'instances de service prend en charge les différentes équipes de domaine de données.
L'architecture principale offre le plus haut niveau d'isolation et de flexibilité pour chaque domaine et est hautement évolutive pour traiter les plates-formes de données décentralisées avec un grand nombre de domaines. Les exigences d'une plate-forme de données décentralisée peuvent varier et, pour des cas d'utilisation spécifiques, une variante de modèle d'architecture différente peut être mieux adaptée.
Le diagramme suivant présente une variante de déploiement partagé du modèle de plate-forme distribuée.
décentralisée-variante-partagée-oracle.zip
Une instance Oracle Autonomous Data Warehouse unique est partagée entre tous les domaines, qui sont isolés à l'aide d'un accès basé sur les rôles (RBAC) et de différents schémas. Les données résidant dans le lac sont également isolées pour chaque domaine à l'aide de stratégies Oracle Cloud Infrastructure Identity and Access Management et de compartiments distincts. Les produits de données sont organisés dans leurs schémas respectifs, catalogués et partagés à l'aide du partage en direct et avec numéro de version.
Pour l'assimilation et le traitement des données, les domaines A et B utilisent les mêmes instances et applications Oracle Cloud Infrastructure Data Integration et Oracle Cloud Infrastructure Data Flow. Les domaines C et D ont des exigences très spécifiques pour l'ingestion et le traitement des données et ont donc des instances distinctes.
La même logique s'applique à la couche de consommation où les domaines A et B partagent une seule instance de cloud analytique, séparés à l'aide de RBAC, tandis que les domaines C et D utilisent leurs propres instances de service.
Il est également possible d'utiliser une solution hybride. Au lieu d'avoir une seule instance pour tous les domaines ou une instance par domaine, certains domaines peuvent utiliser une instance partagée tandis que d'autres ont une instance dédiée.
Une telle solution hybride est généralement motivée par des exigences autres que les exigences fonctionnelles, telles que les exigences en matière de performances, de sécurité, de haute disponibilité ou de récupération après sinistre, qui sont plus exigeantes pour certains domaines, et qui nécessitent des instances distinctes pour répondre à ces exigences, sans nuire aux charges de travail des autres domaines.
Architecture Variante : Hub et Spoke
Souvent, les grandes entreprises ayant des filiales dans différentes régions et pays ont besoin d'exécuter leurs plates-formes de données indépendamment, sans une plate-forme de données centralisée qui dessert toutes les charges de travail des filiales, tout en ayant besoin de partager des données avec le siège social pour une visibilité mondiale et des indicateurs clés de performance (KPI).
Une plateforme de données décentralisée est une bonne solution pour ce scénario, où il y a un hub (le siège social) et plusieurs rayons (les filiales) qui ont besoin d'échanger des données de manière sécurisée et efficace.
Cette variante utilise la géographie comme exemple pour un modèle de hub et de rayons, mais le même modèle peut également être appliqué à d'autres exemples tels qu'une société holding et ses filiales.
Les rayons peuvent être déployés dans la même location que le hub ou dans des locations différentes.
Le diagramme suivant présente un hub et les différents rayons déployés dans différentes régions et qui utilisent des partages avec numéro de version, activés par le protocole Delta Sharing, pour échanger des données. Ce diagramme présente uniquement les composants fonctionnels du moteur de service. Le reste de l'architecture fonctionnelle est similaire à celle illustrée dans l'architecture fonctionnelle principale.
décentralisé-variant-hub-spoke-oracle.zip
Etant donné que les données sont échangées en toute sécurité et transmises entre les régions via Internet, vous devez prendre en compte la latence. Si les produits de données partagés entre les rayons et le hub sont des ensembles de données agrégés et des KPI, et non de grands volumes de données granulaires, ce modèle est simple à déployer, à maintenir et à utiliser.
Une autre approche consiste à utiliser des liens cloud Oracle Autonomous Database qui permettent un partage transparent des données entre les instances, même si elles se trouvent dans d'autres régions.
Pour le partage de données inter-région, l'instance Oracle Autonomous Data Warehouse source doit être clonée dans la région de destination afin que l'instance Autonomous Data Warehouse hub puisse y accéder de manière transparente. Les clones peuvent être actualisés régulièrement, manuellement ou automatiquement, de sorte que le hub Autonomous Data Warehouse puisse utiliser des produits de données à jour partagés par les rayons.
Etant donné que le hub consommera très probablement des produits de données qui constituent un sous-ensemble de l'ensemble de données dans lequel les rayons sont organisés, les rayons peuvent disposer d'une instance Autonomous Data Warehouse dédiée uniquement pour contenir les produits de données à partager avec le hub, ce qui optimise le clone actualisable.
Le trafic réseau pour les clones actualisables est acheminé via le réseau principal Oracle et présente une latence plus faible et une bande passante plus élevée lors du déplacement de produits de données volumineux résidant sur les instances Autonomous Data Warehouse spoke.
Le choix entre l'utilisation de partages avec numéro de version ou de liens cloud est principalement influencé par les performances et le coût plutôt que par les exigences fonctionnelles.
Quelle que soit l'option utilisée, le hub et les rayons ont leur propre plate-forme de données locale qui pourrait utiliser l'approche décentralisée présentée dans cette architecture.
Variante d'architecture : écosystème de données hétérogène
Vous pouvez toutefois utiliser la même architecture pour prendre en charge un écosystème de données hétérogène avec différentes organisations partageant des données à l'aide de différentes technologies et à des fins différentes.
Les cas d'utilisation peuvent inclure des hôpitaux qui partagent des données anonymisées avec des universités à des fins de recherche ou des fournisseurs partageant des données de pièces avec des constructeurs automobiles.
Les entreprises qui utilisent Oracle Autonomous Data Warehouse comme moteur de service peuvent fournir et utiliser des données partagées provenant d'autres technologies prenant en charge le protocole ouvert Partage Delta.
Delta Sharing est un bon choix pour prendre en charge les écosystèmes de données en raison de son large support et de la simplicité avec laquelle il fournit et consomme les données en toute sécurité.
Vous pouvez également partager des données à l'aide d'autres mécanismes, tels que des API ou la transmission en continu de données.
Architecture physique
L'architecture physique de cette plate-forme de données décentralisée prend en charge les éléments suivants :
- Isolation de domaine à l'aide des compartiments et des stratégies Oracle Cloud Infrastructure Identity and Access Management dans lesquels les équipes respectives sont uniquement autorisées à utiliser et déployer des ressources cloud dans leur compartiment
- Déploiement de domaine dans leurs réseaux cloud virtuels de charge globale respectifs pour un niveau d'isolement plus élevé et une sécurité accrue
- Assimilation, stockage, traitement et traitement des données, processus gérés par les équipes de domaine à l'aide de ressources cloud déployées dans leurs compartiments et réseaux cloud virtuels
- Prise en charge des exigences non fonctionnelles telles que l'évolutivité, la haute disponibilité, la récupération après sinistre, la sécurité et les objectifs de niveau de service (SLO) car chaque équipe de domaine utilise des ressources cloud distinctes en fonction de ses exigences de domaine spécifiques
- Contrôle affiné des coûts pour chaque utilisation des ressources cloud de domaine
- Trafic de bout en bout entièrement sécurisé et privé à l'aide d'adresses privées et d'instances déployées dans des sous-réseaux privés
Il est également possible de déployer certains services avec des adresses publiques par domaine tout en respectant les règles de sécurité de l'entreprise.
- Partage de données activé par Oracle Autonomous Data Warehouse à l'aide de partages en direct ou de partages avec numéro de version, et si les données doivent être mises à jour ou avec numéro de version, selon le cas d'utilisation
- Catalogue de données centralisé pour tous les domaines, avec des sous-entités de catalogue de données isolées par domaine à l'aide des stratégies Oracle Cloud Infrastructure Identity and Access Management, à l'exception des produits de données qui doivent être repérables
- Déploiement hautement évolutif à mesure que chaque nouveau domaine peut être intégré en utilisant l'automatisation Infrastructure-as-Code (IaC) sans impact sur les domaines de données existants
Le schéma suivant illustre cette architecture de référence.
plateforme de données décentralisée-physique-oracle.zip
Le diagramme d'architecture physique présente deux domaines pour illustrer la façon dont les services et les réseaux cloud sont organisés pour chaque domaine. En général, tous les compartiments et réseaux de domaines sont identiques, sauf en cas d'exception liée à des exigences spécifiques et non fonctionnelles.
Conception de l'architecture physique :
- Tire parti d'un VCN hub et d'un VCN pour chaque domaine de données qui contient la charge de travail pour ce domaine
- Tire parti de la connectivité sur site à l'aide d'Oracle Cloud Infrastructure FastConnect et d'un VPN site à site pour la redondance.
- Achemine tout le trafic entrant à partir des sites et d'Internet d'abord vers le VCN hub, puis vers les réseaux cloud virtuels de charge de travail du domaine de données
- Sécurise toutes les données en transit et inactives
- Déploie des services avec des adresses privées pour améliorer l'état de sécurité
- Séparation des réseaux cloud virtuels en plusieurs sous-réseaux privés pour améliorer l'état de sécurité
- Fournit un compartiment pour chaque domaine pour l'isolement des ressources
- Utilise une passerelle de routage dynamique (DRG) afin que les ressources cloud prennent en charge le trafic entrant et sortant vers les autres réseaux cloud virtuels de domaines
- Place les instances Autonomous Data Warehouse dans le sous-réseau privé de données pour une sécurité accrue, mais peut fournir et utiliser des partages actifs et gérés par numéro de version à partir des autres instances Autonomous Data Warehouse de domaine si des routages sont établis pour activer ce trafic
Les améliorations possibles de la conception qui ne sont pas décrites dans ce déploiement pour des raisons de simplicité sont les suivantes :
- Exploitation d'une zone d'atterrissage entièrement compatible CIS
- Déployer un pare-feu réseau dans le VCN hub pour améliorer la posture de sécurité globale en inspectant tout le trafic et en appliquant des stratégies
Recommandations
Utilisez les recommandations suivantes comme point de départ pour partager les données en toute sécurité. Vos exigences peuvent différer de l'architecture décrite ici.
Oracle Autonomous Data Warehouse
Cette architecture utilise Oracle Autonomous Data Warehouse sur une infrastructure partagée.
- Utilisez une architecture médaillon pour le lakehouse et créez des produits de données basés sur les couches d'argent (granulaire, augmentée) et d'or (enrichi, agrégé).
- Envisagez de partager des produits de données en utilisant Autonomous Data Warehouse avec sa prise en charge native du partage de données hétérogènes pour fournir une architecture plus simple, plus sécurisée et plus fiable.
- Envisagez de partager des données externes, exposées dans Autonomous Data Warehouse en tant que tables externes ou hybrides, afin de bénéficier des fonctionnalités de sécurité du partage avec numéro de version ou en direct.
- Envisagez de créer des vues pour vos tables de produits de données afin de différencier les objets de base (tables) des objets partagés (vues).
- Pour renforcer la sécurité lors du partage de données avec des partages actifs, envisagez d'utiliser un espace de noms et des valeurs de nom différents des schémas et tables sous-jacents pour masquer les noms d'objet internes.
- Pour renforcer la sécurité lors de l'utilisation du partage en direct avec des liens cloud, demandez à l'administrateur d'inscription de jeu de données de définir la portée de jeu de données la plus restrictive pour vos cas d'emploi.
- Lorsque vous utilisez le partage en direct avec des liens cloud, envisagez d'activer la mise en cache pour améliorer les performances des requêtes des consommateurs de données.
- Lorsque vous utilisez le partage en direct avec des liens cloud avec un grand volume de produits de données, envisagez de décharger les requêtes vers des clones actualisables pour améliorer les performances des consommateurs de données et la ségrégation des charges de travail.
- Si vous disposez d'un grand nombre d'instances Autonomous Data Warehouse de domaine ou si vos besoins de calcul d'instance sont élevés, envisagez de les consolider dans un pool élastique.
OCI Object Storage
Cette architecture utilise Oracle Cloud Infrastructure Object Storage hautement évolutif et durable en tant que stockage de lac.
Envisagez d'utiliser plusieurs compartiments granulaires pour organiser les domaines de données et les équipes au sein des domaines de données afin d'aider à séparer leurs workloads avec les stratégies Oracle Cloud Infrastructure Identity and Access Management.
Oracle Cloud Infrastructure Data Catalog
Cette architecture utilise Oracle Cloud Infrastructure Data Catalog pour gérer les métadonnées techniques, commerciales et opérationnelles des produits de données afin qu'elles puissent être détectées automatiquement.
- Envisagez d'utiliser une instance de catalogue de données unique pour tous les domaines afin de centraliser la gouvernance des métadonnées et des produits de données
- Envisagez d'accorder l'accès en gestion aux utilisateurs de domaine pour leurs ressources de données uniquement
- Envisagez d'accorder un accès en lecture à tous les utilisateurs afin qu'ils puissent trouver des produits de données gérés dans toute l'organisation
- Envisagez d'utiliser des propriétés personnalisées pour enrichir les métadonnées opérationnelles avec des propriétés telles que le propriétaire du produit de données, la disponibilité, la date de la dernière mise à jour, la version, etc.
Déploiement de domaines de données
Cette architecture utilise le modèle Data Lakehouse et les services OCI disponibles pour prendre en charge une charge de travail de données, d'analyse et d'IA de bout en bout.
- Envisagez de séparer les domaines en utilisant des réseaux cloud virtuels distincts pour chaque domaine afin d'améliorer l'état de sécurité et la flexibilité du domaine lors du déploiement des ressources cloud.
- Envisagez de séparer les différents services OCI utilisés par chaque domaine, en tirant parti des compartiments et des stratégies IAM.
Partage de produits de données
- Si vous devez utiliser des produits de données à l'aide d'API, envisagez d'utiliser Oracle REST Data Services.
- Si vous partagez des produits de données à l'aide d'Oracle REST Data Services, envisagez d'utiliser Oracle Cloud Infrastructure API Gateway pour sécuriser les API.
- Si vous avez besoin de diffuser des produits de données, envisagez d'utiliser Oracle Cloud Infrastructure GoldenGate et Oracle Cloud Infrastructure Streaming.
En savoir plus
En savoir plus sur les fonctionnalités de cette architecture et sur les architectures associées.