Subsurface 2024「Apache Icebergの未来とエコシステムの展望」パネルディスカッションまとめ

Subsurface 2024 のパネルディスカッション「Keynote Panel: Looking Forward-Apache Iceberg and the Iceberg Ecosystem」を日本語でまとめます。
可能な限り正確に内容を拾えるようにリスニングに努めたつもりですが、もし誤りがあればご指摘ください。

Subsurface とは？
- イベント概要
- イベントページ
Keynote Panel: Looking Forward-Apache Iceberg and the Iceberg Ecosystem

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

イベントページ

www.dremio.com

各セッションはイベントページから録画が視聴できるほか、Youtubeにもアップされる予定だそうです。

Keynote Panel: Looking Forward-Apache Iceberg and the Iceberg Ecosystem

セッション概要

日本語に訳すと「キーノートパネル - Apache Icebergの未来とエコシステムの展望」という感じでしょうか。
本パネルディスカッションでは、Icebergコミュニティと関連プロジェクトの専門家が集まり、Icebergの進化と今後の方向性について議論しました。
DremioのDeveloper AdvocateでモデレータのAlexから各参加者に問いが投げかけられ、各参加者が順番に答えていく形式です。

スピーカー

Alex Merced
- Developer Advocate @ Dremio
- パネルディスカッションのモデレータを担当
Robert Stupp
- Senior Staff Software Engineer @ Dremio
- NessieやIcebergなど、様々なOSSの開発に携わる
Daniel Weeks
- Co-creator of Apache Iceberg @ Tabular
- Apache Icebergの産みの親の一人
- Tabular社のCTOでもある
Casey Karst
- Principal Product Manager @ Dremio
- Microsoft, Splunk, RelationalAIを経てDremioへ
- MicrosoftではAzure SQL DB、SQL Server 2019、MSFT Analytics Platform Service、Azure SQL DW、Azure Synapseなどに関わる
Paul Meighan
- Product Management @ Amazon
- Amazon S3のプロダクトマネージャ

Q1.「あなたが最も楽しみにしているApache Icebergの新機能は何ですか？」

Robert Stupp「REST Catalog」

NessieもIceberg REST APIを実装中。近日ベータ版を公開予定

Paul Meighan「REST Catalog」

大きな顧客は皆RESTカタログの導入を検討している
RESTカタログは誰にとっても有用な抽象レイヤであり、ブレイクスルーだと思う

ここでRESTカタログの紹介を求められたDanielは、以下のように説明していました。

私がRESTカタログについて話す際の比喩としては、Icebergのテーブル仕様との比較で説明するのが良いと思います。テーブル仕様は、データをどのように配置するか、どのように進化させるかを定義するものです。一方、RESTカタログは、そのデータにどのようにアクセスするかに重点を置いています。

つまり、RESTカタログは、データにどのようにアドレス指定するか、どのようにアクセスするかについて、誰もが共有できる仕様なのです。

そして、カタログは最もシンプルなレベルでは次のようなものです。例えば、あなたが見ている "geo country" という論理名があるとします。そして、実際の基礎となるIcebergのデータがどこにあるのかを特定するにはどうすればよいのでしょうか。それを提供するのがRESTカタログなのです。

※注 Iceberg Catalogの概要と、Iceberg REST Catalogの重要性については、僕のこちらのスライドでもご紹介しています

speakerdeck.com

Daniel Weeks「Iceberg Table Spec v3(Icebergの新バージョンのTable仕様)」

Iceberg Table Spec v3策定に向け、アイデアを集めている
- 例えば、スキーマの自動昇格(Type Promotoin)。Icebergはスキーマ進化とその正確性について厳格であるため、一部のユースケースでは運用の手間になっており、Type Promotionの導入を考えている
- 他の例として、バイナリや汎用的なJSON型のサポート。JSONのペイロードから直接値を保存、取得できる最適化した表現があれば便利なのではと検討している
- その他、Icebergテーブルの管理に関わるロケーションの所有権など

※注 Icebergテーブル仕様v3の関連issueはここに纏まっています

github.com

Casey Karst「Iceberg導入事例の増加とKafka Connect」

プロダクトマネージャーとして、Icebergを採用する顧客の増加に興奮している
より多くの顧客にIcebergの良さを知ってもらい、試してもらえるようにしていきたい
KafkaからIcebergへの書き込みを望む声をよく見るので、TabularとDramioによって作られたIcebergのKafka Connectは非常に価値があると思う

github.com

※注 Kafka ConnectのIcebergコネクタについては、yassanが素晴らしい記事を書いています

developers.microad.co.jp

Q2.「Apache Icebergに関連する他のプロジェクトで今後が楽しみなものは？」

Robert Stupp「Nessie、特にレスポンスタイムの改善」

データレイクの読み取りと書き込みの性能改善に関わることに取り組んでいきたい
RDBMSの分野では1桁ミリ秒、時にはサブミリ秒のレスポンスタイムを実現するような最適化が行われているが、データレイクの世界でそれを実現するのはとても難しい
そういったことをNessieを中心に実現したいと考えている

Daniel Weeks「PyIcebergなどの幅広い言語サポート」

PyIceberg(IcebergクライアントのPython実装)はIcebergの採用を非常に拡大していくはず。従来のIceberg実装はSparkやTrinoなどの"重い"フレームワークに依存していて、セットアップが多く、使い始めるのに多くのことが必要だった
Pythonであれば非常に簡単に導入でき、従来のビッグデータエコシステムの一部ではない他のコミュニティ、例えば機械学習やデータサイエンスの分野にも広まっていくはず
他にもRustやGo実装も拡大してきており、エコシステムがどう発展していくかとても楽しみ
Icebergにアクセスできる人の層を広げていくことが本当に重要だと考えている

github.com

Casey Karst「ペルソナやワークフローを横断する共通インターフェース」

AIや機械学習を支える上で、同じデータセットに複数のペルソナが関わり、ペルソナやワークフロー全体でアクセスを民主化しながら、共通のインターフェースを持つことが重要
データレイクの抽象化レイヤは上へ上へと移動しており、それに従ってペルソナ視点での利用体験を磨けるフェーズに来ている
データアナリストは彼らが求める経験を得られ、データエンジニアは彼らが求める経験を得られ、そしてAIやMLの専門家は彼らが求める経験を得られるようになっていく
多言語サポートやRESTカタログを通じて、普遍的なインターフェースを保ちつつ、ペルソナごとに最適化された経験をどう提供するかに関心がある

Paul Meighan「Pythonによる参入障壁低下とストレージ最適化」

PyIcebergによって、今後はちょっとしたParquetを操作する小さな関数でもIcebergが現れるようになっていくはずで、非常に重要な変化と捉えている
小規模なIcebergテーブルを操作するアクセスパターンはストレージの目線でもユニークな性質を持っている。Icebergをより速く、より安価にするためにストレージをどのように最適化できるかについて顧客と対話しながら取り組んでいる

Q3.「Apache Icebergをさらに簡単に始められるようにするための最大の触媒は何だと思いますか？」

Robert Stupp「利便性、非機能、統制要件への対応」

複雑な設定が不要で、使い始めるのが簡単であることが最も重要。理想的にはブラウザを開けばすぐに使える状態であるべき
どのような使い方をしても、いつでもうまく動くことが重要。謎めいたエラーメッセージではなく、実用的なメッセージを出すべき。再現可能なクエリ、一貫性の強固な保証。より良いパフォーマンス、ダウンタイムがないことなど
その他、GDPRやCCPAなどの統制要件に対応することも非常に重視している

Daniel Weeks「データへのアクセシビリティ」

REST CatalogやPyIcebergなどを通じて、企業全体で適切な問題に適切なツールを持ち込めるようにしたい
データを扱うどのようなツールセットがあったとしても、それを諦めずに済むように、様々なエンジンがそれぞれの方法で簡単にIcebergを操作できるようにしていくことが、クラウドベースの環境における次世代のデータ処理の重要な点だと思う

Casey Karst「顧客による採用と価値の実現」

Icebergはアーリーアダプター向けの技術を徐々に抜け出しつつある
より多くのケーススタディをまとめ、パートナーのエコシステムを拡大し、成功事例の創出と新規の導入検討のフライホイールを回していかなければならない
Icebergを学習するための適切なラーニングパスを整備することも非常に重要。いきなり技術的な詳細に入り込むと迷子になってしまうので、段階を踏んで説明できるアセットを作っていくことが大事
Icebergの普及にはもう少し時間が必要だとは思うが、普及に向けて正しい軌道に乗っており、将来、採用が爆発的に進むのを見ることができると思う

Paul Meighan「エコシステムの拡大とエンタープライズの採用」

Icebergを取り巻くエコシステムが形成されることで、相互のネットワーク効果を通じて、より大きな価値が産まれていく
エコシステムの拡大は、率直に言って、まだ初期段階だと思う。潜在的なIcebergのエコシステムには、はるかに多くの革新的なユースケースがあると確信している。
エンタープライズの採用には、セキュリティ、コンプライアンス、災害復旧など、新しい一連の要件が伴う。今後、これらの問題がコミュニティや顧客によって解決されていくのを目にすることになると思う
エンタープライズの採用曲線に向かう中で、別の一連のワークロードとユースケースは多様化していくだろう

Q4.「人々がデータをIcebergに取り込むのをサポートするために何ができそうですか？」

Robert Stupp「メタデータのさらなる活用」

Icebergカタログやメタデータをよりよく扱うことで、更に多くのことが実現できるはず
例えばparquetファイルを既存のテーブルに追加するといった一見簡単そうなユースケースでも、データが継続的に高速で入ってくるような場合は扱いが少し難しい場面がある
そういった困難を解決し、ユーザーを助けるためには、メタデータやデータカタログなどの仕組みが重要になってくる

Daniel Weeks「ストリームのサポートと移行ツールの拡大」

イベントパイプラインで大量のデータを収集しているような企業では、ストリームのサポートが重要になる
そのようなニーズを念頭にIceberg Kafka Connectに多額の投資を行い、実装を構築した。現在ではKafkaスタイルのパイプラインを使っている人はだれでも簡単にIcebergが使える
その他にも、データをicebergに取り込むためのあらゆる手段の拡張を重視している
もう一つ、Hiveテーブルなどのレガシー技術から移行する人々のためのツールが重要。レガシーフォーマットからIcebergへの移行を支援するプロシージャを提供しているが、将来的により多くのツールが必要になるだろう
長年Hadoopエコシステムで運用してきた大企業にとっては、テーブルフォーマットの選択や方向性の選択以上に、移行はもっと大きな、本当に難しい問題になる
移行を自動化したり、シームレスな移行を支援するための仕組みに取り組んでいく

Casey Karst「Pull型、Push型のデータ取り込み」

どのようなデータがどのようにデータレイクに届いても、データを理解し、Icebergとして取り込める世界観を目指している。それらはPull型とPush型に分けられる
Pull型のモデルとしては、Dremioの新機能であるAuto Ingestionを使うと、S3などのディレクトリにファイルが保存される度に、個別のパイプラインを必要とせず、ファイルを自動的に拾い上げて宛先のIcebergテーブルに書き込むことができる。データをIcebergに取り込むためだけに、これらのパイプをすべて構築し、維持する必要はない
Push型については、Kafka Connectによって直接書き込むことができる
これらによって、データの利用者にとってのインターフェースはIcebergのテーブルになる。これはここ、このファイルはそこ、他のものはどこというように考える必要がなくなり、本当に意味のある方法でクエリを実行し、対話することができる

Paul Meighan「S3をIcebergにとって最適な場所にすること」

ある意味で、S3の仕事は「邪魔にならないこと」
Icebergに必要とされるパフォーマンス、耐久性、セキュリティを提供することが非常に重要。それらはストレージの基本だが、大規模に実現するために実際には膨大な努力が必要になる
S3をIcebergを使う上で最適な場所にすることは、Icebergの成長に大きく貢献できることの一つだと思う

Robertへの質問「Nessieで進行中の興味深い変更について教えてください」

Robert Stupp「Nessieをよりスムーズに使えるようにすること」

人々があまり考えずに、問題に遭遇せずに作業を始められるようにするための様々な改善に取り組んでいる
ドキュメンテーションとガイドを強化し、人々がNessieを使い始められるようにする計画がある

Danielへの質問「データフォーマット間の相互運用性の問題に取り組むApache XTableやDelta Uniformをどう思う？」

Daniel「相互運用性は重要な課題。でもIceberg自体がそれを解決するかも」

IcebergやHudi, DeltaLakeを相互に使えるようにするテクノロジーが多数あると思う。ただ、ある意味、将来的にはicebergもインターチェンジフォーマットになる可能性もある。つまり、icebergの読み方さえ分かれば、icebergの形式でデータを提供するだけでいろんなシステムからデータを利用できるようになる
フォーマット間の変換に関しては難しい問題だが、各フォーマットにはそれぞれ異なる特性や振る舞いがある。私たちの目標としては、それらが人々にとって問題にならないようにすること。つまり、icebergのような形でデータを提供できれば十分な世界にしたい。もちろん、実際には各フォーマットで機能的にも意味的にも違いが大きいので、それを上流のユーザーに影響を与えずに統合するのは大変ではある
上流のユーザ、データサイエンティストなどはテーブルフォーマットを気にしなくて良いようにしたい。彼らが考えるべきはテーブルではなく、SQLのセマンティクスとデータの整合性保証。ParquetだのORCだのAvroだのを気にして、スキーマ進化のときにどうなるかなんて考えるのは、彼らのやるべきことではない。アナリストはデータからいかに価値を引き出すかに集中すべき
究極の目標は、ツール間の連携を高め、こうした問題を意識しなくてもよくなることようにすること
ただ正直、私はApache XTableやDelta Uniformが実際に何をしているのかよく分かっていない。私の専門はあくまでicebergとその機能なので

Caseyへの質問「顧客体験を改善するのに最適な部分はどこだと思いますか?」

Casey「Icebergによる安全なテーブル操作の仕組みを理解してもらうこと」

従来のデータレイクにおけるRead Uncommittedな分離レベルでのデータ操作の限界を理解してもらうことがまずは重要
テーブルの最適化などの運用についてガイダンスやベストプラクティスを提供すると同時に、製品や仕様に組み込んでいくことが重要
ユーザによる細々した対応の必要性はアーリーアダプターなら我慢できる問題だが、エンタープライズな顧客からのフィードバックが届き始めている

Paulへの質問「IcebergをS3でよりよく利用するための最近のイノベーションは？」

Paul「S3 Express One Zone, AWS SDKの最適化」

S3 Express One Zoneという新しい高速ストレージクラスをリリースした。まだこのストレージクラスは初期段階だが、顧客からは良いフィードバックを得ており、採用率も良好である
AWS SDKにおいて、S3のパフォーマンスベストプラクティスをコードで実装するための多くの取り組みを行っている。これをIcebergコミュニティでより広く使ってもらえるようにしたいと考えている