Deep Dive into the New Lakehouse Paradigm and How It Works - The Databricks Blogの翻訳です。

本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

今年(2020年)の初頭、Databricksはどれだけ多くの企業がレイクハウスパターンを導入しているのかを説明するブログ記事を投稿しました。この記事は技術の信奉者からの多大なる興味を惹くことになりました。多くの人がこれを次世代のデータアーキテクチャと称賛した一方で、何人かの人はレイクハウスはデータレイクは同じものだと考えました。最近、我々のエンジニアと創始者の何人かで、いくつかのコアとなる技術的課題とそれに対するソリューションとしてデータレイクとは異なるレイクハウスパラダイムを説明する研究論文を執筆し、Very Large Databases (VLDB) 2020の国際学会でアクセプトされ公開されました。論文「Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores」を読むことができます。

ヘンリーフォードは以下の発言で頻繁に引用されています。「もし私が人々に何が欲しいかと尋ねたら、彼らはより早い馬と答えたことでしょう」この話の最も重要なことは、人々は多くの場合、問題に対するソリューションを完全に再考するのではなく、問題に対するソリューションとして既に知っているソリューションの進化系を思い描くということです。データストレージの世界においては、数年に渡りこのパターンが用いられていました。ベンダーは新たなソリューションを探すのではなく、データウェアハウス、データレイクといった古い馬を再発明し続けていました。

10年以上前、クラウドはデータストレージに対する新たなフロンティアを生み出しました。Amazon S3のようなクラウドオブジェクトストレージは世界で最も大きく、最もコスト効率の高いストレージシステムとなり、データウェアハウスやデータレイクよりも魅力的なプラットフォームとなりました。しかし、キーバリューストアという特性のため、多くの企業が必要とするACIDトランザクションを実現することが困難でした。また、高価なメタデータのオペレーション(オブジェクトの一覧など)によって性能が阻害され、一貫性保証も限定的なものでした。

オブジェクトストアの特性に基づき3つのアプローチが出現しました

データレイク

オブジェクトのコレクション、特にApache Parquetのような列指向フォーマットとしてテーブルを格納するファイルのディレクトリが最初に出現しました。テーブルは多くの追加のデータストアやシステムなしに、幅広いツールからアクセスできるオブジェクトのグループであったので、これは魅力的なアプローチでした。しかし、性能と一貫性の問題は共通するものでした。トランザクションの失敗による隠れたデータ破損は一般的なものであり、結果的整合性は一貫性のないクエリーを引き起こし、レーテンシーは高く、テーブルのバージョン管理や監査ログのような基本的なデータ管理機能は利用できませんでした。

カスタムストレージエンジン

二つ目のアプローチは、Snowflakeデータウェアハウスのようなクラウド向けに構築されたプロプライエタリなシステムのようなカスタムストレージエンジンでした。これらのシステムは、信頼できる唯一の情報源(single source of truth)を提供することができる、独立した強力な一貫性のあるサービスでメタデータを管理することで、一貫性の問題を回避することができます。しかし、全てのI/Oオペレーションはこのメタデータサービスに接続する必要があり、リソースのコストを増加させ、パフォーマンスと可用性を減少させました。さらに、Apache Spark、TensorFlow、PyTorchのような既存の計算エンジンに対するコネクターを実装すrためには多大なエンジニアリング高数を必要とし、自身のデータに対して様々な計算エンジンを適用しているデータチームにとっての課題となりました。これらのシステムは通常、伝統的な構造化データタイプに最適化されているため、非構造化データによってエンジニアリング上の課題は悪化しました。最後に、そして最も悪いこととして、プロプライエタリなメタデータサービスはお客様を特定のサービスプロバイダーにロックインし、後でお客様が新たなアプローチを導入しようとした際には、高価かつ時間を消費するマイグレーションをお客様に突きつけることになりました。

レイクハウス

クラウドオブジェクトストレージ上で動作するオープンソースのACIDテーブルストレージレイヤーであるDelta Lakeを用いて、我々は単なる優れたデータソースを用いたより早い馬ではなく、レイクハウスを通じて、どのようにデータを格納し、活用するのかを根本的に変化させる自動車を作り出す方法を探しました。レイキハウスはデータレイクとデータウェアハウスの最良の部分を組み合わせた新たなパラダイムです。レイクハウスは新たなシステムデザインによって実現されます。データウェアハウスと同じようなデータ構造とデータ管理機能を実装し、データレイクで使用される低コストのストレージ上で直接動作します。これらは、安価かつ高信頼な(オブジェクトストアとしての)ストレージが利用できる近代世界で、あなたがストレージエンジンを再設計しなくてはならないとしたら、結果として得られるものと言えます。

Delta Lakeは、ログ先行書き込みを用い、どのオブジェクトがDeltaテーブルの一部であるのかに関する情報をACIDに基づいてParquetの中に維持し、この情報もクラウドオブジェクトストアで格納します。このデザインによって、クライアントはオブジェクトに対して並列読み込み/書き込みを行うことによる高い性能を実現できるシリアライズ可能な方法で、一度に複数のオブジェクトを更新したり、オブジェクトのサブセットを他のもので置換することなどが可能になります。このログは大規模テーブルデータセットに対して、劇的に高速なメタデータオペレーションを実現します。さらに、Delta Lakeはタイムトラベル(ある断面のスナップショットに対するクエリー、間違った更新のロールバック)、自動データレイアウト最適化、upsert、キャッシュ、監査ログのような先進的な機能を提供します。まとめると、これら全ての機能は、クラウドオブジェクトストレージでデータを操作する際の管理性と性能を改善し、最終的にはデータウェアハウスとデータレイクのキーとなる機能を組み合わせることで、より優れた、そして、よりシンプルなデータアーキテクチャを提供するレイクハウスパラダイムへの扉を開くことになります。

現時点でもDelta Lakeは数千のDatabricksのお客様で利用されており、オープンソースコミュニティのお客様含め、毎日エクサバイト規模の構造化、非構造化データが処理されています。これらのユースケースは、様々なデータソース、アプリケーションに渡っています。格納されるデータタイプには、企業のOLTPシステムからのChange Data Capture (CDC)ログや、アプリケーションログ、時系列データ、グラフデータ、レポートのための集計テーブル、画像、機械学習のための特徴量データなどが含まれます。アプリケーションには、SQLワークロード(最も一般的です)、BI、ストリーミング、データサイエンス、機械学習、グラフ分析などが含まれます。全体として、Delta Lakeは、ParquetやORCのような構造化ストレージフォーマットを使用する多くのデータレイクアプリケーション、多くの従来型のデータウェアハウスワークロードに適したものであることを証明しています。

これらのユースケースにおいて我々は、お客様がワークロードを直接クラウドオブジェクトストレージ上で実行することでデータアーキテクチャを劇的にシンプルにするためにDelta Lakeを活用していること、そして徐々に、メッセージキュー(Apache Kafkaなど)、データレイク、クラウドデータウェアハウス(Snowflake、Amazon Redshiftなど)の一部、あるいは全てを置き換えるためにデータレイクとトランザクション機能の両方を用いてレイクハウスを作成していることを知りました。

研究論文では、著者は以下のことを説明しています。

オブジェクトストアの性質、課題
Delta Lakeストレージフォーマット、アクセスプロトコル
現時点で提供されているDelta Lakeの機能、メリット、制限
現時点で一般的に活用されているコア、特殊なユースケース
TCP-DSパフォーマンスを含むパフォーマンス試験

論文を通じて、Delta Lake自身、そして、どのように低コストなクラウドストレージに対してDBMSライクのパフォーマンス、管理機能を実現しているのかをさらに理解できることでしょう。Delta Lakeのストレージフォーマット、オペレーションをシンプル、高可用性にし、オブジェクトストアに対する広帯域アクセスを提供するするためのアクセスプロトコルも説明されています。

研究論文のダウンロード

Databricks 無料トライアル

Databricks 無料トライアル