Usar contêineres personalizados com o Dataproc sem servidor para Spark

O Dataproc Serverless para Spark executa cargas de trabalho em contêineres do Docker. O contêiner fornece o ambiente de execução para o driver da carga de trabalho e executores. Por padrão, o Dataproc sem servidor para Spark usa uma imagem de contêiner que inclui os pacotes padrão Spark, Java, Python e R associada a uma versão de lançamento do ambiente de execução. Dataproc sem servidor para Spark lotes permite usar uma imagem de contêiner personalizada em vez da imagem imagem. Normalmente, uma imagem de contêiner personalizada adiciona cargas de trabalho do Spark em Java ou Python dependências não fornecidas pela imagem de contêiner padrão. Importante:não incluir o Spark na imagem personalizada do contêiner; O Dataproc Serverless para Spark ativará o Spark no contêiner durante a execução.

Enviar uma carga de trabalho em lote do Spark usando uma imagem de contêiner personalizada

gcloud

Use o gcloud dataproc batch submit spark comando com a sinalização --container-image para especificar a imagem de contêiner personalizada quando você envia uma carga de trabalho em lote do 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

Observações:

  • Custom-image:especifique a imagem do contêiner personalizada usando o seguinte formato de nomenclatura de imagem do Container Registry: {hostname}/{project-id}/{image}:{tag}, por exemplo, "gcr.io/my-project-id/my-image:1.0.1". Observação: você precisa hospedar sua imagem personalizada de contêiner o Container Registry ou Artifact Registry. O Dataproc sem servidor não pode buscar contêineres de outros registros.
  • --jars:especifique um caminho para um carga de trabalho do usuário incluída na imagem do contêiner personalizada ou localizada no Cloud Storage, por exemplo, file:///opt/spark/jars/spark-examples.jar ou gs://my-bucket/spark/jars/spark-examples.jar.
  • Opções de comando de outros lotes: é possível adicionar outros lotes opcionais sinalizações de comando, por exemplo, usar um servidor de histórico permanente (PHS, na sigla em inglês). Observação: o PHS precisa estar localizado na região em que você executa cargas de trabalho em lote.
  • argumentos de carga de trabalhoVocê pode adicionar qualquer argumento de carga de trabalho adicionando um "--" para ao final do comando, seguido pelos argumentos da carga de trabalho.

REST

A imagem personalizada do contêiner é fornecida pelo RuntimeConfig.containerImage como parte de um batches.create solicitação de API.

O exemplo a seguir mostra como usar um contêiner personalizado para enviar uma carga de trabalho em lote usando o Dataproc sem servidor para Spark. batches.create.

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • project-id: ID do projeto do Google Cloud
  • region: região
  • custom-container-image: especifique a imagem do contêiner personalizada usando o seguinte formato de nomenclatura de imagem do Container Registry: {hostname}/{project-id}/{image}:{tag}, por exemplo, "gcr.io/my-project-id/my-image:1.0.1". Observação: você precisa hospedar seu contêiner personalizado Container Registry. ou o Artifact Registry . O Dataproc sem servidor não pode buscar contêineres de outros registros.
  • jar-uri: Especifique um caminho para um jar de carga de trabalho incluído na imagem do contêiner personalizado ou localizado no Cloud Storage, por exemplo: "/opt/spark/jars/spark-examples.jar" ou "gs:///spark/jars/spark-examples.jar".
  • class: o nome totalmente qualificado de uma classe no arquivo jar, como "org.apache.spark.examples.SparkPi".
  • Outras opções:é possível usar outros campos de recursos de cargas de trabalho em lote, como use o sparkBatch.args para passar argumentos para a carga de trabalho (consulte a Batch documentação do recurso para mais informações). Para usar um Servidor de histórico permanente (PHS), consulte Como configurar um servidor de histórico permanente. Observação: o PHS precisa estar localizado na região em que você executa cargas de trabalho em lote.

Método HTTP e URL: 

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

Corpo JSON da solicitação:

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

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

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

Criar uma imagem de contêiner personalizada

As imagens de contêiner personalizadas do Dataproc Serverless para Spark são imagens do Docker. Você pode usar as ferramentas para criar imagens Docker e criar imagens de contêiner personalizadas, mas há que as imagens precisam atender para serem compatíveis com o Dataproc sem servidor para Spark. As seções a seguir explicam essas condições.

Sistema operacional

Você pode escolher qualquer imagem de sistema operacional como a imagem de base da sua imagem personalizada do contêiner. Recomendação: prefira as imagens padrão do Debian 11 (por exemplo, debian:11-slim). desde que foram submetidos aos testes para evitar problemas de compatibilidade.

Utilitários

Você precisa incluir os seguintes pacotes de utilitários, que são obrigatórios para executar o Spark na sua imagem personalizada do contêiner:

  • procps
  • tini

Para executar o XGBoost a partir do Spark (Java ou Scala), você precisa incluir libgomp1

Usuário do contêiner

O Dataproc Serverless para Spark executa contêineres como o usuário spark do Linux com uma UID 1099 e um GID 1099. Diretivas USER definidas em Dockerfiles de imagem de contêiner personalizada são ignorados no tempo de execução. Use o UID e o GID para permissões do sistema de arquivos. Por exemplo, se você adicionar um arquivo jar em /opt/spark/jars/my-lib.jar na imagem como dependência da carga de trabalho, é necessário conceder ao usuário spark permissão de leitura para o .

Streaming de imagens

O Dataproc Serverless para Spark normalmente inicia uma carga de trabalho que exige uma imagem de contêiner personalizada fazendo o download da imagem inteira para o disco. Isso pode significar um atraso na inicialização especialmente para clientes com imagens grandes.

Em vez disso, você pode usar o streaming de imagem, que é um método para extrair dados de imagem em uma conforme necessário. Assim, a carga de trabalho pode ser iniciada sem esperar imagem para download, possivelmente melhorando o tempo de inicialização. Para ativar o recurso de imagem streaming, é necessário ativar o API Container File System. Você também precisa armazenar as imagens de contêiner no Artifact Registry e no Artifact Registry repositório de dados deve estar na mesma região que sua carga de trabalho do Dataproc multirregional que corresponda à região em que sua carga de trabalho é executada. Se o Dataproc não oferecer suporte à imagem ou ao streaming de imagens não estiver disponível, nossa implementação de streaming faz o download de todo o imagem. Não oferecemos suporte aos seguintes recursos para streaming de imagens:

Nesses casos, o Dataproc extrai a imagem inteira antes de iniciar a carga de trabalho.

Spark

Não inclua o Spark na imagem personalizada do contêiner. No ambiente de execução, o Dataproc sem servidor para Spark monta binários e configurações do Spark do host no contêiner: binários são montados no diretório /usr/lib/spark e as configurações são montados no /etc/spark/conf. Os arquivos existentes nesses diretórios são substituídos pelo Dataproc Serverless para Spark no ambiente de execução.

Java Runtime Environment

Não inclua seu Java Runtime Environment (JRE) na imagem personalizada do contêiner. No ambiente de execução, o Dataproc sem servidor para Spark monta OpenJDK do host no contêiner do Docker. Se você incluir um JRE na sua imagem personalizada do contêiner, ele será ignorado.

Pacotes Java

É possível incluir arquivos jar como dependências de carga de trabalho do Spark na imagem personalizada do contêiner. Defina a variável de ambiente SPARK_EXTRA_CLASSPATH para incluir os jars. O Dataproc sem servidor para Spark adicionar o valor da variável env no caminho de classe dos processos da JVM do Spark. Recomendação: coloque jars no diretório /opt/spark/jars e defina SPARK_EXTRA_CLASSPATH. para /opt/spark/jars/*.

Inclua o jar da carga de trabalho na imagem do contêiner personalizado e mencione-o com um caminho local. ao enviar a carga de trabalho, por exemplo, file:///opt/spark/jars/my-spark-job.jar Consulte Enviar uma carga de trabalho em lote do Spark usando uma imagem de contêiner personalizada para conferir um exemplo.

Pacotes do Python

Por padrão, o Dataproc sem servidor para montagens do Spark Conda do host para diretório /opt/dataproc/conda no contêiner no ambiente de execução. PYSPARK_PYTHON é definido como /opt/dataproc/conda/bin/python. O diretório base, /opt/dataproc/conda/bin está incluído em PATH.

É possível incluir seu ambiente Python com pacotes em um diretório diferente na imagem personalizada do contêiner, por exemplo, em /opt/conda, e defina o PYSPARK_PYTHON como /opt/conda/bin/python.

A imagem personalizada do contêiner pode incluir outros módulos Python que não fazem parte do ambiente Python, por exemplo, scripts Python com funções utilitárias. Defina a variável de ambiente PYTHONPATH para incluir os diretórios em que módulos estão localizados.

Ambiente R

Você pode personalizar o ambiente R em sua imagem personalizada de contêiner usando uma das opções a seguir:

  • Use o Conda para gerenciar e instalar pacotes de R do canal conda-forge.
  • Adicionar um repositório R para sua imagem de contêiner do SO Linux e instalar os pacotes de R com o gerenciador de pacotes do SO Linux (consulte a Índice do pacote de software R).

Ao usar uma dessas opções, você precisa definir a variável de ambiente R_HOME. para apontar para seu ambiente R personalizado. Exceção: se você estiver usando o Conda para para gerenciar seu ambiente R e personalizar seu ambiente Python, Não é preciso definir a variável de ambiente R_HOME. ele é automaticamente com base na variável de ambiente PYSPARK_PYTHON.

Exemplo de build de imagem de contêiner personalizada

Esta seção inclui um exemplo de criação de imagem de contêiner personalizada, começando com um Dockerfile de amostra.

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}"
COPY spark-bigquery-with-dependencies_2.12-0.22.2.jar "${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 build

Execute no diretório do Dockerfile.

IMAGE=gcr.io/my-project/my-image:1.0.1

# Download the BigQuery connector.
gsutil cp \
  gs://spark-lib/bigquery/spark-bigquery-with-dependencies_2.12-0.22.2.jar .

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