Subsurface 2024 のセッション「Beyond Tables: What's Next for Apache Iceberg in Data Architecture」を日本語でまとめます。 可能な限り正確に内容を拾えるようにリスニングに努めたつもりですが、もし誤りがあればご指摘ください。
Subsurface とは？
イベント概要
Subsurface とは、Dremio社が主催するデータアーキテクトやデータエンジニア向けのOSSによるデータレイクに関する技術カンファレンスで、Apache Icebergなどのビッグデータに関わる60以上のセッションを学べます。
以下、公式の紹介文を翻訳したものです。
Subsurface LIVEは、業界屈指のクラウドデータレイクハウスカンファレンスであり、今日のクラウドデータレイクエコシステムを推進する最も刺激的で革新的なスピーカーやオープンソースプロジェクトが集結します。
これまでの開催では、世界中から18,000人以上のデータエンジニア、アーキテクト、科学者が集結しました。過去の講演者は、Apple, Netflix, Lyft, LinkedIn, TransUnion, Uber, Marsh McLennan, Adobe, AWS, Microsoft, Shell, Wayfairなどの大手テック企業から、SpiceAIやForcemetricsなどのスタートアップまで幅広く集まりました。さらに、Apache Arrow、Project Nessie、Apache Iceberg、Apache Parquet、Pandasなどのクリエイターによるセッションを開催する機会にも恵まれました。 https://sessionize.com/subsurface-live-2024
イベントページ
各セッションはイベントページから録画が視聴できるほか、Youtubeにもアップされる予定だそうです。
Beyond Tables: What's Next for Apache Iceberg in Data Architecture
セッション概要
日本語に訳すと「テーブルを超えて：データアーキテクチャにおけるApache Icebergの次なるステップ」という感じでしょうか。
Apache Icebergの産みの親の一人であり、Tabularの共同創設者兼CEOであるRyan Blue氏がApache Icebergの現状と将来について話し、特にテーブルフォーマットの枠を超えた進化について説明しました。
スピーカー
Ryan Blue
トピック
Apache Icebergの背景と目的
- IcebergはNetflixでデータレイクをデータウェアハウスと同じように扱えるようにしたい動機から開発された
- 当初、データレイクをデータウェアハウスのように動作させることを目指しており、これがApache Icebergの始まり
- 結果的に、複数のクエリエンジン（例えば、Pig、Hive、Spark、Trino）で共有可能なユニバーサルなテーブルフォーマットになった。これは当初の予想を超える大きな成果だった
- 更に、タイムトラベルやBranching and Taggingなどの応用的な機能も実現した
静かなる革命
- 今日、データレイクだけでなく、SnowflakeやBigQuery、Redshiftなどのデータベース間でもIcebergを共有できるようになってきている
- これまでのデータベースは、ストレージとの緊密な統合と制御を前提に設計されてきた。Icebergのような汎用的な分析用テーブルフォーマットの登場により、複数のデータベースエンジンが同じストレージ上のデータを安全に共有できるようになりつつある
- これは前例のない大変革。MySQLとPostgresが基盤となるテーブルを共有できないのに対し、分析データベースの世界ではそれが可能になってきている
集中型と専門化アーキテクチャの再編
- 分析データベースの設計において、コンポーネントごとに集中型と専門特化型のアーキテクチャの再編が進んでいる
- 集中型の要素
- テーブルとデータ自体は集中管理し、複数のエンジン間でデータをコピーする必要がなくなる
- カタログ、ビュー、アクセス制御、ガバナンスポリシーなども集中管理する
- 専門特化型
- ストリーミングやバッチ処理など、用途に特化したコンピュートエンジン
- グラフデータベースのような特殊な処理。PuppyGraphなど
- 専門的なカテゴリに何が入るのか、集中化されたカテゴリに何が入るのかを見極めることが、今後数年間の注目ポイント
モジュラーアーキテクチャの発展
- データとコンピュートを分離し、データを中心に据えつつ、様々な専門的なエンジンを組み合わせて使えるモジュール型のアーキテクチャへの変化
- データがどこに置かれても、使用するコンピュートエンジンを決定しないという革命的な変化が起こっている
- これらの前提として、集中化されたストレージコンポーネントの中立性が重要である
- 特化型の計算リソースをあらゆるストレージレイヤにプラグインできるようにするには、いくつかの要素が重要になる
- RESTカタログ、View、認証、エンジン間で共有可能な権限管理など
RESTカタログの進化
- Iceberg プロジェクト開始当初は、Hive、Glue、独自のメタデータカタログなど、さまざまなカタログが存在していた。Netflixは自社独自のカタログであるmetacatを開発
- Icebergが成熟するにつれて、よりプラガブルにエンジンが接続できるようにするための共通言語が必要になった
- そこで、RESTプロトコル標準が策定された
- RESTカタログはIcebergテーブルの操作を標準化するだけでなく、アクセスコントロールやサーバサイドでの実行計画など、発展的な機能の実現にも繋がっている
※注 Iceberg Catalogの概要と、Iceberg REST Catalogの重要性については、僕のこちらのスライドでもご紹介しています
Viewの進化への展望
- Viewは技術的には必須ではないが、View定義をコピーして持ち運ぶよりも、共有できた方が遥かに便利
- つまり、カタログとその下位層を共有する世界においては、Viewも共有する必要がある
- Viewの共有には段階がある
- Step 1: エンジン間での共通定義
- 同じ定義をエンジン間で共通的に使えるようにする。これには限界があり、内部結合や特定の結合を扱うと、すぐに限界が来る
- Step 2: SQL方言ごとのView
- テーブルに対してSQL方言ごとの定義を持てるようにする。同じ機能を様々な方言で定義しておくことで、ビューの互換性を確保できる
- 現在のIceberg Spec, Iceberg 1.5が到達している段階
注：IcebergのView仕様については紹介記事を書きました https://bering.hatenadiary.com/entry/2024/03/31/150946
- Step 3: 中間表現
- 方言間の翻訳を担う中間的な表現によって、計算エンジン間で方言の自動変換を実現する
- これによって、エンジン間でビューを完全に共有できるようになる
- 近いことを実現しつつあるプロジェクトとしてCoralやSubstraitがある
- Future: Materialized View
- 必ずしもIcebergがMaterialized Viewを生成するというわけではなく、各エンジンのMaterialized Viewのメタデータを追跡する方法や、その新鮮さ、Materialized Viewを使うべきかViewを実行するべきかを判断する基準などを定義しようとしている
注：IcebergのMaterialized ViewのProposalはこちら
- Viewにより、Icebergの設計パターンが広がる。例えばCDCでは、ミラーテーブルを常に最新に保つ必要がなくなり、一定期間の変更を溜め込んでおき、読み取り時に最新の変更をマージするような仕組みが実現できる
アクセスコントロールとガバナンス
- 認証認可、ガバナンスの強化にも取り組んでいる
- すべてのエンジン間で同じIDを使い、統合的に認証認可できるようにする必要がある
- ポリシーは集中管理され、同時に有効化される必要がある
- Icebergがこれらを直接実装するわけではないが、標準化のファシリテーションとその推奨を行っている
テーブルの暗号化
- 必ずしも集中化とは関係ないが、Icebergコミュニティが単なるテーブル管理を超えた領域に踏み込んでいることを示す良い例
- 多くのユースケースで、データの暗号化が必要になる
- そこでIceberg Specに、標準的な暗号化とメタデータ暗号化を組み込んだ
