Datenplattform - Dezentrale Datenplattform
Verwenden Sie ein Data Lakehouse, um Ereignis- und Streamingdaten von Geräten in Echtzeit zu erfassen und zu analysieren und mit einer breiten Palette von Unternehmensdatenressourcen zu korrelieren, um die gewünschten Erkenntnisse zu gewinnen.
Wie können Sie die verschiedenen Teams Ihres Unternehmens, wie Marketing, Finanzen oder Logistik, mit der Flexibilität unterstützen und unterstützen, mit ihren domänenspezifischen Daten zu arbeiten und gleichzeitig eine sichere domänenübergreifende Datenfreigabe und -nutzung zu ermöglichen, ohne Daten zu duplizieren und Datensilos zu erstellen?
Führen Sie eine domänengesteuerte Datenarchitektur ein, die Teams und Abteilungen im gesamten Unternehmen die Agilität und Flexibilität bietet, die erforderlich ist, um ihre Daten effizient zu nutzen und die für ihr Unternehmen wesentlichen Datenprodukte zu entwickeln.
Diese Referenzarchitektur positioniert die Technologielösung im gesamten Geschäftskontext, in dem strategische Absichten die Schaffung messbarer strategischer Ergebnisse fördern. Diese Ergebnisse generieren neue strategische Absichten und liefern kontinuierliche, datengesteuerte Geschäftsverbesserungen.
Jede Domain folgt unabhängig dem oben gezeigten allgemeinen Prozess, um ihre Domain-Datenprodukte zu erstellen. Domänengesteuerte Datenarchitekturen bieten die Flexibilität, die Unternehmen benötigen, indem sie die Abhängigkeit von einem einzigen Zugriffspunkt wie einer vollständig zentralisierten Datenplattform und einem IT-Team vermeiden und agile Innovationen fördern, um vertrauenswürdige Datenprodukte in jeder Domain zu erstellen.
dezentrale Datenplattform-Übersicht-oracle.zip
Ziel jeder Domain ist es, domänenbezogene Daten zu erfassen und dann Datenprodukte zu erzeugen, die von anderen Domains oder Endverbrauchern konsumiert werden.
Folgende Domains sind möglich:
- Source-aligned: Sendet Daten direkt aus relevanten Domain-Datenquellen, wie z. B. Unternehmensanwendungen, und erzeugt Datenprodukte, die von aggregierten oder verbraucherorientierten Domains konsumiert werden. Diese Datenprodukte stellen die Quelle der Wahrheit für eine bestimmte Domain dar. Die Daten sind granular, kuratiert und grundlegend innerhalb und über Domänen hinweg.
- Aggregieren: Konsumiert und kombiniert quellengerichtete Daten und erstellt aggregierte und Mehrwertdatenprodukte, die Wiederverwendung fördern, Duplizierung reduzieren und grundlegende Geschäftslogik enthalten, die von verbraucherorientierten Domains benötigt wird.
- Verbraucherorientiert: Daten werden aus quellenorientierten und aggregierten Domains konsumiert, um Datenprodukte zu erstellen, die bestimmte Anwendungsfälle erfüllen und die Anforderungen des Datenverbrauchers innerhalb einer bestimmten Domain erfüllen.
Die Datendomain-Teams und ihre Fachexperten (KMU) haben die Flexibilität, die Technologie auszuwählen, die für die Kuratierung ihrer Datenprodukte erforderlich ist, um die Reibung und Komplexität langer Technologieauswahlprozesse zu reduzieren und die Zeit für die Bereitstellung von Datenprodukten zu verkürzen.
Die gewählte Technologie wird in der Regel auf Unternehmensebene bestimmt, sodass sie den Sicherheits-, Skalierbarkeits-, Resilienz- und Hochverfügbarkeitsanforderungen entspricht. Bei dieser Architektur wird davon ausgegangen, dass jeder Oracle Cloud Infrastructure-(OCI-)Service, der mit einem Data Lakehouse verwendet wird, von jeder Domain genutzt werden kann.
Datendomain-Teams verwenden häufig Automatisierung, um Domänenarchetypen bereitzustellen. Dadurch werden vorkonfigurierte Technologien verfügbar, mit denen neue Domains schnell integriert werden können, und gleichzeitig sichergestellt wird, dass Anforderungen auf Unternehmensebene wie Sicherheit durchgesetzt werden.
Nachdem sie erstellt wurden, werden Datenprodukte an andere Domains oder Endbenutzer und Anwendungen gesendet. Datenprodukte werden kontinuierlich kuratiert, um Informationen und Einblicke bereitzustellen.
- Datasets
- APIs
- Dashboards
- Streams
- KI- und ML-Modelle (ML), die einen bestimmten Bedarf erfüllen
Diese Referenzarchitektur verwendet hauptsächlich die gemeinsame Nutzung von Daten als zugrunde liegendes Verfahren zur Bereitstellung und Nutzung von Datenprodukten zwischen Domänen.
Oracle Autonomous Data Warehouse ermöglicht die gemeinsame Nutzung von Daten und die Live-Freigabe von Daten zwischen Autonomous Data Warehouse-Instanzen oder mit versionierten Daten aus allen Technologien, die mit dem offenen Delta Sharing-Protokoll konform sind.
Funktionale Architektur
Diese Architektur zeigt eine dezentrale Plattform, bei der jede Domain eine Teilmenge der gesamten Datenplattform ist und bei der jede Domain die verwendeten Technologien und Services auswählen kann.
Die Architektur verwendet ein Data Lakehouse, um Daten unabhängig von ihrer Form oder Form zu speichern und bereitzustellen. Der Einfachheit halber werden in der Architektur einige Domains dargestellt, die eine Teilmenge der verfügbaren Data Lakehouse-Services verwenden.
Eine dezentrale Datenplattform, die eine Data Lakehouse-Architektur verwendet, bietet:
- Eine interoperable und modulare Lakehouse-Architektur, bei der Datendomänen jede Art von Daten für jeden Anwendungsfall aufnehmen und kuratieren können
- Flexibilität für jede Datendomain bei der Verwendung der Oracle Cloud Infrastructure-(OCI-)Services, die zur Unterstützung der Erstellung ihrer Datenprodukte erforderlich sind
- Kuratierung von Datenprodukten, die mithilfe von Datenfreigabe, Streaming, APIs, Dashboards oder Anwendungen sicher geteilt werden können
- Agilität bei der Erstellung von Datenprodukten, wodurch die Abhängigkeiten zwischen Domänen reduziert werden, mit Ausnahme der für den Austausch von Datenprodukten erforderlichen
- Erhöhte Isolierung von Datendomänen und reduzierte Komplexität des Datenaustauschs durch die Verwendung akzeptierter Datenaustauschmechanismen und -verträge zum Austausch von Daten zwischen Domänen
- Erhöhte Daten-Governance und Datenvertrauen, da sachkundige Fachexperten (KMU) Daten und Datenprodukte für ihre Domains kuratieren
- Einfaches Onboarding neuer Datendomänen mit Infrastructure-as-Code (IaC), um das Deployment mit vordefinierten und getesteten Terraform-Stacks zu automatisieren
- Ressourcen- und Kosteneffizienz, da Datendomain-Teams die Größe der spezifischen Services, die sie zur Erstellung von Datenprodukten verwenden, richtig festlegen
- Angemessene Kostenverantwortung für jede Datendomain mit der Option einer fein granulierten Kostenkontrolle innerhalb der spezifischen Domains
Das folgende Diagramm veranschaulicht die Funktionsarchitektur. Der Einfachheit halber werden nur vier Datendomänen angezeigt, und nur einige der Data Lakehouse-Funktionen, die von Datendomänen verwendet werden können, werden angezeigt.
dezentrale Datenplattform-logisch-oracle.zip
Da die jeweilige Branche und Organisation, die eine dezentrale Datenplattform bereitstellt, die Datendomänen bestimmt, schreibt diese Referenzarchitektur nicht vor, wie Datendomänen definiert werden sollen. Die dargestellten Datendomänen sind nur ein Beispiel.
Die Architektur konzentriert sich auf die folgenden logischen Divisionen, die von allen Domains verwendet werden:
- Verbinden, aufnehmen, transformieren
Stellt eine Verbindung zu Datenquellen her und erfasst und verfeinert ihre Daten für die Verwendung in jeder der Datenschichten in der Architektur.
Quellbezogene Datendomänen beziehen Daten aus internen und externen Datenquellen und aus anderen Domains, die ihre Datenprodukte konsumieren. Aggregierte und vom Verbraucher ausgerichtete Datendomänen beziehen ihre Daten in der Regel aus anderen Domänendatenprodukten. Alle Domains können relevante Domaindaten aus externen Quellen beziehen.
- Beibehalten, kuratieren, erstellen
Ermöglicht den Zugriff auf und die Navigation der Daten, um die aktuelle Geschäftsansicht anzuzeigen. Bei relationalen Technologien können Daten logisch oder physisch in einfachen relationalen, longitudinalen, dimensionalen oder OLAP-Formularen strukturiert sein. Bei nicht relationalen Daten enthält diese Schicht einen oder mehrere Datenpools, die entweder aus einem Analyseprozess ausgegeben werden oder für eine bestimmte analytische Aufgabe optimiert sind.
In dieser Schicht kuratiert jede Datendomain die Daten, die sie zum Erstellen und Bereitstellen von Datenprodukten verwenden. Normalerweise werden Daten kuratiert und organisiert, indem eine Medaillonarchitektur verwendet wird, die Daten von Bronze, Silber, Gold nach seinem Wert und seiner Qualität fördert.
Datenprodukte dienen oft Daten, die sich entweder in der Gold- oder der Silberschicht befinden. Wenn das Datenprodukt granulare Daten verarbeitet, werden diese Daten aus der Silberschicht bereitgestellt. Wenn das Datenprodukt Daten verarbeitet, die aggregiert sind oder bereits ein weiterer erweiterter Datensatz sind, werden diese Daten in der Regel aus der Goldschicht bereitgestellt.
- Analysieren, lernen, vorhersagen
Abstrahiert die logische Geschäftsansicht der Daten für Consumer. Diese Abstraktion erleichtert agile Ansätze bei der Entwicklung, Migration zur Zielarchitektur und die Bereitstellung einer einzelnen Reportingschicht aus mehreren Datenquellen.
Jede Datendomain hat in der Regel eigene Daten-Consumer, wie Domainbenutzer, Anwendungen oder Systeme, die kuratierte Daten in Form von Dashboards, Datenanwendungen, Streaming oder APIs konsumieren.
Datendomänen können Datenprodukte für andere Datendomänen und innerhalb ihrer eigenen Domain bereitstellen, um den projektübergreifenden Datenaustausch zu organisieren.
Die Architektur weist die folgenden funktionalen Merkmale auf:
- Es werden vier Datendomänen dargestellt. Jede Domain kuratiert für diese Domain spezifische Daten, erstellt Datenprodukte basierend auf diesen kuratierten Daten und teilt diese Datenprodukte dann mit anderen Domains innerhalb der Organisation oder mit externen Entitäten.
- Domains können Daten aus internen Datenquellen, von anderen Domains kuratierten Datenprodukten oder von externen Entitys gemeinsam genutzten Daten beziehen.
- Die Kunden- und Finanzdomains sind quellenorientierte Domains, die Daten aus internen Systemen aufnehmen und kuratieren, ihre eigenen Benutzer haben und Datenprodukte für andere Domains kuratieren.
- Die Risikodomain ist eine Aggregatdomain, die Daten aus den Kunden- und Finanzdomains bezieht, um Kundenprofile bzw. erweiterte Finanztransaktionen zu erhalten. Diese Daten werden verwendet, um Risikomodelle für maschinelles Lernen (ML) und KPIs (Key Performance Indicators) zu erstellen und zu trainieren, die von Dashboards verwendet und mit der Marketingdomain geteilt werden.
- Die Marketing-Domain ist eine verbraucherorientierte Domain, die ausschließlich Kundenprofile und Risikobereitschaftsdaten aus den Kunden- und Risikodomänen bezieht. Diese Domain erstellt Segmentierungs-ML-Modelle, mit denen die besten personalisierten Angebote ermittelt werden. Diese werden internen Anwendungen über inferenzierende APIs zur Verfügung gestellt, und die Ergebnisse der Batchinferenzierung werden Partnern, die ausgehende Kampagnen ausführen, als Datenprodukt zur Verfügung gestellt.
- Alle Domains verwenden einen gemeinsamen Datenkatalog, der Informationen zu ihren Datenassets, Datenentitys und Geschäftsglossaren enthält.
- Jedes Datendomainteam und seine Datenprodukteigentümer verwalten ihre spezifischen Datenkatalogobjekte. Die Sicherheitsisolierung wird durch die Verwendung von Oracle Cloud Infrastructure Identity and Access Management-Policys gewährleistet, die definieren, welches Team welche Datenkatalogentitys verwalten kann.
- Allgemeine Data Catalog-Entitys, wie z.B. Geschäftsglossarbegriffe, die im gesamten Unternehmen verwendet werden, werden von einem Data Governance-Body verwaltet, der aus allen Domainprodukteigentümern besteht.
- Datenprodukte werden im Datenkatalog so gekennzeichnet, dass sie durchsuchbar sind, ihre eigene Semantik enthalten und sich auf das Geschäftsglossar beziehen.
- Die Datenfreigabe wird verwendet, um Live- oder versionierte Datenprodukte zwischen Domains zu teilen. Die Wahl der Verwendung von Live- oder versionierten Datenprodukten hängt von jedem Datenprodukt und Anwendungsfall ab.
Die wichtigsten funktionalen Komponenten der Architektur sind:
- Quellbezogene Domains: Kunde und Finanzen
Diese Bereiche konzentrieren sich auf die Kuratierung von Kunden- und Finanzdaten, die aus strukturierten und unstrukturierten Daten abgeleitet werden.
Die Kundendomain verwendet die folgenden Funktionen, um ein Kundenprofildatenprodukt zu erstellen:
- Batchaufnahme (Oracle Cloud Infrastructure Data Integration): Nimmt Daten aus CRM-, Website- und kundenorientierten Anwendungen auf.
- Batchverarbeitung (Oracle Cloud Infrastructure Data Integration, Oracle Cloud Infrastructure Data Flow): Verarbeitet strukturierte und unstrukturierte Daten mit Low-Code-ELT und/oder codeorientiertem ETL, um die Kundenprofile-Datenprodukte zu erstellen.
- Serving (Oracle Autonomous Data Warehouse): Kuratiert Kundenprofildaten und stellt sie den Risiko- und Marketingdomänen zur Verfügung.
- Cloud Storage/Data Lake (Oracle Cloud Infrastructure Object Storage): Speichert Kundendokumente, Verträge oder Formulare.
- Visualisieren/Lernen (Oracle Analytics Cloud): Dient erweiterten Analysen von Domainendbenutzern, einschließlich kundenbezogener KPIs, wie Lebensdauerwert (LTV), Kundenbindungsrate, Kundenzufriedenheitsbewertung (CSAT) und Net Promoter Score (NPS).
- KI- und generative KI-Services: Oracle Cloud Infrastructure Document Understanding extrahiert Daten aus Kundenformularen und -dokumenten und Oracle Cloud Infrastructure Language verarbeitet Textdaten und bereichert sie mit Sentimentanalyse, Named Entity Recognition oder Textklassifizierung.
Die Finanzdomain verwendet die folgenden Funktionen, um ein Datenprodukt für erweiterte Finanztransaktionen zu erstellen:
- Echtzeitaufnahme (Oracle Cloud Infrastructure GoldenGate): Erfasst Finanztransaktionen aus dem Kernbankensystem nahezu in Echtzeit und auf nicht aufdringliche Weise.
- Batchverarbeitung (Oracle Cloud Infrastructure-Datentransformationen): Mit Low-Code-ELT werden Rohdaten validiert, geformt und in ein kuratiertes Datenprodukt umgewandelt, indem Finanztransaktionsdaten mit Ausgabenkategorien, Händlerdetails oder Standortdaten kategorisiert und erweitert werden.
- Serving (Oracle Autonomous Data Warehouse): Speichert kuratierte Daten und stellt erweiterte Transaktionen für die Risikodomain bereit.
- Cloud Storage/Data Lake (Oracle Cloud Infrastructure Object Storage): Speichert finanzbezogene Formulare, die in den in Oracle Autonomous Data Warehouse gespeicherten Finanztransaktionsdatensätzen referenziert werden.
- Aggregatdomain: Risiko
Diese Domäne konzentriert sich auf das Erstellen, Trainieren und Ausführen von Modellen für maschinelles Lernen, um Risiken basierend auf internen Daten wie Kundenprofilen und erweiterten Transaktionen sowie externen Daten wie wirtschaftlichen und makroökonomischen Daten zu erkennen.
Diese Domäne hat sich auf KMU in der Risikoanalyse und -prävention spezialisiert und bedient alle anderen Bereiche, die ihre Datenprodukte benötigen. Die Domain verfügt über interne Benutzer, die erweiterte Analysen verwenden. Der Großteil ihrer Arbeit besteht jedoch darin, Batch-Inferenzierungsergebnisse für maschinelles Lernen gemeinsam zu verwenden. Beispiel: Batch-Inferenzierung kann die Risikoneigung von Kunden, die Finanzdienstleistungen abonnieren, basierend auf ihrem Lebensstil und ihren Ausgaben und auf makroökonomischen Faktoren wie Wirtschaftswachstum, Inflation oder Arbeitslosenquote berechnen.
Diese Domain verwendet die folgenden Funktionen, um ein Datenprodukt mit Risikoneigung zu erstellen:
- Serving (Oracle Autonomous Data Warehouse): Verarbeitet Transformationen und Feature-Engineering, um die ML-Modelle zu speisen sowie die Ergebnisse der Batch-Inferenzierung zu speichern und risikobezogene KPIs zu erstellen. Die aggregierte Risikodomain ist ein Verbraucher der Kundenprofile und der erweiterten Transaktionsdaten, die von den Kunden- bzw. Finanzdomains gemeinsam verwendet werden. Es liefert Daten zur Risikoneigung für die Marketingdomain.
- Learn and Predict (Oracle Cloud Infrastructure Data Science): Umfasst den gesamten Lebenszyklus von Machine Learning-Vorgängen, von explorativer Datenanalyse, Modellentwicklung, Ausführung bis hin zu kontinuierlicher Verbesserung. Es erzeugt Batch-Inferenzierungsergebnisse, die als Grundlage für die gemeinsam genutzten Daten zur Risikoneigung dienen.
- Verbraucherorientierte Domain: Marketing
Diese Domain konzentriert sich auf die Datenkuratierung, um personalisierte und gezielte Kampagnen zu unterstützen. Es verwendet Daten, die von anderen Domains gemeinsam verwendet werden, als Eingabe und stellt die Segmentierungs- und nächstbesten Angebotsdaten in Echtzeit bereit, indem API-gesteuerte Inferenzen verwendet werden und Daten mit 3rd-Party-Marketingpartnern geteilt werden, die Kampagnen ausführen und die Ergebnisse der Kampagnenausführung freigeben.
Diese Domain verwendet die folgenden Funktionen, um Datenprodukte für die Kampagnensegmentierung zu erstellen:
- Batchverarbeitung (Oracle Cloud Infrastructure-Datentransformationen): Prozesse und Ausprägungen von Daten, die aus den Datenfreigaben verbraucht werden. Sie kann auch verwendet werden, um Daten aus den Daten-Shares in Oracle Autonomous Data Warehouse zu replizieren.
- Bereitstellung (Oracle Autonomous Data Warehouse): Speichert kuratierte Daten, Kampagneninformationen, Segmente und gezielte Angebote für eine bestimmte Kampagne.
- Cloud Storage/Data Lake (Oracle Cloud Infrastructure Object Storage): Speichert alle unstrukturierten Daten, die von der Domain verwendet werden.
- Visualisieren/Lernen (Oracle Analytics Cloud): Dient erweiterten Analysen von Domainendbenutzern wie Kampagnenzielen und Ausführungs-KPIs.
- Learn and Predict (Oracle Machine Learning): Umfasst den gesamten Lebenszyklus von Machine Learning-Vorgängen von explorativer Datenanalyse bis hin zur Modellbereitstellung. Benutzer nutzen AutoML, um die Erstellung und Schulung von Modellen zu beschleunigen. Abhängig von den Kampagnen werden die Ergebnisse des Batchinferenzierungsmodells bereitgestellt, indem die Datenfreigabe für externe Partner verwendet wird, die diese Kampagnen ausführen oder über Oracle Machine Learning-Deployments für Echtzeitinferenzen bereitgestellt wird, die von kundenorientierten Anwendungen aufgerufen werden.
- API (Oracle Cloud Infrastructure API Gateway): Sichert und steuert die Oracle Machine Learning-Deployment-API-Endpunkte.
- Shared Services
Zu den von allen Domains für Data Governance und Sicherheit verwendeten Services gehören:
- Data Governance (Oracle Cloud Infrastructure Data Catalog): Katalogisiert das Geschäftsglossar und alle Domaindatenentitys und kategorisiert die Datenprodukte, damit sie erkannt werden können.
- Datensicherheit (Oracle Data Safe, OCI Audit, OCI Logging, OCI Vault): Erhöht den Sicherheitsstatus aller Domains.
Architekturvariante: Shared Deployment
Es ist möglich, dass eine dezentrale Plattform auf einer gemeinsamen Datenplattform ausgeführt wird, auf der ein gemeinsames Set von Serviceinstanzen die verschiedenen Datendomainteams unterstützt.
Die primäre Architektur ermöglicht die höchste Isolation und Flexibilität für jede Domain und ist hoch skalierbar, um dezentrale Datenplattformen mit einer großen Anzahl von Domains zu adressieren. Die Anforderungen an eine dezentrale Datenplattform können variieren und für bestimmte Anwendungsfälle könnte eine andere Architekturmustervariante besser geeignet sein.
Das folgende Diagramm zeigt eine gemeinsame Deployment-Variante des verteilten Plattformmusters.
dezentralisiert-variant-shared-oracle.zip
Eine einzelne Oracle Autonomous Data Warehouse-Instanz wird von allen Domains gemeinsam verwendet, die mit rollenbasiertem Zugriff (RBAC) und verschiedenen Schemas isoliert sind. Die Daten im Lake werden auch für jede Domain mit Oracle Cloud Infrastructure Identity and Access Management-Policys und eindeutigen Compartments isoliert. Datenprodukte werden in ihren jeweiligen Schemas kuratiert, katalogisiert und mithilfe von Live- und versioniertem Sharing freigegeben.
Für die Datenaufnahme und -verarbeitung verwenden die Domains A und B dieselben Oracle Cloud Infrastructure Data Integration- und Oracle Cloud Infrastructure Data Flow-Instanzen und -Anwendungen. Die Domänen C und D haben sehr spezifische Anforderungen an die Datenaufnahme und -verarbeitung und verfügen daher über separate Instanzen.
Die gleiche Logik gilt für die Nutzungsebene, in der Domains A und B eine einzelne Analytics Cloud-Instanz gemeinsam nutzen, getrennt mit RBAC, während Domains C und D ihre eigenen Serviceinstanzen verwenden.
Es ist auch möglich, eine Hybridlösung zu verwenden. Anstatt eine einzelne Instanz für alle Domains oder eine Instanz pro Domain zu verwenden, verwenden einige Domains möglicherweise eine gemeinsame Instanz, während andere über eine dedizierte Instanz verfügen.
Eine solche Hybridlösung basiert in der Regel auf anderen Anforderungen als funktionalen Anforderungen wie Performance-, Sicherheits-, High Availability- oder Disaster Recovery-Anforderungen, die für einige Domains anspruchsvoller sind, und erfordert separate Instanzen, um diese Anforderungen zu erfüllen, ohne die Workloads anderer Domains zu beeinträchtigen.
Architekturvariante: Hub und Spoke
Oft müssen große Unternehmen mit Tochtergesellschaften in verschiedenen Regionen und Ländern ihre Datenplattformen unabhängig ausführen, ohne eine zentralisierte Datenplattform, die alle Tochtergesellschafts-Workloads bedient, während sie weiterhin Daten mit der Zentrale teilen müssen, um globale Transparenz und KPIs zu erhalten.
Eine dezentrale Datenplattform ist eine gute Lösung für dieses Szenario, in dem es einen Hub (die Zentrale) und mehrere Sprecher (die Tochtergesellschaften) gibt, die Daten sicher und effizient austauschen müssen.
Diese Variante verwendet die Geographie als Beispiel für ein Hub- und Speichenmuster, aber das gleiche Muster kann auch auf andere Beispiele wie eine Holdinggesellschaft und ihre Tochtergesellschaften angewendet werden.
Die Sprecher können in demselben Mandanten wie der Hub oder in verschiedenen Mandanten bereitgestellt werden.
Das folgende Diagramm zeigt einen Hub und die verschiedenen Speichen, die in verschiedenen Regionen bereitgestellt werden und versionierte Shares verwenden, die durch das Delta-Sharing-Protokoll aktiviert sind, um Daten auszutauschen. Dieses Diagramm zeigt nur die Funktionskomponenten der Serviermaschine. Der Rest der funktionalen Architektur ähnelt der in der primären funktionalen Architektur.
dezentrale Variante-Hub-Spoke-oracle.zip
Da Daten sicher ausgetauscht und regionsübergreifend über das Internet übertragen werden, sollten Sie die Latenz berücksichtigen. Wenn Datenprodukte, die von den Speichen und dem Hub gemeinsam verwendet werden, aggregierte Datasets und KPIs und keine großen Mengen granularer Daten sind, ist dieses Muster einfach bereitzustellen, zu verwalten und zu betreiben.
Alternativ können Sie Oracle Autonomous Database Cloud-Links verwenden, die eine nahtlose Datenfreigabe über Instanzen hinweg ermöglichen, auch wenn sie sich in anderen Regionen befinden.
Für die regionsübergreifende Datenfreigabe muss die Oracle Autonomous Data Warehouse-Quellinstanz in der Zielregion geklont werden, damit von der Autonomous Data Warehouse-Hubinstanz problemlos darauf zugegriffen werden kann. Klone können in regelmäßigen Abständen manuell oder automatisch aktualisiert werden, sodass der Hub Autonomous Data Warehouse aktuelle Datenprodukte nutzen kann, die von den Sprechern gemeinsam verwendet werden.
Da der Hub höchstwahrscheinlich Datenprodukte verbraucht, die eine Teilmenge des gesamten Datasets sind, das die Speichen kuratieren, können die Speichen über eine dedizierte Autonomous Data Warehouse-Instanz verfügen, die nur Datenprodukte enthält, die mit dem Hub gemeinsam verwendet werden sollen, wodurch der aktualisierbare Klon optimiert wird.
Der Netzwerktraffic für aktualisierbare Klone wird über das Oracle-Backbone geleitet und weist beim Verschieben großer Datenprodukte, die sich auf den Spoke-Autonomous Data Warehouse-Instanzen befinden, eine geringere Latenz und eine höhere Bandbreite auf.
Die Wahl zwischen versionierten Shares oder Cloud-Links wird in erster Linie durch Performance und Kosten und nicht durch funktionale Anforderungen beeinflusst.
Unabhängig von der verwendeten Option verfügen der Hub und die Speichen über eine eigene lokale Datenplattform, die den in dieser Architektur dargestellten dezentralen Ansatz verwenden könnte.
Architekturvariante: Heterogenes Datenökosystem
Sie können jedoch dieselbe Architektur verwenden, um ein heterogenes Datenökosystem mit verschiedenen Organisationen zu unterstützen, die Daten mit verschiedenen Technologien und für verschiedene Zwecke teilen.
Anwendungsfälle können Krankenhäuser umfassen, die anonymisierte Daten für Forschungszwecke an Universitäten weitergeben, oder Lieferanten, die Teiledaten an Automobilhersteller weitergeben.
Unternehmen, die Oracle Autonomous Data Warehouse als Serving Engine verwenden, können gemeinsam genutzte Daten aus anderen Technologien bereitstellen und nutzen, die das offene Delta Sharing-Protokoll unterstützen.
Delta Sharing ist eine gute Wahl, um Datenökosysteme aufgrund seiner breiten Unterstützung und aufgrund der Einfachheit, mit der es Daten sicher bereitstellt und konsumiert, zu unterstützen.
Sie können Daten auch mit anderen Mechanismen wie APIs oder Datenstreaming freigeben.
Physische Architektur
Die physische Architektur für diese dezentrale Datenplattform unterstützt Folgendes:
- Domainisolation mit Oracle Cloud Infrastructure Identity and Access Management-Compartments und -Policys, bei denen die jeweiligen Teams nur zur Verwendung und Bereitstellung von Cloud-Ressourcen in ihrem Compartment autorisiert sind
- Domain-Deployment in den jeweiligen Workload-VCNs für eine höhere Isolationsebene und einen höheren Sicherheitsstatus
- Datenaufnahme-, Speicher-, Verarbeitungs- und Bereitstellungsprozesse, die von Domainteams mit in ihren Compartments und VCNs bereitgestellten Cloud-Ressourcen verwaltet werden
- Unterstützung für nicht funktionale Anforderungen wie Skalierbarkeit, High Availability, Disaster Recovery, Sicherheit und Service Level Objectives (SLOs), da jedes Domainteam separate Cloud-Ressourcen entsprechend seinen spezifischen Domainanforderungen verwendet
- Fein granulierte Kostenkontrolle für jede Nutzung von Domain-Cloud-Ressourcen
- Vollständig sicherer und privater End-to-End-Traffic mit privaten Endpunkten und Instanzen, die in privaten Subnetzen bereitgestellt werden
Es ist auch möglich, dass einige Services mit öffentlichen Endpunkten pro Domain unter Einhaltung der Sicherheitsregeln des Unternehmens bereitgestellt werden.
- Datenfreigabe, die von Oracle Autonomous Data Warehouse mit Live-Shares oder versionierten Shares aktiviert wird und je nach Anwendungsfall aktuelle oder versionierte Daten bereitstellen soll
- Zentralisierter Datenkatalog für alle Domains, wobei die Data Catalog-Subentitys mit Oracle Cloud Infrastructure Identity and Access Management-Policys pro Domain isoliert sind, mit Ausnahme von Datenprodukten, die ermittelt werden müssen
- Hoch skalierbares Deployment, da jede neue Domain mit der Infrastructure-as-Code-(IaC-)Automatisierung integriert werden kann, ohne dass sich dies auf die vorhandenen Datendomänen auswirkt
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.
dezentrale Datenplattform-physikalisch-oracle.zip
Das Diagramm zur physischen Architektur zeigt zwei Domains, um zu veranschaulichen, wie die Cloud-Netzwerke und -Services für jede Domain ausgelegt sind. In der Regel sind alle Domänennetzwerke und Compartments identisch, es sei denn, es gibt eine Ausnahme, die von bestimmten, nicht funktionalen Anforderungen bestimmt wird.
Das Design für die physische Architektur:
- Nutzt ein Hub-VCN und ein VCN für jede Datendomain, die die Workload für diese Domain enthält
- Nutzt On-Premise-Konnektivität mit Oracle Cloud Infrastructure FastConnect und Site-to-Site-VPN für Redundanz
- Leitet den gesamten eingehenden Traffic von On Premise und vom Internet zuerst an das Hub-VCN und dann an die Workload-VCNs der Datendomain weiter
- Sichert alle Daten während der Übertragung und im Ruhezustand
- Stellt Services mit privaten Endpunkten bereit, um den Sicherheitsstatus zu erhöhen
- Trennen Sie VCNs in mehrere private Subnetze, um den Sicherheitsstatus zu erhöhen
- Stellt ein Compartment für jede Domain für die Ressourcenisolation bereit
- Verwendet ein dynamisches Routinggateway (DRG), sodass Cloud-Ressourcen eingehenden und ausgehenden Traffic zu den anderen Domain-VCNs unterstützen
- Platziert Autonomous Data Warehouse-Instanzen zur Erhöhung der Sicherheit im privaten Datensubnetz, kann jedoch Live- und versionierte Shares aus den anderen Autonomous Data Warehouse-Domaininstanzen bereitstellen und konsumieren, wenn Routen eingerichtet sind, um diesen Traffic zu ermöglichen
Potenzielle Designverbesserungen, die in dieser Bereitstellung aus Gründen der Einfachheit nicht dargestellt werden, umfassen:
- Nutzung einer vollständigen CIS-konformen Landezone
- Stellen Sie eine Netzwerkfirewall im Hub-VCN bereit, um den allgemeinen Sicherheitsstatus zu verbessern, indem Sie den gesamten Traffic prüfen und Policys durchsetzen
Empfehlungen
Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für die sichere gemeinsame Nutzung von Daten. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.
Oracle Autonomous Data Warehouse
Diese Architektur verwendet Oracle Autonomous Data Warehouse auf gemeinsam genutzter Infrastruktur.
- Verwenden Sie eine Medaillonarchitektur für das Lakehouse und erstellen Sie Datenprodukte auf Basis der Silber- (granulierten, erweiterten) und Gold- (angereicherten, aggregierten) Schichten.
- Sie sollten Datenprodukte gemeinsam nutzen, indem Sie Autonomous Data Warehouse mit seiner nativen Unterstützung für den heterogenen Datenaustausch verwenden, um eine einfachere, sicherere und zuverlässigere Architektur bereitzustellen.
- Sie sollten externe Daten, die in Autonomous Data Warehouse als externe Tabellen oder Hybridtabellen bereitgestellt werden, gemeinsam nutzen, um von den Sicherheitsfunktionen des versionierten oder Live-Sharing zu profitieren.
- Erstellen Sie Views für Ihre Datenprodukttabellen, um die Basisobjekte (Tabellen) von den gemeinsam verwendeten Objekten (Views) zu unterscheiden.
- Um die Sicherheit beim Teilen von Daten mit Live Shares zu erhöhen, sollten Sie Namespace- und Namenswerte verwenden, die sich von den zugrunde liegenden Schemas und Tabellen unterscheiden, um interne Objektnamen auszublenden.
- Um die Sicherheit bei der Verwendung von Live-Sharing mit Cloud-Links zu erhöhen, lassen Sie den Dataset-Registrierungsadministrator den restriktivsten Dataset-Geltungsbereich für Ihre Anwendungsfälle definieren.
- Wenn Sie Live-Sharing mit Cloud-Links verwenden, sollten Sie das Caching aktivieren, um die Abfrageperformance von Datenverbrauchern zu verbessern.
- Wenn Sie Live-Sharing mit Cloud-Links mit einer großen Menge von Datenprodukten verwenden, sollten Sie die Abfragen in aktualisierbare Klone auslagern, um die Performance der Datenverbraucher und die Workload-Trennung zu verbessern.
- Wenn Sie über eine große Anzahl von Domain-Autonomous Data Warehouse-Instanzen verfügen oder die Compute-Anforderungen Ihrer Instanz hoch sind, sollten Sie sie in einem elastischen Pool konsolidieren.
OCI Object Storage
Diese Architektur verwendet hochskalierbaren und dauerhaften Oracle Cloud Infrastructure Object Storage als Lake-Speicher.
Verwenden Sie mehrere granulare Compartments, um die Datendomänen und die Teams in den Datendomänen zu organisieren, um ihre Workloads mit Oracle Cloud Infrastructure Identity and Access Management-Policys zu trennen.
Oracle Cloud Infrastructure Data Catalog
Diese Architektur verwendet Oracle Cloud Infrastructure Data Catalog, um technische, geschäftliche und betriebliche Metadaten für Datenprodukte zu verwalten, damit sie selbst entdeckt werden können.
- Sie sollten eine einzelne Data Catalog-Instanz für alle Domains verwenden, um die Governance von Metadaten und Datenprodukten zu zentralisieren
- Sie sollten Domainbenutzern nur für ihre Datenassets Verwaltungszugriff erteilen
- Sie sollten allen Benutzern Lesezugriff gewähren, damit sie Datenprodukte finden können, die im gesamten Unternehmen verwaltet werden.
- Verwenden Sie benutzerdefinierte Eigenschaften, um Betriebsmetadaten mit Eigenschaften wie Datenprodukteigentümer, Verfügbarkeit, Datum der letzten Aktualisierung, Version usw. anzureichern.
Datendomänen-Deployment
Diese Architektur verwendet das Data Lakehouse-Muster und die verfügbaren OCI-Services, um eine End-to-End-Daten-, Analyse- und KI-Workload zu unterstützen.
- Ziehen Sie das Trennen von Domains in Betracht, indem Sie separate VCNs für jede Domain verwenden, um den Sicherheitsstatus und die Domainflexibilität beim Deployment von Cloud-Ressourcen zu erhöhen.
- Ziehen Sie in Betracht, die verschiedenen OCI-Services, die jede Domain verwendet, zu trennen, indem Sie Compartments und IAM-Policys nutzen.
Datenproduktfreigabe
- Wenn Sie Datenprodukte über APIs bereitstellen müssen, sollten Sie Oracle REST Data Services verwenden.
- Wenn Sie Datenprodukte mit Oracle REST Data Services freigeben, sollten Sie die APIs mit Oracle Cloud Infrastructure API Gateway sichern.
- Wenn Sie Datenprodukte streamen müssen, sollten Sie Oracle Cloud Infrastructure GoldenGate und Oracle Cloud Infrastructure Streaming verwenden.
Mehr erfahren
Erfahren Sie mehr über die Features dieser Architektur und über zugehörige Architekturen.