Tutorial: So stellen Sie Änderungen an AI/BI-Dashboards mit Declarative Automation Bundles sicher und in großem Umfang bereit

Der Gedanke an eine Vorstandssitzung, die mit einem fehlerhaften Dashboard beginnt, sollte Analytics-Teams schlaflose Nächte bereiten. Ebenso die nachträgliche Erkenntnis, dass ein Einstellungsplan, eine Produkteinführung oder eine Umsatzprognose auf einer falschen Kennzahl basierte. Oder dass ein Support-Team viel zu viele Rückerstattungen ausgestellt hat, weil ein Dashboard die Kaufhistorie eines Kunden falsch dargestellt hat.

Diese Fehler sind selten auf eine schlechte Analyse zurückzuführen. Wie bei jedem Produktionssystem resultieren sie oft daraus, dass Dashboards manuell aktualisiert werden, wenn sich Datenmodelle und Anforderungen weiterentwickeln – ohne Versionierung, ohne einen zuverlässigen Review-Prozess oder ohne eine wiederholbare Methode zur Übertragung von Änderungen zwischen Umgebungen.

Dieser Blogbeitrag bringt es auf den Punkt: produktionsreife Dashboards, die das Geschäft steuern, müssen mit derselben Disziplin verwaltet werden wie Produktionscode. Da Databricks AI/BI auf derselben Data Intelligence Platform läuft wie Ihre Datenpipelines und Ihre Governance-Ebene, können Teams dieselben Produktionspraktiken – Versionskontrolle, umgebungsspezifische Konfiguration und kontrollierte Bereitstellung – auch auf Dashboards anwenden.

Um dies konkret zu machen, zeigen wir, wie Analysten produktionsreife Databricks-Funktionen nutzen können, ohne ihre tägliche Arbeitsweise bei der Erstellung von Dashboards ändern zu müssen.

Konkret zeigen wir, wie Sie mit diesem Workflow Folgendes tun können:

• Jede Änderung an einem Dashboard überprüfen und freigeben
• Die Historie eines Dashboards nachverfolgen und Codeänderungen mit Geschäftsanforderungen verknüpfen
• Ein Dashboard auf eine frühere Version zurücksetzen

Voraussetzungen

Dieser Workflow erfordert eine einmalige Einrichtung der Infrastruktur, die in den meisten Unternehmen bereits vorhanden ist. Wenn dies bei Ihnen noch nicht der Fall ist, bitten Sie Ihr internes DevOps- oder IT-Team um Unterstützung bei der Einrichtung von:

• Mindestens zwei Databricks-Workspaces (z. B. ein Entwicklungs- und ein Produktions-Workspace) zum Erstellen, Testen und Bereitstellen von Dashboards
• Git-gestützte Ordner in Databricks (AWS | Azure | GCP), die zur Versionierung von Dashboard-Definitionen verwendet werden
• Für das Projekt konfigurierten Declarative Automation Bundles (DABs) (AWS | Azure | GCP)

Einführung: Ein strukturierter Workflow für die sichere Bereitstellung von Dashboard-Änderungen

Wir gehen ein realistisches Szenario durch: Sie sind für ein Sales Performance-Dashboard verantwortlich, das wöchentlich von der Finanz- und Vertriebsleitung genutzt wird. Es begann als Praktikantenprojekt direkt in einem Workspace, hat sich aber im Laufe der Zeit weiterentwickelt und wird nun in mehreren Vorstandspräsentationen verwendet.

Eine Verschiebung der Prioritäten nach einer Vorstandssitzung bringt eine neue Anforderung mit sich: Die Finanzabteilung muss nun verbindliche und unverbindliche Umsätze erfassen und eine einzelne aggregierte Umsatzkennzahl ersetzen. Das Dashboard muss diese neue Definition vor der nächsten Prognoseprüfung widerspiegeln.

Diese Werte fließen direkt in reale Geschäftsentscheidungen ein, einschließlich der Berechnung von Vergütungen und Boni. Bringen wir dieses Dashboard also zum ersten Mal auf einen disziplinierten Bereitstellungspfad.

Schritt 1: Das Dashboard zu einem Declarative Automation Bundle hinzufügen

Bevor Sie mit dem Prozess beginnen, arbeiten Sie mit Ihrem IT-Team zusammen, um einige grundlegende Code-Tools einzurichten: ein Git-Repository mit einem leeren „Declarative Automation Bundle“ und einige CI/CD-Skripte zur automatischen Bereitstellung des Bundles.

Ein Git-Repository ist ein Tool zur Verfolgung von Dateiänderungen. Um zu beginnen, müssen wir es mit Databricks verbinden, damit wir die Änderungen an der Dashboard-Konfiguration nachverfolgen können. Erstellen Sie im Databricks-Workspace einen Git-Ordner und fügen Sie die Repository-URL in den Einrichtungsdialog ein. Dadurch wird das Repository in Databricks registriert, sodass wir das Dashboard im nächsten Schritt hinzufügen können.

Ein Declarative Automation Bundle ist eine Möglichkeit, Code-Dateien (in diesem Fall ein Dashboard) zu gruppieren. Wenn das Repository bereits ein Bundle enthält, wird es automatisch erkannt und kann über das Pfeilsymbol geöffnet werden. Andernfalls kann ein neues Bundle über das Menü Erstellen im Git-Ordner erstellt werden.

Im Asset-Bundle-Editor können Sie dem derzeit leeren Bundle sowohl neue als auch vorhandene Komponenten hinzufügen. Um das Dashboard einzubinden, öffnen Sie das Menü Hinzufügen und wählen Sie Vorhandenes Dashboard hinzufügen. Nach dem Hinzufügen sehen Sie, dass das Dashboard im Ordner src als Teil des Bundles erscheint.

Ab diesem Zeitpunkt wird das Dashboard als bereitstellbares Asset verwaltet, was es einfach macht, dasselbe Dashboard über Entwicklungs-, Test- und Produktions-Workspaces hinweg bereitzustellen.

Führen Sie schließlich einen Commit für das Dashboard im Repository durch. Dadurch wird der aktuelle Zustand des Dashboards als Baseline erfasst und ein klarer Ausgangspunkt für die Nachverfolgung und Überprüfung zukünftiger Änderungen geschaffen.

Sie sehen, dass das Dashboard dem Repository hinzugefügt wurde, zusammen mit einigen automatisch generierten Konfigurationsdateien (die auf .yml enden). Diese Dateien beschreiben, wie das Dashboard in verschiedenen Umgebungen bereitgestellt werden soll – Sie müssen sie nicht bearbeiten.

Geben Sie im Feld Commit-Nachricht eine kurze Notiz ein, die Ihre Änderungen beschreibt, und wählen Sie dann Commit & Push. Dadurch wird ein Kontrollpunkt für das Dashboard erstellt – ein bekannter, funktionierender Zustand, zu dem Sie später zurückkehren können –, sodass zukünftige Änderungen verglichen, überprüft und sicher bereitgestellt werden können.

Schritt 2: Das Dashboard aktualisieren

Nachdem das vorhandene Dashboard committet wurde, können Sie Änderungen daran vornehmen, ohne die Live-Version in der Produktion zu beeinträchtigen, und Git wird die vorgenommenen Änderungen genau nachverfolgen.

Die gängige Praxis besteht darin, einen Git-Branch zu erstellen – eine Version des Dashboards, an der Sie arbeiten können, ohne andere zu beeinträchtigen. Sie können dies über die Schaltfläche „Branch erstellen“ tun und ihm dann einen aussagekräftigen Namen geben, z. B. Ihren Namen, das Feature oder eine Ticketnummer, die mit der Änderung verknüpft ist. Betrachten Sie dies als eine private Version für Ihr Update: Sie können das Dashboard frei bearbeiten, testen und verfeinern und dann separat entscheiden, wann Ihre Änderungen für die Überprüfung und Bereitstellung bereit sind.

Jetzt können Sie die Änderungen am Dashboard vornehmen! In diesem Fall ändern Sie die Umsatzzahl oben links, um sowohl nicht zugesagte als auch zugesagte Umsatzzähler hinzuzufügen (fettgedrucktes Blau und Rot wurden für bessere Sichtbarkeit gewählt).

Sie werden feststellen, dass sich an der Erstellungserfahrung nichts ändert – nehmen Sie diese Änderungen wie gewohnt über den Dashboard-UI-Editor vor.

Sobald das Dashboard in der Entwicklungsumgebung korrekt aussieht, können Sie fortfahren, um die Änderungen in die Produktion zu übertragen. Verwenden Sie wie zuvor dieselbe Git-Schaltfläche oben, um diese Änderungen mit einer kurzen Commit-Nachricht einzuchecken.

Schritt 3: Überprüfung der Änderung

Als Nächstes schalten Sie einen weiteren entscheidenden Vorteil dieses Workflows frei: einen Ort, an dem andere Personen Änderungen überprüfen und Feedback geben können, bevor die Änderung in die Produktion gelangt. Die Überprüfung durch eine zweite Person ist eine allgemeine Best Practice. Ebenso wichtig ist jedoch, dass dadurch ein risikofreier Raum entsteht, um Ideen zu diskutieren, Annahmen zu validieren und die Änderung zu verfeinern, bevor sie sich auf das Reporting auswirkt.

Um die Überprüfung zu starten, erstellen Sie einen Pull Request (PR) bei Ihrem Git-Anbieter, was im Grunde eine Review-Seite für das Dashboard-Update ist. Die überprüfende Person kann genau sehen, was sich geändert hat, Kommentare hinterlassen, auf die Sie eingehen können, und das Update genehmigen, sobald alles korrekt aussieht.

Während der Überprüfung bleibt das Produktions-Dashboard unverändert. Erst wenn das Feedback umgesetzt und die Änderung genehmigt wurde, geht es weiter.

Obwohl Dashboard-Änderungen im Hintergrund als Konfigurationsdateien gespeichert und nachverfolgt werden, ist es oft schwer zu verstehen, was sich tatsächlich geändert hat. Aus diesem Grund nutzen die meisten Teams eine kleine Automatisierung, um automatisch eine temporäre Testversion des Dashboards zur Überprüfung bereitzustellen, sobald ein PR geöffnet wird. Auf diese Weise können die Reviewer die vorgeschlagenen Metriken, Berechnungen und Layouts im Kontext sehen, bevor etwas in die Produktion gelangt, und Probleme mit der Datenlogik oder der UI erkennen. Wenn Entwickler oder Reviewer Screenshots oder Links zum Test-Dashboard direkt in den PR einfügen, wird das Feedback zudem schneller und sicherer.

Reviewer können Kommentare hinzufügen und die Änderung genehmigen. Dies wird aufgezeichnet, sodass die Änderung später leichter nachvollziehbar ist.

Schritt 4: Dashboard mithilfe des Bundles in der Produktion bereitstellen

Nachdem die Änderung genehmigt wurde, können Sie das Dashboard in der Produktion bereitstellen.

Dashboards erfordern in der Produktion oft andere Einstellungen als in der Entwicklung – zum Beispiel den Verweis auf einen Produktionskatalog oder ein Produktionsschema anstelle eines Entwicklungs-Datasets oder die Verwendung eines anderen SQL-Warehouses.

Die gute Nachricht ist, dass diese Unterschiede erwartet und im Rahmen des Bereitstellungsprozesses automatisch berücksichtigt werden.

Als Sie das Dashboard zum Asset Bundle hinzugefügt haben, hat Databricks eine kleine .yml-Konfigurationsdatei erstellt, die diese umgebungsspezifischen Einstellungen erfasst. Mit dieser Datei können Sie Werte je nach Umgebung überschreiben, ohne die Dashboard-Logik selbst zu ändern. In unserem Fall haben wir festgelegt, dass sich der vom Dashboard in der Produktion verwendete Katalog von dem in der Testumgebung unterscheiden soll, indem wir einen ${variable}-Wert für den Katalognamen verwenden.

Schließlich führt die databricks.yml-Datei alle Bundle-Ressourcen zusammen und definiert, welcher Katalog in der jeweiligen Umgebung verwendet wird. Dies erleichtert die Verwaltung konsistenter Bereitstellungen über Entwicklungs-, Test- und Produktions-Workspaces hinweg.

Sobald der Pull Request genehmigt und in den Main-Branch gemergt wurde, wird Ihre Bereitstellungsautomatisierung ausgeführt und verwendet die in databricks.yml definierten umgebungsspezifischen Werte. Derselbe Dashboard-Code wird über alle Workspaces hinweg wiederverwendet, während Einstellungen wie Katalog, Schema und Warehouse basierend auf der Zielumgebung angewendet werden. Dadurch entfällt die Notwendigkeit, separate Dashboard-Kopien für jeden Workspace zu verwalten, und es wird sichergestellt, dass sich Änderungen überall vorhersehbar verhalten.

Bei den meisten Git-Anbietern können Sie die Bereitstellungsautomatisierung direkt im Pull Request sehen, um die Bereitstellung zu überwachen und zu bestätigen, wann sie abgeschlossen ist (oder ob ein Problem auftritt). Wenn ein Problem auftritt, wird die Bereitstellung gestoppt, ohne das vorhandene Produktions-Dashboard zu beeinträchtigen, sodass Sie den Fehler beheben können. Sobald die Bereitstellung erfolgreich abgeschlossen ist, ist das aktualisierte Dashboard in der Produktion live und bereit für die Stakeholder!

Bonus 1: Was ist, wenn Sie den Verlauf einsehen möchten?

Sobald das Dashboard-Update live ist, müssen Sie möglicherweise den Verlauf der Änderungen nachvollziehen (was, wann und warum geändert wurde). Ein Vorteil dieses Workflows ist, dass die Änderung jetzt nachverfolgbar ist. Anstelle einer einmaligen Bearbeitung direkt in einem Workspace wird sie als Abfolge gespeicherter Versionen angezeigt.

Jeder Eintrag stellt ein Dashboard-Update dar, zusammen mit dem Autor und dem Zeitstempel. Sie können jeden Eintrag öffnen, um die Änderungen zu überprüfen und bei Bedarf rückgängig zu machen.

Bonus 2: Was ist, wenn Sie eine Änderung rückgängig machen müssen?

Selbst bei sorgfältiger Überprüfung und Tests können Probleme auftreten – beispielsweise ein Dashboard, das nicht geladen werden kann, oder eine Metrikdefinition, die sich als fehlerhaft erweist.

Da das Dashboard über diesen Workflow verwaltet wird, können Sie mithilfe desselben kontrollierten Prozesses, der für die Bereitstellung des Updates verwendet wurde, auf eine funktionierende Version zurückgreifen.

Öffnen Sie zunächst den Änderungsverlauf des Dashboards im Repository und suchen Sie das Update, das Sie rückgängig machen möchten. Von dort aus können Sie die Änderungen überprüfen, um sicherzustellen, dass Sie die richtige Änderung rückgängig machen, bevor Sie fortfahren.

Folgen Sie in den Änderungsdetails dem Link zurück zur Review-Seite. Um das Update rückgängig zu machen, wählen Sie Revert aus. Dadurch wird eine neue „Rückgängig“-Änderung erstellt, die nur dieses spezifische Update rückgängig macht. Das Dashboard wird auf seine vorherige Logik zurückgesetzt, während der restliche Verlauf des Dashboards intakt bleibt.

Sobald die Änderung im Main-Branch zusammengeführt wurde, macht dieselbe Automatisierung, die das Dashboard in der Produktion bereitgestellt hat, diese wieder rückgängig. Das bedeutet, dass Sie auf einen Ausfall oder ein schwerwiegendes Berechnungsproblem in wenigen Minuten reagieren können, ohne die bereits vorhandenen Kontrollen zu umgehen.

Bonus 3: Was passiert, wenn Ihre Datenquellen aktualisiert werden?

Die meisten Dashboards sind eng mit ihren Datenquellen verknüpft. Das bedeutet, dass Aktualisierungen an einem Dashboard oft eng mit Aktualisierungen in den Pipelines verbunden sind. Die gute Nachricht ist, dass Asset Bundles so konzipiert sind, dass sie zusammengehörige Komponenten in einem Paket gruppieren.

Dies stellt sicher, dass Sie von einer Änderung des Upstream-Datenmodells nie überrascht werden. Und wenn Visualisierungsänderungen Aktualisierungen des Datenmodells erfordern, können Sie beide Änderungen in einer einzigen Bereitstellung ausrollen.

Fazit

Die Behandlung von AI/BI-Dashboards als produktionsreife Datenprodukte ist für verlässliche Geschäftsentscheidungen und Risikominderung unerlässlich. In diesem Workflow machen einige wenige zusätzliche Schritte Dashboard-Änderungen sichtbar, überprüfbar und umkehrbar – ohne dass sich Ihre tägliche Arbeit bei der Erstellung von Dashboards ändert.

Durch die Verwaltung von Dashboards mit Git und Declarative Automation Bundles etablieren Teams einen routinierten, vorhersehbaren Workflow für Updates: Änderung vornehmen, überprüfen, testen und bereitstellen. Derselbe Prozess gilt unabhängig davon, ob es sich bei dem Update um eine kleine visuelle Anpassung oder eine wesentliche Änderung der Geschäftslogik handelt.

Mit der richtigen Bereitstellungsdisziplin sind Dashboard-Änderungen kein Risikofaktor mehr, sondern eine vertrauenswürdige Quelle für Erkenntnisse, die sich mit dem Unternehmen weiterentwickelt – selbst in kritischen Situationen wie einer Vorstandssitzung.

Mehr erfahren + Nächste Schritte

Wenn Sie inspiriert sind und tiefer in die in diesem Workflow verwendeten Komponenten eintauchen möchten, finden Sie hier einige Ressourcen, mit denen Sie fortfahren können:

• „Branching-Strategie“ (AWS | Azure | GCP)
  Erfahren Sie, wie Änderungen mithilfe eines Branching-Modells, das Best Practices folgt, zusammengeführt und bereitgestellt werden.
• Declarative Automation Bundles (AWS | Azure | GCP)
  Erfahren Sie, wie Asset Bundles verwendet werden, um Databricks-Ressourcen konsistent über verschiedene Umgebungen hinweg zu packen und bereitzustellen.
• CI/CD für die automatisierte Bereitstellung auf Databricks (AWS | Azure | GCP)
  Erfahren Sie, wie Sie CI/CD mit Starter-Skripten für GitHub Actions implementieren (AWS | Azure | GCP)
• Verwendung von Asset Bundles über die Databricks Workspace-UI (AWS | Azure | GCP)
  Erfahren Sie, wie Sie Bundles direkt aus dem Workspace erstellen, bearbeiten und bereitstellen.
• Git-gestützte Ordner in Databricks (AWS | Azure | GCP)
  Erfahren Sie, wie die Git-Integration in Databricks funktioniert und wie sich die Versionskontrolle in die täglichen Analytics-Workflows einfügt.

Wenn Sie bereit sind, den nächsten Schritt mit Databricks AI/BI zu gehen, können Sie eine der folgenden Optionen wählen:

• Kostenlose Edition und Testversion: Sammeln Sie praktische Erfahrungen, indem Sie sich für unsere kostenlose Edition oder Testversion registrieren.
• Dokumentation: Tauchen Sie mit unserer Dokumentation tiefer in die Details ein.
• Webseite: Besuchen Sie unsere Webseite, um mehr zu erfahren.
• Demos: Sehen Sie sich unsere Demo-Videos an, machen Sie Produkt-Touren und nutzen Sie praktische Tutorials, um AI/BI in Aktion zu erleben.
• Schulung: Beginnen Sie mit einer kostenlosen Produkt-Schulung über die Databricks Academy.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag