30秒でわかる概要
Canonical DBを設計だけで終わらせず、実際のSQLiteとして構築し、基本整合性まで確認しました。異常データを黙って取り込まず、理由と再処理状態を追跡できる物理基盤です。
なぜ必要なのか
予測結果を評価するには、学習や検証に使ったデータがどこから来て、どの状態で受け入れられたのかを追える必要があります。入力データを確認できなければ、モデルの結果だけを見ても判断の土台が揺らぎます。
今回作ったもの
race、horse、entry、result、payoutを中心とする物理スキーマを用意し、primary key、foreign key制約とschema metadataを持たせました。
異常データはsource missing、missing key、conflicting source、parser failure、invalid/stale、unresolvedなどの理由とともにReject Ledgerへ記録します。Ingest状態はaccepted、rejected、held、retry-pendingを区別します。
確認できたこと
確認対象は7件で、すべてを判定し、未解決は0件でした。内訳はIMPLEMENTEDが5件、VERIFIEDが2件です。
実SQLiteには15の非内部テーブルを構築しました。integrity_check = okを確認し、foreign_key_checkのエラーは0件でした。旧db/keiba.dbは変更していません。
市場データの時間を分ける
市場データではavailable timeとcaptured timeを分け、将来point-in-timeで参照できる基盤を用意しています。これはオッズ取得や市場分析の完成を意味しません。その時点で知り得た情報だけを使ったのか、後から確認しやすくするための境界です。
現在の意味と限界
今回確認できたのは、Canonical DBを実際に構築し、基本整合性まで確認できたことです。予測精度、収益性、実運用性能は、この工程のEvidenceだけでは判断していません。履歴データの完全移行も未完了です。
次の検証
次は履歴データをCanonical DBへ移行し、安全に取り込めるもの、Rejectするもの、保留するもの、再処理するものを分けて品質検証します。