データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説

データレイクは、構造化・半構造化・非構造化を問わず、あらゆる形式のデータを原形のまま1か所に貯める分析基盤です。Pentaho社のジェームズ・ディクソン氏が2010年ごろに提唱した概念で、集計前の生データを捨てずに蓄え、後から目的に応じて加工・分析する点に特徴があります。この記事では、生データを貯める仕組みとスキーマオンリードの考え方、データウェアハウス（DWH）やデータマートとの違い、ETLとELTの使い分け、オブジェクトストレージを土台にしたファイル形式・クエリエンジン・カタログの実装、そして「どんな要件で採用し、どこで見送るか」の判断基準までを、基盤を設計・運用する立場から整理します。

まとめ｜データレイクが向く場面とDWHとの使い分けの要点

データレイクは、種類も形式もバラバラなデータを加工前にそのまま集約し、機械学習や探索的な分析に使う「生データの置き場」です。書き込み時点ではスキーマを決めず、読み出すときに構造を当てはめるスキーマオンリードを取るため、想定していなかった分析に後から対応できます。実体はAmazon S3などのオブジェクトストレージで、そこにParquetなどのファイルを置き、AthenaやTrino、Sparkでクエリを走らせる構成が主流です。

一方のデータウェアハウスは、集計・レポート用に整形済みの構造化データを貯める仕組みで、BIのダッシュボードや定型レポートに向きます。両者は競合ではなく役割分担で、生データはデータレイク、整形済みの分析結果はDWHへ、という二層構成が定番です。2020年前後には、この2つを統合するデータレイクハウスという方式も登場しました。採用の分かれ目は、扱うデータが構造化中心か非構造化を含むか、用途が定型BIか機械学習・探索かにあります。以下、仕組み・比較・実装・判断の順で具体化します。

あらゆる形式の生データを加工前の原形のまま貯めるデータレイクの仕組み

まず、なぜデータレイクが多様なデータに強く、一方で放置すると使えなくなるのかを、データの持ち方から押さえます。ここがDWHとの違いと実装設計の土台になります。

構造化・半構造化・非構造化を区別せず原形のまま蓄積するデータの受け皿

データレイクが受け入れるデータは3種類に整理できます。テーブル形式の構造化データ（業務システムのレコード、CSV）、タグやキーで一部に構造を持つ半構造化データ（JSON、XML、ログ）、そして構造を持たない非構造化データ（画像、動画、音声、PDF、センサーの生信号）です。DWHが構造化データしか受け付けないのに対し、データレイクはこの3種を同じ場所に貯められます。取り込み時に整形しないため、IoTのセンサーデータや問い合わせの音声ログのように、その時点で分析方法が固まっていないデータも捨てずに残せる点が、機械学習の学習データ確保で効いてきます。

スキーマオンリードとスキーマオンライトの違いと実装上の設計制約

DWHは、データを書き込む前にテーブル定義（スキーマ）へ合わせて整形します。これがスキーマオンライトです。データレイクは逆に、生のまま書き込み、読み出すときにスキーマを当てはめるスキーマオンリードを取ります。書き込みは速く柔軟になり、代償もあります。読み出す側がデータ構造を正しく知っていないと解釈できず、型の不整合や欠損は実行時まで表面化しません。つまり「入れるのは簡単、正しく取り出すのは設計次第」という性質です。この制約を放置すると、データの意味が失われ、後述のデータスワンプ化を招きます。書き込み時の検証を省いた分、カタログとメタデータ管理で構造を外付けする設計がセットになります。

オブジェクトストレージを土台にした物理的な実体とファイル配置

データレイクは製品名ではなくアーキテクチャの概念で、その物理的な実体はオブジェクトストレージです。代表的な置き場はAmazon S3、Google Cloud Storage、Azure Data Lake Storage Gen2の3つ。ほぼ無制限のスケールと安価な保管単価が、生データを捨てずに貯める前提を支えます。S3互換のAPIで読み書きする点や部分更新に向かない特性は、オブジェクトストレージの仕組みとS3互換APIを実装視点で解説した記事で確認できます。データはバケット内に日付やデータソース別のプレフィックスで配置し、ファイル単位で追記していく形です。こうした安く大量に貯められる土台があって初めて、生データ全部を残すという発想が成立します。

データウェアハウス・データマートとの違いとETL/ELTの使い分け

データレイクの位置づけは、DWHとデータマートとの役割分担で捉えると明確になります。束ねKWの「データウェアハウスとの違い」もここで扱います。

データレイク・DWH・データマートの役割分担と対象データの比較

3つは競合する選択肢ではなく、データの流れの中で担う工程が異なります。生データはレイク、全社の分析用に整形した集約はDWH、部門・用途別に切り出した小さな集計はデータマート、という段階構造です。

DWHは中身がリレーショナルデータベースであることが多く、SQLで集計します。その基礎はデータベースの種類とRDB/NoSQLの選び方を整理した解説が土台になります。レイクは「捨てない置き場」、DWHは「整えた分析用データ」です。役割で分ければ、どちらか一方だけを選ぶ問いにはなりません。

ETLとELTの違いと、生データ蓄積でどちらをいつ選ぶかの判断

DWHとデータレイクは、データを取り込む順番も異なります。従来のDWHはETL（Extract・Transform・Load）で、抽出したデータを整形してから格納する方式です。データレイクはELT（Extract・Load・Transform）で、生のまま先に格納し、分析の直前に変換します。
ETLが向くのは、変換ルールが固まっていて、格納後の形が定型レポートに直結する場合です。ELTが向くのは、後からどんな分析をするか読み切れず、生データを残しておきたい場合です。実務では、まずELTでレイクに生データを貯め、確定した集計だけをDWHへETLで流す、という併用が現実的な落としどころになります。変換を後回しにできる柔軟さと、変換済みで即答できる速さを、両方の層で使い分ける形です。

データレイクハウスという統合方式と主要なテーブルフォーマット

データレイクは安く貯められる代わりに、更新の一貫性（トランザクション）やスキーマ管理が弱いという弱点を抱えていました。ここを補い、レイクのストレージ上で直接DWH並みの分析を実行できるようにしたのがデータレイクハウスです。これを実現する中核が、オープンテーブルフォーマットと呼ばれる技術群です。代表格はApache Iceberg、Delta Lake、Apache Hudiの3つ。オブジェクトストレージ上のParquetファイル群に、ACIDトランザクション、スキーマ変更の追跡、過去時点の参照（タイムトラベル）といった機能を後付けします。生データを1か所に置いたまま、BI（可視化）と機械学習を同じ基盤で扱える点が強みです。レイクとDWHを別々に持つ二重管理を避けたい要件で、レイクハウスが選択肢に上がります。

ファイル形式・クエリエンジン・カタログで組むデータレイクの実装

ここからは実装と運用の話です。データレイクは単一製品ではなく、ストレージ・ファイル形式・クエリエンジン・カタログを組み合わせて構築します。

Parquet・ORC・Avroの使い分けとクラウド別の主要サービス

生データをそのまま置くだけでは分析が遅くなるため、分析用には列指向フォーマットへ変換して保存します。ParquetとORCは列指向で、特定列だけを読む集計クエリならスキャン量を大きく減らせます。行指向のAvroは、スキーマ変更に強くデータの取り込み（ストリーミング）側で使われる形式です。分析基盤ではParquetが事実上の標準です。
クラウド別では、AWSがS3を土台にGlue（カタログ）とLake Formation（ガバナンス）、GCPがCloud StorageとBigQuery、AzureがData Lake Storage Gen2とSynapse Analyticsを提供します。どれもオブジェクトストレージを核に、周辺サービスでカタログとクエリを補う構成は共通しています。

Athena・Trino・Sparkでファイルに直接SQLを実行するクエリ層

データレイクの強みは、データを別のDBへ移さず、ストレージ上のファイルへ直接クエリできる点です。AWSのAmazon Athenaは、S3上のParquetやCSVに対してサーバーレスでSQLを実行し、スキャンしたデータ量に応じて課金します。オープンソースのTrino（旧PrestoSQL）は、複数のデータソースを横断してSQLを投げられる分散クエリエンジンです。Apache Sparkが担うのは、SQLに加えた機械学習の前処理やバッチ変換の領域。いずれも入り口はSQLで、SQLの基本文法と実行の仕組みを解説した記事を押さえておくと、レイク上のクエリ設計がそのまま生きます。スキャン量を抑える鍵は、Parquet化とパーティション設計（日付やソース別のディレクトリ分割）にあります。

データカタログとアクセス制御で構造とガバナンスを後付けで統制する

スキーマオンリードのレイクでは、どこに何のデータがあるかをメタデータで管理しないと、貯めたデータが検索できなくなります。ここを担うのがデータカタログです。AWS Glue Data Catalogは、S3上のファイルをクロールしてテーブル定義（列名・型・パーティション）を自動抽出し、AthenaやTrinoから参照できるようにします。アクセス制御には、Lake Formationのように行・列レベルで権限を絞る仕組みを重ねる形が一般的です。生データには個人情報や機微データが混ざりやすく、「誰がどのデータを読めるか」を後付けで設計しないとガバナンスが破綻します。カタログとアクセス制御は、レイク構築で省略できない土台です。

導入判断でデータレイクを採用すべき条件と、つまずく失敗パターン

最後に、設計する立場での判断を言い切ります。データレイクは万能の分析基盤ではなく、選ぶ条件と外す条件がはっきりしています。

データレイクを採用すべき4つの条件と、DWHで足りる場面の線引き

採用してよいのは、次の条件が揃うときです。非構造化データ（画像・ログ・音声）を分析対象に含める、機械学習の学習データとして生データを残したい、将来の分析要件が読み切れず柔軟性を優先したい、データ量がテラバイト級以上に伸びうる。この4つが揃えば、データレイクが第一候補になります。
逆に、扱うデータが業務システムの構造化データだけで、用途が定型のBIレポートに収まるなら、DWHやBIツールで足ります。ここへ無理にレイクを導入すると、カタログ整備やクエリ設計の運用負荷だけが増え、見合いません。「非構造化データと探索的分析があるか」が、レイクを選ぶ最初の分岐点です。データ量が少なく用途が定型なら、レイクは過剰投資になります。

ガバナンスを欠いてデータスワンプ化する典型的な失敗とその回避策

現場で繰り返される最大の失敗が、データスワンプ（データの沼）化です。「とりあえず全部貯める」を無計画に進めた結果、何のデータか分からないファイルが山積みになり、誰も使えない状態に陥ります。原因は3つに集約されます。1つ目はカタログ未整備で、メタデータがなく検索できない。2つ目は命名・パーティション規約の欠如で、同じデータが重複し所在が分からない。3つ目はアクセス制御の後回しで、機微データを誰が読めるか管理できない。
回避策は、取り込みの最初からカタログ登録を必須にし、ソース別・日付別のディレクトリ規約を決め、権限設計を並行させることです。データレイクは「貯める技術」より「貯めたものを見つけ、統制する設計」で成否が決まります。生データの蓄積から分析・可視化までを含むデータ分析基盤を外部と組んで構築したい場合は、BIツール導入とダッシュボード構築の支援で要件整理から相談できます。

データレイクの設計・実装・DWHとの違い・選定に関するよくある質問

実装・選定の現場で受けやすい質問を、判断に直結する形でまとめます。

データレイクとデータウェアハウスはどちらを導入すべきですか？

非構造化データや機械学習用の生データを扱い、将来の分析要件が固まっていないならデータレイク、構造化データの定型BIレポートが中心ならデータウェアハウスです。実務では二者択一にせず、生データはレイク、確定した集計はDWHへ流す二層構成にするのが現実的です。

データレイクとデータレイクハウスの違いは何ですか？

データレイクは生データを貯める置き場で、更新の一貫性やスキーマ管理が弱いという課題があります。データレイクハウスは、Apache IcebergやDelta LakeといったテーブルフォーマットでレイクにACIDトランザクションとスキーマ管理を加え、レイク上で直接DWH並みの分析を可能にした統合方式です。

データレイクの実体はどこにデータが保存されますか？

Amazon S3、Google Cloud Storage、Azure Data Lake Storage Gen2といったオブジェクトストレージに保存します。データレイクは製品名ではなくアーキテクチャの概念で、安価で大容量なオブジェクトストレージを土台に、カタログやクエリエンジンを組み合わせて構築します。

データレイクにためたデータはどうやって分析しますか？

データを別のDBへ移さず、Amazon Athena、Trino、Apache Sparkといったエンジンで、ストレージ上のファイルに直接SQLや処理を実行します。分析を速くするには、生データを列指向のParquet形式へ変換し、日付やソース別にパーティション分割してスキャン量を抑える設計が効きます。

データスワンプとは何ですか、どう防ぎますか？

データスワンプは、無計画に貯めた結果、何のデータか分からず誰も使えなくなったデータレイクを指します。防ぐには、取り込み時のデータカタログ登録を必須にし、命名・パーティションの規約を決め、アクセス制御を最初から設計します。貯める前に「見つけられる・統制できる」仕組みを用意することが分かれ目です。

関連記事

• オブジェクトストレージとは？仕組みとS3互換API・ブロックとの違い：データレイクの物理的な土台。生データを安く大量に貯める基盤の仕組みを深掘りします。
• データベースとは？種類・DBMS・RDBとNoSQLの選び方：DWHの中身であるRDBの基礎。構造化データの管理側からレイクとの違いを補完します。
• DBMSとは？機能・種類・RDBMS製品の選び方：整形済みデータを扱うDBMSの視点。DWH層のデータ管理を理解する助けになります。
• ストレージとは？種類・HDDとSSDの違い・クラウド選定：ストレージ全体の中でオブジェクトストレージとデータレイクがどこに位置づくかを俯瞰できます。