Migrar do Fabric Runtime 1.3 para o Runtime 2.0

Fabric Runtime 2.0 é a versão mais recente geralmente disponível (GA) e o runtime padrão para cargas de trabalho do Apache Spark no Microsoft Fabric. Ele atualiza o sistema operacional, Java, Scala, Python, R, Apache Spark e Delta Lake. Como várias dessas atualizações cruzam os limites das versões principais, valide seus notebooks, definições de trabalhos do Spark, bibliotecas e pipelines de dados antes de mover cargas de trabalho de produção do Runtime 1.3.

Este guia descreve as mudanças que podem afetar uma migração e fornece um processo em etapas para mover suas cargas de trabalho para o Runtime 2.0.

O que mudou no Runtime 2.0

A tabela a seguir compara os componentes principais do Runtime 1.3 e do Runtime 2.0.

Component	Runtime 1.3	Runtime 2.0	Consideração migratória
Fase de liberação	Fim do suporte anunciado (EOSA)	GA	Migre cargas de trabalho de produção para o tempo de execução GA suportado.
Apache Spark	3.5.5	4.1.1	Revise as mudanças de comportamento do Spark 4.1 e as APIs removidas.
Lago Delta	3.2	4.2	Valide as características das tabelas e a compatibilidade do protocolo em todas as cargas de trabalho do Fabric que utilizam suas tabelas.
Java	11	21	Reconstruir e testar bibliotecas Java e dependências da Interface Nativa Java (JNI).
Scala	2.12.17	2.13.16	Recompile os arquivos JAR do Scala para o Scala 2.13. Artefatos do Scala 2.12 e 2.13 não são compatíveis binariamente.
Python	3.11	3.13	Confirme que cada pacote Python oferece uma versão compatível com Python 3.13 e um wheel para Linux.
R	4.4.1	4.5.2	Reinstale e teste pacotes personalizados de R. O SparkR está obsoleto no Spark 4.1.
Sistema operacional	Azure Linux 2.0 (Mariner 2.0)	Azure Linux 3.0 (Mariner 3.0)	Reconstrua bibliotecas nativas e binários personalizados para Azure Linux 3.0.

O Runtime 2.0 também oferece novas funcionalidades do Apache Spark 4.1, incluindo o tipo de dado VARIANT, funções SQL definidas pelo usuário, variáveis de sessão, sintaxe de pipes, colação de strings, a API de Fonte de Dados em Python, funções de tabela definidas pelo usuário em Python, perfilamento unificado do PySpark e novas APIs de gerenciamento de estado e depuração de Streaming Estruturado. Para uma visão geral, veja Runtime 2.0 no Fabric.

Reveja as mudanças de compatibilidade

Revise as áreas a seguir antes de mudar um espaço de trabalho ou ambiente para Runtime 2.0.

Bibliotecas embutidas e personalizadas

O Runtime 2.0 remove vários pacotes pré-instalados do Python e do R que estavam disponíveis no Runtime 1.3. Reduzir o conjunto padrão de pacotes mantém o tempo de execução enxuto e reduz a superfície de exposição a possíveis incidentes de segurança. Um pacote que estava disponível sem configuração no Runtime 1.3 pode precisar ser adicionado explicitamente ao seu ambiente do Runtime 2.0.

Use o Gerenciador de Bibliotecas para adicionar apenas os pacotes que sua carga de trabalho exige e, em seguida, salvar e publicar o ambiente. O Gerenciador de Bibliotecas resolve as dependências exigidas do pacote, então não adicione cada dependência individualmente nos inventários a seguir. Não presuma que uma biblioteca está disponível ou que sua versão permaneceu inalterada:

Compare os inventários dos pacotes Runtime 1.3 e Runtime 2.0 no repositório de versões do runtime do Fabric.
Adicione bibliotecas faltantes de PyPI, Conda, Maven, R ou personalizadas em um ambiente e publique-o.
Fixe as versões para cargas de trabalho de produção para tornar a resolução de dependências reproduzível.
Confirme que os pacotes Python suportam Python 3.13. Pacotes com extensões nativas devem fornecer um wheel compatível para Linux ou compilar com sucesso no Azure Linux 3.0.
Substitua as dependências do Scala 2.12 por artefatos do Scala 2.13. Nomes de artefatos comumente incluem a versão binária Scala, como _2.12 ou _2.13.
Recompile arquivos JAR personalizados para Java 21, Scala 2.13 e Spark 4.1. Teste as dependências transitivas quanto a conflitos com bibliotecas fornecidas em tempo de execução.
Reconstrua bibliotecas nativas personalizadas para Azure Linux 3.0.

