2026.08.09 AI

データバージョニングとは？方式別の設計とDVC・lakeFS採用判断を実装目線で解説【2026年版】

データバージョニングは、学習や分析に使ったデータの実体そのものに版を付け、数か月後でも同じ状態を取り出せるようにする仕組みです。この記事では、版を付ける対象を4層に分けたうえで、Git LFS・DVC・lakeFS・テーブル形式という4方式の構造差を示します。名前だけ先行しがちなDVCについては正式名称と初回の実行手順まで分解し、総容量・更新頻度・参照チーム数で方式を切り分ける基準、学習パイプラインへの組み込み順序、ストレージ費用と個人情報の削除要求という運用の壊れどころまで扱います。コードやAPIの版番号の付け方には踏み込みません。

まとめ：データバージョニングの方式選定と導入判断の要点

結論を先に置きます。データバージョニングで最初に決めるのはツールではなく、版を付ける対象と粒度です。生データ全部に版を付けようとすると容量も運用も破綻します。版が要るのは、学習ジョブが直接読む「学習用データセット」と「ラベル」の2層。ここに絞れば、残りは抽出条件の記録で足ります。

方式は総容量・更新頻度・参照チーム数で決まります。数十GBまでで1チーム完結ならDVC、数TB規模でオブジェクトストレージが既にあり複数チームが同じデータを触るならlakeFS、日次で行が追記される表形式のデータならDelta LakeやIcebergのスナップショット機能。この3分岐でほぼ収まります。

DVCはData Version Controlの略で、データの実体をリモートストレージへ逃がし、gitにはハッシュを書いた小さなメタファイルだけを残すツールです。導入コストが最も低く、dvc init から dvc push まで5コマンドで動き始めます。まず試すならここから入るのが手数の少ない順路になります。

導入の判断は再学習の頻度と監査要件で切ります。月1回以上の再学習、または「この予測はどのデータで学習したか」を第三者に説明する義務があるなら導入する。単発のPoCで再学習の予定がないなら、抽出条件をrunに記録するだけで十分です。記録の設計そのものは実験管理の記録項目とrun設計で整理しています。

データバージョニングの定義と、gitだけでは版を追いきれない構造的な理由

用語の輪郭を先に固めます。データバージョニングは、データセットの各状態に一意の識別子を与え、その識別子から中身を完全に復元できる状態を保つことを指します。復元できなければ版管理ではなく、単なる履歴メモです。

版を付ける対象｜生データ・学習用データセット・ラベル・特徴量の4層

機械学習の現場で「データ」と呼ばれるものは1種類ではありません。層ごとに変更の頻度も再現の必要性も違うため、まず対象を分解します。

生データ：業務システムやログから取り込んだままの状態。取り込み日時とソース側の主キーで追える場合が多い
学習用データセット：抽出・結合・分割を経て学習ジョブが直接読む形。ここが再現の起点になる
ラベル：アノテーション結果。人の判断が入るため、修正が入ると過去の学習結果と食い違う
特徴量：学習用データセットから計算した入力値。複数モデルで共有されると影響範囲が広がる

実務で版管理の投資に見合うのは、学習用データセットとラベルの2層です。生データはソース側の履歴で追えることが多く、二重に版を持つと容量が単純に倍増します。4層目にあたる特徴量の作り方と重要度の見方を押さえたうえで、それが複数チームで共有される段階まで来ているなら、版管理より特徴量ストアの二層構成と導入判断が扱う仕組みのほうが運用は軽くなる設計です。優先順位を付けずに4層すべてへ手を広げた現場は、たいてい半年で更新が止まります。

gitに直接入れると壊れる理由｜差分圧縮の前提とファイルサイズ上限

gitはテキストの行単位の差分を前提に設計されています。ParquetやTFRecord、画像のような形式は、中身が1レコード変わっただけでもバイト列としては別物になり、差分圧縮が効きません。コミットのたびにファイル全体が丸ごとリポジトリへ積まれ、履歴の総容量が線形に膨らんでいきます。

上限も現実的な制約になります。GitHub公式ドキュメントのGit LFS解説によると、1ファイルあたりの上限はFreeとProが2GB、Teamが4GB、Enterprise Cloudが5GB（2026年9月時点）。加えて、リポジトリをクローンした全員が過去の全世代を引き当てる構造のため、世代を重ねるほど新規参加者の初回クローンが重くなります。データを別の場所へ逃がし、gitには識別子だけを残す。4方式に共通するのはこの発想です。なお、ソースコードやAPI、DBスキーマの版番号の付け方は別の主題で、セマンティックバージョニングとAPIバージョニングの設計で扱っています。

