Fabric Runtime 1.3からRuntime 2.0への移行

Fabric Runtime 2.0は、Microsoft FabricにおけるApache Sparkワークロード向けの最新の一般公開(GA)およびデフォルトのランタイムです。 オペレーティングシステム、Java、Scala、Python、R、Apache Spark、Delta Lakeの更新を行います。 これらのアップデートのいくつかはメジャーバージョンの境界を越えるため、Runtime 1.3から本番ワークロードを移行する前に、ノートブック、Sparkジョブ定義、ライブラリ、データパイプラインを必ず検証してください。

このガイドでは、移行に影響を与える変更点を説明し、ワークロードをRuntime 2.0に移行するための段階的なプロセスを提供します。

ランタイム2.0で何が変わったのか

以下の表は、Runtime 1.3とRuntime 2.0の主要コンポーネントを比較したものです。

Component ランタイム 1.3 ランタイム 2.0 移住の考慮
リリース段階 サポート終了(EOSA)発表 GA 本番ワークロードをサポートされているGAランタイムに移行します。
Apache Spark 3.5.5 4.1.1 Spark 4.1の動作変更と削除されたAPIを確認しましょう。
デルタ湖 3.2 4.2 テーブルの機能やプロトコルの互換性を、あなたのテーブルを使用するすべてのFabricワークロードで検証してください。
Java 11 21 (二十一) JavaライブラリおよびJava Native Interface(JNI)依存関係の再構築とテスト。
Scala 2.12.17 2.13.16 Scala 2.13用にScala JARファイルを再コンパイルします。 Scala 2.12と2.13のアーティファクトはバイナリ互換性がありません。
Python 3.11 3.13 各PythonパッケージがPython 3.13互換リリースとLinuxホイールを提供しているか確認してください。
R 4.4.1 .4.5.2 カスタムRパッケージを再インストールしてテストしてください。 SparkRはSpark 4.1で非推奨となっています。
オペレーティング システム Azure Linux 2.0 (Mariner 2.0) Azure Linux 3.0 (Mariner 3.0) Azure Linux 3.0用にネイティブライブラリとカスタムバイナリを再構築する。

ランタイム2.0はまた、VARIANTデータ型、SQLユーザー定義関数、セッション変数、パイプ構文、文字列コレーション、PythonデータソースAPI、Pythonユーザー定義テーブル関数、統一PySparkプロファイリング、新しい構造化ストリーミングの状態管理およびデバッグAPIなど、新たなApache Spark 4.1機能も提供しています。 概要については、FabricのRuntime 2.0を参照してください。

互換性の変更を確認

ワークスペースや環境をRuntime 2.0に変更する前に、以下の点を確認しましょう。

組み込みおよびカスタムライブラリ

Runtime 2.0は、Runtime 1.3で利用可能だった複数のプリインストールされたPythonおよびRパッケージを削除します。 デフォルトのパッケージセットを減らすことで、ランタイムをリーンに保ち、潜在的なセキュリティインシデントのリスクを減らします。 Runtime 1.3で設定なしで利用可能だったパッケージを、Runtime 2.0環境に明示的に追加する必要があるかもしれません。

Library Managerを使って、ワークロードに必要なパッケージだけを追加し、その後環境を保存・公開してください。 ライブラリマネージャーはパッケージの必要な依存関係を解決するため、次の一覧にあるすべての依存関係を個別に追加しないでください。 ライブラリが利用可能であることや、そのバージョンが変更されていないと決めつけないでください:

  • FabricのランタイムリリースリポジトリにあるRuntime 1.3とRuntime 2.0のパッケージインベントリを比較してください。
  • 環境に不足しているPyPI、Conda、Maven、R、またはカスタム ライブラリを追加し、それを公開します。
  • 依存関係解決を再現可能にするために、本番ワークロードではバージョンを固定します。
  • PythonパッケージがPython 3.13をサポートしているか確認してください。 ネイティブ拡張機能を持つパッケージは、互換性のあるLinuxホイールを提供するか、Azure Linux 3.0上で成功裏にビルドする必要があります。
  • Scala 2.12の依存関係をScala 2.13のアーティファクトに置き換えてください。 アーティファクト名には一般的にScalaのバイナリバージョンが含まれ、例えば _2.12 や _2.13が含まれます。
  • Java 21、Scala 2.13、Spark 4.1に対してカスタムJARファイルを再コンパイルします。 推移的依存関係について、実行時に提供されるライブラリとの競合をテストします。
  • Azure Linux 3.0用にカスタムネイティブライブラリを再構築してください。

