- データ管理分野は急速に変化しており、クラウドストレージとリアルタイム分析需要の増加により、Data Lakehouseの概念が台頭している
- Apache Iceberg、Apache Hudi、Delta Lakeのようなプロジェクトは、Lakehouseアーキテクチャにスキーマ進化、ACIDトランザクション、効率的な更新などの中核機能を提供してきた
- Googleの内部システム Napa は、現在のLakehouseソリューションより一段進んだアプローチを提示している
- さらに Apache Pinot など他のシステムのアイデアを加え、Lakehouseの次世代形であるLakeDBを提案する
現在のLakehouse環境: Iceberg, Hudi, Delta Lake
- Apache Iceberg
- 洗練されたメタデータ管理により、スキーマ進化、タイムトラベル、効率的なクエリプランニングをサポートする
- 大規模な分析データセットに対する一貫性保証を提供する
- Apache Hudi
- ログ構造ベースのストレージとインデックスを活用し、upsert、delete、CDC(変更データキャプチャ)を効率的に処理する
- データ変異と増分処理を重視する
- Delta Lake
- Sparkとビッグデータワークロード向けにACIDトランザクションを提供する
- スキーマ検証、タイムトラベル、バッチ・ストリーミング統合処理をサポートする
- Delta Live Tablesを通じて宣言型パイプラインとマテリアライズドビューを一部提供する
GoogleのNapa: マクロなアプローチ
- 完全な分析データ管理システムとして、大規模データを対象に低レイテンシなクエリと継続的なデータ取り込みをサポートする
- LSM(Log-Structured Merge)-Tree ベースの取り込み
- 高い書き込みスループットのためにLSM-tree方式を採用し、compactionを通じて既存データとマージする構造を持つ
- マテリアライズドビュー の活用
- クエリ高速化のためにマテリアライズドビューを自動的に維持・更新する
- Queryable Timestamp(QT)
- システム全体で一貫した時点管理を提供する
- データ鮮度とクエリ性能のバランスを細かく調整できる
- F1 Query統合
- GoogleのF1 Queryエンジンを活用し、複雑な分析クエリを効率的に処理する
- 高い構成可能性
- ユーザー要件に合わせてデータ鮮度、性能、コストなどを調整できる
Napa, Iceberg, Hudi, Delta Lake の比較
- Napaは包括的な分析データ管理システムであり、LSMベースのマテリアライズドビューを通じて高速クエリを支援し、Queryable Timestamp(QT)という手法でデータ鮮度を細かく調整する。大規模データを高速に分析・レポートしたい場面で有用であり、高い設定柔軟性によってコスト、性能、鮮度を適切にバランスさせて管理できる。
- Icebergはテーブルフォーマットに焦点を当てたプロジェクトで、メタデータを通じて大規模なデータファイルを管理し、atomic update(アトミック更新)のような機能を提供する。主にデータウェアハウジングやスキーマ進化、タイムトラベルのような機能を必要とするデータレイク環境で活用され、構成オプションは主としてテーブルレイアウトやメタデータに集中している。
- Hudiはデータレイクにデータベースに似た機能を組み込んだプラットフォームで、ログ構造ベースのストレージとインデックス技法によってupsertや削除のようなデータ変異操作を効率的に処理する。リアルタイム取り込みや変更データキャプチャ(CDC)、GDPRのような規制順守要件にもよく対応できるよう設計されているが、マテリアライズドビュー機能は基本的に提供しない。
- Delta LakeはACIDトランザクションをサポートするストレージレイヤーであり、バッチとストリーミング処理を統合的に扱いながら、スキーマ enforcement(強制)とタイムトラベル機能も提供する。クエリ性能向上のためにSparkと連携してデータスキッピングやキャッシュを活用し、別途 Delta Live Tables を通じてマテリアライズドビューのような概念もサポートする。さまざまなデータレイク環境で信頼性とトランザクション機能を追加したいときに使われるケースが多い。
LakeDBに対する主張: Napaに着想を得て、他から学ぶ
- NapaおよびApache Pinotなどの革新的なアイデアを組み合わせ、より統合的で柔軟なLakeDBという概念を提案する
- LakeDBは、ユーザー要件(鮮度、コスト、一貫性、インデックス利用など)を宣言的に表現すると、システムが自動的に最適化してくれるデータ管理ソリューションを志向する
1. ストレージ・取り込み・メタデータ・クエリ処理の統合
- 1つのシステム内にストレージ、取り込み、メタデータ、クエリ処理のすべてを含む
- ユーザーはデータ鮮度と一貫性だけを指定すれば、必要な作業が自動的に調整される
- Iceberg、Hudi、Delta Lakeはこの部分で別ツールとの連携が必要なため、複雑性が増す
2. マテリアライズドビューとデータレイアウトの知的最適化
- CoW(Copy-on-Write)とMoR(Merge-on-Read)方式をワークロードに合わせて自動で切り替える
- ユーザー定義の性能・コスト要件に応じて、スナップショットおよびマテリアライズドビューを適切に生成・管理する
- Hudi、Delta Lake、Icebergではこのプロセスの大半を手動で設定しなければならない
3. 細かなデータ鮮度制御
- NapaのQTのように、ユーザーが望む鮮度レベルを指定すると、システムが性能・コスト間のトレードオフを見つける
- 既存システムでは定期的なスナップショットとモニタリングに依存しており、リアルタイム性の保証が難しかった
4. Apache Pinotに着想を得た高度なインデックスとパーティショニング
- Star-Treeのような高度なインデックス方式をサポートし、高カーディナリティな分析にも対応可能にする
- Iceberg、Delta Lakeの単純なパーティショニングやデータスキッピングを超える性能向上を目指す
5. 柔軟な構成
- 同じテーブルを複数のコンシューマーがそれぞれ異なる性能・コスト・鮮度要件に合わせて設定できる
- 既存システムは設定範囲が限定的で、多様化したワークロードに対応するには多くの手作業チューニングが必要になる
6. ACIDとスキーマ進化のサポート
- Iceberg、Delta LakeのACIDおよびスキーマ進化の基盤を継承・拡張する
- 分散環境での同時スキーマ変更やデータ一貫性保証を自動化しようとする
7. オープン性と拡張性
- オープンスタンダードと多様なクエリエンジン連携をサポートし、必要に応じて拡張できる
- 特定ベンダーやプラットフォームに依存せず、ユーザー要件に応じて機能を柔軟に適用できるようにする
LakeDBが次世代進化である理由
- 性能: 高度なインデックス、マテリアライズドビュー、動的なデータレイアウト最適化により、OLAPレベルの速度に近づく
- シンプルさ: 1つのシステムで管理機能を提供し、ユーザー要件(鮮度、性能など)だけを設定すれば自動的に調整される
- 効率性: リソース活用と運用負荷を減らし、コスト面でも利点が期待できる
- 柔軟性: 細かなデータ鮮度制御と豊富な設定オプションにより、多様なワークロードに対応できる
- リアルタイム分析: Apache Pinotのインデックス技法を導入し、低レイテンシと高スループットの両立を目指す
結論
- Apache Iceberg、Apache Hudi、Delta LakeはLakehouseの概念を発展させるうえで大きな役割を果たしてきた
- GoogleのNapaアプローチとApache Pinotなどから出てきたアイデアを組み合わせれば、より統合的で強力なLakeDBビジョンを構想できる
- LakeDBはストレージ、取り込み、メタデータ、クエリ処理を網羅する完成度の高い統合型システムとして、次世代データ管理アーキテクチャになる可能性が高い
まだコメントはありません。