Dateneinblick

Dateneinblick ist die Fähigkeit, die Integrität Ihrer Daten und Datensysteme zu verstehen, indem Sie Ereignisse in Bereichen wie Daten-, Speicher-, Compute- und Verarbeitungspipelines sammeln und korrelieren.

Das Erstellen und Betreiben einer resilienten, skalierbaren und leistungsstarken Datenplattform erfordert bewährte DevOps-inspirierte Prozesse in Teams, die funktionsbezogene Domänen darstellen. Dateneinblick ermöglicht es Geschäftsinhabern, DevOps-Technikern, Datenarchitekten, technischen Fachkräften für Daten sowie Site Reliability Engineers (SREs), die Erkennung, Vorhersage und Prävention von Problemen zu automatisieren und Downtime zu vermeiden, die zu einer Unterbrechung von Produktionsanalysen und KI führen kann.

Zentrale Bereiche des Dateneinblicks

Die meisten Datenplattformen basieren auf den folgenden zentralen Bereichen des Dateneinblicks:

• Überwachung des Datenplattformdiensts
• Überwachung der Datenpipelineleistung
• Überwachung der Datenqualität
• Datenherkunft
• Datenermittlung

End-to-End-Dateneinblick beinhaltet nicht nur das Erfassen von Ereignissen und das Messen von Metriken in allen diesen Komponenten, sondern auch das Korrelieren dieser Ereignisse und Metriken. Dadurch erhalten Sie einen umfassenden Überblick über die Integrität und Zuverlässigkeit Ihrer Unternehmensdatenumgebung.

In diesem Artikel werden die einzelnen Komponenten sowie ihr jeweiliger Beitrag zur Erreichung von Dateneinblick beschrieben.

Überwachung des Datenplattformdiensts

Die grundlegende Infrastruktur für eine Unternehmensdatenplattform kann eine Mischung aus anbieterseitig verwalteter und selbst verwalteter Infrastruktur sein, um Speicherung und Computing zu ermöglichen. DevOps-Techniker oder Infrastrukturtechniker müssen diese grundlegende Infrastruktur überwachen, damit sie Systemausfälle und Leistungsengpässe identifizieren und beheben können, die sich auf moderne Daten- und Analysepipelines auswirken.

Die Überwachung von Daten aus Datenbanken und Netzwerkebenen kann Ihren Verarbeitungsdurchsatz verbessern und die Netzwerklatenz minimieren. Teams benötigen Tools, die sie zur Metrikerfassung, für Benachrichtigen, zur Nachverfolgung und zur Behandlung von Incidents verwenden können und die es ihnen ermöglichen, Incidents mit den Daten- und Analyseproblemen zu korrelieren.

Es empfiehlt sich für Ihre Teams, Observability-as-Code in Ihre Infrastructure-as-Code-Ebene zu integrieren, damit die Überwachungsinstrumentation sofort aktiviert ist, wenn eine Ressource erstellt wird. Die meisten Azure-Dienste bieten standardmäßig eine Instrumentierung für zentrale Ressourcenmetriken (etwa Diagnosedaten).

Überwachung der Datenpipelineleistung

Datenpipelines werden immer komplexer. Sie enthalten mehrere Phasen und Abhängigkeiten und generieren inzwischen riesige Mengen an Überwachungsdaten. Diese Daten umfassen Ereignisse, Metriken und Protokolle. Sie können Ihre Datenpipelineleistung optimieren, indem Sie Überwachungsdaten sammeln und analysieren.

Ihre Datenteams sollten den Zustand Ihrer Datenpipelines über mehrere verwandte Datenprodukte und Geschäftsbereiche hinweg nachverfolgen. Wenn Ihr Team frühzeitig über Ausfälle oder unerwartet lange Laufzeiten benachrichtigt wird, kann es Downtime minimieren und behandeln. Die Korrelation von Pipelineüberwachungsdaten und Plattformdienstüberwachung kann Empfehlungen zur Leistungsoptimierung liefern – beispielsweise die Erhöhung von CPU- und Arbeitsspeicherressourcen für Pipelines mit hoher Last.

Überwachung der Datenqualität

