Creare un'app per l'allenamento di calcio su Databricks

I dati di tracciamento rappresentano oggi il segnale più ricco nello sport, ma il vero divario sta nel trasformare questi dati in qualcosa che un allenatore possa effettivamente utilizzare.

Una partita moderna viene catturata a 25 fotogrammi al secondo (FPS) da 19 feed separati: ogni giocatore, la palla e ogni evento, molte volte al secondo. Per un singolo torneo, si tratta di 339 partite e 51 milioni di righe di dati di tracciamento. Eppure, quasi nulla di tutto ciò è utilizzabile dalla persona che ne ha più bisogno. Un allenatore in panchina non può leggere una tabella da 51 milioni di righe. Coach's Corner colma questo divario, interamente su un'unica piattaforma.

La sfida non è solo la scalabilità, ma anche la tempistica e la cognizione. Gli allenatori prendono decisioni in pochi secondi, non in minuti, e i flussi di lavoro di analytics tradizionali presuppongono il contrario: elaborazione batch, dashboard offline e analisi post-partita. Anche quando gli insight esistono, sono sepolti dietro strumenti che richiedono un analista per interpretarli e trasmetterli. Questo crea un collo di bottiglia strutturale in cui i dati sono ricchi e i modelli sono sofisticati, ma chi deve prendere le decisioni è di fatto cieco nel momento cruciale.

Ecco Coach’s Corner, “La Pizarra”

La Pizarra (“la lavagna”) è una panchina tecnica per le nazionali che funziona come una Databricks App. Un allenatore sceglie una partita e la riproduce in 2D o 3D, spostando la telecamera da un'angolazione televisiva a una vista tattica dall'alto e scorrendo i fotogrammi fino a una velocità di 8x. In sovrimpressione sul replay ci sono gli analytics che contano: mappe dei tiri e degli xG, reti di passaggi, heatmap, calci piazzati, disposizione della squadra, controllo del campo, traiettorie della palla e percorsi dei giocatori. Integrati con le funzionalità di replay ci sono diversi strumenti avanzati: una vista completa della classifica, analytics basati sugli eventi, una firma di stile Scout unica per valutare qualsiasi squadra e un Tactical Agent in grado di generare dossier su richiesta per i prossimi avversari.

La vista panchina mette l'intera partita nelle mani dell'allenatore, consentendo transizioni fluide tra la prospettiva televisiva e quella tattica dall'alto. Con lo scorrimento a 8x e le sovrapposizioni automatiche per linee di passaggio e heatmap, gli elementi tattici come il controllo del campo e la disposizione della squadra diventano schemi tangibili sul terreno di gioco anziché metriche astratte.

Le fondamenta tecniche di Coach's Corner sono state dettate da un unico principio guida: l'interfaccia doveva funzionare come un'estensione dell'istinto naturale dell'allenatore, piuttosto che come un complesso strumento analitico. Ciò ha richiesto un design che riducesse il sovraccarico di interazione, privilegiasse il contesto spaziale rispetto ai grafici tradizionali e presentasse ogni metrica come un elemento dinamico del gioco. Ancorando gli insight direttamente al campo di gioco, l'applicazione elimina la necessità di interpretare manualmente i dati e fornisce analytics cruciali proprio quando sono più rilevanti.

Un'unica piattaforma, ogni hop

La data engineering principale avviene dietro le quinte. I feed di tracciamento grezzi arrivano come NDJSON in un Volume di Unity Catalog, dove Auto Loader li acquisisce in modo incrementale utilizzando il pattern Lakeflow Connect. Da lì, le Spark Declarative Pipelines elaborano i dati attraverso i livelli bronze, silver e gold, in esecuzione in modalità completamente serverless su Photon con 46 data quality expectation denominate e applicate. Le tabelle gold finali, inclusa una tabella di fotogrammi da 51 milioni di righe, sfruttano il liquid clustering per consentire tempi di risposta alle query di 1-3 secondi tramite DBSQL in esecuzione su un piccolo warehouse. Consolidando tutti i volumi, le tabelle, i modelli e gli indici in un unico Unity Catalog, l'architettura elimina il codice di integrazione proprietario e i sistemi di governance secondari.

