OTFで辛いのはストリーミングではなくテーブルレイアウトの劣化じゃないか説

-- Views

July 15, 26

#data #otfsg

スライド概要

2026-07-10 OTFSG Osaka Meetup #2 LTスライド
https://otfsg-tokyo.connpass.com/event/395739/

profile-image
スライド一覧

妻と子供と酒で出来ているインフラエンジニア。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

（ダウンロード不可）

関連スライド

slide-thumbnail

Fleet入門 ～ArgoCDじゃないマルチクラスタ向けGitOpsツール Fleet とは～
rancherjp k8s rancher
user-img やっさん🍶 1.9K
slide-thumbnail

マイクロアドのData LakehouseとIcebergテーブルの最適化について
data
user-img やっさん🍶 1.2K
slide-thumbnail

RancherJPって何してるの？ ～Kubernetes基盤とその周辺OSSをネタに、 120回以上Meetupを続けてきた技術コミュニティの話～
rancherjp cndw2025 cndw
user-img やっさん🍶 218
slide-thumbnail

Kafka Connect Iceberg Sink Connectorを使ってみる
data
user-img やっさん🍶 >100
slide-thumbnail

ベアメタルで実現するSpark＆Trino on K8sなデータ基盤
data
user-img やっさん🍶 >100
slide-thumbnail

猫でも分かるUnreal Engineの学び方 - 超初心者向け編 - 2023 v1.0
ue4 ue5 ue-beginner
user-img エピック ゲームズ ジャパン 1.7M
各ページのテキスト
1.

2026-07-10 OTFSG Osaka Meetup #2 OTFで辛いのはストリーミングではな くテーブルレイアウトの劣化じゃないか 説 やっさん ＠yassan168

2.

OTFのメイントピックは「ストリーミング対応」 ？ Data Lakehouse としてバッチでETLする所までは進み、 次のステップとして、ストリーム対応に取り組んでいませんか？ 最近では Streaming Lakehouse, LTAP, CDC が巷を賑わせています。 では、OTFのメイントピックは「ストリーミング対応」なのか？ ストリーミング対応も大事ですが、それ以上に大事なのは⋯ 継続的に劣化するテーブルレイアウトへの対処 なのではないか？ってのが今回の話。 ※ここでは「テーブルレイアウト」とは、 メタデータ層やストレージ層の状態とします

3.

なぜ劣化するのか？ OTF は 既存ファイルを直接書き換える代わりに、 新しいファイルを追加し、 メタデータで「今のテーブルの見え方」を切り替える。 その為、書き込みが続くと以下が増えていく。 • Data file • Delete file / Deletion vector • Manifest レイアウトが劣化すると何が起きるか • Snapshot ● クエリ開始前の planning が遅くなる ● オブジェクトストア への LIST / GET が増加 • Orphan file ● delete file / DV の突き合わせの読み取りコスト増加 • Partitionの偏り ● writer と maintenance が衝突しやすくなる ● cleanup を誤ると必要なファイルを消すリスクが出る

4.

レイアウトのメンテは「掃除」だけではない テーブルレイアウトの劣化をどこまで直すかでコストが変わる Level 1: Small file をまとめる → 小さすぎるファイルを適正サイズに戻す Level 2: Delete files / DV を物理反映する → 読むたびに差分を突き合わせる状態を減らす Level 3: Sort / Z-order / Clustering → クエリしやすい並びに作り直す

5.

「全部を一気に直す」は危険が危ない 🙅ダメ • 全テーブルを一括 Compaction この辺りの競 合 べりんぐさん の話は のこれが分か りやすい 🙆OK • Hotな partition を避ける • Cold(古い)な partition から処理する • where で対象を絞る • partial-progress.enabled を 有効にして成功分を残す • 失敗時は partition / 時間範囲を狭めて再実行する Apache Icebergテーブル同時書き込み競合解決の仕組みと注意点 - Speaker Deck

6.

Writer が触る範囲を避ける Hot （直近: 0～7日） Warm （8～14日） ※日付は目安 Cold （15日以降） Writerがまだ触る範囲 遅延到着/再処理の 冷却期間 更新がほぼ止まった 範囲 • 劣化は許容 • 定期的なCompaction は避ける • 必要な時だけ 軽いbin-pack • 重い修復をここで行う • sort / clustering • rewrite_manifests • expire_snapshots / remove_orphan_files • 軽い修復に留める • bin-pack 程度 • cleanupはまだ慎重に

7.

Compaction は消えない。置き場所が変わ る。 置き場所 （Incubating） 見るもの 後から直す (メンテナンスジョブ) small file / delete / metadata 内側で直す (LSM compaction) compaction負荷（sorted runs） / bucketの偏り 別レイヤーに逃がす (Hotストレージ) Lakehouseへの反映遅れ / Hotストレージの圧迫

8.

Compaction は消えない。置き場所が変わ る。 置き場所 見るもの 後から直す (メンテナンスジョブ) small file / delete / metadata 内側で直す (LSM compaction) compaction負荷（sorted runs） / bucketの偏り 補足： Paimonでのcompaction は、sorted runsのmerge でファイルの入れ替わりが多 い。→ HDFS的なファイルストレージと相性が良い。 Lakehouseへの反映遅れ 別レイヤーに逃がす オブジェクトストレージではリネームが多く発生するので / Hotストレージの圧迫 （Incubating） (Hotストレージ) commit/lock/cleanupが難しく、HMSが必要だったりする。

9.

OTF運用は format名ではなく劣化を制御できる か ①見る ファイル数 / delete / metadata / planning latency ②避ける Writer が触る Hotな範囲を避ける 一番のキモ。 こうなる様に デ るのが大事。 ータ設計・運用を考え これは今も昔 も一緒。 ③直す Coldな範囲に絞って compaction / cleanup ④回す 失敗したら範囲を狭め、 悪化した場所から次で直す

10.

Appendix

11.

参考資料：Apache Iceberg • Iceberg Table Spec • Apache Icebergテーブル同時書き込み競合解決の仕組みと注意点 Speaker Deck • Accelerate data lake operations with Apache Iceberg V3 deletion vectors and row lineage | AWS Big Data Blog • Manage concurrent write conflicts in Apache Iceberg on the AWS Glue Data Catalog | AWS Big Data Blog

12.
13.

参考資料：Apache Fluss • Fluss Architecture • Fluss Streaming Lakehouse Overview • Fluss Lakehouse Storage • Fluss Talks & Presentations • Fluss Taobaoの事例紹介 • Fluss GitHub Issue: Refactor Lakehouse Storage Implementation • Fluss GitHub Issue: FIP-3 Support tiering Fluss data to Iceberg