Apache Iceberg The Definitive Guide 輪読会 - １章後半

SnowVillage で開催している Apache Iceberg: The Definitive Guide 輪読会の資料です。
１章 "Introduction to Apache Iceberg" の後半を担当しました。

Transcript

1. © 2015 - 2024 Nowcast Inc. Introduction to Apache Iceberg １章後半 2024/7/8 株式会社ナウキャスト 大野巧作　@Kevinrobot34 Apache Iceberg: The Definitive Guide 輪読会 1
2. © 2015 - 2024 Nowcast Inc. 2 1. Introduction to Apache Iceberg • Table Format とは一つのテーブルとしてデータセットのファイルを構造化する方法のこと • ユーザーから見ると、「このテーブルにはどんなデータがあるか？」に対する答えとして定義できる • Table Format の主な目的はテーブルを抽象化し、ユーザーやツールに対してテーブル内のデータを効率的に操作し やすくすること。 ◦ Table Format がない場合、オブジェクトストレージのファイルパスやファイルそのものを自分で管理し、 操作も自分で記述する必要があり大変 What Is a Table Format?
3. © 2015 - 2024 Nowcast Inc. 3 1. Introduction to Apache Iceberg • 2000年代はMapReduceの複雑なジョブを書いてパイプラインを作っていた時代だったらしく、パイプラインを開発 したりデータ分析できる人は限られていた • 2009年、Facebookはこの問題に対処するために Hive というフレームワークを作った ◦ Hive は SQL 文を MapReduce のジョブへと変換するフレームワーク ◦ これを実現するためにはHadoopストレージ上のどのデータがどのテーブルに対応するかを理解する必要があ り、 Hive table format と Hive metastore が生まれた ◦ 単に Hive と言った時に、Hiveのクエリエンジン・ Hive table format ・Hive metastore のそれぞれの場合が あるので要注意 Hive: The Original Table Format
4. © 2015 - 2024 Nowcast Inc. 4 1. Introduction to Apache Iceberg Hive table format のメリット • ディレクトリ単位でテーブルとみなし、そのサブディ レクトリはパーティションとなる ◦ Hive Metastore で管理 ◦ クエリの効率化 • File Format Agnostic ◦ 裏は csv でも csv.gz でも parquet でもいい • 特定のディレクトリ全体を Atomic swap すればユー ザーに影響なくパーティションの更新は可能 • デファクトスタンダードとなっている Hive: The Original Table Format Hive table format のデメリット・限界 • ファイルレベルの更新が非効率 ◦ ディレクトリ全体で partition を atomic swap する仕組みしかない ◦ 複数の partition を更新する仕組みはない • ディレクトリ内部のファイルのリストアップは重いた め、全体的にクエリが遅い • パーティションによる pruning はパーティションカ ラムでしかできない ◦ timestampのパーティションがあっても、従属す るカラムであるdatetimeではpruning不可 • テーブルの統計は非同期ジョブで取得されており、 最新の情報に基づいた最適化はできない • オブジェクトストレージの制約にしばられがち
5. © 2015 - 2024 Nowcast Inc. 5 1. Introduction to Apache Iceberg • Hive Table Format の限界は、テーブルをディレクトリベースで認識しており、 ファイルベースでないことが根本的な原因だと気づいた • モダンな Table Format である Apache Iceberg / Apache Hudi / Delta Lake などはどれもテーブルを ディレクトリではなく個別のファイルの集まりとして定義するアプローチをとっている ◦ 「このテーブルにはどんなデータがあるか？」という問いに対してより細かい個別のファイルレベルで答えら れる仕組みにすることで、様々なメリットが生まれた ▪ ACID Transaction のサポート ▪ 複数の writer がいても安全なトランザクションのサポート ▪ テーブルの統計やメタデータをよりうまく収集できるようになった ▪ → 残り Apache Iceberg ではこのあたりがどうなっているかをみていく Modern Data Lake Table Formats
6. © 2015 - 2024 Nowcast Inc. 6 1. Introduction to Apache Iceberg • Apache Iceberg は 2017 年に Netflix の社員によって作られた Table Format • Hive table format が直面していた課題（パフォーマンス、一貫性、その他諸々）の解決を目指して作られた • 2018年にオープンソースとなり Apache Foundation に寄贈された • 以下を達成することを念頭に置き開発が進められた ◦ Consistency ▪ 複数のパーティションに対する操作も、quick かつ atomic に行われるようにする ▪ ユーザーが inconsistency を観測しないような仕組みにする ◦ Performance ▪ ディレクトリのファイルリストアップは辞め、必要十分なファイルにのみアクセスすることで query plannning も実際の query もパフォーマンスが上がるような仕組みにする ◦ Easy to use ▪ テーブルの物理的な構成を知らなくても自然とパーティションなどの恩恵を享受できるような構成にする ◦ Evolvability ▪ テーブル全体を変更・上書きすることなく、スキーマやパーティションが変更可能な仕組みにする ◦ Scalability ▪ ペタバイトレベルのデータ処理が可能な構成にする What Is Apache Iceberg?
7. © 2015 - 2024 Nowcast Inc. 7 1. Introduction to Apache Iceberg Apache Iceberg ではテーブルのパーティション・ソート・スキーマ情報などを追従し、 メタデータツリーを利用してクエリの最適化を行う。 • Datafiles ◦ 実際のデータ。形式としては Parquet / ORC / Avro がサポートされている。 • Manifest file ◦ Datafiles の一覧（ファイルの場所、統計、などの情報を含む） • Manifest list ◦ 単一のスナップショットに対応するのが Manifest list ◦ Manifest file の一覧（統計情報を含む） • Metadata file ◦ テーブル構造を定義する情報（スキーマ、パーティション、 スナップショットの一覧）からなる • Catalog → ５章で詳細を見ます ◦ Hive Metastore と同様、 table の場所を追従する ▪ Hive : テーブル名とディレクトリの一覧のマップ ▪ Iceberg : テーブル名と対応する最新のMetadata file のマップ What Is Apache Iceberg? - Architecture
8. © 2015 - 2024 Nowcast Inc. 8 1. Introduction to Apache Iceberg • Consistency のところに対応する機能 • 複数の読み書きオペレーションが同時に走っても ACID な状態が保たれるようにしている ◦ 楽観的並行制御 (Optimistic Concurrency Control)は基本的にトランザクションはコンフリクトしないという 前提で、もしそうなった場合にのみロックを取得し操作を行うという、パフォーマンスを優先した並行制御 ◦ 悲観的並行制御 (Pessimistic Concurrency Control) の場合は常にロックを取得し、コンフリクトは確実に発 生しないが、その分パフォーマンスが下がる ◦ 現在、 Apache Iceberg でサポートされているのは楽観的並行制御のみ • ACID の保証はカタログによって実現される ◦ テーブルに対するあらゆる変更は 新しい Metadata file を生成する ◦ カタログが参照する Metadata file は Atomic に swap される Key Features of Apache Iceberg - ACID Transactions Tabular blog - Iceberg and Hudi ACID Guarantees より→
9. © 2015 - 2024 Nowcast Inc. 9 1. Introduction to Apache Iceberg • Consistency のところに対応する機能 • 複数の読み書きオペレーションが同時に走っても ACID な状態が保たれるようにしている ◦ 楽観的並行制御 (Optimistic Concurrency Control)は基本的にトランザクションはコンフリクトしないという 前提で、もしそうなった場合にのみロックを取得し操作を行うという、パフォーマンスを優先した並行制御 ◦ 悲観的並行制御 (Pessimistic Concurrency Control) の場合は常にロックを取得し、コンフリクトは確実に発 生しないが、その分パフォーマンスが下がる ◦ 現在、 Apache Iceberg でサポートされているのは楽観的並行制御のみ • ACID の保証はカタログによって実現される ◦ テーブルに対するあらゆる変更は 新しい Metadata file を生成する ◦ カタログが参照する Metadata file は Atomic に swap される Key Features of Apache Iceberg - ACID Transactions Tabular blog - Iceberg and Hudi ACID Guarantees より→
10. © 2015 - 2024 Nowcast Inc. 10 1. Introduction to Apache Iceberg • Evolvability / Peformance のところに対応する機能 • Icebergより前の Data Lake では Partition の設定を変更したい場合には、 テーブル全体を再生成が必要だった ◦ 例えばHiveであればディレクトリ構成を変更する必要がありデータを 全体的に移動したりして再編成する必要がある。 これは大規模なテーブルだとコストのかかる作業だった。 ◦ もしくは Partition はそのままにし、 パフォーマンスを犠牲にする必要があった • Iceberg では Partition に関する情報はメタデータツリーの中に 格納されており、 Datafiles は関係ない ◦ Partition の変更はメタデータを変更・再生成すれば良いだけであり、 早く安い処理ということになる。途中から変更とかもあり。 • 具体例： booking_table で Partition が month(date) から day(date) に変更 ◦ Query Plan では partition が変更される前の領域では month(date) が 変更された後の領域では day(date) が使われるようになっていることが 分かる。 Key Features of Apache Iceberg - Partition Evolution
11. © 2015 - 2024 Nowcast Inc. 11 1. Introduction to Apache Iceberg • Evolvability のところに対応する機能 • Icebergより前の Data Lake では Schema を変更（列の追加・削除、列名の変更、データ型の変更、etc）したい 場合には、テーブル全体を再生成が必要だった • Iceberg では柔軟に Schema を進化させていくことが可能な構成になっている ◦ Partition Evolution の話 + 必要に応じた Datafiles の変更でできる、という認識 • Partition Evolution の話と合わせ、 “in-place table evolution” と呼ばれていたりする Key Features of Apache Iceberg - Schema Evolution
12. © 2015 - 2024 Nowcast Inc. 12 1. Introduction to Apache Iceberg • Easy to use のところに対応する機能 • Hive の時代では Partition を用いた pruning を利用するためには、物理的な設定を知っている必要があった ◦ あるテーブルに4つの時刻・日付に関するカラムがあるとする ▪ event_timestamp / event_year / event_month / event_day ◦ Partition は event_year / event_month / event_day の３つで設定されている ▪ 以下のようなディレクトリ・パスでデータが保存されているイメージ ▪ s3://bucket/log_table/event_year=2024/event_month=07/event_day=08/20240708_HHMM_log.csv.gz ◦ このような設定だと、以下のように event_timestamp で filter しても pruning はされない ▪ event_timestamp >= DATE_SUB(CURRENT_DATE, INTERVAL 90 DAY) ◦ Partition で pruning するには直接 event_year / event_month / event_day を利用する必要がある • Iceberg での Partition の取り扱いの工夫によりこのような問題は解決された ◦ Iceberg の Partition では2つの情報が保持されていて、後者が特によしなにやってくれるらしい ▪ 物理的な partition に使うカラム ▪ オプショナルな transformation の情報（bucket/truncate/year/month/day） • → 物理的な設定を知らなくても、直感的にクエリしたら Partition の恩恵を受けられるように！ Key Features of Apache Iceberg - Hidden partitioning CREATE TABLE logs ( level string, event_ts timestamptz, message string ) PARTITIONED BY ( level, days(event_ts) )
13. © 2015 - 2024 Nowcast Inc. 13 1. Introduction to Apache Iceberg • Performance のところに対応する機能 • テーブルの行レベルの更新処理は２つのやり方がある ◦ COW: copy-on-write ▪ ある Datafile への変更がたった一行であっても、変更を反映した新しい Datafile として保存する ◦ MOR: merge-on-read ▪ ある Datafile への変更に対応する情報を含む新しいファイルを生成する ▪ 読み込み時にこの変更が反映される感じ ▪ 大量の更新と削除のワークロードを高速化することが可能 ◦ → この辺りは３章とかにもう少し詳しい話があるはず Key Features of Apache Iceberg - Row-level table operations
14. © 2015 - 2024 Nowcast Inc. 14 1. Introduction to Apache Iceberg • Performance / Easy to use のところに対応する機能 • Iceberg では immutable なスナップショットを提供している ◦ スナップショットが git のコミットのようになっているイメージ ◦ テーブルのヒストリカルな断面にアクセス可能 ▪ 特定の時点でのテーブルに対するクエリは Time Travel と呼ばれる ▪ 過去断面を複製しておいておくというようなことをする必要がなく、コスト的に嬉しい ◦ git と同様、現在の状態を revert して以前の状態を復元する (Rollback) ことも容易 ▪ 間違った操作をしても簡単に元に戻せる Key Features of Apache Iceberg - Time travel / Version Rollback
15. © 2015 - 2024 Nowcast Inc. 15 1. Introduction to Apache Iceberg • このチャプターではデータエンジニアリングの歴史を振り返りながら、 Hive Table Format の課題を克服するため に Apache Iceberg などのモダンな Table Format が登場した経緯を確認した • Apache Iceberg はファイルの物理的な構造からメタデータツリーを切り離した ディレクトリ単位でテーブルを認識していた Hive から、 個別のファイルの集合としてテーブルを認識するように進化した ◦ これにより現代的なデータレイクで求められる様々な機能が実現できるようになった ▪ ACID Transactions ▪ Schema Evolution ▪ Partition Evolution ▪ Time Travel / Version Rollback ▪ … • Apache Iceberg プロジェクトは Open Table Format として仕様を策定し、関連するライブラリを整備すること で、モダンなデータレイクで必要なものを提供している • ２章では Apache Iceberg のアーキテクチャについて deep dive していく Conclusion