Durch die Nutzung wiederverwendbarer Fähigkeiten, Medaillon-Muster und gemeinsamer Definitionen lassen sich konsistente, produktionsbereite Pipelines schneller bereitstellen.
von Trent Lezer und James VanGordon
Daikin Applied Americas (DAA) fertigt und wartet gewerbliche HVAC-Systeme in ganz Nordamerika. Das bedeutet die Verwaltung großer Mengen an Betriebs-, Fertigungs- und Servicedaten über verschiedene Systeme hinweg – von der Gerätetelemetrie und Lieferkettendaten bis hin zu Außendienstprotokollen.
Das Datenteam unterstützt Analytics- und AI-Anwendungsfälle in den Bereichen Engineering, Betrieb und Kundenservice, die alle auf zuverlässige, gut strukturierte Pipelines angewiesen sind.
Mit steigenden Anforderungen wuchs auch der Druck auf das Datenteam – durch mehr Pipelines, mehr Anwendungsfälle und mehr Abstimmung zwischen den Teams. Um dem zu begegnen, definierte das Team ein strukturierteres Betriebsmodell für das Design, den Aufbau und die Governance von Pipelines und nutzte Databricks Genie Code, um die Ausführung innerhalb dieses Modells zu beschleunigen.
Das Team nutzte Genie Code als AI-gestützten Ansatz für das Data Engineering. Die direkte Arbeit mit kontrollierten Daten in Unity Catalog hilft bei der Planung und Erstellung mehrstufiger Pipelines im gesamten Workflow. So können Engineers viel schneller von der Idee zur funktionierenden Pipeline gelangen, ohne die Tools wechseln oder Komponenten manuell zusammenfügen zu müssen.
Diese Geschwindigkeit hat die Arbeitsweise des Teams grundlegend verändert. Pipelines, deren Prototyping früher Tage dauerte, konnten nun in Minuten erstellt werden. Die Iterationszyklen wurden verkürzt, und die Engineers verbrachten weniger Zeit mit dem Schreiben von Boilerplate-Code und mehr Zeit mit der Verfeinerung von Logik und Ergebnissen.
Gleichzeitig erfordert die Arbeit in einer großen, gemeinsam genutzten Datenumgebung Konsistenz. Pipelines müssen gemeinsamen Architekturmustern folgen, einheitliche Definitionen verwenden und sich teamübergreifend vorhersehbar verhalten.
Große Sprachmodelle bringen in diesem Kontext eine strukturelle Herausforderung mit sich. Wenn Teams sich auf unterschiedliche Prompts oder vage definierte Anweisungen verlassen, kann dieselbe Anfrage zu inkonsistenten Ergebnissen führen und im Laufe der Zeit zu einer architektonischen Abweichung führen.
Um dies zu beheben, konzentrierte sich das DAA-Team darauf, zu definieren, wie AI in einer kontrollierten Unternehmensumgebung agieren soll, anstatt sich nur auf Prompt Engineering zu verlassen.
Trent Lezer, Sr. Director, Data & Analytics bei Daikin Applied Americas, drückt es so aus: „Genie Code funktioniert am besten, wenn man es wie einen Junior-Engineer behandelt, der schnell arbeitet, aber dieselben architektonischen Einschränkungen wie alle anderen einhalten muss – keine Sonderregelungen, ‚nur weil es AI ist‘.“
Die frühe Nutzung von Genie Code folgte einem bekannten Muster: lange Prompts, die versuchten, Architekturregeln, Namensstandards, Transformationslogik und Dokumentationsanforderungen in einem einzigen Textblock zu kodieren.
Dieser Ansatz war nicht skalierbar. Die Anweisungen unterschieden sich von Team zu Team, Prompts wurden schwer zu pflegen und ähnliche Aufgaben führten zu inkonsistenten Ergebnissen.
Um dem entgegenzuwirken, führte das Team ein MECE-Skill-Framework (Mutually Exclusive, Collectively Exhaustive) ein. Trent erklärt: „Wir haben ein MECE-Skill-Framework implementiert. Jeder Skill definiert eine zusammenhängende Kompetenz, die Skills überschneiden sich nicht und das gesamte Set deckt den kompletten Lebenszyklus der Data-Engineering-Arbeit ab.“
Jeder Skill definiert eine bestimmte Fähigkeit im Data-Engineering-Lebenszyklus. Zusammen überschneiden sich die Skills nicht und decken den gesamten Workflow ab. Zu diesen Skills gehören das Design der Medallion-Architektur, die Quellbereitschaft und Granularitätsdefinition, Transformationsmuster, kanonische Ausrichtung und Governance-Standards.
Anstatt Regeln in Prompts einzubetten, strukturierte das Team die Umgebung so, dass Genie Code die entsprechenden Skills zur Laufzeit lädt und sie bei der Planung und Ausführung anwendet. Dies verlagert das Verhalten von der Interpretation von Ad-hoc-Anweisungen hin zur Arbeit innerhalb eines definierten Ausführungsmodells.
Aus Governance-Perspektive ändert dies auch die Art und Weise, wie Standards durchgesetzt werden. James VanGordon, Solutions Architect bei Databricks, stellt fest: „Das Muster, das ich bei Genie Code immer wieder sehe, ist ziemlich einfach: Prompts helfen beim Einstieg, sind aber ein schlechter Ort, um Teamstandards durchzusetzen. Wenn dieselbe Regel mehr als einmal wichtig ist, sollte sie als Skill im Workspace liegen, wo Genie Code sie tatsächlich nutzen kann.“
Er betont auch die direkte Einbettung von Standards in die Ausführungsumgebung: „Das ist es, was die Sache real macht und nicht nur zu Wunschdenken. Die Skills, der Unity Catalog-Kontext und Genie Code arbeiten am selben Ort. Die Anleitung befindet sich dort, wo die Arbeit entsteht, und nicht abseits in einem Review-Prozess, an den sich später jemand erinnern muss.“
Das Team stärkte auch die Rolle der Medallion-Architektur sowohl als Governance- als auch als Argumentationsrahmen. Bronze-, Silver- und Gold-Layer existierten bereits, aber die Veränderung bestand darin, sie bei der Pipeline-Erstellung als explizite Entscheidungsgrenzen zu nutzen und nicht nur als Speicherebenen.
Bronze steht für die Rohdatenquelle. Silver steht für bereinigte und angepasste Daten. Gold steht für geschäftsreife Analytics.
Um diese Struktur zu operationalisieren, führte das Team Checkpoints zwischen den Layern ein. Bevor Daten weitergegeben werden, müssen Anforderungen wie die Definition der Quellgranularität, die Join-Validierung und Datenstabilitätsprüfungen erfüllt sein.
Diese Checkpoints werden direkt im Entwicklungs-Workflow durchgesetzt, nicht erst in nachgelagerten Review-Schritten. Genie Code arbeitet innerhalb dieser Einschränkungen, während Pipelines erstellt und geändert werden.
Dies gewährleistet Konsistenz über Teams hinweg und verringert gleichzeitig das Risiko von architektonischen Abkürzungen bei der schnellen Entwicklung.
Eine wiederkehrende Herausforderung im Enterprise Data Engineering besteht darin, technische Modelle mit der Geschäftssprache in Einklang zu bringen.
Bei DAA denken die Stakeholder in Kategorien wie Geräten, Kunden, Serviceereignissen und Verträgen, nicht in Tabellen, Joins oder Transformationen.
Um dem zu begegnen, verankerte das Team das Pipeline-Design in stabilen Geschäftsentitäten. Anstatt mit technischen Strukturen zu beginnen, ermitteln die Engineers zunächst, was die Daten darstellen und wie sie sich im Laufe der Zeit verhalten.
Diese Umstellung verbessert nachgelagerte Prozesse und reduziert Unklarheiten, wenn Datensätze domänenübergreifend wiederverwendet werden.
Im Laufe der Zeit werden Silver-Layer-Modelle und Gold-Datensätze konsistenter, da sie auf gemeinsamen Geschäftskonzepten und nicht auf isolierten technischen Entscheidungen basieren.
Mit diesem Betriebsmodell und der integrierten AI sah das Team eine deutliche Veränderung bei der Arbeitsausführung.
Die Pipeline-Entwicklung beschleunigte sich, insbesondere in der frühen Phase der Exploration und Iteration. Engineers verbrachten weniger Zeit mit dem Schreiben von Boilerplate-Code und mehr Zeit mit der Verfeinerung der Geschäftslogik.
Auch die Ergebnisse wurden teamübergreifend konsistenter. Ähnliche Anwendungsfälle folgten ähnlichen strukturellen Mustern, was die Wartbarkeit und Wiederverwendbarkeit verbesserte.
Wichtig ist auch, dass das Vertrauen in die generierten Ergebnisse gestiegen ist. Engineers verbrachten weniger Zeit mit der Validierung der strukturellen Korrektheit und konnten schneller iterieren.
Um diese Erfolge wiederholbar zu machen, standardisierte das Team wichtige Entscheidungen innerhalb des Entwicklungsprozesses.
Anstatt sich auf implizites Wissen zu verlassen, wurden Definitionen explizit gemacht – einschließlich der Frage, was als Bronze-, Silver- und Gold-Daten gilt, wie die Quellgranularität definiert ist, welche Transformationsmuster wiederverwendbar sind und wie Geschäftsentitäten dargestellt werden. Diese Struktur war entscheidend für die Skalierung. Sie stellt sicher, dass AI auch bei der Weiterentwicklung von Anwendungsfällen innerhalb eines konsistenten Frameworks über Teams hinweg arbeitet.
Das Ergebnis dieses Betriebsmodells waren nicht nur schnellere Pipelines. Es war die Fähigkeit, Data Engineering in einer kontrollierten Unternehmensumgebung zu skalieren.
Engineers verbringen weniger Zeit mit dem Schreiben und Korrigieren fehlerhafter Pipelines und mehr Zeit mit der Verfeinerung von Logik und Geschäftsergebnissen.
Die konsistente Anwendung von Skills und Governance-Checkpoints verhindert Abweichungen zwischen Teams, die an ähnlichen Datenherausforderungen arbeiten.
Die Verankerung von Pipelines in Geschäftskonzepten sorgt für mehr Klarheit und reduziert nachgelagerte Nacharbeiten.
Guardrails sind direkt in das System eingebettet, was die Abhängigkeit von manueller Durchsetzung verringert.
Da definierte Skills und Checkpoints die Ergebnisse einschränken, arbeitet AI zuverlässig in Produktions-Workflows.
Trent fasst zusammen: „Das Ziel ist nicht, AI dazu zu bringen, mehr Regeln zu befolgen. Es geht darum, die richtigen Regeln unumgänglich zu machen.“
Bei Daikin Applied Americas ermöglichte die Kombination aus einem strukturierten Betriebsmodell und AI-gestützter Entwicklung dem Datenteam eine schnellere Skalierung bei gleichzeitiger Wahrung von Konsistenz, Klarheit und Kontrolle.
Durch die Definition, wie Pipelines aufgebaut sein sollten, und die direkte Einbettung dieser Regeln in die Entwicklungsumgebung hat das Team ein System geschaffen, in dem sich Geschwindigkeit und Governance gegenseitig verstärken, anstatt in Konkurrenz zueinander zu stehen.
Erfahren Sie mehr über Genie Code.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.