Utilizzare container personalizzati con Dataproc Serverless per Spark

Dataproc Serverless per Spark esegue i carichi di lavoro all'interno di container Docker. Il contenitore fornisce l'ambiente di runtime per i processi di esecuzione e del driver del carico di lavoro. Per impostazione predefinita, Dataproc Serverless per Spark utilizza un'immagine contenitore che include i pacchetti Spark, Java, Python e R predefiniti associati a una versione di release del runtime. L'API Dataproc Serverless per Spark batches ti consente di utilizzare un'immagine container personalizzata anziché l'immagine predefinita. In genere, un'immagine del container personalizzata aggiunge dipendenze Java o Python per il carico di lavoro Spark non fornite dall'immagine del container predefinito. Importante: non includere Spark nell'immagine del contenitore personalizzato. Dataproc Serverless per Spark monterà Spark nel contenitore in fase di esecuzione.

Invia un carico di lavoro batch Spark utilizzando un'immagine container personalizzata

gcloud

Utilizza il comando gcloud dataproc batches submit spark con il flag --container-image per specificare l'immagine del contenitore personalizzato quando invii un carico di lavoro batch 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

Note:

  • Immagine-personalizzata: specifica l'immagine contenitore personalizzata utilizzando il seguente formato di denominazione delle immagini di Container Registry: {hostname}/{project-id}/{image}:{tag}, ad esempio "gcr.io/my-project-id/my-image:1.0.1". Nota:devi ospitare l'immagine del container personalizzato su Container Registry o Artifact Registry. (Dataproc Serverless non può recuperare i container da altri registry).
  • --jars: specifica un percorso a un carico di lavoro utente incluso nell'immagine contenitore personalizzata o situato in Cloud Storage, ad esempio file:///opt/spark/jars/spark-examples.jar o gs://my-bucket/spark/jars/spark-examples.jar.
  • Altre opzioni del comando batches: puoi aggiungere altri flag facoltativi del comando batches, ad esempio per utilizzare un server di cronologia permanente (PHS). Nota: il PHS deve trovarsi nella regione in cui esegui i carichi di lavoro batch.
  • Argomenti del carico di lavoro Puoi aggiungere qualsiasi argomento del carico di lavoro aggiungendo "--" alla fine del comando, seguito dagli argomenti del carico di lavoro.

REST

L'immagine del container personalizzata viene fornita tramite il campo RuntimeConfig.containerImage nell'ambito di una richiesta API batches.create.

Il seguente esempio mostra come utilizzare un contenitore personalizzato per inviare un carico di lavoro batch utilizzando l'API batches.create di Dataproc Serverless per Spark.

Prima di utilizzare i dati della richiesta, apporta le seguenti sostituzioni:

  • project-id: ID progetto Google Cloud
  • region: region
  • custom-container-image: specifica l'immagine contenitore personalizzata utilizzando il seguente formato di denominazione delle immagini di Container Registry: {hostname}/{project-id}/{image}:{tag}, ad esempio "gcr.io/my-project-id/my-image:1.0.1". Nota: devi ospitare il container personalizzato su Container Registry o Artifact Registry . (Dataproc Serverless non può recuperare i container da altri registry).
  • jar-uri: Specifica il percorso di un file jar del carico di lavoro incluso nell'immagine contenitore personalizzata o situato in Cloud Storage, ad esempio "/opt/spark/jars/spark-examples.jar" o "gs:///spark/jars/spark-examples.jar".
  • class: il nome completo di una classe nel file jar, ad esempio "org.apache.spark.examples.SparkPi".
  • Altre opzioni: puoi utilizzare altri campi delle risorse dei carichi di lavoro batch, ad esempio il campo sparkBatch.args per passare gli argomenti al carico di lavoro (per ulteriori informazioni, consulta la documentazione della risorsa Batch). Per utilizzare un server di cronologia permanente (PHS), consulta Configurare un server di cronologia permanente. Nota: il PHS deve trovarsi nella regione in cui esegui i carichi di lavoro batch.

Metodo HTTP e URL:

POST https://dataproc.googleapis.com/v1/projects/project-id/locations/region/batches

Corpo JSON della richiesta:

{
  "runtimeConfig":{
    "containerImage":"custom-container-image
  },
  "sparkBatch":{
    "jarFileUris":[
      "jar-uri"
    ],
    "mainClass":"class"
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

{
"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"
}

Crea un'immagine container personalizzata

Le immagini container personalizzate di Dataproc Serverless per Spark sono immagini Docker. Puoi utilizzare gli strumenti per la creazione di immagini Docker per creare immagini container personalizzate, ma esistono condizioni che le immagini devono soddisfare per essere compatibili con Dataproc Serverless per Spark. Queste condizioni sono spiegate nelle sezioni che seguono.

Sistema operativo

Puoi scegliere qualsiasi immagine del sistema operativo come immagine di base dell'immagine container personalizzata. Consiglio: sono preferite le immagini Debian 11 predefinite (ad esempio debian:11-slim), poiché sono state sottoposte a test per evitare problemi di compatibilità.

Utilità

Nell'immagine container personalizzata devi includere i seguenti pacchetti di utilità, necessari per eseguire Spark:

  • procps
  • tini

Per eseguire XGBoost da Spark (Java o Scala), devi includere libgomp1

Utente del contenitore

Dataproc Serverless per Spark esegue i container come utente spark Linux con un UID 1099 e un GID 1099. Le direttive USER impostate nei Dockerfile delle immagini container personalizzate vengono ignorate in fase di esecuzione. Utilizza UID e GID per le autorizzazioni del file system. Ad esempio, se aggiungi un file JAR in /opt/spark/jars/my-lib.jar nell'immagine come dipendenza del carico di lavoro, devi concedere all'utente spark l'autorizzazione di lettura al file.

Flusso immagine

In genere, Dataproc Serverless per Spark avvia un carico di lavoro che richiede un'immagine container personalizzata scaricando l'intera immagine sul disco. Ciò può comportare un ritardo nel tempo di inizializzazione, soprattutto per i clienti con immagini di grandi dimensioni.

Puoi utilizzare invece il flusso di immagini, un metodo per estrarre i dati delle immagini in base alle esigenze. In questo modo, il carico di lavoro può essere avviato senza attendere il download dell'intera immagine, migliorando potenzialmente il tempo di inizializzazione. Per attivare lo streaming di immagini, devi abilitare l'API Container File System. Devi anche archiviare le immagini dei container in Artifact Registry e il repository di Artifact Registry deve trovarsi nella stessa regione del tuo carico di lavoro Dataproc o in una regione multipla che corrisponde alla regione in cui è in esecuzione il carico di lavoro. Se Dataproc non supporta l'immagine o se il servizio di streaming di immagini non è disponibile, la nostra implementazione di streaming scarica l'intera immagine.

Tieni presente che non supportiamo quanto segue per lo streaming di immagini:

In questi casi, Dataproc estrae l'intera immagine prima di avviare il workload.

Spark

Non includere Spark nell'immagine del container personalizzato. In fase di runtime, Dataproc Serverless per Spark monta i binari e le configurazioni di Spark dall'host nel contenitore: i binari vengono montati nella directory /usr/lib/spark e le configurazioni nella directory /etc/spark/conf. I file esistenti in queste directory vengono sostituiti da Dataproc Serverless per Spark in fase di esecuzione.

Java Runtime Environment

Non includere il tuo Java Runtime Environment (JRE) nell'immagine del container personalizzato. In fase di esecuzione, Dataproc Serverless per Spark monta OpenJDK dall'host nel container. Se includi un JRE nell'immagine del container personalizzato, questo verrà ignorato.

Pacchetti Java

Puoi includere i file JAR come dipendenze del carico di lavoro Spark nell'immagine container personalizzata e impostare la variabile di ambiente SPARK_EXTRA_CLASSPATH per includere i file JAR. Dataproc Serverless per Spark aggiungerà il valore della variabile env nel percorso di classe dei processi JVM di Spark. Consiglio: metti i jar nella directory /opt/spark/jars e imposta SPARK_EXTRA_CLASSPATH su /opt/spark/jars/*.

Puoi includere il file jar del carico di lavoro nell'immagine del container personalizzato, quindi farvi riferimento con un percorso locale quando invii il carico di lavoro, ad esempio file:///opt/spark/jars/my-spark-job.jar (per un esempio, consulta Inviare un carico di lavoro batch Spark utilizzando un'immagine del container personalizzata).

Pacchetti Python

Per impostazione predefinita, Dataproc Serverless per Spark monta Conda dall'host alla directory /opt/dataproc/conda nel contenitore in fase di esecuzione. L'opzione PYSPARK_PYTHON è impostata su /opt/dataproc/conda/bin/python. La relativa directory di base, /opt/dataproc/conda/bin, è inclusa in PATH.

Puoi includere l'ambiente Python con i pacchetti in una directory diversa nella tua immagine container personalizzata, ad esempio in /opt/conda, e impostare la variabile di ambiente PYSPARK_PYTHON su /opt/conda/bin/python.

L'immagine del container personalizzato può includere altri moduli Python che non fanno parte dell'ambiente Python, ad esempio script Python con funzioni di utilità. Imposta la variabile di ambiente PYTHONPATH in modo da includere le directory in cui si trovano i moduli.

Ambiente R

Puoi personalizzare l'ambiente R nell'immagine container personalizzata utilizzando una delle seguenti opzioni:

  • Utilizza Conda per gestire e installare i pacchetti R dal canale conda-forge.
  • Aggiungi un repository R per il sistema operativo Linux dell'immagine container e installa i pacchetti R utilizzando il gestore dei pacchetti del sistema operativo Linux (consulta l'Indice dei pacchetti software R).

Quando utilizzi una delle due opzioni, devi impostare la variabile di ambiente R_HOME in modo che rimandi al tuo ambiente R personalizzato. Eccezione: se utilizzi Conda per gestire l'ambiente R e personalizzare l'ambiente Python, non è necessario impostare la variabile di ambiente R_HOME, poiché viene impostata automaticamente in base alla variabile di ambiente PYSPARK_PYTHON.

Esempio di compilazione di un'immagine container personalizzata

Questa sezione include un esempio di creazione di un'immagine container personalizzata, che inizia con un Dockerfile di esempio.

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

Comandi di compilazione

Esegui nella directory del 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}"