クラウドストレージ上に配置される各ファイルの更新仕様をご案内します。
ファイル更新の仕様
クラウドストレージ連携で提供するデータは、種類によって更新頻度が異なります。
※データ自体の更新頻度はこちらの定義一覧をご確認ください。
ファイルの変更(新規追加・ファイル内の更新・削除)が発生した場合は、過去バージョンのファイルを残さずに置き換えます。CSVについても、変更が発生した差分レコードのみを抜き出した形ではなく、全レコードを含んだ状態のCSVとして配信されます。
また、データの変更が発生した際は、各データフォルダ配下の「update_history」「delete_history」に履歴を記録しており、変更があったファイルを確認できる仕様となっております。変更が発生しない場合はクラウドストレージ上でのファイル更新自体が行われません。
update_historyについて
各データフォルダの配下に「update_history」というフォルダを用意しております。
データの変更(ファイルの追加・ファイル内の更新)が発生した日に、「update_history」フォルダ内へ「yyyymmdd.txt」(例:20260126.txt)というテキストファイルが配置されます。テキストファイルの中には、その日に追加・更新があったファイルの絶対パスが1行ずつ記載されております。
※CSV内のレコード単位の削除は更新に該当し「update_history」に記載されますが、ファイルそのものの削除は「delete_history」に記載されます。
【例】以下のようなフォルダ構成の場合、
sample_data/
├── sample_data_2021.csv
├── sample_data_2022.csv
├── sample_data_2023.csv
├── sample_data_2024.csv
├── sample_data_2025.csv
└── update_history/
└── 20260126.txt「20260126.txt」の中身は以下のようになります。
sample_data/sample_data_2024.csv sample_data/sample_data_2025.csv
この場合、2026年1月26日の更新で「sample_data_2024.csv」 と「sample_data_2025.csv」の2ファイルに変更があったことを意味します。
「update_history」に記載されるのはファイル単位のパスのみです。
CSV内のどのレコードが変更されたかといった情報は記載されませんので、レコード単位の差分を把握されたい場合は、前回取得分のデータとの突合などの方法をご検討ください。
delete_historyについて
配信取り下げなどの理由により、弊社判断でファイルそのものを削除した場合、各データフォルダの配下に「delete_history」というフォルダを用意します。フォルダ内へ「yyyymmdd.txt」というテキストファイルが配置され、その日に削除されたファイルの絶対パスが1行ずつ記載されますので、該当ファイルに対応するローカルデータの削除等のご対応をお願いいたします。
※出力形式はupdate_historyと同様です。
※CSV内のレコード単位の削除は、ファイルとしては更新扱いとなり「update_history」に記載されます。
【例】ファイル削除発生時のディレクトリ構成
sample_data/
├── sample_data_2021.csv
├── sample_data_2022.csv
├── sample_data_2023.csv
├── sample_data_2024.csv
├── sample_data_2025.csv
├── update_history/
│ └── 20260126.txt
└── delete_history/
└── 20260126.txt
update_historyを利用した推奨データの取得方法
update_historyを利用してデータを取得する際は、前回の取得時以降に追加されたupdate_historyファイルをすべて走査し、記載されたファイルをすべて取得する方法を推奨します。
なお、delete_historyについても同様に、前回取得時以降のファイルをすべて走査し、記載されたファイルパスに対応するローカルデータの削除処理を行うことを推奨します。
- 前回データを取得した日時を記録
- update_historyフォルダ内のテキストファイルのうち、前回取得時以降のファイルをすべて取得
- 各テキストファイルに記載されたファイルパスで重複排除し、該当するすべてのファイルを取得
update_historyを活用した差分取得時に、最新の(当日分の)update_historyファイルのみを参照する実装を行う場合、後述の「臨時更新」が発生した際に一部ファイルの変更を取りこぼす可能性があります。
データの完全性を確保するため、前回取得時以降のupdate_historyファイルをすべて参照する方式での実装を推奨いたします。
臨時更新について
通常、データの更新は所定のスケジュール(日次・月次・年次)に従い、1日1回行われます。ただし、障害対応やデータ修正等の理由により、通常のスケジュール外で臨時更新を実施する場合があります。
臨時更新が行われた場合、既に作成済みのupdate_historyファイル(またはdelete_historyファイル)にファイルパスが追記されることがあります。データの取りこぼしを防ぐため、update_historyを利用した推奨データ取得方法に記載の方式での実装を推奨します。
【例】障害対応により、5月28日の定期更新後に臨時更新が行われた場合:
sample_data/
├── ...
└── update_history/
├── 20260527.txt ← 5/27の定期更新
├── 20260528.txt ← 5/28の定期更新+障害対応による臨時更新
└── 20260529.txt ← 5/29の定期更新20260528.txt の中身(12:00 - 通常の定期更新時):
sample_data/sample_data_SAMPLE001_2026.csv sample_data/sample_data_SAMPLE002_2026.csv
20260528.txt の中身(17:00 - 臨時更新後の最終状態):
sample_data/sample_data_SAMPLE001_2026.csv sample_data/sample_data_SAMPLE002_2026.csv sample_data/sample_data_SAMPLE003_2026.csv ← 臨時更新で追加 sample_data/sample_data_SAMPLE004_2026.csv ← 臨時更新で追加
5月28日は定期更新(12:00)の後、障害対応のため臨時更新(17:00)が行われ、20260528.txt にファイルパスが追記されました。
20260529.txt の中身(12:00 - 通常の定期更新時):
sample_data/sample_data_SAMPLE001_2026.csv sample_data/sample_data_SAMPLE002_2026.csv
5月29日に20260529.txt のみを参照すると、臨時更新で追加された「sample_data_SAMPLE003_2026.csv」と「sample_data_SAMPLE004_2026.csv」の2件を取りこぼします。
5月29日にデータを取得する場合は、前回取得時(例:5/28 12:00)以降に更新・追加された 20260528.txt(例:5/28 17:00)と 20260529.txt の両方に記載されたすべてのファイルを取得してください。
なお、臨時更新が発生した場合は、別途お知らせにてご案内いたします。
コメント
0件のコメント
記事コメントは受け付けていません。