はじめまして。stable株式会社 代表の宮﨑 一輝（@ikki_mz）です。
stable株式会社は、データエンジニアリングを専門領域として、企業のデータ活用・データマネジメントに関するあらゆるご支援をしています。
今回は「#も読」の第3回の投稿です。
第3回となるこの記事では、オライリーから出版されている『Practical Lakehouse Architecture』という書籍を読んだので、その内容を紹介できればと思います。
書籍の概要
『Practical Lakehouse Architecture』は、その名の通りレイクハウスアーキテクチャについて体系的に解説した書籍です。アーキテクチャそのものを扱った内容であるため、特定のツールに依存した話だけをしているわけではなく、「レイクハウスアーキテクチャを採用することによるメリット」や「レイクハウスアーキテクチャを構成する要素」など、レイクハウスの基礎を学べる内容となっています。
それでは早速、書籍の内容に触れていきたいと思います。まず、「レイクハウス」とはどのような概念なのかというところから説明していきます。
レイクハウスアーキテクチャとは何か
お察しの通り、レイクハウスとは、「データレイク」と「データウェアハウス」という2つを融合させた概念です。つまり、レイクハウスというのは、「データレイク」と「データウェアハウス」のいいとこ取りをしたようなアーキテクチャだと言えます。
レイクハウスという概念をつかむには、「データレイク」「データウェアハウス」それぞれとどのように異なるのかを押さえると良いでしょう。
データウェアハウスとの比較
まず、データウェアハウスとレイクハウスを比較してみます。
この記事を読む方は、すでにデータウェアハウス（以下、DWH）については馴染み深いものとなっているでしょう。BigQueryやSnowflakeといった製品が代表的なツールです。
DWHは、データを格納しつつ、超高性能なコンピュートでデータの加工・分析までをそのDWHの中で完結して行う、という使い方が主流になってきています。BigQueryを例に挙げると、BigQueryの中にデータを取り込み、取り込んだデータをBigQueryのコンピュートで加工する、というのが基本的な考え方です。
DWHさえあれば、ほとんどのデータ活用をその中で完結させられます。しかし、裏を返すと、「DWHに依存しすぎてしまう」という弱点もあります。いわゆるベンダーロックインと呼ばれるものです。DWHに取り込んだテーブルはDWHによって管理されており、他のツールからそのデータを参照したい場合には、エクスポートや転送といった手間が発生する、という構造になっています。
その一方で、レイクハウスアーキテクチャというのは、データをオブジェクトストレージ上の「オープンな場所」、すなわちデータレイクに置こうという思想のアーキテクチャです。データそのものは特定ベンダーの管理下に閉じ込められることなく、様々なコンピュートエンジンからアクセスできる場所に存在しています。こうすることで、DWHによるベンダーロックインを回避しやすくなるのです。
この「オープン性」の他にも、
- DWHにデータをロードする必要がなくなる
- DWHが主に扱う構造化データ以外に、非構造化データも一緒に扱える
- DWHよりもストレージコストが抑えられる
- AI/MLワークロードとの相性がいい
などのメリットもあります。いずれも、データを特定のDWHの内部ではなくオープンな場所に置く、というレイクハウスの発想から自然と導かれるメリットだと言えます。
データレイクとの比較
では、続いてデータレイクとの比較を見ていきましょう。
データレイクというのは、安価なオブジェクトストレージに構造化・非構造化データを問わず、あらゆるデータを格納して、活用に繋げるというものです。一方で、これまでのデータレイクには、スキーマ管理や権限管理といった運用・ガバナンスの観点で機能が不十分だ、という大きな課題がありました。ある意味では「データを溜めているだけ」の存在だった、といってもいいかもしれません。
具体的には、ACIDトランザクションが効かないのでUPDATEやDELETEが実質できない、スキーマを変えるにはファイルを全書き換え、同時書き込みでデータが壊れる、パーティション設計を間違えると後から直せない、といった問題です。整備されないと「データスワンプ（沼）」と揶揄されるほどでした。これらは、これまでDWHが内部で解決してくれていた問題でもあります。
ここで登場するのがオープンテーブルフォーマット（OTF）です。代表的なOTFであるApache IcebergやDelta Lakeは、Parquetファイル群の上にメタデータ層を載せることで、ACIDトランザクション、行レベルのUPDATE / DELETE / MERGE、スキーマ進化、タイムトラベル、データスキッピングによる高速化といった、これまでDWHが内部で実現してきた機能を、オブジェクトストレージ上で実現できるようにしました。
これにより、データレイク上のデータが「ただ置いてあるファイル」から「DWHのテーブルのように扱えるオブジェクト」へと進化しました。「これまでのデータレイク」と「レイクハウス」の決定的な差分は、ここに現れていると感じます。
少し踏み込んでおくと、このOTFはレイクハウスの中核技術と言える存在です。「ストレージとコンピュートを分離し、オープンな場所に置いたデータを複数のエンジンから扱う」というレイクハウスの根幹は、OTFがあって初めて成り立つからです。このあたりは、後ほど「感想」のところでも改めて触れたいと思います。
レイクハウスを構成する要素
本書ではレイクハウスを構成する要素として、ストレージ・データカタログ・コンピュート・ガバナンスの4つが章を分けて解説されています。レイクハウスをふわっとしか理解していなかった人でも、具体的な構成要素の集合として捉え直せるようになるのは、本書の強みだと思います。それぞれの章の内容をかいつまんで紹介します。
ストレージ
レイクハウスのストレージ層は、クラウドオブジェクトストレージ・オープンファイル形式・オープンテーブル形式の3つで構成されます。ファイル形式としては、圧縮率と集計・分析の効率に優れた列指向形式である Apache Parquet や ORC が主流です。テーブル形式としては、先述した Iceberg・Hudi・Delta Lake などのOTFが、データレイク上でACIDトランザクション、タイムトラベル、スキーマ進化といったDWH的な機能を実現します。さらにパーティショニングやZ-orderといった技術により、不要なデータを読み飛ばすデータスキッピングを行ってクエリ性能を向上させる、といった話も解説されています。
データカタログ
データカタログは、プラットフォーム上のデータを検索・発見・理解するためのメタデータ管理プロセスです。スキーマなどのテクニカルメタデータと、ビジネス上の意味や説明を表すビジネスメタデータの両方を管理します。本書では特に、従来の「データレイクとデータウェアハウスで別々のカタログを使う」という分断を避け、すべてのデータとMLモデルなどのAI資産を1か所で管理する統合データカタログを目指す、というスタンスが印象的でした。各クラウド・プラットフォームでのメタデータ集中管理を担うサービスとして、AWS Glue、Microsoft Purview、Google BigLake、Databricks Unity Catalog などが紹介されています。
コンピュート
ストレージと分離されたコンピュートエンジンは、データの取り込み・変換・分析といったすべての計算処理を担います。データエンジニア向けには Spark や Flink、アナリスト向けには Presto や Trino といったSQLエンジンなど、利用者のペルソナや用途に合わせて最適なエンジンを自由に選択できる、というのがレイクハウスにおけるコンピュート層の特徴です。OSS、クラウドネイティブ、サードパーティ（Snowflake / Databricks など）のエンジンを、オープンなデータ層に対して組み合わせて使えるようになっています。
ガバナンス
レイクハウスでは、技術だけでなく「人」と「プロセス」を含めた統一的なガバナンスが目指されています。データ品質の維持、リネージの追跡、コンプライアンス遵守、安全なデータ共有といったテーマが扱われます。アクセス制御の単位も、ファイル単位ではなくテーブル・列・行レベルまで踏み込んだきめ細かな制御が可能になっている、というのが特徴です。さらに、データ資産だけでなくMLモデルや特徴量テーブルといったAI資産も同じポリシーで統治できる、という点もレイクハウスならではの論点として挙げられています。
感想
ここからは、本書を読んで個人的に感じたことをいくつか書きたいと思います。
データマネジメントの考え方は変わらない
本書で書かれている内容の多くは、レイクハウスアーキテクチャに限った話ではありませんでした。
レイクハウスアーキテクチャという新しい概念であることは間違いありません。ただ、本書で必要とされていることの多くは、データモデリング（メダリオンアーキテクチャ、ディメンションモデリングなど）、ガバナンス・権限管理、個人情報保護といった、これまでDWH時代から我々データエンジニアが取り組んできたデータマネジメント全般のテーマと重なります。
つまり、レイクハウスに移行したとしても「データマネジメント全般としてやるべきこと」自体はあまり変わらないということです。これまで取り組んできたことが、レイクハウスの文脈でも引き続き重要なままだ、というのが素直な印象でした。
ただ、誤解のないように補足しておくと、「やるべきことは変わらない」とはいっても、レイクハウス特有のオペレーションがまったく発生しないわけではありません。例えばOTFでは、書き込みのたびに小さなファイルが大量にできてしまうため、それらをまとめる「コンパクション」や、不要になった古いファイル・スナップショットを削除する「バキューム」といった、OTF特有のメンテナンス運用が新たに発生します。「レイクハウスが流行っているから」と安直に採用してしまうと、こうした運用コストに苦戦するかもしれない、という点には注意が必要だと思います。
レイクハウスを理解するためにはOTFを理解しよう
データマネジメントとしてやることは大きく変わらないとすれば、逆に変わることはなんでしょうか。私がレイクハウスを理解するうえで決定的に重要だと感じたのが、OTF（オープンテーブルフォーマット）の存在です。
これまではパーティションの制御や、それを利用したデータのプルーニングといった話は、DWHが内部で解決してくれる問題として扱われていました。それが、IcebergやDelta LakeといったOTFによって、オブジェクトストレージ上でも実現できるようになった、というのがレイクハウスを成立させている技術的な土台です。
OTFはテーブルの実体であるParquetファイル群とは別に、「どのファイルがテーブルのどのバージョンに属するのか」を記述したメタデータ層を管理してくれます。これがあるおかげで、SparkからもTrinoからもSnowflakeからも、同じテーブルを矛盾なく読み書きできるようになります。「1つのデータを複数のコンピュートで共有する」というレイクハウスの根幹は、OTFがあって初めて実現できるわけです。
逆に言えば、レイクハウスはOTFを前提として成り立っているアーキテクチャです。OTFがなければ、レイクハウスは「データを溜めているだけのデータレイク」と本質的に変わらないものになってしまいます。本書を読んで強く感じたのは、レイクハウスアーキテクチャを理解しようと思ったら、まずOTFが何を解決してくれているのかを理解するのが近道だ、ということでした。
なお、OTFそのものをより深く学びたい方には、『実践Apache Iceberg』（田中智大・疋田宗太郎 著、技術評論社）という書籍が参考になります。代表的なOTFであるApache Icebergについて、その仕組みから実運用のノウハウまで体系的に解説されている一冊なので、本書と合わせて読むとレイクハウスの土台への理解がぐっと深まると思います。
レイクハウスアーキテクチャを採用するメリット
レイクハウスを採用するメリットはいくつもありますが、本書を読んで個人的に印象に残ったのは、ベンダーロックインの回避・コンピュートの自由な選択・コスト最適化のあたりでした。それぞれ簡単に説明しておきます。
ベンダーロックインの回避は、データを特定ベンダーのDWHの中ではなく、オブジェクトストレージ上のオープンな場所に置くことで得られるメリットです。データが特定の製品に閉じ込められないので、別のDWHやエンジンに乗り換えたくなったときの移行の負担を抑えやすくなります。
コンピュートの自由な選択は、ストレージとコンピュートが分離されることで、ワークロードごとに最適なエンジンを選べるというものです。分かりやすいのは機械学習との組み合わせかと思います。例えば「機械学習だけはGoogleのVertex AIをどうしても使いたい」というケースは結構あると思うのですが、レイクハウスの構成を取っていれば、機械学習の部分だけVertex AIを採用して、それ以外はSnowflakeのDWH機能を使う、というような組み合わせができるようになります。同じデータを共有しながら、ワークロードごとに最適なコンピュートを当てに行ける、というのは非常に大きな利点だと感じます。
コスト最適化は、安価なオブジェクトストレージにデータを置けること、そして用途に応じて適切なコンピュートを選べることから生まれるメリットです。例えば、すべての加工を高性能な（その分高価な）Snowflakeのコンピュートで行うのではなく、一部の集計はDuckDBのような安価なエンジンに任せる、といった使い分けも柔軟にできるようになります。
これらのメリットは、相互に関連したものです。レイクハウスアーキテクチャの「オープン性」という特徴が、ベンダーロックインを回避することに繋がり、コンピュートを自由に選択できるため、最適なソリューションを使えたり、コスト削減に繋げられたりするということです。
誰に刺さるアーキテクチャか
最後に、レイクハウスアーキテクチャが誰に刺さるアーキテクチャなのかという点についても、自分なりの考えを書いておきたいと思います。
個人的には、大きめの企業で、データの種類が多い／部署が多い／買収が多い、といった事情でマルチクラウドDWHになりそうなケースに向くアーキテクチャだと感じました。複数のクラウドベンダーをまたいでデータが散らばってしまう状況や、組織再編・M&Aで複数のDWHが社内に併存している状況では、データをオープンな場所に置いて共通のストレージレイヤーとして扱う、というレイクハウスの思想が活きてきます。
ただし、ここまで書いてきた通り、レイクハウスは構成要素が多く、ガバナンスやカタログまで含めて自分たちで設計・運用していく必要があるアーキテクチャです。運用コストはそれなりに大きいので、すべての企業に気軽に勧められるかというと、そこは微妙なところです。「DWH一本で十分回っているのに、わざわざレイクハウスにする必要はあるか？」と問われたときに、明確にYesと答えられる事情がない場合は、無理にレイクハウスを目指さなくてもよいのかな、というのが現時点での個人的な見解です。
おわりに
今回は『Practical Lakehouse Architecture』を題材に、レイクハウスアーキテクチャについて整理してみました。レイクハウスは、データをオープンな場所に置くという発想に立った大きなアーキテクチャの選択肢で、ベンダーロックインの回避や、ワークロードに応じたコンピュート選択といった大きなメリットがあります。一方で、やるべきデータマネジメントの仕事自体はDWH時代からあまり変わらず、運用コストも相応にかかる、というのが正直なところかなと思っています。
最後までお読みいただきありがとうございました。
今後もデータエンジニアリング領域の記事を書いていこうと思います。普段はXでデータエンジニアリングの情報を発信しているので、興味を持っていただけた方は、ぜひXの方もフォローいただけると幸いです。