Apache Iceberg The Definitive Guide 輪読会 - ４章前半

SnowVillage で開催している Apache Iceberg: The Definitive Guide 輪読会の資料です。
４章 "Optimizing the Performance of Iceberg Tables" の後半を担当しました。
主に Compaction の話をしています。

Transcript

1. © 2015 - 2024 Nowcast Inc. Optimizing the Performance of Iceberg Tables ４章前半 2024/7/29 株式会社ナウキャスト 大野巧作　@Kevinrobot34 Apache Iceberg: The Definitive Guide 輪読会 1
2. © 2015 - 2024 Nowcast Inc. 2 4. Optimizing the Performance of Iceberg Tables • ３章までで見てきたように Apache Iceberg table はメタデータレイヤーの情報をうまく利用し、 クエリの高速化に役立てているが、これはクエリ最適化の第一歩に過ぎない • 実際には以下のようなさまざまな手法が用意されており、４章ではこれらを一つ一つ確認していく ◦ Compaction ◦ Data sorting (Clustering) ▪ Sorting ▪ Z-ordering ◦ Table partitioning ◦ Row-level update handling ◦ Metrics collection ◦ … • 最適化可能な場所を特定するためには適切なツールで堅牢な監視を実装するのが重要 ◦ 例えば Iceberg の metadata tables を利用するなど ◦ こういった話は 10章: Apache Iceberg in Production でカバーされる Introduction
3. © 2015 - 2024 Nowcast Inc. 3 4. Optimizing the Performance of Iceberg Tables • クエリ実行に必要なステップ数を削減し処理時間を短くしたり、スキャンすべきデータを減らすことができると、 多くのサービスの利用料も基本的に下がる • Iceberg テーブルにクエリすると、様々なファイルを開き、データをスキャンし、そしてファイルを閉じる、という 操作を何度も行うことになる。つまりデータをスキャンすべきファイルの数を減らすことが最適化につながる。 • Read 時のコストを抑えるためには、程よいサイズのファイルに分割して置いておくのが大事 ◦ 小さいファイルが多数存在する場合 ▪ ストリーミング処理、Sparkによる書き込み処理（メモリ以下のサイズのファイルを作る）などが、 小さいファイルを多数作成することが多い ▪ ファイルを開き、閉じるという操作が多くなってしまうため効率が悪い ▪ データファイルが小さいと読むべきメタデータファイルの数も増えてしまうため効率が悪い ◦ 大きいファイルが少数存在する場合 ▪ ファイル開閉の操作は減るが、クエリに不必要なデータをスキャンすることもある • この問題を解決する一つの方法が Compaction という処理 Read 時のコスト
4. © 2015 - 2024 Nowcast Inc. 4 4. Optimizing the Performance of Iceberg Tables • 多数の小さいファイルを少数の大きいファイルに置き換える処理のこと • Compaction は新しくファイルを書き換える機会なため、ただファイルサイズを変更するだけでなく、 以下のようなデータの処理を行う良い機会でもある ◦ 再パーティション化 ◦ 再クラスタ化 ◦ Delete files のマージ Compaction
5. © 2015 - 2024 Nowcast Inc. 5 4. Optimizing the Performance of Iceberg Tables • 多数の小さいファイルを少数の大きいファイルに置き換える処理のこと • Compaction は新しくファイルを書き換える機会なため、ただファイルサイズを変更するだけでなく、 以下のようなデータの処理を行う良い機会でもある ◦ 再パーティション化 ◦ 再クラスタ化 ◦ Delete files のマージ Compaction https://www.dremio.com/blog/compaction-in-apache-iceberg-fine-tuning-your-iceberg-tables-data-files/ より
6. © 2015 - 2024 Nowcast Inc. 6 4. Optimizing the Performance of Iceberg Tables • ファイルの再編成をする前に、適宜データをソートしておくとクラスタリングも合わせてできることになるが、 これを Compaction Strategy という ◦ Binpack (ファイルの書き換えだけする) か Sort (事前にソートしてからファイルの書き換え) のどちらか ◦ Sort の仕方を Sort Order として指定できる ▪ 1つ以上のカラムで普通にソート or z-order • これらを踏まえて Binpack / Sort / z-order の３つの Compaction Strategy があるみたいな書き方になってる Compaction Strategy Strategy 概要 メリット デメリット Binpack ファイルの書き換えだけする グローバルなソートはしない （各タスク内部でローカルなソートはする） 最も高速 データはクラスタ化されない Sort １つ以上のカラムに基づきグローバルに ソートした上でファイルの書き換えをする 絞り込みに利用されるカラムでソート しておくと、そのようなクエリを高速化 できる Binpack よりは時間がかかる z-order 複数のカラムを z-order でソートした上で ファイルの書き換えをする 複数列に対する絞り込みが多い場合 に、そのようなクエリを高速化できる Binpack よりは時間がかかる また Sort よりも処理が重い
7. © 2015 - 2024 Nowcast Inc. 7 4. Optimizing the Performance of Iceberg Tables rewriteDataFiles プロシージャーを実行すると 以下の流れで Compaction が実行される • （Strategy が Sort の場合）グローバルにデータを ソートしておく • File group を用意する ◦ File group はファイルの集まりで、 単一のジョブが Compaction を行う単位 • File group ごとにジョブを割り当て、それぞれファイルを 読み込み、より大きなファイルとして出力する • 新しいデータファイルに対応するメタデータファイルを 適宜生成する Compaction の流れ https://docs.aws.amazon.com/prescriptive-guidance/latest/apache-iceberg-on-aws/best-practices-compaction.html より
8. © 2015 - 2024 Nowcast Inc. 8 4. Optimizing the Performance of Iceberg Tables • Sort / Clustering はデータを事前に指定した カラムでソートしておくことで、似た値を持つ レコードが近くに配置されるようにしておく 処理のこと • これにより、ソートに利用したカラムで絞り込む ようなクエリの場合には読み込む必要がある ファイルの数が少なくなり高速化が見込める Sort / Clustering https://www.dremio.com/blog/compaction-in-apache-iceberg-fine-tuning-your-iceberg-tables-data-files/ より
9. © 2015 - 2024 Nowcast Inc. 9 4. Optimizing the Performance of Iceberg Tables • Sort / Clustering はデータを事前に指定した カラムでソートしておくことで、似た値を持つ レコードが近くに配置されるようにしておく 処理のこと • これにより、ソートに利用したカラムで絞り込む ようなクエリの場合には読み込む必要がある ファイルの数が少なくなり高速化が見込める Sort / Clustering https://www.dremio.com/blog/compaction-in-apache-iceberg-fine-tuning-your-iceberg-tables-data-files/ より
10. © 2015 - 2024 Nowcast Inc. 10 4. Optimizing the Performance of Iceberg Tables • データが追加されたら、再度クラスタリングし直す必要がある ◦ 後述の定期自動Compactionなどを考える必要がある • この Sort / Clustering の恩恵を受けるためには、よく実行されるクエリを理解し、 対応するカラムでSortしておくことが重要となる • 複数カラムでソートしても、最初のカラム以外では pruning の効果は見込みにくい ◦ EmpName と EmpSal でソートした例 ◦ EmpName はファイルごとに程よく散らばっているが、 EmpSal の範囲は各ファイルで同じになってしまっている ◦ 複数のカラムでフィルターする必要がある場合にはソートを z-order で 行うと良い Sort / Clustering の注意点 https://www.dremio.com/blog/how-z-ordering-in-apache-iceberg-helps-improve-performance/ より
11. © 2015 - 2024 Nowcast Inc. 11 4. Optimizing the Performance of Iceberg Tables • クラスタリングのポイントは似たデータを近い場所（同じファイル）に配置しておくこと • 相関がないような複数のカラムで普通にソートしても、最初のカラム以外は散らばってしまう • 2つのカラムでクラスタリングすること考えた時に、 普通のソートと z order によるソートを比べると、 二次元平面で見た時に z order によるソートの方が 平面内で近い点を順番に通ることがわかる • これにより、２つのカラムでフィルタリングしても どちらでも効率よく pruning ができるようになる z order での sort https://medium.com/@nishant.chandra/z-order-indexing-for-efficient-queries-in-data-lake-48eceaeb2320 より
12. © 2015 - 2024 Nowcast Inc. 12 4. Optimizing the Performance of Iceberg Tables • クラスタリングのポイントは似たデータを近い場所（同じファイル）に配置しておくこと • 相関がないような複数のカラムで普通にソートしても、最初のカラム以外は散らばってしまう • 2つのカラムでクラスタリングすること考えた時に、 普通のソートと z order によるソートを比べると、 二次元平面で見た時に z order によるソートの方が 平面内で近い点を順番に通ることがわかる • これにより、２つのカラムでフィルタリングしても どちらでも効率よく pruning ができるようになる z order での sort https://www.waitingforcode.com/delta-lake/table-file-formats-z-order-compaction-delta-lake/read より
13. © 2015 - 2024 Nowcast Inc. 13 4. Optimizing the Performance of Iceberg Tables 適切に Compaction を実行することでパフォーマンスが良くなるが、手動でやっていると大変。 自動で定期実行することが大事になるが、その選択肢は大きく分けて二つある。 • 自動で定期実行する仕組みを作る ◦ タスクオーケストレーションツールを利用する ▪ Ingestion job が終わった後などの適切なタイミングに定期的に Compaction を行うように スケジューリングしておくと良い ▪ Airflow / Dagster / Prefect / Argo / Luigi などから、 Spark や Dremio といったエンジンに対し 適切なクエリを定期的に投げる ◦ データロードをトリガーとして Compaction を実行する ▪ S3 の PutObject をトリガーに Compaction ジョブを起動するとか？ ◦ Cron で定期的に Compaction をするように設定 • カタログサービスのマネージドな機能を利用し Compaction を自動的に定期実行する ◦ 自動テーブルメンテナンス機能として、 Compaction を定期的に実行してくれるカタログも存在する ◦ Dremio arctic や Tabular 、Snowflake がその代表例 ▪ https://docs.snowflake.com/en/user-guide/tables-iceberg#use-snowflake-as-the-iceberg-catalog Compaction の自動実行
14. © 2015 - 2024 Nowcast Inc. 14 4. Optimizing the Performance of Iceberg Tables • Compaction は現在のパーティションの設定に基づき新しいファイルを生成するため、対象の元データが古いパー ティション分割されていたデータファイルだった場合、新しいパーティション分割方法に変わってしまう • Partial Progress ◦ 全体の処理が終わっていなくても、特定のファイルグループに関する処理が終わり次第コミットしておくこと ◦ メリット ▪ Compaction が完了した分のデータを早期に利用できるようにすることで、 早いうちからクエリの最適化に役立つ ▪ すでに処理が終わったジョブのメモリを解放することで OoM を防ぐのに役立つ ◦ デメリット ▪ コミットが増えるとそれに伴いメタデータが増えるため、ストレージを圧迫する ◦ partial progress に関するオプションをうまく使い利用すると便利 Compaction に関する細かいポイント
15. © 2015 - 2024 Nowcast Inc. 15 4. Optimizing the Performance of Iceberg Tables • bering さんの「Apache Iceberg ハンズオン」の repo の環境でサクッと試すのが楽 • https://github.com/lawofcycles/apache-iceberg-101-ja 実際に Compaction を試す環境用意
16. © 2015 - 2024 Nowcast Inc. 16 4. Optimizing the Performance of Iceberg Tables テスト用の DB / Table を作る insertした行ごとに ファイルが作成されている
17. © 2015 - 2024 Nowcast Inc. 17 4. Optimizing the Performance of Iceberg Tables Compaction を実行してみる Compactionされて、 新しいデータファイルが一つできてる • rewrite_data_files プロシージャで実行可能
18. © 2015 - 2024 Nowcast Inc. 18 4. Optimizing the Performance of Iceberg Tables Compaction を実行してみる rewrite_data_files には様々なオプションがある。 詳細は https://iceberg.apache.org/docs/1.5.1/spark-procedures/#rewrite_data_files • 引数 ◦ table ： Compactionの対象テーブル ◦ strategy ： Compaction strategy で binpack (default) か sort ◦ sort_order ： Strategy が sort の際に、ソートの仕方を指定する。 　 普通のソートであれば “ColumnName SortDirection NullOrder” を対象列分、 　 z-order であれば “zorder(c1, c2, c3)” と指定する • オプション ◦ target-file-size-bytes ： コンパクション後のファイルサイズ、デフォルトは512MB ◦ max-concurrent-file-group-rewrites ： コンパクションで同時並列処理するファイルグループの数の上限 ◦ max-file-group-size-bytes ： 単一ファイルグループの総データ量の上限、デフォルトは100GB ◦ partial-progress-enabled ： partial progress を有効化するか ◦ partial-progress-max-commits ： partial progress 有効時に、許可する最大コミット数 ◦ rewrite-job-order ： ファイルグループの書き込み順序
19. © 2015 - 2024 Nowcast Inc. 19 4. Optimizing the Performance of Iceberg Tables ４章前半まとめ • Iceberg において最適化手法は様々なものがある • 代表的な手法である Compaction について確認してきた • Compaction にも strategy がいくつかある ◦ binpack / sort / z-order ◦ sort や z-order を選択することでデータをクラスタリングすることができ、更なる最適化を見込める • sort や z-order は強力だが銀の弾丸ではなく、最適化対象のクエリをよく確認し、 どの列でソートしておくか考えておくことが重要 • Compaction は定期的に実行する必要があり、オーケストレーションツールで定期実行するか、 一部の Catalog ではネイティブに Compaction を実行しておく機能を提供していたりするので それを利用すると良い • 後半では Compaction 以外の様々な手法について確認していく
20. © 2015 - 2024 Nowcast Inc. 20 4. Optimizing the Performance of Iceberg Tables • https://docs.aws.amazon.com/prescriptive-guidance/latest/apache-iceberg-on-aws/best-practices-compaction.html • https://tabular.io/apache-iceberg-cookbook/data-operations-compaction/ • https://www.dremio.com/blog/apache-iceberg-101-your-guide-to-learning-apache-iceberg-concepts-and-practices/ • https://www.dremio.com/blog/compaction-in-apache-iceberg-fine-tuning-your-iceberg-tables-data-files/ • https://www.dremio.com/blog/maintaining-iceberg-tables-compaction-expiring-snapshots-and-more/ • https://www.dremio.com/blog/how-z-ordering-in-apache-iceberg-helps-improve-performance/ • https://www.linkedin.com/pulse/clustering-vs-partitioning-your-apache-iceberg-tables-alex-merced-oedde/ • https://medium.com/@nishant.chandra/z-order-indexing-for-efficient-queries-in-data-lake-48eceaeb2320 • https://www.waitingforcode.com/delta-lake/table-file-formats-z-order-compaction-delta-lake/read • https://www.youtube.com/watch?v=4bOCDP-rhuM References