Fabricは既存の環境の実行時を変更するとライブラリ仕様を移行しますが、それらのライブラリが互換性を保つ保証はありません。 依存関係解決が競合を見つけたとき、公開は失敗します。 パッケージのインストールオプションや公開モードについては、「Fabric環境のライブラリ管理」を参照してください。

デフォルト環境から削除されたパッケージ

以下のインベントリには、ユーザー向けパッケージおよびその低レベルまたは推移依存関係が含まれます。 これらのリストで、あなたのRuntime 1.3ワークロードが使っているパッケージを探してみてください。 パッケージがリストされている場合は、Library Managerを通じてRuntime 2.0環境でPython 3.13互換またはR 4.5互換のバージョンを追加してください。

Python環境:348のCondaパッケージ
Package Package Package Package
_libgcc_mutex _sysroot_linux-64_curr_repodata_hack abseil-cpp alabaster
aom appdirs archspec argon2-cffi
argon2-cffi-bindings arrow arrow-cpp asgiref
asn1crypto astropy async_generator async-lru
async-timeout autopep8 aws-c-auth aws-c-cal
aws-c-common aws-c-compression aws-c-event-stream aws-c-http
aws-c-io aws-c-mqtt aws-c-s3 aws-c-sdkutils
aws-checksums aws-crt-cpp aws-sdk-cpp azure-keyvault
azure-storage babel backports backports.shutil_get_terminal_size
bcrypt beautifulsoup4 binaryornot binutils_impl_linux-64
binutils_linux-64 bitarray bkcharts black
blas bleach blinker blosc
bokeh boltons boost-cpp boto
bottleneck brunsli c-ares c-blosc2
cached-property cfitsio chardet charls
cmake cmdstan conda-package-handling conda-package-streaming
configparser contextlib2 cookiecutter curl
cython cytoolz daal4py dal
dask dask-core dataclasses datasets
dav1d dill distributed distro
django docutils entrypoints expat
fastcache flake8 flit flit-core
fmt fonts-anaconda future gcc_impl_linux-64
gcc_linux-64 geographiclib geopy get_terminal_size
gevent gflags giflib glib
glob2 glog gmp gmpy2
gobject-introspection grpc-cpp gst-plugins-base gstreamer
gtk2 gxx_impl_linux-64 gxx_linux-64 hdf5
heapdict html5lib huggingface_hub imagecodecs
imageio imagesize inflection iniconfig
intel-openmp intervaltree ipython_genutils jaraco.classes
jeepney jpeg json5 jsonpatch
jsonpointer jupyter_console jupyter_events jupyter-lsp
jupyter_server jupyter_server_terminals jupyterlab jupyterlab_pygments
jupyterlab_server jxrlib kernel-headers_linux-64 keyring
lazy_loader lazy-object-proxy liac-arff libaec
libarchive libavif libclang libcurl
libev libevent libgcc-devel_linux-64 libgfortran-ng
liblief libllvm14 libmamba libmambapy
libnghttp2 libprotobuf libsolv libspatialindex
libssh2 libstdcxx-devel_linux-64 libthrift libtool
libwebp libzopfli lightning-utilities llvm-openmp
llvmlite locket lxml lz4
lz4-c lzo make markdown
mccabe menuinst minio mistune
mkl mkl_fft mkl_random mkl-service
mock more-itertools mpc mpfr
mpi mpich mpmath msgpack-python
msrest multipledispatch multiprocess mysql
nbclassic nbclient nbconvert nest-asyncio
networkx ninja ninja-base nose
notebook notebook-shim nspr nss
numba numexpr numpy-base numpydoc
oauthlib olefile openml orc
overrides pandocfilters paramiko partd
patch patchelf path path.py
pathlib2 pep8 pickleshare pkginfo
pluggy ply poppler poppler-data
prettytable prometheus_client py-cpuinfo py-lief
pybind11-abi pycodestyle pycosat pycurl
pydocstyle pyerfa pyflakes pynacl
pyopenssl pyqt pyqt5-sip pyrsistent
pytables pytest python-fastjsonschema python-json-logger
python-libarchive-c python-lmdb python-slugify python-xxhash
pytorch pytorch-lightning pytorch-mutex pywavelets
qdarkstyle qstylizer qt qt-main
qt-webengine qtawesome qtconsole qtpy
re2 reproc reproc-cpp requests-oauthlib
rfc3339-validator rfc3986-validator rhash ripgrep
rtree s2n safetensors scikit-build
scikit-image scikit-learn-intelex secretstorage send2trash
shap simplegeneric singledispatch sip
slicer snappy snowballstemmer sortedcollections
sortedcontainers soupsieve sphinx sphinxcontrib
sphinxcontrib-applehelp sphinxcontrib-devhelp sphinxcontrib-htmlhelp sphinxcontrib-jsmath
sphinxcontrib-qthelp sphinxcontrib-serializinghtml sphinxcontrib-websupport sqlite
sympy sysroot_linux-64 tbb tbb-devel
tbb4py tblib terminado testpath
text-unidecode textdistance tifffile tinycss2
tokenizers toml tomli-w toolz
torchdata torchmetrics transformers truststore
typed-ast ujson unicodecsv unidecode
utf8proc webencodings websocket-client wheel
whichcraft xlsxwriter xlwt xmltodict
xxhash xyzservices xz yaml-cpp
yapf zfp zict zlib
zope zope.event zope.interface zstandard
Python環境:24 pipパッケージ
Package Package Package Package
accelerate astor dash dash-core-components
dash-cytoscape dash-html-components dash-table docker
interpret interpret-core json-tricks nni
nvidia-ml-py pyperclip pythonwebhdfs responses
retrying salib schema seqeval
simplejson tensorboardx thop typeguard
R環境:67 Condaパッケージ
Package Package Package Package
_libgcc_mutex _sysroot_linux-64_curr_repodata_hack blosc cfitsio
expat fmt freetype freexl
geos geotiff giflib hdf4
hdf5 json-c kealib lcms2
libaec libarchive libgdal libgdal-core
libgdal-fits libgdal-grib libgdal-hdf4 libgdal-hdf5
libgdal-jp2openjpeg libgdal-kea libgdal-netcdf libgdal-pdf
libgdal-pg libgdal-postgisraster libgdal-tiledb libgdal-xls
libkml libnetcdf libnsl librttopo
libspatialite libsqlite libudunits2 libv8
libzip lzo minizip nspr
nss openjpeg poppler poppler-data
proj r-classint r-gsl r-jose
r-mgcv r-s2 r-sf r-units
r-wk spdlog sqlite tiledb
uriparser xerces-c xorg-kbproto xorg-renderproto
xorg-xextproto xorg-xproto xz

