Condividi tramite

Runtime di Azure Synapse

  • Articolo

I pool di Apache Spark in Azure Synapse usano i runtime per collegare le versioni essenziali dei componenti, ad esempio ottimizzazioni, pacchetti e connettori di Azure Synapse con una versione specifica di Apache Spark. Ogni runtime viene aggiornato periodicamente per includere nuovi miglioramenti, funzionalità e patch. Quando si crea un pool di Apache Spark serverless, selezionare la versione di Apache Spark corrispondente. In base a questo, il pool viene preinstallato con i componenti e i pacchetti di runtime associati.

I runtime presentano i vantaggi seguenti:

  • Tempi di avvio delle sessioni più veloci
  • Compatibilità testata con versioni specifiche di Apache Spark
  • Accesso ai connettori più diffusi e compatibili e ai pacchetti open source

Versioni del runtime di Azure Synapse supportate

Suggerimento

È consigliabile aggiornare in modo proattivo i carichi di lavoro a una versione ga più recente del runtime, ovvero Il runtime di Azure Synapse per Apache Spark 3.4 (GA)). Vedere la guida alla migrazione di Apache Spark.

La tabella seguente elenca il nome del runtime, la versione di Apache Spark e la data di rilascio per le versioni di Azure Synapse Runtime supportate.

Nome runtime Data di rilascio Fase di rilascio Data di fine dell'annuncio del supporto Data di validità di fine del supporto
Runtime di Azure Synapse per Apache Spark 3.4 21 novembre 2023 GA (a partire dal 8 aprile 2024) Q2 2025 Q1 2026
Runtime di Azure Synapse per Apache Spark 3.3 17 novembre 2022 fine del supporto annunciato 12 luglio 2024 31/03/2025
Runtime di Azure Synapse per Apache Spark 3.2 8 luglio 2022 deprecato e presto disabilitato 8 luglio 2023 8 luglio 2024
Runtime di Azure Synapse per Apache Spark 3.1 26 maggio 2021 deprecato e presto disabilitato 26 gennaio 2023 26 gennaio 2024
Runtime di Azure Synapse per Apache Spark 2.4 15 dicembre 2020 deprecato e presto disabilitato 29 luglio 2022 29 settembre 2023

Fasi di rilascio del runtime

Per il runtime completo per il ciclo di vita e i criteri di supporto di Apache Spark, vedere Runtime di Synapse per il ciclo di vita e il supporto di Apache Spark.

Applicazione di patch in fase di esecuzione

I runtime di Azure Synapse per le patch apache Spark vengono implementati mensilmente contenenti bug, funzionalità e correzioni di sicurezza per il motore principale di Apache Spark, gli ambienti del linguaggio, i connettori e le librerie.

Nota

  • Gli aggiornamenti di manutenzione verranno applicati automaticamente alle nuove sessioni per un determinato pool di Apache Spark serverless.
  • È necessario testare e verificare che le applicazioni vengano eseguite correttamente quando si usano nuove versioni di runtime.

Importante

Patch di sicurezza log4j 1.2.x

La libreria Log4j open source versione 1.2.x include diverse CVE note (vulnerabilità ed esposizioni comuni), come descritto qui.

In tutti i runtime del pool di Spark Synapse sono state applicate patch ai file JAR Log4j 1.2.17 per attenuare i seguenti CV: CVE-2019-1751, CVE-2020-9488, CVE-2021-4104, CVE-2022-23302, CVE-2022-2330, CVE-2022-23307

La patch applicata funziona rimuovendo i file seguenti necessari per richiamare le vulnerabilità:

  • 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/*

Anche se le classi precedenti non sono state usate nelle configurazioni log4j predefinite in Synapse, è possibile che alcune applicazioni utente possano comunque dipendere da essa. Se l'applicazione deve usare queste classi, usare Gestione librerie per aggiungere una versione sicura di Log4j al pool di Spark. Non usare Log4j versione 1.2.17, perché reintroduce le vulnerabilità.

I criteri di patch differiscono in base alla fase del ciclo di vita del runtime:

  • Runtime disponibile a livello generale: non ricevere aggiornamenti nelle versioni principali ( ovvero 3.x -> 4.x). E aggiornerà una versione secondaria ,ovvero 3.x -> 3.y, purché non ci siano effetti di deprecazione o regressione.

  • Runtime di anteprima: nessun aggiornamento della versione principale, a meno che non sia strettamente necessario. Le versioni secondarie (3.x -> 3.y) verranno aggiornate per aggiungere funzionalità più recenti a un runtime.

  • Il runtime LTS (Long Term Support) viene patchato solo con correzioni di sicurezza.

  • La fine del runtime annunciato dal supporto non include correzioni di bug e funzionalità. Le correzioni di sicurezza vengono backportate in base alla valutazione dei rischi.

Migrazione tra versioni di Apache Spark - Supporto

Questa guida fornisce un approccio strutturato per gli utenti che vogliono aggiornare il runtime di Azure Synapse per i carichi di lavoro apache Spark dalle versioni 2.4, 3.1, 3.2 o 3.3 alla versione ga più recente, ad esempio 3.4. L'aggiornamento alla versione più recente consente agli utenti di trarre vantaggio da miglioramenti delle prestazioni, nuove funzionalità e misure di sicurezza migliorate. È importante notare che la transizione a una versione successiva potrebbe richiedere modifiche al codice Spark esistente a causa di incompatibilità o funzionalità deprecate.

Passaggio 1: Valutare e pianificare

  • Valutazione della compatibilità: iniziare con la revisione delle guide alla migrazione di Apache Spark per identificare eventuali incompatibilità, funzionalità deprecate e nuove API tra la versione di Spark corrente (2.4, 3.1, 3.2 o 3.3) e la versione di destinazione (ad esempio, 3.4).
  • Analizza codebase: esaminare attentamente il codice Spark per identificare l'uso di API deprecate o modificate. Prestare particolare attenzione alle query SQL e alle funzioni definite dall'utente, che potrebbero essere interessate dall'aggiornamento.

Passaggio 2: Creare un nuovo pool di Spark per i test

  • Creare un nuovo pool: in Azure Synapse passare alla sezione Pool di Spark e configurare un nuovo pool di Spark. Selezionare la versione di Spark di destinazione (ad esempio, 3.4) e configurarla in base ai requisiti di prestazioni.
  • Configurare la configurazione del pool di Spark: assicurarsi che tutte le librerie e le dipendenze nel nuovo pool di Spark vengano aggiornate o sostituite per essere compatibili con Spark 3.4.

Passaggio 3: Eseguire la migrazione e testare il codice

  • Eseguire la migrazione del codice: aggiornare il codice in modo che sia conforme alle API nuove o riviste in Apache Spark 3.4. Ciò implica la gestione delle funzioni deprecate e l'adozione di nuove funzionalità, come descritto nella documentazione ufficiale di Apache Spark.
  • Test nell'ambiente di sviluppo: testare il codice aggiornato in un ambiente di sviluppo in Azure Synapse, non in locale. Questo passaggio è essenziale per identificare e risolvere eventuali problemi prima di passare all'ambiente di produzione.
  • Distribuire e monitorare: dopo test e convalida approfonditi nell'ambiente di sviluppo, distribuire l'applicazione nel nuovo pool di Spark 3.4. È fondamentale monitorare l'applicazione per eventuali comportamenti imprevisti. Usare gli strumenti di monitoraggio disponibili in Azure Synapse per tenere traccia delle prestazioni delle applicazioni Spark.

Domanda: Quali passaggi è necessario eseguire nella migrazione dalla versione 2.4 alla versione 3.X?

Risposta: Fare riferimento alla guida alla migrazione di Apache Spark.

Domanda: Si è verificato un errore quando si è tentato di aggiornare il runtime del pool di Spark usando il cmdlet di PowerShell quando sono associate librerie.

Risposta: Non usare il cmdlet di PowerShell se sono installate librerie personalizzate nell'area di lavoro synapse. Seguire invece questa procedura:

  1. Ricreare il pool di Spark 3.3 da zero.
  2. Effettuare il downgrade del pool di Spark 3.3 alla versione 3.1 corrente, rimuovere tutti i pacchetti collegati e quindi eseguire di nuovo l'aggiornamento alla versione 3.3.

Domanda: Perché non è possibile eseguire l'aggiornamento alla versione 3.4 senza ricreare un nuovo pool di Spark?

Risposta: Questo non è consentito dall'esperienza utente, il cliente può usare Azure PowerShell per aggiornare la versione di Spark. Usare "ForceApplySetting", in modo che tutti i cluster esistenti (con versione precedente) vengano rimossi.

Query di esempio:

$_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
              }
        }
    }

Contenuto correlato