レイクハウスと Delta Lake の内部構造
Databricks は以前のブログで、企業におけるレイクハウス（LH）採用の増加状況について解説しました。このブログの内容は、技術系のオーディエンスから大きな反響がありました。多くの方がレイクハウスを次世代のデータアーキテクチャとして賞賛してくださったのですが、データレイクと何ら変わらないのではいうご意見もいただきました。そこで、Databricks のエンジニアと創業者が、データレイクとは一線を画すレイクハウスパラダイムを核とする技術的課題とソリューションについてのリサーチペーパー「Delta Lake: High-performance ACID Table Storage over Cloud Object Stores」（Delta Lake：クラウドオブジェクトストアによる高性能ACIDテーブルストレージ）を共同執筆しました。このペーパーは、大規模データベースの国際会議 VLDB2020 で受理、発表されました。リサーチペーパーの全文はこちらからダウンロードできます。
「もし私が顧客に何が欲しいかと聞いていたら、彼らは、『もっと速い馬が欲しい』と答えていただろう」―フォード・モーター創業者ヘンリー・フォード この言葉の核心は、「人は、問題に対する本来のソリューションを考えるのではなく、自分の知る範囲でソリューションを思い描く」ということです。データストレージの世界では、長い間この傾向が続いていました。ベンダーは、新しいソリューションを模索するのではなく、データウェアハウスやデータレイクの「古馬」の改善を目指し続けたのです。
今から 10 年以上前に、クラウドがデータストレージの新境地を開きました。Amazon S3 をはじめとするクラウドオブジェクトストアは、極めて大規模かつ費用対効果の高いストレージシステムであり、データウェアハウスやデータレイクを保存するために有用なプラットフォームとなっています。しかし、key-value 型ストアの特性により、多くの組織で求められる ACID トランザクションを実現することは困難です。また、オブジェクトのリスト化などのメタデータ操作が高コストであること、一貫性が十分に保証できないことなどが、性能の妨げとなっています。
オブジェクトストアの特性に基づいた 3 つのアプローチ
データレイク
第一のアプローチはデータレイクです。テーブルをオブジェクトのコレクションとして保存するファイルのディレクトリで、通常は、Apache Parquet のようなカラム形式になっています。テーブルはオブジェクトの集合体で、多くのデータストアやシステムを追加する必要はなく、さまざまなツールからのアクセスが可能です。しかし、性能と一貫性に問題があります。トランザクションの失敗による隠れたデータ破損が発生しやすく、結果整合性により一貫性に欠けるクエリとなり、遅延時間は長く、テーブルのバージョン管理や監査ログなどの基本的な管理機能の利用はできません。
カスタムストレージエンジン
第二のアプローチはカスタムストレージエンジンです。Snowflake データウェアハウスのようなクラウド向けにカスタム構築されたシステムなどを指 します。これらのシステムは、単一のデータソースを提供する、一貫性のある独立したサービスでメタデータを管理することで、データレイクの一貫性に欠ける問題を回避できます。しかし、全 I/O 操作がこのメタデータサービスに接続する必要があるため、クラウドリソースのコストが増大し、性能と可用性が低下するというマイナス面があります。また、Apache Spark、TensorFlow、PyTorch などの既存のコンピューティングエンジンにコネクタを実装するには多くのエンジニアリング工数が必要になります。これは、データの処理や分析にさまざまなコンピューティングエンジンを使用するデータチームにとっての負担となります。これらのシステムは通常、従来の構造化データに最適化されているため、非構造化データによってエンジニアリングの課題が複雑化するというリスクもあります。さらに、独自のメタデータサービスがユーザーを特定のサービスプロバイダに固定する、すなわち、ユーザーが新たな手法を導入しようとすると、そのための「移行作業」に多大なコストと工数を要するという問題があります。
レイクハウス
第三のアプローチはレイクハウスです。私たちは、クラウドオブジェクトストア上のオープンソースの ACID テーブルストレージレイヤーである Delta Lake を利用した斬新な高速化を追求しました。データストアの改善に留まらず、レイクハウスを介したデータの保存・利用法を根本的に変えようと考えたのです。データレイクの限界に挑む新しいシステムとして登場したレイクハウスは、データレイクとデータウェアハウスの優れた要素を取り入れた新しいパラダイムです。新 たなシステムデザインによって構築されており、データウェアハウスと類似のデータ構造とデータ管理機能を、データレイクに使用される低コストのストレージに直接実装しています。データレイクハウスは、安価で信頼性の高いストレージ（オブジェクトストア形式）が利用可能になった今、最新のニーズに対応するデータウェアハウス構築のための最善策と言えるでしょう。
Delta Lake は、Parquet 形式に圧縮されたログ先行書き込みを用いて、どのオブジェクトが Delta テーブルの一部であるかという情報を ACID 方式で保持し、同時にクラウドのオブジェクトストアにも格納します。この設計により、複数オブジェクトの一括更新、オブジェクトの一部の置き換えを、直列化可能な方法で実行できます。オブジェクトからの読み取り・書き込みの高度な並列化は依然として可能です。また、ログは、大規模な表形式のデータセットのメタデータ操作を大幅に高速化します。さらに、Delta Lake は、タイムトラベル（ポイントインタイムのスナップショットのクエリ、更新のロールバック）、自動データレイアウトの最適化、アップサート、キャッシュ、監査ログなどの高度な機能も提供します。これらの機能の相乗効果により、クラウドオブジェクトストアでデータを扱う際の管理性と性能の両方が向上し、最終的には、データウェアハウスとデータレイクの主要なケイパビリティを併せ持つ、よりシンプルで優れたデータアーキテクチャを構築するレイクハウスのパラダイムへの扉が開くことになります。
現在、Delta Lake は、数千社に およぶ Databricks のお客様とオープンソースコミュニティの多くの組織に使用されており、さまざまなデータソースやアプリケーションが関わる多様なユースケースにおいて、エクサバイト規模の構造化・非構造化データを日々処理しています。保存されるデータタイプには、エンタープライズ OLTP システムからの変更データキャプチャ（CDC）ログ、アプリケーションログ、時系列データ、グラフ、レポート用の集約テーブル、機械学習用の画像・特徴量データなどがあります。アプリケーションは、最も一般的な SQL ワークロードから、BI、ストリーミング、データサイエンス、機械学習、グラフ分析まで多岐にわたります。Delta Lake は、Parquet や ORC のような構造化ストレージ形式を使用していた多くのデータレイクアプリケーションや、従来型データウェアハウスのワークロードに適していることが実証されています。
これらのユースケースを見ると、お客様は、Delta Lake を活用してワークロードをクラウドオブジェクトストアに対して直接実行することで、データアーキテクチャを極めてシンプルなものにしていることがわかります。また、データレイクとトランザクション機能を備えたレイクハウスを構築して、メッセージキュー（Apache Kafka など）、データレイク、クラウドデータウェアハウス（Snowflake、Amazon Redshift など）による機能の一部または全部を置き換えるというケースもあり、この手法は増加傾向にあるようです。
リサーチペーパーでは次の事柄を中心に解説しています。
- オブジェクトストアの特徴と課題
- Delta Lake の保存形式とアクセスプロトコル
- Delta Lake の現在の機能、メリット、制限
- 現在一般的に導入されているコアなユースケースと特殊なユースケース
- TPC-DS 性能を含む性能実験
このリサーチペーパーは、Delta Lake の理解を深め、低コストのクラウドストレージに保持されたデータに対して Delta Lake が DBMS のような幅広い性能と管理機能をどのようにして実現しているかを理解していただくのに役立ちます。Delta Lake のストレージ形式とアクセスプロトコルによる容易な運用、高可用性、オブジェクトストアへの高帯域幅アクセスについても解説しています。
