Slide 1

Slide 1 text

Sansan株式会社 / 織田 繁 2026-06-26 データレイク 「見えない問題」を可視化する Amazon S3 + Apache Iceberg メダリオン アーキテクチャ オブザーバビリティ設計

Slide 2

Slide 2 text

TimeTable 0〜2分 オープニング 自己紹介・会社紹介 2〜15分 Iceberg 歴史と内部構造 Icebergが生まれた背景と内部構造を図で整理 (前提知識) 15〜25分 Topic 1 スモールファイル問題 metadataで現状把握 25〜28分 Topic 2 孤児ファイル問題 UPDATE / DELETE × Compaction 競合 28〜30分 質問・まとめ 参加者 知見共有・3つ Takeaway

Slide 3

Slide 3 text

写真が入ります 織田 繁 Sansan株式会社 技術本部 Sansan Engineering Unit 兼 Data Intelligence Engineering Unit Infrastructure Group Senior Software Engineer AWS Community Hero JAWS-UG ビッグデータ支部 運営 JAWS-UG 初心者支部 運営 AWS、IaC、Icebergを中心に発信をしています

Slide 4

Slide 4 text

Sansan株式会社 働き方を変える AXサービス 生産性を向上させ、企業 AI活用を最大化するデータベースとしても貢献できる 「働き方を変える AXサービス」を提供します。 データクオリティマネジメント 請求 名刺 管理 営業 契約 AI契約データベースが、利益を守る 「なくせる」をつくり、全社 働き方を変える 名刺アプリ 経理AXサービ ス 取引管理サービ ス 名刺管理から、収益を最大化する ビジネスデータベース 個人向け 法人向け 各サービス 活用で変わる働き方 情報を分析・活用しやすく データに基づいた判断ができる 情報 管理がしやすく すぐに共有できる 必要な情報を すぐに見つけられる

Slide 5

Slide 5 text

Iceberg 歴史と内部構造

Slide 6

Slide 6 text

DWHからApache Icebergまで 歴史

Slide 7

Slide 7 text

DWHとApache Iceberg 使い分け

Slide 8

Slide 8 text

- オープンフォーマット テーブル仕様で、 データレイクにデータウェアハウス的な信頼性をもたらす物 - ACID トランザクション : 大規模テーブルへ 安全な並行読み書き - スキーマ進化 : カラム 追加・削除・リネームをデータ再書き込みなしで実行 - タイムトラベル : スナップショット管理により過去時点 データを参照可能 - パーティション進化 : パーティション設計を後から変更でき、古いデータも正しく読める - エンジン非依存 : Spark / Trino / Flink / Hive など複数エンジンから同一テーブルを操作可能 - 隠しパーティション : クエリ側でパーティション列を意識せず パーティションプルーニングが効く Apache Iceberg 特徴

Slide 9

Slide 9 text

質問 Manifestに どんな情報があると 便利だと思いますか

Slide 10

Slide 10 text

Data file Data file Datafiles Metadata files Manifest file Manifest list Metadata file db.iceberg Catalog Data file Data file Manifest file

Slide 11

Slide 11 text

Data file Data file Datafiles Metadata files Manifest file Manifest list Metadata file db.iceberg Catalog Data file Data file Manifest file Data file path、行数、列毎 Null/Min/Max、Sort順、 Partition値 Manifest file path、追加・削除・既存 file数 及び record 数、Partition Null/Min/Max Table情報、Partition情報、Snapshot毎 情報(Manifest list Path、追加・削除・既存 file数 及び record数) Table名、Metadata file Path 行数、列毎 Null/Min/Max

Slide 12

Slide 12 text

質問 Apache Icebergへ Streaming書き込みする際 課題 何でしょうか

Slide 13

Slide 13 text

Topic 1 スモールファイル問題 Bronze層へ Streaming 書き込み

Slide 14

Slide 14 text

メダリオンアーキテクチャ

Slide 15

Slide 15 text

