"Managed Service for Apache Spark" is the new name for the product formerly known as "Dataproc on Compute Engine" (cluster deployment) and "Google Cloud Serverless for Apache Spark" (serverless deployment).

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Eseguire la migrazione e configurare i canali Conda

I canali dei pacchetti Conda preconfigurati vengono rimossi dalle immagini dei cluster Managed Service for Apache Spark e dai runtime serverless. Questo documento descrive come eseguire la migrazione e configurare i canali Conda per i tuoi workload.

Rimozione dei canali Conda preconfigurati

In precedenza, le immagini di Managed Service for Apache Spark includevano canali Conda preconfigurati, come il repository defaults di Anaconda. A causa delle modifiche alle licenze, Managed Service for Apache Spark rimuove tutti i puntatori ai canali preconfigurati da tutte le immagini e i runtime serverless di Managed Service for Apache Spark passati e futuri.

Modifiche: i comandi che eseguono conda install PACKAGE senza un canale fornito in modo esplicito non risolvono più i pacchetti rispetto ai repository predefiniti e non vanno a buon fine.
Cosa non cambia:le installazioni standard di pacchetti Python da PyPI (pip install PACKAGE o la proprietà del cluster dataproc:pip.packages) non sono interessate.

Disponibilità di immagini laterali senza canali

Per aiutare gli sviluppatori ad adattarsi a questo aggiornamento, Managed Service for Apache Spark ha rilasciato versioni secondarie senza canali di rilascio come elencato nella tabella seguente. Queste immagini mantengono la compatibilità binaria e dei componenti al 100% con le immagini esistenti, differendo solo per la rimozione dei canali Conda preconfigurati.

Traccia immagine	Versioni legacy o interessate	Versione laterale senza Conda pubblicata	Stato e compatibilità
1.3	`<= 1.3.95`	`1.3.96`	Compatibilità al 100% con `1.3.95`; canali Conda rimossi
1.4	`<= 1.4.80`	`1.4.81`	Compatibile al 100% con `1.4.80`; canali Conda rimossi
1,5	`<= 1.5.90`	`1.5.92`	Compatibilità al 100% con `1.5.90`; canali Conda rimossi
2.0	`<= 2.0.160`	`2.0.161`	Compatibile al 100% con `2.0.160`; canali Conda rimossi
2.1	`<= 2.1.116`	`2.1.117` e `2.1.119` e versioni successive	Rilascio supportato; canali Conda rimossi
2.2	`<= 2.2.84`	`2.2.85` e `2.2.87` e versioni successive	Rilascio supportato; canali Conda rimossi
2.3	`<= 2.3.31`	`2.3.32` e `2.3.36` e versioni successive	Rilascio supportato; canali Conda rimossi

Come la rimozione influisce sui carichi di lavoro

Cluster non bloccati: qualsiasi script di creazione di cluster che specifica un alias della versione immagine (ad esempio --image-version=2.2-debian12) riceve automaticamente la nuova immagine senza canali.
Immagini bloccate o personalizzate: i cluster bloccati su release secondarie precedenti o che utilizzano immagini personalizzate continuano a fare riferimento alle configurazioni del canale precedenti, a meno che non vengano aggiornati. Se utilizzi immagini bloccate, devi richiedere un'estensione per avere più tempo ed eseguire la migrazione alle versioni supportate e senza canali.
Errore di esecuzione: qualsiasi azione di inizializzazione, script della pipeline o job che invia conda install PACKAGE senza specificare un canale non riesce e genera errori di risoluzione del canale.

Come configurare i canali Conda

Se i tuoi workload dipendono da Conda per installare pacchetti binari, devi dichiarare esplicitamente il canale utilizzando una delle seguenti opzioni. Per specificare i canali nelle proprietà del cluster correlate a Conda, consulta Utilizzare le proprietà del cluster correlate a Conda.

Opzione 1: flag della riga di comando esplicito

Questa opzione è consigliata per le installazioni ad hoc. Passa il flag --channel quando esegui conda install:

conda install --channel conda-forge PACKAGE

In alternativa, utilizza il flag breve -c:

conda install -c conda-forge PACKAGE

Sostituisci PACKAGE con il nome del pacchetto da installare.

Opzione 2: azioni di inizializzazione del cluster

Questa opzione è consigliata per gli ambienti automatizzati. Aggiungi un'azione di inizializzazione personalizzata che preconfigura il canale che vuoi utilizzare nel file di configurazione .condarc:

#!/bin/bash
# Preconfigure the community conda-forge channel or a private enterprise repository.
conda config --add channels conda-forge
conda config --set channel_priority strict

Esegui la migrazione dalle immagini legacy (1.x e 2.0)

Le versioni 1.3, 1.4, 1.5 e 2.0 di Managed Service for Apache Spark non sono supportate da un periodo di tempo prolungato. L'esecuzione di immagini precedenti introduce rischi operativi e di sicurezza significativi, tra cui vulnerabilità ed esposizioni comuni (CVE) note nei sistemi operativi sottostanti e nelle dipendenze del software open source (OSS).

Google Cloud disattiverà definitivamente la creazione di immagini per le tracce 1.x e 2.0.
Verranno rimosse anche tutte le azioni di inizializzazione disponibili nel repository GitHub GoogleCloudDataproc/initialization-actions che supportano solo queste immagini ritirate (1.x e 2.0).
Tutti i workload devono eseguire la migrazione alle immagini laterali senza canali Conda entro il 15 ottobre 2026.
In definitiva, tutti i workload devono essere migrati a versioni attive e supportate (2.1, 2.2, 2.3 o 3.0 e successive).

Per saperne di più, consulta Versioni immagine di Managed Service for Apache Spark non supportate.

Estensioni disponibili

Managed Service for Apache Spark fornisce due percorsi di estensione tramite una lista consentita con attivazione, che richiede l'approvazione del team di assistenza.

Tipi di estensione

Sono disponibili i seguenti tipi di estensione.

Estensione della soluzione temporanea Conda

Validità:fino al 31 ottobre 2026 al massimo.
Scopo:fornisce un buffer operativo immediato per i clienti i cui deployment automatizzati o azioni di inizializzazione non funzionano a causa del cambio dell'alias dell'immagine predefinito il 25 agosto 2026 e il 1° settembre 2026.
Vantaggio: consente ai progetti di mantenere temporaneamente il comportamento precedente durante la modifica degli script per includere --channel o la transizione alle immagini senza canali.

Estensione del ritiro delle immagini legacy

Validità: fino al 31 dicembre 2026.
Scopo:per i workload mission critical in esecuzione su 1.x o 2.0 che non possono eseguire immediatamente il refactoring del codice per Spark 3.x o ambienti OS più recenti.
Vantaggio: ti consente di continuare a creare cluster sui canali legacy fino alla fine del 2026, evitando interruzioni immediate della produzione.
Prerequisito: puoi ottenere questa estensione solo se i tuoi attuali workload 1.x e 2.0 utilizzano immagini laterali conformi a Conda.

Requisiti delle estensioni

Le estensioni sono regolate da vincoli di conformità e infrastruttura. Per ottenere l'approvazione, devi soddisfare tutti i seguenti requisiti:

Solo per i progetti esistenti: le estensioni si applicano rigorosamente agli ID progetto Google Cloud che hanno una cronologia attiva di esecuzione di queste versioni prima di agosto 2026. I nuovi progetti non verranno aggiunti alla lista consentita.
Scambio obbligatorio di immagini laterali entro il 31 ottobre 2026:se ti viene concessa un'estensione per la versione 1.x o 2.0, devi eseguire la transizione delle configurazioni di creazione del cluster alle versioni secondarie laterali compatibili con Conda (1.3.96, 1.4.81, 1.5.92 e 2.0.161) entro e non oltre il 31 ottobre 2026.
Nessun utilizzo della regione global: per le versioni immagine 1.5 e precedenti, i cluster non devono essere sottoposti a deployment nella regione global precedente. I workload devono utilizzare endpoint regionali specifici (ad esempio us-central1 o europe-west1).
Roadmap di migrazione impegnata:devi disporre di un piano di modernizzazione attivo per spostare i carichi di lavoro nelle versioni supportate conformi a Conda (2.2 e successive o 3.0) prima della scadenza del 31 dicembre 2026.

Come richiedere una proroga

Per richiedere l'inserimento nella lista consentita delle estensioni, invia una richiesta tramite uno dei seguenti canali:

Email:invia la richiesta direttamente all'indirizzo dataproc-msa-support@google.com.
Richiesta di assistenza: invia una richiesta all'assistenza clienti Google Cloud facendo riferimento all'MSA per il ritiro di Conda in Dataproc.
Team dedicato all'account:contatta il tuo Google Cloud Technical Account Manager (TAM) o Customer Engineer (CE) dedicato.

