Apache Iceberg The Definitive Guide 輪読会 - 2章 The Architecture of Apache Iceberg

Apache Iceberg: The Definitive Guide 輪読会の資料です。
２章 "The Architecture of Apache Iceberg "を担当しました。

Transcript

1. Chapter 2. The Architecture of Apache Iceberg べりんぐ 2024/7/15 Apache Iceberg: The Definitive Guide 輪読会
2. べりんぐ • Data Engineering Hobbyist • Twitter: @_Bassari • 技術ブログ書いてます https://bering.hatenadiary.com/ • 趣味の傍ら、Sotaro Hikitaとして Amazon Web Services で働いています 本発表は個人の見解であり、 所属企業を代表するものではありません
3. Chapter 2. The Architecture of Apache Iceberg • Apache Iceberg のTable Format としての アーキテクチャを学ぶ章 • Iceberg のエッセンスは Table Format としての仕様定義 – 「Apache Iceberg」という独立したソフトウェアが存在するわけ ではない – Iceberg Table Spec – Iceberg Projectは主要なクエリエンジン向けのライブラリを提供 – Table Format を理解すれば、Iceberg の仕組みがわかる • Iceberg Table Spec Version – Spec の前方互換性が失われるタイミングでインクリメント – 後方互換性は失われない – 現在の最新はversion 2 (version 3が開発中) – Definitive Guide の内容はv2準拠 • 各ソフトウェアがTable Specを何処まで / どのようにサポー トするかは各自の実装次第である点は注意が必要
4. The Data Layer • テーブルの実データを管理するレイヤー • 基本的にはData Layerの情報を元にクエリ結果を返却 – 一部メタデータレイヤのみで返せるクエリもある (e.g. max value for column X) • Data File と Delete File の 2 種 • 可用性、堅牢性、コスト効率、パフォーマンス、スケー ラビリティ、セキュリティに優れたストレージに配置 • ストレージによっては独自の連携機能がサポートされて いるものもある – e.g. spark.sql.catalog.my_catalog.s3.delete.tags.m y_key3=my_val3 spark.sql.catalog.my_catalog.s3.delete- enabled=false https://iceberg.apache.org/docs/1.5.1/aws/#s3-tags
5. Data Files • テーブルの実データを管理する • Apache Parquet (列指向), Apache ORC (列指向)、 Apache Avro(行指向)をサポート • 大規模データのOLAPには Parquet, Streaming データの ingestion には Avro を使用する、などの使い分け • ファイルフォーマットの抽象化によるfuture-proofの確保
6. Apache Parquet • 大規模なデータ処理に最適化された列指向データ フォーマット • Row Group / Column / Page単位でデータを管理 しており、特定のカラムに対するクエリが高速 • 符号化方式の工夫や、規則的にインクリメント& 連続して同じデータが格納されやすい性質上、 圧縮率が高い • スキーマや統計情報等のメタデータを保持してお り、効率的な操作が可能 – あるカラムの最小値が10で最大値が50の場合、値が 100以上のレコードを探すクエリは そのデータブロッ クをスキップする、など • カラムナフォーマットのきほん 〜データウェアハ ウスを支える技術〜
7. ちなみに https://www.youtube.com/ watch?v=axbmLqmxuo4 https://people.apache.org/committers-by-project.html
8. Copy on Write と Merge on Read ① • Iceberg ではテーブルの更新、削除 ＆ 読み込み方法として Merge on Read(MoR) とCopy on Write(CoW) を選択可能 ＊Apache Hudi の MoR, CoW とは仕組みが異なるので注意が必要 更新、削除 読み込み 更新、削除速度 読み込み速度 Copy on Write 更新、削除後の data fileを作成 data fileを 読み込み 遅い 速い Merge on Read delete fileを作成 delete file でdata fileをフィルタ 速い 遅い • オペレーションごとにMerge on Read と Copy on Write を選択可能 – write.delete.mode – write.update.mode – write.merge.mode
9. Delete Files: Positional Delete / Equality Delete positional delete equality delete • ファイルとファイル内の行インデック スの地点によって削除状態にある レコードを特定 • テーブルの特定のカラムの値で削除状 態にあるレコードを特定 • ユニークではない値を示す場合は1つの 複数のレコードがフィルタリング=削除 される場合もある • delete file はシーケンス番号によって 適用対象のdata file を特定する
10. Copy on Write と Merge on Read ② • Iceberg ではテーブルの更新、削除＆読み込み方法として Merge on Read(MoR) とCopy on Write(CoW) を選択可能 更新、削除 読み込み 更新、削除速度 読み込み速度 Copy on Write 更新、削除後の data fileを作成 data fileを 読み込み 遅い 速い Merge on Read delete fileを作成 delete file でdata fileをフィルタ 速い 遅い • Positional Delete と Equality Delete のどちらを使用するかは通常はエンジン側が自動 で決定する（ユーザが意識する必要はない） • MoR は更新、削除を高速化するが、読み取りにはオーバーヘッドが発生する – 定期的な compaction ジョブによるテーブルメンテナンスの設計が重要になる → 詳細は Chapter 4 「 Optimizing The Performance Of Iceberg Tables 」へ
11. The Metadata Layer • Metadata files, manifest lists, manifest filesの三層 • テーブルに対する全てのオペレーションを 追跡しており、それによって Time travel やSchema Evolutionなどが実現される • 各レイヤのファイルは json や avroなどで 構成される • Data file 同様に信頼性の高いストレージに 保存することが重要 ← metadata file ← manifest file ← manifest list
12. Manifest Files • 1 つ以上の data layer のファイルを管理する avro • 1 つ以上の data file と delete fileを管理する – （data file / delete file のどちらかのみ。クエリエン ジンは先にdelete fileを参照するため） • 管理対象のファイルパスに加えて、所属するパー ティションや統計情報を保持している – クエリエンジンはmanifest file を参照することでデー タ操作を最適化できる • Manifest file のサンプル
13. Iceberg における統計情報 (Hive Style との違い) • 統計情報の保存方法 – Iceberg: data file, manifest file, manifest list, puffin fileで分散管理 → 統計情報が分散管理されているため、テーブルサイズが大きくなっても統計情報の管理がボ トルネックになりにくい – Hive Style: テーブルやパーティション単位で保存 → 統計情報を保持するカタログ等がボトルネックになる場合がある • 統計情報の収集タイミング – Iceberg: データ書き込み時に、エンジンやツールが各データファイルのサブセットに対して統計 情報を収集・書き込み → データ書き込み時に統計情報を都度更新するため、コンスタントに最新の状態を維持できる – Hive Style:パーティション全体やテーブル全体を読み取って統計を計算 → 計算コストが高く、鮮度の高い統計情報の維持が難しい
14. Manifest Lists • Iceberg Table のある時点での snapshot を管理す る avro • 自身が管理する snapshot に紐づく全ての manifest file のメタデータを保持 • 主なフィールド – Snapshot に属する manifest file のパスのリスト – 各 manifest file が管理する data file が属するパー ティション – 各 manifest file が管理するパーティションの統計情 報(上限値と下限値等) • manifest list のサンプル
15. Metadata Files • Iceberg Table のある時点でのメタデータを管理する json • テーブルの最新＆歴代スキーマ、パーティション情 報、snapshot 情報が含まれる • Table が変更されるたびに新しい metadata file が作 成 → Iceberg Catalog によってポイントされる • metadata file のサンプル
16. Puffin Files • Data files, Manifest Files, Manifest Lists でカバーでき ない統計情報やインデックス構造を格納しておく ファイル形式 • Puffin Spec で定義 • Blob と呼ばれる単位でデータを格納する • 現時点でサポートされている Blob Type は Apache DataSketches 準拠の apache-datasketches- theta-v1(Number of Distinct Value) • Leveraging Iceberg Puffin Files to Accelerate Queries (Bodo.ai)
17. puffin-tools Puffin File の中身を探索したいときに便利 https://github.com/ebyhr/puffin-tools
18. NDVとは？ / 統計情報の重要性について • Number of Distinct Value (NDV):データセットやカラム内で重複を除いた一意の値の数 • クエリエンジンの Optimizer はテーブル 列の NDV を把握することで効果的な実行計画 を立案できる • 例えば… – Join 順序の選択 – 3 つ以上のテーブルを結合する場合に、各テーブルのカラムの NDV が把握できてい れば、join 時の計算量が最小化可能な join 順序を判断できる – Join 戦略の選択 – broadcast join: 片方のテーブルを全ノードへコピーして結合 – shuffle join: 両方のテーブルのデータを結合キーに基づき再分配して結合 – テーブル A とテーブル B を結合する際、テーブル A の join 対象のカラム NDVが小 さいことが分かっていれば broadcast join が有効と判断できる
19. NDV の課題と Theta Sketch による解決 • NDV を100% の精度で継続的に計算するためには、全てのユニーク値の記録が必要になり、 メモリ、ストレージ使用量が嵩みがち = O(n) Space Complexity →Apache DataSketches の Theta Sketch Framework は、テーブル全体のサブセットを元 に、統計的に有意な NDV の近似値を推定できる = O(1) Space Complexity • 計算時の Time Complexity はどちらも O(n) だが、 Theta Sketch の方が処理内容が 相対的に軽い • その他、Thea Sketch はデータセットを分割して並列処理し、後でマージしてNDVを計算 できるメリットも • Puffin File は Theta Sketch Framework の 計算に用いるデータをBlobとして格納する • クエリエンジンのサポートが課題 – OSS では現状 Trino しかサポートしてない？ – みんなでコントリビュートしよう！ https://datasketches.apache.org/docs/Theta/ThetaSketchFramework.html
20. Iceberg Catalog Namespace(テーブルの集合)の管理 – namespaceの作成、更新 – namespaceに属するtableの作成、削除、 リネーム、リスト Metadata fileをポイントして、 ACIDの前提となる楽観ロックを担保 • 最新、一つ前のmetadata_location, previous_metadata_locationをポイント • テーブルが変更される度にアトミックに更新 • Iceberg Catalog の一義的な役割はとてもシンプル であるため、実装の選択肢は多様 • Catalog 実装によっては付加的な機能を提供する ものもある(自動 Compaction など) • 最近はREST Catalog へ集約していく流れがある Apache Iceberg Catalog選択のポイント
21. Icebergの同時実行制御 Read • Catalogからmetadata_location(metadata pointer)をロードした時点のSnapshotを参照す るため、クエリ結果は変更の影響を受けない Write 1. 現在が更新されないことを前提に metadata layer, data layerを作成 2. 基にしたmetadata_locationとCatalogの metadata_locationを突合 1. 一致する場合はmetadata_locationを atomicに更新 2. 一致しない場合はabort / retry
22. Conclusion • 本章では、Apache Iceberg テーブルのアーキテク チャとフォーマットについて説明した • これらにより、Hive Table Format の課題を解決 し、データレイク上での ACID トランザクション などの機能を実現することができる • エンジンやツールは Iceberg Table Format を活用 してデータの効率的な読み書きを行うとともに、 タイムトラベルやスキーマ進化といったより高度 な機能を実現している • Chapter 3. Lifecycle of Write and Read Queries では、これらのエンジンやツールで実行されるク エリのライフサイクルについて説明する