Freigeben über

Bewährte Methoden für Zuverlässigkeit

  • Artikel

Dieser Artikel behandelt bewährte Methoden für die Zuverlässigkeit. Sie sind nach Architekturprinzipien organisiert, die in den folgenden Abschnitten aufgeführt sind.

1. Entwurf mit Blick auf Fehler

Verwenden eines Datenformats, das ACID-Transaktionen unterstützt

ACID-Transaktionen sind ein wichtiges Feature für die Aufrechterhaltung der Datenintegrität und Konsistenz. Das Auswählen eines Datenformats, das ACID-Transaktionen unterstützt, hilft beim Erstellen von Pipelines, die einfacher und viel zuverlässiger sind.

Delta Lake ist ein Open-Source-Speicherframework, das ACID-Transaktionen sowie Schemaerzwingung, skalierbare Metadatenverarbeitung sowie Streaming- und Batchdatenverarbeitung bereitstellt. Delta Lake ist vollständig kompatibel mit Apache Spark-APIs und ist für eine enge Integration mit Structured Streaming entwickelt. So können Sie problemlos eine einzige Kopie der Daten sowohl für Batch- als auch für Streamingvorgänge verwenden und eine inkrementelle Verarbeitung im großen Stil ermöglichen.

Verwenden eines robusten verteilten Datenmoduls für alle Workloads

Apache Spark als Compute-Engine von Azure Databricks Lakehouse basiert auf einer resilienten verteilten Datenverarbeitung. Wenn eine interne Spark-Aufgabe kein Ergebnis wie erwartet zurückgibt, plant Apache Spark automatisch die fehlenden Aufgaben und führt den gesamten Auftrag weiter aus. Dies ist hilfreich für Out-of-Code-Fehler, z. B. ein kurzes Netzwerkproblem oder eine widerrufene Spot-VM. Die Arbeit mit der SQL-API und der Spark DataFrame-API umfasst diese in die Engine integrierte Resilienz.

Im Databricks Lakehouse ist Photon, eine native vektorisierte Engine, die vollständig in C++ geschrieben wurde, hochleistungsfähig und kompatibel mit Apache Spark-APIs.

Automatisches Retten ungültiger oder nicht konformer Daten

Ungültige oder nicht konforme Daten können zu Abstürzen von Workloads führen, die auf einem etablierten Datenformat basieren. Um die End-to-End-Resilienz des gesamten Prozesses zu erhöhen, empfiehlt es sich, ungültige und nicht konforme Daten bei der Erfassung herauszufiltern. Die Unterstützung für gerettete Daten stellt sicher, dass Sie während der Erfassung oder ETL niemals Daten verlieren oder verpassen. Die Spalte für gerettete Daten enthält alle Daten, die nicht analysiert wurden, entweder weil sie im gegebenen Schema fehlten, weil es eine Typübereinstimmung gab, oder weil die Groß- und Kleinschreibung der Spalte im Datensatz oder in der Datei nicht mit der im Schema übereinstimmte.

  • Databricks Auto Loader: Auto Loader ist das ideale Tool zum Streamen der Erfassung von Dateien. Es unterstützt gerettete Daten für JSON und CSV. Für JSON beispielsweise enthält die Spalte für wiederhergestellte Daten alle Daten, die nicht analysiert wurden, da sie möglicherweise im angegebenen Schema fehlten, ein Typkonflikt vorlag oder die Klein-/Großschreibung der Spalte nicht übereinstimmte. Die Spalte für wiederhergestellte Daten ist Teil des Schemas, das vom Autoloader standardmäßig als „_rescued_data“ zurückgegeben wird, wenn das Schema abgeleitet wird.
  • Delta Live Tables: Eine weitere Möglichkeit zum Erstellen von Workflows für Resilienz ist die Verwendung von Delta Live Tables mit Qualitätseinschränkungen. Siehe Verwalten der Datenqualität mit Delta Live Tables. Standardmäßig unterstützt Delta Live Tables drei Modi: Beibehalten, Löschen und Fehler bei ungültigen Datensätzen. Um identifizierte ungültige Datensätze unter Quarantäne zu stellen, können Erwartungsregeln auf eine bestimmte Weise definiert werden, sodass ungültige Datensätze in einer anderen Tabelle gespeichert („unter Quarantäne gestellt“) werden. Siehe Ungültige Daten unter Quarantäne stellen.

Konfigurieren von Aufträgen für automatische Wiederholungen und Beendigung