メモ

アウトバウンドアクセス保護や管理された仮想ネットワークで公開リポジトリへのアクセスが妨げられている場合は、対応するホイールファイルをダウンロードするかパッケージミラーをホストしてください。 手順については、「Fabricでネットワークアクセスが制限されたライブラリを管理する」をご覧ください。

Spark 構成の変更

ランタイム2.0ではSparkの設定を追加・削除し、いくつかのデフォルト値を変更します。 Fabricは一部の設定でApache Sparkとは異なるデフォルトを使用しています。

移行前に、ワークスペース、環境、ノートブック、Sparkジョブ定義に対して構成したSpark設定を確認してください。 サポートされていない設定を削除し、変更されたデフォルトに依存しているワークロードをテストしましょう。 ドキュメントで設定変更の指示がない限り、ランタイムのデフォルトを使いましょう。

主なデフォルト値の変更点

以下の表は、選択したベースラインの変更を示しています。 設定されていない とは、ベースラインが明示的に値を設定していないことを意味します。機能が無効になっているという意味でもありません。

Configuration Runtime 1.3 の値 Runtime 2.0 の値 移住の考慮
spark.checkpoint.compress false true チェックポイントファイルはデフォルトで圧縮されています。 チェックポイントの相互運用性とストレージ挙動を検証します。
spark.databricks.delta.optimizeWrite.enabled true 設定されていません プロパティは削除されません。 テーブル、セッション、リソースプロファイルの設定で効果的な最適化された書き込み動作を検証してください。
spark.databricks.delta.optimizeWrite.partitioned.enabled false true パーティション分割されたデルタテーブルの書き込みスループットおよび出力ファイルサイズを検証します。
spark.hadoop.parquet.block.size 1073741824 (1 GiB) 134217728 (128 MiB) Parquetライターは小さなブロックを対象とします。 ファイルサイズと後続の読み取り処理の性能を検証します。
spark.microsoft.delta.optimize.fast.enabled false true OPTIMIZE ファイル数や推定圧縮サイズの基準が満たされない限り、作業をスキップできます。 メンテナンス結果を検証。
spark.microsoft.delta.optimize.fileLevelTarget.enabled false true 以前にコンパクション目標サイズの半分以上に達したファイルは再びコンパクションされません。 OPTIMIZE後にファイルレイアウトを検証してください。
spark.microsoft.delta.targetFileSize.adaptive.enabled false true Deltaはテーブルサイズに基づいて目標ファイルサイズを計算します。 結果となるファイルサイズと読み取り性能を検証します。
spark.speculation.multiplier 1.5 3 タスクは中央値より3倍以上遅い場合にのみ、Sparkはそれを推測実行の対象と見なします。
spark.speculation.quantile 0.75 0.9 Sparkは90% のタスクが終わるまで待ってから、推測的な実行を検討する。
spark.sql.files.maxPartitionBytes 134217728 (128 MiB) 536870912 (512 MiB) ファイルスキャンは各パーティションにより多くのデータを詰め込むことができます。 並列処理とエグゼキュータメモリの使用を検証します。
spark.sql.maxSinglePartitionBytes Long.MaxValue 128m 1つのパーティションはデフォルトで128 MiBに制限されています。 大規模な単一パーティションを生成するクエリを検証します。
spark.sql.orc.compression.codec snappy zstd 新しいORC書き込みはデフォルトでZstandard圧縮を使用します。 下流のリーダーとの互換性やパフォーマンスを検証します。
spark.sql.sources.v2.bucketing.enabled false true Sparkはデフォルトでストレージ分割ジョインやその他のData Source V2バケット動作を有効にします。 クエリプランと結果を検証しましょう。
spark.sql.sources.v2.bucketing.pushPartValues.enabled false true SparkはData Source V2バケット化用の互換性あるパーティション値をプッシュできます。 バケットテーブルのクエリプランを検証します。

ランタイム2.0ではROCKSDBにはLEVELDBではなくspark.shuffle.service.db.backendを使用し、spark.shuffle.service.removeShuffleをtrueに設定しています。 Sparkは外部シャッフルサービスを使って、割り当て解除されたエグゼキューター用の不要なシャッフルブロックを削除します。

デルタ並列スナップショットの読み込み、並列データスキップ、ドライバー側のスナップショット読み込みも false から true に変化します。 クエリの遅延やドライバーリソースの使用をテストし、特に複数のDeltaテーブルにアクセスするクエリに対してテストしてください。

セッション開始オーバーライドとネイティブ実行

Fabric機能のロールアウトは、セッション開始時にベースライン値を上書きすることがあります。

Configuration ランタイム2.0の基準値 パブリック本番リージョンにおけるランタイム 2.0 セッション開始値 移住の考慮
spark.gluten.sql.columnar.costBasedFallback.enabled false true 2026年10月16日に記録された本番展開により、Sparkへのコストベースのフォールバックが可能になりました。 クエリプランやパフォーマンスを再確認し、その導入前にテストしたワークロードも含めて再確認してください。
spark.sql.parquet.native.writer.complexTypes.enabled false true 配列、マップ、構造体のネイティブParquet書き込みと下流の読み取りをテストします。

