オープンレイクハウスの新時代：Databricks 上の Apache Iceberg™ v3 がパブリックプレビューに

本日、DatabricksによるIceberg v3のサポートがパブリックプレビューとして提供開始され、オープンレイクハウス上でIcebergコミュニティの最新イノベーションをネイティブに利用できるようになります。

Iceberg v3は、オープンテーブルフォーマットにとって大きな進歩であり、これまで複雑な回避策が必要だった増分データ処理や半構造化データ分析のユースケースを可能にします。さらに、Iceberg v3は、IcebergとDelta Lakeのデータレイヤーをさらに統合する重要な技術革新であり、相互運用可能なパイプラインを構築する際にデータの書き換えが不要になります。

ここでは、Iceberg v3の新機能、その重要性、そしてDatabricksがレイクハウスを実行するのに最適な理由を説明します。

Iceberg v3の新機能は？

Unity Catalogで管理されるIceberg v3テーブルは、Row Lineage、Deletion Vectors、VARIANTをサポートしており、新しいユースケースと大幅なパフォーマンス向上が可能になります。Databricksは、外部Icebergテーブル（他のカタログに登録されたIcebergテーブル）でもこれらの機能を相互運用できるため、顧客はデータの保存場所に関わらず、エージェントやAIアプリケーションをデータに対して構築できます。

大規模な増分処理：Row LineageとDeletion Vectors

ほとんどのデータは、バッチではなく変更のストリーム（INSERT、UPDATE、MERGE、DELETE）として到着します。通常、運用データベース、イベントストリーム、サードパーティAPIから取得されます。従来、これらの変更を処理するには、2つの困難な問題を解決する必要がありました。

1. ブロンズデータセットでどの行が変更されたかを特定する
2. それらの変更をシルバー/ゴールドデータセットに効率的に適用する

通常、チームはフルテーブルスキャンや外部CDCシステムを使用して変更を検出し、高コストなファイル書き換えでそれらを適用していました。その結果、パイプラインは遅く、保守コストが高く、ドリフトやデータサイロが発生しやすくなっていました。

現在、Row Lineageにより、チームは変更された行を迅速に特定できます。Iceberg v3テーブルの各行には、永続的なrow IDと、行が最後に変更された時期を反映するシーケンス番号が付与されます。

さらに、Deletion Vectorsにより、データセットへの変更の適用がこれまで以上に高速になります。Deletion Vectorsは、Icebergが基盤となるデータファイルをすぐに書き換えることなく、論理的に削除された行を追跡できるようにします。大きなParquetファイルを書き換えて行を物理的に削除する代わりに、エンジンはデータとともに軽量な削除ファイルを作成します。これにより、データ操作のパフォーマンスは、従来のコピーオンライトアプローチよりも最大10倍高速になります。

Deletion VectorsがIcebergでネイティブになったことで、Geodisはパフォーマンスやエンジンの選択を犠牲にすることなく、Databricks上でIcebergレイクハウスを構築できます。

「Deletion VectorsがIcebergで利用可能になったことで、Unity CatalogでIcebergデータエステートを集中管理し、選択したエンジンを活用しながら、クラス最高のパフォーマンスを維持できます。」 — Delio Amato、Chief Architect & Data Officer、Geodis

Row LineageとDeletion Vectorsを組み合わせることで、CDC（変更データキャプチャ）がテーブル自体のネイティブなプロパティになります。チームは、実際に変更されたものだけを増分処理することに焦点を当てたパイプラインを構築でき、コストを削減し、すべてのダウンストリームのアナリストやデータサイエンティストのインサイト獲得までの時間を短縮できます。

VARIANTによる半構造化データのファーストクラス市民化

ログ、APIレスポンス、クリックストリーム、IoTペイロードは非常に価値のある半構造化データソースです。これらが進化するにつれて、AIモデルはそれらと共に適応し、変化する実世界のシグナルから直接学習できます。

しかし、従来、データチームは半構造化データを扱う際に痛みを伴うトレードオフに直面していました。1つの標準的なアプローチは、厳格なスキーマを強制することでしたが、これはアップストリームデータが進化するたびに壊れる壊れやすいパイプラインにつながりました。もう1つの一般的な回避策は、データを生の文字列ダンプとして保存することでしたが、これによりクエリが非常に複雑で遅くなりました。どちらのアプローチもスケーラブルではありませんでした。

Iceberg v3のVARIANTタイプは、このトレードオフを解決します。VARIANTは、リレーショナルカラムと同じIcebergテーブル内に半構造化ペイロードを格納するネイティブカラムタイプです。これには、フラット化、別システムへの保存、正規化のためのETLパイプラインは必要ありません。むしろ、データチームは生の半構造化データをそのまま取り込み、標準SQLでクエリできます。

Pantherは、VARIANTを使用して、半構造化セキュリティログ全体にわたる大規模な取り込みと分析を強化しています。

「Unity CatalogとIceberg v3は、VARIANTを通じて半構造化データの力を解き放ちます。これにより、相互運用性とコスト効率の高いペタバイト規模のログ収集が可能になります。」 — Russell Leighton、Chief Architect、Panther

VARIANTを使用すると、AIモデルと分析パイプラインは、単一のガバナンスされたテーブル内のライブで進化するデータに対して直接機能します。APIレスポンスに新しいフィールドが出現したり、クリックストリームに新しいイベントタイプが入力されたりしても、スキーマ移行なしで即座にクエリできます。シュレッディングのようなパフォーマンス最適化により、顧客は半構造化データに対してカラムのようなパフォーマンスの恩恵を受けることができ、低レイテンシのBI、ダッシュボード、アラートパイプラインを可能にします。

Unity Catalogは、マルチエンジン、マルチカタログエンタープライズ向けの相互運用性とパフォーマンスを提供します

最新のエンタープライズは、ビジネスユニットやレガシーシステム全体にわたる多様なユースケースをサポートするために、複数のエンジンとカタログに依存しています。Unity Catalogは、カタログ間の相互運用性とガバナンスを可能にすると同時に、クエリパターンに基づいてデータレイアウトを最適化するように設計されました。

カタログとエンジンの間の統合されたガバナンス

Unity CatalogのオープンAPIにより、顧客は一度書き込めばどこでも読み取ることができます。データの重複やサイロ化されたアクセス制御はもう必要ありません。UCは他のIcebergカタログにフェデレーションでき、双方向の相互運用性を可能にします。Snowflake、AWS Glue、Salesforce、その他の主要なカタログにあるすべてのIcebergデータは、Unity Catalogによって読み取ることができ、UC内のすべてのデータは、オープンAPIを介してこれらのサードパーティプラットフォームによってアクセスできます。

さらに、Unity Catalogは、外部エンジンに対するきめ細かなアクセス制御をサポートする最初のカタログであり、チームは行フィルターとカラムマスクを一度定義し、データがアクセスされるすべての場所でそれらが強制されるようにすることができます。Unity Catalogでのガバナンスを一元化することで、セキュリティチームはレイクハウスをガバナンスおよび監視することが大幅に容易になり、データチームは任意のツールをレイクハウスに向けられる自律性を得られます。

DeltaとIcebergの相互運用性

UniFormを備えたDelta Lakeは、顧客のDelta LakeおよびIcebergエコシステム間の相互運用性を解き放ちます。Delta Lakeに一度書き込むと、Snowflake、BigQuery、Redshift、Athena、Trino、またはその他のIcebergエンジンからIcebergとして読み取ることができます。Iceberg v3がDeletion Vectors、Row Lineage、VARIANTをネイティブに採用したことで、顧客はDelta Lakeのパフォーマンス機能とIcebergの互換性の間のトレードオフに直面する必要がなくなりました。その結果、スタック内のすべてのエンジンに対応する単一のデータコピーが得られ、保守するレプリケーションパイプラインやドリフトのリスクはありません。大手金融サービスプロバイダーは、コストのかかるフルテーブルレプリケーションサービスをUniFormに置き換え、SnowflakeがUnity Catalog管理テーブルから直接読み取れるようにしました。

自動化されたパフォーマンスと最適化

Databricksは、相互運用性に加え、パフォーマンス、レイアウト最適化、ガバナンスを単一のシステムに統合するため、チームがこれらの機能を自分で連携させる必要がありません。Databricksは、インテリジェントなメンテナンス（Predictive Optimization）、クエリパターンに基づく物理レイアウト最適化（Automatic Liquid Clustering）、およびクロスエンジンガバナンス（Unity Catalog）を1つのレイヤーに統合しており、手動構成は一切不要です。

他のマネージドIcebergオファリングでは、テーブルメンテナンス、ファイルレイアウト、アクセスポリシーの強制をチームが個別に管理する必要があります。Databricksでは、これらの機能は統合され自動化されているため、運用オーバーヘッドのクラス全体が削除されると同時に、完全なデータポータビリティも維持されます。

DatabricksでApache Iceberg v3を開始する

Iceberg v3は、本日Databricksでパブリックプレビュー中です！チームは、パフォーマンスと相互運用性のどちらかを犠牲にすることなく、DeltaとIcebergの最適な機能を活用できるようになりました。

Iceberg v3は、Unity Catalogが有効なDatabricks Runtime 18.0+で利用可能です。

v3が有効なUnity CatalogマネージドIcebergテーブルの作成は簡単です。

UniFormとv3が有効なUnity CatalogマネージドDeltaテーブルの作成も同様に簡単です。

今後の展望: Iceberg v4

Iceberg v3は、パフォーマンスと相互運用性に優れた基盤上でDeltaとIcebergのデータレイヤーを統合します。次のフロンティアはメタデータレイヤーです。Databricksのエンジニアは、メタデータをよりシンプル、高速、スケーラブルにするために、ApacheコミュニティでいくつかのコアIceberg v4提案を積極的に推進しています。これらには、メタデータ構造を簡素化し、ほとんどの操作で複数のファイルではなく単一のファイルを書き込むだけで済むようにするadaptive metadata treeが含まれます。追加の提案には、環境間でのシームレスなテーブル移動のためのrelative path support、およびVARIANTやGEOMETRYのような新しいデータ型に拡張されるmodernized statistics modelが含まれます。これらの進歩は together、エンタープライズスケールでの高速な取り込み、より効率的なクエリ計画、およびシンプルなテーブル管理を意味します。コミュニティと共にIceberg仕様を進化させていくことを楽しみにしています。

Data and AI Summitでさらに学ぶ

Iceberg v3を開始し、6月15日から18日までサンフランシスコで開催される次回のData and AI Summitにご参加ください。そこで、当社のIcebergロードマップとエコシステム全体での取り組みについて詳しく学べます。

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