はじめに

#

先日オープンテーブルフォーマットについて調べてみました。 今日は、オープンテーブルフォーマットの相互運用についての記事を読んでみます。

最初にチャッピーにまとめてもらった表を書いておきます。

UniformのHudi対応はpreview版だったりもするので、これまでdelta lakeを使っていた場合はUniformを、そうでない場合はXTableを選べば良い気がします。もちろんパフォーマンスとうとう差異があり、選択時は精査が必要ですが、今はそこまでわかりません 🙌(お手上げ)

では以下の記事を翻訳していきます。

Delta Lake Universal Format（UniForm）とApache XTableによるオープンテーブルフォーマットの統一

#

Delta Lake Universal Format(UniForm)とApache XTable™（Incubating）は、テーブルフォーマットに依存しないオープンデータレイクハウスを構築できることを証明してきました。

これらはいずれも完全にオープンソースのツールで、ユーザーはデータを1つだけ書き込み、それを下流のあらゆるエンジンから利用可能にできます。

クライアントはUniFormをDelta LakeやApache Icebergとして読み取れるほか、XTableとの連携によりApache Hudiとしても読み取れるようになりました。

このユニバーサルなサポートにより、3つのオープンテーブルフォーマットのエコシステム間でシームレスに相互運用でき、ETL、機械学習、BI、分析ワークロードに最適なツールを自由に選択できる柔軟性を得られます。

本ブログでは以下について解説します：

• ユーザーが相互運用を選ぶ理由
• UniFormとXTableで構築するフォーマット非依存のレイクハウス
• Delta LakeコミュニティとXTableコミュニティの連携方法

３つのオープンなエコシステムを解放する

#

企業はオープンデータレイクハウスアーキテクチャを完全に採用しています。MITテクノロジーレビューが経営層を対象に行った世界的な調査では、74%がレイクハウスアーキテクチャを採用していることがわかりました。Delta Lakeだけでも、本番環境で10,000社以上に利用されており、その中にはFortune 500企業の60%以上が含まれます。

組織がオープンテーブルフォーマットを選ぶ理由は、単一のデータコピーに対してあらゆるエンジンを利用できる自由があるためです。すべてのオープンテーブルフォーマットは、独自形式よりも高い柔軟性を提供しますが、レイクハウスのエコシステムは分断されています。複数のエコシステムにまたがるアーキテクチャを持つ組織にとって、単一のフォーマットを選択するのは現実的でない場合が多いのです。

UniFormとXTableは、特定のエコシステムに縛られないアーキテクチャ構築を支援するために積極的に連携しています。これらのツールは、Delta Lake、Iceberg、HudiがすべてApache Parquetデータファイル上に構築されたメタデータレイヤーで構成されているという事実を活用しています。

MicrosoftとGoogleの支援を受けるXTableは、データファイルを単一コピーのまま維持しつつ、ソースフォーマットとターゲットフォーマット間でメタデータを変換します。共通の目標を背景に、XTableメンバーはDelta LakeリポジトリにHudiサポートを追加するPRをマージしました。

オープンソースコミュニティ間の協力により、Delta Lakeテーブルは3つのエコシステムすべてでクライアントから読み取れるようになりました。次のセクションでは、UniFormとXTableを用いた組織での一般的なユースケースを紹介します。

Delta Lake UniFormとXTableによるレイクハウス

#

Delta 3.0でのリリース以来、UniFormは人気のあるIcebergリーダークライアントとの互換性を証明してきました。一般的なUniFormのユースケースとしては、ETLにDatabricksを使用し、下流でSnowflakeに接続してBIや分析ワークロードを実行する方法があります。

これまでは、Databricksが書き出したDelta LakeテーブルをSnowflakeの内部形式に複製する必要がありました。しかしUniFormを使えば、SnowflakeでDeltaをIcebergとして読み取ることができます。

まず、次のテーブルプロパティを設定して、Delta LakeテーブルでIcebergサポートを有効にします。

UniFormを有効にすると、Delta Lakeテーブルへの書き込み時に、Parquetファイルと同じ場所にあるDeltaLogと並行してIcebergメタデータが自動生成されます。Snowflakeでは、Icebergカタログ統合を使用してUniFormを読み取ることができます。

XTableは、昨年12月のApacheインキュベーション入り以来、GitHubスター数700以上を獲得し、Microsoft、Google、Onehouse、Databricks、Snowflake、Walmart、Dremio、Adobe、Clouderaなど、著名なコントリビューター、メンター、ユーザーを惹きつけています。

Apache XTableを使えば、あらゆるフォーマットから書き込み、別のフォーマットへ双方向に変換できます。Delta Lake、Iceberg、Hudiのいずれを主要フォーマットとして選んでも、それらすべてをシームレスに相互運用できます。

XTableコミュニティでよくあるユースケースとして、Apache Hudiのレコードレベルインデックスによる低レイテンシ書き込みを選びつつ、IcebergのみをサポートするSnowflakeで読み取りたいというものがあります。

内部的には、Apache XTableはDelta Lake UniFormと同様に軽量な増分メタデータ変換を行います。実際のデータファイルは読み取りも書き換えも行わず、メタデータのみを扱います。また、XTableは柔軟なデプロイや運用を可能にするポータブルなランタイムを提供します。詳細な手順はドキュメントを参照できますが、要するに次の2ステップで簡単に実行できます。

1. sourceフォーマットとtargetフォーマット、およびテーブルのファイルロケーションを指定したconfig.yamlファイルを作成します。

2. JARコマンドを実行して変換を実行します。

   

変換を実行する方法のアイデア例：

1. 各コミット後に、Sparkの書き込み処理からXTableを実行するよう設定する
2. Airflowなどを用いて、一定間隔で非同期にXTableをスケジュール実行する
3. Lambdaなどのサービスをデプロイし、オンデマンドでXTableの変換を起動する

Apache XTableの内部アーキテクチャの詳細は、GitHubのREADMEを参照してください。以下は主要コンポーネントを要約した図です。

ストレージ戦争ではなく、オープン性を選ぼう

#

オープンなレイクハウスプロジェクトは複数の競合がありますが、データコミュニティ全体を支えるために協力し合うことが重要です。より多くの組織がレイクハウスアーキテクチャを採用する中で、Delta Lake、Apache Hudi、Apache Icebergの各コミュニティは、それぞれ固有のニーズや好みに応じて成長し、ユーザーやコントリビューターを引きつけ続けるでしょう。

複数のテーブルフォーマットを利用するニーズが高まる中、相互運用性の橋を築くことが重要です。これにより、開発者コミュニティ全体において分断がイノベーションを阻害することを防げます。

私たちのチームは、コードを共有することの強みを認識しており、プロジェクト同士が相互運用性を支え合うべきだと考えています。ぜひ、Delta LakeとXTableのコミュニティに参加し、貢献してください。

さいごに

#

XTable、あるいは Uniformを使って、複数のオープンテーブルフォーマットの相互運用性高められることがわかりました。既に利用しているオープンテーブルフォーマットがなければXTableを使ってみるのが良い気がします。

使ってみないとその効果は実感できないですが、こういうのってなかなか体感できる機会も貴重ですよね。チャンス来い！