Coach's Corner convierte 51M de filas de seguimiento en una app de banquillo 2D/3D en menos de un segundo para entrenadores, abarcando desde la ingesta de Lakeflow en Databricks hasta el scouting de Genie y dosieres agénticos.
por Samwel Emmanuel, Sheridan Harris, Andrew Helmreich, Kush Patel y Nick Ragonese
Los datos de seguimiento son ahora la señal más valiosa en el deporte, pero el verdadero desafío consiste en transformar esos datos en algo que un entrenador realmente pueda utilizar.
Un partido moderno se captura a 25 fps desde 19 transmisiones independientes: cada jugador, el balón y cada evento, muchas veces por segundo. Para un solo torneo, eso representa 339 partidos y 51 millones de filas de datos de seguimiento. Sin embargo, casi nada de esto es utilizable por la persona que más lo necesita. Un entrenador en el banquillo no puede leer una tabla de 51 millones de filas. Coach's Corner cierra esa brecha, completamente en una sola plataforma.
El desafío no es solo la escala, sino también el tiempo y la cognición. Los entrenadores toman decisiones en segundos, no en minutos, y los flujos de trabajo de analítica tradicionales asumen lo contrario: procesamiento por lotes, paneles offline y revisión posterior al partido. Incluso cuando existen insights, están enterrados detrás de herramientas que requieren que un analista los interprete y los transmita. Esto crea un cuello de botella estructural en el que los datos son abundantes y los modelos son sofisticados, pero quien toma las decisiones está prácticamente a ciegas en el momento clave.
La Pizarra es un banquillo técnico de selección nacional que se ejecuta como una Databricks App. Un entrenador elige un partido y lo reproduce en 2D o 3D, cambiando la cámara de un ángulo de transmisión a una vista táctica cenital y desplazándose a una velocidad de hasta 8x. Superpuestos en la reproducción se encuentran los análisis clave: mapas de tiros y xG, redes de pases, mapas de calor, jugadas a balón parado, disposición del equipo, control del campo, trayectorias del balón y recorridos de los jugadores. Integradas con las funciones de reproducción se encuentran varias herramientas avanzadas: una vista completa de la clasificación, análisis basados en eventos, una firma de estilo Scout única para evaluar a cualquier equipo y un Agente Táctico capaz de generar informes bajo demanda sobre los próximos rivales.
La vista de banquillo pone todo el partido en manos del entrenador, lo que permite transiciones fluidas entre la perspectiva de transmisión y la táctica cenital. Con un desplazamiento rápido de 8x y superposiciones automáticas para líneas de pase y mapas de calor, los elementos tácticos como el control del campo y la disposición del equipo se convierten en patrones tangibles en el terreno de juego en lugar de métricas distantes.

La base técnica de Coach's Corner se rigió por un único principio rector: la interfaz tenía que funcionar como una extensión del instinto natural del entrenador, en lugar de como un instrumento analítico complejo. Esto requería un diseño que redujera la sobrecarga de interacción, priorizara el contexto espacial sobre los gráficos tradicionales y presentara cada métrica como un elemento dinámico del juego. Al vincular los insights directamente al terreno de juego, la aplicación elimina la necesidad de interpretar los datos manualmente y ofrece análisis críticos precisamente cuando son más relevantes.
La ingeniería de datos principal ocurre bajo el capó. Las transmisiones de seguimiento sin procesar llegan como NDJSON a un volumen de Unity Catalog, donde Auto Loader las ingiere de forma incremental utilizando el patrón Lakeflow Connect. Desde allí, Spark Declarative Pipelines procesa los datos a través de los niveles bronze, silver y gold, ejecutándose de forma completamente serverless en Photon con 46 expectativas de calidad de datos con nombre aplicadas. Las tablas gold finales, incluida una tabla de fotogramas de 51 millones de filas, aprovechan el liquid clustering para permitir tiempos de respuesta de consulta de 1 a 3 segundos a través de DBSQL ejecutándose en un warehouse pequeño. Al consolidar todos los volúmenes, tablas, modelos e índices en un único Unity Catalog, la arquitectura elimina el código de integración de proveedores y los sistemas de gobernanza secundarios.
La arquitectura evitó deliberadamente la fragmentación al resistirse a la transición hacia microservicios especializados. En lugar de dividir la ingesta, la transformación, el servicio y la orquestación de AI en pilas aisladas y optimizadas localmente, el sistema se mantuvo unificado en una sola plataforma. Mantener todo dentro de Databricks sacrificó cierta flexibilidad teórica a cambio de coherencia operativa: una única capa de gobernanza, un linaje coherente y la ausencia de incompatibilidades entre sistemas. Esto se vuelve especialmente importante cuando se introduce la AI, ya que el costo de los datos no gobernados o inconsistentes se acumula rápidamente.
Spark Declarative Pipelines redefinen la confiabilidad al pasar de un modelo imperativo a uno explícito. En lugar de depender de trabajos rígidos con suposiciones implícitas, el sistema trata la calidad de los datos como una prioridad absoluta al aplicar expectativas formales. Este conjunto de 46 expectativas cumple un doble propósito: protege el pipeline en tiempo real y establece la "exactitud" de los datos para los consumidores intermedios, incluidos la reproducción, la analítica y los agentes de AI.
El siguiente diagrama muestra la arquitectura que impulsa la vista de banquillo. En la parte superior se encuentran las experiencias con las que interactúa el entrenador: reproducción, análisis, scout, clasificación y agentes. En el medio, cada una de esas experiencias está respaldada por capas gobernadas: Unity Catalog para datos y modelos, Lakehouse y Lakebase para el servicio analítico y transaccional, y Vector Search para la búsqueda de similitud. En la parte inferior se encuentra la realidad sin procesar de la que parte todo: transmisiones de seguimiento a 25 fps, eventos del partido, perfiles de jugadores y alineaciones, todo ello llegando a un open lake.

Para garantizar el máximo rendimiento, la aplicación utiliza dos rutas arquitectónicas distintas para la recuperación de datos. Las reproducciones de seguimiento de alta velocidad están impulsadas por Lakebase, que sincroniza las tablas gold con Postgres para permitir lecturas de fotogramas en ventanas a nivel de milisegundos. Al permitir que el reloj del navegador extraiga solo los fotogramas esenciales en lugar de escanear partidos enteros, el sistema mantiene una experiencia interactiva fluida. Por el contrario, los análisis de eventos pesados se dirigen a través de la Statement Execution API al SQL warehouse, manteniendo las consultas computacionales intensivas separadas de la reproducción interactiva en 3D.
Esta bifurcación deliberada entre Lakebase y DBSQL responde a diferentes patrones de acceso y no solo a la velocidad bruta. Las funciones de reproducción exigen lecturas secuenciales y sensibles a la latencia sobre segmentos de datos específicos, mientras que las cargas de trabajo analíticas suelen ser exploratorias y requieren escaneos de conjuntos de datos amplios. Al aislar estas rutas, cada carga de trabajo opera dentro de su entorno ideal, lo que evita que los picos analíticos degraden la experiencia de reproducción o requieran un sobreaprovisionamiento innecesario.
La separación entre Lakebase and DBSQL no se trata solo de rendimiento, sino de patrones de acceso. Las cargas de trabajo de reproducción son altamente secuenciales y sensibles a la latencia, lo que requiere lecturas predecibles en milisegundos sobre fragmentos estrechos de datos. Las consultas analíticas, por otro lado, son en ráfagas y exploratorias, y a menudo escanean porciones más grandes del conjunto de datos. Intentar unificar estas en una sola capa de servicio ralentizaría la reproducción o sobredimensionaría la analítica. Dividir las rutas permite que cada carga de trabajo funcione en su entorno ideal sin compromisos.
La inteligencia reside en los mismos datos gobernados, nunca al margen de ellos. El chat de Scout está respaldado por un espacio de Genie real que convierte las preguntas en lenguaje natural del entrenador en SQL gobernado. Vector Search impulsa la función de “jugadores similares” sobre un índice de perfiles de jugadores. El informe del oponente es un agente: un supervisor de Agent Bricks orquesta Genie, Vector Search y un modelo xG registrado en Unity Catalog, y llama a Claude en Model Serving a través de Unity AI Gateway para realizar llamadas de LLM gobernadas y observables. Cada paso se registra en MLflow, y el agente siempre tiene una alternativa programada determinista, por lo que nunca se queda sin salida frente al público. Dado que lee el mismo catálogo que el entrenador ve en la pizarra, las respuestas siguen siendo coherentes con los datos.
En la vista de scout a continuación, el entrenador no está escribiendo consultas; está haciendo preguntas de la misma manera que lo haría en el vestuario. Genie toma la pregunta “Preguntar sobre xG frente a xBA” y la convierte silenciosamente en SQL gobernado, utilizando los mismos datos de seguimiento y eventos que impulsan el banquillo. La respuesta no es una respuesta genérica de LLM; está basada en las tablas y modelos exactos registrados en Unity Catalog, por lo que la narrativa del scout coincide con los números que vería el analista.

Uno de los problemas más difíciles en la AI aplicada no es generar respuestas, sino garantizar que sean rastreables y defendibles. En el contexto del entrenamiento, un insight erróneo o inverificable es peor que no tener ningún insight. Al basar cada interacción de AI en Unity Catalog y enrutar todas las llamadas de modelos a través de Unity AI Gateway, cada respuesta se vincula de nuevo a datos gobernados y rutas de ejecución observables. Esto permite a los entrenadores y analistas confiar no solo en el resultado, sino también en el proceso que hay detrás.
La arquitectura del agente también refleja una inclinación hacia el determinismo. Mientras que el LLM proporciona síntesis y narrativa, los pasos críticos como la recuperación de datos, el cálculo de métricas y la búsqueda de similitudes son gestionados por sistemas estructurados como Genie y Vector Search. Este enfoque híbrido evita la fragilidad de los sistemas completamente generativos, al tiempo que permite una interacción flexible y natural.
Aunque Coach’s Corner tiene sus raíces en los deportes, su arquitectura aborda un desafío universal: la "brecha de usabilidad" en los datos de alta frecuencia. La mayoría de las organizaciones poseen volúmenes masivos de datos que permanecen inactivos a nivel operativo porque carecen de un sistema para traducir las entradas sin procesar en decisiones inmediatas. Este proyecto demuestra que al unificar la ingesta, la transformación y la AI dentro de un único marco de gobernanza, se elimina la fricción entre los datos y la acción.
La implicación no es solo tener paneles más rápidos, sino un cambio en la forma en que se toman las decisiones. Cuando los insights se pueden generar, validar y entregar dentro del mismo sistema en cuestión de segundos, el papel de los datos evoluciona de un análisis retrospectivo a una participación activa en la toma de decisiones. Esa es la diferencia entre observar el juego e influir en él.
La vista de agentes a continuación es ese patrón expresado en su totalidad: a partir de los datos de seguimiento y los eventos del partido, el agente supervisor extrae la firma de estilo de un equipo, busca partidos similares, llama a un modelo xG y luego le pide a un LLM que sintetice todo en un dossier. El entrenador no ve nada de esa orquestación; ve un botón con la etiqueta "Generar dossier para Brasil", un rastro de razonamiento que puede inspeccionar si lo desea y un informe guardado que pasa a formar parte de su plan de juego.

Concebido inicialmente como una aplicación centrada en los deportes, Coach’s Corner ha evolucionado hasta convertirse en un modelo definitivo para los sistemas modernos de datos e IA dentro del sector del entretenimiento en vivo. Al almacenar los datos brutos una sola vez y refinarlos a través de pipelines confiables, el sistema garantiza que la información se entregue a través de la ruta óptima para cada carga de trabajo específica. Este proceso transforma las entradas brutas en inteligencia gobernada y procesable, disponible en el momento preciso de la decisión. La conclusión principal de esta iniciativa es clara: cuando la gestión de datos, el servicio y la IA se unifican en una sola plataforma, los insights se convierten en acciones inmediatas.
¿Quiere crear algo como esto? Explore la documentación de Databricks Apps para implementar su propia aplicación de datos full-stack, vea cómo Lakebase lleva el servicio Postgres de milisegundos al lakehouse y aprenda cómo Genie y Agent Bricks añaden inteligencia gobernada en lenguaje natural sobre sus datos, todo bajo un único Unity Catalog.
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.