Häufig gestellte Fragen zu deklarativen Automatisierungspaketen

In diesem Artikel werden häufig gestellte Fragen zu deklarativen Automatisierungspaketen (früher als Databricks Asset Bundles bezeichnet) aufgeführt.

Warum wurden Databricks Asset Bundles in Declarative Automation Bundles umbenannt?

Der neue Name Declarative Automation Bundles spiegelt die Verwendung und Funktionen von Bundles genauer wider. Darüber hinaus führte der Begriff "Assets " zu Verwirrung, da er mehr als eine Bedeutung in Databricks hat. Diese Namensänderung ist nicht durchbrechend. Der bundle CLI-Befehl und alle Ihre vorhandene Konfiguration müssen nicht geändert werden.

Wie verwende ich declarative Automation Bundles als Teil meiner CI/CD-Pipeline auf Azure Databricks?

Sie können deklarative Automatisierungspakete verwenden, um Ressourcen in Ihrer Azure Databricks CI/CD-Implementierung zu definieren und programmgesteuert zu verwalten, die in der Regel Folgendes umfasst:

• Notizbücher: Azure Databricks-Notizbücher sind häufig ein wichtiger Bestandteil von Data Engineering- und Data Science-Workflows. Sie können die Versionssteuerung für Notizbücher verwenden und sie auch als Teil einer CI/CD-Pipeline überprüfen und testen. Sie können automatisierte Tests mit Notizbüchern ausführen, um zu überprüfen, ob sie wie erwartet funktionieren.
• Bibliotheken: Verwalten Sie die zum Ausführen des bereitgestellten Codes erforderlichen Bibliotheksabhängigkeiten . Verwenden Sie die Versionssteuerung für Bibliotheken, und fügen Sie sie in automatisierte Tests und Validierungen ein.
• Workflows: Lakeflow-Aufträge bestehen aus Aufträgen, mit denen Sie automatisierte Aufgaben mithilfe von Notizbüchern oder Spark-Aufträgen planen und ausführen können.
• Datenpipelinen: Sie können auch Datenpipelines in die CI/CD-Automatisierung einschließen, indem Sie Lakeflow Spark Declarative Pipelines verwenden, das Framework in Databricks zum Deklarieren von Datenpipelines.
• Infrastruktur: Die Infrastrukturkonfiguration enthält Definitionen und Bereitstellungsinformationen für Cluster, Arbeitsbereiche und Speicher für Zielumgebungen. Infrastrukturänderungen können als Teil einer CI/CD-Pipeline überprüft und getestet werden, um sicherzustellen, dass sie konsistent und fehlerfrei sind.

Warum muss ich separate Entwicklungs- und Produktionszielumgebungen haben?

Separate Entwicklungs- und Producton-Umgebungen ermöglichen Folgendes:

• Isolieren Sie Entwicklungsänderungen sicher, sodass sie sich nicht versehentlich auf die Produktion auswirken.
• Verhindern Sie die Codeduplizierung, indem Sie Ressourcen anpassen, die auf eine bestimmte Zielumgebung angewendet werden.
• Optimieren und vereinfachen Sie CI/CD mit umgebungsspezifischer Konfiguration, z. B. Datenbankpfade, Warnungen und Zugriffssteuerungen.
• Verwenden Sie Workflows in Teams und Umgebungen wieder.

Verwenden Sie Ziele zum Definieren von Bundlebereitstellungsumgebungen. Siehe Ziele.

Wie konsistenziere ich meine Bündel in meiner Organisation?

Verwenden Sie Bündelvorlagen für eine konsistente Struktur, um Setupfehler zu reduzieren und bewährte Methoden zu fördern. Sie können Standardbundlevorlagen verwenden oder eigene benutzerdefinierte Bündelvorlagen erstellen. Siehe Projektvorlagen für deklarative Automatisierungspakete.

Es gibt viele Wiederholungen in meinen Bündeln, wie z. B. die gleichen Clusterdefinitionen. Was ist die beste Möglichkeit, dies zu bewältigen?

Benutzerdefinierte Variablen sind die beste Möglichkeit zum Behandeln von Wiederholungen sowie Einstellungen, die kontextspezifisch sind. Siehe benutzerdefinierte Variablen.

Was sind einige bewährte Methoden bei der Verwendung von Bundles in meinem Bereitstellungsablauf?

Databricks empfiehlt Folgendes:

• Umstellung von manuellen Bereitstellungen zur zuverlässigen Automatisierung mithilfe von Git-integrierten Workflows.
• Validieren Sie ein Bundle mithilfe von databricks bundle validate, bevor Sie es in Ihrer CI/CD-Pipeline bereitstellen.
• Separate Bereitstellungsschritte, um sicherzustellen, dass Änderungen überprüft und beabsichtigt werden.
• Parameterisieren Sie Umgebungen (Dev, Staging, Prod) mit Überschreibungen, um Änderungen zu isolieren.
• Führen Sie Integrationstests nach der Bereitstellung aus, um Probleme frühzeitig abzufangen.
• Verwenden Sie GitHub-Aktionen, Azure DevOps oder GitLab CI, um Bereitstellungen bei Commit oder PR-Zusammenführung auszulösen.
• Verfolgen Sie, was bereitgestellt wird, wo und wann, damit jede Bereitstellung einer Commit- und Bundleversion zugeordnet ist.

Kann ich vorhandene Aufträge, Pipelines, Dashboards und andere Databricks-Objekte in mein Bundle portieren?

Ja. Verwenden Sie den databricks bundle generate Befehl, um eine Konfigurationsdatei für einen vorhandenen Auftrag, eine Pipeline oder ein Dashboard in Ihrem lokalen Bündel zu generieren, und verwenden Sie databricks bundle deployment bind dann die Bindung der Bundleressource an die entsprechende Ressource im Arbeitsbereich. Dies ist ideal für das Onboarding vorhandener Workflows in die strukturierte, versionsbezogene Entwicklung. Die Bindung löst auch relative Pfade zu absoluten Arbeitsbereichsverweisen auf, wodurch Pfadfehler vermieden werden.

Siehe Migrieren vorhandener Ressourcen zu einem Bündel.

Wie teste ich mein Bundle iterativ?

Sie können mit iterativen Bereitstellungen und Ausführungen schneller entwickeln:

• Überprüfen vor der Bereitstellung
• Inkrementelles Deployment
• Ausführen nur, was erforderlich ist
• Bearbeiten und Wiederholen

Dadurch werden Tests und Debugging beschleunigt, der Kontextwechsel reduziert, eine sicherere und schnellere Iteration ohne vollständige erneute Bereitstellungen ermöglicht und sorgt für Disziplin beim Übergang zur Produktion.