Erstellen und trainieren Sie ML-Modelle mithilfe einer Data-Mesh-Architektur auf AWS: Teil 1

Unternehmen aus verschiedenen Branchen nutzen künstliche Intelligenz (KI) und maschinelles Lernen (ML), um branchenspezifische geschäftliche Herausforderungen zu lösen. In der Finanzdienstleistungsbranche können Sie beispielsweise KI und ML verwenden, um Herausforderungen in den Bereichen Betrugserkennung, Kreditrisikovorhersage, Direktmarketing und viele andere zu lösen.

Große Unternehmen richten manchmal ein Center of Excellence (CoE) ein, um die Bedürfnisse verschiedener Geschäftsbereiche (LoBs) mit innovativen Analyse- und ML-Projekten zu erfüllen.

Um qualitativ hochwertige und leistungsfähige ML-Modelle in großem Maßstab zu generieren, müssen sie Folgendes tun:

• Bieten Sie eine einfache Möglichkeit, auf relevante Daten für ihre Analysen und ML CoE zuzugreifen
• Erstellen Sie Rechenschaftspflicht für Datenanbieter von einzelnen LoBs, um kuratierte Datenbestände zu teilen, die auffindbar, verständlich, interoperabel und vertrauenswürdig sind

Dies kann die lange Zykluszeit für die Umwandlung von ML-Anwendungsfällen vom Experiment in die Produktion verkürzen und einen Geschäftswert im gesamten Unternehmen generieren.

Eine Data-Mesh-Architektur strebt danach, diese technischen und organisatorischen Herausforderungen zu lösen, indem sie einen dezentralisierten sozio-technischen Ansatz für die gemeinsame Nutzung, den Zugriff und die Verwaltung von Daten in komplexen und großen Umgebungen – innerhalb oder zwischen Organisationen – einführt. Das Data-Mesh-Designmuster schafft ein verantwortungsbewusstes Datenfreigabemodell, das sich an das Unternehmenswachstum anpasst, um das ultimative Ziel zu erreichen, die Rendite von Geschäftsinvestitionen in die Datenteams, Prozesse und Technologien zu steigern.

In dieser zweiteiligen Serie geben wir Anleitungen dazu, wie Organisationen eine moderne Datenarchitektur mit einem Data-Mesh-Designmuster auf AWS aufbauen und einem Analyse- und ML-CoE ermöglichen können, ML-Modelle mit Daten über mehrere LoBs hinweg zu erstellen und zu trainieren. Wir verwenden ein Beispiel einer Finanzdienstleistungsorganisation, um den Kontext und den Anwendungsfall für diese Serie festzulegen.

In diesem ersten Beitrag zeigen wir die Verfahren zum Einrichten einer Data-Mesh-Architektur mit mehreren AWS-Datenproduzenten- und Verbraucherkonten. Dann konzentrieren wir uns auf ein Datenprodukt, das einer LoB innerhalb der Finanzorganisation gehört, und wie es in einer Data-Mesh-Umgebung geteilt werden kann, damit andere LoBs dieses Datenprodukt nutzen und nutzen können. Dies richtet sich hauptsächlich an die Data-Steward-Persona, die dafür verantwortlich ist, den Prozess des Datenaustauschs zwischen Datenproduzenten und -verbrauchern zu rationalisieren und zu standardisieren und die Einhaltung der Data-Governance-Regeln sicherzustellen.

Im zweiten Beitrag zeigen wir ein Beispiel dafür, wie ein Analyse- und ML-CoE das Datenprodukt für einen Anwendungsfall zur Risikovorhersage nutzen kann. Dies richtet sich hauptsächlich an die Data Scientist-Persona, die für die Nutzung sowohl unternehmensweiter als auch von Datenbeständen von Drittanbietern verantwortlich ist, um ML-Modelle zu erstellen und zu trainieren, die Geschäftserkenntnisse extrahieren, um die Erfahrung von Finanzdienstleistungskunden zu verbessern.

Überblick über das Datennetz

Die Gründerin des Data-Mesh-Patterns, Zhamak Dehghani, in ihrem Buch Data Mesh liefert datengesteuerten Mehrwert in großem Maßstab, definierte vier Prinzipien für das Ziel des Datennetzes:

• Verteilter Domänenbesitz – Um einen organisatorischen Wechsel vom zentralisierten Dateneigentum durch Spezialisten, die die Datenplattformtechnologien betreiben, zu einem dezentralisierten Dateneigentumsmodell zu verfolgen und das Eigentum und die Rechenschaftspflicht für die Daten zurück zu den LoBs zu verlagern, wo Daten produziert (quellenorientierte Domänen) oder konsumiert werden ( verbrauchsorientierte Domains).
• Daten als Produkt – Um die Rechenschaftspflicht für die gemeinsame Nutzung kuratierter, hochwertiger, interoperabler und sicherer Datenbestände voranzutreiben. Daher sind Datenproduzenten aus verschiedenen LoBs dafür verantwortlich, Daten direkt an der Quelle in eine konsumierbare Form zu bringen.
• Self-Service-Analysen – Um die Erfahrung von Datenbenutzern von Analytics und ML zu optimieren, damit sie Datenprodukte mit ihren bevorzugten Tools entdecken, darauf zugreifen und diese verwenden können. Darüber hinaus soll die Erfahrung von LoB-Datenanbietern beim Erstellen, Bereitstellen und Verwalten von Datenprodukten über Rezepte und wiederverwendbare Komponenten und Vorlagen optimiert werden.
• Föderierte Computational Governance – Zusammenführung und Automatisierung der Entscheidungsfindung im Zusammenhang mit der Verwaltung und Kontrolle des Datenzugriffs auf der Ebene der Dateneigentümer aus den verschiedenen LoBs, was immer noch im Einklang mit den Rechts-, Compliance- und Sicherheitsrichtlinien der gesamten Organisation steht, die letztendlich durchgesetzt werden das Netz.

AWS stellte seine Vision zum Aufbau eines Datennetzes auf AWS in verschiedenen Beiträgen vor:

• Zunächst haben wir uns auf den organisatorischen Teil konzentriert, der mit verteiltem Domänenbesitz und Daten als Produktprinzipien verbunden ist. Die Autoren beschrieben die Vision, mehrere LOBs im gesamten Unternehmen auf eine Datenproduktstrategie auszurichten, die den verbrauchsorientierten Domänen Tools zum Auffinden und Abrufen der benötigten Daten zur Verfügung stellt und gleichzeitig die notwendige Kontrolle über die Verwendung dieser Daten gewährleistet, indem sie Rechenschaftspflicht einführt die an der Quelle ausgerichteten Domänen, um Datenprodukte bereitzustellen, die direkt an der Quelle verwendet werden können. Weitere Informationen finden Sie unter Wie JPMorgan Chase eine Data-Mesh-Architektur aufgebaut hat, um einen erheblichen Mehrwert zur Verbesserung seiner Unternehmensdatenplattform zu erzielen.
• Dann konzentrierten wir uns auf den technischen Teil im Zusammenhang mit der Erstellung von Datenprodukten, Self-Service-Analysen und föderierten Computational Governance-Prinzipien. Die Autoren beschrieben die AWS-Kerndienste, die es den quellenorientierten Domänen ermöglichen, Datenprodukte zu erstellen und zu teilen, eine Vielzahl von Diensten, die es verbraucherorientierten Domänen ermöglichen können, Datenprodukte auf unterschiedliche Weise zu nutzen, basierend auf ihren bevorzugten Tools und den Anwendungsfällen, die sie haben darauf hinarbeiten, und schließlich die AWS-Dienste, die das Datenfreigabeverfahren regeln, indem sie Datenzugriffsrichtlinien durchsetzen. Weitere Informationen finden Sie unter Entwerfen Sie eine Data-Mesh-Architektur mit AWS Lake Formation und AWS Glue.
• Wir zeigten auch eine Lösung zur Automatisierung der Datenermittlung und Zugriffskontrolle über eine zentralisierte Data-Mesh-Benutzeroberfläche. Weitere Einzelheiten finden Sie unter Erstellen Sie einen Datenfreigabe-Workflow mit AWS Lake Formation für Ihr Datennetz.

Anwendungsfall Finanzdienstleistungen