Die Datenqualität gibt an, wie genau, vollständig und zeitnah Ihre Daten sind und inwieweit sie die Anforderungen Ihrer Organisation erfüllen. Die Qualität Ihrer Datasets muss kontinuierlich überwacht werden, um die Zuverlässigkeit und Vertrauenswürdigkeit der Datenanwendungen zu gewährleisten, von denen sie genutzt werden. Mithilfe von DataOps wurden Datenzuverlässigkeit und Leistung durch die Automatisierung von Datenqualitätstests (Komponente, Funktion und Integration) kontinuierlich verbessert. Diese Verbesserungen ermöglichen eine schnellere und effizientere Fehlererkennung und Datenanalyse.

Damit DevOps- und SRE-Prinzipien auf die Datenqualität angewendet werden können, müssen Teams wiederholbare, iterative Prozesse und Frameworks zur Erfassung von Datenqualitätsproblemen erstellen, diese Probleme auf Dashboards nachverfolgen und Warnungen für ggf. vorhandene Abweichungen einrichten.

Ihre Datenqualitätsüberwachung kann die Zeit bis zur Erkennung (Time To Detect, TTD), die Zeit bis zur Wiederherstellung (Time To Recovery, TTR) und andere Datenqualitätsmetriken nachverfolgen. TTD bezieht sich auf die Zeit, die Ihr Datenteam benötigt, um ein beliebiges Datenqualitätsproblem zu erkennen – von Aktualitätsanomalien bis hin zu Schemaänderungen, die ganze Pipelines beeinträchtigen. TTR bezieht sich auf die Zeit, die Ihr Team benötigt, um einen Datenincident zu beheben, nachdem es darauf aufmerksam gemacht wurde. Die Verbesserung der Datenqualität ist nicht nur eine technische Aufgabe und erfordert erhebliche organisatorische und kulturelle Unterstützung.

Im Governanceabschnitt zur Datenqualität erfahren Sie, wie Sie Datenqualität in Ihrem Szenario implementieren können.

Datenherkunft

Die Datenherkunft wird allgemein als fortlaufender Datensatz verstanden, in dem Ursprung, Transformationen und Bewegungen Ihrer Daten in Ihrem gesamten Datenbestand nachverfolgt werden. Die Datenherkunft wird in retrospektiven Aufgaben verwendet. Hierzu zählen unter anderem Problembehandlung, Debugging und Nachverfolgung von Grundursachen für Pipelineprobleme. Datenherkunft wird auch für Datenqualitätsanalyse, Compliance und Was-wäre-wenn-Szenarien verwendet, die häufig als Auswirkungsanalyse bezeichnet werden.

Die visuelle Darstellung der Datenherkunft zeigt die Bewegung der Daten von der Quelle zum Ziel einschließlich Datentransformationen im Laufe der Zeit.

Im Governanceabschnitt zur Datenherkunft erfahren Sie, wie Sie Datenherkunft in Ihrem Szenario implementieren können.

Datenermittlung

Die Datenermittlung ist der erste Schritt einer Datenanalyse- oder Datengovernanceworkload für Consumer. Bei einer Data Lake-Plattform für Unternehmen ist es für Datenconsumer (beispielsweise für wissenschaftliche Fachkräfte für Daten und Datenanalysten) schwer, die benötigten Daten zu finden und deren Zuverlässigkeit zu bewerten. Datenkataloge mit präzisen Metadaten erleichtern Suchvorgänge durch die Verwendung eines Datenindex mit folgenden Informationen:

• Speicherorte verfügbarer Daten
• Erkennung von Datenqualität
• Verständnis der Datenstruktur
• Verständnis der Datenherkunft
• Zugriff auf gewünschte Daten

Datenkataloge mit diesen Suchfunktionen erhöhen die Geschwindigkeit aller Datenermittlungsprozesse.

Im Governanceabschnitt zur Datenkatalogen erfahren Sie, wie Sie Datenermittlung in Ihrem Szenario implementieren können.

Festlegen von SLAs, SLIs und SLOs

