Utilizza competenze riutilizzabili, pattern medallion e definizioni condivise per distribuire più rapidamente pipeline coerenti e pronte per la produzione.
Daikin Applied Americas (DAA) produce e gestisce sistemi HVAC commerciali in tutto il Nord America. Ciò significa gestire grandi volumi di dati operativi, di produzione e di servizio tra i vari sistemi, dalla telemetria delle apparecchiature e i dati della supply chain ai registri di assistenza sul campo.
Il team dei dati supporta casi d'uso di analytics e AI nei settori dell'ingegneria, delle operazioni e del servizio clienti, tutti dipendenti da pipeline affidabili e ben strutturate.
Con l'aumentare di queste richieste, è cresciuta anche la pressione sul team dei dati, con un numero maggiore di pipeline, più casi d'uso e un maggiore coordinamento tra i team. Per affrontare questo problema, il team ha definito un modello operativo più strutturato per la progettazione, la creazione e la governance delle pipeline, e ha utilizzato Databricks Genie Code per accelerare l'esecuzione all'interno di questo modello.
Il team ha sfruttato Genie Code come approccio assistito dall'AI al data engineering. Lavorare direttamente sui dati controllati in Unity Catalog può aiutare a pianificare e generare pipeline multi-step in tutto il flusso di lavoro. Ciò consente agli ingegneri di passare da un'idea a una pipeline funzionante molto più velocemente, senza cambiare strumenti o unire manualmente i componenti.
Questa velocità ha cambiato radicalmente il modo di lavorare del team. Le pipeline che in precedenza richiedevano giorni per essere prototipate potevano essere generate in pochi minuti. I cicli di iterazione sono stati abbreviati e gli ingegneri hanno dedicato meno tempo alla scrittura di codice boilerplate e più tempo a perfezionare la logica e i risultati.
Allo stesso tempo, operare in un ambiente di dati condiviso e di grandi dimensioni richiede coerenza. Le pipeline devono seguire pattern architetturali comuni, utilizzare definizioni condivise e comportarsi in modo prevedibile tra i vari team.
I modelli linguistici di grandi dimensioni introducono una sfida strutturale in questo contesto. Quando i team si affidano a prompt diversi o a istruzioni definite in modo approssimativo, la stessa richiesta può produrre output incoerenti e portare a una deriva architetturale nel tempo.
Per affrontare questo problema, il team DAA si è concentrato sulla definizione di come l'AI dovrebbe operare all'interno di un ambiente aziendale regolamentato, anziché affidarsi esclusivamente al prompt engineering.
Come afferma Trent Lezer, Sr. Director, Data & Analytics presso Daikin Applied Americas: "Genie Code funziona al meglio se trattato come un ingegnere junior che lavora velocemente ma deve rispettare gli stessi vincoli architetturali di tutti gli altri, senza esenzioni speciali 'perché è AI'."
L'uso iniziale di Genie Code seguiva un pattern familiare: prompt lunghi che tentavano di codificare regole di architettura, standard di denominazione, logica di trasformazione e requisiti di documentazione in un unico blocco di testo.
Questo approccio non era scalabile. Le istruzioni variavano da un team all'altro, i prompt diventavano difficili da gestire e attività simili producevano output incoerenti.
Per risolvere questo problema, il team ha introdotto un framework di competenze MECE (Mutually Exclusive, Collectively Exhaustive). Come spiega Trent: "Abbiamo implementato un framework di competenze MECE: ogni competenza definisce una capacità coerente, le competenze non si sovrappongono e l'insieme completo copre l'intero ciclo di vita del lavoro di data engineering".
Ogni competenza definisce una capacità specifica nel ciclo di vita del data engineering. Insieme, le competenze non si sovrappongono e coprono l'intero flusso di lavoro. Queste competenze includono la progettazione dell'architettura medallion, la conformità delle sorgenti e la definizione della granularità, i pattern di trasformazione, l'allineamento canonico e gli standard di governance.
Invece di inserire le regole all'interno dei prompt, il team ha strutturato l'ambiente in modo che Genie Code carichi le competenze appropriate a runtime e le applichi durante la pianificazione e l'esecuzione. Questo sposta il comportamento dall'interpretazione di istruzioni ad hoc al funzionamento all'interno di un modello di esecuzione definito.
Dal punto di vista della governance, questo cambia anche il modo in cui vengono applicati gli standard. Come osserva James VanGordon, Solutions Architect presso Databricks, "Il pattern che continuo a vedere con Genie Code è piuttosto semplice: i prompt ti aiutano a iniziare, ma non sono il posto adatto per applicare gli standard del team. Se la stessa regola è importante più di una volta, dovrebbe risiedere nell'area di lavoro come competenza, dove Genie Code può effettivamente utilizzarla".
Sottolinea inoltre l'importanza di integrare gli standard direttamente nell'ambiente di esecuzione: "Questo è ciò che rende tutto questo reale anziché un pio desiderio. Le competenze, il contesto di Unity Catalog e Genie Code lavorano nello stesso posto. La guida si trova dove viene creato il lavoro, non da un'altra parte in un processo di revisione che qualcuno deve ricordarsi di fare in un secondo momento".
Il team ha anche rafforzato il ruolo dell'architettura medallion sia come framework di governance che di ragionamento. I livelli Bronze, Silver e Gold esistevano già, ma il cambiamento è consistito nel renderli confini decisionali espliciti durante la generazione delle pipeline, e non solo livelli di archiviazione.
Bronze rappresenta la sorgente dei dati grezzi. Silver rappresenta i dati puliti e conformati. Gold rappresenta gli analytics pronti per il business.
Per rendere operativa questa struttura, il team ha introdotto dei checkpoint tra i livelli. Prima che i dati avanzino, devono essere soddisfatti requisiti come la definizione della granularità della sorgente, la convalida dei join e i controlli di stabilità dei dati.
Questi checkpoint vengono applicati all'interno dello stesso flusso di lavoro di sviluppo, non come passaggi di revisione a valle. Genie Code opera all'interno di questi vincoli man mano che le pipeline vengono generate e modificate.
Ciò garantisce la coerenza tra i team, riducendo al contempo il rischio di scorciatoie architetturali durante lo sviluppo rapido.
Una sfida ricorrente nel data engineering aziendale è l'allineamento dei modelli tecnici con il linguaggio di business.
In DAA, gli stakeholder pensano in termini di apparecchiature, clienti, eventi di servizio e contratti, non di tabelle, join o trasformazioni.
Per affrontare questo problema, il team ha ancorato la progettazione delle pipeline a entità aziendali stabili. Invece di iniziare con strutture tecniche, gli ingegneri iniziano identificando cosa rappresentano i dati e come si comportano nel tempo.
Questo cambiamento migliora le attività a valle e riduce l'ambiguità quando i dataset vengono riutilizzati in domini diversi.
Nel tempo, i modelli del livello Silver e i dataset Gold diventano più coerenti perché si basano su concetti di business condivisi anziché su decisioni tecniche isolate.
Con questo modello operativo attivo e l'AI integrata, il team ha visto un chiaro cambiamento nel modo in cui veniva eseguito il lavoro.
Lo sviluppo delle pipeline ha subito un'accelerazione, in particolare durante le prime fasi di esplorazione e iterazione. Gli ingegneri hanno dedicato meno tempo alla scrittura di codice boilerplate e più tempo al perfezionamento della logica di business.
Anche gli output sono diventati più coerenti tra i vari team. Casi d'uso simili hanno seguito pattern strutturali simili, migliorando la manutenibilità e il riutilizzo.
Inoltre, è aumentata la fiducia negli output generati. Gli ingegneri hanno dedicato meno tempo alla convalida della correttezza strutturale e hanno potuto iterare più rapidamente.
Per rendere ripetibili questi vantaggi, il team ha standardizzato le decisioni chiave all'interno del processo di sviluppo.
Invece di affidarsi a conoscenze implicite, le definizioni sono state rese esplicite, incluso ciò che si qualifica come dati Bronze, Silver e Gold, come viene definita la granularità della sorgente, quali pattern di trasformazione sono riutilizzabili e come vengono rappresentate le entità aziendali. Questa struttura è stata fondamentale per la scalabilità. Garantisce che l'AI operi all'interno di un framework coerente tra i vari team, anche con l'evolversi dei casi d'uso.
Il risultato di questo modello operativo non è stato solo la creazione di pipeline più veloci. È stata la capacità di scalare il data engineering in un ambiente aziendale regolamentato.
Gli ingegneri dedicano meno tempo alla correzione di pipeline strutturalmente errate e più tempo al perfezionamento della logica e dei risultati di business.
L'applicazione coerente delle competenze e dei checkpoint di governance previene la divergenza tra i team che lavorano su sfide di dati simili.
Basare le pipeline su concetti di business migliora la chiarezza e riduce le rilavorazioni a valle.
I guardrail sono integrati direttamente nel sistema, riducendo la dipendenza dall'applicazione manuale.
Poiché le competenze e i checkpoint definiti vincolano gli output, l'AI opera in modo affidabile all'interno dei flussi di lavoro di produzione.
As Trent riassume: "L'obiettivo non è far sì che l'AI segua più regole. È rendere impossibile ignorare le regole giuste".
Presso Daikin Applied Americas, la combinazione di un modello operativo strutturato con lo sviluppo assistito dall'AI ha consentito al team dei dati di scalare più rapidamente mantenendo coerenza, chiarezza e controllo.
Definendo come dovrebbero essere create le pipeline e integrando tali regole direttamente nell'ambiente di sviluppo, le due cose si rafforzano a vicenda anziché escludersi.
Scopri di più su Genie Code.
(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale
Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.