Includi le seguenti informazioni nella tua richiesta:

Google Cloud Nome dell'organizzazione
ID progetto e numeri di progetto Google Cloud di destinazione
Nomi o UUID dei cluster interessati
Versioni immagine attualmente in uso
Motivo della richiesta di estensione e data di completamento della migrazione prevista

Elenco di controllo per i canali Conda conformi

Completa le seguenti priorità in ordine.

Priorità 1: rilevamento e inventario dei workload

Identifica le immagini ritirate:esamina i progetti della tua organizzazione per individuare eventuali cluster in esecuzione su 1.3, 1.4, 1.5 o 2.0.

Il seguente comando elenca la versione dell'immagine dei cluster attivi in una regione:
```
gcloud dataproc clusters list --region=REGION \
    --format="table(clusterName, status.state, config.softwareConfig.imageVersion)"
```
Sostituisci REGION con la regione in cui si trovano i tuoi cluster.
Controlla l'utilizzo di Conda:esamina le azioni di inizializzazione (--initialization-actions), gli script di avvio e gli script di invio dei job per eventuali chiamate di conda install.

Priorità 2: triage immediato degli errori

Se si verificano interruzioni, procedi nel seguente modo:

Se le pipeline automatizzate non vanno a buon fine a causa della mancanza di pacchetti Conda, applica immediatamente una patch all'azione o allo script di inizializzazione aggiungendo --channel conda-forge (o -c conda-forge):
```
conda install -c conda-forge PACKAGE
```
Se la creazione del cluster non riesce a causa di blocchi di immagini ritirati, contatta immediatamente dataproc-msa-support@google.com o il tuo TAM per richiedere l'inserimento temporaneo nella lista consentita.

Priorità 3: esegui uno scambio laterale di un minore secondario

Questo passaggio non richiede modifiche al codice.

Per le pipeline che non possono eseguire immediatamente l'upgrade alla versione 2.2 o successive dell'immagine, aggiorna i modelli di creazione dei cluster (ad esempio Terraform, Apache Airflow DataprocCreateClusterOperator, Managed Service for Apache Airflow e script CI/CD) per utilizzare la versione laterale senza canali:
- Sostituisci 1.3.* con 1.3.96.
- Sostituisci 1.4.* con 1.4.81.
- Sostituisci 1.5.* con 1.5.92.
- Sostituisci 2.0.* con 2.0.161.
Perché funziona: queste immagini contengono le stesse versioni di Apache Spark, Apache Hadoop, Apache Hive e Java delle versioni secondarie precedenti. Garantiscono la compatibilità al 100% delle applicazioni senza richiedere modifiche al codice.

Priorità 4: ricrea i cluster di lunga durata

Se hai cluster statici a lunga esecuzione di cui è stato eseguito il deployment su immagini precedenti, pianifica un periodo di manutenzione per ricrearli utilizzando le versioni secondarie laterali più recenti (o le versioni 2.x o 3.x supportate compatibili con Conda). La ricreazione dei cluster garantisce che vengano acquisiti tutti gli aggiornamenti critici di sicurezza e configurazione.

Priorità 5: pianifica un upgrade completo alle versioni supportate

Il completamento di questa priorità è previsto per il quarto trimestre del 2026.

Crea ambienti di test sulla versione immagine 2.2 (Debian 12, Spark 3.5) o sulla versione immagine 3.0, che è disponibile a livello generale (GA).
Convalida i job PySpark, Scala e Java in base alle specifiche dell'API Spark 3.x.
Se hai bisogno di assistenza dedicata per la modernizzazione, utilizza l'Organizzazione servizi professionali (PSO) di Google Cloudo i partner di migrazione certificati, come Wipro e HCL.

Domande frequenti

Le sezioni seguenti rispondono alle domande frequenti sulla rimozione del canale Conda.

Generali e background

Le seguenti domande spiegano perché vengono apportate queste modifiche e in che modo differiscono l'una dall'altra.

Perché Managed Service for Apache Spark rimuove i canali Conda preconfigurati?

A causa di modifiche ai requisiti di licenza, Managed Service for Apache Spark sta disaccoppiando i suoi servizi dai canali Anaconda proprietari e passando a meccanismi di pacchettizzazione open source standard.

Qual è la differenza tra la rimozione del canale Conda e il ritiro dell'immagine?

La rimozione del canale Conda interessa tutte le versioni di Managed Service for Apache Spark, incluse le versioni 2.1, 2.2 e 2.3 supportate attivamente e i runtime serverless. Rimuove i puntatori predefiniti ai repository Anaconda.
Il ritiro delle immagini riguarda in modo specifico le immagini legacy 1.x e 2.0. Queste immagini hanno raggiunto la fine del ciclo di vita, non ricevono più patch di sicurezza e la creazione di cluster verrà bloccata.

Problemi tecnici e di compatibilità

Le seguenti domande riguardano l'impatto delle modifiche sull'installazione dei pacchetti Python, sull'utilizzo di Conda e sulla compatibilità delle immagini.

Questa modifica interessa `pip install` o `dataproc:pip.packages`?

No. Le installazioni standard dei pacchetti Python che utilizzano pip o la proprietà del cluster Managed Service for Apache Spark dataproc:pip.packages vengono eseguite direttamente da Python Package Index (PyPI). PyPI è completamente indipendente da Conda e non è interessato in alcun modo.

La mia organizzazione può continuare a utilizzare i pacchetti Anaconda o Conda?

Sì. Puoi continuare a utilizzare Conda per gestire i tuoi ambienti. Tuttavia, devi fornire esplicitamente il canale del repository. Puoi fare riferimento al canale conda-forge supportato dalla community (aggiungendo -c conda-forge) o al mirror del repository Anaconda privato e concesso in licenza della tua organizzazione utilizzando le azioni di inizializzazione.

Quale errore esatto si verifica se il mio script non viene aggiornato?

Quando esegui conda install PACKAGE su un'immagine senza canali, Conda restituisce un errore che indica che non sono configurati canali o che il pacchetto richiesto non è stato trovato nei percorsi di ricerca predefiniti. Ad esempio: PackagesNotFoundError: The following packages are not available from current channels.

Che cos'è un'immagine laterale secondaria e perché dovrei utilizzarla?

Un'immagine secondaria laterale (ad esempio 1.5.92 per la traccia 1.5 o 2.0.161 per la traccia 2.0) è una release di immagini in cui i componenti principali dell'ecosistema big data (Hadoop, Spark, Hive, Presto e runtime Java) rimangono identici alle release precedenti della traccia, ma i canali Conda sottostanti sono stati rimossi. L'upgrade a una versione secondaria laterale non richiede modifiche al codice per i job Spark.

Deployment ed ecosistema

Le seguenti domande riguardano l'impatto delle modifiche sui carichi di lavoro serverless, sui deployment di Google Kubernetes Engine (GKE) e sui servizi di orchestrazione gestiti.

In che modo questo influisce su Managed Service for Apache Spark serverless?

A partire dal 25 agosto 2026, i carichi di lavoro batch serverless appena inviati vengono eseguiti su immagini di runtime di base che non contengono canali Conda preconfigurati. Se pacchettizzi le dipendenze utilizzando immagini container personalizzate o file tar.gz dell'ambiente Conda, assicurati che le definizioni di build specifichino --channel conda-forge o il tuo canale privato.

In che modo ciò influisce su Managed Service for Apache Spark su Google Kubernetes Engine?

Le immagini di Managed Service for Apache Spark su GKE sono state aggiornate per rimuovere i canali Conda preconfigurati (ad esempio, l'immagine di runtime 3.5-dataproc-28 e le release successive). I Dockerfile dei container personalizzati che eseguono conda install devono essere aggiornati per passare un --channel esplicito.

Gli orchestratori gestiti come Managed Service for Apache Airflow o Cloud Data Fusion sono interessati?

Le pipeline standard predefinite gestite da Managed Airflow o Cloud Data Fusion che richiamano le attività di creazione dei cluster di Managed Service for Apache Spark integrate non sono interessate, a meno che il tuo workflow non si basi su azioni di inizializzazione personalizzate che eseguono comandi conda install senza flag o bloccano immagini 1.x o 2.0 ritirate.

Supporto e assistenza

La seguente domanda descrive dove ricevere assistenza per la migrazione.

Dove posso ricevere assistenza tecnica per la mia migrazione?

Per la risoluzione dei problemi tecnici e le richieste di lista consentita, contatta dataproc-msa-support@google.com o apri una richiesta con l'assistenza clienti Google Cloud.
Per l'assistenza alla migrazione aziendale, Google Cloud PSO offre pacchetti di modernizzazione strutturati e i partner integratori di sistemi (SI) certificati, tra cui Wipro e HCL, forniscono servizi di migrazione dedicati idonei per i Fondi di servizi per partner (PSF).