Freigeben über

Bewährte Methoden für Zuverlässigkeit

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 Fehler außerhalb des Codes, wie ein kurzes Netzwerkproblem oder eine zurückgezogene Spot-VM. Die Resilienz ist in die Engine eingebaut, wenn sowohl mit der SQL-API als auch der Spark DataFrame-API gearbeitet wird.

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.

  • Pipelines: Eine weitere Option zum Erstellen von Workflows zur Resilienz ist die Verwendung von Lakeflow Declarative Pipelines mit Qualitätsbeschränkungen. Weitere Informationen finden Sie unter Verwalten der Datenqualität mit Pipelineerwartungen. Lakeflow Declarative Pipelines unterstützt standardmäßig drei Modi: Beibehalten, Ablegen und Fehlschlagen 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. Weitere Informationen finden Sie unter Ungültige Datensätze 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.

Andererseits kann eine hängende Aufgabe verhindern, dass der gesamte Auftrag abgeschlossen wird, was zu hohen Kosten führt. Lakeflow Jobs unterstützen die Timeout-Konfiguration, um Aufträge zu beenden, die länger als erwartet dauern.

Verwendung einer skalierbaren und produktionsgerechten Modellbereitstellungsinfrastruktur

Verwenden Sie Lakeflow-Jobs und MLflow für Batch- und Streaming-Inferenz, um Modelle als Apache Spark UDFs bereitzustellen und dabei Auftragsplanung, Wiederholungen, automatisches Skalieren 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 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:

  • Rohschicht (Bronze): Quelldaten werden in das Lakehouse in die erste Schicht eingespeist und sollten dort verbleiben. 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. Siehe Schemadurchsetzung.
  • 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 Sie 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 Handhabung weiter zu verbessern, unterstützt Lakeflow Declarative Pipelines Erwartungen: Erwartungen definieren Einschränkungen der Datenqualität 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. Weitere Informationen finden Sie unter Verwalten der Datenqualität mit Pipelineerwartungen.

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 Streaming-Workloads empfiehlt Databricks die Verwendung von Lakeflow Declarative Pipelines 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 Cluster zu einem Warehouse hinzufügt und 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. Mithilfe von Lakeflow-Aufträgen können Sie Ihre strukturierten Streaming-Abfragen ganz einfach so konfigurieren, dass beim Fehler automatisch neu gestartet wird. 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 der jeweilige Auftrag sollte zurückgesetzt 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 Sie ein Auftragsautomatisierungs-Framework mit integrierter Wiederherstellung

Lakeflow Jobs sind für die Wiederherstellung konzipiert. Wenn ein Vorgang in einem Multitaskauftrag fehlschlägt (und z. B. alle abhängigen Aufgaben), stellen Aufträge eine Matrixansicht der Ausführung bereit, mit der Sie das Problem untersuchen können, das den Fehler verursacht hat, siehe Ansichtsausführung für einen einzelnen Auftrag. Unabhängig davon, ob es sich um ein kurzes Netzwerkproblem oder um ein echtes Problem in den Daten handelt, können Sie es beheben und eine Reparatur in Lakeflow-Aufträgen starten. Es werden nur die fehlgeschlagenen und abhängigen Aufgaben ausgeführt, während die erfolgreichen Ergebnisse der früheren Ausführung beibehalten werden, 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 wichtig, dass Ihre Datenteams die Azure Databricks-Plattform auch im seltenen Fall eines regionalen, dienstweiten Ausfalls eines Clouddienstanbieters verwenden können, unabhängig davon, ob es sich um eine regionale Katastrophe wie einen Hurrikan, ein Erdbeben oder eine andere Quelle handelt.

Azure Databricks ist häufig ein Kernbestandteil eines Gesamtdatenökosystems, das viele Dienste umfasst, einschließlich upstream-Datenaufnahmedienste (Batch/Streaming), cloudeigener Speicher wie Azure Data Lake Storage, Downstream-Tools und -Dienste 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.