Práticas recomendadas de configuração de compute clássica
Esta página descreve as melhores práticas para configurar recursos de compute clássicos. Para a maioria das novas cargas de trabalho, a Databricks recomenda o uso de serverless compute, que não requer configuração. Se a sua carga de trabalho não for suportada no compute serverless (consulte Limitações do Serverless), use as seguintes melhores práticas para configurar um recurso de compute clássico.
Os fluxos de trabalho da transmissão estructurada têm recomendações de configuração específicas. Consulte Considerações de produção para transmissão estructurada.
Modo de acesso
Recursos de compute clássicos podem ser atribuídos a um modo de acesso padrão ou dedicado, que determina quem pode se anexar ao recurso de compute e usá-lo.
A Databricks recomenda o uso do modo de acesso padrão para a maioria das cargas de trabalho. O compute padrão pode ser compartilhado por vários usuários e grupos, garantindo o isolamento do usuário e todas as permissões de acesso a dados. Isso a torna uma opção de mais fácil gerenciamento e econômica para a maioria das cargas de trabalho.
Use o modo de acesso dedicado apenas se sua carga de trabalho tiver limitações de compute padrão específicas, como ML Runtime na GPU, APIs RDD ou R. Para obter mais informações, consulte Requisitos e limitações do compute padrão.
Se o Unity Catalog estiver habilitado, não defina spark.databricks.passthrough.enabled. A passagem de credenciais é um modo de acesso legado que não é compatível com o Unity Catalog.
Consulte Modos de acesso.
Versão do Databricks Runtime
Use a versão mais recente do Databricks Runtime com suporte de longo prazo (LTS). Versões LTS recebem patches de segurança estendidos e correções de erros, garantindo que as cargas de trabalho permaneçam estáveis e compatíveis com os recursos mais recentes da plataforma.
Selecione um runtime de machine learning apenas se sua carga de trabalho usar GPUs, treinamento distribuído de ML ou AutoML. O Databricks Runtime para ML instala um grande conjunto de bibliotecas que pode entrar em conflito com as suas próprias dependências se não forem necessárias, causando erros ou problemas de correção silenciosos. Consulte Treinar modelos de AI e ML.
Higiene da configuração
Essas práticas mantêm suas configurações de compute limpas e suas cargas de trabalho portáteis.
Evite usar init scripts
Init scripts podem introduzir comportamentos inesperados, incluindo conflitos de biblioteca que interrompem cargas de trabalho e tornam os ambientes menos previsíveis. Em vez disso, adicione bibliotecas às suas políticas de compute, use %pip install em Notebooks ou defina dependências em uma especificação de ambiente. Consulte Adicionar bibliotecas a uma política.
Evitar a codificação fixa das configurações do Spark
Evite codificar as configurações do Spark (como spark.executor.memory ou spark.dynamicAllocation.*) em definições de compute ou job. Valores codificados substituem as otimizações integradas que a Databricks fornece, muitas vezes levando a gastos desnecessários ou desempenho degradado. Use configurações de sessão com escopo de Notebook somente quando houver um motivo específico para sobrescrever um default.
Evitar caminhos de armazenamento local do compute
Não armazene dados em caminhos locais de compute, que não persistem além do ciclo de vida do compute. Em vez disso, utilize volumes do Unity Catalog ou armazenamento temporário. Consulte O que são volumes?.
Evitar montagens DBFS
As montagens do DBFS não possuem listas de controle de acesso (ACLs) adequadas. Em vez disso, use volumes do Unity Catalog ou sistemas de arquivos do workspace (WSFS). Consulte O que são volumes?.
Evitar a instalação de bibliotecas com escopo de compute
A instalação de bibliotecas no nível do compute cria desvio de ambiente nas execuções de jobs. Em vez disso, use %pip install em notebooks ou defina dependências em uma especificação de ambiente. Isso também torna as cargas de trabalho clássicas mais fáceis de migrar para serverless.
desempenho
Avalie se o senhor se beneficiaria com o Photon
Muitas cargas de trabalho se beneficiam do Photon, mas ele é mais benéfico para cargas de trabalho SQL e operações DataFrame que envolvem transformações complexas, como junções, agregações e varreduras de dados em tabelas grandes. As cargas de trabalho com acesso frequente ao disco, tabelas amplas ou processamento repetido de dados também apresentam melhor desempenho.
Lotes simples ETL Os trabalhos que não envolvem grandes transformações ou grandes volumes de dados podem sofrer um impacto mínimo com a ativação do Photon, especialmente se as consultas forem concluídas em menos de dois segundos.
Usar autoscale
Configure o autoscale para que tarefas de longa duração possam adicionar e remover dinamicamente nós worker durante as execuções de Job. Ver Ativar autoscale.
Use pools de instâncias para reduzir os tempos de início
Pools de instâncias reservam recursos de compute do seu provedor de cloud. Os pools diminuem o tempo de inicialização de novos clusters e garantem a disponibilidade de recursos de compute. Consulte Referência de configuração de pool.
Otimização de custos
Use as políticas do site compute
A Databricks recomenda usar políticas de compute. As políticas de compute permitem criar recursos de compute pré-configurados, projetados para fins específicos, como compute pessoal, compute compartilhado, usuários avançados e Jobs. As políticas limitam as decisões que precisam ser tomadas ao configurar as definições de compute.
Se o senhor não tiver acesso às políticas, entre em contato com o administrador do site workspace. Consulte políticas padrão e famílias de políticas.
Usar instâncias preemptivas
Configurar instâncias preemptivas para cargas de trabalho que têm requisitos de latência flexíveis para otimizar custos. Ver instâncias preemptivas.
Configurar zonas de disponibilidade
Especifique uma zona de disponibilidade (AZ) caso sua organização tenha adquirido instâncias reservadas. Ver Zonas de disponibilidade.
computar considerações sobre o dimensionamento
As recomendações a seguir pressupõem que o senhor tenha criação de cluster sem restrições. Os administradores do workspace só devem conceder esse privilégio a usuários avançados.
As pessoas geralmente pensam no tamanho do compute em termos do número de workers, mas há outros fatores importantes a considerar:
- Núcleos totais do executor (computação): o número total de núcleos em todos os executores. Isso determina o paralelismo máximo de uma computação.
- Memória total do executor: a quantidade total de RAM em todos os executores. Isso determina quantos dados podem ser armazenados na memória antes de serem vazados para o disco.
- Armazenamento local do executor: o tipo e a quantidade de armazenamento em disco local. O disco local é usado principalmente no caso de vazamentos durante embaralhamentos e armazenamento em cache.
Considerações adicionais incluem tipo e tamanho da instância do worker, que também influenciam os fatores acima. Ao dimensionar sua computação, considere:
- Quantos dados sua carga de trabalho consumirá?
- Qual é a complexidade computacional da sua carga de trabalho?
- De onde você está lendo os dados?
- Como os dados são particionados no armazenamento externo?
- De quanto paralelismo você precisa?
Há um ato de equilíbrio entre o número de workers e o tamanho dos tipos de instância de worker. Configurar a compute com dois workers, cada um com 16 núcleos e 128 GB de RAM, tem a mesma compute e memória que configurar a compute com oito workers, cada um com 4 núcleos e 32 GB de RAM.
exemplos de configuração de computação
Os exemplos a seguir mostram recomendações de computação com base em tipos específicos de cargas de trabalho. Esses exemplos também incluem configurações a serem evitadas e por que essas configurações não são adequadas para os tipos de carga de trabalho.
Todos os exemplos nesta seção poderiam se beneficiar do uso de compute serverless em vez de iniciar um novo recurso de compute. Se sua carga de trabalho não for compatível com serverless, use as recomendações abaixo para ajudar a configurar seu recurso de compute clássico.
Análise de dados
O analista de dados normalmente realiza o processamento que requer dados de várias partições, o que leva a muitas operações de embaralhamento. Um recurso compute com um número menor de nós maiores pode reduzir a E/S da rede e do disco necessária para realizar esses embaralhamentos.
Um nó único compute com um tipo de VM grande é provavelmente a melhor opção, especialmente para um único analista.
As cargas de trabalho analíticas provavelmente exigirão a leitura repetida dos mesmos dados, portanto, os tipos de nós recomendados são armazenamento otimizado com cache de disco ativado ou instâncias com armazenamento local.
Recursos adicionais recomendados para cargas de trabalho analíticas incluem:
- Habilite o encerramento automático para garantir que a computação seja encerrada após um período de inatividade.
- Considere a possibilidade de ativar a autoescala com base na carga de trabalho típica do analista.
Lotes básicos ETL
Para lotes simples ETL Job que não exigem transformações amplas, como junções ou agregações, use instâncias com requisitos mais baixos de memória e armazenamento. Isso pode resultar em economia de custos em relação a outros tipos de worker.
Lotes do complexo ETL
Para um trabalho complexo no site ETL, como um que requer uniões e junções em várias tabelas, o site Databricks recomenda o uso de menos trabalhadores para reduzir a quantidade de dados embaralhados. Para compensar o fato de ter menos trabalhadores, aumente o tamanho de suas instâncias.
Transformações complexas podem ser compute-intensive. Se você observar erros significativos de vazamento no disco ou de OOM, aumente a quantidade de memória disponível em suas instâncias.
Opcionalmente, use pools para diminuir o tempo de lançamento do compute e reduzir o tempo total de execução ao executar pipelines de jobs.
treinamento modelo do machine learning
Para treinar o modelo de aprendizado de máquina, o site Databricks recomenda a criação de um recurso compute usando a política Personal compute .
Use o compute de nó único com um tipo de nó grande para experimentação inicial. Ter menos nós reduz o impacto dos shuffles.
Adicionar mais workers pode ajudar na estabilidade, mas deve-se evitar adicionar muitos workers devido ao overhead de shuffles de dados.
Os tipos recomendados de worker são armazenamento otimizado com cache de disco ativado ou uma instância com armazenamento local para account para leituras repetidas dos mesmos dados e para ativar o cache de dados de treinamento.
Recursos adicionais recomendados para cargas de trabalho do machine learning incluem:
- Habilite o encerramento automático para garantir que a computação seja encerrada após um período de inatividade.
- Use pools, que permitem restringir o compute a um tipo de instância pré-aprovado.
- Garanta configurações consistentes do compute usando políticas.