はじめに
データレイクは、構造化データと非構造化データをまとめて収容でき、低コストかつオープンフォーマットで柔軟に扱える点が魅力です。
一方で、「分析を回す」「更新を安全に行う」「性能や一貫性を担保する」といった観点では、レイク単体では不完全な部分が見えてきます。
本記事では、Hadoop時代からの流れを整理しつつ、データレイクの利点・欠点、そしてデータウェアハウスとの統合として データレイクハウス と （オープンな）データレイクテーブルフォーマット に至ったのかをまとめます。
この記事で分かること
-
Hadoop/HDFS → Hive → Hiveテーブルフォーマットという流れが、なぜ生まれたのか
-
クラウド移行後に「データレイクで分析する」ときに出てくる2つの方法と、それぞれの課題
-
その課題を踏まえて、データレイクハウスとオープンテーブルフォーマット（データレイクテーブルフォーマット）がどう位置づけられるか
全体の流れ
- Hadoop/HDFSで「大量データを安価に保存・処理」できるようになった
- ただし分析には課題があり、MapReduce→Hive（SQL）→Hiveテーブルフォーマットが定着
- クラウド移行でオブジェクトストレージが主流になると、Hiveの前提が合わない部分が表面化
- データレイクで分析する方法は大きく2つあるが、それぞれ欠点がある
- DWHの“使いやすさ・性能”と、レイクの“低コスト・柔軟性”を統合したい欲求からレイクハウスが誕生
- レイクハウスでは、DWHのような機能（ACID、性能、一貫性）をレイク上で成立させるために データレイクテーブルフォーマット を導入する
1. 簡単な歴史：Hadoop → Hive → Hiveテーブルフォーマット
Hadoop/HDFSで「安く大量に保存・処理」できた
もともと、Hadoop（分散コンピューティング）とHDFS（ファイルシステム）を使い、安価なコンピュータークラスター全体にわたって大量の構造化／非構造化データを保存・処理していました。
ただし「保存するだけでは不十分」で、分析も実行したいという需要が出てきます。
しかし分析はMapReduce（Java）で書くのが重い
Hadoopエコシステムには、Javaで分析ジョブを書いて実行するMapReduceが含まれていました。
ただ、MapReduceジョブは冗長で複雑であり、多くのアナリストはJavaよりもSQLを書くほうが得意でした。
そこで、SQL文をMapReduceジョブに変換するために Hive が作成されます。
SQLのために必要だった「テーブルの目印」＝Hiveテーブルフォーマット
SQLを書くには「ストレージ内のどのファイルが、どのテーブルの一部か」を区別する手段が必要になります。
こうして、ディレクトリとその中のファイルをテーブルとして認識する Hiveテーブルフォーマット が誕生しました。
2. クラウド移行で表面化した摩擦
時間が経つにつれて、人々はHadoopクラスターの使用から、管理が容易でコストも安い クラウドオブジェクトストレージ（Amazon S3、MinIO、Azure Blob Storageなど） に移行しました。
MapReduceも、Apache Spark、Presto、Dremioなどの分散クエリエンジンに取って代わられます。
一方で Hiveテーブルフォーマットは存続 し、ストレージ内のファイルを単一のテーブルとして認識して分析を実行する標準となりました。
ただ、Hive形式（Hive Metastore＋「パーティション＝ディレクトリ階層」でテーブルを表す慣習）は、運用上どうしても ディレクトリ列挙（list） や rename によるコミット、大量のファイル・パーティションの取り回しといった “ファイルシステム的な操作” が増えがちです。
しかしオブジェクトストレージはファイルシステムではないため、これらの操作が API呼び出し（ネットワーク）回数・レイテンシ・コストとして効きやすく、さらに スナップショットや同時書き込み制御といった“テーブル運用に必要なメタデータ管理”もHive形式だけでは弱い、という課題が表面化しました。
3. データレイクの考え方：エンジンは万能ではなく、トレードオフがある
データレイクとデータウェアハウスを区別する特徴の1つは、多様なワークロードに対して 異なるクエリエンジンを活用できる能力です。
しかし、すべてのワークロードに最適で、ストレージとは独立して計算をスケールできる 万能のクエリエンジンは存在しません。
つまりデータレイクの世界では、
「どのエンジンで、どのワークロードを捌くか」には必ずトレードオフがあり、優先するもの（性能・柔軟性・コストなど）によって得意不得意が分かれます。
4. もう一つの前提：データレイクには「ストレージエンジン機能」がない
上記の「万能エンジン」はないという前提に加えて、データレイクにおいては、ストレージエンジンの機能を担うサービスは存在しないことに注意が必要です。
一般的には、クエリエンジンがデータの書き込み方法を決め、その後はテーブル全体やパーティションが再書き込みされない限り、データが修正されたり最適化されることはありません。
この2つ（万能エンジンがない／ストレージエンジン機能がない）の注意点を踏まえると、
データレイクは「何でも置ける」一方で、分析・更新・最適化を安定して回す観点では 不完全な部分が残ります。
5. データレイクに取り込んだ後、分析は一般に2つの方法に分かれる
さらに、データレイクは構造化データと非構造化データをすべて収容するための優れた場所を提供する一方、依然として不完全な部分がありました。
ETLでデータをデータレイクに取り込んだ後、分析を実行する際には一般的に次の2つの方法のいずれかを取ります。
方法1：DWHへコピーして分析する（性能・使いやすさを優先）
データウェアハウスのパフォーマンスと柔軟性を得るために、優先度の高い分析用データのサブセットをコピーし、データウェアハウスに保存する追加のETLパイプラインを設定します。
ただし問題もあります。
- 追加ETLの計算コストがかかる
- 通常はストレージコストがより高額なDWHに、すでにデータを持っているにもかかわらず、そのデータのコピーを保持するコストがかかる
- データマート生成やBI抽出コピーが増えると、コピーが蜘蛛の巣のように絡まり、ガバナンス・追跡・同期が困難になる
方法2：データレイク上で直接クエリする（低コスト・柔軟性を優先）
Dremio、Presto、Apache Spark、Trino、Apache Impalaなどのクエリエンジンを使用して、データレイク上でクエリを実行します。
これらのエンジンは一般的に 読み取り専用のワークロードに適している一方、Hiveテーブルフォーマットの制約により、データレイクからデータを安全に更新しようとすると複雑な問題が生じます。
6.だから「利点を統合したい」：データレイクハウスへ
ここまでを整理すると、データレイクは低コストで、オープンフォーマットによる柔軟性があり、非構造化データを利用できる一方で、実運用で分析を回す観点では、
- DWHコピーはコストとコピー増殖（ガバナンス・追跡・同期の難しさ）が問題になりやすい
- レイク直クエリは読み取り向きで、Hiveテーブルフォーマットの制約のもとでは安全な更新が難しくなり得る
という形で、不十分な点もあります。
そこでデータウェアハウスとデータレイクの利点を統合し欠点を最小限に抑える新しいアーキテクチャが必要になりました。それが「データレイクハウス」です。
7. データレイクハウス：レイクに置いたまま、DWHのような機能を成立させる
データレイクハウスのアーキテクチャは、データレイクから ストレージと計算を分離しつつ、データウェアハウスのような機能（ACIDトランザクション、より良いパフォーマンス、一貫性など）を可能にする仕組みを導入します。
この機能を実現するのが、Hiveテーブルフォーマットの以前の問題をすべて解消する データレイクテーブルフォーマットです。
このテーブルフォーマットでは、
- テーブルフォーマットのデータは データレイクのデータと同じ場所に保存される
- データレイクに対して使うのと 同じクエリエンジンを使うことができる
- 実データは、データレイクに保存していたときと 同じフォーマットで保存される
つまり、データをレイクに置いたまま、DWHのような性質（ACID・性能・一貫性）を成立させるための土台が、オープンテーブルフォーマットとして整備されていく、という流れです。
おわりに
Hadoop/HDFSから始まり、SQLで分析するためにHiveとHiveテーブルフォーマットが生まれ、クラウド移行で摩擦も見えてきました。
そして、分析のやり方が2択に分かれ、それぞれが欠点を抱える中で、両者の利点を統合する発想としてデータレイクハウスが登場します。
その中核にあるのが、Hiveテーブルフォーマットの課題を解消する （オープンな）データレイクテーブルフォーマット、という位置づけです。