In der Regel haben große Finanzdienstleistungsunternehmen mehrere LoBs, wie z. B. Verbraucherbanken, Investmentbanken und Vermögensverwaltung, sowie ein oder mehrere Analyse- und ML-CoE-Teams. Jede LoB bietet unterschiedliche Dienstleistungen an:

• Die Consumer Banking LoB bietet eine Vielzahl von Dienstleistungen für Verbraucher und Unternehmen an, darunter Kredite und Hypotheken, Cash-Management, Zahlungslösungen, Einlagen- und Anlageprodukte und mehr
• Die Geschäfts- oder Investmentbanking-LoB bietet umfassende Finanzlösungen wie Kreditvergabe, Insolvenzrisiko und Großhandelszahlungen für Kunden, darunter kleine Unternehmen, mittelständische Unternehmen und große Konzerne
• Die LoB Vermögensverwaltung bietet Vorsorgeprodukte und Anlagedienstleistungen über alle Anlageklassen hinweg an

Jede LoB definiert ihre eigenen Datenprodukte, die von Personen kuratiert werden, die die Daten verstehen und am besten geeignet sind, anzugeben, wer berechtigt ist, sie zu verwenden, und wie sie verwendet werden können. Im Gegensatz dazu sind andere LoBs und Anwendungsdomänen wie Analytics und ML CoE daran interessiert, qualifizierte Datenprodukte zu entdecken und zu nutzen, sie zu kombinieren, um Erkenntnisse zu gewinnen, und datengesteuerte Entscheidungen zu treffen.

Die folgende Abbildung zeigt einige LoBs und Beispiele für Datenprodukte, die sie gemeinsam nutzen können. Es zeigt auch die Verbraucher von Datenprodukten wie Analytics und ML CoE, die ML-Modelle erstellen, die in kundenorientierten Anwendungen eingesetzt werden können, um die Erfahrung des Endkunden weiter zu verbessern.

Nach dem soziotechnischen Konzept des Datennetzes beginnen wir mit dem sozialen Aspekt mit einer Reihe von organisatorischen Schritten, wie z. B. den folgenden:

• Nutzung von Domänenexperten zur Definition von Grenzen für jede Domäne, sodass jedes Datenprodukt einer bestimmten Domäne zugeordnet werden kann
• Identifizieren von Eigentümern für Datenprodukte, die von jeder Domäne bereitgestellt werden, sodass jedes Datenprodukt eine von seinem Eigentümer definierte Strategie hat
• Identifizieren von Governance-Richtlinien aus globalen und lokalen oder föderierten Anreizen, sodass beim Zugriff von Datenkonsumenten auf ein bestimmtes Datenprodukt die mit dem Produkt verknüpfte Zugriffsrichtlinie automatisch über eine zentrale Data-Governance-Ebene durchgesetzt werden kann

Dann gehen wir zum technischen Aspekt über, der das folgende End-to-End-Szenario umfasst, das im vorherigen Diagramm definiert ist:

1. Statten Sie die Verbraucherbank-LoB mit Tools aus, um ein gebrauchsfertiges Verbraucherkreditprofil-Datenprodukt zu erstellen.
2. Ermöglichen Sie dem Consumer Banking LoB, Datenprodukte in der zentralen Governance-Schicht zu teilen.
3. Integrieren Sie globale und föderierte Definitionen von Datenzugriffsrichtlinien, die beim Zugriff auf das Verbraucherkreditprofil-Datenprodukt über die zentrale Datenverwaltung durchgesetzt werden sollten.
4. Ermöglichen Sie der Analyse und dem ML CoE, das Datenprodukt über die zentrale Governance-Schicht zu erkennen und darauf zuzugreifen.
5. Statten Sie die Analytik und ML CoE mit Tools aus, um das Datenprodukt zum Erstellen und Trainieren eines Kreditrisikovorhersagemodells zu nutzen. Die letzten Schritte (6 und 7 im vorherigen Diagramm) werden in dieser Reihe nicht behandelt. Um jedoch den geschäftlichen Wert zu zeigen, den ein solches ML-Modell in einem End-to-End-Szenario für die Organisation bringen kann, veranschaulichen wir Folgendes:
6. Dieses Modell könnte später wieder in kundenorientierten Systemen wie einem Verbraucherbanking-Webportal oder einer mobilen Anwendung eingesetzt werden.
7. Es kann innerhalb des Kreditantrags gezielt zur Beurteilung des Risikoprofils von Kredit- und Hypothekenanfragen eingesetzt werden.