ネイティブ実行エンジンを使用する場合、回帰テストに以下のチェックを含めてください:

  • 列単位のバッチサイズデフォルトが4,096から10,240に増加する中でメモリ使用量を検証します。
  • ソートベースの列指向シャッフルのしきい値が100,000パーティションから4,000パーティションに減少した場合の、シャッフルプランとパフォーマンスを比較してください。
  • 正規表現の結果とパフォーマンスを比較してください。 ネイティブエンジンのJava正則表現のサポートは無効から有効に変わり、すべての正則表現を Spark にフォールバックさせる設定値も、true から false に変わります。

Fabric では Apache Spark 4.1 のデフォルトは異なる形で維持されます

Fabric Runtime 2.0は、以下のApache Spark 4.1のデフォルトを意図的に上書きしています。 上流のSpark 4.1のデフォルトがFabricで変更されずに適用されるとは限りません。

Configuration Apache Spark 4.1 デフォルト Fabric Runtime 2.0 の値
spark.eventLog.compress true false
spark.eventLog.rolling.enabled true false
spark.sql.ansi.enabled true false
spark.sql.catalog.spark_catalog builtin org.apache.spark.sql.delta.catalog.DeltaCatalog
spark.sql.hive.metastore.version 2.3.10 2.3.2

Spark SQLとDataFrameの挙動

Spark 4.1は、クエリ結果を変更したり、以前は受け入れられていたクエリが失敗したりする動作変更を導入します。 特にANSI SQLの挙動、キャスト、日付とタイムスタンプの操作、データ型、JDBCマッピング、廃止されたSQL構成に注目してください。

以下の比較を行う回帰テストを実行します:

  • 型、精度、スケール、ヌルアビリティを含む出力スキーマ。
  • 行数と結果の集計。
  • ヌル、オーバーフロー、ゼロ除算、無効キャストの挙動。
  • 日付、タイムスタンプ、タイムゾーン、インターバルの結果。
  • JDBCのソースとシンクの型マッピング。
  • 重要なワークロードに対するクエリ計画とパフォーマンス。

レガシー互換性設定を恒久的な移行戦略として使わないでください。 一時的に障害を特定するために使う場合は、移行を完了する前に影響を受けたコードを更新し設定を削除してください。 動作の変更点全セットについては、 Spark SQL移行ガイドをご覧ください。

Spark上のPythonおよびpandas API

Runtime 2.0はPython 3.11からPython 3.13へ移行し、Spark 4.1で導入されたPySparkの変更を含みます。 Spark 4.1はまた、pandas、NumPy、PyArrowの最低サポートバージョンを引き上げ、以前のリリースで非推奨となったAPIを削除しています。

Spark上の一般的な pandas API の更新には以下のようなものがあります:

  • DataFrame.iteritemsとSeries.iteritemsをitemsに置き換えましょう。
  • DataFrame.appendとSeries.appendをps.concatに置き換えましょう。
  • カテゴリカル演算から削除された inplace パラメータを割り当てに置き換えます。
  • inclusiveやSeries.str.replace(regex=...)など、変更されたパラメータ名やデフォルトを確認しましょう。
  • 結果列名、インデックス名、dtype、順序を検証します。

完全なリストについては 、PySparkの移行ガイドをご覧ください。

JavaおよびScalaアプリケーション

Scala 2.13はScala 2.12とバイナリ互換性がありません。 Runtime 1.3 JARをRuntime 2.0で再利用すると、ソースコードが変更されていなくてもクラス読み込みエラーが発生することがあります。 別のRuntime 2.0アーティファクトを構築し、すべてのScalaクロスビルド依存関係を更新してください。

Spark 4.1は内部サーブレットAPI参照を javax から jakartaに変更します。 カスタムリスナー、Spark拡張機能、Spark内部と相互作用するライブラリをレビューしてください。 その他のエンジンレベルの変更については、 Spark Core移行ガイドをご覧ください。

ストリーミングワークロードとコネクタ

Runtime 1.3に含まれる廃止されたこの EventHubConnector はRuntime 2.0では利用できません。 Azure Event Hubs の Kafka 互換エンドポイントで Apache Spark Kafka コネクターを使いましょう。 セットアップのガイダンスについては、Apache Kafka 用 Azure Event Hubs で Apache Spark を使用する をご覧ください。

該当するシナリオでは、Fabricイベントストリームを使用してストリーミングデータを取り込み、Spark Structured Streamingでノートブック上で処理することもできます。 詳細については、「Spark Structured Streamingのノートブックから Microsoft Fabric のイベントストリームをクエリする」をご覧ください。

各構造化ストリーミングワークロードについて:

  • Runtime 2.0のクエリが既存のチェックポイントのコピーから再開できるかどうかをテストします。
  • ステートフル操作、イベントタイムのウォーターマーク、トリガー、ソースおよびシンクオプション、出力スキーマの検証を行います。
  • 検証が完了するまで、ソースデータと元のチェックポイントを保持しておきましょう。
  • チェックポイントが互換性がない場合は、新しいチェックポイントでコントロールリスタートを計画しましょう。 再生やスキップされた入力を考慮し、再起動前にシンクを冪等にしてください。

上流互換性の変更については Structured Streaming移行ガイド を確認してください。

Delta Lake テーブル

Delta Lakeは既存のテーブルに対して後方互換性を維持しているため、Runtime 2.0はRuntime 1.3で作成されたテーブルと連携できます。 しかし、新しいテーブル機能を有効にすると、テーブルのリーダーまたはライタープロトコルが上がり、古いエンジンや他のFabric環境がテーブルを使えなくなります。

初期のランタイム移行中:

  • テーブルプロトコルをアップグレードしたり、Delta Lake 4.2の機能を有効にしたりしないでください。
  • 新たに作成されたテーブルおよび既存のテーブルの機能やプロトコルバージョンを検査してください。 Runtime 2.0では、spark.databricks.delta.properties.defaults.enableDeletionVectors を trueに設定します。手動で機能を有効化することで互換性が保たれると考えるのではなく、結果としてのテーブルメタデータを検証してください。
  • テスト読み込み、書き込み、マージ、スキーマの進化、保守操作、並行アクセス。
  • SQL分析エンドポイント、Power BI、パイプライン、データフロー、イベントストリーム、外部エンジンなど、各テーブルを読み書きするすべてのエンジンを特定しましょう。
  • すべてのコンシューマーがそれをサポートするようになってから、新しいDelta機能を有効にしてください。

Delta Lake 4.2特有の機能はFabric上で実験的であり、Spark体験に限定されています。 サポートマトリックスおよびデフォルトプロトコルバージョンについては、 Delta Lakeのテーブル形式相互運用性を参照してください。

ワークロードを移行

本番ワークスペースのランタイムをすぐに変更するのではなく、段階的な移行を使いましょう。

1. Runtime 1.3のワークロードを洗い出す

次の情報を記録しておきます。

  • ノートブック、Sparkジョブの定義、パイプライン、スケジュール、そして依存項目。
  • ワークスペースレベルおよびアイテムレベルの環境割り当て。
  • Sparkの設定、レガシー互換性設定も含めて。
  • 公開、プライベート、カスタム ライブラリとその解決されたバージョン。
  • カスタムJARファイル、Pythonホイール、Rパッケージ、ネイティブライブラリ、初期化ロジックなどです。
  • データソース、宛先、シークレット、接続、ネットワーク要件。
  • デルタテーブルとそれらのテーブルの非Sparkコンシューマー。
  • ストリーミングチェックポイント、スキーマ、オフセット、復旧要件
  • 期待される出力スキーマ、行数、データ品質チェック、パフォーマンスベースライン。

カスタムライブラリ、ネイティブコード、Scala、ストリーミング状態、高度なDelta機能を使うワークロードを優先してください。

2. ランタイム2.0テスト環境の作成

別の環境項目を作成し、実行時として 2.0(Spark 4.1、Delta 4.2) を選択します。 必要なライブラリを追加し、環境を保存して公開します。 環境を開発またはテストワークスペース内の代表的なノートブックや Spark ジョブ定義のコピーにアタッチします。

もし本番環境でまだRuntime 1.3を使っているなら、テストが完了するまではランタイムを変更しないでください。 検証時に既存の構成にロールバックできるよう、その構成を利用可能な状態にしておいてください。

Runtime 2.0のアップデートがデフォルトチャネルに到達する前に検証するには、テスト環境内の早期アクセスリリースチャネルをご利用ください。 詳細については、Fabricのランタイムリリースチャネルを参照してください。

