在 Databricks 上打造足球教練應用程式

追蹤資料如今已是運動界最豐富的訊號，但真正的差距在於如何將資料轉化為教練實際可用的東西。

一場現代比賽由 19 個獨立畫面以每秒 25 幀（fps）捕捉：每位球員、球，以及每項事件，每秒多次。對於一場錦標賽來說，這代表 339 場比賽與 5,100 萬筆追蹤資料列。然而，這些資料幾乎無法被最需要的人使用。場邊的教練無法閱讀 5,100 萬筆資料列的表格。Coach's Corner 彌補了這道差距，完全運行在單一平台上。

挑戰不僅在於規模，還在於時機與認知。教練在數秒內做出決策，而非數分鐘，而傳統分析工作流程假設的卻是相反的情境：批次處理、離線儀表板，以及賽後檢討。即使有洞見，也被埋在需要分析師詮釋並轉達的工具之後。這在資料豐富、模型精巧，但決策者在關鍵時刻卻等同於盲目的情況下，造成結構性的瓶頸。

認識 Coach’s Corner，「La Pizarra」

La Pizarra（「黑板」）是一款國家隊技術板，以 Databricks App 形式運行。教練可選擇一場比賽，以 2D 或 3D 方式回放，切換攝影機視角，從轉播角度轉為俯視戰術視角，並以最高 8 倍速快轉。回放畫面上疊加重要分析：射門與 xG 地圖、傳球網路、熱區圖、定位球、隊形、場地控制、球跡，以及球員路徑。與回放功能整合的還有數項進階工具：完整的排名檢視、事件驅動分析、獨特的 Scout 風格簽章（用於評估任何球隊），以及能即時產生對手檔案的戰術代理。

板面視圖將整場比賽置於教練手中，讓教練可在轉播視角與戰術俯視視角之間無縫切換。搭配 8 倍速快轉以及傳球路線與熱區圖的自動疊加，場地控制與隊形等戰術元素成為場上具體的模式，而非遙遠的指標。

Coach's Corner 的技術基礎遵循單一指導原則：介面必須成為教練自然直覺的延伸，而非複雜的分析儀器。這需要降低互動負擔、偏好空間脈絡而非傳統圖表，並將每項指標呈現為比賽的動態元素。透過將洞見直接錨定在球場上，應用程式消除了手動解讀資料的需求，並在最關鍵的時刻提供關鍵分析。

單一平台，涵蓋每一個步驟

核心資料工程在幕後進行。原始追蹤來源以 NDJSON 格式存入 Unity Catalog Volume，Auto Loader 使用 Lakeflow Connect 模式逐步擷取。接著，Spark Declarative Pipelines 透過 bronze、silver 與 gold 層級處理資料，完全以 Photon 無伺服器方式執行，並強制執行 46 項命名資料品質期望。最終的 gold 表格（包含 5,100 萬筆的幀表格）利用 liquid clustering，透過小型倉儲上的 DBSQL 達成 1–3 秒的查詢回應時間。將所有 volume、表格、模型與索引整合至單一 Unity Catalog，架構消除了供應商黏著碼與次要治理系統。

此架構刻意避免碎片化，拒絕走向專業化微服務。而非將擷取、轉換、服務與 AI 編排拆分為獨立、局部最佳化的堆疊，系統保持在單一平台上統一。將所有事物保留在 Databricks 內部，犧牲部分理論上的彈性，換取運作一致性：單一治理層、一致的血緣，以及系統間無阻抗不匹配。當引入 AI 時，這點尤其重要，因為未受治理或不一致資料的代價會快速累積。

Spark Declarative Pipelines 透過從命令式模型轉為明確模型，重新定義可靠性。系統不再依賴內嵌假設的僵化工作，而是將資料品質視為首要考量，強制執行正式期望。這套 46 項期望具有雙重目的：即時保護管線，並為下游使用者（包含回放、分析與 AI 代理）建立資料「正確性」。

下圖為驅動板面視圖的架構。頂層是教練接觸的體驗：回放、分析、球探、排名與代理。中間層，每項體驗都由受治理的層級支援：資料與模型的 Unity Catalog、分析與交易服務的 Lakehouse 與 Lakebase，以及相似度的 Vector Search。最底層是所有一切的原始來源：25 fps 追蹤來源、比賽事件、球員檔案與陣容，全數進入開放湖。

針對速度與規模的最佳化服務路徑

為確保峰值效能，應用程式採用兩種不同的資料擷取架構路徑。高速追蹤回放由 Lakebase 提供支援，將 gold 表格同步至 Postgres，以實現毫秒級的視窗幀讀取。讓瀏覽器時鐘僅拉取必要幀，而非掃描整場比賽，系統維持流暢的互動體驗。反之，沉重的事件分析則透過 Statement Execution API 路由至 SQL 倉儲，將密集運算查詢與反應靈敏的 3D 回放分開。

