Self-Service-Datenplattform für ein Data Mesh entwerfen

Last reviewed 2022-10-06 UTC

In einem Data Mesh können Nutzer mit einer Self-Service-Datenplattform Daten effizient nutzen, um Datenprodukte automatisch zu erstellen, freizugeben und zu verwenden. Um diese Vorteile umfassend nutzen zu können, empfehlen wir Ihnen, Ihre Self-Service-Datenplattform mit den in diesem Dokument beschriebenen Funktionen bereitzustellen.

Dieses Dokument ist Teil einer Reihe, in der beschrieben wird, wie ein Data Mesh in Google Cloud implementiert wird. Dabei wird davon ausgegangen, dass Sie die in den folgenden Beschreibungen beschriebenen Konzepte gelesen haben und mit ihnen vertraut sind: Modernes, verteiltes Data Mesh mit Google Cloud erstellen und Architektur und Funktionen in einem Data Mesh.

Die Reihe besteht aus folgenden Teilen:

Datenplattformteams erstellen in der Regel zentrale Self-Service-Datenplattformen, wie in diesem Dokument beschrieben. Dieses Team erstellt die Lösungen und Komponenten, die von Domainteams (sowohl Datenersteller als auch Datennutzer) zum Erstellen und Verarbeiten von Datenprodukten verwendet werden können. Domainteams sind die funktionalen Teile eines Data Mesh. Durch das Erstellen dieser Komponenten ermöglicht das Datenplattformteam eine reibungslose Entwicklung und vereinfacht die Erstellung, Bereitstellung und Wartung von Datenprodukten, die sicher und interoperabel sind.

Das Datenplattformteam soll den Domainteams letztendlich zu einer schnelleren Umsetzung verhelfen. Sie steigern die Effizienz von Domainteams, indem sie den Teams eine begrenzte Anzahl von Tools zur Verfügung stellen, die ihren Anforderungen entsprechen. Durch die Bereitstellung dieser Tools beseitigt das Datenplattformteam den Aufwand für die Domainteams, diese Tools selbst erstellen und beziehen zu müssen. Die Tools sollten an verschiedene Anforderungen anpassbar sein und den Datendomainteams keine unflexiblen Arbeitsmethoden aufzwingen.

Das Datenplattformteam sollte sich nicht auf die Erstellung benutzerdefinierter Lösungen für Datenpipeline-Orchestratoren oder für CI-/CD-Systeme (Continuous Integration/Continuous Deployment) konzentrieren. Lösungen wie CI/CD-Systeme sind als verwaltete Cloud-Dienste wie Cloud Build verfügbar. Durch den Einsatz verwalteter Cloud-Dienste kann den Betriebsaufwand für das Datenplattformteam reduziert und die Konzentration auf die spezifischen Anforderungen der Datendomainteams als Nutzer der Plattform erhöht werden. Der geringere operative Aufwand ermöglicht es dem Datenplattformteam mehr Zeit für die Erfüllung der spezifischen Anforderungen der Datendomainteams aufzuwenden.

Architektur

Das folgende Diagramm veranschaulicht die Architekturkomponenten einer Self-Service-Datenplattform. Das Diagramm zeigt auch, wie diese Komponenten Teams unterstützen können, wenn sie Datenprodukte im gesamten Data Mesh entwickeln und nutzen.

Grafik: Self-Service-Datenplattformkomponenten, wie im folgenden Text beschrieben.

