データ分析

データレイクの高速化: gcs-analytics-core で Apache Iceberg と Spark を最適化

2026年6月9日

Ajay Yadav

Software Engineer

Nivedita Aggarwal

Engineering Manager

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

※この投稿は米国時間 2026 年 6 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

データエンジニアの多くは、複数の分析エンジンでの互換性の管理や、最適なパフォーマンスの確保のために多大な時間を費やしています。Google はこの課題を解決するために、gcs-analytics-core を発表しました。これは、Google Cloud Storage（GCS）の分析の最適化を一元化して高速化するように設計された新しいオープンソースの Java ライブラリです。

GCS 上で高いパフォーマンスを実現しつつ、好みの分析エンジンを柔軟に選択できるほか、gcs-analytics-core ライブラリは、現在 GCS で使用されているさまざまな分析エンジン（Iceberg Spark エンジンなど）にわたって最適化を実現します。今年末までに他の分析エンジンにも拡張する予定です。

このライブラリは、バージョン 1.11.0 以降の Apache Iceberg Java ランタイムでネイティブに利用できます。Apache Spark などの主要なデータ処理フレームワーク間で共有できるように構築されており、GCS 上の分析ワークロードのパフォーマンスを統合し、向上させるほか、Parquet などの列形式の読み取りオペレーションを改善します。

gcs-analytics-core ライブラリとは

gcs-analytics-core ライブラリは、Apache Spark、Trino、Apache Hive などの分析エンジンと、基盤となる GCS Java SDK との間に位置する一元化された最適化レイヤです。読み取り呼び出しをインターセプトしてパフォーマンスを向上させ、フレームワーク固有のチューニングを必要とせずに一貫したエクスペリエンスを提供します。

Apache Iceberg では GCSFileIO 実装に統合され、従来の順次読み取りを並列化された戦略に置き換えることで、レイテンシを最小限に抑え、スループットを最大化します。

主な技術的最適化

このライブラリには、I/O に費やす時間とエンドツーエンドの実行時間を短縮するために設計された、特別な最適化機能が導入されています。

ベクトル化された I/O（スレッド化）: 1 回のオペレーションで複数のデータ範囲を並行してフェッチすることで、読み取りパフォーマンスを向上させ、GCS 呼び出しのオーバーヘッドを削減します。この機能がない場合、システムはデータ範囲ごとに個別の呼び出しを発行する必要があるため、各リクエストにおけるオペレーションの数とファイルを開く操作のレイテンシの両方が増加します。
スマート Parquet プリフェッチ: Parquet データを読み取る際、分析エンジンは通常、データの構造や特定のデータ範囲の場所に関する情報を含むファイルのフッターを最初に読み取ります。このライブラリは、このフッターデータを単一のチャンク（通常 50 KB～100 KB）として自動的にプリフェッチすることで、多くのエンジンで発生しがちな、メタデータを取得するために後方へ何度もシークして複数回ネットワーク呼び出しを行う処理を回避できます。

注目点: Apache Iceberg のインテグレーション

このライブラリ初の重要インテグレーションとして、Apache Iceberg とのインテグレーションを実現しました。Iceberg 1.11.0 以降では、Iceberg の GCSFileIO を利用する分析エンジンで、これらのパフォーマンスの向上を活用できます。ご使用の環境にこのライブラリを導入する際は、Iceberg カタログがネイティブの GCS FileIO を使用するように構成されていることを確認してください。

読み込んでいます...

このライブラリの中核となるこれらの最適化は、更新された Iceberg ランタイムと GCS コネクタアーキテクチャに組み込まれているため、Parquet フッターのプリフェッチや、マルチスレッドによるベクトル化された読み取りのメリットを自動的に享受できます。複雑なカスタムチューニングは必要ありません。

インテグレーションの具体的な詳細については、Apache Iceberg の問題 #14326 をご覧ください。

カタログの互換性

gcs-analytics-core ライブラリは、REST カタログ、Hive、その他のメタデータ管理システムなど、すべての Iceberg カタログと互換性があります。パフォーマンスの最適化をカタログ管理レイヤから切り離すことで、既存のインフラストラクチャ設定を調整することなく、一貫した読み取り性能の向上を実現するほか、さまざまなデータレイクアーキテクチャにわたるスケーリングを可能にします。

Spark を使用した TPC-DS パフォーマンスベンチマーク

これらの改善効果を検証するために、オープンソースの Apache Spark クラスタを使用してエンドツーエンドのベンチマークを実施しました。このクラスタでは、gcs-analytics-core ライブラリとともに GCSFileIO を使用するように Iceberg カタログが構成されています。

このベンチマークでは、業界標準の TPC-DS スキーマをさまざまなデータセットサイズ（1 GB から 10 TB まで）で使用し、ベクトル化された順次読み取りを使用するデフォルトの GCSFileIO 実装と、新しいライブラリの最適化機能を重点的に比較しました。

ストレージレイヤでの I/O ボトルネックが解消されることで、コンピューティングエンジンがネットワーク応答を待つ時間（スキャン時間）が短縮され、データ処理（実行時間）に費やす時間が増えます。

以下に、このエンドツーエンドの TPC-DS ベンチマーク結果を示します。gcs-analytics-core を有効にした場合の改善率をご確認ください。

https://storage.googleapis.com/gweb-cloudblog-publish/images/TPC-DS_benchmark_for_gcs-analytics-core_I7.max-1900x1900.jpg

TPC-DS スキーマサイズ	スキャン時間の改善率	実行時間の改善率
1 GB	71.51%	32.61%
10 GB	48.48%	18.94%
100 GB	40.98%	10.95%
1 TB	35.86%	3.38%
10 TB	18.40%	1.58%

上記のデータが示すように、すべてのデータセットサイズで一貫した改善が見られました。このライブラリは、TPC-DS の複雑なクエリパターンに効果的であり、スキャン時間の短縮により、クエリの実行時間全体を直接短縮します。

使ってみる

Spark ワークロードを実行する前に、以下の要件を満たした構成であることを確認してください。

Apache Iceberg Spark ランタイム 1.11.0 以降と iceberg-gcp-bundle 1.11.0 以降を使用する。
GCSFileIO を使用するようにカタログを構成する。
gcs-analytics-core 最適化フラグを有効にする（spark.sql.catalog.$CATALOG_NAME.gcs.analytics-core.enabled=true）。

ベクトル化された I/O（spark.sql.iceberg.vectorization.enabled=true）を有効にして、読み取りパフォーマンスを向上させる。

読み込んでいます...