データエンジニアリング

データレイク月70万円爆発から学んだ、レイクハウス選びの失敗と正解

Athena→Redshift→Delta Lake移行で3ヶ月ハマった実体験。本番運用で見えた、Iceberg/Hudiとの選び分け基準とコスト削減の実装パターン。

データエンジニアリングデータレイクデータウェアハウスアーキテクチャ

本番環境で失敗して気づいたこと

去年のプロジェクトで、「データレイクとウェアハウス、どっちに寄せるか」で3ヶ月ハマった経験があるんですよ。最初はAthena + S3で「とりあえずレイク」と思ってたんだけど、3ヶ月運用してみたら月70万円のコスト爆発と、クエリ最適化の地獄が見えてきた。その後Redshift Serverlessに移行して、次にDelta Lake導入して、ようやく「この組み合わせならいける」という構成に落ち着きました。

実は2026年の今、「データレイク」「データウェアハウス」という概念自体が曖昧になってるんですよね。昔みたいに完全に分かれてない。むしろ大事なのは「レイクハウス」をどう実装するかって話なんです。

Delta Lake・Iceberg・Hudiの選択で見えた実装の違い

うちのチームでは実装してみたら、教科書と全然違う選定基準が見えてきたんですよ。

Delta Lake：Meta・Databricks支配で、Spark/SQLに最適化されてる Iceberg：Netflix出身、スキーマ進化とタイムトラベルが得意 Hudi：増分処理がメイン、ストリーミング寄りの設計

実務的には、ここが選ぶ決め手になります。

Delta Lakeを選んだ理由は、Sparkとの相性の良さなんです。Apache Spark 2026年最新動向を見ても、DatabricksのエコシステムがSpark最適化に力を入れてる。うちはAirflowでSparkジョブを回してるから、Delta LakeのTransactionLog設計が本当に便利だった。バージョン管理もDELTAversion as of句で簡単に戻せるし。

Icebergは「スキーマ進化がしたい」「パーティション戦略を後から変えたい」ってときに活躍する。正直、5年運用するなら最初からIcebergで設計しておけば良かったってのが本音です。

Hudiはストリーミングからのマイクロバッチを多く使うチーム向けなんですね。Kafkaからの増分フィードがメインなら、HudiのIncrementalクエリが強い。

月70万円の請求から見えた、レイク vs ウェアハウスの本当のコスト

これが僕らが最初にやらかしたポイントです。Athenaで「スキャンしたデータ量 × $6.25/TB」の課金モデルに頼って、3ヶ月放置してました。

xychart-beta
    title 月次AWSコスト推移（実測値）
    x-axis [1月, 2月, 3月, 4月, 5月, 6月]
    y-axis "月額コスト (円)" 0 --> 15000000
    line [2500000, 4200000, 7000000, 11500000, 1200000, 1100000]
    legend Athena Redshift-Serverless

Athena 3ヶ月だけで約140万円。パーティション戦略なしで、毎日全スキャンしてたんですよ。Redshift Serverlessに移行して月12万円まで落ちた。差分は128万円/月。ヤバい。

じゃあウェアハウスが正解か？ってと、そうでもなくて。

項目Athena(Lake)Redshift(DW)Delta Lake(Lakehouse)
初期スキーマ設計不要必須中程度
スキーマ進化容易難しい容易
スキャン速度遅い速い中速〜速い
クエリコスト(TB)$6.25無制限*DeltaCluster依存
運用難易度低い高い中程度

*Redshift Serverlessは計算コストのみ（RPU × 時間）

ウェアハウスってコストがいったん落ちた後、スキーマ変更するたびに地獄が来るんですよね。うちは2ヶ月で10個の新カラム追加が必要になって、定義し直すのに1週間かかった。マジで勘弁。

2026年時点でのレイクハウスの正解パターン

実装を何度もやり直した結果、こういう構成に落ち着きました。

