"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 utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Migra y configura canales de Conda

Se quitarán los canales de paquetes de Conda preconfigurados de las imágenes de clústeres de Managed Service para Apache Spark y los entornos de ejecución sin servidores. En este documento, se describe cómo migrar y configurar canales de Conda para tus cargas de trabajo.

Se quitaron los canales de Conda preconfigurados

Anteriormente, las imágenes de Managed Service para Apache Spark incluían canales de Conda preconfigurados, como el repositorio defaults de Anaconda. Debido a cambios en las licencias, Managed Service para Apache Spark quitará todos los punteros de canales preconfigurados de todas las imágenes y los tiempos de ejecución sin servidores pasados y futuros de Managed Service para Apache Spark.

Qué cambia: Los comandos que ejecutan conda install PACKAGE sin un canal proporcionado de forma explícita ya no resuelven paquetes en repositorios predeterminados y fallan.
Qué no cambia: Las instalaciones de paquetes de Python estándar desde PyPI (pip install PACKAGE o la propiedad del clúster dataproc:pip.packages) no se ven afectadas en absoluto.

Disponibilidad de imágenes laterales sin canales

Para ayudar a los desarrolladores a adaptarse a esta actualización, Managed Service para Apache Spark lanzó versiones secundarias sin canales de versiones, como se indica en la siguiente tabla. Estas imágenes mantienen el 100% de compatibilidad binaria y de componentes con las imágenes existentes, y solo se diferencian en la eliminación de los canales de Conda preconfigurados.

Pista de imagen	Versiones heredadas o afectadas	Versión lateral publicada sin Conda	Estado y compatibilidad
1.3	`<= 1.3.95`	`1.3.96`	100% compatible con `1.3.95`; se quitaron los canales de Conda
1.4	`<= 1.4.80`	`1.4.81`	100% compatible con `1.4.80`; se quitaron los canales de Conda
1.5	`<= 1.5.90`	`1.5.92`	100% compatible con `1.5.90`; se quitaron los canales de Conda
2.0	`<= 2.0.160`	`2.0.161`	100% compatible con `2.0.160`; se quitaron los canales de Conda
2.1	`<= 2.1.116`	`2.1.117`, `2.1.119` y más adelante	Versión compatible; se quitaron los canales de Conda
2.2	`<= 2.2.84`	`2.2.85`, `2.2.87` y más adelante	Versión compatible; se quitaron los canales de Conda
2.3	`<= 2.3.31`	`2.3.32`, `2.3.36` y más adelante	Versión compatible; se quitaron los canales de Conda

Cómo afecta la eliminación a las cargas de trabajo

Clústeres sin fijar: Cualquier secuencia de comandos de creación de clústeres que especifique un alias de versión de imagen (como --image-version=2.2-debian12) recibirá automáticamente la nueva imagen sin canales.
Imágenes fijadas o personalizadas: Los clústeres fijados a versiones secundarias anteriores o que usan imágenes personalizadas siguen haciendo referencia a las configuraciones de canales anteriores, a menos que se actualicen. Si usas imágenes fijadas, debes solicitar una extensión para tener tiempo adicional y migrar a versiones compatibles y sin canales.
Falla en la ejecución: Cualquier acción de inicialización, secuencia de comandos de canalización o trabajo que envíe conda install PACKAGE sin especificar un canal falla con errores de resolución de canales.

Cómo configurar canales de Conda

Si tus cargas de trabajo dependen de Conda para instalar paquetes binarios, debes declarar tu canal de forma explícita con una de las siguientes opciones. Para especificar canales en las propiedades del clúster relacionadas con Conda, consulta Usa propiedades del clúster relacionadas con Conda.

Opción 1: Marca de línea de comandos explícita

Esta opción se recomienda para las instalaciones ad hoc. Pasa la marca --channel cuando ejecutes conda install:

conda install --channel conda-forge PACKAGE

O bien, usa la marca abreviada -c:

conda install -c conda-forge PACKAGE

Reemplaza PACKAGE por el nombre del paquete que deseas instalar.

Opción 2: Acciones de inicialización del clúster

Esta opción se recomienda para entornos automatizados. Agrega una acción de inicialización personalizada que preconfigure el canal que deseas usar en el archivo de configuración .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

Migra desde imágenes heredadas (1.x y 2.0)