O Fabric migra as especificações das bibliotecas quando você altera o tempo de execução de um ambiente existente, mas não pode garantir que essas bibliotecas permaneçam compatíveis. A publicação falha quando a resolução de dependências encontra um conflito. Para opções de instalação de pacotes e modos de publicação, veja Gerenciar bibliotecas em ambientes Fabric.

Pacotes removidos do ambiente padrão

Os inventários a seguir incluem pacotes voltados para o usuário e suas dependências de baixo nível ou transitivas. Pesquise nessas listas por pacotes que sua carga de trabalho do Runtime 1.3 usa. Se um pacote estiver listado, adicione uma versão compatível com Python 3.13 ou R 4.5 pelo Gerenciador de Bibliotecas no seu ambiente Runtime 2.0.

Ambiente Python: pacotes 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`

Ambiente Python: 24 pacotes 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`

Ambiente R: pacotes 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`

Note

Se a proteção de acesso de saída ou uma rede virtual gerenciada impedir o acesso a repositórios públicos, baixe arquivos wheel compatíveis ou hospede um espelho de pacote. Para instruções, veja Gerenciar bibliotecas com acesso limitado à rede no Fabric.

Mudanças na configuração do Spark

Runtime 2.0 adiciona e remove configurações do Spark e altera alguns valores padrão. O Fabric também usa padrões diferentes do Apache Spark para algumas configurações.

Antes de migrar, revise as configurações do Spark que você configurou para seus espaços de trabalho, ambientes, notebooks e definições de trabalhos do Spark. Remova configurações que não sejam mais suportadas e teste cargas de trabalho que dependam de padrões alterados. Use os padrões de runtime, a menos que a documentação oriente você a mudar alguma configuração.

Mudanças notáveis de valor padrão

A tabela a seguir lista alterações da linha de base selecionadas. Não definido significa que a linha de base não define explicitamente um valor; não significa que o recurso está desativado.

Configuration	Valor de runtime 1.3	Valor de runtime 2.0	Consideração migratória
`spark.checkpoint.compress`	`false`	`true`	Os arquivos checkpoint são comprimidos por padrão. Valide a interoperabilidade dos checkpoints e o comportamento de armazenamento.
`spark.databricks.delta.optimizeWrite.enabled`	`true`	Não definido	A propriedade não foi removida. Valide o comportamento eficaz de escrita otimizada com suas configurações de tabela, sessão e perfil de recursos.
`spark.databricks.delta.optimizeWrite.partitioned.enabled`	`false`	`true`	Valide a taxa de transferência de gravação e os tamanhos dos arquivos de saída para tabelas Delta particionadas.
`spark.hadoop.parquet.block.size`	`1073741824` (1 GiB)	`134217728` (128 MiB)	Os gravadores de Parquet visam blocos menores. Valide tamanhos de arquivos e desempenho de leitura subsequente.
`spark.microsoft.delta.optimize.fast.enabled`	`false`	`true`	`OPTIMIZE` pode pular o trabalho a menos que critérios de contagem de arquivos ou tamanho estimado de compactação sejam atendidos. Valide os resultados da manutenção.
`spark.microsoft.delta.optimize.fileLevelTarget.enabled`	`false`	`true`	Arquivos que antes atingiram pelo menos metade do tamanho alvo de compactação não são compactados novamente. Valide o layout do arquivo após `OPTIMIZE`.
`spark.microsoft.delta.targetFileSize.adaptive.enabled`	`false`	`true`	A Delta calcula o tamanho alvo do arquivo com base no tamanho da tabela. Valide os tamanhos de arquivo resultantes e o desempenho de leitura.
`spark.speculation.multiplier`	`1.5`	`3`	Uma tarefa deve ser executada três vezes mais devagar que a mediana antes que Spark a considere para execução especulativa.
`spark.speculation.quantile`	`0.75`	`0.9`	Spark espera 90% das tarefas serem concluídas antes de considerar a execução especulativa.
`spark.sql.files.maxPartitionBytes`	`134217728` (128 MiB)	`536870912` (512 MiB)	As varreduras de arquivos podem acomodar mais dados em cada partição. Valide paralelismo e uso da memória do executor.
`spark.sql.maxSinglePartitionBytes`	`Long.MaxValue`	`128m`	Uma única partição é limitada por padrão a 128 MiB. Valide consultas que produzam partições únicas grandes.
`spark.sql.orc.compression.codec`	`snappy`	`zstd`	Novas escritas ORC usam compressão Zstandard por padrão. Valide compatibilidade e desempenho com leitores downstream.
`spark.sql.sources.v2.bucketing.enabled`	`false`	`true`	O Spark permite por padrão joins particionados por armazenamento e outros comportamentos de bucketing da Data Source V2. Valide planos e resultados de consultas.
`spark.sql.sources.v2.bucketing.pushPartValues.enabled`	`false`	`true`	O Spark pode propagar valores de partição compatíveis para o bucketing da Data Source V2. Valide planos de consulta para tabelas com bucket.

Runtime 2.0 também usa ROCKSDB em vez de LEVELDB para spark.shuffle.service.db.backend e define spark.shuffle.service.removeShuffle para true. O Spark usa o serviço externo de shuffle para excluir blocos de shuffle desnecessários para executores desalocados.

O carregamento de snapshots paralelos Delta, ignorar dados em paralelo e carregamento de snapshots no lado do driver também mudam de false para true. Teste a latência de consultas e o uso de recursos do driver, especialmente para consultas que acessam múltiplas tabelas Delta.

Sobrescritas de início de sessão e execução nativa

As implantações de recursos do Fabric podem substituir os valores de linha de base quando uma sessão é iniciada.

Configuration	Valor de referência do Runtime 2.0	Valor de início de sessão do Runtime 2.0 em regiões públicas de produção	Consideração migratória
`spark.gluten.sql.columnar.costBasedFallback.enabled`	`false`	`true`	A implantação em produção registrada em 16 de outubro de 2026 permite fallback baseado em custos para o Spark. Revise os planos de consulta e o desempenho, incluindo as cargas de trabalho testadas antes dessa implantação.
`spark.sql.parquet.native.writer.complexTypes.enabled`	`false`	`true`	Teste gravações nativas do Parquet e leituras subsequentes para arrays, mapas e structs.

Quando você usa o motor de execução nativo, inclua as seguintes verificações em seus testes de regressão:

Valide o uso da memória com o tamanho padrão do lote colunar aumentando de 4.096 para 10.240.
Compare os planos e o desempenho de embaralhamento com o limiar de embaralhamento colunar baseado em ordenação, que diminui de 100.000 para 4.000 partições.
Compare os resultados e o desempenho de expressões regulares. O suporte nativo a regex do Java muda de desativado para ativado, e a configuração que redireciona todas as expressões regex para o Spark muda de true para false.

Os padrões do Apache Spark 4.1 são preservados de maneira diferente no Fabric

O Fabric Runtime 2.0 intencionalmente sobrescreve os seguintes padrões do Apache Spark 4.1. Não presuma que um padrão upstream do Spark 4.1 se aplica igual no Fabric.

Configuration	Apache Spark 4.1 padrão	Valor do 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`