Verteilte Systeme sind komplex, und ein Ausfall an einem Punkt kann durch das gesamte System kaskadieren.

  • Azure Databricks-Jobs unterstützen Wiederholungsrichtlinien für Aufgaben, die bestimmen, wann und wie oft fehlerhafte Ausführungen wiederholt werden. Siehe Festlegen einer Wiederholungsrichtlinie.
  • Sie können optionale Schwellenwerte für die Dauer einer Aufgabe konfigurieren, einschließlich einer erwarteten Abschlusszeit für die Aufgabe und einer maximalen Abschlusszeit für die Aufgabe.
  • Delta Live Tables automatisiert auch die Wiederherstellung nach Fehlern mithilfe eskalierender Wiederholungen, um Geschwindigkeit und Zuverlässigkeit in Einklang zu bringen. Siehe Entwicklungs- und Produktionsmodi.

Andererseits kann eine hängende Aufgabe verhindern, dass der gesamte Auftrag abgeschlossen wird, was zu hohen Kosten führt. Databricks-Aufträge unterstützen eine Timeoutkonfiguration zum Beenden von Aufträgen, die länger als erwartet dauern.

Verwendung einer skalierbaren und produktionsgerechten Modellbereitstellungsinfrastruktur

Verwenden Sie für Batch- und Streamingrückschlüsse Azure Databricks-Aufträge und MLflow, um Modelle als Apache Spark-UDFs bereitzustellen, um Auftragsplanung, Wiederholungen, automatische Skalierung usw. zu nutzen. Siehe Bereitstellen von Modellen für Batch-Ableitung und -Vorhersage.

Die Modellbereitstellung bietet eine skalierbare und produktionstaugliche Infrastruktur für die Modellbereitstellung in Echtzeit. Sie verarbeitet Ihre Machine Learning-Modelle mithilfe von MLflow und stellt sie als REST-API-Endpunkte bereit. Diese Funktionalität verwendet serverloses Computing, was bedeutet, dass die Endpunkte und die zugehörigen Computeressourcen im Azure Databricks-Cloudkonto verwaltet und ausgeführt werden.

Verwenden von verwalteten Diensten nach Möglichkeit

Nutzen Sie verwaltete Dienste (serverlose Berechnung) aus der Databricks Data Intelligence Platform, z. B.:

Diese Dienste werden von Databricks auf zuverlässige und skalierbare Weise ohne zusätzliche Kosten für den Kunden betrieben, wodurch Workloads zuverlässiger werden.

2. Verwalten der Datenqualität

Verwenden einer Speicherarchitektur mit Ebenen

Kuratieren Sie Daten, indem Sie eine Architektur mit Ebenen erstellen und sicherstellen, dass die Datenqualität steigt, wenn Daten durch die Ebenen verschoben werden. Ein gängiger Ansatz für Ebenen ist:

  • Rohdatenebene (Bronze): Quelldaten werden im Lakehouse auf der ersten Ebene erfasst und sollten dort beibehalten werden. Wenn alle Downstreamdaten auf der Rohdatenebene erstellt werden, ist bei Bedarf eine Neuerstellung der nachfolgenden Ebenen aus dieser Ebene möglich.
  • Ebene für kuratierte Daten (Silber): Der Zweck der zweiten Ebene besteht darin, bereinigte, verfeinerte, gefilterte und aggregierte Daten zu enthalten. Ziel dieser Ebene ist es, eine solide und zuverlässige Grundlage für Analysen und Berichte über alle Rollen und Funktionen hinweg bereitzustellen.
  • Letzte Ebene (Gold): Die dritte Ebene wird für Geschäfts- oder Projektanforderungen erstellt. Sie bietet eine andere Ansicht als Datenprodukte für andere Geschäftseinheiten oder Projekte, bereitet Daten für Sicherheitsanforderungen (z. B. anonymisierte Daten) vor oder optimiert die Leistung (z. B. mit voraggregierten Ansichten). Die Datenprodukte auf dieser Ebene gelten als korrekte Version für das Unternehmen.

Die letzte Ebene sollte nur qualitativ hochwertige Daten enthalten und aus geschäftlicher Sicht vollständig vertrauenswürdig sein.

Verbessern der Datenintegrität durch Reduzieren der Datenredundanz

Das Kopieren oder Duplizieren von Daten führt zu Datenredundanz und damit zu Integritätsverlust, Verlust der Datenreihenfolge und häufig zu unterschiedlichen Zugriffsberechtigungen. Dies reduziert die Qualität der Daten im Seehaus.

Eine temporäre oder einwegbare Kopie von Daten ist selbst nicht schädlich - es ist manchmal notwendig, Flexibilität, Experimentierung und Innovation zu erhöhen. Wenn diese Kopien jedoch betriebsbereit werden und regelmäßig verwendet werden, um Geschäftsentscheidungen zu treffen, werden sie zu Datensilos. Wenn diese Datensilos nicht mehr synchronisiert werden, haben erhebliche negative Auswirkungen auf die Datenintegrität und -qualität und wirft Fragen auf, z. B. „Welches Dataset ist das Masterdataset?“ oder "Ist der Datensatz aktuell?

