Erstellen einer Fußball-Coaching-App auf Databricks

Tracking-Daten sind heute das aussagekräftigste Signal im Sport, aber die eigentliche Herausforderung besteht darin, diese Daten in etwas Nutzbares für Trainer zu verwandeln.

Ein modernes Spiel wird mit 25 Frames pro Sekunde (fps) aus 19 separaten Feeds erfasst: jeder Spieler, der Ball und jedes Ereignis, viele Male pro Sekunde. Für ein einziges Turnier sind das 339 Spiele und 51 Millionen Zeilen an Tracking-Daten. Dennoch ist fast nichts davon für die Person nutzbar, die es am dringendsten benötigt. Ein Trainer auf der Bank kann keine Tabelle mit 51 Millionen Zeilen lesen. Coach's Corner schließt diese Lücke – vollständig auf einer einzigen Plattform.

Die Herausforderung liegt nicht nur in der Skalierung, sondern auch im Timing und der Kognition. Trainer treffen Entscheidungen in Sekundenschnelle, nicht in Minuten, während traditionelle Analyse-Workflows vom Gegenteil ausgehen: Batch-Verarbeitung, Offline-Dashboards und Analysen nach dem Spiel. Selbst wenn Erkenntnisse vorliegen, sind sie oft in Tools verborgen, die erst von Analysten interpretiert und weitergegeben werden müssen. Dadurch entsteht ein struktureller Engpass: Die Daten sind reichhaltig und die Modelle sind hochentwickelt, aber der Entscheidungsträger ist im entscheidenden Moment praktisch blind.

Lernen Sie Coach’s Corner kennen – „La Pizarra“

La Pizarra („die Taktiktafel“) ist eine technische Bank für Nationalmannschaften, die als Databricks App läuft. Ein Trainer wählt ein Spiel aus und spielt es in 2D oder 3D ab, schwenkt die Kamera von der Übertragungsperspektive in eine taktische Draufsicht und spult mit bis zu 8-facher Geschwindigkeit vor oder zurück. Über das Replay werden die entscheidenden Analysen gelegt: Schuss- und xG-Karten, Passnetzwerke, Heatmaps, Standardsituationen, Teamformation, Spielfeldkontrolle, Ballspuren und Laufwege der Spieler. In die Replay-Funktionen sind mehrere fortschrittliche Tools integriert: eine umfassende Tabellenansicht, ereignisgesteuerte Analysen, eine einzigartige Scout-Stilsignatur zur Bewertung jedes Teams und ein Tactical Agent, der auf Abruf Dossiers über bevorstehende Gegner erstellen kann.

Die Bank-Ansicht legt das gesamte Spiel in die Hände des Trainers und ermöglicht nahtlose Übergänge zwischen der Übertragungs- und der taktischen Draufsicht. Mit 8-fachem Spulen und automatischen Overlays für Passwege und Heatmaps werden taktische Elemente wie Spielfeldkontrolle und Teamformation zu greifbaren Mustern auf dem Spielfeld statt zu abstrakten Kennzahlen.

Das technische Fundament von Coach's Corner folgte einem einzigen Leitprinzip: Die Benutzeroberfläche musste als Erweiterung des natürlichen Instinkts eines Trainers funktionieren und nicht als komplexes Analyseinstrument. Dies erforderte ein Design, das den Interaktionsaufwand reduziert, den räumlichen Kontext gegenüber traditionellen Diagrammen bevorzugt und jede Kennzahl als dynamisches Element des Spiels darstellt. Durch die direkte Verankerung von Erkenntnissen auf dem Spielfeld erübrigt die Anwendung eine manuelle Dateninterpretation und liefert kritische Analysen genau dann, wenn sie am relevantesten sind.

Eine Plattform, jeder Schritt

Das eigentliche Data Engineering findet im Hintergrund statt. Rohe Tracking-Feeds landen als NDJSON in einem Unity Catalog Volume, wo Auto Loader sie inkrementell über das Lakeflow Connect-Muster einliest. Von dort aus verarbeiten Spark Declarative Pipelines die Daten über Bronze-, Silber- und Gold-Stufen, die vollständig serverlos auf Photon laufen, wobei 46 definierte Erwartungen an die Datenqualität durchgesetzt werden. Die finalen Gold-Tabellen, einschließlich einer Frame-Tabelle mit 51 Millionen Zeilen, nutzen Liquid Clustering, um Abfrageantwortzeiten von 1–3 Sekunden über DBSQL auf einem kleinen Warehouse zu ermöglichen. Durch die Konsolidierung aller Volumes, Tabellen, Modelle und Indizes in einem einzigen Unity Catalog macht die Architektur herstellerspezifischen Glue-Code und sekundäre Governance-Systeme überflüssig.

