# データ統合 ## 定義 データ統合(data integration)とは、単一のソフトウェアツールではアプリケーションの多様な用途(記録・検索・分析・機械学習・通知等)すべてを効率よく満たせないために、複数の専用ツールを組み合わせて使わざるを得なくなったとき、「データをどこへ最初に書き、どの表現をどこから導出するか」を設計する課題である。OLTPデータベースと全文検索インデックスの統合が典型例で、データウェアハウス・キャッシュ・機械学習パイプライン・通知システムなど表現の数が増えるほど統合の難度は増す。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Data Integration", "Combining Specialized Tools by Deriving Data") ## データフローの推論と全順序の限界 データ統合を解く鍵は、データがどのシステムから来てどう流れるかを明確にすることにある。変更データキャプチャ(CDC)やイベントソーシングログによって、記録系への書き込みだけを新規データの唯一の入口とし、その変更を単一の全順序で他の導出データシステムへ伝播させれば、各システムは(ソフトウェアのバグを除き)記録系と一貫した状態に保たれる。これは[[分散コンセンサス]]で扱う複製ステートマシンの応用であり、全順序を決めることを*全順序ブロードキャスト(total order broadcast)*と呼び、形式的にはコンセンサスと等価である。 しかし全順序の構築には限界がある。(1) スループットが単一ノードの処理能力を超えるとログをシャードせねばならず、シャード間の順序が曖昧になる。(2) 地理分散環境では、データセンタごとに個別のリーダーを置かざるを得ず、データセンタをまたぐイベントの順序が定義されない。(3) マイクロサービスでは各サービスが独立した永続状態を持つため、サービスをまたぐイベントに順序がない。(4) オフライン対応のクライアント側状態は、サーバとは異なる順序でイベントを観測しうる。 因果的な依存関係(例: SNSでの「友達解除」の後に送る愚痴メッセージが、解除前の友達へ配信されてはならない)は、全順序が壊れると失われうる。論理タイムスタンプ([[ID生成器と論理クロック]])やイベントIDの参照による明示的な因果参照、[[結果整合性|自動衝突解決]]が部分的な緩和策として挙げられるが、汎用的な解法は存在しない。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "The limits of total ordering", "Ordering events to capture causality") ## 横断的知見 - **「専用ツールの組み合わせが不可避である」という前提を、Stonebraker の one-size-fits-all 批判と DDIA 第13章が異なる立場から補強する**: [[専用データベースシステム]]が蓄積してきた Stonebraker の主張(2005)は「汎用 RDBMS は特定ワークロードに対して専用エンジンに劣る」という**単一システム選択の観点**からの one-size-fits-all 批判だった。DDIA 第13章はこれを一歩進め、「複数の専用ツールを選んだ後、今度はそれらの間でデータをどう整合させるか」という**複数システム統合の観点**の課題を提示する。両者は同じ前提(万能な単一ツールは存在しない)から出発しながら、Stonebraker はワークロードごとのエンジン選択という「入口」の問題を、DDIA 第13章は選択後のデータ整合という「出口」の問題を扱っており、one-size-fits-all批判の帰結として必然的にデータ統合問題が生じるという因果関係を示す。(Source: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Data Integration") - **DDIA第13章が形式的手段(CDC・全順序ブロードキャスト)で解く「データがどこから来てどう流れるか」という問いを、SLO実務書はデータリネージという運用上の観点から同じ問いとして独立に立てる**: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]]は「データリネージ(data lineage)」を、データがライフサイクルの間に下流へ向かって移動する動きの記録と定義し、これを追跡できればデータの使用法とシステムの結合点の両方を判断できると述べる。DDIA第13章が記録系(record system)から導出データシステムへの伝播を全順序ブロードキャストという形式的メカニズムで解決しようとするのに対し、SLO実務書は同じ構造(上流のプロデューサー/パブリッシャー → 下流のコンシューマー/サブスクライバー)を、SLO の依存関係をサービス境界に沿って設計するための地図として扱う。すなわち「下流のサービスは上流の独立したサービスのサービス目標を考慮に入れなければならない」という実務指針は、DDIA が形式化する「導出データシステムは記録系と一貫した状態に保たれる必要がある」という要求を、信頼性計測(SLO/SLI をハンドオフポイントごとに置く)という運用言語に翻訳したものと解釈できる。ただし SLO実務書は CDC や全順序ブロードキャストのような具体的な実装機構には立ち入らず、境界の識別と目標設定の重要性を指摘するにとどまる(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]] §11.5, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Data Integration", "Reasoning about dataflows")。 ## 未解決の問い - 全順序ブロードキャストが困難な4条件(シャーディング・地理分散・マイクロサービス・オフラインクライアント)がすべて重なる大規模SNSのようなシステムでは、因果的順序をどこまで実務的に保証できているか。書籍は「将来のアプリケーション開発パターンに期待する」と述べるにとどまる。 - 専用データベースシステム(Stonebraker流の one-size-fits-all 批判)を選んだ結果として生じるデータ統合コストは、専用化によって得られる性能利得とどうトレードオフされるべきか。定量的な比較フレームワークは存在するか。 - dbt・Delta Lake/Iceberg のようなデータエンジニアリングツール([[導出データ]]の未解決の問いで既出)は、本ページが論じる「全順序ログによるデータ統合」とどう接続するか。 - SLO実務書のデータリネージ論はハンドオフポイントの識別を推奨するが、その識別作業自体を(手作業ではなく)DDIA第13章の全順序ブロードキャスト/CDCのような形式的機構でどこまで自動化・検証可能にできるか。両ソースの接続点は本ページではまだ具体化されていない。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]("Data Integration", "Combining Specialized Tools by Deriving Data", "Batch and Stream Processing") / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]](§11.5 データリネージ) - 概念: [[専用データベースシステム]](専用ツールを選ぶ側の議論) / [[導出データ]](記録系と導出データの区別) / [[データベースのアンバンドリング]](統合を実装として具体化したもの) / [[分散コンセンサス]] / [[ID生成器と論理クロック]] / [[結果整合性]] / [[適時性と完全性]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]("Data Integration", "Combining Specialized Tools by Deriving Data", "Reasoning about dataflows", "The limits of total ordering", "Ordering events to capture causality") - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]](§11.5 データリネージ)