レイクはデータベースではない。エンジンこそがデータベースだ

現在、会議場やブログ記事、アーキテクチャ図などで語られているのは、データが一定規模に達すると、レイクハウス型アーキテクチャが標準になるという話です。かつては複数のシステムに分散していたデータは、今ではオープンフォーマットのオブジェクトストレージに集約され、必要なコンピューティング層からアクセスできるようになります。

そこから先は、ほとんど必然的に思えます。すべてがレイクの中に存在するなら、なぜすべてをレイク上で直接実行しないのでしょうか？なぜレイクをデータベースにしないのでしょうか？

それは魅力的なアイデアであり、適切な条件下では宣伝どおりに機能します。問題は、その条件が、一般的に言われているよりも具体的であるということです。なぜなら、問題はデータをこのように保存できるかどうかではないからです。保存できることは明らかです。問題は、データが静止状態ではなく、アプリケーションによって積極的に照会、更新され、負荷がかかった状態で応答することが求められる場合に何が起こるかということです。

ストレージは実行ではない

オブジェクトストレージは、実際の課題を解決するため、データプラットフォームの中核を担う存在となっています。耐久性、拡張性、コスト効率に優れ、オープンテーブル形式によってデータの整理やツール間での共有が可能になります。

しかし、ストレージは、どれほど整理されていても、データベースのように動作するわけではありません。

データベースは、その実行方法によって定義されます。クエリへの応答速度、並行処理時の挙動、更新やトランザクションの処理方法、システム負荷時のレイテンシの予測可能性などです。これらはストレージに関する問題ではなく、実行層、つまりシステムがデータ処理を要求された際に実際にどのようにデータを処理するかという点から生じるものです。

Parquetファイルにデータを保存し、その上にメタデータを重ね合わせ、新しいデータをシステムに継続的に供給するパイプラインを構築することは可能です。しかし、オブジェクトストレージの根本的な特性を変更することはできません。オブジェクトストレージは、低遅延で高並行実行を実現するためではなく、耐久性と拡張性を重視して最適化されているからです。

ストレージ優先モデルが破綻し始める場所

実際には、このシステムはかなり一貫した形でトレードオフを示し始めます。

頻繁な書き込みによって大量の小さなファイルが生成され、継続的な最適化が必要となる一方、クエリは拡大し続けるメタデータとますます断片化していくレイアウトをナビゲートしなければなりません。断片化が蓄積し、システムはバックグラウンドプロセスに依存して秩序を回復します。クエリのパフォーマンスはデータの物理的な構成方法に左右され、同時実行性が増加してもレイテンシは改善されません。

これらはどれも驚くべきことではありません。ストレージに実行機能を組み込むのではなく、ストレージの上に重ねて実行する場合に起こることです。それを補うために、さらに多くのレイヤーが導入されます。

データの整理を維持するために、バックグラウンドでの最適化および圧縮ジョブが導入されています。

遅延を低減するために、キャッシング層が追加されています。

運用ワークロードに対応し、データから価値を引き出すために、個別のシステムが登場し、多くの場合、データをデータレイクから下流のデータベースに移動させて、アプリケーションやダッシュボードに利用します。

その時点では、アーキテクチャはもはやレイク自体によってではなく、その周囲の実行レイヤーによって定義されます。これらのレイヤーの中には、回避策として機能するものもあれば、システムそのものとなるものもあります。

レイクハウスが適している場所

このモデルは、即時応答性よりも拡張性が重視される大規模データセットに非常に適しています。ログ、クリックストリームデータ、テレメトリ、その他追加処理の多いワークロードは、このモデルに最適です。また、一度保存して複数のシステムからアクセスしたり、アーカイブしたりすることでメリットが得られる、大規模な非構造化データコレクションにも適しています。

こうした環境において、レイクハウスは調整レイヤーとして機能します。データは一度存在すれば、重複や移動を繰り返すことなく、複数の方法で解釈することが可能です。経済的なメリットも大きく、柔軟性も非常に高いと言えます。

レイクハウスには必ずエンジンが必要だ

レイクハウスはデータを一元管理し、実行エンジンはそのデータが使用される際の動作を決定します。システム間の実際的な違いのほとんどは、この部分で現れ始めます。

対話型ワークロード向けに設計されたエンジンは、パフォーマンスを維持するために圧縮サイクルやバックグラウンド補正に依存しません。データに直接作用し、同時実行数が増加しても低遅延かつ予測可能なレイテンシを維持する方法で、データの取り込み、クエリ、更新を処理します。トランザクションワークロードと分析ワークロードを別々のパスに分離するのではなく、同じシステムの一部として処理します。

これにより、レイクハウスは単なる保管場所という枠を超え、制約を補うためのレイヤーを追加することなく、アプリケーション、リアルタイム分析、AIシステムをサポートできる存在へと進化することが可能になるのです。

そのようなエンジンがなければ、レイクハウスは便利ではあるものの、用途が限られてしまいます。そこはデータが大量に保存され、処理される場所というだけです。しかし、そのようなエンジンがあれば、同じデータに対して継続的に処理を行うことができ、システムがバックグラウンドで再編成されるのを待つことなく、再び利用可能になります。