DataDiese Woche in DataSoftware & SaaS

Agents waren das Thema auf dem dbt Summit, die eigentliche Lektion war eine Reuse-Rate von 0,2 %

Fivetran + dbt Labs haben in Las Vegas „agent-ready data“ verkauft, und ihre eigenen Kundenzahlen zeigen, dass nichts funktioniert, solange Bedeutung nicht in der pipeline deklariert ist. Das Debriefing dieser Woche behandelt das Pricing von dbt State, den Context Layer, freiwillige KI-Aufsicht und die Token-Rechnung, die niemand modelliert.

A spotlit robot agent stands still before a network of pipeline blocks while an engineer marks a few with red ribbons.

Die Themen dieser Woche zeigen alle auf dasselbe Problem. Ein Scheduler, der entscheidet, ob er einen Rebuild überspringt, ein Agent, der entscheidet, was „Umsatz“ bedeutet, und ein Prüfer, der wissen will, wie eine Zahl zustande kam: Sie alle hängen von Bedeutung ab, die jemand vorher in die pipeline geschrieben hat. Die Keynote des dbt Summit liegt vier Wochen zurück, aber das Nachfolgematerial kam auch diese Woche weiter herein: die Pricing-Erklärung von dbt Labs zu dbt State, ein Update des Redshift-Adapters und die Produktnotizen von Fivetran für Oktober. Dazu kamen die Einschätzung von O'Reilly zur KI-Aufsicht und ein Beitrag von KDnuggets zu governed machine learning.

Meine These: KI-Autonomie und Kostendruck stellen dieselbe Forderung, nur aus entgegengesetzten Richtungen. Für einen CDO sind der Budget-Case und der Case für vertrauenswürdige KI jetzt ein und dieselbe Aufgabe: deklarierte Metadaten (Definitionen, Owner, Freshness-Toleranzen, Tests), die in den Transformation Layer geschrieben werden. Teams, die das als Dokumentation behandeln, bekommen weder die Compute-Einsparungen noch Agents, denen sie vertrauen können.

Mit dbt v2 und der GA von dbt State werden übersprungene Rebuilds zum bepreisten Produkt

Hier die Fakten, alle aus der Mitteilung des Anbieters selbst. Fivetran + dbt Labs hat am 16. September in Las Vegas die allgemeine Verfügbarkeit von dbt v2 und dbt State angekündigt. Fivetran + dbt Labs verkauft Tools für Ingestion und Transformation, behandeln Sie also jede der folgenden Performance-Angaben als Herstelleraussage. Laut Unternehmen ist dbt v2 eine komplette Neuentwicklung der dbt-Engine in Rust, gebaut für die Größenordnung, in der Teams heute arbeiten, und für die Art, wie Agents SQL schreiben. Ein Projekt mit 10.000 Modellen soll bis zu 10x schneller geparst werden als mit v1. Rittman Analytics, eine Beratung, die über das Event berichtet hat, schreibt, dass in der Partner-Keynote Werte von 6,5x bis 9x bei vergleichbaren Läufen aus internen Tests genannt wurden. Rechnen Sie in der Praxis also mit weniger als 10x. Die Governance-Nachricht fällt leiser aus: Mit diesem Release endet die Zeit der zwei Engines Core und Fusion, beide bleiben unter Apache 2.0 lizenziert und erhalten weiter Security-Support.

Für einen CDO ist dbt State wichtiger. Es prüft Warehouse-Metadaten und das SQL der Modelle, ermittelt, ob sich das Ergebnis tatsächlich ändern würde, und baut dann, überspringt, klont oder macht ein Auto-Defer auf Produktion. Die Kundenaussagen, alle von dbt Labs veröffentlicht, sehen so aus:

  • Gordon Curzon von Virgin Media O2 schreibt dem Tool 25 % Einsparung sowohl bei der Job-Laufzeit als auch bei den BigQuery-Compute-Kosten zu.
  • Bei CarGurus sank der Compute-Verbrauch um 9 %, bei 35 % weniger gebauten Modellen.
  • Das Team von RxBenefits hat die Kosten für geplante Jobs auf der dbt-Plattform mit einem adaptiven Snowflake-Warehouse um 59 % gesenkt.