Las versiones 1.3, 1.4, 1.5 y 2.0 de Managed Service para Apache Spark no son compatibles desde hace un tiempo. Ejecutar imágenes anteriores presenta riesgos operativos y de seguridad significativos, incluidas las vulnerabilidades y exposiciones comunes (CVE) conocidas en los sistemas operativos subyacentes y las dependencias de software de código abierto (OSS).

Google Cloud desactivará de forma permanente la creación de imágenes para los segmentos 1.x y 2.0.
También se quitarán todas las acciones de inicialización disponibles en el repositorio de GitHub GoogleCloudDataproc/initialization-actions que solo admitan estas imágenes obsoletas (1.x y 2.0).
Todas las cargas de trabajo deben migrarse a las imágenes laterales sin canales de Conda antes del 15 de octubre de 2026.
Todas las cargas de trabajo deben migrarse, en última instancia, a versiones activas y compatibles (2.1, 2.2, 2.3 o 3.0 y versiones posteriores).

Para obtener más información, consulta Versiones de imágenes no compatibles de Managed Service para Apache Spark.

Extensiones disponibles

Managed Service para Apache Spark proporciona dos rutas de extensión a través de una lista de entidades permitidas de aceptación, que requiere la aprobación del equipo de servicio.

Tipos de extensiones

Están disponibles los siguientes tipos de extensiones.

Extensión de solución temporal para Conda

Validez: Hasta el 31 de octubre de 2026 como máximo.
Propósito: Proporciona un búfer operativo inmediato para los clientes cuyas implementaciones automatizadas o acciones de inicialización se interrumpen debido al cambio de alias de imagen predeterminado el 25 de agosto de 2026 y el 1 de septiembre de 2026.
Beneficio: Permite que los proyectos conserven temporalmente el comportamiento anterior mientras se modifican las secuencias de comandos para incluir --channel o se realiza la transición a imágenes sin canales.

Extensión de baja de imágenes heredadas

Validez: Hasta el 31 de diciembre de 2026
Propósito: Para cargas de trabajo esenciales que se ejecutan en 1.x o 2.0 y que no pueden refactorizar el código de inmediato para Spark 3.x o entornos de SO más recientes.
Beneficio: Te permite seguir creando clústeres en segmentos heredados hasta fines de 2026, lo que evita interrupciones inmediatas en la producción.
Requisito previo: Solo puedes obtener esta extensión si tus cargas de trabajo actuales de las versiones 1.x y 2.0 usan imágenes laterales compatibles con Conda.

Requisitos de las extensiones

Las extensiones se rigen por restricciones de cumplimiento y de infraestructura. Para obtener la aprobación, debes cumplir con todos los requisitos que se indican a continuación:

Solo para proyectos existentes: Las extensiones se aplican estrictamente a los IDs de proyecto Google Cloudque tienen un historial de actividad de ejecución de estas versiones antes de agosto de 2026. Los proyectos nuevos no se agregarán a la lista de entidades permitidas.
Intercambio obligatorio de imágenes laterales antes del 31 de octubre de 2026: Si se te otorga una extensión en la versión 1.x o 2.0, debes hacer la transición de las configuraciones de creación de clústeres a las versiones secundarias laterales compatibles con Conda (1.3.96, 1.4.81, 1.5.92 y 2.0.161) a más tardar el 31 de octubre de 2026.
No se usa la región global: En las versiones de imagen 1.5 y anteriores, los clústeres no se deben implementar en la región heredada global. Las cargas de trabajo deben usar extremos regionales específicos (por ejemplo, us-central1 o europe-west1).
Plan de migración comprometido: Debes tener un plan de modernización activo para mover las cargas de trabajo a versiones compatibles con Conda (2.2 y posteriores, o 3.0) antes de la fecha límite del 31 de diciembre de 2026.

Cómo solicitar una extensión

Para solicitar la inclusión en la lista de entidades permitidas de la extensión, envía una solicitud a través de cualquiera de los siguientes canales:

Correo electrónico: Envía tu solicitud directamente a dataproc-msa-support@google.com.
Caso de asistencia: Presenta un caso a Atención al cliente de Cloud que haga referencia al MSA de baja de Dataproc Conda.
Equipo de cuentas: Comunícate con tu administrador Google Cloud técnico de cuentas (TAM) o ingeniero de atención al cliente (CE) exclusivo.

Incluye la siguiente información en tu solicitud:

Google Cloud Nombre de la organización
IDs del proyecto Google Cloud y números de proyecto de destino
Nombres o UUIDs de los clústeres afectados
Versiones de imágenes actuales en uso
Motivo de la solicitud de extensión y la fecha de finalización de la migración prevista

Lista de tareas para canales de Conda que cumplen con los requisitos

Completa las siguientes prioridades en orden.

Prioridad 1: Inventario y descubrimiento de cargas de trabajo

Identifica las imágenes obsoletas: Audita los proyectos de tu organización para detectar cualquier clúster que se ejecute en la versión 1.3, 1.4, 1.5 o 2.0.

Con el siguiente comando, se muestra la versión de la imagen de los clústeres activos en una región:
```
gcloud dataproc clusters list --region=REGION \
    --format="table(clusterName, status.state, config.softwareConfig.imageVersion)"
```
Reemplaza REGION por la región en la que se encuentran tus clústeres.
Audita el uso de Conda: Revisa tus acciones de inicialización (--initialization-actions), secuencias de comandos de inicio y secuencias de comandos de envío de trabajos para detectar cualquier invocación de conda install.

Prioridad 2: Triaje de fallas inmediatas

Si tienes interrupciones, haz lo siguiente:

Si las canalizaciones automatizadas fallan debido a que faltan paquetes de Conda, aplica un parche de inmediato en la acción o secuencia de comandos de inicialización agregando --channel conda-forge (o -c conda-forge):
```
conda install -c conda-forge PACKAGE
```
Si la creación del clúster falla debido a bloques de imágenes obsoletos, comunícate de inmediato con dataproc-msa-support@google.com o con tu TAM para solicitar la inscripción temporal en la lista de entidades permitidas.

Prioridad 3: Ejecutar un intercambio lateral de submenores

Este paso no requiere cambios en el código.

En el caso de las canalizaciones que no se pueden actualizar de inmediato a la versión de imagen 2.2 o posterior, actualiza las plantillas de creación de clústeres (por ejemplo, Terraform, Apache Airflow DataprocCreateClusterOperator, Managed Service para Apache Airflow y secuencias de comandos de CI/CD) para usar la versión lateral sin canales:
- Reemplaza 1.3.* por 1.3.96.
- Reemplaza 1.4.* por 1.4.81.
- Reemplaza 1.5.* por 1.5.92.
- Reemplaza 2.0.* por 2.0.161.
Por qué funciona: Estas imágenes contienen las mismas versiones de Apache Spark, Apache Hadoop, Apache Hive y Java que las versiones secundarias anteriores. Garantizan el 100% de compatibilidad de las aplicaciones sin necesidad de realizar cambios en el código.

Prioridad 4: Vuelve a crear clústeres de larga duración

Si tienes clústeres estáticos de ejecución prolongada implementados en imágenes anteriores, programa un período de mantenimiento para recrearlos con las versiones secundarias laterales más recientes (o las versiones 2.x o 3.x compatibles con Conda). La recreación de los clústeres garantiza que se apliquen todas las actualizaciones críticas de seguridad y configuración.

Prioridad 5: Planifica una actualización completa a las versiones compatibles

La fecha de finalización prevista para esta prioridad es el 4º trimestre de 2026.

Establece entornos de prueba en la versión de imagen 2.2 (Debian 12, Spark 3.5) o en la versión de imagen 3.0, que está disponible de forma general (DG).
Valida los trabajos de PySpark, Scala y Java con las especificaciones de la API de Spark 3.x.
Si necesitas asistencia específica para la modernización, usa la Google CloudProfessional Services Organization (PSO) o socios certificados de migración, como Wipro y HCL.

Preguntas frecuentes

En las siguientes secciones, se responden las preguntas frecuentes sobre la eliminación del canal de Conda.

Antecedentes generales

En las siguientes preguntas, se explica por qué se producen estos cambios y en qué se diferencian entre sí.

¿Por qué Managed Service para Apache Spark quitará los canales de Conda preconfigurados?

Debido a los cambios en los requisitos de licencias, Managed Service para Apache Spark desacopla sus servicios de los canales propietarios de Anaconda y se muda a mecanismos de empaquetado de código abierto estándar.

¿Cuál es la diferencia entre la eliminación de canales de Conda y la baja de imágenes?

La eliminación del canal de Conda afecta a todas las versiones de Managed Service para Apache Spark, incluidas las versiones 2.1, 2.2 y 2.3 que se admiten de forma activa, y los tiempos de ejecución sin servidores. Quita los punteros predeterminados a los repositorios de Anaconda.
La obsolescencia de imágenes afecta específicamente a las imágenes heredadas de las versiones 1.x y 2.0. Estas imágenes llegaron al final del ciclo de vida, ya no reciben parches de seguridad y se bloqueará su uso para la creación de clústeres.

Problemas técnicos y de compatibilidad

Las siguientes preguntas abarcan cómo los cambios afectan la instalación de paquetes de Python, el uso de Conda y la compatibilidad de imágenes.

¿Este cambio afecta a `pip install` o `dataproc:pip.packages`?

No. Las instalaciones de paquetes de Python estándar que usan pip o la propiedad del clúster de Managed Service para Apache Spark dataproc:pip.packages se extraen directamente del índice de paquetes de Python (PyPI). PyPI es completamente independiente de Conda y no se ve afectado de ninguna manera.

¿Mi organización puede seguir usando paquetes de Anaconda o Conda?

Sí. Puedes seguir usando Conda para administrar tus entornos. Sin embargo, debes proporcionar explícitamente el canal del repositorio. Puedes apuntar al canal conda-forge compatible con la comunidad (agregando -c conda-forge) o apuntar al duplicado del repositorio privado y con licencia de Anaconda de tu organización con acciones de inicialización.

¿Qué error exacto se produce si no se actualiza mi secuencia de comandos?

Cuando ejecutas conda install PACKAGE en una imagen sin canales, Conda devuelve un error que indica que no hay canales configurados o que no se puede encontrar el paquete solicitado en las rutas de búsqueda predeterminadas. Por ejemplo: PackagesNotFoundError: The following packages are not available from current channels

¿Qué es una imagen secundaria lateral y por qué debería usarla?

Una imagen lateral secundaria (como 1.5.92 para la pista 1.5 o 2.0.161 para la pista 2.0) es una versión de imagen en la que los componentes principales del ecosistema de macrodatos (entornos de ejecución de Hadoop, Spark, Hive, Presto y Java) siguen siendo idénticos a las versiones anteriores de esa pista, pero se quitaron los canales de Conda subyacentes. La actualización a una versión secundaria lateral no requiere cambios en el código de tus trabajos de Spark.

Implementaciones y ecosistema

Las siguientes preguntas abarcan cómo los cambios afectan las cargas de trabajo sin servidores, las implementaciones de Google Kubernetes Engine (GKE) y los servicios de organización administrados.

¿Cómo afecta esto a Managed Service para Apache Spark sin servidores?

A partir del 25 de agosto de 2026, las cargas de trabajo por lotes sin servidores que se envíen recientemente se ejecutarán en imágenes de tiempo de ejecución base que no contengan canales de Conda preconfigurados. Si empaquetas dependencias con imágenes de contenedor personalizadas o archivos .tar.gz del entorno de Conda, asegúrate de que tus definiciones de compilación especifiquen --channel conda-forge o tu canal privado.

¿Cómo afecta esto a Managed Service para Apache Spark en Google Kubernetes Engine?

Se actualizaron las imágenes de Managed Service para Apache Spark en GKE para quitar los canales de Conda preconfigurados (por ejemplo, la imagen del entorno de ejecución 3.5-dataproc-28 y las versiones posteriores). Los Dockerfiles de contenedores personalizados que ejecutan conda install deben actualizarse para pasar un --channel explícito.

¿Se ven afectados los organizadores administrados, como Managed Service para Apache Airflow o Cloud Data Fusion?

Las canalizaciones estándar predeterminadas que administran Managed Airflow o Cloud Data Fusion que invocan tareas integradas de creación de clústeres de Managed Service para Apache Spark no se ven afectadas, a menos que tu flujo de trabajo dependa de acciones de inicialización personalizadas que ejecuten comandos conda install sin marcar o fijen imágenes 1.x o 2.0 en desuso.

Asistencia y ayuda

En la siguiente pregunta, se describe dónde obtener ayuda con tu migración.

¿Dónde puedo obtener asistencia técnica para mi migración?

Si necesitas ayuda para solucionar problemas técnicos o solicitar que se agregue tu dirección IP a la lista de entidades permitidas, comunícate con dataproc-msa-support@google.com o abre un caso con Atención al cliente de Cloud.
Para obtener asistencia en la migración empresarial, la Google Cloud PSO ofrece paquetes de modernización estructurados, y los socios integradores de sistemas (SI) certificados, incluidos Wipro y HCL, proporcionan servicios de migración exclusivos que son aptos para los Fondos de servicios para Socios (PSF).