Databricks

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 1 di 15. Per anni, le aziende hanno pagato due volte per salvare esattamente gli stessi dati, solo per accontentare sia i loro machine learning engineer che i loro business analyst. Salvare raw data in un sistema e copiarli in un altro crea infiniti problemi di sincronizzazione. Databricks risolve questo problema introducendo un approccio unificato chiamato Data Lakehouse. Storicamente, le organizzazioni hanno suddiviso la propria data architecture in due percorsi separati. Per prima cosa, hanno creato i Data Lake. Sono sistemi di cloud storage economici e altamente scalabili, perfetti per riversare enormi quantità di unstructured data. I data scientist li adorano per addestrare i modelli di machine learning. Ma i Data Lake sono pessimi per query SQL veloci e affidabili. Per risolvere questo problema, le aziende hanno introdotto i Data Warehouse per i loro team di business intelligence. Questo crea un carico operativo enorme. Prendi come esempio una startup in crescita. I loro data engineer riversano i raw event log in un cloud storage bucket. Lì eseguono i loro script Python. Ma il team finance ha bisogno di dashboard. Quindi, gli engineer devono costruire pipeline complesse per estrarre quei dati, trasformarli e caricarli in un data warehouse separato. L'azienda paga due volte per lo storage. Paga per il compute necessario a spostare i dati. E nel momento in cui i dati arrivano nel warehouse, sono già vecchi. Databricks elimina completamente questa pipeline con l'architettura Data Lakehouse. Un Lakehouse combina lo storage economico e flessibile di un data lake con l'affidabilità e le performance di un data warehouse. Mantiene i tuoi dati in un unico formato aperto, direttamente nel tuo cloud storage. Non devi copiarli in un database proprietario. Invece, Databricks aggiunge un transactional layer direttamente sopra il tuo data lake esistente. Ecco il punto chiave. I tuoi dati restano in un unico posto, ma i diversi professionisti ci interagiscono esattamente come serve a loro. I data scientist possono scrivere in Python o Scala per addestrare i modelli direttamente sui file raw. Allo stesso tempo, i business analyst possono eseguire query SQL ad alte performance esattamente sugli stessi dati per alimentare i loro tool di reporting. Spesso le persone pensano per errore che Databricks sia solo un altro database SQL o semplicemente un managed wrapper attorno ad Apache Spark. Non è nessuna delle due cose. È una Data Intelligence Platform completa. Unendo il lake e il warehouse, unisci anche la security e la governance. Nel vecchio modello, dovevi gestire i permessi di accesso nel cloud storage per gli engineer, e separatamente nel data warehouse per gli analyst. Con Databricks, un governance layer unificato gestisce il controllo degli accessi per ogni tabella, file e modello di machine learning. Definisci una data access policy una volta sola, e si applica ovunque, indipendentemente dal linguaggio o dal tool usato per fare le query. La vera potenza dell'architettura Lakehouse non è solo risparmiare soldi sulle pipeline di storage ridondanti; è che i tuoi modelli di intelligenza artificiale e le tue dashboard finanziarie stanno finalmente guardando esattamente gli stessi numeri, esattamente nello stesso momento. Se vuoi aiutare a portare avanti lo show, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 2 di 15. Se la tua azienda utilizza più workspace per elaborare i dati, probabilmente hai diversi punti in cui gestisci i permessi di sicurezza. Questa frammentazione rappresenta un enorme rischio di compliance, perché mantenere le policy sincronizzate tra ambienti disconnessi si basa interamente su aggiornamenti manuali. Unity Catalog elimina questo rischio cambiando radicalmente come funziona la data governance in Databricks. Prima di spiegarne i meccanismi, dobbiamo chiarire un equivoco molto comune. Unity Catalog non è un data dictionary passivo. Non è solo un elenco di tabelle dove gli utenti vanno a leggere le descrizioni. È il policy engine centrale che applica attivamente le regole di sicurezza in tutta la tua architettura. Unity Catalog risolve il problema persistente di sapere esattamente chi ha accesso a cosa. Fornisce un modello di sicurezza unificato basato sullo standard ANSI SQL. Invece di configurare separatamente i ruoli di cloud identity, i permessi a livello di workspace e gli access control a livello di cluster, usi comandi familiari come grant e revoke direttamente sui tuoi dati e sui tuoi asset di AI. Dato che Unity Catalog si trova a livello di account, anziché essere vincolato a un singolo workspace, definisci una regola di sicurezza una volta sola. Quella regola viene poi applicata istantaneamente e universalmente a tutti i workspace collegati a quel catalogo. Immagina una situazione in cui un auditor chiede a un Chief Technology Officer di dimostrare esattamente chi ha eseguito una query su una specifica tabella contenente numeri di carte di credito martedì scorso, e di identificare ogni report downstream che attualmente utilizza quei numeri. Storicamente, rispondere a questa domanda significava fare il parsing dei log di sistema frammentati tra diversi tool, leggere manualmente i job di trasformazione schedulati e sperare di non aver saltato nessuno step intermedio. Unity Catalog gestisce tutto questo nativamente attraverso i suoi prossimi due pilastri: l'auditing built-in e la lineage automatizzata. Per prima cosa, cattura audit log dettagliati a livello utente out of the box. Ogni volta che un utente o un service principal accede ai dati, il catalogo registra l'evento. Ecco il punto chiave. Unity Catalog non si limita a tracciare chi ha eseguito una query su una tabella; traccia cosa succede ai dati subito dopo attraverso la lineage automatizzata. Mentre le tue pipeline schedulate vengono eseguite, il sistema legge continuamente gli execution plan e costruisce una mappa di come fluiscono i dati. Traccia quali tabelle sorgente alimentano quali dataset intermedi, fino ad arrivare alle dashboard finali. Traccia tutto questo sia a livello di tabella che a livello di colonna. Quando l'auditor ti fa domande sui dati delle carte di credito, non devi tirare a indovinare. Guardi il lineage graph e vedi all'istante ogni step di trasformazione e ogni punto di accesso. L'ultimo pilastro fondamentale è il data sharing sicuro. Le organizzazioni spesso hanno bisogno di condividere dataset con vendor esterni o business unit separate. Invece di esportare flat file o duplicare i dati in bucket di cloud storage separati, Unity Catalog integra un protocollo chiamato Delta Sharing. Questo ti permette di concedere a parti esterne un accesso governato ai dati live senza copiarli. Il consumer esterno legge i dati in place, e il suo accesso viene loggato e controllato dall'esatto stesso cervello centrale. Il vero valore di Unity Catalog è che rimuove completamente il pericoloso divario tra lo scrivere una security policy su carta e l'eseguirla effettivamente attraverso data silos isolati. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a costruire!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 3 di 15. Il modo più semplice per bruciare il tuo budget cloud è lasciare un server enorme in funzione a vuoto per tutto il weekend. Vuoi potenza di calcolo esattamente quando ti serve, e zero costi quando non la usi. Questo è esattamente ciò di cui parliamo oggi in Navigating the Workspace and Compute. Il tuo punto di accesso a Databricks è il workspace. Pensa al workspace come all'ambiente unificato in cui il tuo team organizza tutti i propri asset Databricks. Fornisce un'interfaccia web per gestire i tuoi notebook, i data object, gli esperimenti di machine learning e le risorse di compute sottostanti. Il workspace riunisce tutti i tuoi tool collaborativi in un'unica vista organizzata, garantendo che team diversi possano interagire con gli stessi dati sottostanti senza pestarsi i piedi a vicenda. Dietro le quinte, Databricks si basa su un'architettura disaccoppiata. I tuoi dati risiedono in modo persistente nel cloud object storage, mentre la potenza di compute utilizzata per processare quei dati viene avviata in modo completamente separato. Questa separation of concerns determina la tua fatturazione. Dato che il compute è isolato dallo storage, fai il provisioning e paghi per le istanze server solo quando stai attivamente eseguendo del codice. Quando il lavoro è finito, il compute si spegne, ma i tuoi dati rimangono archiviati in modo sicuro e accessibili. Per gestire questa potenza di calcolo, Databricks offre diversi tipi di risorse di compute pensate per workflow specifici. Il primo è un cluster All-Purpose. Lo usi per lavori interattivi e ad-hoc. Metti che un data analyst abbia bisogno di un ambiente ad alte prestazioni per fare una query su un miliardo di righe un martedì pomeriggio. Avvia un cluster All-Purpose, collega il suo notebook e inizia a esplorare. Per evitare sorprese in fattura nel weekend, questi cluster si basano sull'auto-termination. Se l'analista va a casa alle cinque e lascia il notebook aperto, il cluster monitora la propria inattività e si spegne automaticamente dopo un limite di tempo specificato. Ecco il punto chiave riguardo all'automazione. Un errore frequente che fanno i team è schedulare pipeline di produzione automatizzate per farle girare su questi cluster All-Purpose interattivi. Evita di farlo. I cluster All-Purpose hanno un costo di utilizzo più alto, e far girare diversi workflow su un cluster interattivo condiviso può introdurre conflitti di librerie o resource contention. Invece, le pipeline di produzione dovrebbero usare i Job cluster. Un Job cluster è completamente effimero. Quando viene triggerata una pipeline automatizzata, il job scheduler di Databricks fa il provisioning di un Job cluster dedicato strettamente a quel workload. Esegue il codice e, nel secondo esatto in cui il job finisce, il cluster si termina da solo. Questo garantisce un rigoroso isolamento delle risorse per la tua pipeline e ti assicura di pagare la tariffa di compute più bassa possibile per i task automatizzati. Infine, se il tuo workload è puramente analitico, puoi usare un SQL warehouse. Questa è una risorsa di compute ottimizzata specificamente per eseguire comandi SQL e query per le dashboard. Se usi i Serverless SQL warehouse, Databricks gestisce automaticamente il compute sottostante. Fa scale-up all'istante quando arriva un picco di query, e fa scale-down quando la coda si svuota, rimuovendo completamente la necessità di configurare l'infrastruttura da solo. Abbinare il giusto tipo di compute all'esatta natura del tuo task è il modo più efficace in assoluto per garantire che la tua infrastruttura cloud rimanga potente durante le ore di punta e altamente efficiente a livello di costi quando il lavoro è finito. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 4 di 15. Crei un data lake, ma nel giro di pochi mesi nessuno sa dove siano i dati in produzione, di chi siano, o se sia sicuro fare una query su una specifica tabella. La differenza tra un data lake impeccabile e un data swamp ingestibile sta esattamente in tre livelli di profondità. Oggi vediamo come organizzare i tuoi dati: l'Object Model. Unity Catalog mette ordine nei tuoi dati attraverso una gerarchia rigorosa e prevedibile. Il contenitore di livello più alto è il metastore, che contiene i metadata della tua organizzazione. Ma le tue interazioni quotidiane si basano sul namespace primario a tre livelli. Ogni query che scrivi punta a un asset usando il formato catalog punto schema punto object. Il primo livello è il catalog. Questo fornisce un confine ampio per i data asset. Di solito usi i catalog per separare logicamente gli ambienti, ad esempio avendo un catalog per la produzione e uno completamente separato per lo sviluppo. Il secondo livello è lo schema, che viene anche chiamato database. Gli schema si trovano all'interno dei catalog e organizzano i dataset correlati. Potresti creare uno schema per gli eventi raw acquisiti e un altro per le analytics raffinate. Il terzo livello è l'object stesso. Si tratta della tua tabella effettiva, di una view o di un volume che contiene file non tabellari. Imponendo questa naming convention in tre parti, Unity Catalog dà a ogni dato un indirizzo chiaro e inequivocabile. Quando un analista fa una query su production punto sales punto customers, la location, la fase del lifecycle e lo scopo di quei dati sono immediatamente evidenti. Ecco il punto chiave. Una volta arrivato al livello della tabella, devi capire come Unity Catalog interagisce con il tuo storage effettivo. Ci sono due tipi principali di tabelle: managed table ed external table. Le managed table sono il default. Quando crei una managed table, Unity Catalog possiede sia i metadata che i dati sottostanti. Gestisce il layout dei file e l'intero lifecycle dei dati. I file veri e propri vengono salvati in una storage location designata che configuri a livello di metastore, catalog o schema. Le external table funzionano in modo diverso. Usi un'external table quando hai dei file che si trovano già in un bucket di cloud storage e vuoi lasciarli esattamente dove sono. Con un'external table, Unity Catalog registra la struttura e governa l'accesso, ma possiede solo i metadata. Tu mantieni il controllo completo sui file fisici. Questa distinzione diventa fondamentale durante le operazioni distruttive. Immagina uno scenario in cui un data engineer esegue accidentalmente un comando drop table. Se fa il drop di una managed table, Unity Catalog rimuove la tabella dal metastore ed elimina automaticamente i file sottostanti dal tuo cloud storage. I dati vengono distrutti. Se fa il drop di un'external table, Unity Catalog rimuove semplicemente il link ai metadata. La tabella scompare dall'interfaccia del tuo workspace, ma i file raw nel tuo cloud storage rimangono perfettamente intatti e inalterati. Usa sempre le managed table quando vuoi che il catalog ottimizzi e governi l'intero lifecycle dello storage, e riserva le external table per i dati che devi proteggere da cancellazioni accidentali o condividere direttamente con altri sistemi esterni. Grazie per averci fatto compagnia. Spero tu abbia imparato qualcosa di nuovo.

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 5 di 15. Puoi limitare facilmente chi vede una colonna in un database relazionale, ma come fai ad applicare l'access control su un bucket di cloud storage pieno di migliaia di PDF raw? La risposta è: domare i dati non strutturati con i volumi. Prima di vedere come funzionano, chiariamo un malinteso comune. I volumi servono esclusivamente per l'accesso ai file path-based. Non servono per i dati tabellari. Se fai query su righe e colonne con SQL, usi una tabella. Se leggi immagini, documenti di testo o file audio, usi un volume. Un volume è un oggetto all'interno di Unity Catalog. Rappresenta uno spazio di storage logico nel tuo ambiente cloud. Creando un volume, porti i dati non strutturati sotto lo stesso identico ombrello di sicurezza delle tue tabelle strutturate. Invece di gestire le identity policy in AWS o le assegnazioni dei ruoli in Azure solo per leggere un file, controlli l'accesso usando i permessi standard direttamente in Databricks. Prendi un ospedale che addestra un modello di machine learning per rilevare anomalie nelle radiografie. Non possono mettere migliaia di immagini ad alta risoluzione in una tabella di un database. Devono salvarle come file raw in un cloud object storage. Trattandosi di file di pazienti altamente sensibili, una governance rigorosa è fondamentale. Mettendo le radiografie dentro un volume Databricks, il team di engineering può governare esattamente quali data scientist sono autorizzati a leggere quella specifica directory. Ci sono due tipi di volumi: managed ed external. Un volume managed è gestito completamente da Databricks. Quando ne crei uno, non specifichi uno storage path. Databricks ricava semplicemente dello spazio nella storage location di default assegnata al tuo schema corrente. Fai l'upload dei file direttamente al suo interno. Se fai il drop di un volume managed, Databricks elimina anche i file sottostanti. Questo li rende ideali per i file temporanei del workspace o per i dati generati interamente all'interno delle tue pipeline Databricks. Un volume external punta a una directory di cloud storage esistente che già possiedi. Per prima cosa, registri un cloud storage path come external location in Unity Catalog. Poi, ci crei sopra un volume. Questo ti dà una governance rigorosa sui dati prodotti da altri sistemi. Se un'applicazione separata scrive dei file di log in un bucket Azure Data Lake, un volume external permette agli utenti Databricks di leggere quei file in modo sicuro. Se fai il drop di un volume external, i metadati vengono rimossi, ma i file sottostanti nel tuo cloud bucket rimangono completamente intatti. Questo approccio path-based è esattamente ciò che richiede la moderna AI. Le librerie di machine learning open-source in genere si aspettano di leggere i dati da un file system locale. Non sanno come autenticarsi con le interfacce proprietarie di cloud storage. I volumi risolvono questo problema esponendo un directory path che ha l'aspetto e si comporta come una normale cartella locale. Il tuo script di training del modello apre semplicemente un file path. Unity Catalog intercetta quella richiesta e verifica i permessi dell'utente in modo trasparente. Ecco il punto chiave. I volumi eliminano lo scollamento tra come governi i tuoi database strutturati e come metti in sicurezza i tuoi file raw, permettendoti di eseguire workload di machine learning su dati non strutturati senza aggirare la sicurezza enterprise. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 6 di 15. Se i tuoi data engineer continuano a incollare le cloud access key direttamente nei loro script, la tua azienda è a un solo errore da un enorme data breach. La soluzione per collegare in modo sicuro il tuo workspace e il tuo cloud storage senza esporre secret è Bulletproof Cloud Security: le External Location. Quando un utente fa login su Databricks, utilizza un identity token. Quel token dimostra la sua identità al workspace. Ma questa identità non significa assolutamente nulla per il tuo cloud provider sottostante, che si tratti di AWS, Azure o Google Cloud. Per leggere un file da un cloud bucket, il workspace stesso deve autenticarsi con la cloud infrastructure. Storicamente, gli sviluppatori aggiravano questo problema facendo hardcoding delle cloud IAM key direttamente nei loro notebook o nelle environment variable. Questo crea una grave vulnerabilità di sicurezza, poiché chiunque abbia read access al codice può rubare le key. Unity Catalog risolve questo problema attraverso una rigorosa astrazione in due parti. La prima parte è la Storage Credential. Una Storage Credential rappresenta un meccanismo di autenticazione e autorizzazione direttamente legato al tuo cloud provider. Corrisponde a un IAM role in AWS, a una Managed Identity in Azure o a un Service Account in Google Cloud. Invece di consegnare raw cloud key a uno sviluppatore, il tuo cloud admin concede i privilegi di accesso a questa Storage Credential. Unity Catalog ha l'autorità di assumere questo ruolo, mantenendo la credenziale effettiva completamente fuori dalla portata degli utenti del workspace. Ora, una Storage Credential da sola è troppo generica. Quell'IAM role potrebbe avere i permessi per accedere a decine di bucket diversi in tutto il tuo cloud environment. È qui che entra in gioco la seconda parte. Un'External Location associa una Storage Credential a uno specifico cloud storage path, come l'URI di un bucket S3 o il container path di Azure Data Lake Storage. Definisce esattamente dove quella credenziale è autorizzata a operare. Puoi pensarla come a un confine geografico per le tue cloud credential. Prendi uno scenario concreto. Uno sviluppatore deve analizzare i system log archiviati in un bucket S3 altamente sicuro. In un setup legacy, un admin genererebbe delle access key AWS e le invierebbe allo sviluppatore, sperando che non faccia accidentalmente il commit di quelle key in un code repository pubblico. Con Unity Catalog, il workflow cambia completamente. L'admin crea una Storage Credential configurata con un IAM role che può leggere il target bucket. Successivamente, l'admin crea un'External Location che punta strettamente al path S3 contenente i system log, e vi associa quella Storage Credential. Infine, usando SQL standard, l'admin concede allo sviluppatore i permessi per leggere i file esclusivamente su quell'External Location. Quando lo sviluppatore esegue una query sui log, Unity Catalog interviene e gestisce in modo trasparente la cloud authentication per suo conto. Lo sviluppatore non vede mai un'AWS key. Non gestisce secret né configura cloud profile. Fa semplicemente una query sul path consentito. In seguito, puoi creare delle external table o degli external volume direttamente sopra questa location per organizzare ulteriormente i dati. Se lo sviluppatore passa a un altro team, l'admin revoca semplicemente il suo grant all'External Location all'interno di Databricks. La configurazione cloud IAM sottostante rimane completamente intatta. Ecco il key insight. Le External Location disaccoppiano la sicurezza della tua cloud infrastructure dalla governance quotidiana del data access. Tenendo gli IAM role fuori dallo user code e ancorandoli a path espliciti, garantisci che ogni data request sia auditata, sicura e limitata esclusivamente ai dati che intendi condividere. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 7 di 15. I data engineer passano una quantità incredibile di tempo solo a cercare di evitare che i loro fragili script di ingestion API si rompano. Quando un endpoint cambia la sua logica di paginazione o un rate limit si abbassa, la tua pipeline fallisce, e passi il pomeriggio a fare debugging di JSON invece di costruire data model. La soluzione a questo specifico grattacapo è Lakeflow Connect. Prima di vedere come funziona, chiariamo una comune confusione sui nomi. Databricks ha Lakeflow Jobs e Lakeflow Connect. Lakeflow Jobs gestisce l'orchestration, ovvero esegue i task in una sequenza specifica. Lakeflow Connect si occupa esclusivamente di ingestion. È il meccanismo per portare i dati grezzi da sistemi esterni nel tuo ambiente Databricks. Alla base, Lakeflow Connect fornisce dei Managed Connector. Si tratta di integrazioni native, create appositamente per applicazioni enterprise e database. Di solito, quando devi estrarre dati da sistemi esterni, scrivi del codice Python custom. Quel codice deve gestire l'autenticazione, occuparsi dei retry quando il server fa cadere la connessione, tenere traccia di quali record sono già stati acquisiti e fare il parsing di una paginazione complessa. I Managed Connector eliminano tutto quel layer di infrastruttura custom. Databricks gestisce il compute sottostante, le interazioni con le API e il tracking dello stato necessario per le letture incrementali. Dato che Lakeflow Connect gira su compute serverless, non devi configurare o gestire cluster solo per importare i dati. Il servizio scala automaticamente in base al volume dei dati in entrata. Si integra anche direttamente con Unity Catalog, il che significa che i dati di cui fai l'ingestion sono immediatamente governati e disponibili per le query. Considera un requisito standard. Il tuo team di marketing ha bisogno di dati Salesforce aggiornati nel tuo lakehouse. Se lo costruisci da zero, potresti passare una settimana a scrivere uno script custom che fa query sull'API di Salesforce. Devi scrivere la logica per rimanere sotto i rigidi limiti dell'API, gestire i refresh dei token e fare il merge degli aggiornamenti nelle tue tabelle Delta esistenti senza duplicare i record. Con un Managed Connector in Lakeflow Connect, bypassi completamente il codice custom. Fornisci le credenziali di connessione, selezioni gli specifici oggetti Salesforce che vuoi tracciare, e imposti un catalog e uno schema di destinazione. Il setup richiede pochi minuti. Databricks prende in carico l'esecuzione. Scarica lo snapshot storico iniziale dei tuoi dati e poi passa a catturare continuamente le modifiche incrementali man mano che avvengono. Ecco il punto chiave. Spostando il workload di ingestion su un Managed Connector, smetti di fare manutenzione agli script di polling. Quando le specifiche di un'API esterna cambiano, Databricks aggiorna il connettore dietro le quinte. La tua pipeline continua semplicemente a girare. Questo ti libera per poterti concentrare sulla vera business logic, come trasformare i dati grezzi in tabelle aggregate o addestrare modelli di machine learning, invece di fare da babysitter a uno script di estrazione rotto. Il vero valore di Lakeflow Connect non è solo il setup veloce, ma la rimozione permanente del codice di ingestion custom dal tuo backlog di manutenzione. Se vuoi dare una mano a far andare avanti lo show, puoi cercare DevStoriesEU su Patreon e supportarci lì. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 8 di 15. Hai una pipeline ETL complessa in cui una tabella si aggiorna ogni ora, un'altra si aggiorna continuamente e l'orchestrazione delle dipendenze richiede centinaia di righe di codice di state-management. E se potessi semplicemente dichiarare le tabelle finali che vuoi, e lasciare che l'engine crei l'infrastruttura per mantenerle aggiornate? Questa è la premessa dell'ETL automatizzato tramite pipeline dichiarative. In una pipeline imperativa tradizionale, dici al sistema esattamente come fare il suo lavoro. Scrivi il codice per gestire i checkpoint, gestire i retry, mappare le dipendenze e fare il provisioning dei cluster. Le pipeline dichiarative ribaltano questo modello. Dichiari semplicemente come dovrebbe essere la tabella finale, di solito con una query SQL standard o una funzione Python. L'engine sottostante crea l'execution graph, gestisce l'infrastruttura e gestisce automaticamente le transizioni di stato. Per far funzionare tutto questo, Databricks si basa su due tipi di tabelle specifici. Un errore comune è considerarle intercambiabili. Non lo sono. Devi separare chiaramente i tuoi dati degli eventi append-only dalle tue aggregazioni complesse. Il primo tipo è la Streaming Table. Le Streaming Table sono progettate esclusivamente per l'elaborazione incrementale e append-only. Leggono continuamente o in batch da un data source, elaborano solo i nuovi record e li aggiungono al target. Pensa all'elaborazione di un enorme stream di clic su un sito web provenienti da Kafka. Scrivi una query per popolare una Streaming Table a partire da quel topic Kafka. Non scrivi codice per tenere traccia degli offset o per ricordare quali messaggi sono già stati letti. La pipeline mantiene lo stato internamente, garantendo che ogni clic venga elaborato exactly once, anche se il sistema si riavvia. Ora, la seconda parte. Una volta che i tuoi eventi raw sono archiviati in modo sicuro, di solito devi trasformarli. È qui che entrano in gioco le Materialized View. Mentre le Streaming Table gestiscono l'ingest iniziale dei nuovi dati, le Materialized View sono create per aggregazioni complesse, join e record che si aggiornano o si eliminano nel tempo. Tornando ai nostri clic sul sito web, hai bisogno di una executive dashboard giornaliera che mostri i clic totali raggruppati per regione. Definisci una Materialized View che fa una select dalla tua Streaming Table ed esegue l'aggregazione. Quando la pipeline viene eseguita, l'engine valuta la Materialized View. Determina il modo più efficiente per aggiornarla. Se può calcolare le modifiche in modo incrementale, lo farà. Se è necessario un full recompute, lo gestisce automaticamente. Non scrivi mai la logica che detta quando fare il refresh o come fare il merge delle nuove aggregazioni. Ecco il punto chiave. Dato che definisci sia le Streaming Table che le Materialized View in modo dichiarativo, l'engine di Databricks comprende l'intero lineage dei tuoi dati. Sa che la Materialized View dipende dalla Streaming Table. Le unisce in un graph di pipeline unificato. Se un compute node fallisce a metà dell'elaborazione, la pipeline si affida a quel graph per mettersi in pausa, fare retry e riprendere senza duplicare i record o corrompere la dashboard finale. Il tuo codebase non è più ingombro di scaffolding operativo. Contiene solo la pura logica di business che definisce come i dati fluiscono dal source alla destination. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 9 di 15. Se la tua elaborazione notturna dei dati si basa su una chain di cron schedule indipendenti, in pratica stai sperando che lo step precedente sia terminato in tempo. Stai navigando alla cieca. Per fermare i silent failure e garantire l'ordine di esecuzione, hai bisogno della Master Orchestration con i Lakeflow Jobs. Innanzitutto, una breve distinzione. Le Lakeflow Pipelines gestiscono le dipendenze dei dati a livello di tabella. I Lakeflow Jobs, su cui ci concentriamo ora, orchestrano i task a livello macro. Pensa alle pipeline che spostano i dati all'interno del warehouse, mentre i job collegano notebook, script Python e modelli di machine learning in un workflow più ampio. Un job in Databricks è il contenitore principale per la tua orchestrazione. All'interno di quel contenitore, definisci molteplici task. Un task è una singola unità di lavoro isolata. Potrebbe essere l'esecuzione di un notebook Databricks, il submit di un'applicazione Spark, il run di un progetto dbt o il lancio di una query SQL. Collegando tra loro questi task, crei un grafo di esecuzione in cui un task inizia solo quando i suoi prerequisiti specifici vengono completati con successo. Analizziamo uno scenario pratico per vedere come il control flow gestisce l'affidabilità. Hai un processo giornaliero che fa l'ingestion di dati raw, ne verifica la qualità, li trasforma e avvisa il team se qualcosa va storto. Inizi definendo un task di ingestion. Successivamente, colleghi un task di data quality che viene eseguito rigorosamente dopo il completamento dell'ingestion. Ecco il punto chiave. Invece di scrivere un error handling custom nel tuo codice Python per decidere cosa succede dopo, usi il control flow nativo del job. Aggiungi un task con condizione if-else subito dopo il controllo di qualità. La condizione valuta una variabile restituita dal tuo task di data check. Se i dati sono puliti, il job segue l'if-branch e triggera il tuo task di trasformazione downstream. Se i dati sono corrotti, il job prende l'else-branch e triggera un task webhook che pinga un canale Slack. Gestisci anche lo stato utilizzando le condizioni task run-if. Puoi configurare un task di alerting in modo che venga eseguito solo se il task precedente è fallito del tutto, mentre il resto della pipeline si ferma in sicurezza. Questo impedisce la classica cascata di silent failure, in cui uno step di ingestion rotto triggera silenziosamente un modello di machine learning che si addestra su tabelle completamente vuote. Per avviare questo workflow, applichi un trigger. I job possono girare on demand, a intervalli schedulati tradizionali, o in modo continuo. Possono anche essere eseguiti in base a un evento, come l'arrivo di un nuovo file in un bucket di cloud storage esterno. Una volta triggerato, Databricks fornisce observability built-in. Non devi tirare a indovinare dove si è verificato un failure. La piattaforma registra una run history completa con una matrix view, mostrandoti esattamente quale task ha avuto successo, quale task si è bloccato e quanto tempo ha impiegato ogni step. Puoi configurare notifiche a livello di job o di task per inviare email automatiche o webhook nel momento in cui cambia uno stato di esecuzione. Il vero valore di questo modello di orchestrazione è spostare il failure handling fuori dai tuoi singoli script e nell'infrastruttura della piattaforma, assicurando che il tuo sistema sappia esattamente come instradare l'esecuzione quando le cose inevitabilmente si rompono. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a costruire!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 10 di 15. Spostare i dati fuori dal tuo data lake solo per permettere al tuo team di business intelligence di eseguire delle query è lento, costoso e completamente inutile. Finisci per mantenere pipeline fragili solo per copiare dati da un sistema all'altro, introducendo ritardi e duplicando i costi di storage. Questo è esattamente il problema che Databricks SQL risolve. C'è l'idea sbagliata e molto diffusa che Databricks sia strettamente per data engineer e data scientist che scrivono in Python o Scala. Databricks SQL chiarisce questo punto. È un workspace dedicato, costruito interamente per chi lavora con SQL. Pensa a un team di business intelligence che sta migrando da un data warehouse legacy. Storicamente, dovevano aspettare che i data engineer eseguissero job di estrazione notturni per caricare i dati dal lake al warehouse. Solo allora potevano iniziare a creare report. Databricks SQL elimina quell'intero layer di estrazione. Permette agli analisti di eseguire query ANSI-SQL standard direttamente sul data lake. Hai a disposizione l'enorme scalabilità dell'open lake storage, ma ci interagisci usando l'interfaccia familiare e veloce di un warehouse relazionale tradizionale. Il motore che alimenta queste query è il Serverless SQL Warehouse. Un SQL warehouse è semplicemente una risorsa di compute configurata specificamente per i workload SQL. Nelle architetture più vecchie, dovevi fare il provisioning manuale dei cluster, configurare le regole di scaling e aspettare diversi minuti per l'avvio delle macchine virtuali prima di eseguire una query. Ecco il punto chiave. Dato che questi SQL warehouse sono serverless, il layer di compute si avvia quasi istantaneamente. Fa scale out automaticamente quando i tuoi analisti lanciano workload concorrenti pesanti, e si termina da solo quando le query finiscono. La gestione dell'infrastruttura è completamente astratta, lasciando gli analisti liberi di concentrarsi esclusivamente sui propri dati. Per scrivere ed eseguire queste query, la piattaforma fornisce un editor SQL integrato. Questa è l'interfaccia principale per esplorare i dati. All'interno dell'editor, gli utenti possono scrivere SQL standard, navigare nei data catalog, esaminare gli schemi delle tabelle e visualizzare la history delle esecuzioni. Quando una query restituisce dati, l'analista non deve esportarli per comprenderli. Può creare visualizzazioni direttamente nell'editor e organizzarle in dashboard personalizzate che si aggiornano automaticamente. La piattaforma include anche una funzionalità di alerting. Gli analisti possono scrivere una query che verifica una metrica specifica e configurare il sistema per inviare un'e-mail o una notifica web se tale metrica supera una soglia definita. Molte organizzazioni dispongono già di strumenti di visualizzazione consolidati. Databricks SQL si integra direttamente con strumenti di terze parti standard come Power BI e Tableau. Queste applicazioni esterne si connettono al Serverless SQL Warehouse e trattano il data lake esattamente come se fosse un database ad alte prestazioni. Il cambiamento qui riguarda fondamentalmente la vicinanza ai tuoi dati. Portando compute di livello warehouse e SQL standard direttamente sul lake, smetti di copiare dati e inizi ad analizzare la tua single source of truth nel momento stesso in cui atterrano. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 11 di 15. Se tre dipartimenti diversi creano tre dashboard diverse per monitorare le entrate e portano tre numeri diversi alla riunione con i dirigenti, non hai un problema di data pipeline. Hai un problema di semantic layer. La soluzione è stabilire un semantic layer come unica source of truth e, in Databricks SQL, lo fai usando le Metric View. I dati grezzi raramente sono strutturati nel modo in cui ragionano gli utenti business. Le tabelle del database contengono nomi di colonna oscuri, join complessi e log di transazioni grezzi. Un semantic layer colma questo gap traducendo i dati sottostanti in concetti di business familiari. Vediamo uno scenario classico in cui questo meccanismo si rompe. Il tuo team marketing e il tuo team finance fanno entrambi report sui Monthly Active Users. Il marketing scrive una query nella sua dashboard che conta chiunque abbia aperto l'applicazione. Il finance scrive una query diversa in un tool separato che conta solo gli utenti che hanno completato una transazione. Entrambi i team chiamano la loro metrica Monthly Active Users. Quando i numeri non coincidono, la fiducia dell'organizzazione nei dati crolla. Definire i Monthly Active Users come Metric View all'interno di Unity Catalog risolve questo problema per sempre. Per capire il perché, dobbiamo chiarire cos'è effettivamente questa feature. Una Metric View non è la stessa cosa di una SQL View standard. Una SQL View standard si limita a salvare una query che restituisce righe e colonne grezze, lasciando completamente all'utente finale la decisione su come sommare, fare la media o raggruppare quei dati in un secondo momento. Una Metric View è molto più rigorosa. Impone calcoli di aggregazione e dimensionalità specifici direttamente a livello di catalog. Quando crei una Metric View, blocchi l'esatta logica di business. Definisci la measure, come ad esempio un distinct count degli ID utente basato su specifici criteri di transazione. Definisci anche le dimensioni consentite. Questo significa che decidi esplicitamente che questa metrica può essere suddivisa solo per attributi specifici, come la data della transazione, la region dell'utente o il tipo di device. Ecco il punto chiave. Una volta che quella Metric View viene pubblicata in Unity Catalog, diventa l'unica definizione autorevole dei Monthly Active Users per l'intera azienda. Quando gli analisti si connettono a Databricks SQL, non scrivono logica custom per aggregare i dati. Non fanno join tra tabelle e non scrivono clausole where per filtrare gli stati attivi. Fanno semplicemente una query sulla Metric View. Questo disaccoppia completamente la definizione della metrica dal presentation layer. Non importa se il marketing usa Tableau, il finance usa Power BI e il team di prodotto usa le dashboard native di Databricks. Il tool di business intelligence richiede semplicemente la metrica, e Databricks esegue il calcolo predefinito server side. Dato che la logica risiede centralmente in Unity Catalog, è impossibile che dipartimenti diversi inventino accidentalmente i propri calcoli. Tutti recuperano esattamente lo stesso numero, garantendo una coerenza perfetta in tutta l'organizzazione. Il vero potere di un semantic layer non è l'efficienza tecnica; è prendere la logica di business dai tool downstream scollegati e integrarla direttamente nelle fondamenta della data platform stessa. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 12 di 15. E se il tuo direttore vendite potesse semplicemente mandare un messaggio al tuo data warehouse per ottenere insight di business immediati, senza dover mai aprire un ticket al data team? Le richieste di dati ad-hoc interrompono costantemente i workflow di engineering, e gli utenti di business odiano aspettare giorni per una semplice query. La soluzione a questo bottleneck è una feature di Databricks chiamata Genie Spaces, che fa parte della loro più ampia offerta AI/BI. AI/BI è un prodotto di business intelligence basato su un compound AI system. È progettato per comprendere la semantica specifica dei tuoi dati. Genie Spaces fa da interfaccia conversazionale per questo sistema. Un Genie Space sembra e si comporta come una normale app di chat, ma è collegato direttamente al tuo data warehouse. Gli utenti di business scrivono le domande in linguaggio naturale e Genie risponde con dati reali, visualizzazioni e risposte. Quando le persone sentono parlare di AI che fa query sui dati, si preoccupano subito delle allucinazioni. Danno per scontato che il modello tirerà a indovinare i nomi delle colonne, inventerà metriche o restituirà con sicurezza risposte sbagliate. Genie evita tutto questo basandosi interamente sui metadata governati e salvati nel tuo Unity Catalog. Non invia un prompt alla cieca a un modello linguistico generico. L'AI è ancorata al tuo schema reale, ai tuoi data type, alle tue relazioni di foreign key e alle metriche predefinite che il tuo team ha stabilito. Per far funzionare il tutto, per prima cosa un analista crea e configura il Genie Space. Seleziona i dataset pertinenti da Unity Catalog e fornisce una serie di istruzioni. Può aggiungere query di esempio, definire una terminologia di business specifica e chiarire termini ambigui. Ad esempio, può indicare al sistema che quando un utente dice "cliente attivo", intende specificamente un cliente che ha effettuato un acquisto negli ultimi novanta giorni. Questo setup iniziale restringe lo scope dell'AI a un dominio ben definito. Quando viene fatta una domanda, il sistema orchestra diversi step. Legge il prompt in linguaggio naturale e verifica il contesto fornito. Abbina l'intent dell'utente alle tabelle e colonne esatte nel catalogo. Genera quindi una query SQL precisa, esegue quella query sul compute engine SQL di Databricks e formatta i risultati. Immagina un sales manager non tecnico che utilizza un Genie Space già preparato. Digita: "Mostrami le vendite in Europa per prodotto relative all'ultimo trimestre". Il sistema fa il parsing della richiesta in base al suo training. Riconosce "Europa" come dimensione region, individua le tabelle dei prodotti e traduce "ultimo trimestre" in un filtro data preciso. In pochi secondi, l'AI genera l'SQL, lo esegue e restituisce un grafico interattivo che mostra la ripartizione. Se il manager poi risponde: "Ora escludi la Germania", Genie modifica la query sottostante e aggiorna istantaneamente il grafico, mantenendo il contesto conversazionale. Questo workflow cambia radicalmente il modo in cui vengono gestite le richieste ad-hoc. I data engineer e gli analisti passano una fetta enorme della loro settimana a scrivere query SQL one-off per gli stakeholder. Spostare questa esplorazione su Genie Spaces dà agli stakeholder di business risposte immediate, liberando al contempo tempo di engineering per task complessi. Inoltre, l'intero processo rimane completamente governato. Genie rispetta rigorosamente tutti gli access control a livello di riga e colonna definiti in Unity Catalog. Se l'utente che fa la domanda non ha i permessi per vedere dati finanziari sensibili, l'AI semplicemente non farà la query. Ecco il key insight. L'efficacia dell'esplorazione conversazionale dei dati è determinata dalla qualità del tuo data model e dei metadata sottostanti, non solo dall'intelligenza del modello linguistico. Questo è tutto per questo episodio. Grazie per l'ascolto, e keep building!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 13 di 15. Addestrare un modello di machine learning è la parte divertente, ma farne il deploy come API REST sicura e ad alta disponibilità è il punto in cui la maggior parte dei progetti di data science va a morire. Passare da un esperimento in un notebook a un endpoint production-ready richiede la configurazione dello scaling, del load balancing e di una governance rigorosa. Per risolvere questo problema, usi Mosaic AI Model Serving. Questa feature fornisce un'interfaccia unificata per fare il deploy, governare e interrogare i modelli di AI. Un malinteso comune è pensare che Databricks Model Serving sia solo per i modelli che addestri tu stesso dentro Databricks. Non è così. In realtà, funge da AI Gateway centrale. Gestisce tre tipi distinti di modelli: modelli custom, foundation model e modelli esterni. Primo, i modelli custom. Sono i modelli che crei, logghi con MLflow e registri in Unity Catalog. Model Serving fa il provisioning di un container serverless, carica le dipendenze del tuo modello e lo espone come API REST. Non devi gestire l'infrastruttura. Fa scale up quando ci sono picchi di traffico e scale down a zero quando è in idle. Secondo, i foundation model ospitati da Databricks. Si tratta di grandi modelli open-source che Databricks ospita su compute ottimizzato. Hai accesso immediato ad architetture all'avanguardia senza doverti preoccupare del provisioning delle GPU. Terzo, i modelli esterni. È qui che configuri gli endpoint che puntano a servizi di terze parti. Perché fare routing del traffico esterno tramite Databricks anziché chiamare direttamente i provider esterni? Pensa alla governance e al controllo dei costi. Supponiamo che la tua azienda voglia usare GPT-4 per un'applicazione interna. Se ogni sviluppatore hardcoda una API key nel proprio script, perdi visibilità. Non puoi monitorare rigorosamente i costi, gestire i rate limit o applicare filtri per impedire ai dipendenti di inviare dati sensibili dei clienti a un provider esterno. Facendo routing di tutte le request tramite Mosaic AI Model Serving, forzi quel traffico attraverso un unico gateway sicuro. Gestisci un solo set di credenziali. Applichi gli access control tramite Unity Catalog, definendo esattamente chi o cosa può interrogare il modello. Ottieni anche un tracking centralizzato dell'utilizzo, degli errori e della latenza. Il flusso logico è semplice. Definisci un serving endpoint in Databricks. Per un modello custom, punti l'endpoint a un modello MLflow registrato e definisci la compute size e gli scaling limit. Databricks gestisce automaticamente la containerization. Per un modello esterno, fornisci il nome del provider esterno e una API key archiviata in modo sicuro. Una volta che l'endpoint è attivo, le tue applicazioni downstream inviano un payload JSON standard tramite una request HTTP all'URL dell'endpoint. La response torna indietro in un formato coerente, indipendentemente dal fatto che il modello sia in esecuzione su serverless compute di Databricks o risieda in un data center esterno. Ecco il punto chiave. Mosaic AI Model Serving elimina gli attriti del deploy garantendo al contempo la sicurezza. Standardizza il tuo application layer, in modo che il tuo client code comunichi sempre e solo con un singolo endpoint Databricks, completamente astratto da dove o come è ospitato il modello sottostante. A proposito, se vuoi supportare il podcast, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 14 di 15. Hai diecimila log grezzi del customer support in una tabella del database e il business ha bisogno che vengano riassunti e categorizzati in base al sentiment entro la fine della giornata. Normalmente, estrarre questo tipo di insight richiede una complessa pipeline Python, un'attenta gestione delle API key e una logica di batching personalizzata per passare il testo a un Large Language Model. E se potessi eseguire l'intero workload utilizzando un semplice comando del database? Questo è esattamente il problema risolto dalle AI Functions, che integrano i LLM direttamente nelle tue query SQL. Le AI Functions colmano il divario tra la Generative AI all'avanguardia e la data analytics di tutti i giorni. Prendono una funzionalità che di solito richiede competenze specializzate di machine learning engineering e la mettono nelle mani di chiunque sappia scrivere in SQL. Invece di costruire un'infrastruttura separata per estrarre i dati, inviarli a un modello e salvare le prediction, le AI Functions portano il modello direttamente dove i dati già risiedono. Lo strumento principale per questo è un comando integrato chiamato AI query. Lo usi esattamente come una normale funzione di text processing all'interno di un select statement. Specifichi il nome dell'endpoint del modello che vuoi utilizzare e poi fornisci il prompt. Tornando a quei diecimila log di supporto, il tuo workflow diventa banale. Scrivi una query selezionando il tuo customer ID e il testo del log. Quindi, aggiungi una nuova colonna utilizzando la funzione AI query. Il tuo prompt indica al modello di leggere il testo, estrarre il reclamo principale e determinare se il sentiment è positivo, neutro o negativo. Passi la colonna contenente il testo grezzo del log a quel prompt. Quando esegui la query, il database engine distribuisce automaticamente questa richiesta. Elabora ogni singola riga tramite il Large Language Model specificato. Il modello valuta il testo e restituisce il summary e il sentiment. Poiché tutto ciò avviene in SQL, l'output arriva come colonne strutturate standard. Puoi filtrare immediatamente i risultati per mostrare solo il sentiment negativo, fare una join di questi risultati con una tabella di customer billing e aggregare i dati per scoprire quale prodotto sta causando maggiore frustrazione. Ecco l'insight chiave. Potresti pensare che dare ai data analyst l'accesso ai Large Language Model significhi distribuire API key sensibili a tutta l'organizzazione. Non è così. Le AI Functions sono strettamente integrate con Databricks Model Serving. Le connessioni effettive a modelli esterni, o a modelli open source self-hosted, vengono configurate dagli amministratori a livello di piattaforma. Il data analyst non vede mai un'API key, un token o un secret. Fa riferimento solo al nome dell'endpoint preconfigurato nella sua query. L'intera operazione rimane completamente sicura. Ogni query viene loggata e tutti i controlli di accesso applicati ai dati e ai modelli sono rigorosamente applicati dal governance framework della piattaforma. Eliminando la friction dell'infrastruttura e il credential management, cambi la natura della data exploration. Trasformi la complessa analisi di testo non strutturato in una semplice operazione di filtraggio, migliorando istantaneamente la capacità analitica dell'intero team. Grazie per l'ascolto. Statemi bene, ciao a tutti.

Ciao, sono Alex di DEV STORIES DOT EU. Databricks, episodio 15 di 15. Il tuo chatbot standard è gentile, informativo e completamente passivo. Può dirti come sistemare una pipeline rotta basandosi su un manuale, ma non può effettivamente sistemarla al posto tuo. Passare da un'AI che si limita a parlare a un'AI che esegue attivamente dei task richiede un cambiamento fondamentale nell'architettura. Questo cambiamento è l'AI Agent Framework. Chiariamo subito un equivoco comune. Spesso si confondono le semplici applicazioni di Retrieval-Augmented Generation con i veri agenti. Un'applicazione RAG è essenzialmente un motore di ricerca con un language model al di sopra. Recupera documenti e li riassume. Si limita a leggere. Un vero AI Agent ha dei tool. Può scrivere. Può eseguire query SQL, triggerare job e chiamare API esterne. Cambia lo stato dei tuoi sistemi. Il Databricks Agent Framework fornisce l'infrastruttura per creare, valutare e fare il deploy di questi agenti autonomi in modo sicuro all'interno del Lakehouse. Il meccanismo centrale qui è il tool calling combinato con il multi-step reasoning. Invece di generare semplicemente una risposta in un solo passaggio, il language model funge da reasoning engine. Gli dai un obiettivo e un set di tool, che sono fondamentalmente funzioni che hai definito tu. L'agente decide quale tool usare, aspetta il risultato e poi decide cosa fare dopo. Pensa a un agente progettato per monitorare le data pipeline. Quando si verifica un errore, l'agente non resta lì fermo ad aspettare un prompt dell'utente. Il framework gli permette di triggerare un workflow. Per prima cosa, l'agente ha bisogno di contesto. Usa un custom tool che gli hai fornito per eseguire una query SQL sui log di sistema in Databricks. Il framework esegue questa query e restituisce il risultato all'agente. Ecco il punto chiave. L'agente valuta quei log, identifica la root cause dell'errore e poi passa allo step successivo. Si rende conto che il team di engineering deve saperlo. Quindi, seleziona un altro tool, un'integrazione API con l'app di chat aziendale. Chiama quel tool per scrivere e inviare un messaggio con i dettagli dell'errore esatto e il fix proposto. Questo è il multi-step reasoning in azione. L'agente ha pianificato una sequenza, eseguito codice, osservato il risultato e comunicato l'esito, il tutto in modo autonomo. Dare a un language model la capacità di eseguire query e triggerare API è un enorme rischio per la sicurezza se gestito male. Ecco perché l'approccio di Databricks accoppia strettamente l'Agent Framework con Unity Catalog. Quando fai il deploy di un agente usando Databricks Model Serving, non gli stai dando accesso illimitato alla tua infrastruttura. Registri i tuoi tool come funzioni specifiche all'interno di Unity Catalog. Unity Catalog impone una rigida governance su cosa possono fare quelle funzioni. Se dai a un agente un tool per fare query sulle tabelle di log, Unity Catalog assicura che possa leggere solo quelle specifiche tabelle. Se il language model ha un'allucinazione e prova a usare il tool SQL per fare il drop di un database di produzione, il framework lo ferma perché la funzione sottostante non ha i permessi necessari. L'agente è strettamente vincolato alle regole di governance del tuo Lakehouse. Questa funzionalità trasforma il Lakehouse da uno storage layer passivo a un ambiente attivo e automatizzato. Mentre concludiamo questa serie, ti incoraggio a dare un'occhiata alla documentazione ufficiale e a provare a creare tu stesso un semplice agente di tool calling. Se vuoi suggerire argomenti per la nostra prossima serie, fai un salto su devstories dot eu. Il passaggio dai chatbot agli agenti è il cambiamento decisivo nel modo in cui sviluppiamo le applicazioni AI oggi. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!