Databricks Photon engine 徹底理解：高速化・対応ワークロード・制約

Photonは、DatabricksがApache Sparkの実行レイヤーをC++でゼロから再実装したネイティブベクトル化エンジンです。 従来のJVMベースのSpark実行エンジンと互換性を保ちつつ、CPU命令レベルの最適化（SIMD、列指向バッチ処理）により 特にSQLクエリ・DataFrame操作・Delta Lake I/Oで大幅な高速化を実現します。

本記事では、Photonの対応・非対応ワークロード、JVMへの自動フォールバック挙動、有効化方法、 Classic/Photon/Serverlessのコスト比較を整理します。

Photonのアーキテクチャ：なぜ速いのか

従来のSparkはJVM上でJavaバイトコードとして実行されます。Photonはこの実行レイヤーをC++で置き換え、以下の最適化を行います。

• 列指向バッチ処理：行単位ではなくカラム単位でデータをメモリに配置し、CPUキャッシュ効率を最大化
• SIMD命令の活用：1命令で複数のデータポイントを同時処理（Single Instruction, Multiple Data）
• コード生成の排除：JVM Whole-Stage Code Generationの代わりに事前コンパイル済みのC++コードを使用
• メモリ管理の最適化：JVMのGC（ガベージコレクション）を回避し、メモリ割り当てを直接制御

これらの最適化により、Photonは特にCPU律速のワークロード（大量のJOIN、集約、ソート、フィルタリング）で 従来のSparkエンジンに対して2〜8倍程度の高速化を実現する場合があります。

対応ワークロード

Photonは以下のワークロードで高速化効果を発揮します。Spark SQLおよびDataFrame APIの多くの操作がPhoton対象です。

非対応ワークロード

以下のワークロードはPhotonで実行されず、自動的にJVMベースのSparkエンジンにフォールバックします。 Photonが有効な環境でも、これらの処理はクラシックSparkとして動作します。

フォールバック挙動：非対応時の自動切り替え

Photonが有効なクラスタで非対応のオペレーションを実行した場合、エラーにはなりません。 該当オペレーションだけが自動的にJVMベースのSparkエンジンにフォールバックし、残りのPhoton対応オペレーションはPhotonで実行されます。

# 例：Photon対応クラスタでUDFを含むクエリを実行
from pyspark.sql.functions import udf
from pyspark.sql.types import StringType

# このUDFはJVMフォールバックで実行される
@udf(returnType=StringType())
def custom_transform(value):
    return value.upper() + "_PROCESSED"

# filterとgroupByはPhotonで実行、UDF部分のみJVMで実行
result = (
    spark.read.format("delta").load("/mnt/silver/orders")
    .filter("amount > 100")                    # Photon
    .withColumn("label", custom_transform("region"))  # JVM fallback
    .groupBy("label").sum("amount")            # Photon
)
result.display()

クエリ実行計画をSpark UIで確認すると、Photonで実行されたオペレータには「Photon」プレフィックス（PhotonScan、PhotonHashAggregateなど）が表示されます。 プレフィックスがないオペレータはJVMフォールバックしていると判断できます。

Photonの有効化方法

Photonは以下のいずれかの方法で有効化できます。クラスタ作成時に設定するのが最も一般的です。

• クラスタ作成時にPhoton対応のDatabricks Runtime（例: 15.4 LTS Photon）を選択
• Cluster Policyでphoton_enabledをtrueに強制する
• REST API / CLIでクラスタ設定にruntime_engine: PHOTONを指定

// Cluster Policy でPhotonを強制する例
{
  "runtime_engine": {
    "type": "fixed",
    "value": "PHOTON"
  },
  "spark_version": {
    "type": "regex",
    "pattern": "15\\.4\\.x-photon-scala.*",
    "defaultValue": "15.4.x-photon-scala2.12"
  }
}

Serverless SQL Warehouseでは、Photonがデフォルトで有効です。追加設定なしにPhotonの高速化が適用されます。

Classic vs Photon vs Serverlessの料金比較

Photonの導入判断にはDBU単価と処理時間の両方を考慮する必要があります。 以下は各コンピュートオプションのコスト特性の概要です（実際の単価はクラウドプロバイダやリージョンにより異なります）。

Photonの費用対効果を見るには、同一ワークロードをClassicとPhotonで実行し、実行時間とDBU消費量を比較するのが確実です。 JOIN・集約・ソートが中心のETLジョブでは、Photonの単価上昇を処理時間短縮が上回ることが一般的です。

パフォーマンス最大化のベストプラクティス

• カスタムUDFをSpark組み込み関数に書き換える（UDFはJVMフォールバックするため）
• RDD APIをDataFrame APIに移行する（RDDはPhoton非対応）
• Delta Lake形式で保存する（Parquetの最適化されたPhotonリーダーが使える）
• データスキッピング（Z-ORDER / Liquid Clustering）と組み合わせてI/O削減する
• 小さなファイルを統合する（OPTIMIZE）ことでScan効率を上げる

試験で問われるポイント

• PhotonがC++実装のベクトル化エンジンであること（JVMではない）
• RDDとカスタムUDFがPhoton非対応であること
• 非対応オペレーションはエラーではなくJVMフォールバックすること
• PhotonとServerlessの違い（Serverless = Photon + マネージドコンピュート + 即時起動）
• DBU単価はClassic ＜ Photon ＜ Serverlessだが、総コストは処理時間次第であること

問題で確認

よくある質問