# データレイク ## 定義 データレイク(data lake)とは、分析に有用でありうるあらゆるデータのコピーを保持する中央集権的なデータリポジトリであり、業務系システムから ETL プロセスを通じて取得される点はデータウェアハウスと共通する。データウェアハウスとの違いは、データレイクが特定のファイル形式・データモデル・スキーマを一切課さず、単にファイルの集合として保持することにある。ファイルは Avro や Parquet のようなエンコーディングでデータベースレコードの集合を格納することもあれば、テキスト・画像・動画・センサー読み取り値・疎行列・特徴量ベクトル・ゲノム配列など任意の種類のデータでもよい。オブジェクトストアのようなコモディティ化されたファイルストレージを利用できるため、リレーショナルなデータウェアハウスより安価であることが多い。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "From data warehouse to data lake") ## 登場の背景 データウェアハウスが採用するリレーショナルデータモデルは、BI 向けの SQL クエリには適するが、データサイエンティストの用途には不向きなことが多い。具体的には、機械学習モデルの訓練に向けて行・列を数値ベクトル・行列に変換する特徴量エンジニアリングや、自然言語処理・コンピュータビジョンによるテキスト・画像からの構造化情報抽出は、SQL では表現しづらいカスタムコードを要する。多くのデータサイエンティストは Pandas・scikit-learn(Python)、R、Spark のような分散分析フレームワークを好み、リレーショナルデータベースでの作業を避ける傾向がある。この需要に応えるためにデータレイクが登場した。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "From data warehouse to data lake") ## sushi principle(生データの方が良い) ETL プロセスが一般化して「データパイプライン」と呼ばれるようになる中、データレイクは業務系システムからデータウェアハウスへ至る経路の中間駅として位置づけられることがある。この場合データレイクは、リレーショナルなウェアハウススキーマへの変換前の「生」のデータを業務系システムが生成した形のまま保持する。この方式の利点は、各データ消費者が生データを自分の用途に最も適した形へ独自に変換できることにある。これは俗に「sushi principle(生データの方が良い)」と呼ばれる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "From data warehouse to data lake") ## データレイクを超えて 分析実務の成熟に伴い、DataOps Manifesto に象徴されるようなデータパイプラインの管理・運用への関心が高まっている。これは GDPR・CCPA のような規制がもたらすガバナンス・プライバシー・コンプライアンス要求にも駆動されている。また分析用データはファイルやリレーショナルテーブルだけでなくイベントストリームとしても提供されるようになっており、ファイルベース分析が定期的な再実行(日次バッチ等)で変化に追随するのに対し、ストリーム処理は秒オーダーでの応答を可能にする。分析システムの出力を業務系システムへ還流させる過程はリバース ETL(reverse ETL)と呼ばれ、たとえば分析システムで訓練された ML モデルを本番の業務系システムへデプロイしレコメンデーションを生成する用途に使われる(TFX・Kubeflow・MLflow 等のツールで実施)。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] "Beyond the data lake") ## 横断的知見 - **データレイクの実装基盤(分散ファイルシステム/オブジェクトストア)は第11章で具体化され、「スキーマを課さない」という第1章の定義に反してテーブルフォーマットがスキーマを再導入する**: 第1章は抽象的に「業務系システムから ETL で取得したファイルの集合」とデータレイクを定義するが、[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]] はその物理的な実装基盤である[[分散ファイルシステムとオブジェクトストア]](HDFS・S3等)を詳説する。さらに第11章「Analytics」節は、Apache Icebergのようなテーブルフォーマットと Unity のようなカタログがテーブル・ファイルのマッピングやスキーマを管理する**データレイクハウス(data lakehouse)**アーキテクチャを紹介し、これによりデータウェアハウスと分析目的のデータレイクの境界が曖昧になっていると述べる。第1章の「データレイクはスキーマを一切課さない」という定義は、レイクハウスというテーブルフォーマット層の追加によって部分的に修正される——「生ファイルはスキーマレス、その上に構造化のレイヤーを重ねる」という2層構造が実務の到達点である。(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]]) - **第11章は、第1章が予告した「データパイプライン」の実装技術をETL/ワークフロースケジューラ/データメッシュとして具体化する**: 第1章「Beyond the data lake」はデータパイプラインの運用課題(ガバナンス・DataOps)を抽象的に触れるにとどまるが、第11章「Extract–Transform–Load」節は、Airflow・Dagster・Prefectのようなワークフロースケジューラが実際にETLパイプラインをスケジュール・オーケストレーション・デバッグする仕組み、失敗ジョブの自動リトライ、そしてデータメッシュ・データコントラクト・データファブリックという複数チームによる分散的なデータパイプライン管理の実務標準を提示する。「データレイクを中間駅とするパイプラインの実装技術」という第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 11 Batch Processing]]) ## 未解決の問い - Delta Lake・Apache Hudiは第11章でも明示的には扱われず、Apache Iceberg + Unityカタログの組み合わせのみが「データレイクハウス」の代表例として言及される。3つのテーブルフォーマットの機能差(トランザクション保証、time travelの実装方式)は本書の範囲では未整理。 - レイクハウスアーキテクチャがもたらす「生ファイル+テーブルフォーマット層」という2層構造は、第1章のsushi principle(生データの方が良い)とどう両立するか——テーブルフォーマットがスキーマを課すことは、生データを消費者ごとに自由に変換できるという利点を損なわないか。 - [[導出データ]] ページが扱う Treasure Data 社の依存関係グラフの実例は、第11章のデータメッシュ・データコントラクト・データファブリックが目指すガバナンスモデルでどこまで解消されるか。概念の紹介にとどまり、定量的な効果検証は本書の範囲外。 - 第12章(ストリーム処理)は、本章が触れた「分析用データはイベントストリームとしても提供される」という潮流をどう具体化するか。 ## 関連 - ソース: [[@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]] - 概念: [[データウェアハウス]](データレイクの対概念・発展元) / [[導出データ]](データレイクに保持されるデータの多くは導出データ) / [[分散ファイルシステムとオブジェクトストア]](データレイクの物理実装基盤) / [[MapReduce]] / [[データフローエンジン]] - 書籍: [[Designing Data-Intensive Applications 2nd Edition]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]]("From data warehouse to data lake"・"Beyond the data lake" 節) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]]("Distributed Filesystems"・"Object Stores"・"Extract–Transform–Load"・"Analytics" 節)