L'architettura ha deliberatamente evitato la frammentazione resistendo al passaggio verso microservizi specializzati. Invece di suddividere l'acquisizione, la trasformazione, il serving e l'orchestrazione dell'AI in stack isolati e ottimizzati localmente, il sistema è rimasto unificato su un'unica piattaforma. Mantenere tutto all'interno di Databricks ha sacrificato un po' di flessibilità teorica a favore della coerenza operativa: un unico livello di governance, una lineage coerente e nessun disadattamento di impedenza tra i sistemi. Questo diventa particolarmente importante quando si introduce l'AI, perché il costo di dati non governati o incoerenti si accumula rapidamente.

Le Spark Declarative Pipelines ridefiniscono l'affidabilità passando da un modello imperativo a uno esplicito. Invece di affidarsi a job rigidi con presupposti integrati, il sistema tratta la qualità dei dati come una priorità assoluta, applicando aspettative formali. Questa suite di 46 aspettative ha un duplice scopo: salvaguarda la pipeline in tempo reale e stabilisce la "correttezza" dei dati per i consumatori a valle, inclusi replay, analytics e agenti AI.

Il diagramma seguente mostra l'architettura che alimenta la vista panchina. In alto si trovano le esperienze con cui l'allenatore interagisce: replay, analisi, scout, classifiche e agenti. Al centro, ciascuna di queste esperienze è supportata da livelli governati: Unity Catalog per dati e modelli, Lakehouse e Lakebase per il serving analitico e transazionale, e Vector Search per la similarità. In basso si trova la realtà grezza da cui tutto ha inizio: feed di tracciamento a 25 FPS, eventi della partita, profili dei giocatori e formazioni, che confluiscono tutti in un lake aperto.

Percorsi di serving ottimizzati per velocità e scalabilità

Per garantire prestazioni massime, l'applicazione utilizza due percorsi architetturali distinti per il recupero dei dati. I replay di tracciamento ad alta velocità sono alimentati da Lakebase, che sincronizza le tabelle gold su Postgres per consentire letture di fotogrammi a finestra a livello di millisecondi. Consentendo al clock del browser di recuperare solo i fotogrammi essenziali anziché scansionare intere partite, il sistema mantiene un'esperienza interattiva fluida. Al contrario, gli analytics degli eventi più pesanti vengono instradati tramite la Statement Execution API al SQL warehouse, mantenendo le query computazionali intensive separate dal reattivo replay 3D.

Questa deliberata biforcazione tra Lakebase e DBSQL risponde a diversi pattern di accesso, piuttosto che alla sola velocità grezza. Le funzioni di replay richiedono letture sequenziali e sensibili alla latenza su segmenti di dati specifici, mentre i carichi di lavoro analitici sono spesso esplorativi e richiedono ampie scansioni del dataset. Isolando questi percorsi, ciascun carico di lavoro opera all'interno del proprio ambiente ideale, evitando che i picchi analitici degradino l'esperienza di replay o richiedano un overprovisioning non necessario.

La separazione tra Lakebase e DBSQL non riguarda solo le prestazioni, ma i pattern di accesso. I carichi di lavoro di replay sono altamente sequenziali e sensibili alla latenza, e richiedono letture prevedibili nell'ordine dei millisecondi su porzioni limitate di dati. Le query analitiche, d'altra parte, sono discontinue ed esplorative, e spesso scansionano porzioni più ampie del dataset. Tentare di unificare questi elementi in un unico livello di serving rallenterebbe il replay o richiederebbe un overprovisioning degli analytics. La suddivisione dei percorsi consente a ciascun carico di lavoro di operare nel proprio ambiente ideale senza compromessi.

Un livello di scouting AI, basato su dati governati

L'intelligenza risiede sugli stessi dati governati, mai accanto ad essi. La chat di Scout è supportata da uno spazio Genie reale che converte le domande in linguaggio naturale dell'allenatore in SQL governato. Vector Search alimenta la funzione "giocatori simili" su un indice dei profili dei giocatori. Il dossier sull'avversario è un agente: un supervisore Agent Bricks orchestra Genie, Vector Search e un modello xG registrato in Unity Catalog, ed effettua chiamate a Claude su Model Serving tramite Unity AI Gateway per chiamate LLM governate e osservabili. Ogni passaggio è tracciato in MLflow e l'agente ha sempre un fallback programmato deterministico, in modo da non trovarsi mai in un vicolo cieco davanti a un pubblico. Poiché legge lo stesso catalogo che l'allenatore vede sulla lavagna, le risposte rimangono coerenti con i dati.

Nella vista scout qui sotto, l'allenatore non scrive query; fa domande come farebbe nello spogliatoio. Genie prende la richiesta "Chiedi informazioni su xG vs xBA" e la trasforma silenziosamente in SQL governato, utilizzando gli stessi dati di tracciamento e di evento che alimentano la panchina. La risposta non è una risposta LLM generica; è basata sulle tabelle e sui modelli esatti registrati in Unity Catalog, in modo che la narrazione dello scout corrisponda ai numeri che vedrebbe l'analista.

Uno dei problemi più difficili nell'AI applicata non è generare risposte, ma garantire che siano tracciabili e difendibili. Nel contesto dell'allenamento, un insight errato o non verificabile è peggio di nessun insight. Basando ogni interazione AI in Unity Catalog e instradando tutte le chiamate ai modelli attraverso Unity AI Gateway, ogni risposta è collegata a dati governati e percorsi di esecuzione osservabili. Ciò consente ad allenatori e analisti di fidarsi non solo dell'output, ma anche del processo che lo genera.

L'architettura dell'agente riflette anche una propensione al determinismo. Mentre l'LLM fornisce sintesi e narrazione, i passaggi critici come il recupero dei dati, il calcolo delle metriche e la ricerca di similarità sono gestiti da sistemi strutturati come Genie e Vector Search. Questo approccio ibrido evita la fragilità dei sistemi completamente generativi, consentendo al contempo un'interazione flessibile e naturale.

Perché è importante

Sebbene Coach’s Corner sia radicato nello sport, la sua architettura affronta una sfida universale: il "divario di usabilità" nei dati ad alta frequenza. La maggior parte delle organizzazioni possiede enormi volumi di dati che rimangono operativamente silenti perché manca un sistema per tradurre gli input grezzi in decisioni immediate. Questo progetto dimostra che unificando acquisizione, trasformazione e AI all'interno di un unico framework di governance, l'attrito tra dati e azione viene eliminato.

L'implicazione non è solo avere dashboard più veloci, ma un cambiamento nel modo in cui vengono prese le decisioni. Quando gli insight possono essere generati, convalidati e distribuiti all'interno dello stesso sistema in pochi secondi, il ruolo dei dati si evolve dall'analisi retrospettiva alla partecipazione attiva al processo decisionale. Questa è la differenza tra osservare il gioco e influenzarlo.

La vista degli agenti riportata di seguito è la piena espressione di questo pattern: a partire dai dati di tracciamento e dagli eventi della partita, l'agente supervisore estrae la firma stilistica di una squadra, cerca partite simili, chiama un modello xG e poi chiede a un LLM di sintetizzare il tutto in un dossier. L'allenatore non vede nulla di questa orchestrazione; vede un pulsante con l'etichetta "Genera dossier per il Brasile", una traccia di ragionamento che può ispezionare se desidera e un report salvato che diventa parte del suo piano di gioco.

Inizialmente concepito come un'applicazione incentrata sullo sport, Coach’s Corner si è evoluto in un blueprint definitivo per i moderni sistemi di dati e AI nel settore dell'intrattenimento dal vivo. Caricando i dati grezzi una sola volta e perfezionandoli attraverso pipeline affidabili, il sistema garantisce che le informazioni vengano fornite tramite il percorso ottimale per ogni specifico carico di lavoro. Questo processo trasforma gli input grezzi in informazioni governate e azionabili, disponibili nell'esatto momento della decisione. La conclusione principale di questa iniziativa è chiara: quando la gestione dei dati, il serving e l'AI sono unificati su un'unica piattaforma, gli insight si convertono in azioni immediate.

Vuoi creare qualcosa di simile? Esplora la documentazione di Databricks Apps per distribuire la tua app di dati full-stack, scopri come Lakebase porta il serving Postgres a livello di millisecondi nel lakehouse e scopri come Genie e Agent Bricks aggiungono un'intelligence governata in linguaggio naturale ai tuoi dati, il tutto sotto un unico Unity Catalog.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale