DDIA 第12章：データシステムの未来

読書進行中 — 2026-06-04に開始、続きは後日。

Designing Data-Intensive Applicationsの第12章は締めくくりの章。基礎の10章とバッチ・ストリーム処理の2章の後、一歩引いて問いかける：これらの要素はどう組み合わさり、データ集約システムはどこへ向かうのか？

データ統合：専門ツールの組み合わせ

現代のシステムは、すべてを1つのデータベースで賄うことはほとんどない。チームはOLTPデータベース、検索インデックス、キャッシュ、データウェアハウス、ストリームプロセッサ、MLパイプラインを組み合わせる — それぞれが特定の仕事に最適化されている。

難しい問題は、source of truthが変わったときに派生データセットを一貫して保つこと。これまでの章のパターンが再登場する：

第11章の Change Data Capture (CDC)
イベントソーシングと不変ログ
バックフィルと分析のための バッチパイプライン
ニアリアルタイム更新のための ストリーム処理

この章は、孤立したコンポーネントではなく、データフロー — データがシステム間をどう移動し変換されるか — の観点で考えることを提唱する。

データベースのアンバンドル

従来のデータベースは、ストレージ、インデックス、クエリ言語、レプリケーション、トランザクション処理を1つの製品に束ねている。

トレンドは アンバンドル：各アクセスパターン（ドキュメント、グラフ、時系列、検索）に最適な専門ストアを使い、ストリームとバッチジョブで接続する。

トレードオフ：

ユースケースごとに柔軟性とパフォーマンスが向上
運用の複雑さが増す — 統合レイヤーは自分たちで担う
スキーマ、系譜（lineage）、正確性のための強い規約が必要

バッチとストリーム処理：表裏一体のコイン

第10章（バッチ）と第11章（ストリーム）は別物に見えた。第12章はそれらを統一する：

どちらも不変ログまたはデータセットから 派生データ を処理する
ストリーム = 低レイテンシ、継続的；バッチ = 高スループット、履歴からのreplay
現代のエンジン（Flink、Spark Structured Streaming、Kafka）は境界を曖昧にする — 同じログ、異なる消費モード

Kappa vs Lambda の再考：目標は可能な限り1つの論理パイプラインであり、2つの分岐したコードベースではない。

正確性のための設計

分散システムでは 正確性（correctness） が微妙になる。主要な考え方：

エンドツーエンドの整合性

個々のコンポーネントは正しくても、システム全体としてデータを失ったり重複させたりする可能性がある。修正にはパイプライン全体を横断して考える必要がある：

冪等書き込み（第11章、メッセージキュー）
達成可能な範囲での exactly-onceセマンティクス（多くの場合、魔法ではなく冪等性 + 重複排除による）
信頼性の高い伝播のための トランザクションアウトボックス と CDC

制約と調整

より強い保証（一意性、サービス間の外部キー）が必要な場合、調整（coordination） が必要 — ロック、リース、またはコンセンサス（第9章の一貫性とコンセンサスに戻る）。

この章は警告する：調整には コスト（レイテンシ、可用性）がある。ビジネスが本当に必要とする場所でのみ使うこと。

適時性と整合性

整合性（integrity） = 破損なし、データ損失なし。適時性（timeliness） = ユースケースに十分新鮮なデータ。

これらは独立している — 正しいが古いデータも、新鮮だが間違ったデータもありうる。両方を明示的に設計する。

派生データとアプリケーション設計

アプリケーションはデータベースを、イベントログまたは上流の正からの 派生状態のキャッシュ として扱うべき — 常に最終的な権威としてではない。

この考え方は以下の場面で役立つ：

バグ後のインデックス再構築
新しい読み取りモデルの追加（CQRSスタイル）
ストレージシステムの移行

データフローの負荷と調整

複雑なパイプラインには、ステージ間の スケジューリング、バックプレッシャー、モニタリング が必要。10段階中7段階目の障害が、下流のconsumerを静かに破損させてはならない。

運用上の懸念：パイプラインステージ間のスキーマ進化、修正後のreplay、ソースイベントに対する派生出力のテスト。

倫理と未来

最終セクションは 人間への影響 に目を向ける：

予測分析と行動データ — ユーザー行動を形作るフィードバックループ
プライバシー — 同意、データ最小化、削除権 vs 不変ログ
アルゴリズム的説明責任 — 自動化システムがユーザーを害したとき、誰が責任を負うのか？
競争優位としてのデータ — 少数のプラットフォームへのデータ権力の集中

Kleppmannは締めくくりで思い出させる：エンジニアは実在の人々に影響を与えるシステムを構築する。倫理的な省察なしの技術的卓越性は不完全である。

要点（下書き — 読書進行中）

データ統合が現代アーキテクチャの中心的課題 — 1つのデータベースを選ぶことではない
ストレージ/クエリ/インデックスを アンバンドル し、ログ、CDC、バッチ、ストリームで統合する
バッチとストリームは同じ不変データ上の 補完的なモード
エンドツーエンドの正確性には冪等性、信頼性の高い配信、パイプライン全体の思考が必要
整合性と適時性は別次元 — 両方を明示的に設計する
未来にはより専門化されたツールとデータの使い方に対するより大きな責任が含まれる

章を読み終えた後に更新予定。

🌐 Claudeによる翻訳