Partilhar via

Tempos de execução do Azure Synapse

  • Artigo

Os pools do Apache Spark no Azure Synapse usam tempos de execução para unir versões de componentes essenciais, como otimizações, pacotes e conectores do Azure Synapse, com uma versão específica do Apache Spark. Cada tempo de execução é atualizado periodicamente para incluir novas melhorias, recursos e patches. Ao criar um pool do Apache Spark sem servidor, selecione a versão correspondente do Apache Spark. Com base nisso, o pool vem pré-instalado com os componentes e pacotes de tempo de execução associados.

Os tempos de execução têm as seguintes vantagens:

  • Tempos de arranque de sessão mais rápidos
  • Compatibilidade testada com versões específicas do Apache Spark
  • Acesso a conectores populares e compatíveis e pacotes de código aberto

Versões de tempo de execução do Azure Synapse suportadas

Gorjeta

É altamente recomendável atualizar proativamente as cargas de trabalho para uma versão mais recente do tempo de execução do GA, que é o Azure Synapse Runtime for Apache Spark 3.4 (GA)). Consulte o guia de migração do Apache Spark.

A tabela a seguir lista o nome do tempo de execução, a versão do Apache Spark e a data de lançamento das versões suportadas do Azure Synapse Runtime.

Nome do tempo de execução Data de lançamento Fase de lançamento Data de anúncio do fim do suporte Data de Fim do Suporte
Azure Synapse Runtime para Apache Spark 3.4 21 de novembro de 2023 GA (a partir de 8 de abril de 2024) 2º trimestre de 2025 1º trimestre de 2026
Azure Synapse Runtime para Apache Spark 3.3 17 de novembro de 2022 Anunciado o fim do suporte Julho 12th, 2024 3/31/2025
Azure Synapse Runtime para Apache Spark 3.2 8 de julho de 2022 Preterido e logo desativado 8 de julho de 2023 Julho 8, 2024
Azure Synapse Runtime para Apache Spark 3.1 26 de maio de 2021 Preterido e logo desativado 26 de janeiro de 2023 26 de janeiro de 2024
Azure Synapse Runtime para Apache Spark 2.4 15 de dezembro de 2020 Preterido e logo desativado 29 de julho de 2022 29 de setembro de 2023

Estágios de liberação em tempo de execução

Para obter o tempo de execução completo para o ciclo de vida do Apache Spark e as políticas de suporte, consulte Synapse runtime for Apache Spark lifecycle and supportability.

Aplicação de patches em tempo de execução

Os tempos de execução do Azure Synapse para patches do Apache Spark são implementados mensalmente contendo correções de bugs, recursos e segurança para o mecanismo principal, ambientes de linguagem, conectores e bibliotecas do Apache Spark.

Nota

  • As atualizações de manutenção serão aplicadas automaticamente a novas sessões para um determinado pool Apache Spark sem servidor.
  • Você deve testar e validar se seus aplicativos são executados corretamente ao usar novas versões de tempo de execução.

Importante

Patches de segurança Log4j 1.2.x

A biblioteca Log4j de código aberto versão 1.2.x tem vários CVEs (Common Vulnerabilities and Exposures) conhecidos, conforme descrito aqui.

Em todos os tempos de execução do Synapse Spark Pool, corrigimos os JARs do Log4j 1.2.17 para mitigar as seguintes CVEs: CVE-2019-1751, CVE-2020-9488, CVE-2021-4104, CVE-2022-23302, CVE-2022-2330, CVE-2022-23307

