🎨 直感で掴む

データを「分析・モデリングに使える形に整える」工程。 分析の質はここで 8 割決まります。

本ページでは データレイク を、 定義・前提条件・使い方・落とし穴の順に整理して解説します。 厳密な定義より、 まず何を、 いつ、 どう使うかを理解することを優先してください。

📐 定義

構造化・非構造化を生のまま保存する大規模ストレージ

英語名 Data Lake。

🎯 いつ・どこで使うか

• 「データエンジニアリング」分野の標準的な道具として、 多くの分析で登場します。
• 📚 データエンジニアリング を学ぶときに必ず通過する基本概念です。
• 論文・実務レポートで頻出する用語なので、 1 度はちゃんと理解しておくと後が楽です。

📋 前提条件・適用範囲

この用語を理解・使用するときは、 次のような前提を意識してください：

• データの性質：尺度（名義/順序/間隔/比例）と分布を確認
• サンプル数：手法によって最低限のサンプル数が異なります
• 独立性：観測が独立であるかを確認（時系列・パネル等では別の手法が必要）
• 欠損・外れ値：前処理の方針を明確に

⚠️ よくある落とし穴

🐍 Python での扱い

SSDSE-B-2026 のような公的統計データを Python で扱う際の基本パターン：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import pandas as pd
import numpy as np

# データ読み込み
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='utf-8', skiprows=1)
print(df.shape)
print(df.dtypes)
print(df.describe())

# 「データレイク」の文脈で扱う場合の例：
# 分野: データエンジニアリング
# 関連手法は同カテゴリの他用語を参照してください。

具体的なコードは データエンジニアリング を参照してください。

📝 レポートでの報告

分析結果を報告するときに含めるべき情報：

• 使ったデータ：出典・期間・サンプル数
• 適用条件の確認：前提が満たされているか
• 計算結果：数値だけでなく不確実性（CI・SE）も
• 解釈：何を意味するか、 何を意味しないか
• 限界：適用範囲外への拡張は避ける

✅ チェックリスト

• □ 「データレイク」を使う場面か再確認したか
• □ データの尺度・分布・サンプル数を確認したか
• □ 前提条件を満たしているか
• □ 計算した値だけでなく不確実性も把握したか
• □ 解釈と限界を区別したか
• □ 関連グループ教材で全体像を確認したか

🔖 キーワード索引

💡 30秒で分かる結論（補足）

データレイク ── 構造化・半構造化・非構造化を問わず生のまま低コストに蓄積する大規模ストレージ。 ETL 後に整える DWH と対照的に 「貯めてから考える」 思想。

• 代表実装：S3 / GCS / Azure Blob Storage（オブジェクトストレージ）
• 処理層：Spark / Presto / DuckDB / Athena / Databricks がクエリエンジン
• 進化形：データレイクハウス（Delta Lake / Apache Iceberg / Hudi）でトランザクション性を追加
• 規模感：PB 級まで線形拡張、 ストレージは 1 GB あたり $0.02 程度
• 陥穽：何も考えず入れ続けると データスワンプ（沼）化、 ガバナンス必須

📍 文脈 ── あなたが今見ているもの

データレイクは データエンジニアリング の蓄積層の中核です。 上流は データ収集 ・ センサー ・ SNS ・ 行動ログ、 下流は DataFrame ・ BI ・ ML パイプライン。

対比概念は データウェアハウス（DWH、 整形済み・スキーマ厳格）とRDB（行指向・トランザクション）。 「型が決まっていない / 後で型を決めたい」生データはレイクへ、 「定型集計が走る」整形済みは DWH へ、と使い分けます。

🏗 典型的なアーキテクチャ（Medallion）

Databricks が広めた Bronze / Silver / Gold 3 層構造が定石。 段階的にデータを精錬していくモデルです：

この階層化が、 「データを失わず、 用途別に最適化する」レイクの核心。 Bronze には全てを残し、 Silver / Gold は再生成できる前提で設計します。

📁 ストレージフォーマットの選び方

2025 年現在、 列指向（Parquet）＋テーブルフォーマット（Iceberg/Delta）の組合せが事実上の標準。 CSV は人間用、 内部処理は Parquet が無難です。

📐 コストの計算式

クラウドデータレイクの月額コストは大きく次の和で表せます：

$$ C_{\text{月}} = C_s + C_r + C_w + C_q $$

$C_s$=ストレージ容量料、 $C_r$=API リクエスト料、 $C_w$=ネットワーク転送料、 $C_q$=クエリ料（Athena/BigQuery 等）。 ストレージは安いが、 「クエリで全件スキャン」を繰り返すと $C_q$ が急増。 列指向＋パーティション分割で対策します。

🐍 Python 実装（取り込み〜分析）

(1) SSDSE-B のような CSV を S3 へ Parquet で投入：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

import pandas as pd
import boto3

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='utf-8', skiprows=1)

# 年でパーティション分割した Parquet 出力
df.to_parquet('data/lake/bronze/ssdse_b.parquet',
              partition_cols=['年度'], compression='snappy')

# S3 にアップロード
boto3.client('s3').upload_file(
    'data/lake/bronze/ssdse_b.parquet',
    'my-data-lake', 'bronze/ssdse/year=2026/data.parquet')

(2) DuckDB で S3 上の Parquet をローカル PC から直接クエリ（最近の定番）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

import duckdb

con = duckdb.connect()
con.execute("INSTALL httpfs; LOAD httpfs;")

