データレイクの「見えない問題」を可視化する

■ イベント
AWS Summit Japan 2026
https://aws.amazon.com/jp/events/summits/

■登壇概要
タイトル：データレイクの「見えない問題」を可視化する
登壇者：Sansan株式会社 織田 繁

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

Transcript

1. Sansan株式会社 / 織田 繁 2026-06-26 データレイク 「見えない問題」を可視化する Amazon S3 + Apache Iceberg メダリオン アーキテクチャ オブザーバビリティ設計
2. TimeTable 0〜2分 オープニング 自己紹介・会社紹介 2〜15分 Iceberg 歴史と内部構造 Icebergが生まれた背景と内部構造を図で整理 （前提知識） 15〜25分 Topic 1 スモールファイル問題 metadataで現状把握 25〜28分 Topic 2 孤児ファイル問題 UPDATE / DELETE × Compaction 競合 28〜30分 質問・まとめ 参加者 知見共有・3つ Takeaway
3. 写真が入ります 織田 繁 Sansan株式会社 技術本部 Sansan Engineering Unit 兼 Data Intelligence Engineering Unit Infrastructure Group Senior Software Engineer AWS Community Hero JAWS-UG ビッグデータ支部 運営 JAWS-UG 初心者支部 運営 AWS、IaC、Icebergを中心に発信をしています
4. Sansan株式会社 働き方を変える AXサービス 生産性を向上させ、企業 AI活用を最大化するデータベースとしても貢献できる 「働き方を変える AXサービス」を提供します。 データクオリティマネジメント 請求 名刺 管理 営業 契約 AI契約データベースが、利益を守る 「なくせる」をつくり、全社 働き方を変える 名刺アプリ 経理AXサービ ス 取引管理サービ ス 名刺管理から、収益を最大化する ビジネスデータベース 個人向け 法人向け 各サービス 活用で変わる働き方 情報を分析・活用しやすく データに基づいた判断ができる 情報 管理がしやすく すぐに共有できる 必要な情報を すぐに見つけられる
5. Iceberg 歴史と内部構造
6. DWHからApache Icebergまで 歴史
7. DWHとApache Iceberg 使い分け
8. - オープンフォーマット テーブル仕様で、 データレイクにデータウェアハウス的な信頼性をもたらす物 - ACID トランザクション : 大規模テーブルへ 安全な並行読み書き - スキーマ進化 : カラム 追加・削除・リネームをデータ再書き込みなしで実行 - タイムトラベル : スナップショット管理により過去時点 データを参照可能 - パーティション進化 : パーティション設計を後から変更でき、古いデータも正しく読める - エンジン非依存 : Spark / Trino / Flink / Hive など複数エンジンから同一テーブルを操作可能 - 隠しパーティション : クエリ側でパーティション列を意識せず パーティションプルーニングが効く Apache Iceberg 特徴
9. 質問 Manifestに どんな情報があると 便利だと思いますか
10. Data file Data file Datafiles Metadata files Manifest file Manifest list Metadata file db.iceberg Catalog Data file Data file Manifest file
11. 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
12. 質問 Apache Icebergへ Streaming書き込みする際 課題 何でしょうか
13. Topic 1 スモールファイル問題 Bronze層へ Streaming 書き込み
14. メダリオンアーキテクチャ
15. ストリーム・小バッチ書き込み 例 2KB 4KB data file 推奨サイズ 128〜512MBですが、大量 小ファイルが Bronze層に蓄積する 小さなファイル問題 S3 ListObjectが大量発生。Amazon Athena プランニングフェーズが遅くなる ソート順 劣化 メタデータ 統計情報を利用して、不要なデータをSkipすることが出来なくなる メタデータ肥大化 スナップショット数に比例してmanifest fileが増加し続ける 2KB 6KB 2KB 8KB 2KB 4KB 2KB 8KB 2KB ・・・ Bronze層で 何が起きるか
16. - ファイルサイズを定期的に取得し、ダッシュボードで可視化を行う - 推奨サイズ 128～512MB 何を継続的に計測する か - 小さなファイル問題
17. - 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されていない時
18. - Snapshot 古さをチェックする - どこまで古いsnapshotを残すか 要件次第で ある - Firehoseで数分単位にCommitするなら1-2日程度 - ETL処理で日次でCommitするなら1ヶ月保持でもOK - 設定されたsnapshot メンテナンスが停止してないことをWatchすることが必要 何を継続的に計測する か – メタデータ肥大化
19. 解消手順（spark） STEP 1 rewrite_data_files 小さいデータファイルを大きいデー タファイルへ再書き込み - 小さい Parquet ファイルを統 合し、大きいファイルへ - 再Sort可能 STEP 2 rewrite_manifests 断片化した manifest file を統合 ・再編成 - 小さな manifest file を統合して 数を削減 - データファイル 触らず、メタ データ層だけを最適化 STEP 3 expire_snapshots expireされるsnapshotから み参照 されていたデータファイル削除 - 保持期間外 snapshotをメタ データから削除 - 排他的に参照されていたデー タファイルも物理削除される 小さなファイル問題、ソート順 劣化、メタデータ肥大化
20. 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でメンテナンス 処理を実施 「見える化」で止めず、検知・通知・修復を一気通貫で設計する
22. 質問 DELETE文を流せ 物理削除完了 と言えますか？
23. Topic 2 孤児ファイル問題 UPDATE / DELETE × Compaction 競合
24. メダリオンアーキテクチャ
26. 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で定期実行し、件数を取得する 孤児ファイルを含めた物理削除に必要な手順
27. 質問・まとめ
28. まとめ 今日持ち帰っていただく 3つ こと 01 「見える化」を行い、検知から修復までを設計する 02 rewrite_data_files、rewrite_manifests、expire_snapshots 役割が違う 03 DELETEで消えても、物理削除されていない可能性がある orphan_files 確認・削除を行う
29. Sansan 技術本部 採用情報 https://media.sansan-engineering.com/