Die Teams Ihrer Organisation können DevOps-artige SRE-Verfahren (Site Reliability Engineering) für die Datenüberwachung einführen. Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs), Servicelevelindikatoren (SLIs) und Servicelevel-Zielpunkte (Service Level Objectives, SLOs) können Ihrer Organisation dabei helfen, Downtime zu reduzieren und die Zuverlässigkeit Ihrer Daten sicherzustellen.

Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs)

SLAs erfordern gut definierte SLIs (quantitative Measures der Dienstqualität) und vereinbarte SLOs (die idealen Werte oder Bereiche, die jeder SLI erreichen soll).

Das Festlegen einer Daten-SLA erfordert die aktive Mitwirkung und Zusammenarbeit aller Beteiligten, die von einer SLA betroffen sind. Bei diesen Beteiligten kann es sich unter anderem um Datenproducer, Datentechniker, Datenanalysten, Datenconsumer oder Business Analysts handeln.

Das Festlegen von Zuverlässigkeits-SLAs umfasst in der Regel drei Schritte: Definieren, Messen und Nachverfolgen.

Definieren Sie beim Festlegen Ihrer SLA zunächst, was Zuverlässigkeit bedeutet. Alle relevanten Beteiligten müssen sich auf diese Definition einigen. Stellen Sie sicher, dass alle relevanten Stakeholder eingebunden werden und einverstanden sind. Das gilt insbesondere, wenn Ihre nachgelagerten Consumer aus unterschiedlichen Teams oder unterschiedlichen geografischen Regionen und Zeitzonen stammen.

Ihre SLA muss sorgfältig ausgearbeitet werden. Binden Sie Ihre Rechtsabteilung ein, wenn es sich bei Datenconsumern um externe zahlende Kunden handelt. Für interne Kunden muss Ihre SLA-Definition wichtige Bereiche wie Datenzusage, Datenqualität und einen Prozess zur Behandlung von Datenincidents enthalten, wenn die Zusage nicht erfüllt ist.

SLA-Beispiel

Angenommen, Contoso ist ein Medienunternehmen, das einen für Unternehmen konzipierten Data Lake betreibt, und dieser Data Lake unterstützt mehrere Datenprodukte aus verschiedenen Geschäftsbereichen. Das Datenanwendungsteam von Contoso ist für die Bereitstellung der Vertriebsdaten vom Vortag verantwortlich, die dem Vertriebsdashboard von Contoso zugrunde liegen. Im Falle einer ausbleibenden oder unvollständigen Datenübermittlung erhält das Datentechnikteam E-Mails von frustrierten Führungskräften und muss sich manuell um die fehlerhafte Pipeline kümmern, über die die Vertriebsdaten hätten übermittelt werden sollen. Um ihre Ergebnisse zu messen und zu verbessern, erstellt das Datenteam eine SLA mit dem Vertriebsteam, wie im folgenden Abschnitt zu sehen.

Vereinbarung zum Servicelevel zwischen Datenteam und Vertriebsteam

„Agreement“ (Vertrag)	BESCHREIBUNG
Geschäftsbereich	Das Datenteam sagt zu, das Vertriebsteams beim Treffen datengestützter Entscheidungen zu unterstützen.
Promise	Das Datenteam sagt zu, Vertriebsdaten vom Vortag bereitzustellen, die für das Vertriebsdashboard benötigt werden. Diese Daten können Informationen zu Umsätzen und Konversionsraten für alle US-Regionen umfassen. Die Daten für das Vertriebsdashboard werden vor 6:00 Uhr (UTC) über Datenpipelines übermittelt.
Datenqualität	NULL-Überprüfung: Der Kundename darf nicht NULL sein. Fehlender Wert: Die Kundenregion darf nicht fehlen. Aktualität: Das Verkaufsdatum muss alle Transaktionen umfassen, die vor 24:00 Uhr (UTC) getätigt wurden.
Verwaltung von Datenincidents	Wenn die obige Zusage der Datenübermittlung nicht erfüllt wird, kann das Vertriebsteam das Problem melden, und das Datenteam sagt zu, das Problem mit einer TTR von < 6 Stunden zu beheben.

Servicelevelindikatoren (SLIs)