Die Architektur hat Fragmentierung bewusst vermieden, indem sie dem Trend zu spezialisierten Microservices widerstanden hat. Anstatt Ingestion, Transformation, Serving und AI-Orchestrierung in isolierte, lokal optimierte Stacks aufzuteilen, blieb das System auf einer einzigen Plattform vereint. Alles innerhalb von Databricks zu belassen, bedeutete zwar den Verzicht auf etwas theoretische Flexibilität, brachte dafür aber operative Kohärenz: eine einzige Governance-Ebene, konsistente Lineage und kein Impedanz-Mismatch zwischen den Systemen. Dies wird besonders wichtig, wenn AI ins Spiel kommt, da sich die Kosten für unkontrollierte oder inkonsistente Daten schnell summieren.

Spark Declarative Pipelines definieren Zuverlässigkeit neu, indem sie von einem imperativen zu einem expliziten Modell wechseln. Anstatt sich auf starre Jobs mit impliziten Annahmen zu verlassen, behandelt das System die Datenqualität als Kernanliegen, indem es formale Erwartungen durchsetzt. Diese Suite von 46 Erwartungen erfüllt einen doppelten Zweck: Sie sichert die Pipeline in Echtzeit und stellt die „Korrektheit“ der Daten für nachgelagerte Consumer sicher, einschließlich Replay, Analysen und AI-Agents.

Das folgende Diagramm zeigt die Architektur, die die Bank-Ansicht antreibt. Ganz oben befinden sich die Bereiche, mit denen ein Trainer interagiert: Replay, Analyse, Scout, Tabelle und Agents. In die Mitte wird jeder dieser Bereiche durch kontrollierte Ebenen gestützt: Unity Catalog für Daten und Modelle, Lakehouse und Lakebase für analytisches und transaktionales Serving sowie Vector Search für Ähnlichkeitssuchen. Ganz unten befindet sich die Rohdatenbasis, mit der alles beginnt: 25-fps-Tracking-Feeds, Spielereignisse, Spielerprofile und Aufstellungen, die alle in einem Open Lake landen.

Optimierte Serving-Pfade für Geschwindigkeit und Skalierbarkeit

Um Spitzenleistungen zu garantieren, nutzt die Anwendung zwei unterschiedliche Architekturpfade für den Datenabruf. Schnelle Tracking-Replays werden von Lakebase unterstützt, das Gold-Tabellen mit Postgres synchronisiert, um Frame-Abrufe im Millisekundenbereich zu ermöglichen. Da der Browser-Takt nur die erforderlichen Frames abruft, anstatt ganze Spiele zu scannen, bleibt die interaktive Nutzung flüssig. Umgekehrt werden rechenintensive Ereignisanalysen über die Statement Execution API an das SQL-Warehouse geleitet, wodurch aufwendige Berechnungen vom reaktionsschnellen 3D-Replay getrennt bleiben.

Diese bewusste Aufteilung zwischen Lakebase und DBSQL trägt unterschiedlichen Zugriffsmustern Rechnung und nicht nur der reinen Geschwindigkeit. Replay-Funktionen erfordern sequentielle, latenzempfindliche Lesevorgänge über bestimmte Datensegmente, während analytische Workloads oft explorativ sind und umfassende Scans von Datensätzen erfordern. Durch die Isolierung dieser Pfade läuft jeder Workload in seiner idealen Umgebung. Dies verhindert, dass Lastspitzen bei Analysen das Replay-Erlebnis beeinträchtigen oder eine unnötige Überbereitstellung erfordern.

Die Trennung zwischen Lakebase und DBSQL ist nicht nur eine Frage der Performance, sondern der Zugriffsmuster. Replay-Workloads sind stark sequentiell und latenzempfindlich und erfordern vorhersagbare Lesevorgänge im Millisekundenbereich über schmale Datensegmente. Analytische Abfragen hingegen treten stoßweise auf, sind explorativ und scannen oft größere Teile des Datensatzes. Der Versuch, diese in einer einzigen Serving-Ebene zu vereinen, würde entweder das Replay verlangsamen oder die Analysen überdimensionieren. Die Aufteilung der Pfade ermöglicht es jedem Workload, ohne Kompromisse in seiner idealen Umgebung zu laufen.

Eine AI-Scouting-Ebene, basierend auf kontrollierten Daten

Die Intelligenz setzt direkt auf denselben kontrollierten Daten auf, niemals daneben. Der Scout-Chat wird durch einen echten Genie-Space unterstützt, der die in natürlicher Sprache gestellten Fragen eines Trainers in kontrolliertes SQL übersetzt. Vector Search ermöglicht die Suche nach „ähnlichen Spielern“ über einen Spielerprofil-Index. Das Gegner-Dossier wird von einem Agenten erstellt: Ein Agent Bricks-Supervisor orchestriert Genie, Vector Search und ein in Unity Catalog registriertes xG-Modell und ruft Claude auf Model Serving über das Unity AI Gateway für kontrollierte, beobachtbare LLM-Aufrufe auf. Jeder Schritt wird in MLflow protokolliert, und der Agent verfügt immer über ein deterministisches, skriptbasiertes Fallback, sodass er vor Publikum nie in einer Sackgasse landet. Da er denselben Katalog liest, den der Trainer auf der Tafel sieht, bleiben die Antworten konsistent mit den Daten.

In der unten gezeigten Scout-Ansicht schreibt der Trainer keine Abfragen; er stellt Fragen so, wie er es in der Kabine tun würde. Genie nimmt „Frage zu xG vs. xBA“ und wandelt dies im Hintergrund in kontrolliertes SQL um, wobei dieselben Tracking- und Ereignisdaten verwendet werden, die auch die Bank-Ansicht antreiben. Die Antwort ist keine generische LLM-Reaktion; sie basiert auf den exakten Tabellen und Modellen, die in Unity Catalog registriert sind, sodass die Analyse des Scouts mit den Zahlen übereinstimmt, die auch der Analyst sehen würde.

Eines der schwierigsten Probleme in der angewandten AI ist nicht das Generieren von Antworten, sondern sicherzustellen, dass sie nachvollziehbar und begründbar sind. Im Trainer-Kontext ist eine falsche oder nicht überprüfbare Erkenntnis schlimmer als gar keine. Indem jede AI-Interaktion in Unity Catalog verankert und alle Modellaufrufe über das Unity AI Gateway geleitet werden, ist jede Antwort mit kontrollierten Daten und beobachtbaren Ausführungspfaden verknüpft. So können Trainer und Analysten nicht nur dem Ergebnis vertrauen, sondern auch dem Prozess dahinter.

Die Agent-Architektur spiegelt auch eine Tendenz zum Determinismus wider. Während das LLM für Synthese und Formulierung sorgt, werden kritische Schritte wie Datenabruf, Metrikberechnung und Ähnlichkeitssuche von strukturierten Systemen wie Genie und Vector Search übernommen. Dieser hybride Ansatz vermeidet die Fehleranfälligkeit rein generativer Systeme und ermöglicht dennoch eine flexible, natürliche Interaktion.

Warum das wichtig ist

Obwohl Coach’s Corner im Sport verwurzelt ist, adressiert seine Architektur eine universelle Herausforderung: die „Nutzbarkeitslücke“ bei hochfrequenten Daten. Die meisten Unternehmen verfügen über riesige Datenmengen, die operativ ungenutzt bleiben, weil ihnen ein System fehlt, um rohe Inputs in sofortige Entscheidungen zu übersetzen. Dieses Projekt beweist, dass durch die Vereinigung von Ingestion, Transformation und AI in einem einzigen Governance-Framework die Reibung zwischen Daten und Handeln eliminiert wird.

Die Folge sind nicht nur schnellere Dashboards, sondern eine grundlegende Veränderung der Entscheidungsfindung. Wenn Erkenntnisse innerhalb desselben Systems in Sekundenschnelle generiert, validiert und bereitgestellt werden können, entwickelt sich die Rolle von Daten von der retrospektiven Analyse hin zur aktiven Mitgestaltung von Entscheidungen. Das ist der Unterschied zwischen dem Beobachten des Spiels und dessen Beeinflussung.

Die unten dargestellte Agenten-Ansicht zeigt dieses Muster in seiner reinsten Form: Ausgehend von Tracking-Daten und Spielereignissen ruft der Supervisor-Agent das Stilprofil eines Teams ab, sucht nach ähnlichen Spielen, ruft ein xG-Modell auf und bittet dann ein LLM, all dies in einem Dossier zusammenzufassen. Der Trainer sieht nichts von dieser Orchestrierung. Er sieht lediglich eine Schaltfläche mit der Aufschrift „Dossier für Brasilien erstellen“, einen Argumentationspfad, den er bei Bedarf einsehen kann, und einen gespeicherten Bericht, der Teil seines Matchplans wird.

Ursprünglich als sportorientierte Anwendung konzipiert, hat sich Coach’s Corner zu einem wegweisenden Entwurf für moderne Daten- und KI-Systeme im Live-Entertainment-Sektor entwickelt. Indem Rohdaten einmalig erfasst und über zuverlässige Pipelines verfeinert werden, stellt das System sicher, dass Informationen über den optimalen Pfad für jeden spezifischen Workload bereitgestellt werden. Dieser Prozess transformiert Rohdaten in kontrollierte, direkt nutzbare Erkenntnisse, die genau im Moment der Entscheidung zur Verfügung stehen. Die wichtigste Erkenntnis aus dieser Initiative ist klar: Wenn Datenmanagement, Serving und KI auf einer einzigen Plattform vereint sind, werden Erkenntnisse in sofortiges Handeln umgesetzt.

Möchten Sie so etwas Ähnliches entwickeln? Erkunden Sie die Dokumentation zu Databricks Apps, um Ihre eigene Full-Stack-Daten-App bereitzustellen, sehen Sie, wie Lakebase eine Postgres-Bereitstellung im Millisekundenbereich in das Lakehouse bringt, und erfahren Sie, wie Genie und Agent Bricks kontrollierte, naturalsprachliche Intelligenz auf Basis Ihrer Daten hinzufügen – alles vereint unter einem Unity Catalog.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag