Construindo um aplicativo de treinamento de futebol no Databricks

Os dados de rastreamento são hoje o sinal mais rico no esporte, mas o verdadeiro desafio é transformar esses dados em algo que um treinador possa realmente usar.

Uma partida moderna é capturada a 25 quadros por segundo (fps) a partir de 19 transmissões separadas: cada jogador, a bola e cada evento, muitas vezes por segundo. Para um único torneio, isso representa 339 partidas e 51 milhões de linhas de dados de rastreamento. No entanto, quase nada disso pode ser aproveitado pela pessoa que mais precisa. Um treinador no banco de reservas não consegue ler uma tabela de 51 milhões de linhas. O Coach's Corner elimina essa barreira, totalmente em uma única plataforma.

O desafio não é apenas a escala, mas também o tempo e a cognição. Os treinadores tomam decisões em segundos, não em minutos, e os fluxos de trabalho tradicionais de análise de dados pressupõem o oposto: processamento em lote, painéis offline e análises pós-jogo. Mesmo quando existem insights, eles ficam escondidos atrás de ferramentas que exigem que um analista os interprete e os repasse. Isso cria um gargalo estrutural no qual os dados são ricos e os modelos são sofisticados, mas quem toma as decisões fica praticamente às cegas no momento mais importante.

Conheça o Coach’s Corner, “La Pizarra”

O La Pizarra (“a lousa”) é um banco técnico de seleção nacional executado como um Databricks App. O treinador escolhe uma partida e a reproduz em 2D ou 3D, mudando a câmera do ângulo de transmissão para uma visão tática de cima para baixo e avançando ou retrocedendo a até 8x de velocidade. Sobrepostos à reprodução estão as análises que importam: mapas de finalizações e xG, redes de passes, mapas de calor, jogadas ensaiadas, posicionamento da equipe, controle de campo, trajetórias da bola e caminhos dos jogadores. Integradas aos recursos de reprodução estão várias ferramentas avançadas: uma visão completa da tabela de classificação, análises orientadas a eventos, uma assinatura de estilo exclusiva do Scout para avaliar qualquer equipe e um Agente Tático capaz de gerar relatórios sob demanda sobre os próximos adversários.

A visão do banco de reservas coloca a partida inteira nas mãos do treinador, permitindo transições fluidas entre as perspectivas de transmissão e tática de cima para baixo. Com controle de velocidade de até 8x e sobreposições automatizadas para linhas de passe e mapas de calor, elementos táticos como controle de campo e posicionamento da equipe tornam-se padrões tangíveis no campo, em vez de métricas distantes.

A base técnica do Coach's Corner foi ditada por um único princípio orientador: a interface precisava funcionar como uma extensão do instinto natural do treinador, e não como um instrumento analítico complexo. Isso exigiu um design que reduzisse o esforço de interação, priorizasse o contexto espacial em vez de gráficos tradicionais e apresentasse cada métrica como um elemento dinâmico do jogo. Ao ancorar os insights diretamente no campo de jogo, o aplicativo elimina a necessidade de interpretação manual de dados e fornece análises críticas exatamente quando elas são mais relevantes.

Uma única plataforma, cada etapa

A engenharia de dados principal acontece nos bastidores. Os feeds de rastreamento brutos chegam como NDJSON em um Volume do Unity Catalog, onde o Auto Loader os ingere incrementalmente usando o padrão Lakeflow Connect. A partir daí, as Spark Declarative Pipelines processam os dados pelas camadas bronze, prata e ouro, rodando de forma totalmente serverless no Photon com 46 expectativas de qualidade de dados nomeadas e aplicadas. As tabelas ouro finais, incluindo uma tabela de quadros de 51 milhões de linhas, utilizam liquid clustering para permitir tempos de resposta de consulta de 1 a 3 segundos via DBSQL executado em um pequeno warehouse. Ao consolidar todos os volumes, tabelas termos, modelos e índices em um único Unity Catalog, a arquitetura elimina códigos de integração de terceiros (glue code) e sistemas de governança secundários.

A arquitetura evitou deliberadamente a fragmentação ao resistir à transição para microsserviços especializados. Em vez de dividir a ingestão, a transformação, a disponibilização (serving) e a orquestração de AI em pilhas isoladas e otimizadas localmente, o sistema permaneceu unificado em uma única plataforma. Manter tudo dentro do Databricks trocou um pouco de flexibilidade teórica por coerência operacional: uma única camada de governança, linhagem consistente e sem incompatibilidade de impedância entre os sistemas. Isso se torna especialmente importante quando a AI é introduzida, pois o custo de dados não governados ou inconsistentes se acumula rapidamente.

As Spark Declarative Pipelines redefinem a confiabilidade ao mudar de um modelo imperativo para um modelo explícito. Em vez de depender de jobs rígidos com premissas embutidas, o sistema trata a qualidade dos dados como uma prioridade de primeira classe, aplicando expectativas formais. Este conjunto de 46 expectativas atende a um duplo propósito: protege o pipeline em tempo real e estabelece a "exatidão" dos dados para os consumidores downstream, incluindo reprodução, análises e agentes de AI.

O diagrama abaixo mostra a arquitetura que alimenta a visão do banco de reservas. No topo estão as experiências com as quais o treinador interage: reprodução, análise, scout, classificação e agentes. No meio, cada uma dessas experiências é apoiada por camadas governadas: Unity Catalog para dados e modelos, Lakehouse e Lakebase para disponibilização analítica e transacional, e Vector Search para busca por similaridade. Na base está a realidade bruta de onde tudo começa: feeds de rastreamento de 25 fps, eventos de partida, perfis de jogadores e escalações, todos chegando a um lake aberto.

Caminhos de disponibilização otimizados para velocidade e escala

Para garantir o máximo desempenho, o aplicativo utiliza dois caminhos arquitetônicos distintos para a recuperação de dados. As reproduções de rastreamento de alta velocidade são alimentadas pelo Lakebase, que sincroniza as tabelas ouro com o Postgres para permitir leituras de quadros em janelas de tempo na escala de milissegundos. Ao permitir que o relógio do navegador puxe apenas os quadros essenciais em vez de escanear partidas inteiras, o sistema mantém uma experiência interativa fluida. Por outro lado, as análises pesadas de eventos são roteadas por meio da Statement Execution API para o SQL warehouse, mantendo as consultas computacionais intensivas separadas da reprodução 3D responsiva.

Essa bifurcação deliberada entre Lakebase e DBSQL atende a diferentes padrões de acesso, e não apenas à velocidade bruta. As funções de reprodução exigem leituras sequenciais e sensíveis à latência em segmentos de dados específicos, enquanto as cargas de trabalho analíticas costumam ser exploratórias e exigem varreduras amplas de conjuntos de dados. Ao isolar esses caminhos, cada carga de trabalho opera em seu ambiente ideal, evitando que picos analíticos prejudiquem a experiência de reprodução ou exijam superdimensionamento desnecessário.

A separação entre Lakebase e DBSQL não se trata apenas de desempenho, mas de padrões de acesso. As cargas de trabalho de reprodução são altamente sequenciais e sensíveis à latência, exigindo leituras previsíveis em milissegundos sobre fatias estreitas de dados. As consultas analíticas, por outro lado, ocorrem em picos e são exploratórias, muitas vezes varrendo partes maiores do conjunto de dados. Tentar unificar tudo isso em uma única camada de disponibilização atrasaria a reprodução ou exigiria um superdimensionamento das análises. Dividir os caminhos permite que cada carga de trabalho opere em seu ambiente ideal, sem concessões.

Uma camada de scout com AI, baseada em dados governados

A inteligência reside nos mesmos dados governados, nunca fora deles. O chat do Scout é apoiado por um espaço Genie real que converte as perguntas em linguagem natural do treinador em SQL governado. O Vector Search alimenta a busca por “jogadores semelhantes” em um índice de perfil de jogador. O relatório do adversário é um agente: um supervisor do Agent Bricks orquestra o Genie, o Vector Search e um modelo xG registrado no Unity Catalog, e chama o Claude no Model Serving por meio do Unity AI Gateway para chamadas de LLM governadas e observáveis. Cada etapa é rastreada no MLflow, e o agente sempre tem um fallback programado determinístico, para nunca ficar sem resposta diante de um público. Como ele lê o mesmo catálogo que o treinador vê na lousa, as respostas permanecem consistentes com os dados.

Na visão do scout abaixo, o treinador não está escrevendo consultas; ele está fazendo perguntas da mesma forma que faria no vestiário. O Genie recebe “Pergunte sobre xG vs xBA” e o transforma silenciosamente em SQL governado, usando os mesmos dados de rastreamento e eventos que alimentam o banco de reservas. A resposta não é um retorno genérico de LLM; ela é baseada nas tabelas e modelos exatos registrados no Unity Catalog, de modo que a narrativa do scout corresponda aos números que o analista veria.

Um de os problemas mais difíceis na AI aplicada não é gerar respostas, mas garantir que elas sejam rastreáveis e defensáveis. No contexto de um treinador, um insight errado ou não verificável é pior do que nenhum insight. Ao basear cada interação de AI no Unity Catalog e rotear todas as chamadas de modelo pelo Unity AI Gateway, cada resposta é vinculada a dados governados e caminhos de execução observáveis. Isso permite que treinadores e analistas confiem não apenas no resultado, mas no processo por trás dele.

A arquitetura do agente também reflete uma inclinação para o determinismo. Embora o LLM forneça síntese e narrativa, etapas críticas como recuperação de dados, computação de métricas e busca por similaridade são tratadas por sistemas estruturados como Genie e Vector Search. Essa abordagem híbrida evita a fragilidade dos sistemas totalmente generativos, ao mesmo tempo que permite uma interação flexível e natural.

Por que isso importa

Embora o Coach’s Corner tenha suas raízes nos esportes, sua arquitetura aborda um desafio universal: a "lacuna de usabilidade" em dados de alta frequência. A maioria das organizações possui volumes massivos de dados que permanecem operacionalmente silenciosos porque não têm um sistema para traduzir entradas brutas em decisões imediatas. Este projeto prova que, ao unificar a ingestão, a transformação e a AI dentro de uma única estrutura de governança, o atrito entre os dados e a ação é eliminado.

A implicação não é apenas dashboards mais rápidos, mas uma mudança na forma como as decisões são tomadas. Quando os insights podem ser gerados, validados e entregues no mesmo sistema em segundos, o papel dos dados evolui de uma análise retrospectiva para a participação ativa na tomada de decisões. Essa é a diferença entre observar o jogo e influenciá-lo.

A visualização de agentes abaixo é esse padrão totalmente expresso: a partir de dados de rastreamento e eventos de partida, o agente supervisor extrai a assinatura de estilo de um time, busca partidas semelhantes, chama um modelo xG e, em seguida, pede a um LLM para sintetizar tudo isso em um dossiê. O treinador não vê nada dessa orquestração; ele vê um botão rotulado “Gerar dossiê para o Brasil”, um rastro de raciocínio que pode inspecionar se desejar e um relatório salvo que se torna parte de seu plano de jogo.

Concebido inicialmente como um aplicativo focado em esportes, o Coach’s Corner evoluiu para um modelo definitivo para sistemas modernos de dados e AI no setor de entretenimento ao vivo. Ao carregar dados brutos uma única vez e refiná-los por meio de pipelines confiáveis, o sistema garante que as informações sejam servidas pelo caminho ideal para cada carga de trabalho específica. Esse processo transforma entradas brutas em inteligência governada e acionável, disponível no momento exato da decisão. A principal lição dessa iniciativa é clara: quando o gerenciamento de dados, o serving e a AI são unificados em uma única plataforma, os insights são convertidos em ação imediata.

Quer construir algo assim? Explore a documentação do Databricks Apps para implantar seu próprio aplicativo de dados full-stack, veja como o Lakebase traz o serving de Postgres em milissegundos para o lakehouse e saiba como o Genie e o Agent Bricks adicionam inteligência de linguagem natural governada sobre seus dados, tudo sob um único Unity Catalog.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original