Iceberg マニフェストキャッシングで、Impala のクエリプラン作成を12倍高速に

Iceberg マニフェストキャッシングで、Impala のクエリプラン作成を12倍高速に

by Riza Suminto
この記事は、2024/7/13に公開された「12 Times Faster Query Planning With Iceberg Manifest Caching in Impala」の翻訳です。

Iceberg は、大規模な分析ワークロードのために設計された、新しいオープンテーブルフォーマットです。Apache Iceberg プロジェクトは、Iceberg 仕様の Java ライブラリ実装の開発を続けています。Impala、Hive、Spark、Trino などのいくつかの計算エンジンは、Apache Iceberg プロジェクトが提供するこの Java ライブラリを採用することで、Iceberg テーブル形式のデータクエリをサポートします。

Impala、Hive、Spark といったさまざまなクエリーエンジンは、Apache Iceberg Java Library を使うことですぐにその恩恵を受けることができます。テーブル内のデータファイルのリストアップ、テーブルスナップショットの選択、パーティションフィルタリング、述語フィルタリングなどの Iceberg のテーブル解析を、各クエリエンジンが実装することなく、Iceberg Java API に委譲することができるのです。しかし、Iceberg Java API  呼び出しのコストは必ずしも低くはありません。

このブログでは、Cloudera が Apache Iceberg プロジェクトにコントリビュートした、Iceberg メタデータの読み取りに関するハイパフォーマンス化について説明し、クエリーエンジンとして Apache Impala を使用した場合のパフォーマンス効果を紹介します。Hive や Spark などの他のクエリーエンジンでも、この Iceberg の新機能の恩恵を受けることができます。

Impala + Iceberg におけるメタデータの繰り返し読み込み問題

Apache Impala はオープンソースの分散型超並列 SQL クエリーエンジンです。Apache Impala には、バックエンド・エグゼキューターとフロントエンド・プランナーという2つのコンポーネントがあります。Impala のバックエンド・エグゼキュータは C++ で書かれており、高速なクエリ実行を提供します。一方、 Impala フロントエンドプランナーは Java で書かれており、ユーザーからの SQL クエリを分析し、クエリの実行を計画します。クエリの計画作成中、Impala フロントエンドはパーティション情報、データファイル、統計情報といったテーブルのメタデータを分析し、最適化されたクエリプランを導き出します。Impala フロントエンドは Java で記述されているため、Impala は Apache Iceberg プロジェクトが提供する Java ライブラリを通じて、Iceberg テーブルのメタデータの多くの側面を直接分析することができます。

図1. TPC-DS Q9 でフィルター述語を変えながら 15 回スキャンした store_sales テーブル

Hive テーブルフォーマットでは、パーティション情報や統計情報などのテーブルメタデータは Hive メタストア (HMS) に格納されます。HMS は mysql や postgresql などの RDBMS によってバックアップされているため、Impala は Hive テーブルメタデータに高速にアクセスできます。また、Impala は CatalogD と Coordinator のローカルカタログにテーブルメタデータをキャッシュするため、対象となるテーブルメタデータとファイルに以前にアクセスしたことがあれば、テーブルメタデータの分析がさらに高速になります。Impala は同じテーブルを複数回分析することがあるため、このキャッシュは Impala にとって重要です。図1は、1 つの共通テーブル store_sales を15回分析し、15 個の別々のテーブルスキャンフラグメントを計画した TPC-DS Q9 計画を示しています。

図2. Iceberg Java API による Iceberg テーブルメタデータの読み込み

対照的に、Iceberg テーブル・フォーマットは、メタデータをファイル・システム内のファイル・セットとして、データ・ファイルの隣に保存します。図2は、スナップショット・ファイル、マニフェスト・リスト、マニフェスト・ファイルの3種類のメタデータ・ファイルを示しています。Iceberg フォーマットのデータ ファイルとメタデータ ファイルは不変です。Iceberg テーブルに対する新しい DDL/DML 操作は、以前のファイルを書き換えたり置き換えたりするのではなく、新しいファイル セットを作成します。Iceberg Java API を使ったテーブル・メタデータの問い合わせでは、これらのメタデータ・ファイルのサブセットを読み込む必要があります。そのため、同じテーブルを分析するメタデータファイルであっても、それぞれにストレージの待ち時間とネットワークの待ち時間のオーバーヘッドが発生します。この問題は IMPALA-11171 に記述されています。

図3. S3上の Iceberg テーブルを対象としたTPC-DS Q9計画中の複数ソケットの読み取り動作

Iceberg マニフェスト・ファイル・キャッシュの設計

Impala フロントエンドは、高速なクエリ実行計画作成のパフォーマンスを維持しながら、Iceberg Java API を使用することに注意しなければなりません。Iceberg メタデータファイルの複数回のリモート読み込みを減らすには、Impala が Hive テーブル形式に対して行っているのと同様のキャッシュ戦略を、Impala フロントエンド側か Iceberg Java Library に組み込んで実装する必要があります。最終的には、コミュニティ全体にとって有用なものを提供し、すべてのコンピュートエンジンがその恩恵を受けられるように、後者を選択することにしました。また、このようなキャッシュ・メカニズムをできるだけ邪魔にならないように実装することも重要です。

図4. Iceberg マニフェスト・キャッシング・デザイン

このキャッシュ・メカニズムを実装するために、Apache の Iceberg プロジェクトにプル・リクエスト4518を出しました。このアイデアは、マニフェスト・ファイル (Iceberg メタデータ・ファイル階層の最下位) のバイナリ・コンテンツをメモリにキャッシュし、Iceberg Java Library がファイル・システムから再度読み込む代わりに、キャッシュが存在すればメモリから読み込むようにするというものです。これは、マニフェストファイルを含む Iceberg メタデータファイルは不変であることにより実現されています。Iceberg テーブルが進化した場合、古いマニフェストファイルを修正する代わりに新しいマニフェストファイルが書き込まれます。そのため、Iceberg Java Library は処理の中で、ファイルシステムから必要なマニフェストファイルを読み込み、マニフェストキャッシュに新しいコンテンツを追加し、古いマニフェストファイルを消去します。

図 4 は、Iceberg マニフェストキャッシュの 2 層設計を示しています。最初の階層は FileIO レベルのキャッシュで、FileIO を Iceberg自体が提供する ContentCache にマッピングします。FileIO 自体が、コア Iceberg ライブラリと下層にあるストレージの間の主要なインターフェイスです。Iceberg ライブラリによるファイルの読み書きはすべて FileIO インターフェイスを経由します。デフォルトでは、この第 1 層キャッシュは、メモリ内に ContentCache エントリを同時に持つことができる FileIO を最大 8 つ持っています。この数は、Java システムプロパティ iceberg.io.manifest.cache.fileio-max.FileIO によって増やすことができます。

第2層のキャッシュは ContentCache オブジェクトで、ファイル・ロケーション・パスとそのファイル・パスのバイナリー・ファイル・コンテンツのマッピングです。バイナリファイルのコンテンツは、4MB のチャンクに分割された ByteBuffer としてメモリに格納されます。どちらの階層も、Iceberg Java Libraryで使われている高性能キャッシュ・ライブラリであるCaffeineライブラリを使用しており、weak keyとsoft valueの組み合わせで実装されています(弱参照を参照してください)。この組み合わせにより、JVM のメモリー圧迫やFileIOのガベージ・コレクションが発生した場合に、キャッシュ・エントリーを自動的に消去することができます。このキャッシュは、Iceberg Java Library のコア (ManifestFiles.java) に実装されているため、異なる FileIO 実装でもコードを変更することなくすぐに使用できます。

Impala の Coordinator と CatalogD は、この Iceberg マニフェストキャッシュを使用して、Iceberg テーブル上で高速なファイルリストとデータファイルのプルーニング(刈り込み)を行うことができます。Icebergマニフェストキャッシュは、CatalogD と Coordinator のローカルカタログの役割を排除するものではないことに注意してください。テーブルスキーマ、ファイル記述子、ブロックロケーション (HDFS バックアップされたテーブルの場合) など、一部のテーブルメタデータは未だに CatalogD 内にキャッシュされています。CatalogD キャッシュとIceberg マニフェストキャッシュを組み合わせることで、Impala で高速なクエリプランニングを実現することができます。

表 1.  CatalogD と Iceberg マニフェストキャッシュのテーブル形式間での役割。

FileIO ごとの ContentCache は、それぞれの Iceberg Catalogプロパティで調整できます。各プロパティの説明とデフォルト値は次のとおりです:

Impala のパフォーマンス向上

図5. TPC-DS クエリー 3TB スケールに対する Impala クエリーコンパイル時間の逆CDF

Impala やその他のクエリーエンジンは、Apache Iceberg バージョン1.1.0からマニフェスト・キャッシング機能を活用できるようになりました。図5 は、Impala フロントエンドによるコンパイル時間の改善を示しています。X 軸は TPC-DS ワークロードにおけるクエリのパーセンテージを表し、Y 軸はミリ秒単位のクエリコンパイル時間を表しています。マニフェストキャッシュを使用しない Iceberg (バニラ Iceberg) と比較して、Iceberg マニフェストキャッシュを有効にすると、クエリコンパイルが12倍高速化され (Iceberg + caffeine)、Hive 外部テーブルのパフォーマンスとほぼ同等になります。注意点として、Impala では、Coordinator のキャッシュ有効期限である io.manifest.cache.expiration-interval-msの設定が1時間と高く設定されます。これは Impala に とって有益です。デフォルトのHiveカタログでは、Impala のフロントエンドが Iceberg の HiveCatalog のシングルトンを保持し、その有効期限が長いためです。上記の設計のセクションで説明したように、Iceberg ファイルは不変であるため、長い有効期限を設定しても問題ありません。また、有効期限を長く設定することで、キャッシュエントリをより長く保存し、同じテーブルを対象とする複数のクエリ計画に利用することができます。

​​Impala は現在、デフォルトの Iceberg カタログ・プロパティを core-site.xml から読み込んでいます。1時間の有効期限間隔で Iceberg マニフェストのキャッシュを有効にするには、Coordinator および CatalogD サービスの core-site.xml に以下の構成を設定します:

まとめ

Apache Iceberg は、大規模な分析ワークロードのために設計された、新しいオープンテーブル形式です。Apache Iceberg プロジェクトは、Impala、Hive、Spark など多くのクエリエンジンに採用されている Iceberg Javaライブラリの開発を続けています。Cloudera は Apache IcebergにIcebergマニフェストキャッシング機能を提供し、マニフェストファイルの繰り返し読み込みの問題を軽減しています。Apache Impalaをクエリーエンジンとして使用したときの Icebergマニフェストキャッシングの効果として、Impala が Icebergマニフェストキャッシングを有効にした Iceberg テーブルのクエリーコンパイル時間を最大12倍高速化できることをご紹介しました。

さらに詳しく:

  1. Cloudera Data Warehouse (CDW) における Iceberg マニフェストキャッシュ設定の詳細については、以下を参照してください。
    https://docs.cloudera.com/cdw-runtime/cloud/iceberg-how-to/topics/iceberg-manifest-caching.html
  2. ウェビナー「Supercharge Your Analytics with Open Data Lakehouse Powered by Apache Iceberg」をご覧ください。Icebergの機能のライブデモも収録されています。

Cloudera Data Warehouse (CDW)、Cloudera Data Engineering (CDE)、Cloudera Machine Learning (CML)は、60日間のトライアルにサインアップするか、CDP をテストドライブしてお試しください。CDP の Apache Iceberg についてのチャットにご興味のある方は、アカウントチームにお知らせください。

Cloudera Japan Marketing
この著者の他の記事

コメントする

あなたのメールアドレスは公開されません。また、コメントにリンクを貼ることはできません。