Apache Iceberg Catalog選択のポイント

OTFSG Tokyo Meetup #2の登壇資料です

Transcript

1. Apache Iceberg Catalog 選択のポイント べりんぐ 2024/3/1
2. べりんぐ • Data Engineering Hobbyist • Twitter: @_Bassari • 技術ブログ書いてます(データ周り多め) – https://bering.hatenadiary.com/
3. (ごく簡単に)Apache Icebergとは？ • 2017年にNetflixが開発 • Serializable isolation (ACID) • ファイル、パーティションが増えても オペレーションはO(1) • Time Travel • full schema / partition evolution • Hidden Partitioning • copy-on-write / merge-on-read org.apache.iceberg.catalog.Catalog Hive Style Formatの課題を解決するために登場した、 データレイクに最適化されたOpen Table Formatの一種 Iceberg Table Spec https://iceberg.apache.org/spec/
4. Iceberg のアーキテクチャ概要 iceberg Catalog • namespaceに属するテーブルとmeta data fileを管理 • meta data fileの更新を管理 • meta data fileをポイント metadata Layer Metadata file •テーブルとスナップショット履歴情報 Manifest list •あるスナップショットを構成するmanifest fileのリスト Manifest file •実データのパスと統計情報 data Layer Data file •実データ(avro / orc / parquet)
5. Iceberg Catalog の役割 Namespace(テーブルの集合)の管理 • namespaceの作成、更新 • namespaceに属するtableの作成、削除、 リネーム、リスト Metadata fileをポイントして、 ACIDの前提となる楽観ロックを担保 • 最新、一つ前のmetadata_location, previous_metadata_locationをポイント • テーブルが変更される度にアトミックに更新 org.apache.iceberg.catalog.Catalog ü メタデータ構造の根本を担当 ü ACID特性の立役者 org.apache.iceberg.catalog.Catalog
6. Icebergの同時実行制御 Read • Catalogからmetadata_location(metadata pointer)をロードした時点のSnapshotを参照す るため、クエリ結果は変更の影響を受けない Write 1. 現在のlocationが更新されないことを前提に metadata layer, data layerを作成 2. 基にしたmetadata_locationとCatalogの metadata_locationを突合 1. 一致する場合はmetadata_locationを atomicに更新 2. 一致しない場合はabort / retry https://docs.google.com/document/d/1UxXifU8iqP_byaW4E2RuKZx1nobxmAvc5urVcWas1B8/edit
7. インターフェース仕様を満たす範囲で多様なオプションから選択可能 Catalog 実装の選択肢 主な選択肢 • Hadoop Catalog • Hive Catalog • JDBC Catalog • Nessie Catalog • REST Catalog ＊SaaS / Managed Service系 Tabular, Dremio, GCP Iceberg BigLake, AWS Glue, Databricks Delta Uniform, Snowflake Iceberg Table…etc 主な検討ポイント • 必要なコンポーネント(依存関係) • 派生的な機能の有無 • エンジン / ツールのサポート状況 • 非機能面 • Managed / Self hosted
8. ü 任意のファイルシステム/オブジェクトストレージ上で カタログ情報とMetadata Layerを管理する(*) ＊カタログとmetadata layerがセットなのはHadoop Catalogのみ ü Iceberg環境にクイックな構築が可能 ü Production用途で使ってはいけない Hadoop Catalog Pros • カタログ専用のプロセス無しで簡単に利用可能 (Hadoopとの依存関係はない) Cons 様々な制約があり、Productionでの利用は推奨されない • ACIDを保証するにはストレージがatomic renameをサポートする必要がある • 全メタデータを特定のディレクトリ/パス配下に保持しなければならない • Namespaceやテーブルが多数ある場合に性能問題の懸念がある • 一部のオペレーションがサポートされない org.apache.iceberg.hadoop.HadoopCatalog Client File System / Object Storage
9. Hadoop Catalog ü Iceberg環境にクイックな構築が可能 ü Production用途で使ってはいけない 任意のファイルシステム/オブジェクトストレージ上で カタログ情報とMetadata Layerを管理する(*) ＊カタログとmetadata layerがセットなのはHadoop Catalogのみ • カタログ専用のプロセス無しで利用可能 (Hadoopとの依存関係はない) • ACIDを保証するには基盤となるファイルシステムがAtomic Renameをサポートする 必要がある 様々な制約があり、Productionでの利用は推奨されない • 全メタデータを特定のディレクトリ/パス配下に保持しなければならない • Namespaceやテーブルが多数ある場合に性能問題の懸念がある • 一部のオペレーションがサポートされない org.apache.iceberg.hadoop.HadoopCatalog https://medium.com/@ajanthabhat/how-not-to-use-apache- iceberg-046ae7e7c884
10. ü Hive Metastoreを拡張してIceberg Catalogとする ü Hive Metastoreのlocation table propertyにmetadata fileのパスをポイント Hive Catalog org.apache.iceberg.hive.HiveCatalog Pros • 既存のHive Metastore環境がある場合は導入が容易 • 様々なエンジン、ツールとの互換性 • Hive Tableと混在可能で移行しやすい Cons • Hive Metastoreを運用する必要がある "Parameters": { "metadata_location":“hoge/table_name/metadata/xxxx.metadata.json", "previous_metadata_location": “moge/ table_name /metadata/yyyy.metadata.json", “table_type": "ICEBERG" }, Client Hive Metastore
11. ü JDBC compliantなDBのテーブルとしてCatalogを管理する JDBC Catalog org.apache.iceberg.jdbc.JdbcCatalog Pros • PostgreSQL, MySQLなど親しみやすいスタックで導入できる • 非機能に関してDB側の仕組みをレバレッジできる Cons • エンジン/ツールにJDBC driverをパッケージする必要がある • JDBC Catalog実装のSQLがhard codingされているため使えるDBが限られる CREATE TABLE ICEBRG_TABLES ( CATALOG_NAME VARCHAR(255) NOT NULL, TABLE_NAMESPACE VARCHAR(255) NOT NULL, TABLE_NAME VARCHAR(255) NOT NULL, METADATA_LOCATION VARCHAR(1000), PREVIOUS_METADATA_LOCATION VARCHAR(1000), PRIMARY KEY (CATALOG_NAME, TABLE_NAMESPACE, TABLE_NAME)); Client JDBC compliant DB
12. ü metadataLocationにmetadata fileのパスをポイント ü Multi-table / Multi-statementトランザクションをサポート * Iceberg on Nessieに関しては『Apache Iceberg: The Definitive Guide』で詳しく解説されていそう Nessie Catalog org.apache.iceberg.nessie.NessieCatalog Pros • Multi-table / Multi-statementトランザクションをサポート Cons • Nessieを運用する必要がある • Nessieをサポートするエンジン/ツールが相対的に限られる (Spark, Flink, Dremio Sonar, Presto, Trino, PyIceberg) Client Nessie
13. ü Iceberg REST Open API specificationに準拠して任意のカタログ実装のインター フェースをRESTで提供する方式 ü バックエンドの特定の実装を限定するものではない ü Iceberg Catalogの今後の発展の重要な役割を担う(後述) !!! REST Catalogのオフィシャルなサーバサイド実装は存在していない ü Tabular社がREST Catalogのサンプル実装を公開している https://tabular.io/blog/rest-catalog-docker/ REST Catalog org.apache.iceberg.rest.RESTCatalog Pros • 相対的にデプロイの依存関係が少ない • バックエンドに多様な実装を検討可能 • 認証系や性能面の最適化など様々な機能拡張の余地がある Cons • 独自のREST Catalogを実装、運用する必要がある • REST Catalogをサポートするエンジン/ツールが相対的に限られる iceberg/open-api/rest-catalog-open-api.yaml Client REST Server Any Catalog
14. ü Icebergのコアな開発メンバーたち / Tabularには、カタログの多様化により 周辺系の互換性やサポートが困難になっている課題感がある ü 一次的な窓口をREST Catalogに集約することで、Catalogの多様性を維持しつつ互換 性の問題を解決しようとしている(Hive Thriftのイメージ) REST Catalogの重要性 org.apache.iceberg.rest.RESTCatalog 新しい言語やエンジンは、ひとつの実装であらゆるカタログをサポートできる 派生的な機能の実現 • サーバーサイドでの競合の解決やリトライ、metadataのキャッシュなどが可能 • クライアントとバックエンド間でのアクセスコントロール • REST Catalog専用の派生機能の開発が進んでいる • change based commit, lazy snapshot loading, multi table commit など iceberg/open-api/rest-catalog-open-api.yaml Iceberg Community Sync - Feb 14 2024 • Iceberg Catalogの今後の展望についての議論 • https://www.youtube.com/watch?v=uAQVGd5zV4I&t=1585s Iceberg Catalog as a Service • REST Catalogの利点、移行戦略、性能面の最適化 についての紹介 • https://www.youtube.com/watch?v=ms3as-0yr5k
15. ü 複数のTableへの複数の操作の整合性を管理できるようにする ü SNAPSHOT, SERIALIZABLEの両方をサポート(*) ü REST Catalog以外でのサポートは予定されていない * SERIALIZABLEの定義がやや特殊。Design Doc参照 Multi-Table Transaction(開発中) org.apache.iceberg.rest.RESTCatalog • 現状はTransaction APIでテーブルレベルの整合性を管理 • org.apache.iceberg.Transactions • 「CatalogTransaction」を導入してCatalogがMulti-Table Transactionを確保する iceberg/open-api/rest-catalog-open-api.yaml • Design Doc: Multi-Table Transactions in Iceberg • https://docs.google.com/document/d/1UxXifU8iqP_byaW4E2RuKZx1 nobxmAvc5urVcWas1B8/edit?tab=t.0#heading=h.6sa1rpsxiuke • 開発状況(ほぼ出来てそう) • https://github.com/apache/iceberg/projects/30#card-89728195
16. Table one = catalog.loadTable(“first“); Table two = catalog.loadTable(“second“); Table three = catalog.loadTable(“third“); // create a new catalog TX CatalogTransaction catalogTx = catalog.createTransaction(“SNAPSHOT“); // use Catalog API to load a table and perform changes Catalog txCatalog = catalogTx.asCatalog(); // table metadata is only updated within the catalog TX but not visible outside of it txCatalog.loadTable(“first“).newFastAppend().appendFile(“FILE_A“).appendFile(“FILE_B“).commit(); txCatalog.loadTable(“second“).newDelete().deleteFile(“FILE_C“).commit(); txCatalog.loadTable(“second“).newFastAppend().appendFile(“FILE_B“).appendFile(“FILE_C“).commit(); txCatalog.loadTable(“third“).newDelete().deleteFile(“FILE_A“).commit(); txCatalog.loadTable(“third“).newAppend().appendFile(“FILE_D“).commit(); // before committing the catalog TX, catalog.loadTable(X) should still see the original state catalogTx.commitTransaction(); // now catalog.loadTable(X) should see all changes that have been done above こんな感じのことが出来るようになる
17. REST Catalog/Icebergおすすめ実験環境 org.apache.iceberg.rest.RESTCatalog iceberg/open-api/rest-catalog-open-api.yaml https://github.com/tabular-io/docker-spark-iceberg REST Catalog, Spark, MinIO(オブジェクトストレージ), Jupyter環境を簡単に構築 色々な機能を試せるナイスなNotebook MinIOのUIからメタデータの動きを観察
18. ü Hive, Nessie, REST catalogなどのマネージド版として提供される ü 多様な選択肢が存在 Tabular, Dremio, GCP Iceberg BigLake, AWS Glue, Databricks Delta Uniform, Snowflake Iceberg Table…etc ü カタログの非機能の大部分をサービスプロバイダが担ってくれる ü メタデータの自動コンパクションなど、派生的な機能をサポートすることが多い ü アクセスコントロールなど、 サービスプロバイダのエコシステムと連携できる場合が多い ※ SaaS / Managed Service系 REST Catalogが主流化 / 専用機能が実装されていったらどうなるんだろう…? • HiveやNessieベースの既存マネージドカタログとどう統合する？ • REST Catalogの裏にマネージドなCatalogが存在する形になる？ • そのREST Catalogは誰が提供する？ • REST Catalogとマネージドカタログの間の機能分担はどうなる？
19. まとめ • Iceberg CatalogはIcebergのメタデータ管理、ACIDサポートの 根幹を担うコンポーネント • Catalog実装の選択肢は多様で、以下を踏まえて選ぶ • 必要なコンポーネント(依存関係) • 派生的な機能の有無 • エンジン / ツールのサポート状況 • 非機能面 • Managed / Self hosted • 今後はREST Catalogがメインになり、 その裏で色々なCatalog実装を選んでいく形になりそう
20. その他参考リンク • What’s New in Apache Iceberg • Ryan Blueの発表でREST CatalogやMulti-table Transactionなどに触れられている • https://www.dremio.com/subsurface/live/live2023/session/whats-new-in-apache- iceberg/ • IcebergのIsolation levelを決めるディスカッション • https://drive.google.com/file/d/1MICV3d8Xa1c17WI6qU_Nni1pS_fJQBAG/view • Catalogs and the REST catalog • https://tabular.io/apache-iceberg-cookbook/getting-started-catalog-background/
21. その他参考リンク • 『Apache Iceberg: The Definitive Guide』 • 非常に詳細 & 網羅的な解説書 • O‘Reilly OnlineでEarly Release版が読める • 2024/4/30発売予定 • A Developer’s Introduction to Apache Iceberg using MinIO • REST Catalogを簡単に試せるハンズオン • https://blog.min.io/a-developers-introduction-to-apache-iceberg-using-minio/ • REST Catalogについてのドキュメント拡充を提案するissue • https://github.com/apache/iceberg/issues/7785