SLIs müssen die in Ihrer SLA beschriebenen SLOs immer erfüllen oder übertreffen. Identifizieren Sie beim Festlegen eines SLI zunächst wichtige Metriken, die Sie nachverfolgen und messen können, um Ihre vereinbarte SLA zu erreichen.

SLI-Beispiel

Angenommen, das Datenteam von Contoso identifiziert wichtige Metriken aus verschiedenen Bereichen, um die im vorherigen Beispiel beschriebene SLA zu erfüllen. Außerdem erstellt es ein Dashboard, richtet Warnungen für den Fall ein, dass wichtige Metriken von einer festgelegten Baseline abweichen, und automatisiert Aktionen, um einige Probleme zu behandeln.

Metrik	Zweck
CPU- und Arbeitsspeicherauslastung des Spark-Clusters	Messen aller Leistungsengpässe in der zugrunde liegenden Infrastruktur für die Ausführung von Datenpipelines
Gesamtlaufzeit der Pipeline in Minuten	Messen, ob eine Pipeline mehr Zeit beansprucht als erwartet
Fehler- und Erfolgsrate von Pipelines	Messen, bei wie vielen Pipelines Fehler auftreten bzw. wie viele Pipelines erfolgreich sind
Datenqualitätsmetriken (Downstream)	Sicherstellen, dass die von der Datenpipeline bereitgestellten Daten die Erwartungen erfüllen
Datenqualitätsmetriken (Upstream)	Sicherstellen, dass die Upstreamqualitätsanforderungen für Rohdaten erfüllt sind
Aktualisierungen von Transformationsmetadaten	Sicherstellen, dass die Datenherkunft von Upstream bis Downstream Metadaten zu allen Transformationen enthält, die auf die Daten angewendet wurden
Indizierung und Aktualisierungen von Downstreamdaten	Sicherstellen, dass das Vertriebsteam alle Datasets findet, die für das zugehörige Dashboard erforderlich sind
Definierter Prozess zum Messen von TTD und TTR	Messen von TTD und TTR und Sicherstellen, dass die TTR < 6 Stunden ist

Servicelevel-Zielpunkte (Service Level Objectives, SLOs)

Ein SLO besteht aus einem SLI, der Messdauer für den SLI und der angestrebten Erfolgsrate, die in der Praxis erreichbar ist. Das Definieren der Richtung und des angestrebten Erfolgs mag zunächst wie eine Mammutaufgabe wirken. Erwarten Sie keine Perfektion, sondern vielmehr eine stetige Verbesserung über mehrere Iterationen hinweg.

SLOs können von Folgendem abhängig sein:

• Datenprodukt
• Die Datenkategorie
• Datenquellregionen
• Dateneinblickkomponenten

SLO-Beispiel

Angenommen, das Datenteam von Contoso liefert Vertriebsdaten für sieben verschiedene US-Regionen. 210 Datasets werden jedes Kalenderjahr in allen Regionen bereitgestellt, und nur 200 Datasets sind vollständig und erfüllen die SLA. Angesichts dieser erfolgreichen Bereitstellungen ergibt sich eine Erfolgsrate von 95,99 Prozent für dieses Jahr. Die zehn nicht erfolgreichen (unvollständigen) Datasets sind mit einer akzeptablen Fehlerrate von vier Prozent aufgetreten.

Das Datenteam erstellt ein Überwachungsdashboard, das aggregierte SLIs nachverfolgt, um dieses SLO über einen Zeitraum von 30 Tagen zu überwachen. Sowohl das Datenteam als auch das Vertriebsteam erhalten eine Benachrichtigung, wenn die angestrebte Erfolgsrate nicht erreicht wird.

Reifegradmodell für Dateneinblick

Dateneinblick ist ein wesentlicher Bestandteil des DataOps-Frameworks und sollte parallel zu Ihren Bemühungen zur Verbesserung der DataOps-Prozesse Ihrer Organisation berücksichtigt werden. Das folgende Reifegradmodell kann Ihnen dabei helfen, den aktuellen Status Ihres Dateneinblicks zu bewerten und Entscheidungen hinsichtlich der nächsten Schritte zu treffen:

Phase	Überwachung des Datenplattformdiensts	Überwachung der Datenpipelineleistung	Überwachung der Datenqualität	Datenherkunft	Datenermittlung
Phase 5 (hoch entwickelt)	Daten werden in allen Dateneinblickkomponenten mindestens eines Datenprodukts in einer einheitlichen Ansicht gesammelt und mithilfe von maschinellem Lernen korreliert, um Anomalien zu finden. SLO, SLI und SLA werden auf Dashboards für alle Dateneinblickkomponenten nachverfolgt.	Leistungsmetriken für Datenpipelines werden für mehrere Datenprodukte nachverfolgt. Die Ursachenanalyse wird vom System durchgeführt und gesteuert.	Das Vertrauen in die Datenqualität ist hoch. Datenconsumer können die Zuverlässigkeit von Daten überprüfen.	Die Datenherkunft wird visuell dargestellt und auf verschiedene Arten verwendet – etwa zur Nachverfolgung der Grundursache von Pipelineausfällen, für die Datenqualitätsanalyse und zu Compliancezwecken.	Datenconsumer können mühelos verfügbare Daten finden, die sie benötigen.
Phase 4 (fortgeschritten)	SLO, SLI und SLA werden auf Dashboards für die wichtigsten Dateneinblickkomponenten nachverfolgt. Plattformüberwachungsdaten und Leistungsüberwachungsdaten für Pipelines werden mithilfe von Automatisierung korreliert.	Tools für Datenincidents überwachen und messen TTD- und TTR-Metriken für alle Incidents.	Die Datenqualität wird über ein Framework verwaltet, das für mehrere Datenprodukte verwendet werden kann, und mithilfe von Dashboards nachverfolgt.	Die Datenherkunft umfasst Datenqualitätstags und ist mit der Auffindbarkeit von Daten verknüpft.	Die Datenherkunft ist nun mit der Auffindbarkeit von Daten verknüpft und umfasst auch Datenqualitätstags.
Phase 3 (Weiterentwicklung)	Gut definierte SLOs, SLIs und SLAs decken fast alle Komponenten für Dateneinblick ab. Datenincidents werden mithilfe spezialisierter Tools verwaltet.	Plattformüberwachungsdaten werden mit der Überwachung der Datenpipelineleistung korreliert. Dabei wird ein gewisses Maß an Automatisierung verwendet.	Datenqualitätsprüfungen sind gut definiert und benutzerdefinierten Metriken zugeordnet.	Die Datenherkunft ist so weit ausgereift, dass sie genügend Metadaten für die Entscheidungsfindung enthält.	Die Auffindbarkeit von Daten wird über spezialisierte Datenkatalogtools erreicht.
Phase 2 (Planung)	Ein erster Entwurf von SLO, SLI und SLA deckt die wichtigsten Komponenten ab, die für Dateneinblick benötigt werden. Plattformüberwachungsdaten sind zentralisiert, und es gibt eine einheitliche Ansicht der gesamten Datenumgebung. Datenincidents werden vollständig manuell behandelt.	Leistungsmetriken für Datenpipelines sind definiert und werden gemessen.	Datenqualitätsprüfungen sind vorhanden, es ist aber keine Standardmetrik definiert (sodass auch keine Standardmetrik gemessen und visualisiert wird.)	Die Datenherkunft ist auf ein einzelnes Datenprodukt beschränkt oder wird nicht nachverfolgt.	Die Auffindbarkeit von Daten wird erreicht, es werden aber keine hoch entwickelten Tools verwendet.
Phase 1 (Lernen)	Jeder kritische Plattformdienst (anbieterseitig verwaltet oder selbst verwaltet) wird in der Datenlandschaft überwacht.	Die Pipelineüberwachung ist minimal. Bei Fehlern werden Warnungen ausgelöst, es gibt jedoch keine Erkenntnisse zu möglichen Ursachen.	Datenqualitätstests können über die Pipeline ausgeführt werden, es wird jedoch keine Metrik gemessen oder nachverfolgt.	Es ist keine Datenherkunft vorhanden.	Es ist keine Auffindbarkeit von Daten vorhanden.