在 Lakebase 與 DBSQL 之間刻意分流，針對的是不同的存取模式，而非僅追求原始速度。回放功能需要對特定資料區段進行順序、延遲敏感的讀取，而分析工作負載通常是探索性的，需要廣泛的資料集掃描。透過隔離這些路徑，每項工作負載在理想的環境中運作，避免分析尖峰降低回放體驗，或造成不必要的過度佈建。

Lakebase 與 DBSQL 之間的分離不僅關乎效能，還關乎存取模式。回放工作負載高度順序且對延遲敏感，需要在狹窄的資料切片上進行可預測的毫秒讀取。另一方面，分析查詢是突發且探索性的，通常掃描資料集的較大部分。嘗試將兩者統一到單一服務層，要麼會拖慢回放，要麼會過度佈建分析。分割路徑讓每項工作負載在理想環境中運作而不妥協。

以受治理資料為基礎的 AI 球探層

智慧建構在相同的受治理資料上，而非旁邊。Scout 聊天由真實的 Genie space 支援，將教練的自然語言問題轉換為受治理的 SQL。Vector Search 在球員檔案索引上提供「相似球員」功能。對手檔案是一個代理：Agent Bricks 監督者協調 Genie、Vector Search 與 Unity Catalog 註冊的 xG 模型，並透過 Unity AI Gateway 呼叫 Model Serving 上的 Claude，以進行受治理、可觀察的 LLM 呼叫。每一步驟都在 MLflow 中追蹤，代理總是有確定性的指令碼備援，因此永遠不會在觀眾面前卡住。因為它讀取與教練在板面上看到的相同目錄，答案與資料保持一致。

在下方的球探視圖中，教練無需撰寫查詢；他們以更衣室內的提問方式提問。Genie 接收「詢問 xG vs xBA」，並安靜地轉換為受治理的 SQL，使用與驅動板面的相同追蹤與事件資料。答案不是一般的 LLM 回應；它建構在 Unity Catalog 中註冊的確切表格與模型上，因此球探的敘述與分析師看到的數字相符。

應用式 AI 最困難的問題之一，不是產生答案，而是確保答案可追溯且有據可查。在教練情境中，錯誤或無法驗證的洞見比沒有洞見更糟。透過將每項 AI 互動建構在 Unity Catalog 上，並將所有模型呼叫路由至 Unity AI Gateway，每項回應都連結回受治理的資料與可觀察的執行路徑。這讓教練與分析師不僅信任輸出，也信任背後的流程。

代理架構也反映出對確定性的偏好。雖然 LLM 提供綜合與敘述，關鍵步驟如資料擷取、指標運算與相似度搜尋，仍由 Genie 與 Vector Search 等結構化系統處理。這種混合方法避免了完全生成式系統的脆弱性，同時仍能實現靈活、自然的互動。

為什麼重要

雖然 Coach’s Corner 根植於運動，其架構卻解決了一個普遍挑戰：高頻資料中的「可用性差距」。大多數組織擁有大量資料，但因缺乏將原始輸入轉化為即時決策的系統，這些資料在運作上保持沉默。這個專案證明，透過在單一治理框架內統一擷取、轉換與 AI，資料與行動之間的摩擦得以消除。

其意涵不僅是更快的儀表板，而是決策方式的轉變。當洞見能在同一系統內數秒生成、驗證並傳遞，資料的角色從回顧性分析演變為主動參與決策。這就是觀察比賽與影響比賽的差別。

下方的代理視圖完整呈現這種模式：從追蹤資料與比賽事件開始，監督代理拉取球隊的風格簽章、搜尋相似比賽、呼叫 xG 模型，然後要求 LLM 將所有內容綜合為一份檔案。教練看不到任何 orchestration；他們看到標示「為巴西生成檔案」的按鈕、可供檢查的推理追蹤，以及成為賽前計畫一部分的已儲存報告。

Coach’s Corner 最初構想為運動導向應用程式，後來演變為現場娛樂產業中現代資料與 AI 系統的決定性藍圖。透過一次載入原始資料，並透過可靠管線精煉，系統確保資訊透過每個特定工作負載的最佳路徑提供。此程序將原始輸入轉化為受治理、可行動的智慧，並在決策的精準時刻提供。主要收穫明確：當資料管理、服務與 AI 統一在單一平台上，洞見即轉化為即時行動。

想打造類似應用程式嗎？請探索 Databricks Apps 文件以發佈您自己的全端資料應用程式，了解 Lakebase 如何將毫秒級 Postgres 服務帶入湖屋，並學習 Genie 與 Agent Bricks 如何在您的資料上新增受治理的自然語言智慧，所有功能皆在單一 Unity Catalog 下運作。