Granulare Nutzungszuweisung für dbt-Pipelines mit Abfrage-Tags – geklont

Ihr dbt-Projekt führt jede Nacht 80 Modelle aus. Die Lagerkosten haben sich im letzten Quartal verdoppelt. Die Modellleistung variiert stark, und die Auswirkungen der neuesten Optimierungen sind unklar. Finanzen fragt, welches Team verantwortlich ist. Sie öffnen den Abfrageverlauf und sehen ... 80 identische Zeilen mit der Bezeichnung 'Databricks Dbt'. Viel Glück.

Mit Query Tags (jetzt in der öffentlichen Vorschau) können Datenteams jetzt von sofort einsatzbereiten automatisch eingefügten Tags profitieren, wie z. B. dbt_model_name, die jeden Durchlauf bereichern. Sie können jeder Abfrage, die Ihre Pipeline generiert, auch eigene benutzerdefinierte Tags zuordnen – Team, Kostenstelle, Umgebung usw. –, die von Ihrer Pipeline generiert werden.

Tags werden in system.query.history aufgezeichnet, sodass Kostenzuordnung, Performance-Debugging und Workload-Überwachung mit einer einfachen SQL-Abfrage vereinfacht werden können (vollständige Details finden Sie in der Dokumentation).

In diesem Blog wird ein vollständiges Open-Source-dbt-Projekt beschrieben, das Query Tags durchgängig demonstriert: von der Konfiguration bis hin zu Kostenzuordnungs-Dashboards. Alle hier beschriebenen Informationen sind als GitHub-Repository verfügbar, das Sie klonen und in Ihrem eigenen Workspace bereitstellen können. Oder fragen Sie einfach

Genie.Integration von dbt-databricks in Query Tags

Der dbt-databricks-Adapter (Version 1.11+) unterstützt Query Tags nativ. Es gibt drei Ebenen, auf denen Tags angewendet werden können, wobei jede auf den vorherigen aufbaut:

Automatisch eingefügte Tags

Zusätzlich zu Ihren benutzerdefinierten Tags fügt dbt-databricks automatisch Metadaten zu jeder Modellausführung ein:

Diese automatischen Tags bedeuten, dass Sie modellbezogene Transparenz ohne Konfiguration erhalten – der Adapter übernimmt dies für Sie.Tags auf

Profilebene

Der einfachste Ansatz: Fügen Sie einem bestimmten Ziel in Ihrem dbt-Profil ein Feld query_tags hinzu. Jede Abfrage im Projekt erbt diese Tags automatisch.

Beispielsweise werden in dieser einzigen Zeile jede Abfrage mit vier Dimensionen gekennzeichnet: Wem gehört sie (Team), wohin gehen die Kosten (Costcenter), zu welcher Pipeline sie gehört (Projektname) und in welcher Umgebung sie ausgeführt wird (env).

Tags auf Modellebene

Für eine detailliertere Zuordnung können Sie Tags für bestimmte Modelle in dbt_project.yml oder für die Modellkonfiguration in der SQL-Definition angeben. 

Tags auf Modellebene werden mit Tags auf Profilebene zusammengeführt. Wenn beide denselben Schlüssel definieren, hat der Wert auf Modellebene Vorrang.

Wo Tags angezeigt werden – system.query.history

Nach dem Ausführen von dbt-run wird jede SQL-Anweisung in system.query.history angezeigt, wobei die Spalte query_tags als MAP ausgefüllt ist. Sie können sie mit der Standardsyntax für Kartenzugriff abfragen:

Hiermit werden alle markierten Abfragen der letzten 7 Tage zurückgegeben. Die benutzerdefinierten und automatisch eingefügten Tags werden in einzelne Spalten extrahiert und können dann zusammengefasst werden.

Sie finden die Abfrage-Tags für die ausgeführte Abfrage auch in der Benutzeroberfläche für den Abfrageverlauf oder die Benutzeroberfläche für SQL Warehouse Monitoring.