3. ライブラリとコードの更新

互換性レビューで特定された変更点を適用します:

  1. 欠落している組み込みパッケージを明示的な環境の依存関係に置き換えましょう。
  2. Python 3.13、Java 21、Scala 2.13、Azure Linux 3.0をサポートしていないパッケージをアップグレードまたは置き換えてください。
  3. カスタムJARファイルやネイティブバイナリを再構築しましょう。
  4. アップデートにより、PySpark と pandas API on Spark の呼び出しが削除されました。
  5. EventHubConnectorをKafkaコネクターに置き換えてください。
  6. Runtime 2.0で利用できない構成のSpark設定を削除し、デフォルトが変更された構成の明示的なオーバーライドを確認しましょう。
  7. レガシー設定に恒久的に依存するのではなく、Spark SQLの挙動の違いをコード内で解決しましょう。
  8. この段階では既存のデルタテーブル機能やプロトコルを変更しないようにしてください。

4. 適合性と回帰テストを実行する

同じ代表的な入力をRuntime 1.3とRuntime 2.0で実行してください。 比較:

  • 完了状況、ログ、警告、再試行。
  • スキーマとデータ型。
  • 行レベルと集計結果。
  • デルタテーブルの歴史とプロトコル。
  • ストリーミングの進行状況、状態、レイテンシー、重複処理。
  • 実行時間、リソース使用、コスト
  • 下流の結果は、SQL 分析エンドポイント、Power BI、パイプライン、その他のコンシューマーで使用されます。

成功したランだけでなく、失敗や復旧のテストも含めてください。 テストセッションの再起動、ジョブリトライ、チェックポイントの復旧、そして並行テーブルアクセス。

5. ランタイム2.0の展開

ワークロードを制御されたバッチ単位で移動:

  1. 検証済みのRuntime 2.0環境を公開します。
  2. 少量の本番環境のノートブックやSparkジョブ定義に添付してください。
  3. バッチを実行し、出力や下流のコンシューマーを監視します。
  4. 観察期間終了後も残りのワークロードを続けてください。
  5. アイテムレベルの移行が完了した後にのみ、Runtime 2.0をワークスペースのデフォルトとして設定してください。

ワークスペースのランタイムを変更すると、新しいSparkセッションに影響が出ます。 既存のセッションは終了するまで現在のランタイムを使い続けます。

6. ロールバック手段を確保する

Runtime 1.3の環境、アーティファクト、ライブラリ仕様、ストリーミングチェックポイントは、Runtime 2.0の観察期間が終了するまで保持してください。 ロールバックするには、Runtime 1.3環境を再接続するか、前のワークスペースランタイムを復元して新しいSparkセッションを開始してください。

Important

デルタプロトコルのアップグレードは一般的に元に戻せません。 Runtime 2.0の検証を完了し、すべてのテーブルコンシューマーとの互換性を確認するまでは、プロトコルを上げるテーブル機能を有効にしないでください。

移行チェックリスト

移行を完了する前に、以下の点を確認してください:

  • [ ] 必要なすべてのPythonおよびRパッケージは明示的に利用可能で、Python 3.13またはR 4.5とも互換性があります。
  • [ ] カスタムJARファイルはJava 21、Scala 2.13、Spark 4.1を対象としています。
  • [ ] ネイティブ依存関係はAzure Linux 3.0で動作します。
  • [ ] ワークスペース、環境、ノートブック、Sparkジョブ定義の設定は削除されたSpark設定を使用しません。
  • [ ] ワークロードは、変更された Runtime 2.0 Spark の構成の既定値に対してテストされます。
  • [ ] Spark SQLとPySpark回帰テストは合格しました。
  • [ ] Event HubsのワークロードはKafkaコネクタを使用します。
  • [ ] 構造化ストリーミングワークロードは設計通りに再起動と回復を行います。
  • [ ] デルタテーブルのプロトコルと機能はすべてのコンシューマーと互換性があります。
  • [ ] データの品質、パフォーマンス、コストの結果はあなたの受け入れ基準を満たしています。
  • [ ] 本番リリース、監視、ロールバック手順は文書化・テストされています。

関連するコンテンツ

  • 最終更新: