データレイクとDWHの違い

定義と前提が違う——スキーマと粒度の思想

データレイクは「とりあえず全部置く」前提で、構造化・半構造化・非構造化を問わずデータを格納します。保存形式はParquetやORCなどの列指向が中心で、スキーマは読み出し時に解釈（スキーマ・オン・リード）。画像やログ、IoT時系列、音声テキスト化など、将来の用途がまだ定まらないデータを低コストに長期保存できるのが強みです。

一方DWH（データウェアハウス）は「使い方が決まったデータを最適化して置く」前提です。スキーマ・オン・ライトで事前に整形し、ディメンション/ファクトの粒度を設計し、クエリ性能・同時実行・整合性を優先します。業務KPIの算出、定常BI、監査対応と相性が良いです。要するに、レイクは可能性重視、DWHは決定力重視です。

近年はレイク上にACIDテーブルを載せるDelta Lake/Apache Iceberg/Apache Hudiなどの「レイクハウス」も一般化し、両者の境界は実装面で近づきました。それでも「未知のデータを受け止める箱（レイク）」と「意思決定に耐える整形済みデータの箱（DWH）」という役割分担は変わりません。

使い分けの意思決定フレーム——目的・鮮度・コストで切る

抽象論にせず、導入順と配置を以下で決めると迷いにくいです。

• 目的の明確さ：算出方法が固定されたKPI/レポートはDWH。仮説探索、LLM学習素材、クリックストリームの試行はレイク。
• データ種：JSONログ、画像/音声、テキストはまずレイク。正規化済みトランザクションはDWHへ整形して格納。
• 鮮度要件：サブ秒〜数分でのダッシュボード更新はDWH（またはレイクハウスのマテビュー）。日次・週次バッチや履歴保持はレイク主体。
• コストとスケール：保存量がボトルネックならレイク優先、クエリ課金を抑える。固定的な大量集計を高速に回すならDWHで最適化。
• ガバナンス/監査：権限制御、データ品質SLA、監査証跡が厳しい領域はDWHまたはACID対応のレイクハウスでテーブル管理。

実務では「まず全データをレイクに着地（Raw/Bronze）」→「再利用しやすい形に整形（Silver）」→「業務KPIのゴールドテーブルはDWHかレイクハウスに昇格」という二段構えが現実的です。未知はレイクで担保、既知はDWHで磨く、が合言葉です。

設計の実務ポイント——ゾーニング、品質、パイプライン

ゾーン設計とテーブル形式

• Raw/Bronze：完全な生データ。追記専用、削除しない。保存はParquet + パーティション（例：date=YYYY-MM-DD）。
• Silver：型揃え・正規化・PIIマスキング・ジョイン。スキーマはドキュメント化し、カタログで管理。
• Gold：KPI用に集約済み。DWHの星型スキーマ、またはIceberg/Deltaのマネージドテーブルに載せる。

ACID対応テーブル（Delta/ Iceberg / Hudi）を使うと、アップサート（CDC対応）、タイムトラベル、スキーマ進化が扱いやすくなります。これにより「レイクに置いたが、業務でも安心して使える」状態を作れます。

品質・ガバナンスとコスト抑制

• データ品質チェック：必須カラムの非NULL、ドメイン制約、重複検出をパイプラインに自動化。
• 系譜（リネージ）：どの生データがどのKPIに影響するかを可視化。影響範囲が即時に分かると変更が怖くありません。
• 権限制御：Rawは限定公開、Goldは原則公開などのレイヤリングで「見せる勇気/隠す勇気」を両立。
• コスト管理：大テーブルは列プルーニング・パーティションプルーニング前提で設計。スキャン削減が最強の節約です。

パイプラインの選択（ETL/ELT）とAIの実務

変更が多い初期はELT（まず着地、後で変換）が俊敏です。基幹系の厳密更新はETLで整形してから投入。CDCで更新履歴を取り、バッチとストリームを併用します。探索フェーズではアナリストがChatGPTやClaudeでSQLのたたき台を作り、エンジニアはCopilotで変換コードの雛形を効率化、要約や要件整理にGeminiを使うなど、生成AIを補助輪にするのが現場流です。

身近な企業活用例——地方スーパー30店舗の失敗と改善

全データを一気にDWHへ集約しようとし、POS・EC・アプリ行動ログ・チラシ画像までETLで固めようとして破綻しました。スキーマ変更のたびにパイプラインが落ち、DWHのストレージ/クエリ費が月500万円に膨張、ダッシュボード更新も30分遅延。

見直しでは、まずデータレイクに全データをParquetで着地（Raw）。アプリログと画像はレイクに留め、購買ファクトと商品ディメンションだけをGoldに昇格してDWHへ。カタログでデータ所有者を明確化し、IcebergテーブルでCDCを吸収。KPIの定義（売上、粗利、在庫回転）はDWHで星型に固定、広告配信やレコメンドの特徴量はレイク側で生成し、必要に応じてマテリアライズ。

結果、日次バッチは3時間→45分、在庫回転率は10％改善、広告ROASは18％向上。DWHの月額は500→220万円に半減、クエリのP95は3分→20秒に短縮。業務側はChatGPTでSQLの初稿を作成しアナリストがレビュー、エンジニアはCopilotでETLのテストを自動生成、店舗長向けサマリーはGeminiで自然言語要約して朝会に配信。レイクは「実験の自由度」、DWHは「ブレない指標」という棲み分けで、失敗から立て直しました。

まとめ——二者択一ではなく役割の最適配置

データレイクは未知とスケール、DWHは整合と速さ。両者をレイクハウスや明確なゾーニングでつなぐと、探索と意思決定が同じ土俵に並びます。重要なのは技術名より「どのデータをどの粒度で、どのSLAで誰が責任を持つか」を先に決めることです。データ解析プラットフォーム事業の視点では、ストレージ・テーブル形式・カタログ・権限・パイプライン・コスト監視を一貫して設計し、レイクとDWHを運用で滑らかに接続することが価値になります。選ぶのではなく、組み合わせる設計が、現場を強くします。