Die nützlichste Zahl ist die, die der Anbieter nicht in die Schlagzeile gesetzt hat. Bei Fanatics Betting and Gaming ergab dbt State ohne jede Konfiguration eine Reuse-Rate von etwa 0,2 %, also praktisch nichts. Wirksam wurde es erst, nachdem das Team Source Freshness konfiguriert und SLAs auf Modellebene deklariert hatte. Damit stieg der Pilot von 0,2 % auf rund 15 % Model Reuse. Das Tool hat sich erst gelohnt, als das Team festgelegt hatte, was „frisch genug“ bedeutet.

Rechenbeispiel: Trägt sich die Reuse-Gebühr selbst?

Das Pricing ist öffentlich. dbt State berechnet 0,094 $ pro täglich aktiver Zieltabelle, wobei jeder Test als eigene Zieltabelle zählt. Ein Modell mit zwei Spaltentests kostet also 0,282 $ für jeden Tag, an dem es wiederverwendet wird, egal wie viele Läufe es an diesem Tag wiederverwenden.

Ein hypothetisches Beispiel, reine Arithmetik. Nehmen wir ein Projekt mit 200 Modellen mit je zwei Tests: 600 Zieltabellen. Bei den 15 % Reuse, die Fanatics erreicht hat, sind das 90 wiederverwendete Tabellen pro Tag, also 8,46 $ pro Tag oder etwa 254 $ in einem Monat mit 30 Tagen. Nehmen wir weiter an, dass 8.000 $ Warehouse-Compute pro Monat auf dbt-Jobs entfallen. Mit den 9 % von CarGurus sparen Sie 720 $ und behalten netto etwa 466 $. In der Spanne von 15 bis 30 %, die der Anbieter bewirbt, sparen Sie 1.200 $ bis 2.400 $. Weil die Gebühr an Reuse gekoppelt ist, kostet ein unkonfiguriertes Deployment fast nichts und spart fast nichts. Die eigentlichen Kosten liegen in der Engineering-Zeit, die für das Deklarieren von Freshness draufgeht. Beachten Sie außerdem, dass testlastige Projekte pro wiederverwendetem Modell mehr zahlen und dass dbt State Python-Modelle zwar baut, aber nicht wiederverwendet.

Das ist eine Entscheidung für Ihre Data-FinOps-Praxis, nichts, was man auf einer Folie abnickt. Testen Sie es in Ihrem am stärksten überplanten Projekt, wo Fanatics die größten Reuse-Gewinne fand, und nutzen Sie die kostenlose Testphase zum Messen. Dieselbe Logik, nicht zweimal für dieselben Bytes zu zahlen, findet sich in einem weiteren Beitrag von dbt Labs diese Woche: dbt kann Modelle jetzt über Redshift-Data-Warehouses hinweg materialisieren, ohne Daten zu kopieren, und der Adapter ist von den alten Postgres-Metadaten-APIs auf Redshift-native SVV_*-Systemviews und SHOW-APIs umgestiegen. Redshift-Shops sollten das testen. Alle anderen können es auslassen.

Was ist ein Context Layer, und braucht ein CDO schon einen?

Ein Context Layer ist ein gesteuerter Speicher für Definitionen, Metadaten und Geschäftswissen, den ein Agent liest, bevor er antwortet. Die meisten CDOs brauchen die Definitionen jetzt und können mit dem Produkt warten. Die Version von Fivetran vereint laut Pressemitteilung des Anbieters die Daten und Metadaten, die nötig sind, um LLMs und AI Agents relevanten Kontext zu geben. Sie baut auf dem strukturierten Kontext von dbt auf und ergänzt unstrukturiertes Wissen wie Dokumente und Slack-Threads. Bemerkenswert ist die Designentscheidung für Offenheit. Fivetran sagt, das Produkt publiziere in ein Agents Schema: offene, einfache SQL-Tabellen in Ihrem eigenen Warehouse, die jedes KI-Tool abfragen kann. Zum Pitch gehören Funktionen, die „Umsatz“ auf genau einen gesteuerten Datensatz auflösen, unter mehreren, die diesen Namen beanspruchen, sowie Metadaten-Connectoren, die aus dem dbt Semantic Layer und aus Quellen wie Looker, Sigma und Power BI ziehen.

Lassen Sie sich vom Anbieter den Status verbindlich nennen. Die Pressemitteilung spricht von Private Beta. Der eigene Ankündigungsblog von Fivetran sagt, es sei jetzt in Limited Public Preview. Egal welches Label Sie nehmen, es ist ein Early-Access-Produkt. Daneben steht dbt Charts in der Public Beta: dashboards als YAML, versioniert direkt neben den Modellen, von denen sie abhängen, sodass Charts, die ein Agent entwirft, durch denselben Pull Request gehen können wie das SQL.

