【要約】Garmin Exportで過去データが消えた。Snapshot Accumulationを実装した理由 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がGarminのデータを定期取得する際、最新分のみを保持する運用では、過去データが消失するリスクがあった。具体的には以下の課題に直面した。
- ・Garmin Exportのファイル構成が、取得タイミングによって変動する。
- ・睡眠データ等のJSONファイルにおいて、特定の期間が次のExportで欠落する事例を確認。
- ・「データの不在」が「Garmin側の削除」か「仕様」か判別不能。
- ・最新分での上書きは、長期的な傾向分析や再現性を損なう。
// Approach
開発者は、最新のExportを置き換えとせず、各Exportを独立した「観測」として蓄積する手法を採用した。
- ・Snapshot Storeに各Exportの原本を読み取り専用で登録。
- ・「Missing-Is-Not-Delete」の原則に基づき、後のExportに存在しないデータも削除しない。
- ・DatasetごとのMerge Policyを適用し、absentやnullを区別してCanonical Viewを再構築。
- ・snapshot_lineage.json等のアーティファクトを出力し、データの由来を可視化。
// Result
Garmin Running Data Normalizer v1.2にて、4回のExportを用いた検証を行い、データの整合性を確保した。
- ・6通りのSnapshot間比較、24通りの登録順、13件の失敗/回復シナリオすべてでPASS。
- ・元のExport内容の変更は0件であることを確認。
- ・データの欠落を恐れず、長期的なAI分析が可能な基盤を構築。
Senior Engineer Insight
> データ整合性を最優先した堅実な設計である。ETLにおいて「不在＝削除」と見なす設計は、外部APIを扱う際に致命的な欠陥を招く。本手法は、計算コストを許容してでも、データの「再現性」と「由来」を担保しており、時系列分析において高い信頼性を提供する。ただし、Snapshot Storeの管理はバックアップとは別個の運用が必要であり、運用の複雑性は増す。