Runtime di Azure Synapse
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
Avviso
Notifica di fine del supporto per il runtime di Azure Synapse per Apache Spark 2.4 e Apache Spark 3.1.
- A partire dal 29 settembre 2023, Azure Synapse interromperà il supporto ufficiale per i runtime di Spark 2.4.
- A partire dal 26 gennaio 2024, Azure Synapse interromperà il supporto ufficiale per i runtime di Spark 3.1.
- Dopo queste date, non verranno affrontati ticket di supporto correlati a Spark 2.4 o 3.1. Non sarà disponibile alcuna pipeline di versione per correzioni di bug o di sicurezza per Spark 2.4 e 3.1. L'uso di Spark 2.4 o 3.1 dopo che le date di scadenza del supporto sono intraprese a proprio rischio. Sconsigliamo vivamente il suo uso continuo a causa di potenziali problemi di sicurezza e funzionalità.
Suggerimento
È consigliabile aggiornare in modo proattivo i carichi di lavoro a una versione ga più recente del runtime, ad esempio Azure Synapse Runtime 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) | ||
| Runtime di Azure Synapse per Apache Spark 3.3 | 17 novembre 2022 | DISPONIBILITÀ generale (a partire dal 23 febbraio 2023) | Q2/Q3 2024 | Q1 2025 |
| Runtime di Azure Synapse per Apache Spark 3.2 | 8 luglio 2022 | Fine del supporto annunciato | 8 luglio 2023 | 8 luglio 2024 |
| Runtime di Azure Synapse per Apache Spark 3.1 | 26 maggio 2021 | deprecated | 26 gennaio 2023 | 26 gennaio 2024 |
| Runtime di Azure Synapse per Apache Spark 2.4 | 15 dicembre 2020 | deprecated | 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.classorg/apache/log4j/net/SMTPAppender.classorg/apache/log4j/net/JMSAppender.classorg/apache/log4j/net/JMSSink.classorg/apache/log4j/jdbc/JDBCAppender.classorg/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:
- Ricreare il pool di Spark 3.3 da zero.
- 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.