Als Nächstes beschreiben wir die technischen Anforderungen der einzelnen Komponenten.

Tauchen Sie tief in die technischen Anforderungen ein

Um Datenprodukte für alle verfügbar zu machen, müssen Organisationen es einfach machen, Daten zwischen verschiedenen Einheiten im gesamten Unternehmen auszutauschen und gleichzeitig die angemessene Kontrolle darüber zu behalten, oder mit anderen Worten, Agilität mit angemessener Governance in Einklang zu bringen.

Datennutzer: Analytics und ML CoE

Die Datenkonsumenten wie Data Scientists aus Analytics und ML CoE müssen in der Lage sein, Folgendes zu tun:

• Entdecken und greifen Sie auf relevante Datensätze für einen bestimmten Anwendungsfall zu
• Sie können sicher sein, dass Datensätze, auf die sie zugreifen möchten, bereits kuratiert und auf dem neuesten Stand sind und aussagekräftige Beschreibungen haben
• Fordern Sie Zugriff auf Datensätze an, die für ihre Geschäftsfälle von Interesse sind
• Verwenden Sie ihre bevorzugten Tools, um solche Datensätze in ihrer Umgebung für ML abzufragen und zu verarbeiten, ohne Daten vom ursprünglichen Remote-Standort replizieren zu müssen oder sich um technische oder infrastrukturelle Komplexitäten kümmern zu müssen, die mit der Verarbeitung von Daten verbunden sind, die physisch an einem Remote-Standort gespeichert sind
• Lassen Sie sich über alle Datenaktualisierungen der Dateneigentümer benachrichtigen

Datenproduzent: Domain-Inhaberschaft

Die Datenproduzenten, wie z. B. Domänenteams aus verschiedenen LoBs in der Finanzdienstleistungsorganisation, müssen kuratierte Datensätze registrieren und freigeben, die Folgendes enthalten:

• Technische und operative Metadaten wie Datenbank- und Tabellennamen und -größen, Spaltenschemata und Schlüssel
• Geschäftsmetadaten wie Datenbeschreibung, Klassifizierung und Sensibilität
• Verfolgen von Metadaten wie Schemaentwicklung vom Quell- zum Zielformular und allen Zwischenformularen
• Datenqualitätsmetadaten wie Korrektheits- und Vollständigkeitsverhältnisse und Datenverzerrung
• Zugriffsrichtlinien und -verfahren

Diese werden benötigt, damit Datenkonsumenten Daten finden und darauf zugreifen können, ohne sich auf manuelle Verfahren verlassen zu müssen oder sich an die Domänenexperten des Datenprodukts wenden zu müssen, um mehr Wissen über die Bedeutung der Daten und den Zugriff darauf zu erlangen.

Data Governance: Auffindbarkeit, Zugänglichkeit und Überprüfbarkeit

Unternehmen müssen die zuvor erläuterte Agilität mit der angemessenen Minderung der mit Datenlecks verbundenen Risiken in Einklang bringen. Insbesondere in regulierten Branchen wie Finanzdienstleistungen besteht die Notwendigkeit, eine zentrale Datenverwaltung aufrechtzuerhalten, um einen umfassenden Datenzugriff und eine Auditkontrolle zu gewährleisten und gleichzeitig den Speicherbedarf zu reduzieren, indem mehrere Kopien derselben Daten an verschiedenen Standorten vermieden werden.

In traditionellen zentralisierten Data-Lake-Architekturen veröffentlichen die Datenproduzenten häufig Rohdaten und übertragen die Verantwortung für die Datenpflege, das Datenqualitätsmanagement und die Zugriffskontrolle an Daten- und Infrastrukturingenieure in einem zentralisierten Datenplattformteam. Diese Datenplattformteams sind jedoch möglicherweise weniger mit den verschiedenen Datendomänen vertraut und verlassen sich dennoch auf die Unterstützung der Datenproduzenten, um den Zugriff auf Daten gemäß den in jeder Datendomäne durchgesetzten Richtlinien ordnungsgemäß zu kuratieren und zu steuern. Im Gegensatz dazu sind die Datenproduzenten selbst am besten in der Lage, kuratierte, qualifizierte Datenbestände bereitzustellen, und sind sich der domänenspezifischen Zugriffsrichtlinien bewusst, die beim Zugriff auf Datenbestände durchgesetzt werden müssen.

