Pular para o conteúdo principal

referência de configuração de computação

nota

A organização deste artigo pressupõe que o senhor esteja usando o formulário simples compute UI. Para obter uma visão geral das atualizações do formulário simples, consulte Use o formulário simples para gerenciar compute.

Este artigo explica as definições de configuração disponíveis ao criar um novo recurso multifuncional ou Job compute. A maioria dos usuários cria o recurso compute usando as políticas atribuídas, o que limita as definições configuráveis. Se você não vê uma configuração específica na sua interface do usuário, é porque a política que você selecionou não permite que você defina essa configuração.

Formulário simples compute

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.

Criar um novo recurso para todos os fins compute​

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 .

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

política de computação​

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.

Configurações de desempenho​

As seguintes configurações aparecem na seção de desempenho do formulário simples compute UI:

Databricks Runtime versões​

Databricks Runtime é o conjunto de componentes principais que são executados em seu site compute. Selecione o tempo de execução usando o menu suspenso Databricks Runtime Version . Para obter detalhes sobre versões específicas do site Databricks Runtime, consulte Databricks Runtime notas sobre versões e compatibilidade. 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.

Use a aceleração Photon​

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

Para ativar ou desativar a aceleração do Photon, marque a caixa de seleção Use Photon Acceleration (Usar aceleração do ). Para saber mais sobre o Photon, consulte O que é o Photon?

tipo de nó de trabalho​

Um recurso compute consiste em um nó driver e zero ou mais nós worker. O senhor pode escolher tipos de instância de provedor de nuvem separados para os nós driver e worker, embora em default o nó driver use o mesmo tipo de instância que o nó worker. A configuração do nó do driver está abaixo da seção Desempenho avançado .

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. Você também pode selecionar um pool para usar como nó de worker ou driver.

important

Não use um pool com instâncias de VM preemptivas como seu tipo de driver. Selecione um tipo de motorista sob demanda para evitar que seu motorista seja recuperado. Consulte Conectar ao pool.

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ó de trabalho​

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.

provisionamento padrão worker armazenamento de nós​

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.
  • Local SSD usado pelo Spark worker. Isso hospedou Spark serviço e logs. Cada SSD local tem 375 GB. Para configurar o número de SSD locais anexados, consulte Tipos de instância com SSDlocal.
  • SSD remotos quando o autoscale do armazenamento está habilitado. Começam em 150 GB na criação e no autoscale, conforme a necessidade.

Tipos de instância de GPU​

Para tarefas computacionalmente desafiadoras que exigem alto desempenho, como as associadas à aprendizagem profunda, o site Databricks suporta o recurso compute que é acelerado com unidades de processamento gráfico (GPUs). Para obter mais informações, consulte GPU-enabled compute.

Tipos de instância com SSD​

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ância que têm SSD local são criptografados com a criptografia do lado do servidor do default Google Cloud e usam automaticamente o cache de disco para melhorar o desempenho. Os tamanhos de cache em todos os tipos de instância são definidos automaticamente, portanto, você não precisa definir o uso do disco explicitamente.

Configure o site local SSD para o senhor. compute​

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.

Nó único compute​

A caixa de seleção Single node (Nó único ) permite que o senhor crie um único nó compute recurso.

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 de um único nó​

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ó.

Seleção de um ou vários nós​

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:

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

    Para contornar esse problema, desative o leitor Parquet nativo:

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

Habilitar a autoescala​

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 trabalhadores que seu recurso compute irá autoscale entre, use os campos Min e Max ao lado do tipo de trabalhador dropdown.

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 .

nota

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 da autoescala​

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.

nota

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

nota

O dimensionamento automático da computação tem limitações na redução do tamanho do clustering para cargas de trabalho de transmissão estruturada. Databricks recomenda o uso de DLT com autoescala aprimorada para cargas de trabalho de transmissão. Consulte Otimizar a utilização de clustering do pipeline DLT com autoescala aprimorada.

Como a autoescala 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 piscina​

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 do parado no pool. Se for maior, o tempo de compute startup será equivalente ao de compute que não usa um pool.

exemplo de autoescala​

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

Configurações avançadas de desempenho​

As seguintes configurações aparecem na seção Advanced desempenho no formulário simples compute UI.

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. Quando o senhor criar o site compute usando a interface do usuário, clique na caixa de seleção Use preemtible instances (Usar instâncias previsíveis ) em Advanced desempenho .
  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.
JSON
{
  "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.

Rescisão automática​

O senhor pode definir o encerramento automático para compute na seção Desempenho avançado . Durante a criação do site compute, especifique um período de inatividade em minutos após o qual o senhor deseja que o recurso compute seja encerrado.

Se a diferença entre a hora atual e a última execução do comando no recurso compute for maior do que o período de inatividade especificado, o Databricks encerrará automaticamente o compute. Recurso Para obter mais informações sobre o encerramento do site compute, consulte Terminate a compute.

Tipo de motorista​

O senhor pode selecionar o tipo de driver na seção Desempenho avançado . O nó do driver mantém as informações de estado de todos os notebooks anexados ao recurso compute. O nó driver também mantém o SparkContext, interpreta todos os comandos que o senhor executa a partir de um Notebook ou de uma biblioteca no recurso compute e executa o mestre Apache Spark que coordena o executor 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.

Etiquetas​

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.

O gráfico de Databricks uso faturável do no account console pode agregar o uso por tags individuais. Os downloads dos relatórios de uso faturável CSV da mesma página também incluem default e tags personalizadas. As tags também se propagam para o rótulo GKE e GCE.

Para obter informações detalhadas sobre como os tipos de tags pool e compute funcionam juntos, consulte Uso de atributos usando 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 .

Configurações avançadas​

As seguintes configurações aparecem na seção Advanced (Avançado ) do formulário simples compute UI:

Modos de acesso​

O modo de acesso é um recurso de segurança que determina quem pode usar o recurso compute e os dados que podem ser acessados usando o recurso compute. Cada recurso do site compute em Databricks tem um modo de acesso. As configurações do modo de acesso podem ser encontradas na seção Advanced (Avançado ) do formulário simples compute UI.

A seleção do modo de acesso é feita automaticamente pelo site default, o que significa que o modo de acesso é escolhido automaticamente para o senhor com base no site selecionado Databricks Runtime. Tempos de execução de aprendizado de máquina e Databricks Tempos de execução inferiores a 14.3 default para Dedicated ; caso contrário, será usado o Standard .

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

Modo de acesso

Visível para o usuário

Suporte UC

Idiomas suportados

Notas

Dedicado (anteriormente usuário único)

Sempre

Sim

Python, SQL, Scala, R

Pode ser atribuído e usado por um único usuário ou grupo.

Padrão (anteriormente compartilhado)

Sempre

Sim

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

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

Para obter informações detalhadas sobre o suporte de funcionalidade para cada um desses modos de acesso, consulte Limitações do modo de acesso de computação para Unity Catalog.

nota

Em Databricks Runtime 13.3 LTS e acima, o script de inicialização e a biblioteca são suportados por todos os modos de acesso. Os requisitos e os níveis de suporte variam. Consulte Onde o script de inicialização pode ser instalado? e biblioteca com escopo de computação.

Google serviço account​

Para associar esse recurso compute a um serviço do Google account usando o Google Identity, clique em Advanced (Avançado ), depois em Google serviço account e adicione o endereço do seu serviço do Google account email no campo Google serviço account . Esse valor é usado para autenticar com o GCS e BigQuery fonte de dados.

important

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 compute, em Advanced > Instances ( Avançado > Instâncias), selecione a zona de disponibilidade do recurso compute. Essa configuração permite que o senhor especifique qual zona de disponibilidade deseja que o recurso compute use. Em default, a configuração da zona de disponibilidade é definida como Auto . Com a configuração Automático , uma única zona de disponibilidade é selecionada 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.

Ativar o armazenamento local de escala automática​

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 a opção Enable autoscale local storage (Ativar armazenamento local de autoescala ), abra a seção Advanced (Avançado ) e clique em Instances (Instâncias ) tab.

Criptografia de disco local​

Os tipos de instância que têm SSD local são criptografados com a criptografia do lado do servidor do Google Cloud default. Consulte Tipos de instância com SSDlocal.

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 compute, clique no botão Advanced .

  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 o senhor configura compute usando o clustering API, define as propriedades de Spark no campo spark_conf em create clustering API ou Update clustering API.

Para impor as configurações de Spark em compute, os administradores de workspace podem usar as políticas decompute.

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

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

ini
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:

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

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

variável de ambiente​

Configure a variável de ambiente personalizada que o senhor pode acessar a partir do script de inicialização em execução no recurso compute. Databricks também fornece variáveis de ambiente predefinidas que o senhor pode usar no script de inicialização. O senhor não pode substituir essas variáveis de ambiente predefinidas.

  1. Na página de configuração compute, clique no botão Advanced .

  2. Clique na tab Spark .

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

    Campo Variáveis de ambiente

nota

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.

computar log delivery​

Quando o senhor cria um compute multifuncional ou de trabalho, pode especificar um local para fornecer o clustering logs para o nó driver Spark, nós worker e eventos. Os registros são entregues a cada cinco minutos e arquivados a cada hora no destino escolhido. Databricks entregará todos os logs gerados até que o recurso compute seja encerrado.

Para configurar o local de entrega de log:

  1. Na página compute, clique no botão Advanced (Avançado ).
  2. Clique na tab Logging .
  3. Selecione um tipo de destino.
  4. Digite o caminho do registro .

Para armazenar o logs, o Databricks cria uma subpasta no caminho escolhido do log com o nome cluster_id do compute.

Por exemplo, se o caminho de log especificado for /Volumes/catalog/schema/volume, os logs de 06308418893214 serão entregues em /Volumes/catalog/schema/volume/06308418893214.

nota

O fornecimento de logs para volumes está em Public Preview e só é suportado em compute habilitado para Unity-Catalog com modos de acesso Standard ou Dedicated . Se você selecionar um volume como caminho, certifique-se de ter as permissões READ VOLUME e WRITE VOLUME no volume. Consulte Quais são os privilégios dos volumes? .

nota

compute log delivery to volumes não é compatível com a arquitetura GKE em GCP. Atualize para a arquitetura GCE para usar esse recurso. Consulte Atualizar permissões para a implementação do GCE compute.

nota

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

Última atualização em