---
title: OTFで辛いのはストリーミングではなくテーブルレイアウトの劣化じゃないか説
tags:  #data #otfsg  
author: [やっさん🍶](https://www.docswell.com/user/yassan)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/5JGLMXL57L.jpg?width=480
description: 2026-07-10 OTFSG Osaka Meetup #2 LTスライド https://otfsg-tokyo.connpass.com/event/395739/
published: July 15, 26
canonical: https://www.docswell.com/s/yassan/527WYV-otfsg-osaka-02-lt
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/5JGLMXL57L.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/47QYR8YLEP.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/KE4W82W5J1.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/L71Y2MY2JG.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/G7WGR3G2E2.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4JZLRVL4E3.jpg)

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はまだ慎重に


# Page. 7

![Page Image](https://bcdn.docswell.com/page/YE6WR5WGEV.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GE5M8YMXE4.jpg)

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が必要だったりする。


# Page. 9

![Page Image](https://bcdn.docswell.com/page/9729KG9QJR.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/DJY4NV4Y7M.jpg)

Appendix


# Page. 11

![Page Image](https://bcdn.docswell.com/page/V7NYXMYRE8.jpg)

参考資料：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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/YJ9P8NPZ73.jpg)

参考資料：Apache Paimon
• Paimon Primary Key Table Compaction
• Paimon Dedicated Compaction
• Paimon Table Mode


# Page. 13

![Page Image](https://bcdn.docswell.com/page/GJ8D8KXYJD.jpg)

参考資料：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