Microsoft FabricでPython UDFや配列・Map・Structなどの複雑なデータ型を使うSparkジョブが遅い場合、今回のNoticeは優先して確認すべき内容です。結論から言うと、Native Execution Engine（NEE）がPython UDF、Scala UDF、複雑データ型をよりネイティブな実行パスで処理できるようになり、既存のNotebookやSparkジョブがコード変更なしで高速化する可能性があります。ただし、NEEが有効になっていること、フォールバックが発生していないこと、JSON/XMLやANSIモードなどの制限に該当しないことを確認する必要があります。([Microsoft Fabric Community][1])
Microsoft FabricのNative Execution Engineで何が変わったのか
2026年6月23日に公開または更新された「Improve performance for Python UDFs and complex data types in Microsoft Fabric’s Native Execution Engine」は、Microsoft FabricのSpark実行性能に関する改善案内です。公式ソース上の分類はNoticeであり、廃止や強制移行ではなく、利用中のSparkワークロードで性能改善の余地があるかを確認するための情報として読むのが適切です。
今回の中心は、Microsoft FabricのNative Execution Engineが、これまで性能上のボトルネックになりやすかったPython UDF、Scala UDF、Arrays、Maps、Structsなどの複雑データ型を、より最適化された列指向の実行経路で扱えるようになった点です。従来のSpark実行では、Python UDFでJVMとPython worker間のシリアライズが発生し、複雑データ型の処理では最適化された列指向処理から行ベース処理へ戻ることがありました。NEEでは、このオーバーヘッドを減らし、対応する処理をネイティブ実行に乗せやすくしています。([Microsoft Fabric Community][1])
| 確認項目 | これまでの課題 | 今回のポイント |
|---|---|---|
| Python UDF | JVMとPython worker間のデータ受け渡しが重くなりやすい | シリアライズ往復を減らし、列指向処理を維持しやすくなる |
| Scala UDF | UDFを含む処理で最適化経路から外れる場合がある | 対応する処理でネイティブ実行の恩恵を受けやすくなる |
| Array、Map、Struct | ネストしたデータ処理で行ベース処理へ戻る場合がある | explode、Mapアクセス、Structフィールド抽出などが最適化対象になりやすい |
| 既存ジョブ | 高速化のためにSQLへ書き換えたり、事前にフラット化したりする必要があった | NEEが有効なら、既存コードのまま改善する可能性がある |
どの利用者に影響があるか
影響が大きいのは、Microsoft FabricのData EngineeringまたはData Scienceで、Spark Notebook、Spark Job Definition、Lakehouse上のETLを運用しているチームです。特に、Pythonで業務ロジックをUDF化しているジョブ、テレメトリやイベントログのようなネスト構造を含むデータ、Deltaテーブル上で半構造化データを扱うパイプラインは確認価値があります。
一方で、Power BIレポートの表示だけを利用しているユーザーや、Sparkを使っていない利用者への直接影響は限定的です。また、単純なI/O待ちが中心の処理では、NEEを有効にしても体感差が小さい可能性があります。公式ドキュメントでも、NEEはParquetやDeltaなどの形式、複雑な変換・集計、CPU負荷の高い処理で効果が出やすい一方、ワークロード特性や構成によって結果が変わると説明されています。(Microsoft Learn)
期待できる性能改善の目安
Microsoft Fabric Blogでは、内部ベンチマークとして、Vectorized PythonまたはScala UDFで最大5.76倍、複雑なUDFで1.08〜2.5倍、複雑型を含むTPC-DSエンドツーエンドワークロードで最大2.35倍の高速化が示されています。ただし、これは代表的なワークロードでの測定結果であり、実際の改善幅はUDFの内容、データのネスト深度、クラスター構成、フォールバックの有無によって変わります。([Microsoft Fabric Community][1])
| ワークロード | 期待値の読み方 | 実務での判断 |
|---|---|---|
| Pandas UDFなどのVectorized UDF | 改善幅が大きくなりやすい | まず検証対象にする |
| 通常のPython UDF | 改善する可能性はあるが幅はワークロード次第 | 実行時間と出力差分を比較する |
| Array、Map、Structを使う処理 | ネスト処理のフォールバックが減る可能性 | explodeやStruct参照を含むジョブを確認する |
| 単純な読み書き中心の処理 | 効果が小さい場合がある | NEEよりパーティション、ファイルサイズ、データ配置を優先して見る |
すぐ確認したい設定
最初に確認すべきなのは、対象ワークスペースや環境でNative Execution Engineが有効になっているかです。Microsoft Learnでは、EnvironmentのSpark computeにあるAcceleration設定から「Enable native execution engine」を有効化し、保存・Publishする手順が案内されています。環境レベルで有効にすると、その環境に紐づく後続のNotebookやジョブが設定を継承します。(Microsoft Learn)
NotebookやSpark Job Definition単位で確認したい場合は、先頭で次のように設定します。
%%configure
{
"conf": {
"spark.native.enabled": "true"
}
}一部のクエリだけNEEを無効化したい場合は、セル単位でfalseにできます。ただし、Sparkはセルを順番に実行するため、後続セルで再びNEEを使う場合はtrueへ戻す必要があります。(Microsoft Learn)
spark.conf.set("spark.native.enabled", "false")
# 対象処理を実行した後、必要に応じて戻す
spark.conf.set("spark.native.enabled", "true")フォールバックを必ず確認する
NEEを有効にしただけで、すべての処理が必ずネイティブ実行されるわけではありません。未対応の演算子、ライブラリ、ファイル形式、設定に該当すると、通常のJVMベースのSpark実行へフォールバックする場合があります。これはジョブ停止を避ける仕組みとしては有用ですが、「有効にしたのに速くならない」原因にもなります。(Microsoft Learn)
確認方法は主に3つです。
| 確認方法 | 見るポイント |
|---|---|
| Spark UI / Spark History Server | 実行計画にTransformer、NativeFileScan、VeloxColumnarToRowExecなどが出ているか |
df.explain() | 対象DataFrameの実行計画にネイティブ実行を示すノードがあるか |
| Fabric Spark Advisor | Notebookセル上でフォールバック警告が出ていないか |
本番ジョブで確認する場合は、1回だけの実行時間ではなく、同じ入力データ、同じ容量、同じSpark構成で複数回比較するのが安全です。キャッシュ、同時実行、OneLakeや外部ストレージの状態によって実行時間はぶれるためです。
運用上の注意点
注意したいのは、「複雑データ型に対応した」ことと「すべての半構造化データ処理が高速化される」ことは同じではない点です。Microsoft Learnでは、NEEはParquet、Delta、CSVをサポートする一方、JSONやXML形式へのクエリは加速対象外で通常のJVMエンジンへ戻ると説明されています。たとえば、JSONファイルを直接読み込む処理ではなく、取り込み後にDeltaテーブル化されたArray、Map、Struct列を処理する部分で効果が出る、と切り分けて考えるべきです。(Microsoft Learn)
| 注意点 | 影響 | 対応 |
|---|---|---|
| JSON/XMLを直接読む処理 | NEEの加速対象外になりやすい | DeltaまたはParquet化後の処理で効果を測る |
| ANSIモード | NEEでは未対応でフォールバックする | ANSI前提の検証ジョブを分ける |
| Structured Streaming | 現時点では未対応として扱われる | バッチ処理とは別に確認する |
| 任意のPythonオブジェクトシリアライズを伴うライブラリ | フォールバックする可能性がある | Pandas UDF化やSQL関数化を検討する |
| 深いネスト構造 | 一部操作でJVMへ戻る可能性がある | Spark Advisorと実行計画で確認する |
丸め、Map重複キー、collect_list()の順序依存 | 結果差分が問題になる可能性がある | 性能だけでなく出力の一致もテストする |
特にデータ品質チェック、金額計算、重複キー検出、順序に依存する集計を含む処理では、実行時間だけでなく結果の同一性を確認してください。NEEは性能改善のための機能ですが、既存ジョブの意味論に影響しうる制限が公式ドキュメントに記載されています。(Microsoft Learn)
管理者・開発者が取るべき次の行動
まず、Fabric内のSparkジョブを棚卸しし、Python UDF、Pandas UDF、Scala UDF、Array、Map、Structを使っているものを抽出します。次に、検証用の環境またはNotebook単位でNEEを有効にし、NEE有効時と無効時の実行時間、CU消費の傾向、出力結果、フォールバック警告を比較します。
確認の優先順位は次の通りです。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | 実行時間が長いETL、夜間バッチ、Python UDFを多用するジョブ | 改善時の効果が大きい |
| 高 | ネストしたイベントデータ、IoT、ログ分析 | 複雑データ型対応の恩恵を受けやすい |
| 中 | Deltaテーブル上の集計・変換処理 | NEEの列指向処理と相性がよい |
| 低 | 小規模データ、単純な読み書きのみの処理 | 改善幅が限定的になりやすい |
今回の変更は、Microsoft FabricでSparkを使うチームにとって「コードを書き換える前に、実行エンジンの設定とフォールバックを確認する」きっかけになります。Python UDFをSQLへ無理に置き換えたり、ネストデータを早い段階でフラット化したりしていた場合は、NEE有効化後の実測値を見て設計を見直す価値があります。まずは検証環境で代表的なジョブを1つ選び、NEE有効化、実行計画確認、結果差分確認、実行時間比較の順に進めるのが現実的です。
[1]: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/Improve-performance-for-Python-UDFs-and-complex-data-types-in/ba-p/5212036 “
Improve performance for Python UDFs and complex da… – Microsoft Fabric Community
“
コメント