# S3 上の Parquet 全体に SQL（必要列のみ列指向で読み込み）
q = """
SELECT 都道府県, AVG(高齢化率) AS avg_aging
FROM read_parquet('s3://my-data-lake/silver/ssdse/*.parquet')
GROUP BY 都道府県
ORDER BY avg_aging DESC
LIMIT 10;
"""
print(con.execute(q).fetch_df())

(3) Delta Lake で ACID トランザクション：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

from deltalake import write_deltalake, DeltaTable

# 初回書き込み
write_deltalake('data/lake/silver/ssdse', df, mode='overwrite')

# 更新（UPSERT 風）
dt = DeltaTable('data/lake/silver/ssdse')
dt.merge(
    source=df,
    predicate='source.都道府県 = target.都道府県 AND source.年度 = target.年度',
    source_alias='source',
    target_alias='target',
).when_matched_update_all().when_not_matched_insert_all().execute()

# Time Travel：1 バージョン前の状態を取得
old = DeltaTable('data/lake/silver/ssdse', version=0).to_pandas()
print(old.head())

⚠️ さらなる落とし穴

🌐 関連手法・派生

• データウェアハウス（DWH） — Snowflake, BigQuery, Redshift。 整形済みデータの分析専用
• データレイクハウス — Databricks, Iceberg のレイク＋トランザクション
• データメッシュ — ドメイン主導でデータプロダクトを分散管理
• レイクハウスフェデレーション — 複数レイクを横断クエリ
• CDC（Change Data Capture） — RDB の変更をレイクに反映
• Apache Hudi / Iceberg — オープン テーブル フォーマット

🔗 関連用語（前提・並列・発展）

役割で色分け：前提／並列／発展

📖 事例：小売チェーンの POS データレイク

全国 1000 店舗、 1 日数千万件の POS データを 5 年保管する設計を考えます：

• Bronze：POS から JSON で MQTT 経由、 Kinesis → S3 へ Avro で投入。 圧縮で日次 50GB 程度
• Silver：Glue ジョブで Parquet に変換、 店舗ID/日付でパーティション。 サイズ 1/10 に
• Gold：Athena ビューで「店舗×日×商品分類」の集計、 BI から参照
• 5 年で約 100 TB、 月額 ストレージ $2300 + クエリ $1500、 計 $3800 程度

📜 歴史と発展

• 2006 年：Hadoop オープンソース化、 HDFS が「データレイク」の原型
• 2010 年：「データレイク」用語の登場（Pentaho CTO の James Dixon）
• 2012 年〜：AWS S3 普及、 オブジェクトストレージが主流に
• 2015 年：Apache Parquet 1.0 リリース、 列指向の事実上の標準
• 2017 年：Delta Lake、 Apache Hudi、 Apache Iceberg が次々登場
• 2020 年：Databricks が「データレイクハウス」概念を打ち出す
• 2022 年：DuckDB / Polars でローカル分析が高速化、 「ビッグデータ不要論」も
• 2024 年：Apache Iceberg がベンダ中立標準として有力に

🏠 進化形：データレイクハウス

2020 年以降のトレンドが レイクハウス。 レイク（柔軟性）と DWH（信頼性）のいいとこ取りを目指します：

代表実装：Databricks Lakehouse、 Snowflake on Iceberg、 BigQuery + BigLake。 統合データ基盤として人気上昇中。

🎨 直感で掴む（深掘り）

「データレイク」という言葉そのものが比喩です。 川（データソース）から流れ込んだ水（データ）が、 形を整えずにそのまま大きな湖に溜まるイメージ。 利用者は釣り糸を垂らすように、 必要な時に必要な形でデータを取り出します。

対照的に、 データウェアハウス（DWH）は ペットボトル飲料 のような存在。 工場で品質管理され、 規格化されて店頭に並んでいる。 そのまま飲める一方、 「もう作り直せない」「色付き水（型変更）が欲しくても無理」という制約があります。

この自由度こそ「貯めてから考える（schema-on-read）」哲学の本質で、 IoT や SNS のように「将来どう使うか未知の」データを扱う現代において、 DWH より柔軟性が高い基盤として選好されるようになりました。

⚙️ End-to-End パイプライン

典型的なデータレイクの処理フローを順に追います。 各段階で使うツールも例示：

🏢 主要クラウドベンダ比較

既存のクラウド契約に合わせるのが王道。 マルチクラウドなら Iceberg + Trino のオープン構成を検討。

🎯 設計時の 10 原則

1. イミュータブル原則：書き込んだファイルは変更しない。 更新は新バージョン
2. パーティションキー設計：「最も WHERE される列」（多くは日付）で分割
3. 列指向必須：分析用は Parquet/ORC が原則。 CSV は人間用
4. 命名規約：環境/層/ドメイン/テーブル/パーティション の階層
5. スキーマレジストリ：Avro/Parquet のスキーマを一元管理（Confluent SR 等）
6. カタログ必須：何があるかを検索できる仕組み（Glue / Hive Metastore）
7. 暗号化 at rest / in transit：両方とも有効化、 KMS 鍵管理
8. 監査ログ常設：CloudTrail / Stackdriver でアクセス記録を保存
9. ライフサイクル設定：古いデータは IA / Glacier に自動遷移
10. 1 オブジェクト 100MB〜1GB：これより小さいとメタ操作が重い

❓ よくある質問

📚 関連グループ教材

この用語の全体像を学ぶには、 まず横断的な教材で文脈を掴むのが効率的です：

• 📚 データエンジニアリング — このカテゴリの全体像を学ぶ
• 📚 データリテラシー — このカテゴリの全体像を学ぶ
• 📚 データガバナンス — 統治・運用
• 📚 データ圧縮 — 列指向と圧縮

🔗 同カテゴリの他用語