ストリーム・小バッチ書き込み 例 2KB 4KB data file 推奨サイズ 128〜512MBですが、大量 小ファイルが Bronze層に蓄積する 小さなファイル問題 S3 ListObjectが大量発生。Amazon Athena プランニングフェーズが遅くなる ソート順 劣化 メタデータ 統計情報を利用して、不要なデータをSkipすることが出来なくなる メタデータ肥大化 スナップショット数に比例してmanifest fileが増加し続ける 2KB 6KB 2KB 8KB 2KB 4KB 2KB 8KB 2KB ・・・ Bronze層で 何が起きるか

Slide 16

Slide 16 text

- ファイルサイズを定期的に取得し、ダッシュボードで可視化を行う - 推奨サイズ 128~512MB 何を継続的に計測する か - 小さなファイル問題

Slide 17

Slide 17 text

- Manifest file 統計にあるソートキー min/maxを確認する - 完全にソートされているなら0-9,10-19, 20-29, 30-39, 40-49 と重なりがない - 0-49, 0-49, 0-49, 0-49, 0-49 となっていると、スキップが出来ず全検索になる 何を継続的に計測する か – ソート順 劣化 Sortされている時 Sortされていない時

Slide 18

Slide 18 text

- Snapshot 古さをチェックする - どこまで古いsnapshotを残すか 要件次第で ある - Firehoseで数分単位にCommitするなら1-2日程度 - ETL処理で日次でCommitするなら1ヶ月保持でもOK - 設定されたsnapshot メンテナンスが停止してないことをWatchすることが必要 何を継続的に計測する か – メタデータ肥大化

Slide 19

Slide 19 text

解消手順(spark) STEP 1 rewrite_data_files 小さいデータファイルを大きいデー タファイルへ再書き込み - 小さい Parquet ファイルを統 合し、大きいファイルへ - 再Sort可能 STEP 2 rewrite_manifests 断片化した manifest file を統合 ・再編成 - 小さな manifest file を統合して 数を削減 - データファイル 触らず、メタ データ層だけを最適化 STEP 3 expire_snapshots expireされるsnapshotから み参照 されていたデータファイル削除 - 保持期間外 snapshotをメタ データから削除 - 排他的に参照されていたデー タファイルも物理削除される 小さなファイル問題、ソート順 劣化、メタデータ肥大化

Slide 20

Slide 20 text

Iceberg テーブル運用 3 層設計 Layer 1 計測(Metrics) 何を・どこから収集するか - 定期実行 また S3 Event Bridge実行で各種メタデータ を取得する - Amazon CloudWatch等で 可視化も可能 Layer 2 通知(Alerting) いつ・誰に知らせるか - CloudWatch Alarm でしきい 値管理 - WARNING / CRITICAL 2 段階で 通知管理 Layer 3 自動化(Automation) どう修復・予防するか - Amazon EventBridge Scheduler で定期実行 - Alert Triggerでメンテナンス 処理を実施 「見える化」で止めず、検知・通知・修復を一気通貫で設計する

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

質問 DELETE文を流せ 物理削除完了 と言えますか?

Slide 23

Slide 23 text

Topic 2 孤児ファイル問題 UPDATE / DELETE × Compaction 競合

Slide 24

Slide 24 text

メダリオンアーキテクチャ

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

orphan(孤児)を含めた、data file 物理削除に 以下手順が必要 - ① DELETE — 論理削除(delete file作成) - ② rewrite_data_files — MoR 場合、削除行を除いた実ファイルに書き直す - ③ expire_snapshots — 旧snapshotを削除し、紐づくdatafileを物理削除 - ④ remove_orphan_files — ど snapshotも参照しない孤児ファイルを物理削除 - デフォルトで 作成後3日間 保護設定があります - ⑤監視 remove_orphan_files をdry_run => trueで定期実行し、件数を取得する 孤児ファイルを含めた物理削除に必要な手順

Slide 27

Slide 27 text

質問・まとめ

Slide 28

Slide 28 text

まとめ 今日持ち帰っていただく 3つ こと 01 「見える化」を行い、検知から修復までを設計する 02 rewrite_data_files、rewrite_manifests、expire_snapshots 役割が違う 03 DELETEで消えても、物理削除されていない可能性がある orphan_files 確認・削除を行う

Slide 29

Slide 29 text

Sansan 技術本部 採用情報 https://media.sansan-engineering.com/

Slide 30

Slide 30 text

No content