# データウェアハウス ## 定義 データウェアハウス(data warehouse)とは、企業内の複数の OLTP(業務処理)システムから読み取り専用のデータコピーを集約した、分析専用の別データベースである。1980 年代後半から 1990 年代前半にかけて、企業が OLTP システム上で直接分析クエリを実行することをやめ、分析を別システムに分離する潮流の中で登場した。大企業は数十〜数百の OLTP システム(ECサイト・店舗 POS・在庫管理・配送計画・仕入先管理・人事管理等)を独立に運用する一方、データウェアハウスは通常 1 つに集約され、アナリストが複数の業務系データを横断してクエリできるようにする。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "Data Warehousing") ## OLTP から分離する理由 - データの所在が複数の業務系システムに散在し、単一クエリで結合しづらい(データサイロ問題) - OLTP に適したスキーマ・データレイアウトは分析には適さない - 分析クエリは高コストであり、OLTP データベース上で実行すると他ユーザーの性能に影響する - OLTP システムがセキュリティ・コンプライアンス上の理由で別ネットワークに存在し、アナリストが直接アクセスできないことがある (Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "Data Warehousing") ## ETL/ELT データウェアハウスへデータを取り込む過程は抽出(Extract)・変換(Transform)・格納(Load)の 3 段階からなり、ETL と呼ばれる。変換と格納の順序を入れ替え、格納後にウェアハウス内で変換する場合は ELT と呼ばれる。ETL の対象は自社の OLTP データベースに限らず、CRM・メールマーケティング・カード決済等の外部 SaaS プロダクトが持つデータも含まれ、この場合は Fivetran・Singer・Airbyte のような専門のデータコネクタサービスがしばしば使われる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "Data Warehousing") ## HTAP との関係 HTAP(hybrid transactional/analytical processing)は OLTP と分析を単一システムで行い ETL を不要にしようとするアプローチである。しかし多くの HTAP システムは、内部的には OLTP システムと分析システムを別々に持ち、それを共通インターフェースの裏に隠しているにすぎない。そのため HTAP はデータウェアハウスを置き換えるものではなく、同一アプリケーションが大量行スキャンの分析クエリと低レイテンシな個別レコードの読み書きを両方必要とする場合(不正検知等)に有用な補完技術と位置づけられる。運用系データベースが各業務系ごとに独立して持つべきとされる(マイクロサービス的な)実務慣行とも相まって、企業は依然として単一の集約されたデータウェアハウスを持つのが一般的である。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "Data Warehousing") ## 横断的知見 - **第1章が予告した ETL は、第11章でバッチ処理の主要ユースケースとして具体化され、実装技術・組織モデルの両面で肉付けされる**: 第1章は ETL/ELT の3段階(抽出・変換・格納)を定義するにとどまるが、[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]] は、バッチジョブの「並列処理に適したembarrassingly parallelな変換」という特性がETLに向く理由、Airflow・Dagster・Prefectのようなワークフロースケジューラによるスケジュール・オーケストレーション・失敗時の自動リトライ、そして単一データエンジニアリングチーム集中モデルから データメッシュ・データコントラクト・データファブリックという分散パイプライン管理モデルへの移行を具体的に述べる。第1章の抽象的な ETL 定義に、第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]]) - **データレイクハウスは、第1章の「データウェアハウス→データレイク」という発展史に3番目の到達点を付け加える**: 第11章「Analytics」節は、Apache Icebergのようなオープンテーブルフォーマットと Unity のようなカタログで管理される **データレイクハウス(data lakehouse)** アーキテクチャを紹介し、これがデータウェアハウスと分析用データレイクの境界を曖昧にしていると述べる。BigQueryやSnowflakeのようなスケーラブルなクラウドデータウェアハウスも同様にバッチ処理との境界を曖昧にしつつあり、第1章が描いた「OLTPから分離した単一のデータウェアハウス」という1990年代前半の構図は、レイクハウスという第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 11 Batch Processing]]) ## 未解決の問い - 本書第3章・第4章はデータウェアハウスのスキーマ設計(スター/スノーフレークスキーマ)と内部ストレージレイアウト(列指向)をどこまで掘り下げるか。現時点([[列指向OLAPデータベース]])は個別製品(Snowflake・ClickHouse・DuckDB)の実装詳細に留まり、データウェアハウスという企業アーキテクチャパターン一般との接続はまだ薄い。 - HTAP システムが「内部的に2システムを結合している」という本章の指摘は、[[OLTPシステムアーキテクチャ]] が扱う Aurora Limitless 等のクラウドネイティブ OLTP とどう技術的に交差するか。 - データレイクハウス(第11章)とデータウェアハウス(第1章)の境界が曖昧になっているという指摘に対し、両者を明確に区別する技術的基準(スキーマ強制のタイミング、トランザクション保証の範囲等)は本書のどこで整理されるか。 ## 関連 - ソース: [[@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]] - 概念: [[データレイク]](データウェアハウスからの発展形) / [[導出データ]](データウェアハウスは導出データシステムの代表例) / [[列指向OLAPデータベース]](データウェアハウスの内部ストレージ技術) / [[OLTPシステムアーキテクチャ]](分離元の業務系システム) / [[MapReduce]] / [[データフローエンジン]](ETLを実行するバッチ処理基盤) - 書籍: [[Designing Data-Intensive Applications 2nd Edition]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]]("Data Warehousing" 節) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]]("Extract–Transform–Load"・"Analytics" 節)