第3回　CAP定理と整合性モデル¶

本日の到達目標¶

CAP定理の3要素（Consistency, Availability, Partition tolerance）を定義できる
強整合性と結果整合性の違いとトレードオフを説明できる
分散環境でのデータ切り出しにおける「再現可能性」の条件を設計できる

1. 分散システムとデータ品質¶

1.1 なぜ分散システムが必要か¶

ビッグデータは単一サーバーに収まらない → データを 複数のサーバー（ノード）に分散して保存・処理する

分散システムの利点 - 大容量データの保存 - 並列処理による高速化 - 障害時の冗長性（一台壊れても動く）

分散システムの代償：データの 整合性（Consistency） が保ちにくくなる

2. CAP定理¶

2.1 定理の定義¶

CAP定理（Brewer, 2000）：分散システムは以下の3つの性質を同時にすべて満たすことはできない

性質	英語	意味
C	Consistency（整合性）	どのノードを読んでも常に最新・同一のデータが得られる
A	Availability（可用性）	システムは常に応答を返す（古いデータでも返す）
P	Partition tolerance（分断耐性）	ネットワーク障害でノード間通信が切れても動作を継続する

定理の本質：ネットワーク障害（分断）はいつか必ず起きる。
だから「P（分断耐性）はほぼ必須」→ C と A のどちらかを犠牲にせざるを得ない。

2.2 CP vs AP のトレードオフ¶

CP型システム（整合性優先） - 分断発生時：一部のノードへの書き込みを拒否してでも一貫性を守る - 例：ZooKeeper, etcd, HBase - 適用：金融取引、在庫管理（「在庫が2個ある」が全ノードで一致すべき）

AP型システム（可用性優先） - 分断発生時：古いデータかもしれないが必ず応答を返す - 例：Amazon DynamoDB, Apache Cassandra, CouchDB - 適用：SNSのタイムライン、ECサイトのカート（多少古くても影響小）

【カードに記入・3分】：機械学習の学習データとして使うデータベースは、CP型・AP型どちらが望ましいか？理由は？

3. 整合性モデル¶

3.1 強整合性（Strong Consistency）¶

定義：書き込みが完了した直後から、全ノードで同じ値が読める

書き込み: ノードA に x = 100 を書く
       ↓ 全ノードへの同期が完了するまで書き込み完了を返さない
読み取り: ノードB から x を読む → 必ず 100 が返る

代償：同期のためにレイテンシが増大する（特に地理的に離れたノード間）

3.2 結果整合性（Eventual Consistency）¶

定義：しばらく時間が経てば全ノードで同じ値になる（が、瞬間的にはズレがある）

書き込み: ノードA に x = 100 を書く（即座に完了を返す）
       ↓ バックグラウンドで他ノードへ伝播（数ミリ秒〜数秒後）
読み取り(直後): ノードB から x を読む → 古い値（例: 90）が返る可能性
読み取り(伝播後): ノードB から x を読む → 100 が返る

代償：分析時に「いつ時点の値か」が不明確になる

3.3 その他の整合性レベル¶

レベル	概要	例
線形化可能性（Linearizability）	最も強い。全操作が一本の時系列に並ぶ	etcd
逐次整合性（Sequential Consistency）	各クライアント内の順序は保証	—
因果整合性（Causal Consistency）	因果関係のある操作の順序を保証	—
読み自分の書き（Read-your-writes）	自分が書いたものは必ず自分で読める	DynamoDB（セッション内）
結果整合性	最終的に一致	Cassandra（デフォルト）

4. 分析への影響：データの切り出し問題¶

4.1 「時点の固定」の重要性¶

機械学習・統計分析で最も危険なのは特徴量と目的変数の時点がズレること

例（ECサイトの購買予測）

変数	正しい設計	間違いの例
目的変数 y	2024年1月の購買有無	—
説明変数 x1	2023年12月時点の閲覧履歴	2024年1月の閲覧履歴（未来情報）
説明変数 x2	2023年12月時点の年齢	現在の年齢（変化後）

未来の情報を使って過去を予測する「リーケージ（情報漏洩）」→ 評価は良いが実用で使えないモデルになる

4.2 再現可能な訓練・検証データの作り方¶

問題：結果整合性システムから切り出すと、読み取り時点によって値が変わる

解決策：スナップショット 1. 分析開始時点でデータを一度コピー・固定する 2. 日付付きのファイル（例：sales_2024-01-01.parquet）として保存 3. 以降の分析はすべてこのスナップショットを参照

【NGパターン】
モデルA学習（1月）: sales DBから直接読む
     ↓ （DBが更新される）
モデルB学習（3月）: sales DBから直接読む
→ モデルAとBで異なるデータを使っていて比較できない

【OKパターン】
スナップショット固定（1月1日）: data/snapshot_20240101.parquet
モデルA学習: snapshot_20240101.parquet を読む
モデルB学習: snapshot_20240101.parquet を読む
→ 同一データで比較可能

4.3 訓練・検証分割の設計¶

なぜ厳密な分割が必要か

結果整合性システムでは、「訓練データと検証データを同時に切り出さないと整合性が崩れる」

時系列データの分割

時刻: ────────────────────────────────→
       |← 訓練 →|← 検証 →|← テスト →|
                ↑         ↑
             cutoff1    cutoff2

- 時系列ではランダム分割禁止（未来の情報が訓練データに混入） - cutoff日時を固定してファイルに記録する

5. 実用的なパターン：ACID vs BASE¶

5.1 ACID（トランザクション型DB）¶

文字	性質	意味
A	Atomicity（原子性）	操作は全成功か全失敗
C	Consistency（整合性）	制約を常に満たす
I	Isolation（独立性）	同時実行されても干渉しない
D	Durability（永続性）	コミット後はクラッシュしても保持

→ 強整合性。金融・在庫など正確性が最優先の場面

5.2 BASE（NoSQL型DB）¶

文字	性質	意味
BA	Basically Available	基本的に応答を返す
S	Soft state	状態は更新なしで変化しうる
E	Eventually consistent	最終的に整合する

→ 結果整合性。スケーラビリティ優先の場面

6. 基盤リンクの整理¶

基盤概念	本回での役割	後半分析での意味
列指向	同一条件で同じ列集合を抽出する	特徴量生成の一貫性を保つ
整合性	核心：訓練/検証の時点固定	リーケージを防ぐ・再現性を確保
DAG	切り出し条件をパイプラインに固定	実験が常に同じデータで再現できる
近似	分割前の分布確認を近似集計で	高速に層化の確認ができる

7. 本日のまとめ¶

CAP定理：分散システムは C・A・P を同時に満たせない。実用上 P は必須 → C か A を選ぶ
強整合性：常に最新値・遅い。結果整合性：応答は速いが瞬間的にズレうる
分析では「いつ時点のデータか」を固定するスナップショットが再現性の鍵
時系列データではリーケージを防ぐ分割設計が不可欠

次回予告¶

第4回では DAG（有向非巡回グラフ）とウィンドウ関数 を扱う。
バッチ/ストリーム処理の依存関係と、後半で使う時間窓特徴量（移動平均・直近値・頻度）の生成方法を学ぶ。

事後課題¶

以下の問いに答えること（A4 半枚程度）：

Twitterのタイムライン（TL）は CP 型と AP 型のどちらに近いか、またその設計判断は適切か論じること。
自分が第1回で選んだデータセットで、「訓練データと検証データの時点を固定する」とはどういう意味かを具体的に説明すること。

第3回 CAP定理と整合性モデル¶