Lösungsüberblick

Das folgende Diagramm zeigt die High-Level-Architektur der vorgeschlagenen Lösung.

Wir adressieren den Datenverbrauch durch Analytics und ML CoE mit Amazonas Athena und Amazon Sage Maker in Teil 2 dieser Serie.

In diesem Beitrag konzentrieren wir uns auf den Daten-Onboarding-Prozess in das Datennetz und beschreiben, wie eine einzelne LoB wie das Datenteam für Verbraucherbanken AWS-Tools wie verwenden kann AWS-Kleber und AWS Glue Data Brew um die Qualität ihrer Datenprodukte vorzubereiten, zu kuratieren und zu verbessern und diese Datenprodukte dann im zentralen Data-Governance-Konto zu registrieren AWS Lake-Formation.

LoB Consumer Banking (Datenproduzent)

Eines der Kernprinzipien von Data Mesh ist das Konzept von Daten als Produkt. Es ist sehr wichtig, dass das Consumer-Banking-Domänendatenteam an der Vorbereitung von Datenprodukten arbeitet, die für die Verwendung durch Datenkonsumenten bereit sind. Dies kann durch die Verwendung von AWS-Tools zum Extrahieren, Transformieren und Laden (ETL) wie AWS Glue erfolgen, um die gesammelten Rohdaten zu verarbeiten Amazon Simple Storage-Service (Amazon S3) oder stellen Sie alternativ eine Verbindung zu den Betriebsdatenspeichern her, in denen die Daten produziert werden. Sie können auch verwenden DataBrew, ein visuelles Datenvorbereitungstool ohne Code, mit dem sich Daten einfach bereinigen und normalisieren lassen.

Beispielsweise kann das Consumer-Banking-Domänendatenteam bei der Vorbereitung des Verbraucherkreditprofil-Datenprodukts eine einfache Kuration vornehmen, um die Attributnamen der aus dem Open-Source-Datensatz abgerufenen Rohdaten aus dem Deutschen ins Englische zu übersetzen Statlog Kreditdaten Deutschland, die aus 20 Attributen und 1,000 Zeilen besteht.

Datenamt

Lake Formation ist der zentrale AWS-Service zur Ermöglichung der Data-Mesh-Governance. Lake Formation bietet die Möglichkeit, Data Governance innerhalb jeder Datendomäne und domänenübergreifend durchzusetzen, um sicherzustellen, dass Daten leicht auffindbar und sicher sind. Es bietet ein föderiertes Sicherheitsmodell, das zentral verwaltet werden kann, mit Best Practices für Datenerkennung, Sicherheit und Compliance und ermöglicht gleichzeitig eine hohe Agilität innerhalb jeder Domäne.

Lake Formation bietet eine API zur Vereinfachung der Erfassung, Speicherung und Verwaltung von Daten sowie Sicherheit auf Zeilenebene zum Schutz Ihrer Daten. Es bietet auch Funktionen wie granulare Zugriffskontrolle, gesteuerte Tabellen und Speicheroptimierung.

Darüber hinaus bietet Lake Formations a Datenfreigabe-API die Sie zum Teilen von Daten verwenden können über verschiedene Konten. Dies ermöglicht dem Analyse- und ML CoE-Konsumenten, Athena-Abfragen auszuführen, die Tabellen über mehrere Konten hinweg abfragen und verknüpfen. Weitere Informationen finden Sie unter AWS Lake Formation-Entwicklerhandbuch.

AWS-Ressourcenzugriffsmanager (AWS RAM) bietet eine sichere Methode zur gemeinsamen Nutzung von Ressourcen über AWS Identity and Access Manager (IAM)-Rollen und -Benutzer über AWS-Konten innerhalb einer Organisation oder Organisationseinheiten (OUs) hinweg AWS-Organisationen.

