コンテンツに移動
データ分析

詳細解説: Lightning Engine が Apache Spark のパフォーマンスを 4.9 倍高速化する仕組み

2026年6月17日
Newton Alex

Director of Engineering

Abhishek Modi

Principal Software Engineer, Google Cloud

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

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

基本的な ETL と分析から最先端の生成 AI まで、Apache Spark はグローバルなデータ処理のアーキテクチャを支える柱として機能します。とはいえ、データ量が増大するにつれて、パフォーマンスとインフラストラクチャ費用の兼ね合いが成長の阻害要因となる可能性があります。自律型エージェントが数千ものマルチホップ クエリを同時にトリガーできるエージェントの時代においては、このパフォーマンスのボトルネックがユニット エコノミクスに直接影響します。

このたび、Managed Service for Apache Spark 向け Lightning Engine の一般提供が開始され、サーバーレスマネージド クラスタの両方のデプロイモードで利用可能になったことをお知らせいたします。上述のようなスケーリングの課題を直接解決するために設計されたこの Lightning Engine は、最新の Spark ワークロードに完全に対応しているため、既存のデータ パイプラインに変更を加える必要はありません。

オペレーション不要のシンプルなサーバーレス デプロイモードと、インフラストラクチャを詳細に制御できるマネージド クラスタ デプロイモードのどちらを選択しても、Lightning Engine は統合パフォーマンス エンジンとして機能し、ジョブの実行を強力に促進します。100 万件を超える実際のワークロードで Lightning Engine を検証することにより、産業グレードの安定性と信頼性の高いパフォーマンス向上を実現できるようファインチューニングしました。

この一般提供リリースにより、Lightning Engine は以下を実現します。

  • 標準のオープンソース Spark と比較して最大 4.9 倍高速なパフォーマンス

  • 主要な高速 Spark の代替プロダクトと比較して 2 倍の費用対効果

では、Managed Service for Apache Spark がどのようにしてこうした素晴らしい成果を上げているのか、詳しく見ていきましょう。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_6snIfkF.max-1400x1400.jpg

仕組み: ベクトル化したネイティブ実行

従来の Spark 実行では、JVM 実行のオーバーヘッドとガベージ コレクションの一時停止がボトルネックになることが少なくありません。Lightning Engine では、Spark の物理クエリプランを、SIMD(単一命令、複数データ)ベクトル化に最適化されたネイティブ C++ 命令にコンパイルすることで、こうした制限を回避します。

Google 開発の専用拡張機能が組み込まれたオープンソースの Gluten および Velox ランタイム上に構築されたこのネイティブ実行レイヤは、以下の機能を活用して、最も要求の厳しいデータ処理タスクを高速化します。

  • 並べ替えのベクトル化: ネイティブ メモリでデータを列状に処理することで並べ替え処理を高速化し、CPU サイクルのオーバーヘッドを大幅に削減します。

  • ウィンドウ関数の高速化: ネイティブの C++ レイヤ内で直接実行することにより、行セット全体に対して行われる計算(移動平均、集計、重複除去など)を高速化します。

  • スマートなフォールバック: クエリに、ネイティブ サポートされていない演算子やカスタム Java UDF が含まれている場合、エンジンのインテリジェントなプッシュダウン レイヤが、その特定のサブツリーを自動的かつスムーズに JVM に戻し、不要なデータ形式の変換を回避して、全体的な実行の安定性を維持します。

最適化された Cloud Storage と BigQuery のコネクタ

エンジンがデータ不足に陥ると、ハイ パフォーマンス コンピューティングも役に立ちません。Lightning Engine では、Cloud Storage と BigQuery からのデータの読み取りがボトルネックにならないよう、ストレージ コネクタを以下のように最適化しました。

  • パスの直接接続: 複数のノードホップをバイパスし、Cloud Storage との双方向ストリーミングを使用します。これにより、ストリームを再オープンしなくてもシーク操作やベクトル化した readV API を実行できるため、複雑で深くネストされた Parquet ファイルや ORC ファイルのスキャン時間を短縮できます。

  • メタデータ呼び出しの削減: 大規模なパーティション分割テーブルを管理する際は、ただファイルを一覧表示するだけで時間を消費するという、パフォーマンスの隠れた代償を伴うことがよくあります。Lightning Engine は、ドライバで辞書順のリストを利用してメタデータを収集し、それをエグゼキュータに直接送信します。これにより、冗長な Cloud Storage API 呼び出しが排除され、Cloud Storage のメタデータ コストが大幅に削減されます。

  • ネイティブの BigQuery コネクタ: BigQuery データを Arrow 形式で直接使用します。Arrow から JVM UnsafeRow への、コストの高い変換を回避することで、エンジンはシリアル化のオーバーヘッドを排除し、スキャン時間を短縮できます。

ブロードキャスト結合と高度なクエリの最適化

Lightning Engine には、Google の F1 および Spanner クエリエンジンにインスパイアされたコストベースの高度なクエリ オプティマイザーが組み込まれており、いくつかのカスタム最適化ルールが導入されています。以下に例を示します。

  • 単一のハッシュ テーブル キャッシュ: 標準のブロードキャスト結合では、Spark はタスク間で結合ハッシュ テーブルを繰り返し構築します。一方、Lightning Engine では、エグゼキュータごとにハッシュ テーブルを一度だけ構築してキャッシュに保存するため、冗長な CPU サイクルが排除され、エグゼキュータのメモリ使用量が減少します。

  • 集計のプッシュダウン: 結合シャッフルの前に部分的な集計を自動的にプッシュします。これにより、ネットワーク経由で転送する必要があるデータ量を最小限に抑え、コストの高いシャッフル ステージを大幅に減らすことができます。

  • 自動シャッフル パーティショニング: ランタイム統計情報に基づいてクエリステージごとに最適なシャッフル パーティション数を動的かつ適応的に決定し、過剰なパーティショニングをなくして、メモリ不足(OOM)によるスピルを防止します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_ghHCex2.max-1300x1300.png
Google Cloud Next ‘26 での Lightning Engine の技術的な詳細と Lowe’s の事例の紹介

使ってみる

これらのアップデートはすでに公開されているため、すぐにご利用いただけます。Lightning Engine を有効にするには、Google Cloud コンソールから直接操作するか、gcloud CLI を使用します。

Lightning Engine を有効にして サーバーレス バッチジョブを送信するには、Spark プロパティでプレミアム ティアを指定します。

読み込んでいます...

Lightning Engine とネイティブ クエリ実行(NQE)が有効な新しいマネージド クラスタをスピンアップするには、ターミナルで次のコマンドを実行します。

読み込んでいます...

別の方法として、Google Cloud コンソールManaged Service for Apache Spark のページに移動します。[クラスタを作成] をクリックし、[Compute Engine 上のクラスタ] を選択して、クラスタ構成設定で [Lightning Engine] を選択すると、ワークロードのクエリ高速化が自動的に有効になります。

- エンジニアリング担当ディレクター、 Newton Alex

- Google Cloud、プリンシパル ソフトウェア エンジニア、Abhishek Modi 

投稿先