Tutorial: Wie Sie Änderungen an KI-/BI-Dashboards mit Databricks Asset Bundles sicher und im großen Maßstab bereitstellen

Die Vorstellung, dass eine Vorstandssitzung mit einem Dashboard voller Fehler beginnt, sollte Analytics-Teams nachts wach halten. Das gilt auch für die nachträgliche Feststellung, dass ein Einstellungsplan, eine Produkteinführung oder eine Umsatzprognose auf einer falschen Metrik basierte. Oder dass ein Supportteam viel zu viele Rückerstattungen ausgestellt hat, weil ein Dashboard den Kaufverlauf eines Kunden falsch dargestellt hat.

Diese Fehler werden selten durch eine schlechte Analyse verursacht. Wie bei jedem Produktionssystem resultieren sie oft daraus, dass Dashboards manuell aktualisiert werden, während sich Datenmodelle und Anforderungen weiterentwickeln – ohne Versionierung, ohne einen zuverlässigen Überprüfungsprozess oder ohne eine wiederholbare Methode zur Übernahme von Änderungen in verschiedenen Umgebungen.

Dieser Blogpost vertritt eine einfache These: Produktionsreife Dashboards, die das Geschäft vorantreiben, müssen mit der gleichen Disziplin wie Produktionscode verwaltet werden. Da Databricks AI/BI auf derselben Data Intelligence Platform wie Ihre Datenpipelines und Governance-Schicht ausgeführt wird, können Teams dieselben Produktionspraktiken – Versionskontrolle, umgebungsspezifische Konfiguration und kontrollierte Bereitstellung – auch auf Dashboards anwenden.

Um dies zu verdeutlichen, zeigen wir, wie Analysten die produktionsreifen Funktionen von Databricks nutzen können, ohne ihre tägliche Arbeit bei der Erstellung von Dashboards zu ändern.

Insbesondere zeigen wir Ihnen, wie dieser Flow Ihnen Folgendes ermöglicht:

• Jede Änderung an einem Dashboard überprüfen und genehmigen
• Verfolgen Sie den Verlauf eines Dashboards und verknüpfen Sie Code-Änderungen mit Geschäftsanforderungen
• 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 Sie diese noch nicht haben, bitten Sie Ihre interne DevOps- oder IT-Gruppe, Ihnen bei der Einrichtung zu helfen:

• Mindestens zwei Databricks-Workspaces (z. B. ein Entwicklungs- und ein Produktions-Workspace), um Dashboards zu erstellen, zu testen und bereitzustellen
• Git-gestützte Ordner in Databricks (AWS | Azure | GCP), die zur Versionierung von Dashboard-Definitionen verwendet werden
• Databricks Asset Bundles (DABs) (AWS | Azure | GCP), die für das Projekt konfiguriert sind

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

Wir gehen ein realistisches Szenario durch: Sie sind für ein Vertriebs-Performance -Dashboard verantwortlich, das wöchentlich von der Finanz- und Vertriebsleitung verwendet wird. Es startete als Praktikantenprojekt, das direkt in einem workspace erstellt wurde, hat sich aber im Laufe der Zeit weiterentwickelt und wird nun in mehreren Überprüfungen durch die Führungskräfte verwendet.

Eine Prioritätenverschiebung nach einer Vorstandssitzung bringt eine neue Anforderung mit sich: Die Finanzabteilung muss jetzt zugesagte und nicht zugesagte Verkaufsbeträge nachverfolgen. Das ersetzt eine einzelne aggregierte Verkaufs-Metrik und das Dashboard muss die neue Definition vor der nächsten Prognoseprüfung widerspiegeln.

Diese Werte fließen direkt in echte Geschäftsentscheidungen ein, einschließlich Vergütungs- und Bonusberechnungen. Bringen wir dieses Dashboard also zum ersten Mal auf einen disziplinierten Bereitstellungspfad.

Schritt 1: Fügen Sie das Dashboard zu einem Databricks Asset Bundle hinzu

Bevor Sie mit dem Prozess beginnen, arbeiten Sie mit Ihrer IT-Abteilung zusammen, um einige grundlegende Code-Tools einzurichten: ein Git-Repository mit einem leeren „Databricks Asset Bundle“ und einigen ci/cd-Skripten, um das Bundle automatisch bereitzustellen.

Ein Git-Repository ist ein Tool zur Nachverfolgung von Dateiänderungen. Um loszulegen, 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 das Einrichtungsdialogfeld ein. Dadurch erkennt Databricks das Repository und wir können ihm im nächsten Schritt das Dashboard hinzufügen.

Ein Databricks Asset Bundle ist eine Möglichkeit, Codedateien (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 über das Menü Erstellen im Git-Ordner ein neues Bundle erstellt werden.

Im Asset Bundle-Editor können Sie dem derzeit leeren Bundle sowohl neue als auch vorhandene Komponenten hinzufügen. Um das Dashboard einzuschließen, öffnen Sie das Menü Hinzufügen und wählen Sie Vorhandenes Dashboard hinzufügen aus. Nachdem Sie es hinzugefügt haben, wird das Dashboard als Teil des Bundles im Ordner src angezeigt.

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

Abschließend committen Sie das Dashboard in das Repository. 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 werden 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 angewendet werden soll – Sie müssen sie nicht bearbeiten.

Fügen Sie eine kurze Notiz, die Ihre Tätigkeit beschreibt, in das Feld Commit-Nachricht ein und wählen Sie dann Commit & Push. Dadurch wird ein Prüfpunkt für das Dashboard erstellt – ein als funktionsfähig bekannter Zustand, zu dem Sie später zurückkehren können –, sodass zukünftige Änderungen verglichen, überprüft und sicher angewendet werden können.

Schritt 2: Das Dashboard aktualisieren

Nachdem das vorhandene Dashboard committet wurde, können Sie Änderungen daran vornehmen, ohne die Produktionsversion zu beeinträchtigen, und Git verfolgt die von Ihnen vorgenommenen spezifischen Änderungen.

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

Jetzt können Sie die Änderungen am Dashboard vornehmen! In diesem Fall ändern Sie die Vertriebszahl oben links, um Zähler für nicht zugesagten und zugesagten Vertrieb hinzuzufügen (fettgedrucktes Blau und Rot wurden zur besseren Sichtbarkeit gewählt).

Sie werden feststellen, dass sich an der Erstellungsumgebung nichts ändert – nehmen Sie diese Änderungen wie gewohnt mit dem UI-Editor des Dashboards vor.

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

Schritt 3: Überprüfen Sie die Änderung

Als Nächstes erschließen Sie einen weiteren wichtigen Vorteil dieses Workflows: einen Ort, an dem andere Ä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, aber ebenso wichtig ist, dass dadurch ein Raum mit geringem Risiko geschaffen wird, 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 eine Pull-Anfrage (PR) bei Ihrem Git-Anbieter. Dies ist im Grunde eine Überprüfungsseite für das Dashboard-Update. Der Prüfer kann genau sehen, was sich geändert hat, Kommentare für Sie hinterlassen, die Sie bearbeiten müssen, und das Update genehmigen, sobald alles in Ordnung ist.

Während der Überprüfung bleibt das Produktions-Dashboard unverändert. Erst nachdem das Feedback bearbeitet und die Änderung genehmigt wurde, wird sie weitergeleitet.

Obwohl Dashboard-Änderungen im Hintergrund als Konfigurationsdateien gespeichert und verfolgt werden, ist es oft schwer zu verstehen, was sich tatsächlich geändert hat. Aus diesem Grund verwenden die meisten Teams eine kleine Automatisierung, um bei jedem Öffnen eines PR automatisch eine temporäre Testversion des Dashboards zur Überprüfung bereitzustellen. Auf diese Weise können Reviewer die vorgeschlagenen Kennzahlen, Berechnungen und Layouts im Kontext sehen, bevor etwas in die Produktion gelangt, und Probleme mit der Datenlogik oder der Benutzeroberfläche erkennen. Wenn der Entwickler oder Reviewer Screenshots oder Links zum Test-Dashboard direkt in den PR einfügt, wird das Feedback ebenfalls schneller und zuverlässiger.

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

Schritt 4: Stellen Sie das Dashboard mithilfe des Bundles in der Produktionsumgebung bereit.

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

Dashboards benötigen in der Produktion oft andere Einstellungen als in der Entwicklung – zum Beispiel, dass sie auf einen Produktionskatalog oder ein Produktionsschema anstelle eines Entwicklungs-Datasets verweisen oder ein anderes SQL Warehouse verwenden.

Die gute Nachricht ist, dass diese Unterschiede erwartet und im Rahmen des Bereitstellungsprozesses behandelt werden.

Als Sie das Dashboard dem Asset Bundle hinzugefügt haben, hat Databricks eine kleine .yml generiert, Konfigurationsdatei, 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 Katalog, den das Dashboard in der Produktion verwendet, von dem im Test unterscheiden soll, indem wir für den Katalognamen einen ${variable} -Wert verwenden.

Schließlich bündelt die Datei databricks.yml alle Bundle-Ressourcen und definiert, welcher Katalog in jeder Umgebung verwendet wird, was die Verwaltung konsistenter Bereitstellungen über Entwicklungs-, Test- und Produktions-Workspaces hinweg erleichtert.

Sobald der Pull-Request genehmigt und in den Main-branch gemergt wurde, nimmt Ihre Bereitstellungsautomatisierung die Ausführung auf und verwendet die umgebungsspezifischen Werte, die in databricks.yml definiert sind. Derselbe Dashboard-Code wird Workspace-übergreifend wiederverwendet, während Einstellungen wie Katalog, Schema und Warehouse basierend auf der Zielumgebung angewendet werden. Dadurch entfällt die Notwendigkeit, für jeden Workspace separate Dashboard-Kopien zu pflegen, und es wird sichergestellt, dass sich Änderungen überall vorhersagbar verhalten.

Bei den meisten Git-Anbietern können Sie die Bereitstellungsautomatisierung auf dem Pull Request sehen, sodass Sie die Bereitstellung überwachen und bestätigen können, wann sie abgeschlossen ist (oder ob ein Problem auftritt). Wenn ein Problem auftritt, stoppt die Bereitstellung, ohne das bestehende Produktions-Dashboard zu beeinträchtigen, damit Sie eine Fehlerbehebung durchführen können. Sobald die Bereitstellung erfolgreich abgeschlossen ist, ist das aktualisierte Dashboard in der Produktion live und für die Stakeholder bereit!

Bonus 1: Was, wenn Sie den Verlauf überprüfen möchten?

Sobald das Dashboard-Update live ist, müssen Sie möglicherweise den Verlauf nachvollziehen können, was sich wann und warum geändert hat. Ein weiterer Vorteil dieses Flows ist, dass die Änderung jetzt nachverfolgbar ist. Anstatt einer einmaligen Bearbeitung, die direkt in einem Arbeitsbereich vorgenommen wird, erscheint sie als eine Abfolge von gespeicherten Versionen.

Jeder Eintrag stellt ein Dashboard-Update dar, zusammen mit dem Autor und dem timestamp. Sie können jeden Eintrag öffnen, um die Änderungen zu überprüfen und sie bei Bedarf zurückzusetzen.

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

Auch bei sorgfältiger Überprüfung und Tests können weiterhin Probleme auftreten – wie z. B. ein Dashboard, das nicht geladen werden kann, oder eine Metrikdefinition, die sich als falsch herausstellt.

Da das Dashboard über diesen Workflow verwaltet wird, können Sie mit demselben kontrollierten Prozess, der für die Anwendung des Updates verwendet wird, ein Rollback auf eine bekanntermaßen funktionierende Version durchführen.

Öffnen Sie zunächst den Änderungsverlauf des Dashboards im Repository und suchen Sie das Update, das Sie rückgängig machen möchten. Dort können Sie überprüfen, was geändert wurde, um zu bestätigen, dass Sie die richtige Änderung rückgängig machen, bevor Sie fortfahren.

Folgen Sie in den Änderungsdetails dem Link zurück zur Überprüfungsseite. Um das Update zurückzusetzen, wählen Sie Zurücksetzen aus. Dadurch wird eine neue „Rückgängig“-Änderung erstellt, die nur dieses spezifische Update rückgängig macht, wodurch das Dashboard auf seine vorherige Logik zurückgesetzt wird, während der Rest des Dashboard-Verlaufs intakt bleibt.

Sobald die Änderung in den Main Branch gemergt wurde, wird dieselbe Automatisierung, die das Dashboard in der Produktionsumgebung bereitgestellt hat, ein Rollback durchführen. Das bedeutet, dass Sie auf einen Ausfall oder ein Problem mit einer Berechnung mit großer Auswirkung in wenigen Minuten reagieren können, ohne die bereits vorhandenen Kontrollen zu umgehen.

Bonus 3: Was ist, wenn Ihre Datenquellen ein Update haben?

Die meisten Dashboards sind eng mit ihren Datenquellen verknüpft, was bedeutet, dass Aktualisierungen eines Dashboards oft eng mit Aktualisierungen in den Pipelines verknüpft sind. Die gute Nachricht ist, dass Asset Bundles dafür konzipiert sind, verwandte Komponenten in einem Paket zu gruppieren.

Dies stellt sicher, dass eine vorgelagerte Datenmodelländerung Sie nie überrascht und dass Sie, falls Visualisierungsänderungen Datenmodellaktualisierungen erfordern, beide Änderungen in einer einzigen Bereitstellung ausrollen können.

Fazit

Die Behandlung von KI-/BI-Dashboards als produktionsreife Datenprodukte ist für zuverlässige Geschäftsentscheidungen und zur Risikominderung unerlässlich. In diesem Workflow machen einige wenige zusätzliche Schritte Dashboard-Änderungen sichtbar, überprüfbar und umkehrbar – ohne die Art und Weise zu ändern, wie Sie täglich Dashboards erstellen.

Durch die Verwaltung von Dashboards mit Git und Databricks Asset Bundles etablieren Teams einen routinemäßigen, vorhersehbaren Workflow für Updates: die Änderung vornehmen, sie überprüfen, sie testen und sie 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 Deployment-Disziplin sind Dashboard-Änderungen keine Risikoquelle mehr, sondern eine vertrauenswürdige Quelle für Einblicke, die sich mit dem Unternehmen weiterentwickelt, selbst in wichtigen Situationen wie einer Vorstandssitzung.

Weitere Informationen und nächste Schritte

Wenn Sie inspiriert sind und sich eingehender mit den in diesem Workflow verwendeten Komponenten befassen möchten, finden Sie hier einige Ressourcen, die ein guter Ausgangspunkt sind:

• „Branching-Strategie“ (AWS | Azure | GCP)
  Erfahren Sie, wie Änderungen mithilfe eines Branching-Modells, das Best Practices folgt, zusammengeführt und angewendet werden.
• Databricks Asset Bundles (AWS | Azure | GCP)
  Erfahren Sie, wie Asset Bundles verwendet werden, um Databricks-Ressourcen umgebungsübergreifend konsistent zu paketieren und bereitzustellen.
• CI/CD für die automatisierte Bereitstellung auf Databricks (AWS | Azure | GCP)
  Erfahren Sie, wie Sie CI/CD mit den Starter-Skripten für Github Actions implementieren können (AWS | Azure | GCP)
• Verwenden 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 Analyse-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 anmelden.
• 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, nehmen Sie an Produkttouren teil und erhalten Sie praxisnahe Tutorials, um diese KI/BI in Aktion zu sehen.
• Training: Starten Sie mit dem kostenlosen Produkt- Training der Databricks Academy.

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