データ版管理の4方式｜ポインタ方式とテーブル方式で分かれる管理の粒度

方式は大きく2系統に割れます。ファイル単位で識別子を持たせるポインタ系（Git LFS・DVC・lakeFS）と、テーブル全体のスナップショットを積むテーブル形式系（Delta Lake・Iceberg）です。選択で巻き戻しの粒度が変わります。

Git LFS方式｜ポインタ置換の仕組みと機械学習の現場で足りなくなる境界

Git LFSは、対象ファイルをコミット時に小さなテキストへ置き換える拡張です。リポジトリに入るのはSHA-256のオブジェクトIDとサイズを書いた数行のポインタで、実体は専用のLFSサーバへ送られます。git lfs track で拡張子を登録すれば以降は自動で振り分けられ、既存のgit操作はそのまま使えます。公式リポジトリのリリース一覧で確認できる最新版はv3.8.0系（2026年8月28日公開）。

足りなくなるのは、データセットが大きく世代が多い場合です。チェックアウト時に必要な世代の実体を取得する仕組みのため、ブランチを切り替えるたびに数GBの転送が走ります。ストレージ課金がホスティング事業者の従量制に乗る点も、自前のS3互換ストレージへ逃がしにくさとして効きます。数百MB規模のデータを少数世代だけ管理するなら手軽ですが、学習データの本命に据えるには制約が多い方式です。

DVC方式｜メタファイルをgitに残しデータ実体をリモートへ逃がす構造

DVCは、データファイルのハッシュ・サイズ・パスを書いた小さなメタファイルをgit管理下に置き、実体は指定したリモートストレージへ送る設計です。公式のコマンドリファレンスにあるとおり dvc add でメタファイルが生成され、これをgitにコミットする。実体の送受信は dvc push と dvc pull が担います。PyPIのパッケージページで確認できる最新は3.67.1系（2026年3月31日公開）、対応PythonはApache License 2.0のもとで3.9以上（2026年9月時点）。

この構造の利点は、データの版がgitのコミットと自然に対応する点にあります。あるコミットをチェックアウトし、続けてDVC側の取得を走らせれば、そのコミット時点のコード・パラメータ・データが同時に揃う。リモートの実体置き場はS3やAzure Blob Storageなどから選べ、ストレージ費用は自社の契約内に収まります。難点は、大量の小さなファイルを含むデータセットで取得が遅くなることと、gitの操作にDVC側の操作を必ず1手足す運用規律が要る点です。

lakeFS方式｜オブジェクトストレージにブランチとコミットを載せる層

lakeFSは、S3互換のオブジェクトストレージそのものにブランチ・コミット・マージの概念をかぶせるデータレイク向けの層です。公式リポジトリのリリース一覧で確認できる最新版はv1.86.0系（2026年8月5日公開）。アプリケーション側はS3互換のAPIでlakeFS越しにアクセスするため、既存のSparkジョブやデータ処理コードを大きく書き換えずに導入できます。

特徴はブランチ作成がメタデータ操作だけで完結する点です。公式のデータモデル解説が示すように、数TBのデータセットからブランチを切ってもオブジェクトの複製は発生せず、変更したオブジェクトだけが新たに書かれます。取り込んだデータの検証をブランチ上で済ませてから本流へマージする運用が、この構造で成立する仕組みです。CLIで書くと、取り込み専用のブランチを切って検証後にマージする流れは次の4コマンドに収まります。

lakectl repo create lakefs://ml-data s3://my-bucket/ml-data
lakectl branch create lakefs://ml-data/ingest-202609 -s lakefs://ml-data/main
lakectl commit lakefs://ml-data/ingest-202609 -m "add september batch"
lakectl merge lakefs://ml-data/ingest-202609 lakefs://ml-data/main

反面、サーバコンポーネントの運用が必要で、1人のデータサイエンティストが手元で始める用途には重すぎます。ブランチ名に取り込み年月を入れておくと、後から「どの取り込み分で精度が動いたか」を辿る作業が数分で済みます。

テーブル形式｜Delta LakeとIcebergが持つスナップショットと時点参照