Der beste unabhängige Kommentar kam von Praktikern. Mark Rittman sieht den richtigen Context Layer vor allem als Frage der Hygiene und weniger als Technologiekauf. Wer bereits dimensionale Modelle und einen Semantic Layer über seinen Gold-Tabellen hat, für den bleibt nur noch die Technologiewahl. Ein anderer Bericht nach dem Summit schrieb, man werde die gemeinsame Context-Layer-Initiative von Fivetran + dbt misstrauisch im Auge behalten. Mein Rat: Kaufen Sie noch nichts. Nehmen Sie Ihre zehn wichtigsten Kennzahlen und schreiben Sie jede als gesteuerte Metrikdefinition auf. DailyRevOps listet die Felder gut auf: semantischer Name, Business Owner, Quellmodelle, Granularität, Filter, Zeitbasis, Währungs- oder Einheitenregeln, Freshness-Erwartung und bekannte Ausschlüsse. Jeder Context Layer, den Sie später kaufen, ist nur so gut wie diese Einträge.

KI-Aufsicht bleibt freiwillig, also landet die Prüfbarkeit bei der pipeline

In der aktuellen Ausgabe von This Week in AI berichtete O'Reilly, dass die Trump-Regierung eine freiwillige Vereinbarung mit großen KI-Unternehmen angekündigt hat. Sie sieht internes Safety-Monitoring, externe Audits und unabhängige Board-Reviews vor, ohne rechtliche Durchsetzung. Gleichzeitig hat die Federal Trade Commission eine Untersuchung gegen OpenAI, Anthropic und weitere KI-Unternehmen eingeleitet, die sich auf mögliche Risiken für Verbraucher konzentriert. Die Hosts von O'Reilly folgern, dass Teams Governance-Praktiken brauchen, die einer Prüfung von außen standhalten.

Für einen CDO heißt das praktisch: Niemand wird Ihnen eine Compliance-Checkliste für Agents in die Hand drücken, Sie müssen also selbst Rechenschaft ablegen können. KDnuggets hat am 8. Oktober das Engineering-Argument geliefert: Enterprise-KI-Teams können es sich nicht leisten, Governance als letzten Compliance-Check zu behandeln. Die Anforderungen gehören von Anfang an in die Auswahl der Trainingsdaten und in das Modellverhalten.

Ein Beitrag von dbt Labs, der zum Teil gegen Transformationslogik innerhalb von Databricks argumentiert, stellt die Audit-Frage schärfer. Das ist Wettbewerbspositionierung, lesen Sie es entsprechend. Der Test hält trotzdem: Wenn Ihr CFO fragt, warum der Umsatz für Q3 korrigiert wurde, braucht man zur Nachverfolgung Zugriff auf die Databricks-Plattform statt eines git diff. Der Beitrag zitiert außerdem eine Zahl von Databricks selbst aus der Übernahme von Neon im Mai 2025: Über 80 % der Datenbanken auf der Plattform wurden von AI Agents angelegt und nicht von Menschen. Die Zahl ist anderthalb Jahre alt und betrifft eine Plattform, zeigt aber, wohin die Entwicklung geht. Wenn Agents Modelle schreiben, ist die sichtbare Versionshistorie Ihrer Definitionen der Audit Trail. Hier muss nichts gekauft werden. Machen Sie die unten beschriebene Übung.

Warum das Modellieren für den Token wichtiger ist als der Context Layer

Das unterschätzte Thema der Woche ist ein Blogbeitrag von dbt Labs über die eigene interne Infrastruktur, also Selbstauskunft. Als Mitarbeiter anfingen, Claude über einen API-Wrapper auf Gong-Gesprächsdaten anzusetzen, verbrauchte eine einzige Abfrage zur Account-Historie 8.300 Tokens pro Gesprächstranskript, rund 240.000 Tokens im Kontext für die Historie eines Accounts mit ~30 Gesprächen, und lief in die Rate Limits von Gong. Die Lösung war gewöhnliche Datenarbeit. Fivetran hatte Gong bereits nach Snowflake geladen, also modellierte und fasste das Team die Transkripte dort zusammen und stellte sie über den dbt MCP Server bereit. Das aktive Komprimieren der Transkripte verringerte das Datenvolumen um das 20-Fache oder mehr und drückte ein 60-minütiges Gespräch von über 10.000 Tokens auf wenige Hundert.

Unterschätzt ist das, weil es die KI-Stückkosten auf die Seite des Datenteams verschiebt. Die meisten Unternehmen budgetieren Tokens als Posten des Modellanbieters, und der Einkauf verhandelt den Preis pro Million. Dieser Fall zeigt, dass das Volumen pro Antwort davon abhängt, wie die Daten modelliert wurden, bevor sie ins Kontextfenster kamen, und das kann einen Unterschied vom Faktor 20 ausmachen. Ein Context Layer, der noch im Early Access steckt, repariert kein rohes Transkript, das direkt an einen Agent geht. Ein dbt-Modell, das es zusammenfasst, schon, und zwar heute, mit Tools, die die meisten Teams bereits haben.

Das Deklarations-Gate: eine Regel für die Automatisierung jedes Modells

Schreiben Sie das ans Whiteboard: Kein Scheduler, kein Agent und kein dashboard darf auf ein Modell zugreifen, das keinen benannten Owner, keine schriftliche Definition, keine Freshness-Toleranz und nicht mindestens einen Test hat.

Jeder Fehlermodus dieser Woche geht auf eine fehlende Deklaration zurück. Ohne Freshness-Toleranzen hat dbt State bei Fanatics nichts wiederverwendet. Ohne Definitionen rät ein Agent, welcher Umsatztabelle er trauen soll. Ohne versionierte Logik wird die Frage des CFO aus dem Gedächtnis beantwortet. Ohne modellierte Form der Daten wächst die Token-Rechnung mit jeder gestellten Frage. Wenden Sie das Gate Modell für Modell an und beginnen Sie mit dem, was Ihre Agents zuerst anfassen.

Was Sie am Montag tun sollten

  • Exportieren Sie 30 Tage dbt-Job-Historie und zählen Sie die Modelle, die neu gebaut wurden, obwohl sich weder Upstream-Daten noch Code geändert hatten. Diese Zahl ist Ihr Business Case für dbt State oder Ihr Grund, darauf zu verzichten.
  • Rechnen Sie die DATT-Kalkulation von oben mit Ihren eigenen Modell- und Testzahlen durch, bevor eine Testphase beginnt, und markieren Sie alle Python-Modelle, da diese nicht wiederverwendet werden.
  • Wählen Sie die zehn Kennzahlen, nach denen Ihre KI-Piloten am wahrscheinlichsten gefragt werden, und füllen Sie für jede die Vertragsfelder von DailyRevOps aus, mit einem benannten Business Owner.
  • Machen Sie die CFO-Übung: Nehmen Sie den am stärksten korrigierten KPI des letzten Quartals und stoppen Sie, wie lange es dauert, die Änderung allein aus der Versionskontrolle zu erklären.
  • Fragen Sie den Owner Ihres größten KI-Use-Cases nach den Tokens pro Antwort und finden Sie heraus, wo unmodellierte Quelldaten ins Kontextfenster gelangen.
  • Wenn Sie den Fivetran Context Layer evaluieren, lassen Sie sich Release-Status und Preisbasis schriftlich geben, angesichts der widersprüchlichen Labels.

Die Zahl von Fanatics gehört in Ihren nächsten Lenkungsausschuss. Das bloße Einschalten des Tools brachte eine Reuse-Rate von 0,2 %, das Deklarieren von Freshness und SLAs hob sie auf rund 15 %. Agents werden sich genauso verhalten: Sie können nur die Bedeutung nutzen, die Ihr Team bereits in der pipeline deklariert hat.

Mehr dazu

Die Lektionen, die diesen Artikel weiterführen, frei zugänglich.

  1. 1dbt (data build tool): industrialisierte SQL-TransformationModerne Datenarchitektur
  2. 2Der Metrics- und Semantic LayerAnalytics, BI & Decision Intelligence
  3. 3Active Metadata und der Data CatalogModerne Datenarchitektur
  4. 4Data FinOps: Cloud-Datenkosten im GriffModerne Datenarchitektur
  5. 5Shift-left Data Quality: Governance in der Engineering-Pipeline verankernData Governance & Compliance

Sources

Artikel gelesen?

Bestätigen Sie Ihre Lektüre, um XP zu sammeln und Ihr Radar zu füttern.