Iceberg Summit 2026のセッション「From Batch to Streaming and AI, Iceberg for Everyone by Everyone」をまとめます。
From Batch to Streaming and AI, Iceberg for Everyone by Everyone - YouTube
- スピーカー
- オープンテーブルフォーマットが必要とされた理由
- V1の3つの原子的操作と、その限界
- V2のdelete filesによる行レベル更新
- 相互運用スタックへと広がるIcebergとコミュニティの成長
- ストリーミングとAIに向けたV4の始動
- ストリーミングの課題とroot manifestによるメタデータ再設計
- AIが求めるもの。ワイドテーブルとカラム単位の更新
- V4を支える関連セッションと、次の一歩への呼びかけ
- まとめ
スピーカー
このセッションは、Apache Iceberg のProject Management Committee（PMC）メンバーであり、Apache Software Foundation のメンバーでもあるRussell Spitzer氏によって行われました。Spitzer氏はIcebergプロジェクトの初期から関わってきた一人で、最初のコントリビューションは期限切れスナップショットまわりのテストを追加する小さなPRだったと振り返ります。本セッションでは、その自身の歩みを起点に、Apache Iceberg がどこから来てどこへ向かうのかをコミュニティの視点から語っています。
オープンテーブルフォーマットが必要とされた理由
Iceberg がどこへ向かうのかを語るには、どこから来たのかを押さえておく必要があります。Spitzer氏が振り返る出発点が、自身の最初のコミット f7944f8 です。2020年7月、RemoveSnapshots にテストを2つ追加しただけの小さなPR（#1223）でした。コミットメッセージにある通り、期限切れスナップショットが参照するマニフェストを扱うコードパスはそれまでテストで通っておらず、バグはないものの将来の破壊を防ぐためにテストを足した、という内容です。
最初の貢献はテーブルフォーマットを定義し直すような大仕事ではなく、コミュニティに関わるためのほんの一歩でした。これはIcebergプロジェクト自体の歩みとも重なります。ごく小さなところから始まり、そこから少しずつ進化してきたわけです。
Apache Iceberg が登場する前のデータ管理は、大きく2つのパラダイムに分かれていました。一方は、オープンな形式のファイル群をディレクトリに配置していく方式です。スライドでは /zip=70115 や /zip=60035 といったパス配下にファイルを置き、Hadoop 上で扱う様子が示されています。もう一方は、ウェアハウスと呼ばれるプロプライエタリなシステムに格納する方式です。
どちらにも長所と短所がありました。ディレクトリにファイルを並べる方式は、多くのエンジンとそのまま連携できる相互運用性が魅力で、構築も利用も簡単です。しかしファイルシステムをそのままテーブルのカタログ代わりに使うため、原子性（atomicity）が欠けます。スキーマを管理する手段もなく、ファイルを書き込む各プロバイダとの間に守るべき契約（contract）も存在しません。SQLに見えるAPIを上に被せた例もありましたが、私たちが慣れ親しんだリレーショナルシステムのようには振る舞いませんでした。
ウェアハウスはその逆です。リレーショナルテーブルに期待するセマンティクスを一通り備えていますが、プロプライエタリゆえにロックインが生じ、他の多くのシステムとは相互運用できないのが通例でした。
ここで必要とされたのが、オープンテーブルフォーマットです。Spitzer氏の定義によれば、これはビッグデータのテーブルの上にSQLの信頼性を載せつつ、さまざまなエンジンへ移植できる状態を指します。これはApache Iceberg公式サイトでIcebergそのものを説明している文言でもあります。
ファイル群に対してSQL的・リレーショナルな操作ができるという技術的な部分は理解しやすいものです。一方で「オープン」であることは、Icebergが何を作ってきて、これから何を作り続けるべきかを理解するうえで欠かせません。オープンであることこそが相互運用性の鍵だからです。コンウェイの法則、つまり組織のあり方はその組織が生み出すプロダクトに反映されるという経験則の通り、オープンに相互運用するコミュニティがなければ、オープンに相互運用するフォーマットを持つことも難しくなります。
そのオープンさには3つの意味があります。1つ目はオープンな標準です。Icebergテーブルに触れる誰もがその扱い方を正確に把握でき、どんな機能があってないのかが全員に明確であることを意味します。2つ目はオープンなコードです。プロジェクトに関わる誰もが書かれているコードを見られ、バグを探し、望めば貢献できる状態を指します。そして3つ目が、最も重要とされるオープンなコミュニティです。Icebergを支えるのは人々の協働であり、そこから標準もコードも生まれてきました。
V1の3つの原子的操作と、その限界
Iceberg V1のテーブル構造は、カタログ、メタデータ、データの3層で表現されます。カタログはテーブル名（図ではdb1.table1）から最新のメタデータファイルへのポインタを保持します。メタデータファイルはスナップショット（図のs0、s1）を記録し、各スナップショットはマニフェストリストを指します。マニフェストリストは複数のマニフェストファイルを束ね、マニフェストファイルが実際のデータファイル群を参照する形です。
この構造から導かれる核心は、V1のモデルで原子的に行える操作がたった3つしかないという点にあります。新しいデータファイルを追加する、既存のデータファイルを削除する、ファイルを置き換える。この3つだけです。スナップショットを差し替えることでこれらをトランザクションとして実現します。
ファイルの追加（Add File）、削除（Remove File）、置換（Replace File）という3つの原子的操作は、いずれもファイル単位で完結します。図はそれぞれ、空だった場所にファイルが入る、存在したファイルが消える、既存ファイルが変更行を含む新しいファイルに差し替わる様子を表しています。
このわずか3操作の上に、ペタバイト級のスケールまで耐えるテーブルフォーマットを構築できます。ファイルをまとめて素早く原子的に入れ替えられるため、大きな単位でデータを扱うバッチ処理やパーティション単位の書き換えには十分に機能しました。
Icebergは2017年のRyan Blue氏による最初のコミットから始まり、2018年11月にApache Incubatorへ入り、2019年10月に最初の公式リリースである0.7.0-incubatingを出しました。2020年には0.9.0までにIncubatorを卒業してトップレベルのApacheプロジェクトとなり、この年だけで4回のリリースを重ねています。140を超えるユニークコントリビューターから1,352のコミットが集まりました。
この急速な普及はすべて、ファイルの追加・削除・置換という3操作だけを許す仕様の上で成し遂げられたものです。大きなファイルをまとめて差し替えるうちは問題ありません。ただし、データファイルの中のごく一部、数行だけを変えたいというユースケースが現れると、このモデルは限界に直面します。
問題の本質は、行の置き換えが未変更行のコピーを強いる点にあります。V1には行を直接書き換える手段がなく、ファイル単位の操作しか持ちません。
1行だけ変更したい場合でも、その行を含むデータファイルを丸ごと作り直す必要があります。変更されていない大量の行まで新しいファイルへコピーされるため、コストは非常に高くなります。たまに一度や二度行う程度なら許容できるかもしれません。
しかしGDPRの「忘れられる権利」のような要求が現れると話は変わります。特定ユーザーのレコードを削除するために、該当行を含むファイルを次々と書き直す操作が頻発するようになりました。
DELETE WHERE user IN (...) のようなクエリでは、対象となる行が数十、数百、ときに数千のファイルに散らばっています。それぞれのファイルでごくわずかな行を消すために、変更のない膨大なデータを何度も書き直すことになります。
この時点で、Iceberg V1はこうしたワークロードを扱うには不十分でした。とはいえコミュニティは、Icebergは行儀の良いバッチ処理やパーティション・ファイルの置き換えだけを担うものだと割り切ったわけではありません。私たちはこの課題を解くべき問いとして引き受けることになります。
V2のdelete filesによる行レベル更新
V2はV1にできたことをすべて引き継いでいます。ファイルのAdd、Remove、Replaceという3つの原子的操作はそのまま利用できます。図はV1がサポートしてきた操作を示したもので、ファイルを追加する、ファイルを削除する、そしてファイルを丸ごと置き換える、という3つの形が並びます。
問題はReplace Fileです。一部の行（Changed Rows）だけを書き換えたいときも、V1ではファイル全体を新しいファイルに置き換えるしかありません。変更していない行まで丸ごとコピーして書き直すことになります。GDPRの忘れられる権利やDELETE WHEREのように一握りの行だけを操作したいユースケースでは、この全コピーが大きな負担になります。
未使用データのコピーを避けて行レベルの更新を実現するために導入したのが、私たちがdelete fileと呼ぶ仕組みです。delete fileは、既存のデータファイルに手を触れずに、そのファイルの中の特定の行を「削除済み」として記録するファイルです。
図のRemove Rowが示すとおり、元のデータファイルはそのまま残し、隣にdelete fileを1つ追加します。読み取り時には、データファイルとそれに対応するdelete fileを同時に読み込み、削除対象の行を取り除いた結果をその場でマージして返します。これにより、行を消すために巨大なデータファイルを書き直す必要がなくなります。
行の更新も、delete fileと新しいデータファイルの組み合わせで表現します。図のChange Rowは、元のデータファイル、変更前の行を消すためのdelete file、そして変更後の行を収めたNew Fileという3つの組み合わせです。古い値をdelete fileで隠し、新しい値を別ファイルとして足す形になります。
読み取り時にこれらを合成すれば、その時点でテーブルがどう見えるべきかが得られます。原理だけ見ればV1でもデータファイルを丸ごと置き換えれば同じ結果は出せました。delete fileが優れているのは、変更していないデータをコピーせずに済む点です。
ここで本質的なのは、テーブル内のファイルを変更する操作が、すべて「ファイルを追加するだけ」に還元される点です。既存ファイルを書き換えないため、その上のメタデータ層も単調に増えていきます。マニフェストファイルを書き換える必要がなく、新しいものを足していくだけで済みます。
delete fileによる行レベル更新は多くの場面で成功を収めましたが、新しいユースケースと利用者は増え続け、フォーマットはV3へと進みました。
V3では、行の置き換えをより効率的に行う仕組みを取り入れています。位置指定のdelete（position delete、ファイル内の行位置で削除対象を指す方式）については、従来のdelete fileを置き換える新しい表現を用意しました。型の面では、半構造化データを格納するvariantと、地理空間データを扱うgeoが加わっています。さらに暗号化のサポートも入りました。
こうした拡張が次々と実現できたのは、コミュニティが実際のユースケースを観察し、そこで何をしたいのかを見極めながら、その要求に合わせてフォーマットを進化させ続けてきたからです。
相互運用スタックへと広がるIcebergとコミュニティの成長
フォーマットが新しい要求に応えて進化を重ねた期間は、コミュニティが急成長した期間でもありました。V2が登場した2021年から数えると、テーブルフォーマットはV2とV3の2回の大きなリリースを経て、数えきれないほどのライブラリリリースと、オンライン・対面の両方で開かれたIceberg Summitを積み重ねてきました。2024年に最初のIceberg Summit、2025年には対面での第2回SummitとV3が重なり、2026年には第3回Summitを迎えています。
この間にApache Iceberg本体のリポジトリには8,000を超えるコミットが積み上がり、ユニークなコントリビューターは1,000人を超えました。スライドの数字は8,249コミット、1,026コントリビューターです。ただしこれはあくまでApache Icebergの中核リポジトリだけを数えた値で、実態はもっと大きいのです。Icebergはもはや単一のJava実装でも、テーブルフォーマットの仕様書一枚でもありません。
Apache Icebergは、相互運用スタック全体を覆う複数の仕様の集合へと広がりました。テーブルをある場所から別の場所へ動かすだけでなく、カタログとどう対話してテーブル情報を取得しコミットするかを定めたCatalog REST Specがあります。エンジン間で共有できるビューを扱うView Spec、各種のblobやインデックスを格納するためのPuffin Spec、そして最近仕様に加わった、システム間でUDF（ユーザー定義関数）を移動するためのUDF Specもそろっています。
実装言語もJavaにとどまりません。iceberg-python、iceberg-rust、iceberg-go、iceberg-cppがあり、それぞれが独立したコミュニティと実装を持っています。テーブルだけでなく、Javaだけでもない。これらをすべて合わせて数えると、コミュニティの規模はさらに大きくなります。
周辺の仕様や多言語実装まで含めてコミュニティ全体を数え直すと、コミットは13,059件、コントリビューターは1,518人に達します。V2が始まった時点と比べて10倍以上の広がりです。この数字には、Project Management Committee（PMC、プロジェクトの運営・意思決定を担う委員会）のメンバーやcommitter（コミット権を持つ貢献者）も含まれています。
前回のSummit以降に新しくcommitterやPMCに加わった人たちがいます。committerにはGang WuとDrew Gallardo、PMCメンバーにはKevin Liu、Matthew Topol、Prashant Singh、Sung Yunが名を連ねます。
新しくcommitterやPMCに加わった人たちは、Apache Icebergに計り知れない貢献を重ね、コミュニティを一段と強くしてきました。
ここまでの数字だけを見れば、Apache Icebergは順風満帆に見えます。新しい業界イベントが開かれるたびにIcebergのサポートが中心に据えられ、もうテーブルフォーマットとして必要なことはすべて満たした、これ以上やることはないと考える人もいるかもしれません。データの扱い方に大きな地殻変動が起きないのであれば、確かにそれでよかったはずです。しかし、コンピューターサイエンスの世界全体を揺るがすような変化が起きているとしたら、話は変わってきます。
ストリーミングとAIに向けたV4の始動
データ管理の前提が再び大きく動いています。IDCの調査「Converged Workloads: Enabling Real-Time Enterprise Intelligence and AI Innovation, 2025」によれば、エンタープライズの96%がAIとアナリティクスのためにストリーミングを使っているか、使う計画があるとされています。データ処理の世界では、分散システムの定番書とされる教科書が2026年版に向けて大幅改訂され、AIとクラウドネイティブなアーキテクチャを取り込もうとしています。ポストチャットボットの時代、すなわちAIエージェントが実務に入り込む段階に移りつつあるという論調も出てきました。テーブルフォーマットに求められるものも、こうした変化に合わせて変わっていきます。
この変化に対して、私たちコミュニティは受け身ではありません。V3仕様は2025年5月29日に承認されました。そのわずか1週間も経たないうちに、EdwardによってV4の作業を可能にする最初のコミットが入っています。V3を終えた直後にV4へ着手したのは、現行仕様に残されたギャップを認識していたからです。行レベル削除を導入したときと同じように、業界の要求が変わればテーブルフォーマットへの要求も変わります。Apache Iceberg はその新しい要求に合わせて作り直す必要があります。過去にも作り変えてきた以上、同じことはまたできます。Iceberg は私たちが必要とするものへ姿を変えられる、というわけです。
ここで見落としてはならないのは、エージェントとAIの時代であっても、Iceberg を支えているのは依然として人間のコミュニティだという点です。だからこそ新しい要求やリクエストを受け止め、それに合わせてコミュニティとプロジェクトを変えていけます。時代が変わるなら、私たちもそれとともに変わります。
新しいストリーミングとAIのユースケースに応えるV4へ向けて、すでに多くの作業が進んでいます。これを実現できるのは、皆が協力して取り組むからです。最初の論点はストリーミングです。ストリーミングはきわめて重要で、AIの時代にあってさらに重みを増しています。
ストリーミングの課題とroot manifestによるメタデータ再設計
ストリーミングが指すのは、システムへ繰り返しデータが流れ込み続けるユースケースです。IoTデバイスからのテレメトリ、大量のログ収集、他システムからのCDC（Change Data Capture、変更データのキャプチャ）といった場面で、しばしば多数の小さなコミットを伴いながらデータが絶え間なく届きます。重要なのは個々のイベントではなく、情報が連続して流れ続けるという性質です。
こうしたユースケースはAIの時代になってさらに比重を増しています。誤解のないように言えば、Apache Iceberg は現状でもストリーミングに使えます。ただ、Icebergを将来のストリーミングの主役に据えるには、まだ改善すべき弱点が残っています。
ストリーミングが抱える問題
Icebergにファイルを1つ追加する手順には、無視できないオーバーヘッドが伴います。V3のテーブルに100行を足す場合を考えてみます。最初に100行を収めたデータファイルを1つ書きます。次に、そのデータファイルがテーブルの一部であることを記す1行だけのマニフェストファイルを作ります。さらに、新しいマニフェストの存在を記録するためにマニフェストリストを書き直します。たった100行のために、データファイル・マニフェストファイル・マニフェストリスト、そしてmetadata.jsonを数えれば4つものファイルを書くことになります。
問題は、コミットのたびにメタデータ層がファイル1つ分ずつ膨らみ、しかもそのファイルの中身は1行だけという点です。これは効率的とは言えません。現にストリーミングを運用している人々は、マニフェストファイルを継続的に統合するアグレッシブなコンパクションを走らせ、メタデータ層のオーバーヘッドを抑え込んでいます。加えて、直近のデータを読むにも常に2ホップが必要です。まずマニフェストファイルを読み、それからデータを読むという経路をたどらざるを得ません。
root manifest
V4で進めているメタデータ層の再設計の核となるのが、root manifestと呼ぶ仕組みです。考え方はシンプルで、配下にマニフェストしか持てない特別なファイルだったマニフェストリストをやめ、最上位にマニフェストファイルを置きます。このトップレベルのマニフェストファイルは、配下にマニフェストファイルを持つことも、データファイルを直接持つこともできます。
この変更は階層を単純にするだけでなく、いくつもの利点をもたらします。第一に、ストリーミングで毎回マニフェストファイルを書いてコミットする負担がなくなります。中間の仲介者を挟まず、root層へ直接ファイルを書き込めるからです。第二に、マニフェストファイルがマニフェストファイルを持てる構造なので、末端のデータファイルが持つ列統計を最上位まで容易に集約できます。V1からV3のマニフェストリストでもプルーニングは可能でしたが、それはパーティション統計に限られていました。新しいレイアウトでは列統計をroot層まで積み上げられるため、より細かい枝刈りが効きます。
adaptive metadata tree
root manifestを土台に、提案では adaptive metadata tree（適応的メタデータツリー）と呼ぶ仕組みを導入します。root manifestをバッファとして扱い、ファイルを次々と溜め込んでいきます。そして十分な数が溜まった時点で初めて、それらをleaf manifestへ切り出します。
この切り出しは書き込み時に行えます。ライターはroot manifestに含まれる全ファイルの完全なリストを把握しているため、新しいアペンドの延長で自然にleafを生成できるからです。結果として、マニフェストを統合するための独立したrewrite manifest処理が不要になります。ツリーを適応的に育てられ、それを保つための付随的な最適化を別途走らせる必要もなくなる、という形です。
single-depth tables
同じ仕組みは小さなテーブルにも効いてきます。小規模なテーブルであれば、すべてをroot manifestのレベルだけで完結させられます。たまに数行が流れ込む程度の小さなストリーミングテーブルなら、メタデータ層をマニフェストファイルのちょうど1 IO下に収められ、2層のメタデータを持たずに運用できます。これにより書き込みも読み取りも速くなり、テーブルを極めて軽快に動かせます。
V4でのこうした工夫は、多くのストリーミングのケースを助けるはずです。残るのは、近頃ますます話題に上るAIベースのユースケースをどう扱うかという、より大きな問いになります。
AIが求めるもの。ワイドテーブルとカラム単位の更新
AIユースケースに向き合うには、Apache Icebergがそこから何を要求されるのかを最初に整理する必要があります。Icebergはサービス層ではなく、ディスク上のファイル群に対してSQLをどう実行するかという「契約」を定めるものです。だからこそ問うべきは、LLMベースのワークロードがテーブルフォーマットに何を求めるか、ディスク上のデータをどう更新し、どうアクセスし、何を保存しようとするのかという点になります。
ここで現行仕様が抱える論点として、なぜデータを保存するのか、なぜテーブルなのか、列単位の更新をどう扱うか、そしてマルチモーダルデータをどう支えるか、という大きな課題が浮かび上がります。
近年のテーブルは当初の想定を超えて横方向に膨らんでいます。かつてテーブルの列数は20〜100程度を見込んでいましたが、feature store（機械学習の特徴量を蓄える基盤）やLLMの学習モデルの普及により、数千から数万列に達するテーブルが現れています。各列が既存の行に対する新たな特徴量の計算結果を表す形です。
この極端に幅広いテーブルはIcebergにとって厄介な存在です。私たちのメタデータモデルは、テーブルの全列を1つのファイルに収めることを前提とします。テーブルが幅広くなるほど1ファイルが収められる列幅は飽和し、結果として1ファイルあたりの行数が減ってしまいます。
ここにマルチモーダルの課題も絡みます。列のなかには文字列や整数ではなく、JPEG画像や動画フッテージのように、行に紐づくものの本来は関係形式を持たない大きなペイロードを表すものが出てきます。幅広テーブルの問題はこうした非構造データの保存とも結びついています。
幅広テーブルは、テーブルの成長方向そのものを変えつつあります。V3までのIcebergでは、テーブルが拡張されるとは行を追加するか、行を変更することを意味していました。出発点はファイルのadd/removeで、次に行のadd/removeへと進んだ流れです。ところがAIユースケースでは、行ではなく列を追加するパターンが目立ちます。モデルが特徴量のセットを丸ごと生成し直して列を置き換えたり、新しい実験のために列を追加したりするわけです。
つまりテーブルは下方向ではなく右方向に伸びていきます。列を追加するテーブルを扱う道具は現状にもありますが、Icebergの第一級の操作がファイルの追加・削除と行の追加・削除に限られるため、できることは限定的です。V2への移行のときと同じように、V4ではこうした新しいユースケースを扱う能力を加える必要があります。
列単位の更新
V4では、Apache Icebergのテーブルに列単位の更新を導入するための提案が複数、現在進行で検討されています。
根底にある考え方はシンプルです。ある列が、本来その列が属するファイルとは別のファイルに存在することを許す、という発想です。一定の列を持つ「ベースファイル」があり、それとは別に、同じテーブルに属するものの最初のファイルには含まれない列を持つ「追加の列ファイル」を置けるようにします。これによって列を置き換えたり、新しい列を追加したりできるようになります。
この仕組みは、既存のデータファイルに対して列を置き換える操作（REPLACE COLUMNS）と、新しい列を追加する操作（ADD COLUMNS）の両方を可能にします。図では、ベースファイルに対して別ファイルとして用意した列を結合する形で、置換と追加が表現されています。
同様の機能は他のテーブルフォーマットにも存在します。Apache Icebergコミュニティの強みは、業界の他のフォーマットや事例に現れた良いアイデアを取り込める点にあります。Icebergがこうした新しい次元へ広がることを妨げるものはありません。
これが実現すれば、数万列を持ち、各ファイルがテーブルの一部の列だけを収める形で数千ファイル分の幅を持つテーブルも保存できます。従来どおりのデータ保存を続けながら、際限なく広がるテーブルに対応できるわけです。マルチモーダルも同じ枠組みで扱いやすくなります。同じ行を表す列を別ファイルに分離できるため、重いオブジェクトを関係データとは別のファイルに置きつつ、テーブルフォーマットによって全体の整合を保てます。列を変更・追加するたびにファイルを書き直さずに済む点も大きな利点です。
メタデータ層への適用
データ層に導入するこの能力は、メタデータ層にも適用できます。これがV4提案のもう一つの柱です。
高レベルで見ると、たとえばテーブルからデータファイルを1つ取り除きたい場合、従来はマニフェスト全体を書き直す必要がありました。対象のデータファイルのエントリを含むマニフェストを取り出し、そのエントリを除いた新しいマニフェストを作り直す形です。これを行のdeleteと同じ仕組みで表現できれば、マニフェストに手を触れずにデータファイルを取り除けます。
その結果、テーブル全体のマニフェスト層、つまりメタデータ層がはるかにキャッシュしやすくなります。全体をメモリに保持しやすくなり、ファイルを絶えず置き換える必要もなくなります。V4にはほかにも多くの改良が含まれますが、全体像としては、AIとストリーミングのユースケースをより良く扱えるようになるということです。
V4を支える関連セッションと、次の一歩への呼びかけ
V4で導入される列単位更新の実装の詳細は、別セッションに委ねられています。Gábor Kaszab氏とPeter Vary氏による「Column Families in Iceberg: Enabling Efficient Feature Updates for Wide Tables」では、幅広テーブルに対する効率的な列更新を、Icebergにどう組み込むかが扱われます。
Eduard Tudenhöfner氏の「Understanding Column Statistics in v4」は、新しい列統計が、再設計されたマニフェストツリーの中をどのように上位へ伝播していくかを掘り下げます。root manifestへ列統計を集約する仕組みの裏側に関心があるなら、参照すべきセッションです。
メタデータ構造の刷新そのものを深掘りするのが、Amogh Jahagirdar氏とSteven Wu氏による「Breaking the Mold: Re-thinking Iceberg Metadata Structure in v4」です。adaptive metadata treeへの移行がプロジェクトに具体的にどう作用するか、その詳細をたどれます。
ここで紹介された顔ぶれは、V4を前へ進める数名にすぎません。Apache Icebergには1,500人を超えるユニークなコントリビューターがいて、その一人ひとりがプロジェクトに欠かせない貢献をしてきました。issueを立てることも、SlackやメーリングリストでHaiと声をかけることも、新しい視点と関心を持つ人をコミュニティに迎え入れることになり、フォーマットの進化を豊かにします。
私たちの誰もが、最初は小さな一歩から始めています。Spitzer氏自身の最初のコミットは、RemoveSnapshotsにテストを2本追加しただけの小さなPR（#1223、2020年7月21日）でした。既存ロジックにバグはないものの、期限切れスナップショットが参照するマニフェストを含む有効スナップショットのコードパスがテストで通っていなかったため、将来の破壊を防ぐカバレッジを足した変更です。テーブルフォーマットの根幹を書き換える巨大なPRで参加したわけではなく、good first issueと呼べるような小さな改善が出発点でした。
これはSpitzer氏に限った話ではありません。Apache IcebergのPMCメンバーの多くが、似た物語を持っています。Fokko Driesprong氏の最初のコミットは、Apache Parquetを1.10.1へ上げる依存更新（#488、2019年9月、apache-iceberg-0.7.0-incubating期）でした。
それぞれが、プロジェクトを少し良くする一点を見つけて入ってきています。Steven Wu氏の入口は、BaseMetastoreTableOperationsがNoSuchTableException時にrefreshを無効化すると、current()の戻り値をチェックしない呼び出し側で不親切なNPEを招くという修正（#1553、2020年10月）でした。
最初の貢献は、たいてい巨大な機能ではありませんでした。Renjie Liu氏のapache/iceberg-rustへの最初のコミットは、エラー定義をマクロで行う変更（#17、2023年8月）です。
仕様の章をまるごと書き起こすことも、オープンテーブルフォーマットの定義を引き直すことも必要ありませんでした。Peter Vary氏の出発点は、Hive Catalogのデフォルトテーブル位置をデータベースの位置から導く小さな変更（#1240、2020年7月）でした。
自分が手伝えそうな、ちょっとした一点。それが入口です。Honah J.氏のコミットは、Pythonでfixed[16]からuuidへのプロモーションを扱う変更（#8215、2023年8月）でした。
あなたのApache Icebergの物語の次の章は何になるでしょうか。Julien Le Dem氏の最初のコミットは、Sparkのバージョンを2.3.0に更新するもの（#16をクローズ、2018年3月、apache-iceberg-0.7.0-incubating期）でした。
関わり始めるのに大きな労力はいりません。何かを変える必要すらないのです。Kevin Liu氏の入口は、メタデータファイルが見つからないときのリトライ回数を制限するHive向けの修正（#3379、2021年10月）でした。
テーブルフォーマットの考え方を一変させる必要も、仕様を書き換える必要もありません。Daniel Weeks氏の最初のコミットは、Tables APIの実装を統合し、metastore tables実装を汎用化する整理（#29、2018年4月）でした。
必要なのは小さな一歩だけです。Pull Requestをレビューするのも貢献の一つです。Sung Yun氏の最初のコミットは、JDBC namespaceのプロパティ列名を予約語でない名前へ変更する修正（#5017、2022年6月）でした。
バグを報告することも、Apache Icebergのイベントを主催することも、立派な関わり方です。Matthew Topol氏の入口は、apache/iceberg-goにschemaとtypesを入れる最初の機能追加（#1、2023年8月）でした。
同じ部屋にいる誰かに自己紹介して、コミュニティに少しだけ深く関わるのもいいでしょう。Szehon Ho氏の最初のコミットは、write.target-file-size-bytesのデフォルトを512MBへ変更するもの（#2220、2021年2月）でした。
Summitの場にいること自体が、すでに大きな一歩です。Ryan Blue氏のコミットは、Apache Icebergの最初の公開リリース（コミットa5eb3f6、2017年12月18日、親なし）でした。プロジェクトの起点となった一行です。
そこで止まらずに進んでほしい、というのがSpitzer氏の呼びかけです。新しい人と出会い、質問をぶつけ、アイデアを提案する。Parth Brahmbhatt氏の入口は、ReplaceFileアクションを実装し、overwriteとreplaceが共通の基底クラスを継承できるよう共通部分を抽出した変更（Issue-25、#31、2018年6月）でした。原子的操作Add/Remove/Replaceの一角を支える初期実装です。
昨日より少しだけ深くコミュニティに関わること。こうしてIcebergは良くなっていきます。Prashant Singh氏の最初のコミットは、PrestoDBとTrinoへのリンクを新しいタブで開くようにするドキュメント修正（#3576、2021年11月）でした。
こうしてApache Icebergプロジェクトは進化します。Yufei Gu氏の最初のコミットは、write.target-file-size-bytesの正しいデフォルト値をドキュメントに反映するもの（#2393、2021年3月）でした。
誰にとっても機能するフォーマットへとApache Icebergを育てるには、協働を続けるしかありません。一人の巨大な貢献ではなく、多くの小さな一歩の積み重ねが、ここまでのIcebergを作ってきました。今ここでSummitに参加していること自体が、その次の一歩の始まりになります。
まとめ
Apache Icebergは、ファイルの追加・削除・置換という3操作だけのV1から、delete fileによる行レベル更新を可能にしたV2、位置指定deleteやvariant・geo型を加えたV3へと、現実のユースケースに合わせて姿を変えてきました。そしてストリーミングとAIという新しい要求に対しては、root manifestとadaptive metadata treeによるメタデータ層の再設計、列単位の更新やマルチモーダルデータへの対応をV4で進めています。こうした進化を支えてきたのは、巨大な貢献ではなく、誰もが小さな一歩から関わってきたコミュニティの積み重ねでした。時代が変わるならフォーマットも変わる、そしてそれを動かすのは依然として人々である、というのが本セッションの一貫したメッセージです。
