5100万行の追跡データを戦術判断へ変えるCoach’s Corner

Databricksは、339試合・5100万行の追跡データを、コーチが試合中に2D/3D再生、戦術分析、対戦相手調査へ使えるCoach’s Cornerへ変換した構成を紹介しました。

要点

• 19系統・毎秒25フレームの追跡データをLakeflowでbronze、silver、goldへ処理し、46の品質条件を適用します。
• 連続フレームはLakebaseからミリ秒単位で取得し、重い分析はDBSQLへ分けて1〜3秒で応答させます。
• Genie、Vector Search、登録済みxGモデル、Unity AI Gateway経由のClaudeを組み合わせ、対戦相手資料を生成します。
• AIの柔軟な文章生成と、決定的な検索・計算・フォールバックを分け、MLflowで実行を追跡します。

今回のブログ記事で語られていること

記事が扱う課題は、スポーツの追跡データが豊富でも、試合中に判断するコーチへ届かなければ価値にならないことです。一大会で339試合、19の入力、毎秒25フレーム、5100万行に達するデータを、分析担当が後からダッシュボードで説明するのでは遅すぎます。Coach’s CornerはDatabricksアプリとして、試合を2Dまたは3Dで最大8倍速再生し、シュートと期待得点、パス網、ヒートマップ、セットプレー、チーム形状、ピッチ支配、選手経路を映像上へ重ねます。コーチの直感を妨げないよう、表やグラフより空間的な文脈を前面に出しています。

データ基盤では、生のNDJSONをUnity Catalog Volumeへ置き、Auto LoaderとLakeflowのパターンで増分取り込みします。Sparkの宣言型パイプラインがブロンズ、シルバー、ゴールドの各層へ処理し、46のデータ品質条件を適用します。5100万行のフレーム表にはリキッドクラスタリングを使い、小規模なDBSQLウェアハウスで1〜3秒の分析応答を実現したと説明します。すべてのボリューム、表、モデル、索引をUnity Catalogへ置き、別々の管理層や接着コードを増やさないことも設計意図です。

表示経路は一つに統一していません。再生は狭い時間範囲を連続して読み、遅延に敏感なので、gold表をPostgres互換のLakebaseへ同期し、ブラウザーの時計に合わせて必要なフレームだけをミリ秒単位で取得します。一方、広い範囲を走査するイベント分析はStatement Execution APIからDBSQLへ送ります。AI層では、Genieが自然言語を統制されたSQLへ変換し、Vector Searchが類似選手を探します。対戦相手資料はAgent Bricksの監督役がGenie、Vector Search、Unity Catalog登録済みxGモデルを呼び、Unity AI Gateway経由のClaudeがまとめます。各段階をMLflowで追い、生成処理が失敗した場合の決定的な代替手順も用意します。

背景にあるテーマ

高頻度データの課題は保存量より、判断者が必要な瞬間に理解できる形へ変換することです。分析、トランザクション表示、検索、生成AIを同じ経路へ押し込まず、アクセス特性ごとに分ける設計が重要になります。

今回のブログ記事が関係する人

スポーツ分析担当、リアルタイムデータ基盤チーム、Databricksアプリ開発者、生成AIを意思決定画面へ組み込むプロダクトチームに関係します。

どう読むと価値があるか

実測値はこの事例の構成に依存しますが、連続再生と重い分析を別の配信層へ分ける点、生成AIを統制データと決定的処理へ接続する点は他の高頻度業務にも応用できます。

実務へのつながり

利用者が判断に使える許容時間を先に定め、連続読み取り、集計、検索、生成を分けます。AI回答には参照表、計算、モデル呼び出し、代替手順を記録し、誤答時に原因を追えるようにします。

結局、今回のブログ記事をどう読むべきか

大量データを一つのダッシュボードへ詰める事例ではなく、判断速度に合わせて配信経路を設計した事例です。統制された同じデータを、再生、分析、AIへ最適な形で渡す点が読みどころです。