Bewährte Methoden für Entwickler in Databricks

Diese Seite bietet bewährte Methoden für Ihren Datenentwicklungs- und Entwicklungslebenszyklus, einschließlich Versionsverwaltung, Umgebungsverwaltung, Entwicklertools und verwalteten Bereitstellungen.

Quellcodeverwaltung

Versionssteuerung für alle Dateien

Die deklarative Automatisierung basiert auf der Idee, dass, wenn sich etwas nicht in der Versionssteuerung befindet, nicht vorhanden ist. Daher empfiehlt Databricks, fast jede Datei unter Versionskontrolle zu stellen, darunter:

• Alle Notizbücher und Quelldateien (.py, .sql)
• Konfigurationsdateien des Bundles (databricks.yml und umgebungsspezifische YAML-Überschreibungen)

Führen Sie jedoch keinen Commit durch:

• Erstellen Sie Artefakte, wie .jar- oder .whl-Dateien. Laden Sie stattdessen kompilierte Binärdateien während der CI in Unity-Katalogvolumes hoch. Siehe Upload JAR.
• Token oder Anmeldeinformationen. Verwenden Sie die Secret-Verwaltung auf Arbeitsbereichsebene, die auf einem Cloud Secret Manager (z. B. AWS Secrets Manager oder Azure Key Vault) basiert, und synchronisieren Sie die Werte in Databricks Secret-Scopes. Siehe Verwaltung von Geheimnissen.
• Lokale Datenbeispiele und Dateien mit PII. Verwenden Sie .gitignore, um sie auszuschließen.

Einzelnes Repository

Databricks empfiehlt, ein einzelnes Repository für alle Codedateien (Quellcode und Konfigurationsdateien) zu verwenden, da die Zusammenarbeit und die Gemeinsame Nutzung von Code und bewährten Methoden für Menschen und KI vereinfacht wird. Wenn Sie über mehrere Bündel für separate Bereitstellungszyklen verfügen, behalten Sie sie in einem einzigen Repository bei.

Die einzige Ausnahme von der empfehlung für einzelne Repositorys ist in regulierten Branchen, in denen mehrere Repositorys für Vertraulichkeitszwecke erforderlich sind.

Trunkbasierte Verzweigungsstrategie

Um Merge-Konflikte zu minimieren und sicherzustellen, dass der Main-Branch stets in einem bereitstellbaren Zustand ist, verwenden Sie eine Trunk-basierte Branching-Strategie.

Ein einfacher Workflow wäre:

1. Entwickeln Sie lokal oder im Arbeitsbereich, und stellen Sie sie für einen Databricks-Entwicklungsarbeitsbereich bereit, um Änderungen zu testen.
2. Erstellen Sie einen kurzlebigen Feature-Branch für Aktualisierungen in der Versionsverwaltung und synchronisieren Sie regelmäßig Ihre lokalen Änderungen oder Änderungen im Arbeitsbereich.
3. Wenn das Testen abgeschlossen ist, führen Sie die Feature-Verzweigung mit der Hauptzweigung zusammen.
4. CI/CD stellt automatisch den Hauptzweig in einem Staging-Arbeitsbereich bereit und automatisierte Tests werden ausgelöst.
5. Wenn die Staging-Tests und -Prüfungen erfolgreich abgeschlossen sind, stellt CI/CD den Hauptzweig in einem Produktionsarbeitsbereich bereit.

Diese Schritte werden im folgenden Diagramm beschrieben:

Arbeitsbereichskonfiguration

Isolieren von Arbeitsbereichsumgebungen

Isolieren Sie Arbeitsbereichsumgebungen, um die Auswirkungen einer fehlgeschlagenen Bereitstellung zu minimieren. Beispiel:

• Kleine Teams (bis zu 5 Dateningenieure): Beginnen Sie mit zwei Arbeitsbereichen (Entwicklung und Produktion) in einem einzigen Cloudkonto.
• Wachsende Teams (5+ Dateningenieure): Wechseln zu drei Arbeitsbereichen (Entwicklung, Staging und Produktion). Die Staging-Umgebung sollte die Produktionsumgebung funktional repräsentieren – mit derselben Build-Konfiguration, demselben Schema und denselben kritischen Integrationen – auch wenn sie kleiner dimensioniert ist.
• Regulierte Branchen (Banken, Gesundheitswesen, Verteidigung): Physisches Isolieren von Arbeitsbereichen und Cloudkonten, um Datenlecks zu verhindern. Die Isolation innerhalb eines einzelnen Kontos über die Grenzen von IAM und Unity Catalog zu verwalten, ist möglich, bietet jedoch eine weniger robuste Sicherheitslage.

Verwenden Sie für Produktionsarbeitsbereiche serverlose Berechnungen mit Netzwerkrichtlinien, sofern möglich. Konfigurieren Sie andernfalls Cloudkonten so, dass private Subnetze oder VNets mit streng kontrollierten Ausgangs- und Netzwerksicherheitskontrollen verwendet werden.

Weitere Informationen finden Sie unter kontextbasierte Netzwerkrichtlinien.

Isolieren der Datenspeicherung

• Verwenden Sie ein einzelnes Unity Catalog-Metastore und erstellen Sie separate Kataloge für Entwicklung, Staging (falls zutreffend) und Produktion, entsprechend Ihrem Workspace-Layout.
• Verwenden Sie persönliche Schemas für die Entwicklungs- und Stagingkataloge einzelner Entwickler (Nicht-Produktionskataloge).
• Binden Sie den Produktionskatalog nur im ISOLATED Modus an den Produktionsarbeitsbereich. Das Festlegen des Isolationsmodus eines Katalogs auf ISOLATED stellt sicher, dass Produktionsdaten aus Entwicklungs- oder Staging-Umgebungen unerreichbar sind, selbst wenn eine Identität falsch konfiguriert ist.
• Reservieren Sie separate Metastores, Konten oder Regionen nur für Organisationen mit behördlichen, Datenhoheits- oder Mehrregionenanforderungen, die die Isolation auf Katalogebene nicht erfüllen kann.

Behandeln von Tabellen- und Spaltenmetadaten als Code

Behandeln Sie Tabellen- und Spaltenkommentare als Teil Ihres Codes. Bewahren Sie sie zusammen mit Ihren deklarativen Automatisierungsbundledefinitionen in .sql Dateien auf, und stellen Sie sie über einen Metadatenauftrag bereit, damit präzise, geschäftsbezogene Definitionen immer verfügbar sind. Schreiben Sie Kommentare, die beschreiben, was eine Zeile darstellt, die Einheiten und gültigen Werte in einfacher Sprache, anstatt den Spaltennamen zu wiederholen.

Konfigurieren von persönlichen Schemas

Konfigurieren Sie während der Entwicklung Bündel für die Verwendung eines persönlichen Schemas pro Benutzer, z. B dev_${user_name}. . Dadurch wird verhindert, dass Entwickler in einem freigegebenen Arbeitsbereich gegenseitig ihre Tabellen überschreiben.

Serverlose Berechnung verwenden

Verwenden Sie serverloses Compute, um die Clusterverwaltung zu vereinfachen und Kosten zu optimieren. Siehe Verbindung mit serverlosem Computing herstellen.

CI/CD-Empfehlungen

Deklarative Automatisierungspakete für CI/CD

Deklarative Automatisierungspakete (früher als Databricks Asset Bundles bezeichnet) bieten einen leistungsstarken, einheitlichen Ansatz für die Verwaltung von Code, Workflows und Infrastruktur innerhalb des Databricks-Ökosystems und werden für Ihre CI/CD-Pipelines empfohlen.

Weitere Details zur Verwendung von Bundles für CI/CD-Workflows finden Sie unter CI/CD-Workflows auf Databricks.

