レイクハウスアーキテクチャの全体像をつかむ一冊『Practical Lakehouse Architecture』を読む
宮﨑 一輝
はじめまして。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によって管理されており、他のツールからそのデータを参照したい場合には、エクスポートや転送といった手間が発生する、という構造になっています。
