Upgrade to Pro — share decks privately, control downloads, hide ads and more …

オンプレ環境でIcebergを運用して分かったテーブルメンテナンスの重要性

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.

 オンプレ環境でIcebergを運用して分かったテーブルメンテナンスの重要性

2026/06/11 Apache Iceberg実践 ! ベストプラクティス Meetup
オンプレ環境でIcebergを運用して分かったテーブルメンテナンスの重要性

More Decks by システム開発部広報委員会

Transcript

  1. Apache Iceberg実践 ! ベストプラクティス Meetup | オンプレ環境で Icebergを運用してわかったテーブルメンテナンスの重要性 • マイクロアド

    データマネージメントユニット ▪ 大規模データ処理開発 ▪ データマネジメント • 好きな言語 ▪ Python • 経歴 ▪ 2022/4: 株式会社マイクロアドに新卒入社 自己紹介 / 高橋 唐樹 2
  2. Apache Iceberg実践 ! ベストプラクティス Meetup | オンプレ環境で Icebergを運用してわかったテーブルメンテナンスの重要性 マイクロアドのデータ基盤 /

    概要 4 • 最近HiveからIcebergに移行 ▪ 移行の話は OTF Talk #32 とか OTFSG Tokyo Meetup #5 とかでしてます • クエリエンジン・カタログ・ストレージともにオンプレで運用 ▪ Trino, Spark ▪ iceberg-rest-fixture: 自動メンテナンス機能なしのシンプルなカタログ ▪ Dell ECS (ObjectScale): S3互換ストレージ
  3. Apache Iceberg実践 ! ベストプラクティス Meetup | オンプレ環境で Icebergを運用してわかったテーブルメンテナンスの重要性 Icebergのテーブルメンテナンス 6

    • Expire Snapshots ▪ 古いデータを消す ▪ 容量を減らすためには必須 • Remove Orphan Files ▪ 追跡されていない孤立ファイルを消す ▪ 書き込み失敗時 + 正常な運用でも追跡されないメタデータファイルは出る • Rewrite Data Files (コンパクション) ▪ 細かく分かれたデータファイルをまとめる ▪ データの読み込みが効率化 • Rewrite Manifests ▪ マニフェストファイルをまとめる ▪ 実行計画作成が効率化
  4. Apache Iceberg実践 ! ベストプラクティス Meetup | オンプレ環境で Icebergを運用してわかったテーブルメンテナンスの重要性 Icebergのテーブルメンテナンス 7

    • Expire Snapshots ▪ 古いデータを消す ▪ 容量を減らすためには必須 • Remove Orphan Files ▪ 追跡されていない孤立ファイルを消す ▪ 書き込み失敗時 + 正常な運用でも追跡されないメタデータファイルは出る • Rewrite Data Files (コンパクション) ▪ 細かく分かれたデータファイルをまとめる ▪ データの読み込みが効率化 • Rewrite Manifests ▪ マニフェストファイルをまとめる ▪ 実行計画作成が効率化
  5. Apache Iceberg実践 ! ベストプラクティス Meetup | オンプレ環境で Icebergを運用してわかったテーブルメンテナンスの重要性 事例① /

    書き込み頻度が高いテーブル 8 • クローリング結果を書き込むテーブル ▪ データ量はあまり多くない • 複数のクローリング処理から同時に書き込んでいる ▪ 数秒おきに書き込み : 正常なファイル・古くて追跡されなくなったメタデータファイルが大量に発生 ▪ 書き込みの競合も多い : リトライで書き直されたファイルが大量に発生 • テーブルメンテナンスは手動運用 ▪ 他のテーブルとはライフサイクルが違うため
  6. Apache Iceberg実践 ! ベストプラクティス Meetup | オンプレ環境で Icebergを運用してわかったテーブルメンテナンスの重要性 事例① /

    書き込み頻度が高いテーブル 9 • Remove Orphan Filesを実行したときに起こったこと ▪ SparkのDriverのメモリを大量に要求される ▪ SparkのBroadcast Joinの上限 (8GB) を超えてそのままでは実行できない ▪ ストレージ層からの応答が不安定になる • 何が起きた? ▪ テーブルで追跡している全ファイル と テーブルのロケーションにある全ファイル を照合して孤立ファイルを判定 ▪ テーブルで追跡しているファイルの一覧が巨大 ▪ S3はテーブルのロケーションにある全ファイルの取得が苦手 • 削除対象の期間を絞っても照合にかかる計算コストは同程度 ▪ 放置しすぎると”詰む”可能性がある
  7. Apache Iceberg実践 ! ベストプラクティス Meetup | オンプレ環境で Icebergを運用してわかったテーブルメンテナンスの重要性 事例② /

    Merge on Readテーブル 10 • 日次で更新されるマスターテーブル ▪ データ規模: 約200〜300億件 ▪ 日次での更新: 全体の10%程度 ▪ → 大部分は更新されないので全件書き直しはコストが高い • MoRで更新することで書き込み量を削減 ▪ MoR: Merge on Read = 差分書き込み ▪ ⇔ CoW: Copy on Write CREATE TABLE sample ( ... ) USING iceberg TBLPROPERTIES ( 'write.{ delete | update | merge }.mode'='merge-on-read' );
  8. Apache Iceberg実践 ! ベストプラクティス Meetup | オンプレ環境で Icebergを運用してわかったテーブルメンテナンスの重要性 事例② /

    Merge on Readテーブル 11 • テーブルメンテナンス (コンパクション) をしないと参照のパフォーマンスは悪化する ▪ 様子見で自動化してなかった ▪ 手動作業のコンパクション自体で 1時間半かかるような場合も • 定期的にコンパクションするよう自動化した ▪ 平均ファイルサイズなどのしきい値で悩むくらいならまずやる! Merge on Readテーブルを参照する定期実行クエリの処理時間 手動作業 手動作業 手動作業 手動作業 ここから自動化
  9. Apache Iceberg実践 ! ベストプラクティス Meetup | オンプレ環境で Icebergを運用してわかったテーブルメンテナンスの重要性 まとめ 12

    • Icebergカタログ選定の段階でテーブルメンテナンス機能は考慮すべき ▪ マネージドだと自動メンテナンスが多い ▪ セルフマネージドでも Lakekeeperのように機能としてあるカタログもある • 自動メンテナンス機能のないカタログを選ぶ場合も運用初期から仕組みを検討すべき ▪ しきい値調整は後からできるので詰んでしまう前にやる