Mit Dataproc Serverless for Spark werden Arbeitslasten in Docker ausgeführt. Der Container stellt die Laufzeitumgebung für die Treiber- und Executor-Prozesse der Arbeitslast bereit. Standardmäßig verwendet Dataproc Serverless for Spark ein Container-Image, das die Standard-Spark-, Java-, Python- und R-Pakete enthält, die mit einer Laufzeitversion verknüpft sind. Mit der Dataproc Serverless for Spark API für Batches können Sie anstelle des Standard-Images ein benutzerdefiniertes Container-Image verwenden. In der Regel werden mit einem benutzerdefinierten Container-Image Java- oder Python-Abhängigkeiten für die Spark-Arbeitslast hinzugefügt, die nicht vom Standard-Container-Image bereitgestellt werden. Wichtig:Fügen Sie Spark nicht in Ihr benutzerdefiniertes Container-Image ein. Dataproc Serverless für Spark bindet Spark zur Laufzeit in den Container ein.
Spark-Batcharbeitslast mit einem benutzerdefinierten Container-Image einreichen
gcloud
Verwenden Sie den Befehl gcloud dataproc batches submit spark mit dem Flag --container-image, um Ihr benutzerdefiniertes Container-Image anzugeben, wenn Sie eine Spark-Batcharbeitslast einreichen.
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
Hinweise:
- Custom-image:Geben Sie das benutzerdefinierte Container-Image im folgenden Container Registry-Image-Benennungsformat an:
{hostname}/{project-id}/{image}:{tag}, z. B. „gcr.io/my-project-id/my-image:1.0.1“. Hinweis:Das benutzerdefinierte Container-Image muss in Container Registry oder Artifact Registry gehostet werden. (Dataproc Serverless kann keine Container aus anderen Registrierungen abrufen). --jars:Geben Sie einen Pfad zu einer Nutzerarbeitslast an, die in Ihrem benutzerdefinierten Container-Image enthalten ist oder sich in Cloud Storage befindet, z. B.file:///opt/spark/jars/spark-examples.jarodergs://my-bucket/spark/jars/spark-examples.jar.- Weitere Befehlsoptionen für Batches:Sie können weitere optionale Befehlsflags für Batches hinzufügen, z. B. um einen Persistent History Server (PHS) zu verwenden. Hinweis: Der PHS muss sich in der Region befinden, in der Sie Batch-Arbeitslasten ausführen.
- Workload-Argumente: Sie können beliebige Workload-Argumente hinzufügen, indem Sie am Ende des Befehls ein „--“ gefolgt von den Workload-Argumenten hinzufügen.
REST
Das benutzerdefinierte Container-Image wird über das Feld RuntimeConfig.containerImage im Rahmen einer batches.create-API-Anfrage bereitgestellt.
Im folgenden Beispiel wird gezeigt, wie Sie mit einem benutzerdefinierten Container eine Batch-Arbeitslast mit der Dataproc Serverless for Spark-API „batches.create“ einreichen.
Ersetzen Sie diese Werte in den folgenden Anfragedaten:
- project-id: ID des Google Cloud-Projekts.
- region: region
- custom-container-image: Geben Sie das benutzerdefinierte Container-Image im folgenden Container Registry-Image-Benennungsformat an:
{hostname}/{project-id}/{image}:{tag}, z. B. „gcr.io/my-project-id/my-image:1.0.1“. Hinweis: Der benutzerdefinierte Container muss in Container Registry oder Artifact Registry gehostet werden. (Dataproc Serverless kann keine Container aus anderen Registrierungen abrufen). jar-uri: Geben Sie einen Pfad zu einem Workload-JAR an, das in Ihrem benutzerdefinierten Container-Image enthalten ist oder sich in Cloud Storage befindet, z. B. „/opt/spark/jars/spark-examples.jar“ oder „gs:///spark/jars/spark-examples.jar“.class:Der voll qualifizierte Name einer Klasse in der JAR-Datei, z. B. „org.apache.spark.examples.SparkPi“.- Weitere Optionen:Sie können auch andere Ressourcenfelder für Batcharbeitslasten verwenden, z. B. das Feld
sparkBatch.args, um Argumente an Ihre Arbeitslast zu übergeben. Weitere Informationen finden Sie in der Ressourcendokumentation unterBatch. Informationen zur Verwendung eines Persistent History Servers (PHS) finden Sie unter Persistent History Server einrichten. Hinweis: Der PHS muss sich in der Region befinden, in der Sie Batch-Arbeitslasten ausführen.
HTTP-Methode und URL:
POST https://dataproc.googleapis.com/v1/projects/project-id/locations/region/batches
JSON-Text anfordern:
{
"runtimeConfig":{
"containerImage":"custom-container-image
},
"sparkBatch":{
"jarFileUris":[
"jar-uri"
],
"mainClass":"class"
}
}
Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:
Sie sollten in etwa folgende JSON-Antwort erhalten:
{
"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"
}
Benutzerdefiniertes Container-Image erstellen
Benutzerdefinierte Container-Images für Dataproc Serverless for Spark sind Docker-Images. Sie können die Tools zum Erstellen von Docker-Images verwenden, um benutzerdefinierte Container-Images zu erstellen. Die Images müssen jedoch bestimmte Bedingungen erfüllen, um mit Dataproc Serverless for Spark kompatibel zu sein. In den folgenden Abschnitten werden diese Bedingungen erläutert.
Betriebssystem
Sie können ein beliebiges Betriebssystem-Basis-Image für Ihr benutzerdefiniertes Container-Image auswählen.
Empfehlung: Verwenden Sie die Standard-Debian-12-Images, z. B. debian:12-slim, da sie getestet wurden, um Kompatibilitätsprobleme zu vermeiden.
Dienstprogramme
Sie müssen die folgenden Dienstprogrammpakete, die zum Ausführen von Spark erforderlich sind, in Ihr benutzerdefiniertes Container-Image aufnehmen:
procpstini
Wenn Sie XGBoost über Spark (Java oder Scala) ausführen möchten, müssen Sie Folgendes einschließen:
libgomp1
Containernutzer
Bei Dataproc Serverless for Spark werden Container als spark-Linux-Nutzer mit der UID 1099 und der GID 1099 ausgeführt. USER Direktive, die in Dockerfiles für benutzerdefinierte Container-Images festgelegt sind, werden bei der Laufzeit ignoriert. Verwenden Sie die UID und GID für die Dateisystemberechtigungen.
Wenn Sie beispielsweise eine JAR-Datei unter /opt/spark/jars/my-lib.jar im Image als Arbeitslastabhängigkeit hinzufügen, müssen Sie dem Nutzer spark die Leseberechtigung für die Datei erteilen.
Image-Streaming
Bei Dataproc Serverless for Spark wird für eine Arbeitslast, für die ein benutzerdefiniertes Container-Image erforderlich ist, normalerweise das gesamte Image auf die Festplatte heruntergeladen. Dies kann zu einer Verzögerung bei der Initialisierung führen, insbesondere bei Kunden mit großen Bildern.
Sie können stattdessen das Bildstreaming verwenden, eine Methode zum Abrufen von Bilddaten nach Bedarf. So kann die Arbeitslast gestartet werden, ohne auf den Download des gesamten Images warten zu müssen. Dies kann die Initialisierungszeit verbessern. Wenn Sie das Bildstreaming aktivieren möchten, müssen Sie die Container File System API aktivieren. Außerdem müssen Sie Ihre Container-Images in Artifact Registry speichern. Das Artifact Registry-Repository muss sich in derselben Region wie Ihre Dataproc-Arbeitslast oder in einer Multi-Region befinden, die der Region entspricht, in der Ihre Arbeitslast ausgeführt wird. Wenn Dataproc das Bild nicht unterstützt oder der Bildstreamingdienst nicht verfügbar ist, wird das gesamte Bild von unserer Streamingimplementierung heruntergeladen.
Folgendes wird für das Bildstreaming nicht unterstützt:
- Bilder mit leeren oder doppelten Ebenen
- Images, die das V2 Image Manifest, Schemaversion 1 verwenden
In diesen Fällen ruft Dataproc das gesamte Image ab, bevor die Arbeitslast gestartet wird.
Spark
Fügen Sie Spark nicht in Ihr benutzerdefiniertes Container-Image ein. Bei der Laufzeit werden von Dataproc Serverless for Spark Spark-Binärdateien und ‑Konfigurationen vom Host in den Container bereitgestellt: Binärdateien werden im Verzeichnis /usr/lib/spark und Konfigurationen im Verzeichnis /etc/spark/conf bereitgestellt. Vorhandene Dateien in diesen Verzeichnissen werden zur Laufzeit von Dataproc Serverless für Spark überschrieben.
Java-Laufzeitumgebung
Fügen Sie Ihre eigene Java-Laufzeitumgebung (JRE) nicht in Ihr benutzerdefiniertes Container-Image ein. Bei der Laufzeit wird OpenJDK von Dataproc Serverless for Spark vom Host in den Container bereitgestellt. Wenn Sie eine JRE in Ihr benutzerdefiniertes Container-Image aufnehmen, wird sie ignoriert.
Java-Pakete
Sie können JAR-Dateien als Spark-Arbeitslastabhängigkeiten in Ihr benutzerdefiniertes Container-Image aufnehmen und die Umgebungsvariable SPARK_EXTRA_CLASSPATH so festlegen, dass die JAR-Dateien eingeschlossen werden. Dataproc Serverless für Spark fügt den Wert der Umgebungsvariablen in den Klassenpfad der Spark-JVM-Prozesse ein. Empfehlung: Legen Sie JAR-Dateien im Verzeichnis /opt/spark/jars ab und legen Sie SPARK_EXTRA_CLASSPATH auf /opt/spark/jars/* fest.
Sie können das JAR-File der Arbeitslast in Ihr benutzerdefiniertes Container-Image aufnehmen und beim Einreichen der Arbeitslast auf einen lokalen Pfad verweisen, z. B. file:///opt/spark/jars/my-spark-job.jar. Ein Beispiel finden Sie unter Spark-Batcharbeitslast mit benutzerdefiniertem Container-Image einreichen.
Python-Pakete
Standardmäßig wird in Dataproc Serverless for Spark Conda zur Laufzeit vom Host auf das Verzeichnis /opt/dataproc/conda im Container bereitgestellt.
PYSPARK_PYTHON ist auf /opt/dataproc/conda/bin/python gesetzt. Das Basisverzeichnis /opt/dataproc/conda/bin ist in PATH enthalten.
Sie können Ihre Python-Umgebung mit Paketen in einem anderen Verzeichnis in Ihrem benutzerdefinierten Container-Image einschließen, z. B. in /opt/conda, und die Umgebungsvariable PYSPARK_PYTHON auf /opt/conda/bin/python festlegen.
Ihr benutzerdefiniertes Container-Image kann andere Python-Module enthalten, die nicht Teil der Python-Umgebung sind, z. B. Python-Scripts mit Dienstprogrammfunktionen.
Legen Sie die Umgebungsvariable PYTHONPATH so fest, dass sie die Verzeichnisse enthält, in denen sich die Module befinden.
R-Umgebung
Sie können die R-Umgebung in Ihrem benutzerdefinierten Container-Image mit einer der folgenden Optionen anpassen:
- Verwenden Sie Conda, um R-Pakete aus dem
conda-forge-Kanal zu verwalten und zu installieren. - Fügen Sie ein R-Repository für das Linux-Betriebssystem Ihres Container-Images hinzu und installieren Sie R-Pakete mit dem Linux-Betriebssystem-Paketmanager (siehe R Software Package Index).
Bei beiden Optionen müssen Sie die Umgebungsvariable R_HOME so festlegen, dass sie auf Ihre benutzerdefinierte R-Umgebung verweist. Ausnahme: Wenn Sie Conda sowohl zum Verwalten Ihrer R-Umgebung als auch zum Anpassen Ihrer Python-Umgebung verwenden, müssen Sie die Umgebungsvariable R_HOME nicht festlegen. Sie wird automatisch basierend auf der Umgebungsvariablen PYSPARK_PYTHON festgelegt.
Beispiel für die Erstellung eines benutzerdefinierten Container-Images
Dieser Abschnitt enthält Beispiele für die Erstellung benutzerdefinierter Container-Images. Dazu gehören Beispiel-Dockerfiles, gefolgt von einem Build-Befehl. Ein Beispiel enthält die minimale Konfiguration, die zum Erstellen eines Images erforderlich ist. Das andere Beispiel enthält Beispiele für zusätzliche Konfigurationen, einschließlich Python- und R-Bibliotheken.
Minimalkonfiguration
# Recommendation: Use Debian 12.
FROM debian:12-slim
# Suppress interactive prompts
ENV DEBIAN_FRONTEND=noninteractive
# Install utilities required by Spark scripts.
RUN apt update && apt install -y procps tini libjemalloc2
# Enable jemalloc2 as default memory allocator
ENV LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
# 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
Zusätzliche Konfiguration
# Recommendation: Use Debian 12.
FROM debian:12-slim
# Suppress interactive prompts
ENV DEBIAN_FRONTEND=noninteractive
# Install utilities required by Spark scripts.
RUN apt update && apt install -y procps tini libjemalloc2
# Enable jemalloc2 as default memory allocator
ENV LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
# Install utilities required by XGBoost for Spark.
RUN apt install -y procps libgomp1
# Install and configure Miniconda3.
ENV CONDA_HOME=/opt/miniforge3
ENV PYSPARK_PYTHON=${CONDA_HOME}/bin/python
ENV PATH=${CONDA_HOME}/bin:${PATH}
ADD https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh .
RUN bash Miniforge3-Linux-x86_64.sh -b -p /opt/miniforge3 \
&& ${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 --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/mamba install ipython ipykernel
# Install Conda packages.
#
# The following packages are installed in the default image.
# Recommendation: include all packages.
#
# Use mamba to quickly install packages.
RUN ${CONDA_HOME}/bin/mamba install -n base \
accelerate \
bigframes \
cython \
deepspeed \
evaluate \
fastavro \
fastparquet \
gcsfs \
google-cloud-aiplatform \
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 \
langchain \
lightgbm \
koalas \
matplotlib \
mlflow \
nltk \
numba \
numpy \
openblas \
orc \
pandas \
pyarrow \
pynvml \
pysal \
pytables \
python \
pytorch-cpu \
regex \
requests \
rtree \
scikit-image \
scikit-learn \
scipy \
seaborn \
sentence-transformers \
sqlalchemy \
sympy \
tokenizers \
transformers \
virtualenv \
xgboost
# Install pip packages.
RUN ${PYSPARK_PYTHON} -m pip install \
spark-tensorflow-distributor \
torcheval
# Install R and R libraries.
RUN ${CONDA_HOME}/bin/mamba install -n base \
r-askpass \
r-assertthat \
r-backports \
r-bit \
r-bit64 \
r-blob \
r-boot \
r-brew \
r-broom \
r-callr \
r-caret \
r-cellranger \
r-chron \
r-class \
r-cli \
r-clipr \
r-cluster \
r-codetools \
r-colorspace \
r-commonmark \
r-cpp11 \
r-crayon \
r-curl \
r-data.table \
r-dbi \
r-dbplyr \
r-desc \
r-devtools \
r-digest \
r-dplyr \
r-ellipsis \
r-evaluate \
r-fansi \
r-fastmap \
r-forcats \
r-foreach \
r-foreign \
r-fs \
r-future \
r-generics \
r-ggplot2 \
r-gh \
r-glmnet \
r-globals \
r-glue \
r-gower \
r-gtable \
r-haven \
r-highr \
r-hms \
r-htmltools \
r-htmlwidgets \
r-httpuv \
r-httr \
r-hwriter \
r-ini \
r-ipred \
r-isoband \
r-iterators \
r-jsonlite \
r-kernsmooth \
r-knitr \
r-labeling \
r-later \
r-lattice \
r-lava \
r-lifecycle \
r-listenv \
r-lubridate \
r-magrittr \
r-markdown \
r-mass \
r-matrix \
r-memoise \
r-mgcv \
r-mime \
r-modelmetrics \
r-modelr \
r-munsell \
r-nlme \
r-nnet \
r-numderiv \
r-openssl \
r-pillar \
r-pkgbuild \
r-pkgconfig \
r-pkgload \
r-plogr \
r-plyr \
r-praise \
r-prettyunits \
r-processx \
r-prodlim \
r-progress \
r-promises \
r-proto \
r-ps \
r-purrr \
r-r6 \
r-randomforest \
r-rappdirs \
r-rcmdcheck \
r-rcolorbrewer \
r-rcpp \
r-rcurl \
r-readr \
r-readxl \
r-recipes \
r-recommended \
r-rematch \
r-remotes \
r-reprex \
r-reshape2 \
r-rlang \
r-rmarkdown \
r-rodbc \
r-roxygen2 \
r-rpart \
r-rprojroot \
r-rserve \
r-rsqlite \
r-rstudioapi \
r-rvest \
r-scales \
r-selectr \
r-sessioninfo \
r-shape \
r-shiny \
r-sourcetools \
r-spatial \
r-squarem \
r-stringi \
r-stringr \
r-survival \
r-sys \
r-teachingdemos \
r-testthat \
r-tibble \
r-tidyr \
r-tidyselect \
r-tidyverse \
r-timedate \
r-tinytex \
r-usethis \
r-utf8 \
r-uuid \
r-vctrs \
r-whisker \
r-withr \
r-xfun \
r-xml2 \
r-xopen \
r-xtable \
r-yaml \
r-zip
ENV R_HOME=/usr/lib/R
# Add extra Python modules.
ENV PYTHONPATH=/opt/python/packages
RUN mkdir -p "${PYTHONPATH}"
# 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}"
# 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
Build-Befehl
Führen Sie den folgenden Befehl im Dockerfile-Verzeichnis aus, um das benutzerdefinierte Image zu erstellen und in die Artifact Registry zu übertragen.
# Build and push the image. gcloud builds submit --region=REGION \ --tag REGION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:IMAGE_VERSION