Referência de configuração de compute

Este artigo explica as configurações disponíveis na interface de usuário Criar Compute. A maioria dos usuários cria recursos de compute usando suas políticas atribuídas, o que limita as configurações configuráveis. Se você não vir uma configuração específica em sua interface do usuário, é porque a política que você selecionou não permite que você configure essa configuração.

Página de criação de compute irrestrita do GCP

As configurações e as ferramentas de gerenciamento descritas neste artigo se aplicam a todos os fins e ao Job compute. Para obter mais considerações sobre a configuração do Job compute, consulte Configurar compute para o Job.

Crie um novo recurso de compute para todos os fins

Para criar um novo recurso de compute de uso geral:

  1. Na barra lateral do workspace, clique em Compute.

  2. Clique no botão Criar compute.

  3. Configure o recurso de compute.

  4. Clique em Criar compute.

Seu novo recurso de compute iniciará automaticamente e estará pronto para uso em breve.

Políticas

Políticas são um conjunto de regras usadas para limitar as opções de configuração disponíveis para os usuários quando eles criam recursos de compute. Se um usuário não tiver a permissão de Criação de cluster irrestrita, ele só poderá criar recursos de compute usando suas políticas concedidas.

Para criar recursos de compute de acordo com uma política, selecione uma política no menu suspenso Política.

Por padrão, todos os usuários têm acesso à política Compute Pessoal, permitindo que eles criem recursos de compute de máquina única. Se você precisar de acesso ao Compute Pessoal ou a quaisquer políticas adicionais, entre em contato com o administrador do seu workspace.

Compute de nó único ou multinó

Dependendo da política, você pode selecionar entre criar um recurso de compute de Nó único ou um recurso de compute de Multinó.

O compute de nó único destina-se a jobs que usam pequenas quantidades de dados ou cargas de trabalho não distribuídas, como bibliotecas de aprendizado de máquina de nó único. O compute multinó deve ser usado para jobs maiores com cargas de trabalho distribuídas.

Propriedades do nó único

Um recurso de compute de nó único tem as seguintes propriedades:

  • Executa o Spark localmente.

  • O driver atua como mestre e worker, sem nós worker.

  • Gera uma thread executor por núcleo lógico no recurso de compute, menos 1 núcleo para o driver.

  • Salva todas as saídas de log stderr, stdout e log4j no log do driver.

  • Não pode ser convertido em um recurso de compute multinó.

Selecionando nó único ou multinó

Considere seu caso de uso ao decidir entre compute de nó único ou multinó:

  • O processamento de dados em grande escala esgotará os recursos em um recurso de compute de nó único. Para essas cargas de trabalho, a Databricks recomenda o uso de compute multinó.

  • O compute de nó único não foi projetado para ser compartilhado. Para evitar conflitos de recursos, a Databricks recomenda o uso de um recurso de compute multinó quando o compute precisa ser compartilhado.

  • Um recurso de compute multinó não pode ser dimensionado para 0 workers. Use o compute de nó único em vez disso.

  • Compute de nó único não é compatível com isolamento de processo.

  • O agendamento de GPU não está habilitado no compute de nó único.

  • Em compute de nó único, o Spark não consegue ler arquivos Parquet com uma coluna UDT. A seguinte mensagem de erro é exibida:

    The Spark driver has stopped unexpectedly and is restarting. Your notebook will be automatically reattached.

    Para contornar esse problema, desative o leitor Parquet nativo:

    spark.conf.set("spark.databricks.io.parquet.nativeReader.enabled", False)

Modos de acesso

O modo de acesso é um recurso de segurança que determina quem pode usar o recurso de compute e os dados que eles podem acessar usando o recurso de compute. Todo recurso de compute no Databricks tem um modo de acesso.

A Databricks recomenda que o senhor use o modo de acesso compartilhado para todas as cargas de trabalho. Use o modo de acesso de usuário único somente se a funcionalidade necessária não for suportada pelo modo de acesso compartilhado.