O patch aplicado funciona removendo os seguintes ficheiros que são necessários para invocar as vulnerabilidades:

  • org/apache/log4j/net/SocketServer.class
  • org/apache/log4j/net/SMTPAppender.class
  • org/apache/log4j/net/JMSAppender.class
  • org/apache/log4j/net/JMSSink.class
  • org/apache/log4j/jdbc/JDBCAppender.class
  • org/apache/log4j/chainsaw/*

Embora as classes acima não tenham sido usadas nas configurações padrão do Log4j no Synapse, é possível que algum aplicativo de usuário ainda dependa dele. Se seu aplicativo precisar usar essas classes, use o Gerenciamento de Biblioteca para adicionar uma versão segura do Log4j ao Spark Pool. Não use o Log4j versão 1.2.17, pois ele estaria reintroduzindo as vulnerabilidades.

A política de patch difere com base no estágio do ciclo de vida do tempo de execução:

  • Tempo de execução geralmente disponível (GA): não receba atualizações nas versões principais (ou seja, 3.x -> 4.x). E atualizará uma versão secundária (ou seja, 3.x -> 3.y) desde que não haja impactos de depreciação ou regressão.

  • Tempo de execução da visualização: Nenhuma atualização de versão principal, a menos que estritamente necessário. As versões secundárias (3.x -> 3.y) serão atualizadas para adicionar os recursos mais recentes a um tempo de execução.

  • O tempo de execução do Suporte de Longo Prazo (LTS) é corrigido apenas com correções de segurança.

  • O tempo de execução anunciado para o fim do suporte não terá correções de bugs e recursos. As correções de segurança são retroportadas com base na avaliação de risco.

Migração entre versões do Apache Spark - suporte

Este guia fornece uma abordagem estruturada para usuários que desejam atualizar suas cargas de trabalho do Azure Synapse Runtime for Apache Spark das versões 2.4, 3.1, 3.2 ou 3.3 para a versão mais recente do GA, como a 3.4. A atualização para a versão mais recente permite que os usuários se beneficiem de aprimoramentos de desempenho, novos recursos e medidas de segurança aprimoradas. É importante observar que a transição para uma versão superior pode exigir ajustes no código existente do Spark devido a incompatibilidades ou recursos obsoletos.

Passo 1: Avaliar e planear

  • Avaliar a compatibilidade: comece com a revisão dos guias de migração do Apache Spark para identificar possíveis incompatibilidades, recursos preteridos e novas APIs entre sua versão atual do Spark (2.4, 3.1, 3.2 ou 3.3) e a versão de destino (por exemplo, 3.4).
  • Analise a Base de Código: examine cuidadosamente o código do Spark para identificar o uso de APIs preteridas ou modificadas. Preste especial atenção às consultas SQL e às UDFs (User Defined Functions), que podem ser afetadas pela atualização.

Etapa 2: Criar um novo pool do Spark para teste

  • Criar um novo pool: no Azure Synapse, vá para a seção Pools de faíscas e configure um novo pool de faíscas. Selecione a versão de destino do Spark (por exemplo, 3.4) e configure-a de acordo com seus requisitos de desempenho.
  • Configurar a configuração do pool de faíscas: certifique-se de que todas as bibliotecas e dependências do novo pool do Spark sejam atualizadas ou substituídas para serem compatíveis com o Spark 3.4.

Etapa 3: Migrar e testar seu código

  • Migrar código: atualize seu código para ser compatível com as APIs novas ou revisadas no Apache Spark 3.4. Isso envolve abordar funções obsoletas e adotar novos recursos, conforme detalhado na documentação oficial do Apache Spark.
  • Teste no Ambiente de Desenvolvimento: teste seu código atualizado em um ambiente de desenvolvimento no Azure Synapse, não localmente. Esta etapa é essencial para identificar e corrigir quaisquer problemas antes de passar para a produção.
  • Implantar e monitorar: após testes e validação completos no ambiente de desenvolvimento, implante seu aplicativo no novo pool do Spark 3.4. É fundamental monitorar o aplicativo para quaisquer comportamentos inesperados. Utilize as ferramentas de monitoramento disponíveis no Azure Synapse para acompanhar o desempenho de seus aplicativos Spark.

Pergunta: Que medidas devem ser tomadas na migração do 2.4 para o 3.X?

Resposta: Consulte o guia de migração do Apache Spark.

Pergunta: Recebi um erro quando tentei atualizar o tempo de execução do pool do Spark usando o cmdlet do PowerShell quando eles anexaram bibliotecas.

Resposta: Não use o cmdlet do PowerShell se você tiver bibliotecas personalizadas instaladas em seu espaço de trabalho Synapse. Em vez disso, siga estes passos:

  1. Recrie o Spark Pool 3.3 a partir do zero.
  2. Faça o downgrade do Spark Pool 3.3 para 3.1 atual, remova todos os pacotes anexados e atualize novamente para o 3.3.

Pergunta: Por que não posso atualizar para a versão 3.4 sem recriar um novo pool do Spark?

Resposta: Isso não é permitido a partir da UX, o cliente pode usar o Azure PowerShell para atualizar a versão do Spark. Use "ForceApplySetting", para que todos os clusters existentes (com a versão antiga) sejam desativados.

Consulta de exemplo:

$_target_work_space = @("workspace1", "workspace2")

Get-AzSynapseWorkspace |
    ForEach-Object {
        if ($_target_work_space -contains $_.Name) {
            $_workspace_name = $_.Name
            Write-Host "Updating workspace: $($_workspace_name)"
            Get-AzSynapseSparkPool -WorkspaceName $_workspace_name |
            ForEach-Object {
                Write-Host "Updating Spark pool: $($_.Name)"
                Write-Host "Current Spark version: $($_.SparkVersion)"
        
                Update-AzSynapseSparkPool -WorkspaceName $_workspace_name -Name $_.Name -SparkVersion 3.4 -ForceApplySetting
              }
        }
    }

Conteúdos relacionados