Configurar VMs de worker do Dataflow

Neste documento, descrevemos como configurar as VMs de trabalho para um job do Dataflow.

Por padrão, o Dataflow seleciona o tipo de máquina para as VMs de worker que executam seu job, além do tamanho e do tipo do Persistent Disk. Para configurar as VMs de worker, defina as seguintes opções de pipeline ao criar o job.

Tipo de máquina

O tipo de máquina do Compute Engine que o Dataflow usa ao iniciar VMs de worker. É possível usar tipos de máquina x86 ou Arm, incluindo tipos personalizados.

Java

Defina a opção de pipeline workerMachineType.

Python

Defina a opção de pipeline machine_type.

Go

Defina a opção de pipeline worker_machine_type.

  • Para Arm, as séries de máquinas Tau T2A e C4A são compatíveis. Para mais informações sobre o uso de VMs ARM, consulte Usar VMs ARM no Dataflow.

  • As VMs x86 são compatíveis automaticamente.

  • Os tipos de máquina com núcleo compartilhado (por exemplo, f1-micro, g1-small, e2-micro, e2-small e e2-medium) não são recomendados para jobs do Dataflow e não recebem suporte de acordo com o Contrato de nível de serviço do Dataflow.

  • O faturamento não depende da família de tipos de máquinas. Para mais informações, consulte Preços do Dataflow.

  • Para os tipos de máquina f1-micro e g1-small, o Dataflow fatura como se eles tivessem uma vCPU. Para os tipos e2-micro, e2-small e e2-medium, o Dataflow fatura como se eles tivessem duas vCPUs. Essas taxas são cobradas mesmo que os tipos de máquina com núcleo compartilhado forneçam menos do que as vCPUs faturadas de tempo de CPU sustentado.

Tipos de máquina personalizados

Para especificar um tipo de máquina personalizado, use o seguinte formato: FAMILY-vCPU-MEMORY. Substitua o seguinte:

  • FAMILY. Use um dos seguintes valores:
    Série de máquinaValor
    N1custom
    N2n2-custom
    N2Dn2d-custom
    n4-custom
    E2e2-custom
  • vCPU: o número de vCPUs.
  • MEMORY: a memória, em MB.

Para ativar a memória estendida, adicione -ext ao tipo de máquina. Exemplos: n2-custom-6-3072, n2-custom-2-32768-ext.

Para mais informações sobre tipos de máquinas personalizadas válidas, consulte Tipos de máquinas personalizadas na documentação do Compute Engine.

Tipo de disco

O tipo de Persistent Disk a ser usado.

Não especifique um Persistent Disk ao usar o Streaming Engine ou o tipo de máquina N4.

Java

Defina a opção de pipeline workerDiskType.

Python

Defina a opção de pipeline worker_disk_type.

Go

Defina a opção de pipeline disk_type.

Para especificar o tipo de disco, use o seguinte formato: compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/DISK_TYPE.

Substitua:

  • PROJECT_ID: ID do projeto;
  • ZONE: a zona do Persistent Disk, por exemplo, us-central1-b.
  • DISK_TYPE: o tipo de disco, por exemplo, pd-ssd, pd-standard ou hyperdisk-balanced.

Para mais informações, consulte a página de referência da API Compute Engine para diskTypes.

Provisionar IOPS e capacidade de processamento

Ao usar discos Hyperdisk Balanced, é possível provisionar IOPS e capacidade de processamento independente do tamanho do disco. Para provisionar IOPS e capacidade de processamento, use as seguintes opções de pipeline:

Java

  • Para provisionar IOPS, defina a opção de pipeline diskProvisionedIOPS.
  • Para provisionar a capacidade em MiB/s, defina a opção de pipeline diskProvisionedThroughput.

Python

  • Para provisionar IOPS, defina a opção de pipeline disk_provisioned_iops.
  • Para provisionar a capacidade em MiB/s, defina a opção de pipeline disk_provisioned_throughput_mibps.

Go

  • Para provisionar IOPS, defina a opção de pipeline disk_provisioned_iops.
  • Para provisionar a capacidade em MiB/s, defina a opção de pipeline disk_provisioned_throughput_mibps.