Wie im vorherigen Diagramm dargestellt, bietet die Self-Service-Datenplattform Folgendes:

  • Plattformlösungen: Diese Lösungen bestehen aus zusammensetzbaren Komponenten für die Bereitstellung von Google Cloud-Projekten und -Ressourcen, die Nutzer auswählen und in verschiedenen Kombinationen zusammenstellen können, um ihre spezifischen Anforderungen zu erfüllen. Statt direkt mit den Komponenten zu interagieren, können Nutzer der Plattform mit Plattformlösungen interagieren, um ein bestimmtes Ziel zu erreichen. Datendomainteams sollten Plattformlösungen entwickeln, um häufige Probleme und Probleme zu lösen, die zu einer Verlangsamung bei der Entwicklung und Nutzung von Datenprodukten führen. Beispielsweise können Datendomainteams, die das Data Mesh einrichten, eine IaC-Vorlage (Infrastructure-as-Code) verwenden. Mithilfe von IaC-Vorlagen können sie schnell eine Reihe von Google Cloud-Projekten mit Standard-IAM-Berechtigungen (Identity and Access Management), Netzwerk-, Sicherheitsrichtlinien und relevanten Google Cloud APIs erstellen, die für die Datenproduktentwicklung aktiviert sind. Wir empfehlen, dass für jede Lösung auch eine Dokumentation wie "Erste Schritte"-Anleitungen und Codebeispiele zur Verfügung stehen. Datenplattformlösungen und ihre Komponenten müssen standardmäßig sicher und konform sein.

  • Allgemeine Dienste: Diese Dienste bieten die Sichtbarkeit, Verwaltung, Freigabe und Beobachtbarkeit von Datenprodukten. Diese Dienste stärken das Vertrauen von Datennutzern in Datenprodukte und sind für Datenersteller eine effektive Möglichkeit, Datennutzer auf Probleme mit ihren Datenprodukten hinzuweisen.

Lösungen für Datenplattformen und gängige Dienste können Folgendes umfassen:

  • IaC-Vorlagen zum Einrichten grundlegender Arbeitsbereiche für die Datenproduktentwicklung, darunter:
    • IAM
    • Logging und Monitoring
    • Netzwerk
    • Sicherheits- und Compliancevorkehrungen
    • Ressourcen-Tagging für die Abrechnung von Attributionen
    • Speicherung, Transformation und Veröffentlichung von Datenprodukten
    • Registrierung, Katalogisierung und Metadaten von Datenprodukten
  • IaC-Vorlagen, die Sicherheitsvorkehrungen für die Organisation und Best Practices befolgen, mit denen Google Cloud-Ressourcen in vorhandenen Arbeitsbereichen für die Datenproduktentwicklung bereitgestellt werden können.
  • Anwendungs- und Datenpipelinevorlagen, die zum Bootstrapping neuer Projekte oder als Referenz für vorhandene Projekte verwendet werden können. Beispiele für solche Vorlagen:
    • Verwendung gängiger Bibliotheken und Frameworks
    • Tools für Plattform-Logging, Monitoring und Beobachtbarkeit einbinden
    • Build- und Test-Tools
    • Konfigurationsverwaltung
    • Paketerstellung und CI/CD-Pipelines für die Bereitstellung
    • Authentifizierung, Bereitstellung und Verwaltung von Anmeldedaten
  • Häufige Dienste zur Bereitstellung von Beobachtbarkeit und Governance für Datenprodukte, die Folgendes umfassen können:
    • Verfügbarkeitsdiagnosen zur Anzeige des Gesamtstatus von Datenprodukten
    • Benutzerdefinierte Messwerte zur Lieferung nützlicher Indikatoren für Datenprodukte
    • Operative Unterstützung durch das zentrale Team zur Benachrichtigung der Datennutzerteams über Änderungen an verwendeten Datenprodukten
    • Produktübersichten zur Darstellung der Leistung von Datenprodukten
    • Metadatenkatalog zur Erkennung von Datenprodukten
    • Ein zentral definiertes Set von Computing-Richtlinien für die globale Anwendung auf das Data Mesh
    • Marketplace für eine vereinfachte Datenfreigabe zwischen Domainteams

Unter Plattformkomponenten und -lösungen mithilfe von IaC-Vorlagen erstellen werden die Vorteile von IaC-Vorlagen zum Freigeben und Bereitstellen von Datenprodukten erläutert. Unter Allgemeine Dienste bereitstellen wird erläutert, warum es hilfreich ist, Domainteams gemeinsame Infrastrukturkomponenten bereitzustellen, die vom Datenplattformteam erstellt und verwaltet werden.

Plattformkomponenten und -lösungen mit IaC-Vorlagen erstellen