表形式のデータなら、ファイルの版を意識せずテーブル自体の時点参照で済ませる選択肢があります。Delta Lakeは _delta_log にトランザクションログを積み、任意のバージョン番号やタイムスタンプを指定した読み出し（タイムトラベル）を提供します。公式リポジトリのリリース一覧によると最新版は4.4系（2026年8月20日公開）。Apache Icebergも同様にスナップショット単位の参照を持ち、公式のリリース一覧では1.11.0が最新版です（2026年5月20日公開）。

読み出しの書き方は公式のバッチ読み書きドキュメントにまとまっており、版番号と時刻のどちらでも指定できます。

SELECT * FROM events VERSION AS OF 128;
SELECT * FROM events TIMESTAMP AS OF '2026-06-01 00:00:00';

注意すべきは保持期間の既定値です。公式のユーティリティ解説によると、Delta Lakeの VACUUM は既定で7日より古い不要ファイルを削除対象とし、実行後はその期間を超えた時点への巻き戻しができなくなります。ログファイルの既定保持期間は30日で、delta.logRetentionDuration で変更できます。半年前の学習データを再現する要件があるなら、既定のまま運用してはいけません。テーブル作成時にまとめて延ばしておく書き方は次のとおりです。

ALTER TABLE events SET TBLPROPERTIES (
  delta.logRetentionDuration = 'interval 400 days',
  delta.deletedFileRetentionDuration = 'interval 400 days'
);

保持期間を要件に合わせて延ばすか、学習に使った時点のスナップショットを別テーブルとして固定する設計が要ります。延ばした分だけ不要ファイルが残る点は、次章の費用の話と直結します。

DVCとは｜Data Version Controlの担当範囲と最初に動かす手順

4方式のうち、名前だけが先に知られていて中身が曖昧なまま検討に入りやすいのがDVCです。読み方・担当範囲・最初の実行手順を分けて押さえると、他方式との比較がぶれなくなります。

DVCの正式名称と読み方｜Data Version Controlが版を持つ対象

DVCはData Version Controlの略で、ディー・ブイ・シーと読みます。同じ3文字の略語は会員権や車載機器など別分野にもあるため、検索で情報を集めるときは「DVC data version control」のように分野語を添えると資料が混ざりません。機械学習の文脈では、gitと並べて使うデータ版管理ツールを指します。

担当する範囲は3つに分かれます。データとモデルの実体に版を付けること、処理の依存関係を宣言してパイプラインの再実行範囲を決めること、実験の記録を残すことです。gitを置き換える道具ではなく、gitの上に乗せる層だと捉えると設計を誤りません。ライセンスはApache License 2.0で、コードはGitHubのリポジトリで公開されています。2025年の移管にともない、リポジトリの所在はiterative配下からtreeverse配下へ移りました。

最初に動かす5コマンド｜初期化からリモート登録と実体の送信までの実行手順

手元で挙動を確かめる最短経路を示します。gitリポジトリの中で初期化し、データを登録し、リモートへ送るまでが一続きです。

pip install "dvc[s3]"
dvc init
dvc add data/train.parquet
git add data/train.parquet.dvc data/.gitignore
git commit -m "track training data with dvc"
dvc remote add -d storage s3://ml-data-versions/proj-a
dvc push

3行目で生成されるのは train.parquet.dvc という数行のテキストで、中身はハッシュ・サイズ・パスだけです。実体はgitに入らず、4行目で自動生成される除外設定によってgitの追跡対象から外れます。リモートの登録方法は公式のリモートストレージ解説に一覧があり、S3・Azure Blob Storage・Google Cloud Storage・SSH・HTTPなどから選べます。別の担当者が同じ状態を復元するときは、gitのチェックアウト後に送受信コマンドの対になる dvc pull を走らせるだけです。

dvc.yamlで再実行の範囲を決める｜依存と出力を宣言する記述の型

手でコマンドを叩く段階を抜けたら、処理の依存関係をファイルに宣言します。公式のdvc.yaml解説にある構造で、各段階の入力・出力・実行コマンドを並べる形です。

stages:
  prepare:
    cmd: python src/prepare.py
    deps:
      - src/prepare.py
      - data/raw
    outs:
      - data/train.parquet
  train:
    cmd: python src/train.py
    deps:
      - src/train.py
      - data/train.parquet
    outs:
      - models/model.pkl
    metrics:
      - metrics.json:
          cache: false

この宣言があると、変更されたファイルに依存する段階だけが再実行されます。前処理のスクリプトだけを直したときに学習まで走り直す、という無駄が消える仕組みです。依存に書き漏らしたファイルは変更されても再実行の引き金にならないため、宣言の抜けは「直したはずなのに結果が変わらない」という形で表面化します。

方式の選定基準｜総容量・更新頻度・参照チーム数で切り分ける判断の軸

方式の優劣は絶対的なものではなく、案件の3つの数値でほぼ決まります。迷ったときはこの順で当てはめてください。

選定の3軸｜総容量・更新頻度・同時に参照するチーム数で決まる分岐

1つ目の軸が総容量です。全世代を合計して数十GBに収まるなら、DVCで十分に回ります。数TBを超えるとメタファイルとgit操作の組み合わせが重くなり、lakeFSのようにストレージ側で版を持つ構成へ移る判断が現実的になります。

2つ目が更新頻度。週1回のバッチ更新ならファイル単位の版で追えますが、日次で行が追記され続けるテーブルにファイル版を付けるのは筋が悪い。この場合はDelta LakeやIcebergのスナップショットに寄せます。3つ目が参照チーム数で、同じデータを2チーム以上が同時に触るなら、ブランチとマージの仕組みを持つ方式でないと衝突を裁けません。1人が手元で回す実験用データに、サーバ運用が要る方式を持ち込むのは投資として過剰です。

方式別の比較｜導入の重さ・扱えるデータ量・巻き戻しの粒度の対応表

3軸を方式に対応させると次のようになります。表の数値は2026年9月時点の各公式情報と一般的な運用規模の目安です。

方式	導入の重さ	向く総容量	巻き戻しの粒度	実体の置き場
Git LFS	軽い	数百MB程度	ファイル単位	LFSサーバ
DVC	軽い	数GB〜数十GB	ファイル単位	自社のストレージ
lakeFS	サーバ運用が要る	数TB以上	リポジトリ単位	S3互換ストレージ
Delta Lake	基盤に依存	テーブル規模次第	テーブルの時点	データレイク

混在させても構いません。実務では、テーブルはDelta Lakeの時点参照で追い、そこから切り出した学習用データセットのスナップショットだけをDVCで固定する、という組み合わせが扱いやすい形になります。1方式で全層を覆おうとすると、どこかに無理が出ます。

実装設計｜リモートストレージの構成と学習パイプラインへの組み込み手順

方式が決まったら、実体の置き場とパイプラインへの組み込み順序を設計します。ここを詰めないと、データは版管理されているのに学習ジョブがそれを読んでいない状態が起こります。

リモート設定とキャッシュ｜オブジェクトストレージを実体置き場にする構成

DVCを例にとると、実体の置き場はプロジェクト単位でリモートとして登録し、開発者の手元にはキャッシュディレクトリが作られます。同じハッシュのファイルは手元のキャッシュから復元されるため、複数のブランチを行き来しても再ダウンロードは発生しません。キャッシュが既定のままリポジトリ内に置かれると、複数プロジェクトで同じデータセットを扱う環境では実体が重複します。共有ディレクトリへ移す設定を先に入れておくとディスク消費を抑えられます。

dvc cache dir /mnt/shared/dvc-cache
dvc config cache.shared group
dvc config cache.type symlink
dvc remote add -d storage s3://ml-data-versions/proj-a
dvc remote modify storage region ap-northeast-1

3行目のリンク方式はディスク消費をさらに抑えますが、実体がキャッシュ側を指すため、学習コードがデータを書き換える処理を持っているとキャッシュを壊します。書き換えが入る前処理では、この設定を外して実体のコピーを受け取る構成にしてください。バケット設計も先に決めます。実体はハッシュ名で並び、人が見て中身を判別できません。バケットやプレフィクスをプロジェクト単位で分け、ライフサイクルルールと権限をその単位で当てられる形にしておくこと。参照が張られたあとの分割は手間がかかります。

学習パイプラインへの組み込み｜取得・学習・記録を並べる実行順序

学習ジョブの実行順序は固定します。順序が崩れると、記録された版と実際に読んだデータがずれます。

コードのコミットをチェックアウトし、データ側の取得コマンドで実体を復元する
復元したデータのハッシュまたはスナップショットIDを、実行時のパラメータとして取得する
学習を実行し、そのIDを実験管理の記録へパラメータとして残す
生成したモデルの成果物に、学習に使ったデータ版のIDをタグとして付与する

2の工程を省き、データ版のIDを人が手で書き写す運用は必ずずれます。取得コマンドの出力から機械的に読み取り、そのまま記録へ渡す実装にしてください。

実験管理とモデルレジストリとの対応付け｜データ版IDを紐づける単位

データバージョニングは単体では効きません。データ版のIDが、学習の実行記録と、本番へ出したモデルの両方から辿れて初めて再現性が成立します。学習の実行単位に何をどう記録するかは実験管理のrun設計と記録項目の領分で、データ版のIDはそこでパラメータとして残す項目のひとつになります。

本番に出したモデルの側からも同じIDを辿れる状態が必要です。障害時に問われるのは「今動いているモデルはどのデータで学習したか」であり、これに答えるにはモデルの版とデータの版が1対1で結ばれている必要があります。モデル側の版管理と本番昇格の設計はモデルレジストリの版管理と昇格フローにまとめています。紐づけの単位は、学習の実行1回に対してデータ版1つ。1回の学習で複数のデータセットを結合しているなら、結合後の成果物に版を付け直すほうが追跡は簡単になります。

運用で壊れる箇所｜ストレージ費用の膨張と個人情報の削除要求への対処

導入直後は問題が出ません。壊れるのは半年後、ストレージの請求書と、個人情報の削除要求が届いたときです。設計段階で手を打てる論点を2つ挙げます。

ストレージ費用の増え方｜世代を残す範囲と削除ポリシーの決め方の基準

版管理の費用は、データ量そのものではなく世代数との掛け算で増えます。100GBのデータセットを週次で更新し全世代を残せば、1年で5TB規模。変更されたファイルだけが新たに保存される方式であっても、画像やParquetのように全体が置き換わる形式では削減効果は小さく見積もるべきです。

削除ポリシーは、世代の性質で分けます。本番モデルの学習に使った版は削除しない。それ以外の試行錯誤の版は、保持期間を決めて自動で消す。この2分類だけで、費用の伸びは大きく変わります。判断の材料は、その版から学習されたモデルが今も稼働しているかという1点です。稼働中のモデルに対応する版を消すと、監査で説明できない状態になります。保管先の単価差を効かせる余地もあり、参照頻度が落ちた世代を低頻度アクセス向けのストレージクラスへ寄せる設定は、ライフサイクルルールで自動化できます。

個人情報を含むデータの版管理｜削除要求と履歴保持が衝突する場面

個人データを含む学習データで削除要求を受けると、全世代から該当レコードを消す必要が生じます。版管理は「過去の状態を変えない」ことを前提に作られているため、この要求と正面から衝突します。

現実的な対処は2つ。ひとつは、個人を直接識別する項目を版管理の対象へ入れない設計です。学習に使うのは仮名化・匿名化された派生データに限り、対応表は版管理の外で別途管理する。もうひとつは、版の保持期間を法令や契約で求められる期間に合わせて短く区切り、期限が来たら世代ごと物理削除する運用です。全世代を無期限に保持する設計は、個人データを含む案件では採用しないこと。

導入してよい3条件と、データバージョニングを見送るべき案件の見極め

ここは条件を付けて言い切ります。データバージョニングは、すべての機械学習案件に必要な仕組みではありません。

導入を決める3条件｜再学習の頻度・監査要件・データ量の実務的な閾値

次の3条件のうち1つでも当てはまるなら、導入する判断が合理的です。

再学習が月1回以上ある：データが更新されるたびに精度が動き、原因の切り分けにデータ版の比較が要る
監査・説明責任の要件がある：金融や医療の与信・診断支援では、学習データの特定が求められる
学習用データセットが数GBを超え、2名以上が触る：手元のファイル名運用が破綻する規模

優先度が高いのは2つ目です。監査要件は後から満たそうとしても、過去のデータが復元できなければ手の打ちようがありません。1つ目と3つ目は、破綻してから導入しても間に合います。

見送ってよい場面｜単発PoCと抽出条件の記録だけで足りる案件の条件

逆に、見送るべき場面も明確です。3か月で終わる単発のPoCで、再学習の予定がなく、担当が1名。この条件が揃うなら、データバージョニングの導入は過剰投資になります。抽出日時・抽出条件・行数・主要カラムの統計量を実験管理のパラメータとして記録しておけば、必要な再現性は確保できます。

もうひとつ見送ってよいのが、ソース側のデータ基盤が既に時点参照を持っている案件です。データウェアハウスがスナップショットを保持していて、日付指定で当時の状態を取り出せるなら、その上にもう1層の版管理を重ねる必要はありません。二重管理はどちらが正なのか分からなくなる分だけ、状況を悪化させます。

