1つの書き込みパス、複数のエントリ：RipplingがUnity Catalog管理のApache Iceberg™をどのように活用しているか

これは、Ripplingのデータプラットフォーム担当スタッフエンジニアであるTae Lee氏によるゲスト投稿です。

Ripplingでは、テーブルに書き込みを行うエンジンと、それを読み取るエンジンが常に同じであるとは限りません。Databricksのジョブがテーブルを作成し、下流のコンシューマーがRippling Data CloudのTrinoベースのクエリレイヤーやSnowflake、あるいは他のレイクハウスリーダーである場合もあります。そのため、カタログの選定は単なるメタデータの詳細にとどまらず、誰がテーブルに書き込めるか、誰がそれをメンテナンスするか、そして他のエンジンがそれをどのように読み取るかを決定する重要な要素となります。

つまり、すべてのワークロードを1つのエンジンや1つのカタログに強制的に押し込めることがゴールではありません。ゴールは、各プロデューサーが最も効率的に動作するプラットフォームを使用できるようにしつつ、下流のシステムが重複なく利用できるガバナンスの効いたテーブルを公開することです。

Unity Catalogで管理されたIcebergテーブルは、このアーキテクチャにおいてDatabricksが生成する部分に採用しているパターンです。

カタログの所有権はライターに従う

私たちのカタログ戦略は、「カタログはライターに従うべきである」というシンプルなルールから始まります。

AWSネイティブのコンピューティングには、AWS Glue Data Catalogを使用しています。これは、Glue、Athena、EMR、または関連するインフラストラクチャなどのAWSエンジンによって書き込まれるワークロードに自然に適合します。

Databricksで生成されるワークロードには、Unity Catalogを使用します。これは、Apache Iceberg™において特に重要です。Databricksはフェデレーションを介して外部のIcebergテーブルを読み取ることができますが、それらのテーブルはUnity Catalogで管理されたIcebergテーブルと同じではありません。Databricksがテーブルに書き込む必要がある場合、またはワークロードがDatabricksのパフォーマンスとガバナンスに大きく依存している場合は、テーブルをUC管理にする必要があります。

プラットフォーム間で共有する必要があるSnowflake生成のデータには、Snowflakeが管理するIcebergテーブルとともにSnowflake Horizon Catalogを使用します。これは、プロデューサーとしてのSnowflakeによって主導される、独立したカタログの決定です。

ここで重要な違いがあります。Icebergはオープンなテーブルフォーマットを提供しますが、メタデータのコミット、権限、およびテーブルのライフサイクルを所有するのは依然としてカタログです。フォーマットのポータビリティとカタログの所有権は関連していますが、同じものではありません。

なぜDatabricksのワークロードに管理されたIcebergを使用するのか

このパターンを導入する前は、Databricksで生成された出力を他の場所で利用するには、通常、追加のハンドオフ（引き渡し）が必要でした。つまり、Databricksでの書き込み後にもう1つのコピーをエクスポートするか、利用側のシステムに直接書き込んで、Databricksが再び必要としたときにコネクタやフェデレーションパスを介して読み戻すかです。どちらのアプローチも機能しますが、データの重複した実体化（マテリアライズ）、余分なコンピューティング、およびコネクタ固有の制限が発生します。 

Unity Catalogで管理されたIcebergは、より明確な境界線を提供します。

Databricksはテーブルをネイティブに書き込みます。Unity Catalogがテーブルのメタデータ、アクセスモデル、およびライフサイクルを所有します。テーブルデータとIcebergのメタデータは、Ripplingが所有するS3ストレージに保存されます。 

外部エンジンは、Iceberg REST Catalog APIまたはカタログフェデレーションを介して接続します。認証情報の自動払い出し（Credential vending）により、これらのエンジンに基盤となるストレージへのスコープ限定アクセス権が付与されます。その後、エンジンは独自のコンピューティングを使用して、S3からParquetファイルを直接読み取ります。 

これが私たちにとって重要な特性です。Databricksのジョブがテーブルを一度作成すれば、Trino、Snowflake、Spark、Athena、EMRなどの下流のエンジンが、標準的なIcebergのアクセスパターンを介して同じテーブルを利用できます。コンシューマーは、すべてのクエリを別のエンジンのSQLダイアレクトや実行レイヤーを介してプロキシする必要がないため、エンジン間の変換、プッシュダウン動作、スロットリング、および下流の読み取り用のプロデューサー側コンピューティングへの依存を減らすことができます。 

これはDatabricksからのエクスポートではありません。Databricksネイティブのプロデューサーを持つ、オープンなIcebergテーブルです。

ML出力からData Cloudへ

このパターンは、Databricksで生成された出力が、より広範な製品や分析領域の一部となる必要がある場合に最も役立ちます。

Ripplingでは、MLおよびAIのワークロードは、依然としてユースケースに適したターゲット（Deltaテーブル、ベクトルデータベース、OpenSearch、またはその他の専用の宛先）を選択します。管理されたIcebergは、選択された公開パターンの1つであり、すべてのML出力のデフォルトのターゲットではありません。

管理されたIcebergが重要になるのは、ハンドオフ（引き渡し）の段階です。選択された出力について、DatabricksのジョブはUnity Catalogで管理されたIcebergテーブルを一度公開するだけで済みます。その後、Rippling Data Cloudは、Trinoベースのアクセスパターンを含むクエリレイヤーを介してその同じテーブルを利用し、下流の変換、ダッシュボード、およびAI駆動の製品機能で使用できます。

アーキテクチャは次のようになります。

これにより、1つのガバナンスの効いたテーブルと1つの書き込みパスが実現します。下流のコンシューマーは物理的なコピーを重複して持つ必要がなく、Lakeflow Jobsは利用するすべてのシステムに個別に書き込む必要がありません。

運用はオープン性と同じくらい重要

Glueでカタログ化されたIcebergテーブルの場合、そのメンテナンスはAWSネイティブのプラットフォームパスに属します。Glueにはテーブル最適化機能がありますが、それは依然として別の運用モデルです。それらの機能をどこで有効にするか、どのように監視するか、そしてGlueを使用するワークロードの動作をどのように検証するかを決定する必要があります。

Unity Catalogで管理されたIcebergの場合、DatabricksはPredictive Optimization（予測最適化）を通じて、自動テーブルメンテナンス、ファイルの最適化とコンパクション、統計情報の収集、管理テーブルのデータレイアウトの最適化など、そのライフサイクルの多くを処理します。テーブルを書き込むのと同じプラットフォームが、パフォーマンスを維持するために必要なクレンジング（衛生管理）の多くも管理するため、これは非常に便利です。

これが、私たちがUC管理のIcebergを単なる相互運用性機能として捉えていない理由の1つです。これは運用モデルでもあります。Databricksで生成されたテーブルの場合、メンテナンスパスは読み取りパスと同じくらい重要です。

ロックインについて正確に理解する

このアーキテクチャはデータのロックインを軽減しますが、すべての依存関係を排除するわけではありません。

データのロックインは低レベルです。テーブルは、Ripplingが所有するS3ストレージ内のParquet上のIcebergです。

下流のエンジンは、オープンなIcebergパターンを介してデータを直接読み取ることができます。

カタログとガバナンスの依存関係は現実に存在します。Unity Catalogは、メタデータ、権限、リネージ、および管理テーブルの動作のコントロールプレーンであり続けます。仮に私たちがDatabricksから移行したとしても、データはポータブルですが、カタログとメンテナンスシステムを置き換える必要があります。

これは、このクラスのテーブルにとって許容できるトレードオフです。Databricksがプロデューサーであり、テーブルがガバナンスされ、メンテナンスされ、他のエンジンから読み取り可能である必要がある場合、UCはその真価を発揮します。

実質的な成果

Unity Catalogで管理されたIcebergの価値は、すべてのテーブルに対して1つのカタログを提供することではありません。実際にはそうではありませんし、それが私たちのゴールでもありません。

その価値は、オープンな下流での利用を必要とするDatabricks生成テーブルに対して、1つの書き込みパスを提供することにあります。Databricksはネイティブな書き込みおよび最適化パスを利用できます。下流のシステムは、S3内のオープンデータに直接アクセスできます。 

RESTカタログを介してテーブルにアクセスするエンジンは、生のストレージパスを介してガバナンスをバイパスするのではなく、同じメタデータおよびアクセスレイヤーを経由します。これが実質的な成果です：

「Unity Catalogと管理されたIcebergは、私たちのAIおよびMLパイプライン向けのネイティブなパフォーマンスと、すべての下流コンシューマー向けのオープンな相互運用性という、両方の長所を提供してくれます。1つの書き込みパス、重複ゼロ、そしてRipplingのData Cloud向けに構築しているAI駆動製品を含む、すべてのエンジンが尊重するガバナンスレイヤーが実現します。」

Ripplingにとって、相互運用性とはすべてのエンジンを互換可能にすることではありません。それは、公開されたテーブルのポータビリティ、ガバナンス、および必要なシステムでの利用可能性を維持しながら、各エンジンに得意な仕事をさせることです。

To learn more about Unity Catalog and Icebergのサポートについて詳しくは、Unity Catalogの 製品ページをご覧ください。 

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事