Lake Formation bietet zusammen mit AWS RAM eine Möglichkeit, die gemeinsame Nutzung von Daten und den Zugriff über AWS-Konten hinweg zu verwalten. Wir bezeichnen diesen Ansatz als RAM-basierte Zugriffskontrolle. Weitere Einzelheiten zu diesem Ansatz finden Sie unter Erstellen Sie einen Datenfreigabe-Workflow mit AWS Lake Formation für Ihr Datennetz.

Lake Formation bietet auch eine andere Möglichkeit, die gemeinsame Nutzung und den Zugriff auf Daten zu verwalten Lake-Formation-Tags. Wir bezeichnen diesen Ansatz als Tag-basierte Zugriffskontrolle. Weitere Einzelheiten finden Sie unter Erstellen Sie mithilfe der Tag-basierten Zugriffskontrolle von AWS Lake Formation eine moderne Datenarchitektur und ein Data-Mesh-Muster im großen Maßstab.

In diesem Beitrag verwenden wir den Tag-basierten Zugriffssteuerungsansatz, da er die Erstellung von Richtlinien für eine kleinere Anzahl logischer Tags vereinfacht, die üblicherweise in verschiedenen LoBs zu finden sind, anstatt Richtlinien für benannte Ressourcen auf Infrastrukturebene festzulegen.

Voraussetzungen:

Um eine Data-Mesh-Architektur einzurichten, benötigen Sie mindestens drei AWS-Konten: ein Producer-Konto, ein zentrales Konto und ein Consumer-Konto.

Stellen Sie die Data-Mesh-Umgebung bereit

Um eine Data-Mesh-Umgebung bereitzustellen, können Sie Folgendes verwenden GitHub-Repository. Dieses Repository enthält drei AWS CloudFormation Vorlagen, die eine Datennetzumgebung bereitstellen, die jedes der Konten (Produzent, Zentral und Verbraucher) umfasst. In jedem Konto können Sie die entsprechende CloudFormation-Vorlage ausführen.

Zentrales Konto

Führen Sie im zentralen Konto die folgenden Schritte aus:

1. Starten Sie den CloudFormation-Stack:
   
2. Erstellen Sie zwei IAM-Benutzer:
   1. DataMeshOwner
   2. ProducerSteward
3. Gewähren DataMeshOwner als Lake Formation-Administrator.
4. Erstellen Sie eine IAM-Rolle:
   1. LFRegisterLocationServiceRole
5. Erstellen Sie zwei IAM-Richtlinien:
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. Erstellen Sie die Datenbank Kreditkarte für ProducerSteward auf dem Produzentenkonto.
7. Teilen Sie die Datenstandortberechtigung mit dem Produzentenkonto.

Produzentenkonto

Führen Sie im Produzentenkonto die folgenden Schritte aus:

1. Starten Sie den CloudFormation-Stack:
   
2. Erstellen Sie den S3-Bucket credit-card, die den Tisch hält credit_card.
3. Erlauben Sie S3-Bucket-Zugriff für die Lake Formation-Dienstrolle des zentralen Kontos.
4. Erstellen Sie den AWS Glue-Crawler creditCrawler-<ProducerAccountID>.
5. Erstellen Sie eine AWS Glue-Crawler-Servicerolle.
6. Erteilen Sie Berechtigungen für den Speicherort des S3-Buckets credit-card-<ProducerAccountID>-<aws-region> zur AWS Glue-Crawler-Rolle.
7. Erstellen Sie einen Producer-Steward-IAM-Benutzer.

Verbraucherkonto

Führen Sie im Verbraucherkonto die folgenden Schritte aus:

1. Starten Sie den CloudFormation-Stack:
   
2. Erstellen Sie den S3-Bucket <AWS Account ID>-<aws-region>-athena-logs.
3. Erstellen Sie die Athena-Arbeitsgruppe consumer-workgroup.
4. IAM-Benutzer erstellen ConsumerAdmin.

Fügen Sie eine Datenbank hinzu und abonnieren Sie das Verbraucherkonto dafür

Nachdem Sie die Vorlagen ausgeführt haben, können Sie die Schritt-für-Schritt-Anleitung um ein Produkt in den Datenkatalog aufzunehmen und es vom Verbraucher abonnieren zu lassen. Der Leitfaden beginnt mit der Einrichtung einer Datenbank, in der der Hersteller seine Produkte platzieren kann, und erklärt dann, wie der Verbraucher diese Datenbank abonnieren und auf die Daten zugreifen kann. All dies wird während der Verwendung durchgeführt LF-Tags, das ist die Tag-basierte Zugriffskontrolle für Seenbildung.