Aktives Verwalten von Schemas

Unkontrollierte Schemaänderungen können zu ungültigen Daten und fehlerhaften Aufträgen führen, die diese Datasets verwenden. Azure Databricks verfügt über mehrere Methoden zum Überprüfen und Erzwingen des Schemas:

  • Delta Lake unterstützt Schemavalidierung und Schemaerzwingung, indem Schemavariationen automatisch behandelt werden, um das Einfügen fehlerhafter Datensätze während der Erfassung zu verhindern. Weitere Informationen finden Sie unter Schemaerzwingung.
  • Auto Loader erkennt das Hinzufügen neuer Spalten, während Ihre Daten verarbeitet werden. Wenn Sie eine neue Spalte hinzufügen, werden Ihre Streams standardmäßig mit UnknownFieldException angehalten. Auto Loader unterstützt mehrere Modi für Schemaentwicklung.

Verwenden von Einschränkungen und Datenerwartungen

Deltatabellen unterstützen standardmäßige SQL-Einschränkungsverwaltungsklauseln, die sicherstellen, dass die Qualität und Integrität der einer Tabelle hinzugefügten Daten automatisch überprüft wird. Wenn eine Einschränkung verletzt wird, löst Delta Lake einen InvariantViolationException-Fehler aus, um zu signalisieren, dass die neuen Daten nicht hinzugefügt werden können. Weitere Informationen finden Sie unter Einschränkungen bei Azure Databricks.

Um diese Behandlung weiter zu verbessern, unterstützt Delta Live Tables Erwartungen: Erwartungen definieren Datenqualitätseinschränkungen für den Inhalt eines Datasets. Eine Erwartung besteht aus einer Beschreibung, einer Invariante und einer Aktion, die zu ergreifen ist, wenn ein Datensatz die Invariante nicht erfüllt. Erwartungen für Abfragen verwenden Python-Decorators oder SQL-Einschränkungsklauseln. Siehe Verwalten der Datenqualität mit Delta Live Tables.

Verwenden eines datenzentrierten Ansatzes für maschinelles Lernen

Ein Leitprinzip, das im Kern der KI-Vision für die Databricks Data Intelligence Platform bleibt, ist ein datenorientierter Ansatz für maschinelles Lernen. Da generative KI immer weiter verbreitet wird, bleibt diese Perspektive genauso wichtig.

Die Kernkomponenten jedes ML-Projekts können einfach als Datenpipeline betrachtet werden: Feature Engineering, Schulung, Modellimplementierung, Rückschluss und Überwachungspipeline sind alle Datenpipelinen. Daher erfordert die Operationalisierung einer ML-Lösung das Zusammenführen von Daten aus Vorhersage-, Überwachungs- und Featuretabellen mit anderen relevanten Daten. Grundsätzlich besteht die einfachste Möglichkeit, dies zu erreichen, darin, KI-gestützte Lösungen auf derselben Plattform zu entwickeln, die zum Verwalten von Produktionsdaten verwendet wird. Siehe datenzentrierte MLOps und LLMOps

3. Entwurf für die automatische Skalierung

Aktivieren der automatischen Skalierung für ETL-Workloads

Mit der automatischen Skalierung können Cluster die Größe basierend auf Workloads automatisch ändern. Automatische Skalierung kann in vielen Anwendungsfällen und Szenarien sowohl aus Kosten- als auch aus Leistungssicht von Vorteil sein. In der ‚Dokumentation finden Sie einige Überlegungen zur Entscheidung, ob die automatische Skalierung verwendet werden soll und wie Sie den größten Vorteil nutzen können.

Für Streamingworkloads empfiehlt Databricks die Verwendung von Delta Live Tables mit automatischer Skalierung. Databricks Enhanced Autoscaling optimiert die Clusterauslastung durch automatisches Zuordnen von Clusterressourcen basierend auf Arbeitslastvolumen, wobei minimale Auswirkungen auf die Datenverarbeitungslatenz Ihrer Pipelines auftreten.

Aktivieren der automatischen Skalierung für SQL Warehouse

Der Skalierungsparameter eines SQL-Warehouses legt die minimale und die maximale Anzahl von Clustern fest, über die an das Warehouse gesendete Abfragen verteilt werden. Der Standardwert ist ein Cluster ohne automatische Skalierung.

Erhöhen Sie die Anzahl der Cluster, um eine größere Anzahl gleichzeitiger Benutzer für ein bestimmtes Warehouse zu verarbeiten. Informationen dazu, wie Azure Databricks einem Warehouse Cluster hinzufügt und daraus entfernt, finden Sie unter Dimensionierung, automatische Skalierung und Warteschlangenverhalten von SQL-Warehouse.

4. Testen von Wiederherstellungsverfahren

Wiederherstellen von Abfragefehlern bei strukturiertem Streaming