Modo de acesso

Visível para o usuário

Suporte UC

Idiomas suportados

Notas

Único usuário

Sempre

Sim

Python, SQL, Scala, R

Pode ser atribuído e usado por um único usuário. Chamado de modo de acesso atribuído em alguns workspaces.

Compartilhado

Sempre (é necessário um plano Premium)

Sim

Python (no Databricks Runtime 11.3 LTS e superior), SQL, Scala (no compute habilitado para Unity Catalog usando Databricks Runtime 13.3 LTS e superior)

Pode ser usado por vários usuários com isolamento de dados entre os usuários.

Nenhum isolamento compartilhado

Os administradores podem ocultar este modo de acesso aplicando o isolamento do usuário na página de configurações do administrador.

Não

Python, SQL, Scala, R

Há uma configuração relacionada ao nível da conta para compute compartilhado sem isolamento.

Personalizado

Oculto (para todo novo compute)

Não

Python, SQL, Scala, R

Essa opção é exibida apenas se você tiver um recurso de compute existente sem um modo de acesso especificado.

Você pode atualizar um recurso de compute existente para atender aos requisitos do Unity Catalog definindo seu modo de acesso como Usuário Único ou Compartilhado. Para obter informações detalhadas sobre a funcionalidade que é suportada por cada um desses modos de acesso em workspaces habilitados para o Unity Catalog, consulte Limitações do modo de acesso do Compute para o Unity Catalog.

Observação

No Databricks Runtime 13.3 LTS e superior, scripts de inicialização e bibliotecas são suportados por todos os modos de acesso. Os requisitos e os níveis de suporte variam. Consulte Onde os scripts de inicialização podem ser instalados? e Bibliotecas com escopo de cluster.

Versões do Databricks Runtime

Databricks Runtime é o conjunto de componentes principais que são executados no seu compute. Selecione o runtime usando o menu suspenso Versão do Databricks Runtime. Para obter detalhes sobre versões específicas do Databricks Runtime, consulte Notas sobre a versão e compatibilidade do Databricks Runtime. Todas as versões incluem o Apache Spark. A Databricks recomenda o seguinte:

  • Para compute de uso geral, utilize a versão mais recente para garantir que você tenha as otimizações mais recentes e a compatibilidade mais atualizada entre seu código e os pacotes pré-carregados.

  • Para compute de job executando cargas de trabalho operacionais, considere usar a versão Long Term Support (LTS) do Databricks Runtime. Usar a versão LTS garantirá que você não tenha problemas de compatibilidade e possa testar sua carga de trabalho completamente antes de atualizar.

  • Para casos de uso de ciência de dados e machine learning, considere a versão Databricks Runtime ML.

Usar a aceleração Photon

O Photon está disponível em computação executando o Databricks Runtime 9.1 LTS e superior.

Para habilitar ou desabilitar a aceleração Photon, marque a caixa de seleção Usar Aceleração Photon. Para saber mais sobre o Photon, consulte O que é Photon?

Tipos de nó de worker e driver

Um recurso de compute consiste em um nó driver e zero ou mais nós worker. Você pode escolher tipos de instância de provedor de nuvem separados para os nós driver e worker, embora por padrão o nó driver use o mesmo tipo de instância que o nó worker. Diferentes famílias de tipos de instância se adaptam a diferentes casos de uso, como cargas de trabalho com uso intensivo de memória ou de computação.

O senhor também pode selecionar um pool para usar como worker ou nó de driver. Use apenas um pool com instâncias de VM preemptivas como seu tipo worker. Selecione um tipo de motorista sob demanda separado para evitar que seu motorista seja recuperado. Consulte Conectar-se a pools.

Tipo worker