Datenproduktregistrierung

Die folgende Architektur beschreibt die detaillierten Schritte, wie das LoB-Team für Verbraucherbanken, das als Datenproduzenten fungiert, seine Datenprodukte im zentralen Data-Governance-Konto registrieren kann (Integrieren von Datenprodukten in das Datennetz der Organisation).

Die allgemeinen Schritte zum Registrieren eines Datenprodukts sind wie folgt:

1. Erstellen Sie eine Zieldatenbank für das Datenprodukt im zentralen Governance-Konto. Beispielsweise erstellt die CloudFormation-Vorlage aus dem zentralen Konto bereits die Zieldatenbank credit-card.
2. Teilen Sie die erstellte Zieldatenbank mit dem Ursprung im Produzentenkonto.
3. Erstellen Sie einen Ressourcenlink der gemeinsam genutzten Datenbank im Produzentenkonto. Im folgenden Screenshot sehen wir das auf der Lake Formation-Konsole im Producer-Account rl_credit-card ist der Ressourcenlink der credit-card Datenbank.
   
4. Füllen Sie Tabellen (mit den im Produzentenkonto kuratierten Daten) in der Ressourcen-Link-Datenbank (rl_credit-card) mit einem AWS Glue-Crawler im Produzentenkonto.
   

Die erstellte Tabelle erscheint automatisch im zentralen Governance-Konto. Der folgende Screenshot zeigt ein Beispiel der Tabelle in Lake Formation im zentralen Konto. Dies erfolgt nach dem Ausführen der vorherigen Schritte zum Auffüllen der Ressourcenverknüpfungsdatenbank rl_credit-card im Produzentenkonto.

Zusammenfassung

In Teil 1 dieser Serie haben wir die Ziele von Finanzdienstleistungsunternehmen diskutiert, um mehr Agilität für ihre Analyse- und ML-Teams zu erreichen und die Zeit von Daten zu Erkenntnissen zu verkürzen. Wir haben uns auch auf den Aufbau einer Data-Mesh-Architektur auf AWS konzentriert, wo wir benutzerfreundliche, skalierbare und kostengünstige AWS-Services wie AWS Glue, DataBrew und Lake Formation eingeführt haben. Datenerzeugende Teams können diese Dienste nutzen, um kuratierte, qualitativ hochwertige, interoperable und sichere Datenprodukte zu erstellen und zu teilen, die von verschiedenen Datenkonsumenten für Analysezwecke verwendet werden können.

In Teil 2, konzentrieren wir uns auf Analyse- und ML-CoE-Teams, die Datenprodukte verwenden, die von der Verbraucherbank-LoB geteilt werden, um ein Kreditrisikovorhersagemodell mit AWS-Diensten wie Athena und SageMaker zu erstellen.

---

Über die Autoren

Karim Hammuda ist Specialist Solutions Architect for Analytics bei AWS mit einer Leidenschaft für Datenintegration, Datenanalyse und BI. Er arbeitet mit AWS-Kunden zusammen, um Analyselösungen zu entwickeln und zu entwickeln, die zu ihrem Geschäftswachstum beitragen. In seiner Freizeit schaut er gerne TV-Dokumentationen und spielt mit seinem Sohn Videospiele.

Hasan Poonawala ist Senior AI/ML Specialist Solutions Architect bei AWS und unterstützt Kunden bei der Entwicklung und Bereitstellung von Anwendungen für maschinelles Lernen in der Produktion auf AWS. Er verfügt über mehr als 12 Jahre Berufserfahrung als Datenwissenschaftler, Praktiker des maschinellen Lernens und Softwareentwickler. In seiner Freizeit liebt Hasan es, die Natur zu erkunden und Zeit mit Freunden und Familie zu verbringen.

Benoît de Patoul ist AI/ML Specialist Solutions Architect bei AWS. Er hilft Kunden, indem er Anleitungen und technische Unterstützung bereitstellt, um Lösungen im Zusammenhang mit KI/ML mit AWS zu entwickeln. In seiner Freizeit spielt er gerne Klavier und verbringt Zeit mit Freunden.