Weitere Informationen zu deklarativen Automatisierungspaketen finden Sie unter What are Declarative Automation Bundles?.

Verwenden von Terraform nur für externe Ressourcen

Verwenden Sie Terraform, um die folgenden Ressourcen zu definieren:

• Cloudebene und externe Ressourcen
• Administratoraktionen, die nicht privilegierte Benutzer nicht ausführen sollten, z. B. Arbeitsbereichsbereitstellung oder Cloudnetzwerkkonfiguration

Verwenden Sie deklarative Automatisierungspakete für alle anderen Databricks-Ressourcen.

Bündelverwaltung

Kleine Pakete erstellen

Databricks empfiehlt, kleine, fokussierte Bündel über ein einzelnes großes Bundle zu entwickeln.

• Setzen Sie alles, was ein einzelnes Team besitzt, in ein Bündel.
• Über dieselbe CI/CD-Pipeline testen und bereitstellen, die denselben Lebenszyklus und dieselbe Release-Kadenz hat.
• Jedes Bundle sollte alle Umgebungen für ein bestimmtes Projekt (Dev, Staging, Production) abdecken, anstatt separate Bundles pro Umgebung zu verwenden.

Erstellen sie separate Bündel für:

• Verschiedene Produkte oder Domänen, z. B. "Abrechnungsanalyse" und "Betrugserkennung"
• Unterschiedliche Besitz- oder Berechtigungsgrenzen
• Workloads mit deutlich unterschiedlichen Lebenszyklen
• Fälle, in denen Sie eine unabhängige Heraufstufung oder ein Rollback benötigen

Verwenden von sync.paths zum Synchronisieren freigegebener Ordner

Wenn Sie mehrere Pakete in einem Repository verwalten, verwenden Sie sync.paths, um freigegebene Ordner außerhalb des Paketstammverzeichnisses zu synchronisieren. Auf diese Weise können verschiedene Projekte einen gemeinsamen Bibliotheksordner, wie z. B. ../common, gemeinsam nutzen und dabei separate Bereitstellungsidentitäten beibehalten.

Bundle-übergreifende Abhängigkeiten in CI/CD modellieren

Wenn Bundle B von den von Bundle A veröffentlichten Ressourcen abhängt, modellieren Sie diese Abhängigkeit in Ihrer CI/CD- oder Orchestrierungsebene, anstatt beide in ein Bundle zu reduzieren.

• Machen Sie den Bereitstellungs- und Veröffentlichungsworkflow von Bundle A zu einer expliziten Voraussetzung für Bundle B. Verdrahten Sie Ihre Pipeline, sodass Bundle B erst gestartet wird, nachdem die Bereitstellung von Bundle A erfolgreich war und alle erforderlichen Überprüfungen bestanden wurden.
• Geben Sie veröffentlichte Asset-Kennungen oder Speicherorte als Pipeline-Eingaben weiter und brechen Sie frühzeitig ab, wenn vorgelagerte Assets fehlen. Dadurch wird sichergestellt, dass Bundle B niemals gegen einen nur teilweise veröffentlichten Zustand bereitgestellt wird.

Weitere Informationen zur Freigabe von Bundles finden Sie unter Freigabe von Bundles und Bundle-Dateien.

Benutzerdefinierte Bündelvorlagen

Verwenden Sie benutzerdefinierte Vorlagen für deklarative Automatisierungs-Bundles als standardmäßigen Ausgangspunkt für neue Projekte, sodass jedes Projekt dieselben Leitplanken erbt – Berechtigungen, Tagging, Clusterrichtlinien, CI/CD-Anbindung und Instanz-Baselines –, ohne dass jedes Team alles von Grund auf neu lösen muss.

Vorlagen sollten gemeinsame, langlebige Konventionen wie Governance, Standardvorgaben für die Performance, die Umgebungsstruktur und Kontingentgrenzen abbilden. Vermeiden Sie appspezifische Geschäftslogik, geheime Schlüssel oder einmalige Konfiguration in Vorlagen.

Parametrisieren Sie nur Parameter, bei denen zu erwarten ist, dass sie je nach Team, Projekt oder Umgebung variieren:

• Project oder Anwendungsname
• Einstellungen des Zielarbeitsbereichs
• Katalog- oder Schemanamen
• Dienstprinzipalkennungen
• Zeitpläne und Benachrichtigungseinstellungen

Legen Sie die Leitplanken der Plattform und gemeinsame Standardwerte in der Vorlage fest, anstatt sie zu parametrisieren.

Informationen zu benutzerdefinierten Bündelvorlagen und deren Erstellung finden Sie unter Deklarative Automatisierungsbundle-Projektvorlagen.

Rollbacks und Hotfixes einplanen

Halten Sie Bündel klein genug, um ein gezieltes Rollback für ein einzelnes Bundle auszuführen, anstatt ein Rollback über viele nicht verknüpfte Workloads hinweg zu koordinieren.

Während eines Vorfalls:

1. Das betroffene Bundle auf die letzte bekanntermaßen funktionierende Version zurücksetzen oder zurückrollen.
2. Verwenden Sie einen Hotfix nur für dringende, schmale Korrekturen, die nicht auf den normalen Heraufwertungsfluss warten können.
3. Führen Sie jeden Hotfix unmittelbar nach der Validierung in den Hauptzweig zurück, damit der Trunk die einzige Quelle der Wahrheit bleibt.

Allgemeine Entwicklung

Verwenden Sie Dienstprinzipale oder OIDC

Verwenden Sie Dienstprinzipale für alle Nichtentwicklungsautomatisierungen, um automatisierte Workflows von einzelnen Benutzerkonten zu entkoppeln und sicherzustellen, dass Aufträge weiterhin ausgeführt werden, wenn interne Benutzer verlassen. Siehe Dienstprinzipale.

• Verwenden Sie separate Dienstprinzipale für die Bereitstellung und Laufzeit. Ein dedizierter Bereitstellungsdienstprinzipal für Bundlebereitstellungen sollte minimalen Datenzugriff haben. Jeder Produktionsjob oder jede Pipeline sollte einen eigenen Dienstprinzipal zur Ausführung verwenden, dessen Berechtigungen nur auf die Daten und Ressourcen beschränkt sind, die die jeweilige Workload benötigt. Diese Trennung stellt sicher, dass Bereitstellungen sicher bleiben, wenn Sie Datenzugriffsberechtigungen anpassen oder verschärfen, und vermeidet, Infrastrukturänderungen an den Zugriff auf Produktionsdaten zu koppeln.
• Regulierte Branchen: Verwenden Sie workload Identity Federation (OIDC) für CI/CD. Dies beseitigt langlebige Geheimnisse in GitHub Actions oder Azure DevOps. Siehe Aktivieren des Workload-Identitätsverbunds in CI/CD.

Verwenden von Databricks-Entwicklertools

Entwickeln Sie in der Benutzeroberfläche des Databricks-Arbeitsbereichs mithilfe von Git-Ordnern oder in einer lokalen IDE. Wenn Sie Visual Studio Code oder eine kompatible Abspaltung verwenden, installieren Sie die offizielle Databricks-Erweiterung für:

• Databricks-spezifische Agent-Fähigkeiten
• Unity-Katalog und Dateisystemzugriff
• Funktionen für die Remoteentwicklung zur Ausführung von Workloads auf Databricks Compute

Weitere Informationen finden Sie unter Databricks-Erweiterung für Visual Studio Code.

Geschäftslogik in Notebooks minimieren

Behandeln Sie Notizbücher nicht als primären Container für Geschäftslogik. Verwenden Sie sie nur zur Erkundung und Visualisierung.

• Python: Setzen Sie kernlogik in importierbare .py Module in src/ oder src/py/, und rufen Sie diese Funktionen aus Notizbüchern auf.
• SQL: Speichern Sie Abfragen in .sqlDateien in src/ oder src/sql/, und verweisen Sie in Jobs und Pipelines auf diese Dateien, anstatt SQL direkt in Notebooks einzubetten.

Verwenden Sie Notizbücher nur als dünne Orchestrierungs- und Visualisierungsebenen, die den zugrunde liegenden Code aufrufen. Dieser Ansatz erleichtert das Testen und Wiederverwenden.

Wenn Sie ein Notizbuch-schweres Projekt migrieren, führen Sie dies inkrementell aus. Extrahieren Sie jeweils ein wiederverwendbares Modul oder eine SQL-Datei, und verwenden Sie deklarative Automatisierungsbundle, um migrierte Ressourcen unter denselben Bereitstellungs- und Testworkflow wie das restliche Projekt zu bringen.

Dynamisches Übergeben des Kontexts

Vermeiden Sie statische Variablen für Vorgangsabhängigkeiten. Verwenden Sie dynamische Wertverweise wie {{tasks.<task_key>.values.<value_key>}}, um den Laufzeitkontext zwischen Aufgaben in einem mehrstufigen Auftrag zu übergeben.

Testen und Beobachtbarkeit

Implementieren von Testebenen

Verwenden Sie drei Testebenen, die der Art entsprechen, wie Sich Ihre Bündel in Richtung Produktion bewegen:

1. Komponententests: Behalten Sie geschäftslogik in importierbaren src/ Modulen bei und decken Sie sie mit pytest oder einem entsprechenden Framework ab. Führen Sie diese bei jedem Pull-Request aus, damit Fehlschläge das Zusammenführen blockieren.
2. Bundleüberprüfung: Lokal ausführen bundle validate . Bevorzugen Sie in CI bundle deploy einen Nicht-Produktions-Workspace zu verwenden, um YAML- und Ressourcenzuordnungsprobleme vor der Produktionsbereitstellung zu erkennen.
3. Integrationstests in Staging: Führen Sie nach der Bereitstellung im Staging End-to-End-Aufträge mit Abschlussprüfungen und kritischen Datenqualitäts-Assertionen wie Zeilenanzahl oder Schemaerwartungen aus.

Die Bedingung, dass Artefakte in die Produktion überführt werden, lautet: "Alle Tests im Hauptzweig und in der Staging-Umgebung sind erfolgreich."

Verwenden Sie für Lakeflow Spark Declarative Pipelines die integrierten Entwicklungs- und Validierungsfeatures anstelle von Ad-hoc-Notizbüchern. Testen Sie pipelinelogik anhand kleiner, repräsentativer Datasets, die Datensätze mit Fehlern enthalten, und verwenden Sie den Entwicklungsmodus, um Änderungen zu überprüfen, bevor Sie Produktionstabellen aktualisieren.

Behandeln Sie die Protokollierung als Teil der Bereitstellung

Behandeln Sie bei mit Declarative Automation Bundles bereitgestellten Workloads Metriken und Protokollierung als Teil der Bereitstellungsvereinbarung und nicht als etwas, das jedes Projekt unabhängig definiert.

• Geben Sie strukturierte Protokolle konsistent für Aufträge, Pipelines und Aufgaben aus. Schließen Sie den Paketnamen, die Zielumgebung, den Workloadnamen, den Ausführungsbezeichner und alle Geschäfts-IDs ein, die zum Nachverfolgen von Fehlern erforderlich sind.
• Verfolgen Sie für jede Produktions-Workload einen standardmäßigen Satz betrieblicher Metriken: Ausführungsstatus, Dauer, Anzahl der Wiederholungen sowie gegebenenfalls Durchsatz- oder Aktualitätsindikatoren.
• Codieren Sie diese Konventionen in freigegebenen Bibliotheken, wiederverwendbaren Workloaddefinitionen oder Bündelvorlagen, damit Teams keine Observability-Muster für jedes Projekt neu erstellen müssen.