Granulare Nutzungszuordnung für dbt-Pipelines mit Abfrage-Tags

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 auch eigene benutzerdefinierte Tags – Team, Kostenstelle, Umgebung usw. – an jede Abfrage anhängen, die Ihre Pipeline generiert.

Tags werden in system.query.history aufgezeichnet, sodass Kostenzuordnung, Performance-Debugging und Workload-Überwachung mit einer einfachen SQL-Abfrage vereinfacht werden (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 Sie können Genie fragen.

Integration dbt-databricksmit Query Tags

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

Automatisch eingefügte Tags

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

Dank dieser automatischen Tags erhalten Sie Einblick in jedes Modell ohne Konfiguration – der Adapter übernimmt dies für Sie.

Tags auf Profilebene

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

Beispielsweise kennzeichnet diese einzelne Zeile jede Abfrage mit vier Dimensionen: 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 der Ausführung von dbt run wird jede SQL-Anweisung in system.query.history angezeigt, wobei die Spalte query_tags als MAP<STRING, STRING> ausgefüllt ist. Sie können sie mit der Standardsyntax für den Kartenzugriff abfragen:

Dadurch werden alle mit Tags versehenen Abfragen der letzten sieben Tage zurückgegeben. Die benutzerdefinierten und automatisch eingefügten Tags werden in einzelne Spalten extrahiert und können dann aggregiert werden.

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

Unten rechts im Abfrageprofil sehen Sie die von Ihnen definierten Abfrage-Tags. Sie erhalten alle erforderlichen Informationen auf einen Blick.

Kostenzuordnung mit Query Tags

Mit Query Tags können Sie die detaillierte Nutzungszuordnung direkt über SQL-Abfragen bestimmen, sodass keine manuelle Protokollanalyse oder Aufteilung von Warehouse-Ressourcen erforderlich ist.

Welche dbt-Modelle verbrauchen die meisten Lagerressourcen?

Sie können diese Frage auf zwei Arten beantworten: Fragen Sie Genie in einfacher Sprache nach einer Ad-hoc-Untersuchung oder schreiben Sie die SQL-Datei selbst, um ein wiederholbares Ergebnis für das Dashboard 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 eingeben, 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 Optimierungsmaßnahmen konzentrieren sollten.

Erstellen eines selbstüberwachenden Dashboards

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

Das Dashboard umfasst:

• KPIs: Gesamtzahl der getaggten Abfragen, Gesamtzahl der Rechnersekunden, 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, das zeigt, wie die Berechnung auf Tabelle, Ansicht und Metric_View verteilt ist
• Abfragendetailtabelle: 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 waren diese Erkenntnisse nicht sichtbar.

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).

Kennzeichnen von Metrikansichten

Databricks-Metrikansichten (verfügbar ab Version dbt-databricks1.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 sind an die SQL-Abfragen angehängt, die die Metrikansicht erstellen oder aktualisieren (nach system.query.history verfolgt), 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. Hier erfahren Sie, was wir beim Erstellen des Referenzprojekts und beim Gespräch mit Power-Benutzern von dbt:

• 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 eine Ausdehnung der Konfigurationen pro Modell wird vermieden.
• Kennzeichnen Sie immer die Umgebung. 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 der automatischen Injektion @@dbt_model_nameerhalten Sie vollständige Rückverfolgbarkeit: Projekt → Modell → Materialisierung.
• Übertreiben Sie es nicht. Die automatisch eingefügten Tags decken bereits Modellname, Materialisierungstyp und Adapterversionen ab. Sie müssen diese Informationen nur selten in benutzerdefinierten Tags duplizieren. Konzentrieren Sie benutzerdefinierte Tags auf geschäftlichen Kontext, den dbt nicht ableiten kann: Teamverantwortung, Kostenstelle, Projektidentität.
• Kennzeichnen Sie Kennzahlansichten explizit. Da es sich bei Metrikansichten um eine neuere Materialisierung handelt, ist es hilfreich, 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

So starten Sie:

1. Klonen des Repositorys
2. Erstellen Sie eine virtuelle Python 3.12-Umgebung und installieren Sie Abhängigkeiten: pip install dbt-databricks>=1.12.0a1
3. Aktualisieren Sie die Datei profiles.yml mit Ihrem Workspace-Host, SQL Warehouse-HTTP-Pfad, Katalog und benutzerdefinierten Abfrage-Tags
4. Führen Sie dbt deps && dbt run --profiles-dir . aus, um die Pipeline auszuführen
5. Abfragen Sie 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. Bereitstellung mit databricks Paketbereitstellung für geplante Ausführungen und das Analyse-Dashboard

Tauschen Sie Werte für Ihr eigenes Team und Ihre Kostenstellen ein. Das Muster funktioniert für jedes dbt-Projekt auf Databricks.

Klonen 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