Dataproc Serverless para Spark ejecuta cargas de trabajo en contenedores de Docker. El contenedor proporciona el entorno de ejecución para los procesos del controlador y del ejecutor de la carga de trabajo. De forma predeterminada, Dataproc Serverless para Spark usa un imagen de contenedor que incluya los paquetes predeterminados de Spark, Java, Python y R asociados a una versión de actualización del entorno de ejecución. La API de lotes de Dataproc Serverless para Spark te permite usar una imagen de contenedor personalizada en lugar de la imagen predeterminada. Por lo general, una imagen de contenedor personalizada agrega dependencias de Java o Python de la carga de trabajo de Spark que no proporciona la imagen de contenedor predeterminada. Importante: No incluir Spark en tu imagen de contenedor personalizada Dataproc Serverless para Spark activará Spark al contenedor en el entorno de ejecución.
Envía una carga de trabajo por lotes de Spark con una imagen de contenedor personalizada
gcloud
Usa el comando gcloud dataproc batches submit spark con la marca --container-image para especificar tu imagen de contenedor personalizado cuando envíes una carga de trabajo por lotes de Spark.
gcloud dataproc batches submit spark \ --container-image=custom-image, for example, "gcr.io/my-project-id/my-image:1.0.1" \ --region=region \ --jars=path to user workload jar located in Cloud Storage or included in the custom container \ --class=The fully qualified name of a class in the jar file, such as org.apache.spark.examples.SparkPi \ -- add any workload arguments here
Notas:
- Custom-image: Especifica la imagen de contenedor personalizada con el siguiente formato de nombre de imagen de Container Registry:
{hostname}/{project-id}/{image}:{tag}, por ejemplo, "gcr.io/my-project-id/my-image:1.0.1". Nota: Debes alojar tu imagen de contenedor personalizada en Container Registry o Artifact Registry. (Dataproc Serverless no puede recuperar contenedores de otros registros). --jars: Especifica una ruta de acceso a un del usuario incluida en tu imagen de contenedor personalizada o ubicada en Cloud Storage, por ejemplo,file:///opt/spark/jars/spark-examples.jarogs://my-bucket/spark/jars/spark-examples.jar.- Otras opciones de comandos por lotes: Puedes agregar otras marcas de comando opcionales por lotes, por ejemplo, para usar un servidor de historial persistente (PHS). Nota: El PHS debe estar ubicado en la región en la que ejecutas cargas de trabajo por lotes.
- argumentos de carga de trabajoPuedes incluir cualquier argumento de carga de trabajo agregando un “--” a el final del comando, seguido de los argumentos de la carga de trabajo.
REST
La imagen de contenedor personalizada se proporciona a través del campo RuntimeConfig.containerImage como parte de una solicitud a la API batches.create.
En el siguiente ejemplo, se muestra cómo usar un contenedor personalizado para enviar una carga de trabajo por lotes usando la API de Dataproc Serverless para Spark Batch.create
Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:
- project-id: ID del proyecto de Google Cloud
- region: región
- custom-container-image: Especifica la imagen de contenedor personalizada con el
siguiente formato de nombre de imagen de Container Registry:
{hostname}/{project-id}/{image}:{tag}, por ejemplo, “gcr.io/my-project-id/my-image:1.0.1”. Nota: Debes alojar tu contenedor personalizado en Container Registry o Artifact Registry . (Dataproc sin servidores no puede recuperar contenedores de otros registros). jar-uri: Especifica una ruta de acceso a un archivo jar de carga de trabajo incluido en tu imagen de contenedor personalizada o ubicado en Cloud Storage, por ejemplo, "/opt/spark/jars/spark-examples.jar" o “gs:///spark/jars/spark-examples.jar”.class: Es el nombre completamente calificado de una clase en el archivo jar, como "org.apache.spark.examples.SparkPi".- Otras opciones: Puedes usar otros campos de recursos de carga de trabajo por lotes, por ejemplo,
usa el campo
sparkBatch.argspara pasar argumentos a tu carga de trabajo (consulta la documentación del recursoBatchpara obtener más información). Para usar un Servidor de historial persistente (PHS), consulta Configura un servidor de historial persistente. Nota: El PHS debe estar ubicado en la región en la que ejecutas cargas de trabajo por lotes.
Método HTTP y URL:
POST https://dataproc.googleapis.com/v1/projects/project-id/locations/region/batches
Cuerpo JSON de la solicitud:
{
"runtimeConfig":{
"containerImage":"custom-container-image
},
"sparkBatch":{
"jarFileUris":[
"jar-uri"
],
"mainClass":"class"
}
}
Para enviar tu solicitud, expande una de estas opciones:
Deberías recibir una respuesta JSON similar a la que se muestra a continuación:
{
"name":"projects/project-id/locations/region/batches/batch-id",
"uuid":",uuid",
"createTime":"2021-07-22T17:03:46.393957Z",
"runtimeConfig":{
"containerImage":"gcr.io/my-project/my-image:1.0.1"
},
"sparkBatch":{
"mainClass":"org.apache.spark.examples.SparkPi",
"jarFileUris":[
"/opt/spark/jars/spark-examples.jar"
]
},
"runtimeInfo":{
"outputUri":"gs://dataproc-.../driveroutput"
},
"state":"SUCCEEDED",
"stateTime":"2021-07-22T17:06:30.301789Z",
"creator":"account-email-address",
"runtimeConfig":{
"properties":{
"spark:spark.executor.instances":"2",
"spark:spark.driver.cores":"2",
"spark:spark.executor.cores":"2",
"spark:spark.app.name":"projects/project-id/locations/region/batches/batch-id"
}
},
"environmentConfig":{
"peripheralsConfig":{
"sparkHistoryServerConfig":{
}
}
},
"operation":"projects/project-id/regions/region/operation-id"
}
Compila una imagen de contenedor personalizada
Las imágenes de contenedores personalizadas de Dataproc Serverless para Spark son imágenes de Docker. Puedes usar las herramientas para compilar imágenes de Docker para compilar imágenes de contenedores personalizadas, pero hay condiciones que las imágenes deben cumplir para ser compatibles con Dataproc sin servidor para Spark. En las siguientes secciones, se explican estas condiciones.
Sistema operativo
Puedes elegir cualquier imagen de sistema operativo como imagen base de tu imagen de contenedor personalizada.
Recomendación: Se prefieren las imágenes predeterminadas de Debian 11 (por ejemplo, debian:11-slim), ya que se probaron para evitar problemas de compatibilidad.
Utilidades
Debes incluir los siguientes paquetes de utilidades para ejecutar Spark en tu imagen de contenedor personalizada:
procpstini
Para ejecutar XGBoost desde Spark (Java o Scala), debes incluir
libgomp1
Usuario de contenedor
Dataproc Serverless para Spark ejecuta contenedores como el usuario spark de Linux con un
UID de 1099 y un GID de 1099. Las directivas USER establecidas en los Dockerfiles de imágenes de contenedores personalizados se ignoran durante el tiempo de ejecución. Usa el UID y el GID para los permisos del sistema de archivos.
Por ejemplo, si agregas un archivo JAR en /opt/spark/jars/my-lib.jar en la imagen
como una dependencia de carga de trabajo, debes otorgarle al usuario spark permiso de lectura para la
.
Transmisión de imágenes
Por lo general, Dataproc sin servidores para Spark comienza una carga de trabajo que requiere una imagen de contenedor personalizada descargando toda la imagen en el disco. Esto puede significar una demora en el tiempo de inicialización, especialmente para los clientes con imágenes grandes.
En su lugar, puedes usar la transmisión de imágenes, que es un método para extraer datos de imágenes según sea necesario. Esto permite que la carga de trabajo se inicie sin esperar a que se complete imagen para descargar, lo que podría mejorar el tiempo de inicialización. Habilitar imagen de transmisión, debes habilitar el API de Container File System. También debes almacenar tus imágenes de contenedor en Artifact Registry, y el repositorio de Artifact Registry debe estar en la misma región que tu carga de trabajo de Dataproc o en una multirregión que corresponda a la región en la que se ejecuta la carga de trabajo. Si Dataproc no admite la imagen o la transmisión de imágenes servicio no está disponible, nuestra implementación de transmisión descarga imagen. Ten en cuenta que no admitimos lo siguiente para la transmisión de imágenes:
- Imágenes con capas vacías o duplicadas
- Imágenes que usan el manifiesto de imágenes de V2, versión de esquema 1
En estos casos, Dataproc extrae la imagen completa antes de iniciar la carga de trabajo.
Spark
No incluyas Spark en tu imagen de contenedor personalizada. En el entorno de ejecución, Dataproc Serverless para Spark
Activa los objetos binarios y los parámetros de configuración de Spark del host en el contenedor: objetos binarios
se activan en el directorio /usr/lib/spark y los archivos de configuración en el
/etc/spark/conf. Se anularon los archivos existentes en estos directorios
por Dataproc Serverless para Spark en el entorno de ejecución.
Java Runtime Environment
No incluyas tu propio entorno de ejecución de Java (JRE) en la imagen de contenedor personalizada.
En el tiempo de ejecución, Dataproc Serverless para Spark activa OpenJDK desde el host en la
contenedor. Si incluyes un JRE en la imagen de contenedor personalizada, se ignorará.
Paquetes Java
Puedes incluir archivos JAR como dependencias de la carga de trabajo de Spark en tu imagen de contenedor personalizada y configurar la variable de entorno SPARK_EXTRA_CLASSPATH para incluir los archivos JAR. Dataproc Serverless para Spark
añadirá el valor de la variable de entorno en la ruta de acceso de los procesos de JVM de Spark. Recomendación: Coloca los archivos JAR en el directorio /opt/spark/jars y establece SPARK_EXTRA_CLASSPATH en /opt/spark/jars/*.
Puedes incluir el archivo jar de la carga de trabajo en tu imagen de contenedor personalizada y, luego, hacer referencia a él con una ruta de acceso local.
cuando envíes la carga de trabajo, por ejemplo, file:///opt/spark/jars/my-spark-job.jar
(consulta Envía una carga de trabajo por lotes de Spark con una imagen de contenedor personalizada para ver un ejemplo).
Paquetes de Python
De forma predeterminada, Dataproc Serverless para Spark activa Conda desde el host al directorio /opt/dataproc/conda en el contenedor durante el tiempo de ejecución.
PYSPARK_PYTHON se configura como /opt/dataproc/conda/bin/python. Su directorio base, /opt/dataproc/conda/bin, se incluye en PATH.
Puedes incluir tu entorno de Python con paquetes en un directorio diferente en tu imagen de contenedor personalizada, por ejemplo, en /opt/conda, y establecer la variable de entorno PYSPARK_PYTHON en /opt/conda/bin/python.
Tu imagen de contenedor personalizada puede incluir otros módulos de Python que no forman parte del entorno de Python, por ejemplo, secuencias de comandos de Python con funciones de utilidad.
Establece la variable de entorno PYTHONPATH de modo que incluya los directorios donde
se ubican los módulos.
Entorno de R
Puedes personalizar el entorno de R en tu imagen de contenedor personalizada con una de las siguientes opciones:
- Usa Conda para instalar y administrar paquetes de R desde el canal
conda-forge. - Agrega un repositorio de R para el SO Linux de tu imagen de contenedor y, luego, instala los paquetes de R con el administrador de paquetes del SO Linux (consulta el índice de paquetes de software de R).
Cuando usas cualquiera de las opciones, debes configurar la variable de entorno R_HOME
para que apunte a tu entorno de R personalizado. Excepción: Si usas Conda para
administran tu entorno de R y personalizan el entorno de Python,
No necesitas configurar la variable de entorno R_HOME. se crea automáticamente
establecido en función de la variable de entorno PYSPARK_PYTHON.
Ejemplo de compilación de imagen de contenedor personalizada
En esta sección, se incluye un ejemplo de compilación de una imagen de contenedor personalizada, que comienza con un Dockerfile de muestra.
Dockerfile
# Debian 11 is recommended.
FROM debian:11-slim
# Suppress interactive prompts
ENV DEBIAN_FRONTEND=noninteractive
# (Required) Install utilities required by Spark scripts.
RUN apt update && apt install -y procps tini libjemalloc2
# (Optiona) Install utilities required by XGBoost for Spark.
RUN apt install -y procps libgomp1
# Enable jemalloc2 as default memory allocator
ENV LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
# (Optional) Add extra jars.
ENV SPARK_EXTRA_JARS_DIR=/opt/spark/jars/
ENV SPARK_EXTRA_CLASSPATH='/opt/spark/jars/*'
RUN mkdir -p "${SPARK_EXTRA_JARS_DIR}"
#Uncomment below and replace EXTRA_JAR_NAME with the jar file name.
#COPY "EXTRA_JAR_NAME" "${SPARK_EXTRA_JARS_DIR}"
# (Optional) Install and configure Miniconda3.
ENV CONDA_HOME=/opt/miniconda3
ENV PYSPARK_PYTHON=${CONDA_HOME}/bin/python
ENV PATH=${CONDA_HOME}/bin:${PATH}
COPY Miniconda3-py39_4.10.3-Linux-x86_64.sh .
RUN bash Miniconda3-py39_4.10.3-Linux-x86_64.sh -b -p /opt/miniconda3 \
&& ${CONDA_HOME}/bin/conda config --system --set always_yes True \
&& ${CONDA_HOME}/bin/conda config --system --set auto_update_conda False \
&& ${CONDA_HOME}/bin/conda config --system --prepend channels conda-forge \
&& ${CONDA_HOME}/bin/conda config --system --set channel_priority strict
# Packages ipython and ipykernel are required if using custom conda and want to
# use this container for running notebooks.
RUN ${CONDA_HOME}/bin/conda install ipython ipykernel
# (Optional) Install Conda packages.
#
# The following packages are installed in the default image, it is strongly
# recommended to include all of them.
#
# Use mamba to install packages quickly.
RUN ${CONDA_HOME}/bin/conda install mamba -n base -c conda-forge \
&& ${CONDA_HOME}/bin/mamba install \
conda \
cython \
fastavro \
fastparquet \
gcsfs \
google-cloud-bigquery-storage \
google-cloud-bigquery[pandas] \
google-cloud-bigtable \
google-cloud-container \
google-cloud-datacatalog \
google-cloud-dataproc \
google-cloud-datastore \
google-cloud-language \
google-cloud-logging \
google-cloud-monitoring \
google-cloud-pubsub \
google-cloud-redis \
google-cloud-spanner \
google-cloud-speech \
google-cloud-storage \
google-cloud-texttospeech \
google-cloud-translate \
google-cloud-vision \
koalas \
matplotlib \
nltk \
numba \
numpy \
openblas \
orc \
pandas \
pyarrow \
pysal \
pytables \
python \
regex \
requests \
rtree \
scikit-image \
scikit-learn \
scipy \
seaborn \
sqlalchemy \
sympy \
virtualenv
# (Optional) Add extra Python modules.
ENV PYTHONPATH=/opt/python/packages
RUN mkdir -p "${PYTHONPATH}"
COPY test_util.py "${PYTHONPATH}"
# (Optional) Install R and R libraries.
RUN apt update \
&& apt install -y gnupg \
&& apt-key adv --no-tty \
--keyserver "hkp://keyserver.ubuntu.com:80" \
--recv-keys E19F5F87128899B192B1A2C2AD5F960A256A04AF \
&& echo "deb http://cloud.r-project.org/bin/linux/debian bullseye-cran40/" \
>/etc/apt/sources.list.d/cran-r.list \
&& apt update \
&& apt install -y \
libopenblas-base \
libssl-dev \
r-base \
r-base-dev \
r-recommended \
r-cran-blob
ENV R_HOME=/usr/lib/R
# (Required) Create the 'spark' group/user.
# The GID and UID must be 1099. Home directory is required.
RUN groupadd -g 1099 spark
RUN useradd -u 1099 -g 1099 -d /home/spark -m spark
USER spark
Comandos de compilación
Ejecuta en el directorio de Dockerfile.
IMAGE=gcr.io/my-project/my-image:1.0.1
# Download the Miniconda3 installer.
wget https://repo.anaconda.com/miniconda/Miniconda3-py39_4.10.3-Linux-x86_64.sh
# Python module example
cat >test_util.py <<EOF
def hello(name):
print("hello {}".format(name))
def read_lines(path):
with open(path) as f:
return f.readlines()
EOF
# Build and push the image.
docker build -t "${IMAGE}" .
docker push "${IMAGE}"