こんにちは。今日は、Databricks社が発表したLakhouseアーキテクチャの論文を日本語で要約しながら読んでみたので、メモを残しておきます。なお、翻訳と要約にはChatGPTを利用しています。
Databricks社からの論文はこちらで公開されているようなので、今後もウォッチしたいですね。
Databricks Research | Databricks
Contents
論文翻訳
Abstract
- 現在のデータウェアハウスアーキテクチャは衰退し、新しい「Lakehouse」アーキテクチャに置き換わる。
- Lakehouseは、(i) オープンなデータ形式（Apache Parquetなど）をベースにし、(ii) 機械学習とデータサイエンスを一流でサポートし、(iii) 最先端のパフォーマンスを提供する。
- Lakehouseはデータウェアハウスに関する多くの課題を解決するのに役立つ。例えば、データの古さ、信頼性、総所有コスト、データのロックイン、限定的なユースケースのサポート。
- 業界は既にLakehouseに移行しており、データ管理にどのような影響を及ぼすかについて議論されている。
- Parquetを使用したLakehouseシステムの結果も報告され、TPC-DSで人気のあるクラウドデータウェアハウスと競合している。
1, Introduction
これまでのデータアーキテクチャ
- データウェアハウスの歴史は、ビジネスリーダーが運用データベースからデータを収集し、集中型データウェアハウスに格納して分析に使用することから始まりました。
- 第一世代のデータ分析プラットフォームは、スキーマを書き込み時に定義して、データモデルを最適化しました。
- 第一世代のシステムは、計算とストレージをオンプレミスのアプライアンスに結合し、データセットの増加に伴いコストが高騰しました。
- 第二世代のデータ分析プラットフォームでは、生データをデータレイクにオフロードし、低コストのストレージシステムを使用しました。
- データレイクは柔軟なスキーマ-on-readアーキテクチャを採用し、多くの分析エンジンへの直接アクセスを可能にしました。
- クラウドデータレイクが普及し、HDFSの代替として採用されました。クラウドデータレイクは非常に耐久性が高く、低コストのストレージを提供し、自動アーカイブストレージもサポートします。
- クラウドにおけるアーキテクチャは、第二世代のシステムとほぼ同じで、データレイクとデータウェアハウスの2つの階層から成り立っており、業界で主流となっています。
現在のデータアーキテクチャの課題
- クラウドデータレイクとウェアハウスのアーキテクチャは、ストレージとコンピュートを分離するため、表面的にはコストが低いが、ユーザーにとっては高度に複雑です。
- 最初の世代のプラットフォームでは、すべてのデータは運用データシステムから直接データウェアハウスにETLされましたが、現代のアーキテクチャではデータはまずデータレイクにETLされ、それから再びデータウェアハウスにETLされるため、複雑さ、遅延、新しい障害モードが発生します。
- 企業のユースケースには機械学習などの高度な分析も含まれており、データレイクやデータウェアハウスは理想的でない。
- 現代のデータアーキテクチャは、信頼性の問題、データの新鮮さの問題、高度な分析のサポートの限界、総所有コストの問題という4つの問題に直面しています。
課題の解決策：Lakehouse
- この論文では、標準的なオープンデータフォーマット（例：ParquetおよびORC）を基にしたデータレイクを、データウェアハウスの性能と管理機能、高度な分析ワークロードからの高速で直接のI/Oを提供できる高性能なシステムに変換することが可能かどうかについて議論されています。
- このシステムデザインは「Lakehouse」と呼ばれ、業界内でさまざまな形で成功の兆候が見られており、操作データと高度な分析に依存するビジネスアプリケーションが増えるにつれて、データウェアハウジングの主要な課題の一部を解決できる魅力的な設計ポイントであると主張されています。
- Lakehouseにより、次の主要な問題が解決されました。
- データレイクでの信頼性のあるデータ管理: Lakehouseは、今日のデータレイクと同様に生データを保存できる必要があり、同時にデータの品質を向上させるためにETL/ELTプロセスをサポートする必要があります。最近のシステム、Delta LakeやApache Icebergなど、データレイクのトランザクショナルビューを提供し、トランザクション、以前のテーブルバージョンへのロールバック、ゼロコピークローニングなどのデータウェアハウスでのETL/ELTを簡素化する重要な管理機能を提供します。
- 機械学習とデータサイエンスのサポート: MLシステムはすでにデータレイク形式から直接読み取りをサポートしており、Lakehouseへの効率的なアクセスが可能です。また、多くのMLシステムはデータ操作の抽象化としてDataFramesを採用しており、最近のシステムではデクラレーティブなDataFrame APIを設計して、MLワークロードのデータアクセスのクエリ最適化を実現しています。これらのAPIはLakehouseの多くの最適化をMLワークロードに直接活用できるようにします。
- SQLパフォーマンス: Lakehouseは、過去10年間に蓄積された大量のParquet/ORCデータセット（または長期的には直接アクセス可能な他の標準フォーマット）の上で最新のSQLパフォーマンスを提供する必要があります。データウェアハウスはSQLを受け入れ、プロプライエタリなストレージフォーマットを含むすべての要素を最適化することができます。しかし、Parquet/ORCデータセットに関する補助データとこれらの既存のフォーマット内でのデータレイアウトの最適化に関するさまざまなテクニックを使用して、競争力のあるパフォーマンスを達成することができます。Databricks Delta EngineなどのSQLエンジンは、TPC-DSで主要なクラウドデータウェアハウスを上回る結果を示しています。
- 論文の残りの部分では、Lakehouseプラットフォームの動機、技術的な設計の可能性、研究の影響について詳細に説明します。
2, Motivation: Data Warehousing Challenges
- データウェアハウスは多くのビジネスプロセスに不可欠ですが、誤ったデータ、データの新鮮さの不足、高コストといった課題が頻繁にユーザーを困惑させています。
- これらの課題の一部は、企業データプラットフォームの設計に起因する「偶発的な複雑さ」から生じており、Lakehouseを導入することで解消できると主張されています。
- データ品質と信頼性の問題が最も報告されるトップの課題であり、現在の二層データアーキテクチャはこれを悪化させる余分な複雑さを持っています。
- データの新鮮さの問題も増加しており、データウェアハウスへのデータロード前にデータのステージング領域を別途持ち、定期的なETL/ELTジョブを使用してデータをロードしているため、データは新鮮さを失います。
- 多くの業界でデータの大部分は非構造化データであり、SQLデータウェアハウスとそのAPIはこれをサポートしづらいです。
- 機械学習とデータサイエンスアプリケーションの普及が進んでいますが、データウェアハウスとデータレイクはこれに適していません。これらのアプリケーションは非SQLコードで大量のデータを処理する必要があり、ODBC/JDBCを介した実行は効率的ではありません。
- 現在の業界動向からも、2階層のデータレイク+ウェアハウスモデルに不満を持つ顧客が多いことが示唆されています。データウェアハウスは外部テーブルのサポートを追加し、データレイクからのクエリを可能にしましたが、データレイクテーブルの管理、ETLの複雑さ、データウェアハウス内のデータの新鮮さや高度な分析の課題は解決されていません。
- 直接データレイクストレージを対象とするSQLエンジン（例：Spark SQL、Presto、Hive、AWS Athenaなど）への広範な投資が行われていますが、これらのエンジンだけではデータレイクの問題をすべて解決することはできません。データレイクはまだACIDトランザクションやインデックスなどの基本的な管理機能を欠いており、データウェアハウスのパフォーマンスに匹敵するアクセス手法も提供していません。
3, The Lakehouse Architecture
- Lakehouseは、低コストなストレージを基にし、同時にACIDトランザクション、データバージョニング、監査、インデックス、キャッシング、クエリの最適化などの伝統的な分析DBMSの管理機能とパフォーマンス機能を提供するデータ管理システムと定義されます。
- Lakehouseは、データレイクとデータウェアハウスの主要な利点を組み合わせています。データレイクからの低コストのオープンフォーマットでのストレージへのアクセス可能性と、データウェアハウスからの強力な管理および最適化機能を結合しています。
- 主要な問題は、これらの利点を効果的に組み合わせることができるかどうかです。特に、Lakehouseの直接アクセスのサポートは、関係型DBMS設計の基盤であったデータ独立性の一部を放棄することを意味します。
- Lakehouseは、クラウド環境に特に適しており、コンピュートとストレージが分離されています。異なるコンピューティングアプリケーションは完全に分離されたコンピューティングノードでオンデマンドで実行できますが、同じストレージデータに直接アクセスできます。
- Databricksでは、このデザインを基にしたLakehouseプラットフォームの構築を進めており、Delta Lake、Delta Engine、Databricks ML Runtimeプロジェクトを通じて実現しようとしています。しかし、他のデザインや具体的な技術的選択肢も可能であり、さまざまな代替案と将来の研究方向について議論されています。
3.1, Implementing a Lakehouse System
- Lakehouseの実装には、低コストのオブジェクトストア（例：Amazon S3）でデータを保存し、トランザクションメタデータ層を追加するアイディアがあります。これにより、管理機能を提供しながら、低コストのオブジェクトストアから通常のファイルフォーマットを使用してデータを直接読み取ることができます。
- メタデータ層は管理機能を提供しますが、SQLパフォーマンス向上には追加の最適化が必要です。これには、キャッシング、補助データ構造（インデックスや統計情報）、データレイアウトの最適化などが含まれます。
- Lakehouseはデータ管理機能を高速化し、宣言的DataFrame APIによって高度な分析ワークロードをサポートします。MLライブラリもLakehouseと統合でき、最適化が可能です。
- これらの技術アイデアについての詳細は後続のセクションで説明します。
3.2, Metadata Layers for Data Management
- Lakehouseの実現には、データレイクストレージ上のメタデータレイヤーが重要です。これにより、ACIDトランザクションなどの管理機能が実現できます。Delta LakeやApache Icebergなどのシステムは、これらの機能を提供し、データ品質向上、ガバナンス機能の実装にも役立っています。
- メタデータレイヤーはデータ品質やアクセス制御などを管理し、データレイクベースのパイプラインの品質向上に寄与します。
- 今後の方向性や代替デザインに関しては、まだ多くの未解決の問題が存在し、さまざまなデザインオプションが検討されています。
3.3, SQL Performance in a Lakehouse
- Lakehouseアーキテクチャの主要な課題は、データ独立性の一部を犠牲にする一方で、最先端のSQLパフォーマンスを提供する方法です。データフォーマットはパブリックAPIの一部であるため、データフォーマットに依存しないSQLパフォーマンスの最適化手法が提案されています。
- 最適化手法には、キャッシング、補助データ、データレイアウトが含まれます。これらの手法は典型的な分析ワークロードに適しており、パフォーマンスを向上させます。
- Databricksは、Delta Engineを使用してこれらの最適化手法を実装し、クラウドデータウェアハウスと競合するパフォーマンスを提供し、低コストで利用できることを示しました。
- 将来の方向性として、新しいデータレイクストレージフォーマットの設計や、キャッシング戦略、補助データ構造、データレイアウト戦略の研究があります。
- サーバーレスコンピューティングシステムを使用してクエリを最適化し、レイテンシを最小限に抑える研究も行われています。
3.4, Efficient Access for Advanced Analytics
- 高度な分析ライブラリは通常SQLではなく命令型コードで書かれており、データアクセス層の設計が柔軟性と最適化の両方を実現する挑戦です。
- データフレームAPIの宣言的バージョンを提供するアプローチは成功しており、Delta LakeとDelta Engineの最適化を活用できます。
- Sparkのクエリプランナーは選択とプロジェクションをデータソースプラグインにプッシュし、Delta Lakeの最適化を使用してMLおよびデータサイエンスのワークロードを高速化します。
- 機械学習APIも進化しており、データアクセスAPIも存在しますが、データウェアハウスではあまり注目されていません。
- データアクセスインタフェースに関する異なるデザインや新しいフォーマットの検討が必要です。
- データサイエンティスト向けにLakehouseの機能を活用できる標準インタフェースが必要です。例えば、MLflowとDelta Lakeの統合などがあります。
4, Research Questions and Implications
- Lakehousesに関する今後の研究課題として、ストレージフォーマットやアクセスAPIの適切な選択が挙げられます。
- データのオープンフォーマットを維持することは、コスト、可用性、ガバナンスの観点から重要であると考えられます。
- Lakehouseの影響はデータ管理の他の分野にも及び、データ統合、クリーニング、HTAPシステム、MLデータ管理などに新たな可能性をもたらすでしょう。
- データエンジニアリングプロセスとチームの組織についても議論があり、Lakehouseデザインは分散コラボレーションに適しているとされています。
さいごに
最後に、翻訳を担当したChatGPTから感想を貰いましたので共有します。
また、レイクハウスについてうまいのかうまくないのかよく分からない例え話ももらったのでこちらも共有します。
おしまい
コメントを残す