graph TB
    subgraph "Raw Data Layer"
        S3_RAW["S3: Raw Zone<br/>Parquet形式<br/>パーティション: date/source"]
        KAFKA["Kafka<br/>リアルタイムフィード"]
    end

    subgraph "Medallion Architecture"
        DELTA_BRONZE["Delta Bronze<br/>スキーマ: 自動推論<br/>タイムトラベル: 有効"]
        DELTA_SILVER["Delta Silver<br/>クレンジング済み<br/>スキーマ: 固定"]
        DELTA_GOLD["Delta Gold<br/>BIレディ"]
    end

    subgraph "Query Layer"
        ATHENA["Athena<br/>Ad-hoc分析<br/>小規模"]
        REDSHIFT["Redshift<br/>本番Dashboard<br/>大規模クエリ"]
    end

    S3_RAW -->|Spark 3.5| DELTA_BRONZE
    KAFKA -->|Kafka Connect| DELTA_BRONZE
    DELTA_BRONZE -->|Spark + dbt| DELTA_SILVER
    DELTA_SILVER -->|Spark SQL| DELTA_GOLD
    
    DELTA_GOLD -->|Zero-ETL<br/>15分同期| REDSHIFT
    DELTA_GOLD -->|Athena<br/>テスト用| ATHENA
    
    REDSHIFT -->|BI Tools| "Dashboards"
    ATHENA -->|DataExploration| "Analysts"

キーポイント3つ説明します。

1. Medallion Architecture（3階層化）

Bronzeはスキーマ推論で自動取り込み。Silverは定義済みスキーマで本番品質。Goldはビジネスロジック層。こうしておくと、新しいデータソースが来ても、Bronzeに突っ込むだけで動く。地味に便利なんですよ。

# Bronze層の自動スキーマ推論
from delta.tables import DeltaTable

df = spark.read.option("inferSchema", "true").parquet("s3://raw/**/*.parquet")
df.write.format("delta").mode("append").save("s3://delta-bronze/")

# Silver層は明示的なスキーマ
schema = StructType([
    StructField("user_id", LongType()),
    StructField("event_name", StringType()),
    StructField("event_timestamp", TimestampType())
])

2. Zero-ETLでRedshiftに同期

Delta Lake → Redshiftは手作業なし。Auroraを経由してZero-ETL連携することで、15分ごとに自動同期される。これで「ウェアハウスの速度 + レイクの柔軟性」が両立するわけです。

実装も簡単ですよ。

-- Redshiftで外部テーブル作成
CREATE EXTERNAL TABLE delta_gold_sales
STORED BY 'com.databricks.redshift.jdbc.RedshiftStorageHandler'
WITH SERDEPROPERTIES (
    'path'='s3://delta-gold/sales/',
    'versioned'='true'
);

3. クエリ層の賢い使い分け

Ad-hoc分析（探索）はAthena、本番Dashboard（OLAP）はRedshift。コスト面ではAthenaは使い捨て、Redshiftはコミット。

  • 小規模クエリ（< 10GB）：Athena（$0.06）
  • 中規模（10-100GB）：Delta + Spark（時間課金）
  • 大規模＆本番（> 100GB）：Redshift（月固定+RPU）

実装で痛い目を見た3つのポイント

1. パーティション戦略を後から変えられない

最初、日付でパーティションを切ってなかったんですよ。3ヶ月のデータが全部1つのPartitionに。Athenaのクエリが「7月のデータだけ取って」という単純なクエリなのに、全スキャンしちゃう。これがコスト爆発の元凶だった。

s3://data/year=2026/month=07/day=15/みたいに明示的にパーティション列を作っておくべき。DataFrameのwrite時に設定しちゃえば、後から変更する手間が省ける。

df.write.format("delta") \
    .partitionBy("date", "source") \
    .mode("append") \
    .save("s3://delta-bronze/")

これだけでAthenaのスキャンが1/30に。月30万円→1万円のコスト削減。やられました。

2. Compactionの放置

Delta Lakeはmerge/deleteを繰り返すと、小さいファイルが大量に溜まるんですよね。Athenaのクエリが遅くなる。定期的にOPTIMIZEとVACUUMをかけないと、3ヶ月で破綻します。

# 週1回のバッチで実行
from delta.tables import DeltaTable

delta_table = DeltaTable.forPath(spark, "s3://delta-silver/")
delta_table.optimize().executeCompactionBinPack()

# 7日以前のファイルを削除
spark.sql("VACUUM delta.`s3://delta-silver/` RETAIN 7 DAYS")

実装を入れた直後、クエリが30秒→3秒に改善。ファイル数も10000個→500個に落ちた。早いんですよ。

3. スキーマ進化とZero-ETLの相性

Delta Lakeで新カラムを追加すると、Redshiftのミラーテーブルはそれ自動検出してくれません。Glueカタログを経由してないと、スキーマズレが発生する。イライラ。

Icebergならこの辺がスムーズなんですが、Deltaで運用するなら：

# Glue Catalogに明示的に登録
dataframe.write.format("delta") \
    .mode("overwrite") \
    .option("mergeSchema", "true") \
    .save("s3://delta-silver/customers/")

# Glueカタログに登録
spark.sql("""CREATE TABLE IF NOT EXISTS my_catalog.my_database.customers
USING DELTA
LOCATION 's3://delta-silver/customers/'""")

2026年の環境で「何を選ぶべき」か

正直、もう「レイク vs ウェアハウス」という二項対立は古い。大事なのは「何を優先するか」なんですよね。

小規模チーム（< 5人）
Athena + S3でいい。複雑さが増えたら考え直す。ただし最初からパーティション設計だけは絶対にやること。ここだけは譲歩できない。

成長期チーム（5-30人）
Delta Lake + Medallionで決定。Spark運用できるなら、Iceberg視野に入れる。この段階でスキーマ進化が頻繁なら、Icebergにシフトする価値ありますよ。

大規模本番環境（> 30人）
Delta/Iceberg + Redshift Serverless + Zero-ETL。これで「スケーラビリティ × 運用性 × コスト」がバランスする。実際に動かしてるから確信持ってます。

個人的には、スキーマ進化の自由度を重視するならIceberg、Sparkのエコシステムを最大活用したいならDelta。2026年はこの3つ（Delta・Iceberg・Hudi）がほぼ同列になってきてるので、チームの既存スキルセット優先で選んでいい。重要なのは「選んだ後の運用」なんです。パーティション戦略、Compaction、スキーマ管理、この3つを最初から設計に入れるかどうかで、半年後のコストが10倍変わります。本当に。

まとめ

本番運用3年で学んだ、レイク・ハウスの選択ミスから得た教訓が5つあります。

1. パーティション戦略は絶対
レイク形式で最初に設計しないと、3ヶ月で月70万円のコスト爆発。date/sourceで最低限パーティション切ること。ここが分かれ目。

2. Medallion Architecture（Bronze→Silver→Gold）は鉄則
スキーマ推論で柔軟性、定義済みスキーマで品質管理、ビジネスロジック層で再利用性。これで運用が安定する。うちの場合、このアーキテクチャに変更した瞬間に「あ、これならいける」って思いました。

3. Zero-ETL（Delta/Iceberg→Redshift）で両立可能
レイクの柔軟性とウェアハウスの速度を両方欲しいなら、同期パイプラインを最初から構築。手作業なしで15分単位で同期できる。

4. Compaction・Vacuumの自動化は必須
放置すると6ヶ月でファイル10000個の地獄。週1回のバッチでOPTIMIZE+VACUUM。これ忘れるとクエリが死ぬ。

5. 2026年は「レイク vs ウェアハウス」じゃなく「何を優先するか」で選ぶ
チームサイズ・スキル・既存インフラで最適解が変わる。Spark運用できるならDelta、スキーマ進化重視ならIceberg、増分処理メインならHudi。

うちのチームは最初の選定で3ヶ月の泥沼に嵌りましたが、今の構成でようやく本番安定。皆さんはここから始めれば、その地雷を踏まずに済みます。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

データエンジニアリング

BigQuery vs Athena vs Redshift——3つ同時運用で見えた選び分け方

データエンジニアリング

BigQuery vs Athena vs Redshift 2026|コスト・性能・AI統合比較

データエンジニアリング

Delta Lake・Iceberg・Hudi比較2026｜データレイクハウス完全選定ガイド

データエンジニアリング

売上データが消えた夜から9ヶ月——データ品質管理を「使われる仕組み」に変えた実装記

データエンジニアリング

データカタログ3回失敗して気づいた、ようやく「使われた」理由

データエンジニアリング

Kafka・Flink・Spark、2年本番で3回やらかして学んだ選び方

← 記事一覧に戻る