Comportamento do Spark SQL e do DataFrame

O Spark 4.1 introduz mudanças de comportamento que podem alterar resultados de consultas ou fazer com que consultas previamente aceitas falhem. Preste atenção especial ao comportamento do ANSI SQL, casts, operações de data e timestamp, tipos de dados, mapeamentos JDBC e configurações SQL obsoletas.

Execute testes de regressão que comparem:

Esquemas de saída, incluindo tipo, precisão, escala e aceita nulos.
Contagem de linhas e resultados agregados.
Comportamento nulo, overflow, divisão por zero e comportamento de conversão inválida.
Data, marca temporal, fuso horário e resultados do intervalo.
Mapeamentos de origem e sink do JDBC.
Planos de consulta e desempenho para cargas de trabalho críticas.

Não use configurações de compatibilidade legadas como estratégia de migração permanente. Se você usar temporariamente um para isolar uma falha, atualize o código afetado e remova a configuração antes de concluir a migração. Para o conjunto completo de mudanças de comportamento, veja o guia de migração SQL do Spark.

API de Python e pandas no Spark

Runtime 2.0 migra do Python 3.11 para o Python 3.13 e inclui as mudanças no PySpark introduzidas no Spark 4.1. O Spark 4.1 também eleva as versões mínimas suportadas de pandas, NumPy e PyArrow e remove APIs que estavam obsoletas em versões anteriores.

Atualizações comuns da API do pandas no Spark incluem:

Substitua DataFrame.iteritems e Series.iteritems por items.
Substitua DataFrame.append e Series.append por ps.concat.
Substitua os parâmetros removidos nas operações categóricas por atribuições.
Revise nomes e valores padrão de parâmetros alterados, como inclusive e Series.str.replace(regex=...).
Valide nomes de colunas de resultados, nomes de índice, dtypes e ordenação.

Para a lista completa, consulte o guia de migração do PySpark.

Aplicações em Java e Scala

Scala 2.13 não é binariamente compatível com Scala 2.12. Reutilizar um JAR do Runtime 1.3 no Runtime 2.0 pode causar erros de carregamento de classes mesmo quando o código-fonte não mudou. Construa um artefato separado do Runtime 2.0 e atualize todas as dependências cross-built do Scala.

O Spark 4.1 também altera suas referências internas de API de servlets de javax para jakarta. Revise listeners personalizados, extensões do Spark e bibliotecas que interajam com os componentes internos do Spark. Para outras mudanças no nível do motor, veja o guia de migração do Spark Core.

Cargas de trabalho e conectores de streaming

O obsoleto EventHubConnector incluído no Runtime 1.3 não está disponível no Runtime 2.0. Use o conector Apache Spark Kafka com o endpoint compatível com Kafka para Hubs de Eventos do Azure. Para orientações de configuração, veja Usar o Apache Spark com os Hubs de Eventos do Azure para o Apache Kafka.

Para cenários aplicáveis, você também pode avaliar o eventstream do Fabric para ingerir dados de streaming e processá-los em um notebook com o Spark Structured Streaming. Para mais informações, veja Consultar eventstream no Microsoft Fabric a partir de um notebook com Spark Structured Streaming.

Para cada carga de trabalho de Streaming Estruturado:

Teste se a consulta do Runtime 2.0 pode reiniciar a partir de uma cópia do checkpoint existente.
Valide operações com estado, marcas d'água em tempo de evento, gatilhos, opções de origem e destino, e esquemas de saída.
Mantenha os dados de origem e o checkpoint original disponíveis até a validação estar concluída.
Se um checkpoint for incompatível, planeje um reinício controlado com um novo checkpoint. Leve em conta as entradas rejogadas ou puladas, e deixe o sink idempotente antes de reiniciar.

Revise o guia de migração do Structured Streaming para mudanças de compatibilidade upstream.

Tabelas Delta Lake

A Delta Lake mantém compatibilidade retroativa para tabelas existentes, então o Runtime 2.0 pode funcionar com tabelas criadas pelo Runtime 1.3. No entanto, ativar um recurso mais recente pode elevar o protocolo de leitor ou gravador da tabela e impedir que motores antigos ou outras experiências Fabric usem a tabela.

Durante a migração inicial em tempo de execução:

Não atualize os protocolos da tabela nem ative recursos do Delta Lake 4.2.
Inspecione os recursos e as versões do protocolo das tabelas recém-criadas, bem como das tabelas existentes. Runtime 2.0 define spark.databricks.delta.properties.defaults.enableDeletionVectors para true; verifique os metadados resultantes da tabela em vez de assumir que evitar a habilitação manual de funcionalidades preserva a compatibilidade.
Teste leituras, escritas, fusões, evolução de esquemas, operações de manutenção e acesso concorrente.
Identifique cada motor que lê ou escreve cada tabela, incluindo o endpoint de análise SQL, Power BI, pipelines, fluxos de dados, fluxos de eventos e motores externos.
Ative um novo recurso Delta somente depois que todos os consumidores o suportarem.

Recursos específicos do Delta Lake 4.2 são experimentais no Fabric e limitados às experiências Spark. Para as versões da matriz de suporte e do protocolo padrão, veja interoperabilidade do formato de tabela Delta Lake.

Migrar suas cargas de trabalho

Use uma migração em etapas em vez de mudar imediatamente o runtime de um workspace de produção.

1. Inventarie suas cargas de trabalho do Runtime 1.3

Registre as seguintes informações:

Notebooks, definições de trabalho do Spark, pipelines, agendamentos e itens dependentes.
Atribuições de ambiente em nível de espaço de trabalho e item.
Configurações do Spark, incluindo quaisquer configurações de compatibilidade legadas.
Bibliotecas públicas, privadas e personalizadas e suas versões resolvidas.
Arquivos JAR personalizados, wheels do Python, pacotes R, bibliotecas nativas e lógica de inicialização.
Fontes de dados, destinos, credenciais, conexões e requisitos de rede.
tabelas Delta e todos os consumidores não Spark dessas tabelas.
Checkpoints de streaming, esquemas, offsets e requisitos de recuperação.
Esquemas de saída esperados, contagens de linhas, verificações de qualidade de dados e linhas de base de desempenho.

Priorize as cargas de trabalho que utilizem bibliotecas personalizadas, código nativo, Scala, estado de streaming ou recursos avançados do Delta.

2. Criar um ambiente de teste do Runtime 2.0

Crie um item de ambiente separado e selecione 2.0 (Spark 4.1, Delta 4.2) como seu runtime. Adicione as bibliotecas necessárias, salve o ambiente e publique o ambiente. Anexe o ambiente a cópias de notebooks representativos e definições de jobs do Spark em um espaço de trabalho de desenvolvimento ou teste.

Se seu workspace de produção ainda usa o Runtime 1.3, não mude seu runtime até que os testes estejam concluídos. Mantenha a configuração existente disponível para rollback durante a validação.

Para validar as próximas atualizações do Runtime 2.0 antes que cheguem ao canal padrão, use o canal de lançamento antecipado no seu ambiente de teste. Para mais informações, veja os canais de lançamento em tempo de execução do Fabric.

3. Atualizar bibliotecas e código

Aplique as mudanças identificadas na revisão de compatibilidade:

Substitua pacotes embutidos ausentes por dependências explícitas do ambiente.
Atualize ou substitua pacotes que não suportem Python 3.13, Java 21, Scala 2.13 ou Azure Linux 3.0.
Reconstrua arquivos JAR personalizados e binários nativos.
Atualize as chamadas da API do PySpark e da API do pandas no Spark removidas.
Substitua EventHubConnector pelo conector Kafka.
Remova as configurações do Spark para configurações que não estão disponíveis no Runtime 2.0 e revise as sobrescritas explícitas de configurações cujas configurações padrão mudaram.
Resolva diferenças de comportamento do Spark SQL no código em vez de depender permanentemente de configurações legadas.
Mantenha as características e protocolos existentes da tabela Delta inalterados durante essa fase.

4. Executar testes de compatibilidade e regressão

Execute as mesmas entradas representativas no Runtime 1.3 e Runtime 2.0. Comparar:

Status de conclusão, registros, avisos e novas tentativas.
Esquemas e tipos de dados.
Resultados em nível de linha e agregados.
Histórico e protocolo da tabela Delta.
Progresso do streaming, estado, latência e tratamento de duplicados.
Tempo de execução, uso de recursos e custo.
Resultados downstream no endpoint de análise SQL, no Power BI, em pipelines e em outros consumidores.

Inclua testes de falha e recuperação, não apenas execuções bem-sucedidas. Reinicios de sessões de teste, retentações de trabalho, recuperação de checkpoint e acesso concorrente à tabela.

5. Lançar o Runtime 2.0

Transferir as cargas de trabalho em lotes controlados:

Publique o ambiente validado do Runtime 2.0.
Anexe-o a um pequeno conjunto de notebooks de produção ou definições de trabalhos do Spark.
Execute o lote e monitore as saídas e os consumidores downstream.
Continuar com as cargas de trabalho restantes após o período de observação.
Defina o Runtime 2.0 como padrão do workspace somente após a conclusão da migração em nível de item.

Mudar o tempo de execução do workspace afeta as novas sessões do Spark. Sessões existentes continuam usando seu runtime atual até pararem.

6. Manter um caminho de rollback

Mantenha o ambiente do Runtime 1.3, artefatos, especificações da biblioteca e checkpoints de streaming até o término do período de observação do Runtime 2.0. Para reverter, reconecte o ambiente Runtime 1.3 ou restaure o runtime anterior do workspace e inicie uma nova sessão do Spark.

Importante

Uma atualização do protocolo Delta não é geralmente reversível. Não ative recursos de tabela que elevem o protocolo até que você tenha concluído a validação do Runtime 2.0 e confirmado a compatibilidade com todos os consumidores de tabelas.

Lista de verificação de migração

Antes de concluir a migração, confirme que:

[ ] Todo pacote Python e R exigido está explicitamente disponível e compatível com Python 3.13 ou R 4.5.
[ ] Arquivos JAR personalizados têm como alvo Java 21, Scala 2.13 e Spark 4.1.
[ ] Dependências nativas funcionam no Azure Linux 3.0.
[ ] Configurações de espaço de trabalho, ambiente, notebook e definição de trabalho do Spark não usam configurações removidas do Spark.
[ ] As cargas de trabalho são testadas em relação aos padrões de configuração alterados do Runtime 2.0 do Spark.
[ ] Testes de regressão do Spark SQL e do PySpark passam.
[ ] As cargas de trabalho dos Hubs de Eventos usam o conector Kafka.
[ ] Cargas de trabalho de Streaming Estruturado reiniciam e recuperam conforme projetado.
[ ] Protocolos e recursos da tabela Delta permanecem compatíveis com todos os consumidores.
[ ] Qualidade dos dados, desempenho e resultados de custo atendem aos seus critérios de aceitação.
[ ] Os procedimentos de lançamento, monitoramento e rollback em produção são documentados e testados.

Comentários

Esta página foi útil?

Última atualização em 2026-10-23