Auf der Im Abfrageprofil unten rechts werden die von Ihnen definierten Abfrage-Tags angezeigt. Sie erhalten alle erforderlichen Informationen auf einen Blick.

Kostenzuordnung mit Abfrage-Tags

Abfrage-Tags ermöglichen die direkte Bestimmung der detaillierten Nutzungszuordnung über SQL-Abfragen. Manuelle Protokollanalysen oder Aufteilung von Warehouse-Ressourcen sind nicht mehr erforderlich.

Welche dbt-Modelle verbrauchen die meisten Warehouse-Ressourcen?

Sie können diese Frage auf zwei Arten beantworten: Fragen Sie Genie in Klarsprache nach einer Ad-hoc-Untersuchung oder schreiben Sie die SQL-Datei selbst, um ein wiederholbares und dashboardfähiges Ergebnis zu erhalten. Beide lesen aus denselben system.query.history-Daten.

Option 1: Genie

Genie schreibt und führt die entsprechende Abfrage aus, und Sie können die Folgefragen weiter ausführen, ohne SQL zu berühren.

Option 2: SQL

Beide Pfade geben dasselbe Bild zurück. In unserem Referenzprojekt dominieren die vier Mart-Tabellen (materialisiert als Tabelle) die Rechenzeit, während Staging-Ansichten und Messwertansichten nahezu sofort verfügbar sind. Dadurch erfahren Sie sofort, worauf sich die Optimierungsbemühungen konzentrieren sollten.

Erstellen eines selbstüberwachenden Dashboards

Unser Referenzprojekt umfasst ein KI/BI-Dashboard, das system.query.history abfragt, gefiltert durch die projekteigenen Abfrage-Tags. Das Ergebnis: Die Pipeline, die die Rechnungsdaten analysiert, verfolgt auch ihre eigenen Kosten – sie füttert Abfrage-Tags selbst.

Das Dashboard enthält:

• KPIs: Gesamtzahl der getaggten Abfragen, Gesamtzahl der Rechensekunden, unterschiedliche DBT-Modelle
• Tägliche Aktivität: Anzahl der Abfragen und Rechenzeit pro Tag, aufgeteilt nach Umgebung
• Modellaufschlüsselung: Berechnungszeit pro Modell, farbig nach Materialisierungstyp
• Materialisierungsaufteilung: Kreisdiagramm mit der Verteilung der Berechnung auf Tabelle, Ansicht und metric_view
• Query-Detailtabelle: Jede markierte Abfrage mit Modell, Dauer, Umgebung und Ausführer

In unserem Referenzprojekt machten die vier Mart-Modelle 92 % der Rechenzeit aus. Ohne Query-Tags blieben diese Erkenntnisse unsichtbar.

Das Erstellen dieses Dashboards selbst dauert mit Genie Code Minuten: Fragen Sie nach der Rechenzeit pro dbt-Modell aus system.query.history, gefiltert durch Ihre Abfrage-Tags, und es schreibt die SQL und stellt die Visuals zusammen. Wenn Sie lieber direkt zum fertigen Ergebnis springen möchten, wird das Dashboard auch im Referenzprojekt enthalten und mit einem Databricks-Paket zusammen mit dem DBT-Job bereitgestellt (eine detaillierte Anleitung finden Sie im Github-Repository).

Kennzeichnung von Messwertansichten

Databricks-Messwertansichten (verfügbar mit dbt-databricks 1.12+) sind ein neuer Materialisierungstyp, der wiederverwendbare Geschäftssemantiken in Form von Dimensionen und Kennzahlen direkt im Unity-Katalog definiert (siehe vollständige Dokumentation). Sie können Abfrage-Tags wie jedes andere Modell tragen, indem Sie den Konfigurationsparameter query_tags verwenden:

Beachten Sie den Unterschied: query_tags werden an die SQL-Abfragen angehängt, die die Metrikansicht erstellen oder aktualisieren (verfolgt in system.query.history), während databricks_tags Unity-Katalog-Tags auf dem Objekt selbst sind (für Governance und Ermittlung). Erstere dient der Nachverfolgung auf Abfrageebene, während letztere auf Unity-Katalogobjektebene für die allgemeine Datenerkennung eingesetzt wird. 

Best Practices für die Tagging von dbt-Projekten

In diesem Artikel haben wir den ganzheitlichen Prozess zum Aufbau einer soliden FinOps-Praxis behandelt, bei der Query-Tags die Grundlage für die Kostenzuordnung bilden. Folgendes haben wir beim Erstellen des Referenzprojekts und beim Gespräch mit Power-Usern von dbt gelernt:

• Verwenden Sie eine konsistente Tag-Hierarchie. Definieren Sie unternehmensweite Tags auf Profilebene (Team, Kostenstelle, Projektname, env) und reservieren Sie Tags auf Modellebene für Ausnahmefälle. Dadurch bleiben Tags vorhersehbar und vermeiden Konfigurationsaufwände pro Modell.
• Taggen Sie die Umgebung immer an. Verwenden Sie unterschiedliche env-Werte für lokale Entwicklung (local-dev) und bereitgestellte Jobs (dev, staging, prod). Auf diese Weise können Sie Ad-hoc-Entwicklungsabfragen von geplanten Produktionsläufen in Ihren Analysen trennen. In unserem Referenzprojekt ist das lokale Profil auf "env": "local-dev" festgelegt, während das bereitgestellte Profil auf "env": "dev" festgelegt ist.
• Verwenden Sie `project_name`, um Pipelines zu unterscheiden. Wenn mehrere dbt-Projekte ein Lager gemeinsam nutzen, können Sie project_name Kosten pro Pipeline zuordnen, ohne Warehouses aufzuteilen. In Kombination mit dem automatisch eingespeicherten @@dbt_model_name erhalten Sie vollständige Rückverfolgbarkeit: Projekt → Modell → Materialisierung.
• Übertreiben Sie keine Tags. Die automatisch eingefügten Tags decken bereits Modellname, Materialisierungstyp und Adapterversionen ab. Sie müssen diese Informationen nur selten in benutzerdefinierten Tags duplizieren. Fokussieren Sie benutzerdefinierte Tags auf den geschäftlichen Kontext, den dbt nicht ableiten kann: Teamverantwortung, Kostenstelle, Projektidentität.
• Kennzahlansichten explizit markieren. Da es sich bei Metrikansichten um eine neuere Form handelt, ist es sinnvoll, sie mit einem Feature-Key zu versehen (z. B. "feature": "metric_view"), damit Sie in Ihrer Kostenanalyse problemlos nach Abfragen zur Erstellung von Metrikansichten filtern können.

Probieren Sie es selbst aus

Das vollständige Referenzprojekt ist auf GitHub verfügbar: github.com/databricks-solutions/dbt-query-tags

Für den Einstieg:

1. Klonen des Repository
2. Erstellen Sie eine virtuelle Python 3.12-Umgebung und installieren Sie Abhängigkeiten: pip installieren dbt-databricks>=1.12.0a1
3. Aktualisieren Sie die Datei profiles.yml mit Ihrem Workspace-Host, dem HTTP-Pfad von SQL Warehouse, dem Katalog und den benutzerdefinierten Abfrage-Tags
4. Ausführen dbt deps && dbt führen Sie --profiles-dir aus , um die Pipeline auszuführen
5. Query system.query.history, um Ihre Tags in Aktion zu sehen.
6. Aktualisieren Sie dbt_profiles/profiles.yml und databricks.yml, um auf die korrekte Konfiguration hinzuweisen.
7. Bereitstellen mit databricks Bundle Deploy für geplante Ausführungen und das Analyse-Dashboard

Wechseln Sie in Ihre eigenen Team- und Kostenstellenwerte ein. Das Muster funktioniert für jedes dbt-Projekt auf Databricks.

Clonen Sie das Repository noch heute! Mit einer Zeile in Ihrem Profil erhalten Sie die Sichtbarkeit der Nutzungszuordnung auf Modellebene für Ihr gesamtes Lager.

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