想定読者
- Iceberg という単語は聞いたことがあるが、まだ触っていない
- Icebergを導入してみたいが、積極的な利点が説明できない
設計の大事さ
AI・分析基盤の変化が速い時代、何を標準の土台にするべきかが読みにくくなりました。クエリエンジンもAI基盤も、数年（数ヶ月かも...）スパンで「こっちの方が速い」「こっちの方が使いやすい」が起きます。
だからこそ、変わるもの（コンピュート）と、長く残るもの（ストレージ）を分離して設計するのが重要だと感じています。
そう思うようになったきっかけは、今年 9 月のServerless Daysでの、AWSの下佐粉さんのApache Icebergセッションです。
Icebergについて
Icebergの仔細については、Beringさんの記事がまとまっています。
https://bering.hatenadiary.com/entry/2023/09/24/175953
Icebergのイメージを簡単に説明すると、「S3＋Parquetにテーブル管理を足したもの」です。
業務上の悩み
私は、新卒1年目として、クライアント先でAWS上にデータ基盤の構築をする業務に携わっておりまして、日々の業務では、
- S3にParquetでデータを置く
- Glue Crawlerでカタログ化して
- Athenaでクエリする
という構成でデータ基盤を構築しています。
ところが、実際に基盤を運用してみると、次のような悩みが出てきます。
- 分析対象の粒度を細かくしたいときに、データの全件洗い替えの作業が起こる
- いまはAthena中心で動いているけど、将来は別のクエリエンジンやAI基盤に寄せたくなるかもしれない
Icebergであれば、S3上のParquetを「ちゃんとテーブルとして扱う」ための仕組みを提供してくれます。運用で困るポイントをテーブル側が吸収してくれます。
なんで今、Icebergなのか
今の時代に怖いのが、特定の製品に寄せた形式でデータを持ってしまって、移行が重くて身動きが取れなくなってしまうことです。
IcebergはOTF（Open Table Format） なので、
- データはS3（オブジェクトストレージ）に置いたまま
- 使うエンジンやプラットフォームを後から変えやすい
- 移行コストを最小化して、選択肢を残せる
という形で、データのストレージを中立に持っておけるのが大きいです。
最後に
データのストレージとコンピュートを疎結合で持っておく。
私はこの発想がいちばん刺さりました。