Strukturiertes Streaming bietet Fehlertoleranz und Datenkonsistenz für Streamingabfragen. Mit Databricks-Aufträgen können Sie Ihre Abfragen zu strukturiertem Streaming ganz einfach so konfigurieren, dass sie bei einem Ausfall automatisch neu gestartet werden. Durch Aktivieren der Prüfpunkte für eine Streaming-Abfrage können Sie die Abfrage nach einem Fehler neu starten. Die neu gestartete Abfrage wird fortgesetzt, von wo aus die fehlgeschlagene Abfrage unterbrochen wurde. Siehe Strukturierte Streaming-Prüfpunkte und Produktionsüberlegungen für Strukturiertes Streaming.

Stellen Sie ETL-Jobs mithilfe von Daten-Zeitreisefunktionen wieder her

Trotz gründlicher Tests kann ein Auftrag in der Produktion fehlschlagen oder unerwartete, sogar ungültige Daten erzeugen. Manchmal kann dies mit einem zusätzlichen Auftrag behoben werden, nachdem Sie die Quelle des Problems verstanden und die Pipeline korrigiert haben, die überhaupt zu dem Problem geführt hat. Häufig ist dies jedoch nicht einfach, und für den jeweiligen Auftrag sollte ein Rollback ausgeführt werden. Mithilfe von Delta-Zeitreisen können Benutzer Änderungen auf eine ältere Version oder einen Zeitstempel zurücksetzen, die Pipeline reparieren und die korrigierte Pipeline neu starten.

Eine praktische Möglichkeit dazu ist der RESTORE-Befehl.

Nutzen eines Auftragsautomatisierungs-Frameworks mit integrierter Wiederherstellung

Databricks-Aufträge sind für die Wiederherstellung konzipiert. Wenn bei einer Aufgabe in einem Auftrag mit mehreren Aufgaben (und daher bei allen abhängigen Aufgaben) ein Fehler auftritt, bieten Azure Databricks-Aufträge eine Matrixansicht der Ausführungen, mit der Sie das Problem untersuchen können, das den Fehler verursacht hat (siehe Anzeigen der Ausführungen eines Auftrags). Unabhängig davon, ob es sich um ein kurzes Netzwerkproblem oder ein echtes Problem in den Daten handelt, können Sie es beheben und eine Reparaturausführung in Azure Databricks-Aufträgen starten. Dabei werden nur die fehlerhaften und abhängigen Aufgaben ausgeführt, und die erfolgreichen Ergebnisse der vorherigen Ausführung werden beibehalten, was Zeit und Geld spart, siehe Problembehandlung und Reparatur von Auftragsfehlern

Konfigurieren eines Notfallwiederherstellungsmusters

Ein klares Muster für die Notfallwiederherstellung ist für eine cloudnative Datenanalyseplattform wie Azure Databricks entscheidend. Es ist es wichtig, dass Ihre Datenteams die Azure Databricks-Plattform auch im seltenen Fall eines Ausfalls eines regionalen dienstweiten Clouddienstanbieters verwenden können, unabhängig davon, ob dies durch eine regionale Katastrophe wie einen Hurrikan oder ein Erdbeben oder eine andere Quelle verursacht wird.

Azure Databricks ist häufig ein zentraler Bestandteil eines gesamten Datenökosystems, das viele Dienste umfasst, einschließlich Upstream-Datenerfassungsdiensten (Batch/Streaming), nativem Cloudspeicher wie Azure Data Lake Storage Gen2, Downstreamtools und -diensten wie Business Intelligence-Apps und Orchestrierungstools. Einige Ihrer Anwendungsfälle sind möglicherweise besonders anfällig für einen regionalen dienstweiten Ausfall.

Die Notfallwiederherstellung umfasst eine Reihe von Richtlinien, Tools und Verfahren, die die Wiederherstellung oder Fortsetzung wichtiger Technologieinfrastrukturen und Systeme nach einem natürlichen oder von Menschen verursachten Notfall ermöglichen. Ein großer Clouddienst wie Azure bedient viele Kunden und verfügt über integrierte Wächter vor einem einzelnen Fehler. Beispielsweise ist eine Region eine Gruppe von Gebäuden, die mit verschiedenen Stromquellen verbunden sind, um zu gewährleisten, dass ein einzelner Stromausfall eine Region nicht herunterfährt. Cloudregionenfehler können jedoch auftreten, und der Schweregrad des Fehlers und deren Auswirkungen auf Ihr Unternehmen können variieren.

5. Automatisieren von Bereitstellungen und Workloads

Siehe Operational Excellence – Automatisieren von Bereitstellungen und Workloads.

6. Überwachen von Systemen und Workloads

Siehe Operational Excellence – Einrichten von Überwachung, Warnungen und Protokollierung.