No compute multinó, os nós worker executam os executores do Spark e outros serviços necessários para um recurso de compute funcionando corretamente. Quando você distribui sua carga de trabalho com o Spark, todo o processamento distribuído acontece nos nós worker. O Databricks executa um executor por nó worker. Portanto, os termos executor e worker são usados alternadamente no contexto da arquitetura do Databricks.

Dica

Para executar um trabalho do Spark, você precisa de pelo menos um nó de worker. Se o recurso de compute tiver zero workers, você poderá executar comandos não Spark no nó do driver, mas os comandos Spark falharão.

Endereços IP do nó do worker

O Databricks inicia nós worker com dois endereços IP privados cada. O endereço IP privado primário do nó hospeda o tráfego interno do Databricks. O endereço IP privado secundário é usado pelo contêiner Spark para comunicação dentro do cluster. Esse modelo permite que o Databricks forneça isolamento entre vários recursos de compute no mesmo workspace.

Tipo de driver

O nó do driver mantém as informações de estado de todos os notebooks conectados ao recurso de compute. O nó do driver também mantém o SparkContext, interpreta todos os comandos executados de um notebook ou uma biblioteca no recurso de compute e executa o mestre Apache Spark que se coordena com os executores do Spark.

O valor padrão do tipo de nó do driver é o mesmo que o tipo de nó do worker. Você pode escolher um tipo de nó de driver maior com mais memória se estiver planejando collect() muitos dados de workers do Spark e analisá-los no notebook.

Dica

Como o nó do driver mantém todas as informações de estado dos notebooks conectados, desanexe os notebooks não utilizados do nó do driver.

Tipos de instância de GPU

Para tarefas computacionalmente desafiadoras que exigem alto desempenho, como aquelas associadas à aprendizagem profunda, o Databricks oferece recursos de compute acelerados com unidades de processamento gráfico (GPUs). Para obter mais informações, consulte compute habilitada para GPU.

Instâncias preemptivas

Uma instância de VM preemptiva é uma instância que você pode criar e executar a um preço muito mais baixo do que as instâncias normais. No entanto, o Google Cloud pode interromper (apropriar-se de) essas instâncias se exigir acesso a esses recursos para outras tarefas. As instâncias preemptivas usam o excesso de capacidade do Google Compute Engine e, portanto, a disponibilidade varia de acordo com o uso.

Ao criar um novo recurso de computação, você pode habilitar instâncias de VM preemptivas de duas maneiras diferentes:

  1. Ao criar compute usando a interface do usuário, clique em instâncias preemptivas ao lado dos detalhes do Tipo de worker .

  2. Ao criar um pool de instâncias usando a interface do usuário, defina Sob demanda/preemptivo como Todos preemptivos, Preemptivo com GCP de fallback ou GCP sob demanda. Se as instâncias de VM preemptivas não estiverem disponíveis, por padrão, o compute voltará a usar instâncias de VM sob demanda. Para configurar o comportamento de fallback, defina gcp_attributes.gcp_availability como PREEMPTIBLE_GCP ou PREEMPTIBLE_WITH_FALLBACK_GCP. O padrão é ON_DEMAND_GCP.

{
  "instance_pool_name": "Preemptible w/o fallback API test",
  "node_type_id": "n1-highmem-4",
  "gcp_attributes": {
      "availability": "PREEMPTIBLE_GCP"
  }
}

Em seguida, crie um novo recurso de computação e defina Pool como um pool de instâncias preemptivo.

Tipos de instâncias com SSDs locais

Para ver a lista mais recente de tipos de instâncias, os preços de cada uma e o tamanho dos SSDs locais, consulte o estimador de preços do GCP.

Os tipos de instâncias que têm SSDs locais são criptografados com a criptografia padrão do lado do servidor do Google Cloud e usam automaticamente o armazenamento em cache em disco para melhorar o desempenho. Os tamanhos de caches em todos os tipos de instâncias são definidos automaticamente e, portanto, você não precisa definir o uso do disco explicitamente.

Configure SSDs locais para sua computação

Você pode configurar o número de SSDs locais a serem anexados ao recurso de computação quando usar a API de clusters para criar seu recurso de computação.

Para configurar o número de SSDs locais, defina um valor para local_ssd_count no objeto gcp_attributes. Cada tipo de instância só pode ser compatível com um determinado número de SSDs locais conectados. O valor especificado em local_ssd_count deve ser válido para o tipo de instância do driver e do worker. Para obter mais informações, consulte o GCP para SSDs e tipos de máquinas locais.

Ativar autoscale

Quando a opção Ativar autoscale está marcada, você pode fornecer um número mínimo e máximo de workers para o recurso de compute. O Databricks então escolhe o número apropriado de workers necessários para executar seu job.

Para definir o número mínimo e máximo de workers entre os quais seu recurso de compute fará o autoscale, use os campos Mín workers e Máx workers ao lado do menu suspenso Tipo de worker.

Se você não habilitar o autoscale, deverá inserir um número fixo de workers no campo Workers ao lado da lista suspensa Tipo de worker.

Observação

Quando o recurso de compute está em execução, a página de detalhes de compute exibe o número de workers alocados. Você pode comparar o número de workers alocados com a configuração do worker e fazer os ajustes necessários.

Benefícios do dimensionamento automático

Com o autoscale, o Databricks realoca dinamicamente os workers para dar conta das características do seu job. Certas partes do seu pipeline podem ser mais exigentes computacionalmente do que outras, e o Databricks adiciona automaticamente workers adicionais durante essas fases do seu trabalho (e os remove quando não são mais necessários).

O autoscale facilita a obtenção de alta utilização porque você não precisa provisionar o compute para corresponder a uma carga de trabalho. Isso se aplica especialmente a cargas de trabalho cujos requisitos mudam ao longo do tempo (como explorar um conjunto de dados durante o dia), mas também pode se aplicar a uma carga de trabalho mais curta cujos requisitos de provisionamento são desconhecidos. O autoscale oferece, portanto, duas vantagens:

  • As cargas de trabalho podem ser executadas mais rapidamente em comparação com um recurso de compute subprovisionado de tamanho constante.

  • O autoscale pode reduzir os custos gerais em comparação com um recurso de compute de tamanho estático.

Dependendo do tamanho constante do recurso de compute e da carga de trabalho, o autoscale oferece um ou ambos os benefícios ao mesmo tempo. O tamanho do compute pode ficar abaixo do número mínimo de workers selecionados quando o provedor de nuvem encerra as instâncias. Nesse caso, o Databricks tenta continuamente provisionar novamente as instâncias para manter o número mínimo de workers.

Observação

O autoscale não está disponível para jobs spark-submit.

Observação

O dimensionamento automático de computação tem limitações ao reduzir o tamanho do cluster para cargas de trabalho de streaming estruturado. A Databricks recomenda usar Delta Live Tables com Autoscale aprimorado para cargas de trabalho de streaming. Consulte Otimize a utilização do cluster dos pipelines do Delta Live Tables com escalonamento automático aprimorado.

Como o Autoscale se comporta

O autoscale tem as seguintes características:

  • Começa adicionando 8 nós. Então escala exponencialmente, realizando tantos passos quantos forem necessários para atingir o máximo.

  • Reduz quando 90% dos nós não estão ocupados por 10 minutos e o compute está ocioso há pelo menos 30 segundos.

  • Reduz exponencialmente, começando com 1 nó.

autoscale com pools

Se estiver anexando seu recurso de compute a um pool, considere o seguinte:

  • Certifique-se de que o tamanho do compute solicitado seja menor ou igual ao número mínimo de instâncias ociosas no pool. Se for maior, o tempo de inicialização do compute será equivalente ao compute que não usa um pool.

Exemplo de Autoscale automático

Se você reconfigurar um recurso de compute estático para autoscale, o Databricks redimensiona imediatamente o recurso de compute dentro dos limites mínimo e máximo e, em seguida, inicia o autoscale. Como exemplo, a tabela a seguir demonstra o que acontece com um recurso de compute com um determinado tamanho inicial se você reconfigurar o recurso de compute para autoscale entre 5 e 10 nós.

Tamanho inicial

Tamanho após a reconfiguração

6

6

12

10

3

5

Ativar o autoscale do armazenamento local

As instâncias de compute do Google Cloud podem ser complementadas com armazenamento adicional em nível de worker usando discos persistentes de estado sólido zonais.

Com o armazenamento local de autoscale, o Databricks monitora a quantidade de espaço livre em disco disponível nos workers Spark de sua computação. Se um worker começar a ficar com pouco espaço em disco, o Databricks redimensionará automaticamente o PD SSD zonal antes que ele fique sem espaço em disco. Os volumes PD SSD zonais são anexados até um limite de 5 TB de espaço total em disco por instância (incluindo o armazenamento local da instância).

Para configurar o armazenamento de autoscale, selecione Ativar armazenamento local de autoscale.

Armazenamento provisionado padrão

O Databricks provisiona o seguinte armazenamento para cada nó de worker:

  • Um disco de inicialização por instância usado pelo sistema operacional host e pelos serviços internos do Databricks. O disco de inicialização é de 100 GB para instâncias que não são de GPU e de 200 GB para instâncias de GPU.

  • SSD local usado pelo worker do Spark. Hospeda os serviços e logs do Spark. Cada SSD local tem 375 GB. Para configurar o número de SSDs locais conectados, consulte Tipos de instâncias com SSDs locais.

  • SSD remotos quando o autoscale do armazenamento está habilitado. Começam em 150 GB na criação e no autoscale, conforme a necessidade.

Criptografia de disco local

Os tipos de instâncias que têm SSDs locais são criptografados com a criptografia padrão do lado do servidor do Google Cloud. Consulte Tipos de instâncias com SSDs locais.

Encerramento automático

Você pode definir o encerramento automático para compute. Durante a criação do compute, especifique um período de inatividade em minutos após o qual deseja que o recurso de compute seja encerrado.

Se a diferença entre a hora atual e o último comando executado no recurso de compute for maior que o período de inatividade especificado, o Databricks encerrará automaticamente esse compute. recurso Para obter mais informações sobre o encerramento de compute, consulte Encerrar um compute.

Tags

As tags permitem que você monitore facilmente o custo dos recursos de nuvem usados por vários grupos em sua organização. Especifique as tags como pares de valor-chave quando você criar o compute, e o Databricks aplicará essas tags aos pods do Databricks Runtime e aos volumes persistentes no cluster do GKE e aos relatórios de uso do DBU.

Os gráficos de uso faturável do Databricks no console de contas podem agregar o uso por tags individuais. Os relatórios CSV de uso faturável baixados da mesma página também incluem tags default e personalizadas. As tags também são propagadas para os rótulos GKE e GCE.

Para obter informações detalhadas sobre como os tipos de tag de pool e compute funcionam juntos, consulte Monitorar o uso com tags.

Para adicionar tags ao seu recurso de compute:

  1. Na seção Tags, adicione um par key-value para cada tag personalizada.

  2. Clique em Adicionar.

Conta de serviço do Google

Para associar esse recurso de computação a uma conta de serviço do Google usando o Google Identity, clique em Opções avançadas e adicione o endereço de e-mail de sua conta de serviço do Google no campo Conta de serviço do Google . Esse valor é usado para fazer a autenticação com as fontes de dados do GCS e do BigQuery.

Importante

A conta de serviço que você usar para acessar as fontes de dados do GCS e do BigQuery deve estar no mesmo projeto que a conta de serviço especificada ao configurar sua conta do Databricks.

Zonas de disponibilidade

Na página de configuração de computação, em Opções avançadas, selecione a zona de disponibilidade do recurso de computação. Essa configuração permite especificar qual zona de disponibilidade você deseja que o recurso de computação use. Por padrão, a configuração da zona de disponibilidade é definida como Automática. Com uma configuração de Automática, uma única zona de disponibilidade é escolhida automaticamente para você.

Você também pode escolher uma zona específica. A escolha de uma zona específica é útil principalmente se sua organização tiver comprado instâncias reservadas em zonas de disponibilidade específicas.

Zona de alta disponibilidade

Você também pode selecionar HA como a zona de disponibilidade. A alta disponibilidade (HA) é um recurso do sistema projetado para fornecer um nível consistente de tempo de atividade por períodos prolongados. O uso de uma configuração de zona HA pode reduzir a probabilidade de problemas de disponibilidade de zona única, como indisponibilidade zonal ou impossibilidade de originar a capacidade da instância em uma zona.

Quando HA é selecionado como a zona de disponibilidade, o Databricks equilibra o posicionamento das instâncias entre as zonas em uma região. Isso pode levar a um aumento no preço devido a taxas de saída entre zonas.

Configuração do Spark

Para ajustar os jobs do Spark, você pode fornecer propriedades de configuração personalizadas do Spark.

  1. Na página de configuração do compute, clique na alternância Opções Avançadas.

  2. Clique na tab Spark.

    Configuração do Spark

    Na configuração do Spark, insira as propriedades de configuração como um par key-value por linha.

Quando você configurar a computação usando a API de clusters, defina as propriedades do Spark no campo spark_conf na API de criação de clusters ou na API de atualização de clusters.

Para impor configurações do Spark no compute, os administradores do workspace podem usar políticas de compute.

Recuperar uma propriedade de configuração do Spark de um segredo

Databricks recomenda armazenar informações confidenciais, como senhas, em segredo, em vez de texto simples. Para fazer referência a um segredo na configuração do Spark, use a seguinte sintaxe:

spark.<property-name> {{secrets/<scope-name>/<secret-name>}}

Por exemplo, para definir uma propriedade de configuração do Spark chamada password para o valor do segredo armazenado em secrets/acme_app/password:

spark.password {{secrets/acme-app/password}}

Para obter mais informações, consulte gerenciar segredos.

Variáveis de ambiente

Configure variáveis de ambiente personalizadas que você pode acessar de init script em execução no recurso de compute. O Databricks também fornece variáveis de ambiente predefinidas que você pode usar em init script. Você não pode substituir essas variáveis de ambiente predefinidas.

  1. Na página de configuração do compute, clique na alternância Opções Avançadas.

  2. Clique na tab Spark.

  3. Defina as variáveis de ambiente no campo Variáveis de ambiente.

    Campo Variáveis de ambiente

    Observação

    ENV é uma palavra reservada e não pode ser usada como nome de uma variável de ambiente.

O senhor também pode definir variáveis de ambiente usando o campo spark_env_vars na API de criação de clusters ou na API de atualização de clusters.

Entrega de logs do compute

Ao criar um compute, você pode especificar um local para entregar os logs do nó driver do Spark, dos nós worker e dos eventos. Os logs são entregues a cada cinco minutos e arquivados de hora em hora no destino escolhido. Quando um recurso de compute é encerrado, o Databricks garante a entrega de todos os logs gerados até o momento em que o recurso foi encerrado.

O destino dos registros depende do cluster_id do recurso de compute. Se o destino especificado for dbfs:/cluster-log-delivery, os logs de compute para 0630-191345-leap375 são entregues para dbfs:/cluster-log-delivery/0630-191345-leap375.

Para configurar o local de entrega de log:

  1. Na página do compute, clique na alternância Opções Avançadas.

  2. Clique na tab Logging.

  3. Selecione um tipo de destino.

  4. Insira o caminho do log do compute.

    O caminho do log deve ser um caminho DBFS que começa com dbfs:/.

Observação

Esse recurso também está disponível na API REST. Consulte a API de clusters.