データレイクの「見えない問題」を可視化する
by
SansanTech
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
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