レイクハウスはいいぞ。

みなさんデータ管理してますか？
はい、私はしています。
データをいかに柔軟かつ厳格かつ低コストに管理するか、日々苦戦しています。
世の中のデータエンジニアのみなさんも同じ苦しみを抱えているので色んな技術が現れており、今回紹介するレイクハウスもそのひとつです。

どんな課題があってレイクハウスが登場し、どう良くなったのか、デメリットは何かを見ていきましょう。

従来の2層アーキテクチャの課題

まずはデータウェアハウスができました。
構造化された（表形式の）データであればどんなビッグなデータであっても扱えるので、分析用途に重宝されました。
しかし扱えるのが表形式だけというのは、いささか不便です。
SNSが普及して画像や音声、映像など、テキストだけでなく色んな形式のデータが飛び交っていたからです。

そこでデータレイクがデータウェアハウスの前段に追加されました。
その名の通りデータが湖のごとく貯められている場所です。
どんな形式でもどんなに容量が大きくても柔軟かつ低コストに貯められるのですが、データ管理が難しくてあちこちに湖ができたり、あるいは湖ではなく沼ができたりしました。

またデータレイク+データウェアハウスの組み合わせはETLの過程が複雑になったりデータの整合性を取ったりするのが難しかったのです。
それにデータの置き場所が２か所になることで当然コストも余分に掛かりました。

レイクハウスの登場

色んな形式のデータをコスト低く扱いたいし、データガバナンスを確保するためにデータの管理も上手くやりたい。
そんな期待を背負って登場したのがレイクハウスです。

レイクハウスではデータを引き続きデータレイクに置いたまま、その上に一層かぶせることでデータウェアハウスと同じようにデータ管理しやすくしています。
なのでデータが大きくなっても低コスト大容量を実現できますし、どんな形式のデータを置いてもいいわけです。
今のところ画像や音声、動画をそのままクエリできるわけではありませんが、何らかの処理を行って再びレイクハウスに置き直せば表形式データとして扱えるようになります。
またACIDトランザクションやデータのバージョン管理、メタデータ管理機能も持ち合わせています。
データは1か所にしか存在していないので整合性の問題もコストが二重に掛かる問題も起きません。

デメリット

そんなにありません。
あるとすれば、まだ発展途上の技術なのでよくわからないことがバグを踏む可能性があるぐらいでしょうか。

まとめ

レイクハウスはいいぞ。