ツール選定の現況｜DVCのlakeFS移管が採用判断に与える影響と見通し

ツール選定の前提が2025年に動きました。DVCはIterativeからlakeFSを開発するTreeverseへ移管され、移管時に公開された公式のQ&Aでは、ライセンス変更・機能の有料化・アクセス制限のいずれも予定はなく、コマンドや既存ワークフローに破壊的変更はないと明記されています。位置づけは、DVCが小〜中規模のデータサイエンス案件向けの軽量ツール、lakeFSがエンタープライズのデータ基盤向けという住み分けです。

採用判断への影響は限定的と見ています。小規模から始めて大規模へ移る経路は描きやすくなり、一方で単一ベンダーへの依存度は上がりました。判断材料になるのは、DVCがApache License 2.0のオープンソースで、メタファイルの中身がハッシュとパスという単純な構造である点。開発が滞っても、実体を復元する処理は自前で書けます。この移行可能性をツール選定の基準に入れてください。製品横断の選び方はMLOpsツールの比較と選定基準で整理しています。既存のデータ基盤へ版管理を後付けする設計や、監査に耐える再現性を備えた学習基盤の構築は、機械学習モデル開発として外部の実装知見を入れながら進めると、運用に入ってからの手戻りを抑えられます。

データバージョニングの導入と運用の現場でよくある質問への実務的な回答

導入検討でつまずきやすい点を、実務で寄せられる疑問の形で整理します。

データバージョニングとバージョン管理（Git）の違いは何ですか？

対象と保存の仕組みが違います。Gitはテキストの行差分を前提にソースコードの履歴を管理する仕組みで、バイナリの大容量ファイルには差分圧縮が効きません。データバージョニングは、データの実体を別のストレージへ置き、gitには識別子だけを残すことでこの制約を回避します。両者は排他ではなく、コードをgit、データをDVCやlakeFSで管理し、コミット単位で対応させる使い方が基本形です。

DVCとは何の略で、gitと併用する前提のツールなのですか？

Data Version Controlの略で、gitと併用する前提のツールです。データの実体をリモートストレージへ送り、gitにはハッシュを書いたメタファイルだけを残すため、gitのコミットとデータの版が1対1で対応します。単体でソースコードの履歴を管理する機能は持っておらず、gitの代替にはなりません。導入はPythonパッケージを入れて dvc init を実行するところから始まり、サーバの構築は不要です。

DVCとlakeFSはどちらを選べばよいですか？

総容量とチーム数で切り分けます。全世代の合計が数十GBまでで、1チームが手元で回すならDVC。サーバ運用が不要で、gitの操作にコマンドを1つ足すだけで始められます。数TB規模のデータレイクがあり、複数チームが同じデータを同時に触るならlakeFS。ブランチ作成がメタデータ操作で完結するため、大規模でも検証用の分岐を現実的な速度で切れます。開発元が同じTreeverseに揃ったため、小規模から始めて後で移る経路も描けます。

数百GBの画像データでもデータバージョニングは現実的ですか？

現実的ですが、全ファイルに版を付ける設計は避けてください。画像は1枚ずつが独立したバイナリのため、ファイル数が多いほど取得処理が遅くなります。実務では、画像そのものは追記のみのストレージへ置いて削除しない運用とし、版を付けるのは「どの画像IDを学習に使ったか」を書いたマニフェストファイルに絞る方式が扱いやすい形になります。

データを更新するたびに全件をコピーして保存するのですか？

方式によります。DVCはファイル単位のハッシュで管理するため、変更のなかったファイルは再保存されません。lakeFSも変更されたオブジェクトだけを新たに書き、ブランチ作成では複製が発生しない構造です。ただし、1つの大きなParquetファイルを毎回書き換える形なら、ファイル単位では全体が別物になり毎回丸ごと保存されます。

個人情報を含む学習データで削除要求が来た場合はどうしますか？

過去の全世代から該当レコードを消す作業が必要になり、版管理の前提と衝突します。設計段階で回避するのが唯一の現実解です。個人を直接識別する項目は版管理の対象へ入れず、仮名化した派生データだけを管理対象にする。あわせて、版の保持期間を契約や法令で求められる期間に合わせて区切り、期限到来で世代ごと削除する運用を組んでおきます。