# 導出データ ## 定義 導出データ(derived data)とは、他のデータセットに対するクエリや変換処理の結果として生成され、時間の経過とともに更新・追加され続けるデータを指す。RDBMS における「テーブル」が本来は最新状態のスナップショットを意味していたのに対し、列指向クエリエンジン(Redshift、BigQuery、Trino、Spark、DuckDB 等)の発展によって分析クエリの実行が容易になり、こうした導出データが大量に生成されるようになった結果、現代における「テーブル」は起点データそのものよりも、そこから派生した導出データを指すことが多くなっている(Source: [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]] p.19)。 導出データは技術的には冗長(既存情報の重複)だが、読み取りクエリの性能を確保する上でしばしば不可欠である。単一の記録系から複数の導出データセットを作ることで、同じデータを異なる視点から眺められるようになる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "Systems of Record and Derived Data") ## 記録系(system of record) 導出データの対概念が記録系(system of record、正典 canonical とも呼ばれる)である。記録系は権威ある正典データを保持するシステムであり、ユーザー入力のような新規データは最初に記録系へ書き込まれる。各事実は(典型的には正規化された形で)ちょうど一度だけ表現され、他システムとの間に不一致があれば記録系の値が定義上正しいとされる。 一方、導出データは既存データを変換・加工した結果であり、失われても元のシステムから再生成できる。キャッシュ・インデックス・マテリアライズドビュー・非正規化された値・データセットに対して訓練されたモデルはいずれも導出データに該当する。分析システムは他所で作られたデータの消費者であるため通常は導出データシステムであり、業務系サービスは記録系と導出データ(検索を高速化するインデックス・キャッシュ)の両方を併せ持つことが多い。 重要なのは、データベース・ストレージエンジン・クエリ言語それ自体は本質的に記録系でも導出データシステムでもないという点である。この区別はツールではなく、アプリケーションがそのツールをどう使うかに依存する。記録系にある元データが変わったとき導出データをどう更新するかという課題は、多くのデータベースが「アプリケーションは常に単一のデータベースだけを使う」という前提で設計されているために難しく、データパイプラインによる「データ統合(data integration)」という課題として書籍後半(第11章)で扱われる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "Systems of Record and Derived Data") ## 横断的知見 - **同じ「導出データ」という語を、日本語講演(1st edition ベース)と原著2nd edition が異なる粒度で導入している**: [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]] は「列指向クエリエンジンの発展によりテーブル=導出データが大量発生した」という**現代の分析基盤の観察**から導出データを説明する。一方 [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] は「記録系/導出データ」という**対概念のペア**として導入し、キャッシュ・インデックス・マテリアライズドビューといった OLTP システム内の身近な例も導出データに含める、より一般的な定義を採る。前者はデータウェアハウス以降の分析基盤の文脈に特化した観察、後者は業務系・分析系を問わない汎用的なデータフローの語彙という関係にあり、互いに矛盾しない異なる抽象度の記述である。(Source: [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]]) - **Treasure Data 社の依存関係グラフが示す「導出データの導出データ」という多段構造は、書籍が言う「ツールでなく使い方に依存する」区別を実務上難しくする一例と読める**: 講演が紹介する数千規模の依存関係グラフでは、ある導出データがさらに別の導出データの入力になるという多段のチェーンが生じる。書籍の定義に従えば連鎖のどの段も「記録系ではない導出データ」だが、実運用では連鎖の途中のどのノードが実質的な正典として扱われているかが曖昧になりやすい。この観察は書籍のいずれの一次資料にも直接の記述はなく、両ソースを突き合わせて初めて見える論点である。 - **第1章の「記録系/導出データ」という抽象的な対概念に対し、第3章はOLTPレベルの2つの具体的なインスタンスを与える——非正規化とイベントソーシングのマテリアライズドビューである**: 第1章は導出データの例としてキャッシュ・インデックス・マテリアライズドビュー・非正規化された値を挙げるにとどまるが、第3章 [[リレーショナル対ドキュメントモデル]] は非正規化を「本質的に導出データの一形態であり、冗長コピーを更新し続けるプロセスのセットアップが必要になる」と明示的に位置づけ、X(旧Twitter)のマテリアライズドタイムラインというアプリケーションレベルの実例で具体化する。同様に第3章 [[イベントソーシングとCQRS]] のマテリアライズドビュー(projection)は、イベントログという単一の記録系から複数の読み取り最適化された導出データを生成する設計パターンであり、「記録系から導出データへ」という第1章の抽象図式の、アプリケーション設計レベルでの具体的な実装方法を提示する。第1章が「記録系の変更をどう導出データへ伝播させるか」を未解決の問いとして残していたのに対し、第3章のイベントソーシングは「イベントログへの追記→複数ビューへの決定的な再計算」という具体的な伝播メカニズムの一つの答えを与える。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]]) - **第11章は「記録系の変更をどう導出データへ伝播させるか」という第1章の未解決の問いに、バッチ処理レベルでの具体的な答えを与える——直接書き込みでなくストリームへのプッシュ、または新規データベースのバルクロード**: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]] は、バッチジョブが導出データ(推薦結果・ユーザー向けレポート・ML特徴量等)を本番系サービングシステムへ反映する際、クライアントライブラリで直接データベースへ書き込む方式は低スループット・過負荷・「全か無かの保証」の喪失という3つの問題を抱えると指摘する。代わりにKafkaのようなストリームへ出力をプッシュし、ジョブ完了通知まで下流システムが未コミットとして不可視に保つ方式、またはバルクインポートツール(TiDB Lightning、RocksDBのSSTファイル取り込み等)で新規データベースを構築しアトミックに切り替える方式が実務的な代替として示される。イベントソーシング(第3章)が「イベントログへの追記→決定的な再計算」というアプリケーション設計レベルの答えを与えたのに対し、第11章は「バッチジョブの出力→ストリーム経由の伝播またはバルクロード」というインフラ・パイプラインレベルの答えを与えており、両者は抽象度の異なる層で記録系→導出データの伝播問題に応答している。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]]) - **Treasure Data社の依存関係グラフが示した「導出データの導出データ」という多段構造の複雑さに対し、第11章はデータメッシュ・データコントラクト・データファブリックというガバナンス実践を部分的な解として提示する**: 講演が指摘した「導出データの連鎖のどのノードが実質的な正典として扱われているか曖昧になりやすい」という問題に対し、第11章は、パイプライン管理が単一のデータエンジニアリングチームに集中していた従来モデルから、データメッシュ・データコントラクト・データファブリックといった標準・ツール群によって組織内の他チームも自分のデータパイプラインを安全に公開・管理できるモデルへ移行しつつあると述べる。これはガバナンスの枠組みを提示するにとどまり、依存関係グラフの複雑さそのものを自動的に削減する技術的解法ではないが、「誰が・どの段の導出データに責任を持つか」という体制面の問いには答えを与える。(Source: [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]]) - **第13章は、記録系から導出データへの伝播メカニズムという第1章以来の問いに、「分散トランザクションとの比較」という形で本書の総括的な回答を与える**: 第1章は「記録系の変更をどう導出データへ伝播させるか」を抽象的な問いとして残し、第3章はイベントソーシングというアプリケーション設計レベルの答えを、第11章はバッチジョブのストリームプッシュ/バルクロードというインフラレベルの答えを与えてきた。[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]はこれらの断片を「ログベースの導出データ」対「分散トランザクション」という二者択一の構図でまとめ上げ、XA分散トランザクションはフォールトトレランス・性能で劣り広範な採用に至っていないため、CDCやイベントソーシングログによる非同期な導出こそが異種データシステムを統合する最有力なアプローチだと明確に結論づける。適時性(reading your own writesのような即時可視性)は分散トランザクションの方が優れるが、完全性(データが失われない・矛盾しない)は非同期な導出データでも十分に達成できるという整理は、第1章以来「記録系との整合性維持がなぜ難しいか」だけを論じてきた本ページに、「維持するとしてどの手段が優れるか」という比較の視点を初めて与える。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]) - **技術的には無害な「派生」という操作が、倫理面では意味のある同意を成立不可能にする根本原因として第14章で再登場する**: 第1〜11章は導出データを一貫して技術的中立な語彙(記録系からの再生成可能性、冗長性、パイプラインでの伝播)として扱うが、[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 14 Doing the Right Thing]] は同じ性質——ユーザーベース全体の行動トラッキングと外部データソースを組み合わせ、単一ソースからは予測できない形で加工される——を、ユーザーが自分のデータの用途を理解できず「意味のある同意(meaningful consent)」を与えられない根本原因として位置づける。同じ技術的操作(データの結合・変換)が、技術章では設計上の課題(記録系との整合性維持)として、倫理章では同意という規範的要件を実務上不可能にする要因として、異なる評価軸で論じられている。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 14 Doing the Right Thing]]) ## 未解決の問い - dbt のようなクエリ依存関係記述ツールと、Delta Lake / Iceberg / Apache Hudi のようなテーブルフォーマットが提供する time travel(スナップショット管理)は、導出データの履歴管理としてどう役割分担すべきか。第11章は「オブジェクトストアやオープンテーブルフォーマットの多くがtime travelをサポートする」と述べるが、dbtのような依存関係記述ツールとの関係は明示しない。 - データメッシュ・データコントラクト・データファブリックという第11章のガバナンス実践は、Treasure Data社の依存関係グラフのような数千規模の実運用でどこまで複雑さを実際に低減できるか。概念の紹介にとどまり、定量的な効果検証は本章の範囲外。 - バッチ処理とストリーム処理の区別が薄れていく(Dataflow Model 以降の潮流)中で、導出データの「鮮度」をどう定義・保証すべきか。第12章(ストリーム処理)で扱われる可能性が高い。 - 非正規化(第3章)とマテリアライズドビュー(イベントソーシング/CQRS、第3章)はいずれも導出データだが、前者は更新のたびに冗長コピーを同期する必要があるのに対し、後者はイベントログからの決定的な再計算を前提とする。この2つの「導出データを最新に保つ」戦略(同期更新 対 決定的な再計算)は、一貫性・実装コストの面でどう体系的に比較されるか。バッチジョブの「ストリームへのプッシュ」(第11章)は後者(決定的な再計算)に近いが、リアルタイム性はイベントソーシングに劣る可能性があり、3方式の比較は未整理。 - 第14章が指摘する「導出データセットはユーザーが理解できない」という問題に対し、データ来歴(data lineage)の可視化・データコントラクト(第11章で紹介)のような技術的透明性向上策はどこまで有効か。第11章はガバナンス上の責任分担を扱うが、エンドユーザー向けの理解可能性については触れていない。 - 第13章の「ログベースの導出データが分散トランザクションより有望」という結論は、適時性を要求するアプリケーション(即時読み取りが必須なユースケース)ではどこまで成立するか。第13章自身が「reading your own writesのような保証は有用」と留保をつけており、この留保が第1章・第3章・第11章が論じてきた具体的な導出データパターン(キャッシュ・マテリアライズドビュー等)のどれに実際に影響するかは未整理。 ## 関連 - 概念: [[列指向OLAPデータベース]] / [[データウェアハウス]](記録系である OLTP システムから導出データであるデータウェアハウスへの ETL) / [[イベントソーシングとCQRS]] / [[リレーショナル対ドキュメントモデル]] / [[データフローエンジン]](導出データを生成するバッチ処理の実行エンジン) / [[MapReduce]] / [[データのプライバシーと同意]](導出データが意味のある同意を困難にする倫理的含意) / [[データ統合]](導出データを複数システムへ伝播させる際の統合問題) / [[エンドツーエンド論]](分散トランザクションに代わる完全性維持の原理) - ソース: [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]](p.18-20 導出データの定義と Treasure Data 社の依存関係グラフ実例) / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]]("Systems of Record and Derived Data" 節、記録系との対概念としての定義) / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]]("Normalization, Denormalization, and Joins", "Event Sourcing and CQRS") / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]]("Serving Derived Data"・"Extract–Transform–Load" 節) / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]("Derived data versus distributed transactions" 節) / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 14 Doing the Right Thing]]("Consent and Freedom of Choice" 節) ## 出典 - [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]](p.18-20) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]]("Systems of Record and Derived Data" 節) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]]("Normalization, Denormalization, and Joins", "Event Sourcing and CQRS") - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]]("Serving Derived Data"・"Extract–Transform–Load" 節) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]("Derived data versus distributed transactions" 節) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 14 Doing the Right Thing]]("Consent and Freedom of Choice" 節)