Das Ziel von Datenplattformteams ist die Einrichtung von Self-Service-Datenplattformen, um die Daten optimal nutzen zu können. Für die Erstellung dieser Plattformen statten sie Domainteams mit geprüften, sicheren und Self-Service-Infrastrukturvorlagen aus. Domainteams verwenden diese Vorlagen, um ihre Datenentwicklungs- und Datenverbrauchsumgebungen bereitzustellen. IaC-Vorlagen unterstützen Datenplattformteams dabei, dieses Ziel zu erreichen und die Skalierung zu ermöglichen. Die Verwendung geprüfter und vertrauenswürdiger IaC-Vorlagen vereinfacht den Ressourcenbereitstellungsprozess für Domainteams, da diese Teams vorhandene CI/CD-Pipelines wiederverwenden können. Auf diese Weise können Domainteams schnell loslegen und im Data Mesh produktiv werden.

IaC-Vorlagen können mit einem IaC-Tool erstellt werden. Es gibt zwar mehrere IaC-Tools, darunter Cloud Config Connector, Pulumi, Chef und Ansible, die Beispiele in diesem Dokument sind jedoch für Terraform basierte IaC-Tools. Terraform ist ein Open-Source-IaC-Tool, mit dem das Datenplattformteam effiziente zusammensetzbare Plattformkomponenten und -lösungen für Google Cloud-Ressourcen erstellen kann. Mit Terraform schreibt das Datenplattformteam Code, der den gewünschten Endstatus angibt, und lässt das Tool herausfinden, wie dieser Status erreicht werden kann. Dieser deklarative Ansatz ermöglicht es dem Datenplattformteam, Infrastrukturressourcen als unveränderliche Artefakte für die Bereitstellung in verschiedenen Umgebungen zu behandeln. Außerdem verringern Sie das Risiko von Inkonsistenzen zwischen bereitgestellten Ressourcen und dem deklarierten Code in der Versionsverwaltung (auch als Konfigurationsabweichung bezeichnet). Konfigurationsabweichungen, die durch Ad-hoc- und manuelle Änderungen an der Infrastruktur verursacht werden, verhindern die sichere und wiederholbare Bereitstellung von IaC-Komponenten in Produktionsumgebungen.

Gängige IaC-Vorlagen für zusammensetzbare Plattformkomponenten umfassen die Verwendung von Terraform-Modulen zum Bereitstellen von Ressourcen wie einem BigQuery-Dataset, einem Cloud Storage-Bucket oder einer Cloud SQL-Datenbank. Terraform-Module können zu End-to-End-Lösungen für die Bereitstellung vollständiger Google Cloud-Projekte kombiniert werden, einschließlich relevanter Ressourcen, die mithilfe der zusammensetzbaren Module bereitgestellt werden. Beispiele für Terraform-Module finden Sie in den Terraform-Blueprints für Google Cloud.

Jedes Terraform-Modul sollte standardmäßig die von Ihrer Organisation verwendeten Sicherheitsmaßnahmen und Compliance-Richtlinien erfüllen. Diese Leitlinien und Richtlinien können auch als Code ausgedrückt und mit automatisierten Tools zur Complianceprüfung wie dem Richtlinienvalidierungstool von Google Cloud automatisiert werden.

Ihre Organisation sollte kontinuierlich die von der Plattform bereitgestellten Terraform-Module testen und dabei die gleichen automatisierten Compliance-Schutzmechanismen verwenden, die sie zum Hochstufen von Änderungen in der Produktion verwenden.

Damit IaC-Komponenten und -Lösungen für Domainteams mit minimalen Erfahrung mit Terraform auffindbar und nutzbar sind, empfehlen wir die Verwendung von Diensten wie Service Catalog. Nutzer mit erheblichen Anpassungsanforderungen sollten ihre eigenen Bereitstellungslösungen aus denselben zusammensetzbaren Terraform-Vorlagen erstellen können, die auch von vorhandenen Lösungen verwendet werden.

Bei der Verwendung von Terraform empfehlen wir, die Best Practices von Google Cloud zu befolgen, wie unter Best Practices für die Verwendung von Terraform beschrieben.

In den folgenden Abschnitten wird beispielhaft gezeigt, wie Terraform verwendet werden kann, um Plattformkomponenten zu erstellen, Verbrauchsschnittstellen freizugeben und ein Datenprodukt zu nutzen.

Verbrauchsschnittstelle freigeben

Eine Verbrauchsschnittstelle für ein Datenprodukt bildet eine sichere Grundlage für die Datenqualität und Betriebsparameter, die vom Datendomainteam bereitgestellt werden, damit andere Teams ihre Datenprodukte finden und verwenden können. Jede Verbrauchsschnittstelle enthält außerdem ein Produktsupportmodell und eine Produktdokumentation. Ein Datenprodukt kann unterschiedliche Arten von Verbrauchsschnittstellen haben, z. B. APIs oder Streams, wie unter Datenprodukte in einem Data Mesh erstellen beschrieben. Die am häufigsten verwendete Verbrauchsschnittstelle ist möglicherweise ein autorisiertes BigQuery-Dataset, eine autorisierte Ansicht oder eine autorisierte Funktion. Diese Schnittstelle stellt eine schreibgeschützte virtuelle Tabelle bereit, die als Abfrage im Data Mesh ausgedrückt wird. Die Schnittstelle gewährt keine Leserberechtigungen für den direkten Zugriff auf die zugrunde liegenden Daten.

Google stellt ein Terraform-Modul zum Erstellen autorisierter Ansichten zur Verfügung, ohne Teams Berechtigungen für die zugrunde liegenden autorisierten Datasets zu erteilen. Der folgende Code aus diesem Terraform-Modul gewährt diese IAM-Berechtigungen in der autorisierten Ansicht dataset_id:

module "add_authorization" {
  source = "terraform-google-modules/bigquery/google//modules/authorization"
  version = "~> 4.1"

  dataset_id = module.dataset.bigquery_dataset.dataset_id
  project_id = module.dataset.bigquery_dataset.project

  roles = [
    {
      role           = "roles/bigquery.dataEditor"
      group_by_email = "ops@mycompany.com"
    }
  ]

  authorized_views = [
    {
      project_id = "view_project"
      dataset_id = "view_dataset"
      table_id   = "view_id"
    }
  ]
  authorized_datasets = [
    {
      project_id = "auth_dataset_project"
      dataset_id = "auth_dataset"
    }
  ]
}

Wenn Sie Nutzern Zugriff auf mehrere Ansichten gewähren müssen, kann das Gewähren des Zugriffs auf jede autorisierte Ansicht sowohl zeitaufwendig als auch schwieriger sein. Statt mehrere autorisierte Ansichten zu erstellen, können Sie ein autorisiertes Dataset verwenden, um alle im autorisierten Dataset erstellten Ansichten automatisch zu autorisieren.

Datenprodukt nutzen

Bei den meisten Analyseanwendungsfällen werden Verbrauchsmuster von der Anwendung bestimmt, in der die Daten verwendet werden. Eine zentral bereitgestellte Verbrauchsumgebung dient hauptsächlich zur Datenexploration, bevor die Daten in der verbrauchenden Anwendung verwendet werden. Wie unter Produkte in einem Data Mesh ermitteln und nutzen beschrieben, ist SQL die am häufigsten verwendete Methode zum Abfragen von Datenprodukten. Aus diesem Grund sollte die Datenplattform Datennutzern eine SQL-Anwendung zur Untersuchung der Daten zur Verfügung stellen.

Abhängig vom Analyseanwendungsfall können Sie Terraform möglicherweise verwenden, um die Nutzungsumgebung für Datennutzer bereitzustellen. Data Science ist beispielsweise ein häufiger Anwendungsfall für Datennutzer. Sie können Terraform verwenden, um nutzerverwaltete Vertex AI-Notebooks bereitzustellen, die als Data-Science-Entwicklungsumgebung verwendet werden. Von den Data-Science-Notebooks können sich Datennutzer mit ihren Anmeldedaten beim Data Mesh anmelden, um Daten zu untersuchen, auf die sie Zugriff haben, und ML-Modelle anhand dieser Daten zu entwickeln.

Informationen zum Bereitstellen und Sichern einer Notebook-Umgebung mit Terraform in Google Cloud finden Sie unter Vertrauliche Daten in nutzerverwalteten Notebooks von Vertex AI Workbench schützen.

Allgemeine Dienste bereitstellen

Zusätzlich zu den Self-Service-IaC-Komponenten und -Lösungen kann das Datenplattformteam auch die Verantwortung für die Erstellung und den Betrieb gemeinsamer Plattformdienste übernehmen, die von mehreren Datendomainteams verwendet werden. Gängige Beispiele für gemeinsam genutzte Plattformdienste sind selbst gehostete Software von Drittanbietern wie Business Intelligence-Visualisierungstools oder ein Kafka-Cluster. In Google Cloud kann das Datenplattformteam im Auftrag von Datendomainteams Ressourcen wie Dataplex- und Cloud Logging-Senken verwalten. Durch die Verwaltung von Ressourcen für die Datendomainteams kann das Datenplattformteam die zentrale Richtlinienverwaltung und Prüfprozesse im gesamten Unternehmen vereinfachen.

In den folgenden Abschnitten wird gezeigt, wie Sie Dataplex für die zentrale Verwaltung und Governance in einem Data Mesh in Google Cloud verwenden und wie Sie Features zur Beobachtbarkeit von Daten in einem Data Mesh implementieren.

Dataplex für Data Governance

Dataplex bietet eine Datenverwaltungsplattform, mit der Sie unabhängige Datendomains innerhalb eines Data Mesh erstellen können, das die Organisation umfasst. Mit Dataplex können Sie zentrale Kontrollen für die Steuerung und Überwachung von Daten über Domains hinweg herstellen.

Mit Dataplex kann eine Organisation ihre Daten (unterstützte Datenquellen) und zugehörige Artefakte wie Code, Notebooks und Logs logisch in einem Dataplex Lake gruppieren, der eine Datendomain darstellt. Im folgenden Diagramm verwendet eine Vertriebsdomain Dataplex, um ihre Assets, einschließlich der Datenqualitätsmesswerte und Logs, in Dataplex-Zonen zu organisieren.

Grafik: Von Dataplex organisierte Assets.

Wie im vorherigen Diagramm gezeigt, kann Dataplex verwendet werden, um Domaindaten über die folgenden Assets zu verwalten:

  • Mit Dataplex können Datendomainteams Datenressourcen in einer logischen Gruppe namens "Dataplex Lake" einheitlich verwalten. Das Datendomainteam kann seine Dataplex-Assets im selben Dataplex Lake erstellen, ohne Daten physisch zu verschieben oder in einem einzelnen Speichersystem zu speichern. Dataplex-Assets können sich auf Cloud Storage-Buckets und BigQuery-Datasets beziehen, die in anderen Google Cloud-Projekten als dem Google Cloud-Projekt gespeichert sind, das den Dataplex Lake enthält. Dataplex-Assets können strukturiert oder unstrukturiert sein oder in einem analytischen Data Lake oder Data Warehouse gespeichert werden. Im Diagramm gibt es Data Lakes für die Vertriebsdomain, die Lieferkettendomain und die Produktdomain.
  • Mit Dataplex-Zonen kann das Datendomainteam Datenassets in kleineren Untergruppen innerhalb desselben Dataplex Lake gruppieren und Strukturen hinzufügen, die wichtige Aspekte der Untergruppe erfassen. Zum Beispiel können Dataplex-Zonen verwendet werden, um zugehörige Datenassets in einem Datenprodukt zu gruppieren. Durch das Gruppieren von Datenassets in einer einzelnen Dataplex-Zone können Datendomainteams Zugriffsrichtlinien und Data Governance-Richtlinien einheitlich in der gesamten Zone als einzelnes Datenprodukt verwalten. Im Diagramm gibt es Datenzonen für Offline- und Onlineverkäufe, Lieferketten-Warehouses und Produkte.

Dataplex Lakes und Zonen ermöglichen es einer Organisation, verteilte Daten zu vereinheitlichen und auf der Grundlage des Geschäftskontexts zu organisieren. Diese Struktur bildet die Grundlage für Aktivitäten wie das Verwalten von Metadaten, das Einrichten von Governance-Richtlinien und das Überwachen der Datenqualität. Mit solchen Aktivitäten kann die Organisation ihre verteilten Daten in großem Maßstab verwalten, z. B. in einem Data Mesh.

Beobachtbarkeit von Daten

Für jede Datendomain sollten eigene Monitoring- und Benachrichtigungsmechanismen implementiert werden, die idealerweise einen standardisierten Ansatz verwenden. Jede Domain kann die unter Konzepte im Dienst-Monitoring beschriebenen Monitoring-Praktiken anwenden und die erforderlichen Anpassungen an den Datendomains vornehmen. Beobachtbarkeit ist ein umfangreiches Thema und wird in diesem Dokument nicht behandelt. In diesem Abschnitt werden nur Muster behandelt, die für Data Mesh-Implementierungen nützlich sind.

Bei Produkten mit mehreren Datennutzern kann die Bereitstellung von zeitnahen Informationen zu dem Status des Produkts zu einer operativen Belastung werden. Einfache Lösungen wie manuell verwaltete E-Mail-Distributionen sind in der Regel anfällig für Fehler. Sie können nützlich sein, um Nutzer über geplante Ausfälle, bevorstehende Produkteinführungen und Einstellungsvorgänge zu informieren, aber sie bieten keine operative Kenntnis in Echtzeit.

Zentrale Dienste können eine wichtige Rolle bei der Überwachung des Zustands und der Qualität der Produkte im Data Mesh spielen. Obwohl die Verwendung von Beobachtbarkeitsfeatures keine Voraussetzung für eine erfolgreiche Implementierung des Data Mesh ist, kann die Zufriedenheit der Datenersteller und -nutzer verbessert und die Betriebs- und Supportkosten insgesamt gesenkt werden. Das folgende Diagramm zeigt eine Architektur der Beobachtbarkeit des Data Mesh, die auf Cloud Monitoring basiert.

Grafik: Beobachtbarkeit des Data Mesh

In den folgenden Abschnitten werden die im Diagramm gezeigten Komponenten beschrieben:

Verfügbarkeitsdiagnosen

Datenprodukte können einfache benutzerdefinierte Anwendungen erstellen, die Verfügbarkeitsdiagnosen implementieren. Diese Diagnosen können als übergeordnete Indikatoren für den Gesamtstatus des Produkts dienen. Wenn beispielsweise das Datenproduktteam einen plötzlichen Rückgang der Datenqualität seines Produkts feststellt, kann das Team dieses Produkt als fehlerhaft markieren. Verfügbarkeitsdiagnosen, die nahezu in Echtzeit erfolgen, sind besonders für Datennutzer wichtig, die Produkte abgeleitet haben, die von der konstanten Verfügbarkeit der Daten im vorgelagerten Datenprodukt abhängen. Datenersteller sollten ihre Verfügbarkeitsdiagnosen so erstellen, dass sie vorgelagerte Abhängigkeiten prüfen. Dadurch erhalten sie einen genauen Überblick über den Zustand ihres Produkts.

Datennutzer können in ihre Verarbeitung Verfügbarkeitsdiagnosen aufnehmen. Beispielsweise kann ein Composer-Job, der einen Bericht anhand der Daten generiert, die von einem Datenprodukt bereitgestellt werden, im ersten Schritt prüfen, ob sich das Produkt im Status "Wird ausgeführt" befindet. Wir empfehlen, dass Ihre Anwendung für die Verfügbarkeitsdiagnose eine strukturierte Nutzlast im Nachrichtentext der HTTP-Antwort zurückgibt. Diese strukturierte Nutzlast sollte angeben, ob ein Problem vorliegt, und zwar die Ursache des Problems in menschenlesbarer Form und nach Möglichkeit die geschätzte Zeit für die Wiederherstellung des Dienstes. Diese strukturierte Nutzlast kann auch detailliertere Informationen zum Zustand des Produkts liefern. Beispielsweise kann sie die Zustandsinformationen für jede der Ansichten im autorisierten Dataset enthalten, die als Produkt bereitgestellt werden.

Benutzerdefinierte Messwerte

Datenprodukte können verschiedene benutzerdefinierte Messwerte haben, um ihren Nutzen zu messen. Datenerstellerteams können diese benutzerdefinierten Messwerte in den jeweiligen domainspezifischen Google Cloud-Projekten veröffentlichen. Um eine einheitliche Monitoringumgebung für alle Datenprodukte zu schaffen, kann einem zentralen Data Mesh-Monitoring-Projekt Zugriff auf diese domainspezifischen Projekte gewährt werden.

Jede Art von Schnittstelle für den Datenproduktverbrauch hat unterschiedliche Messwerte, um ihren Nutzen zu messen. Messwerte können auch spezifisch für die Unternehmensdomain sein. Beispielsweise können die Messwerte für BigQuery-Tabellen, die über Ansichten oder über die Storage Read API verfügbar gemacht werden, so aussehen:

  • Der Anzahl der Zeilen.
  • Datenaktualität (ausgedrückt als Anzahl von Sekunden vor der Messzeit).
  • Der Datenqualitätsfaktor.
  • Die verfügbaren Daten. Dieser Messwert kann angeben, dass die Daten für Abfragen verfügbar sind. Alternativ können Sie die bereits in diesem Dokument erwähnten Verfügbarkeitsdiagnosen verwenden.

Diese Messwerte können als Service Level Indicators (SLI) für ein bestimmtes Produkt angezeigt werden.

Bei Datenströmen, die als Pub/Sub-Themen implementiert sind, kann diese Liste die Pub/Sub-Standardmesswerte angeben, die für die Themen verfügbar sind.

Operativer Support durch das zentrale Datenplattform-Team

Das zentrale Datenplattformteam kann benutzerdefinierte Dashboards bereitstellen, um den Datennutzern unterschiedliche Detailebenen anzuzeigen. Ein einfaches Status-Dashboard, in dem die Produkte im Data Mesh und der Verfügbarkeitsstatus für diese Produkte aufgeführt sind, kann dabei helfen, mehrere Endnutzeranfragen zu beantworten.

Das zentrale Team kann auch als Benachrichtigungsverteilungs-Hub dienen, um Datennutzer über verschiedene Ereignisse in den von ihnen verwendeten Datenprodukten zu benachrichtigen. Dieser Hub wird in der Regel durch das Erstellen von Benachrichtigungsrichtlinien generiert. Durch die Zentralisierung dieser Funktion kann die Arbeit reduziert werden, die von jedem Datenerstellerteam erledigt werden muss. Für das Erstellen dieser Richtlinien sind keine Kenntnisse der Datendomains erforderlich. Außerdem sollten sie Engpässe im Datenverbrauch vermeiden.

Ein idealer Endzustand für das Data Mesh-Monitoring ist die Vorlage für das Datenprodukt-Tag, mit der die SLIs und Service Level Objectives (SLOs) verfügbar gemacht werden, die das Produkt unterstützt, sobald des verfügbar ist. Das zentrale Team kann dann die entsprechenden Benachrichtigungen mithilfe des Dienst-Monitoring mit der Monitoring API automatisch bereitstellen.

Produktübersichten

Als Teil der zentralen Governance-Vereinbarung können die vier Funktionen in einem Data Mesh die Kriterien für das Erstellen von Übersichten für Datenprodukte definieren. Diese Übersichten können zu einer objektiven Messung der Datenproduktleistung werden.

Viele der Variablen zur Berechnung der Übersichten sind der Prozentsatz der Zeit, in der Datenprodukte ihr SLO erfüllen. Nützliche Kriterien sind der Prozentsatz der Betriebszeit, die durchschnittlichen Datenqualitätswerte und der Prozentsatz der Produkte mit einer Datenaktualität, die nicht unter einen Grenzwert fällt. Damit diese Messwerte automatisch mit Monitoring Query Language (MQL) berechnet werden können, sollten die benutzerdefinierten Messwerte und die Ergebnisse der Verfügbarkeitsdiagnosen aus dem zentralen Monitoringprojekt ausreichen.

Nächste Schritte