Se você não definir essas opções, os jobs que usam discos hyperdisk-balanced vão usar por padrão o desempenho de referência de 3.000 IOPS e 140 MiB/s de capacidade de processamento. Para mais informações, consulte Sobre o Hyperdisk Balanced na documentação do Compute Engine.

Limitações

  • O provisionamento de IOPS e capacidade de processamento para o Hyperdisk Balanced é compatível com as versões 2.74.0 ou mais recentes do SDK do Apache Beam.

Tamanho do disco

O tamanho do disco permanente.

Java

Defina a opção de pipeline diskSizeGb.

Python

Defina a opção de pipeline disk_size_gb.

Go

Defina a opção de pipeline disk_size_gb.

Se você definir essa opção, especifique pelo menos 30 GB para incluir a imagem de inicialização e os registros locais do worker.

Diminuir o tamanho do disco reduz a E/S aleatória disponível. Jobs com limite aleatório que não usam o Dataflow Shuffle ou o Streaming Engine podem resultar em aumento do tempo de execução e do custo do job.

jobs em lote

Para jobs em lote que usam o Dataflow Shuffle, essa opção define o tamanho do disco de inicialização de uma VM de worker. Para jobs em lote que não usam o Dataflow Shuffle, essa opção define o tamanho dos discos usados para armazenar dados aleatórios. O tamanho do disco de inicialização não é afetado.

Se um job em lote usar o Dataflow Shuffle, o tamanho de disco padrão será de 25 GB. Caso contrário, o padrão é 250 GB.

Jobs de streaming

Para jobs de streaming que usam o Streaming Engine, essa opção define o tamanho dos discos de inicialização. Para jobs de streaming que não usam o Streaming Engine, essa opção define o tamanho de cada Persistent Disk adicional criado pelo serviço Dataflow. O disco de inicialização não é afetado.

Se um job de streaming não usar o Streaming Engine, será possível definir o tamanho do disco de inicialização com o sinalizador experimental streaming_boot_disk_size_gb. Por exemplo, especifique --experiments=streaming_boot_disk_size_gb=80 para criar discos de inicialização de 80 GB.

Se um job de streaming usar o Streaming Engine, o tamanho padrão do disco será de 30 GB. Caso contrário, o padrão é 400 GB.

Plataforma mínima de CPU

Se você tiver cargas de trabalho sensíveis ao desempenho que dependem de recursos específicos da CPU, poderá especificar uma plataforma mínima de CPU para VMs de trabalho. Essa opção garante que os workers do Dataflow usem um processador que atenda ou exceda a geração de CPU especificada.

Para especificar a plataforma mínima de CPU, defina a opção de pipeline experimental min_cpu_platform. O valor precisa ser o nome exato da plataforma de CPU selecionada, como AMD Milan ou Intel Ice Lake. Por exemplo, especifique --experiments=min_cpu_platform='AMD Milan' para definir a plataforma mínima de CPU como AMD Milan. Para uma lista das plataformas mínimas de CPU compatíveis, consulte Disponibilidade de plataformas de CPU. Para informações sobre limitações, consulte limitações ao especificar uma plataforma mínima de CPU.

Para verificar se as VMs de worker do Dataflow foram criadas com a plataforma mínima de CPU especificada, confira as entradas do Cloud Logging do job da seguinte maneira:

  1. Acesse o console do Cloud Logging no Google Cloud console.

  2. Use o filtro a seguir e substitua a plataforma de CPU e o ID do job do Dataflow de exemplo pelas informações do seu job.

    resource.type="gce_instance"
protoPayload.request.minCpuPlatform="AMD Milan"
"dataflow_job_id"

  3. Analise os registros resultantes para confirmar se o Dataflow especificou a plataforma mínima de CPU durante o processo de criação da VM.

Use o Cloud Storage FUSE para montar seus buckets do Cloud Storage em VMs do Dataflow

O Cloud Storage FUSE permite ativar seus buckets do Cloud Storage diretamente com VMs do Dataflow, permitindo que o software acesse arquivos como se eles fossem locais. Essa integração elimina a necessidade de pré-download de dados, simplificando o acesso aos dados para suas cargas de trabalho. Para mais informações, consulte Processar dados de ML usando o Dataflow e o Cloud Storage FUSE.

A seguir