Proteger capacidade computacional específica pode ser um desafio, especialmente durante períodos de alto tráfego (e alta pressão). Os engenheiros de dados e administradores de plataforma estão muito familiarizados com a frustração da capacidade insuficiente, ou erros de “esgotamento”, que ocorrem quando o lançamento de um cluster falha porque um provedor de nuvem não consegue atender a uma solicitação para um tipo de instância específico.
Seja:
AWS_INSUFFICIENT_INSTANCE_CAPACITY_FAILURECLOUD_PROVIDER_RESOURCE_STOCKOUTno Azure ouGCP_INSUFFICIENT_CAPACITY,
Esses erros interrompem cargas de trabalho críticas, especialmente durante períodos críticos para os negócios, quando o tempo de atividade é mais importante.
O que são tipos de nós flexíveis?
Tradicionalmente, os clusters Databricks exigiam que cada nó fosse o tipo exato de instância especificado na sua configuração. Se esse tipo específico não estivesse disponível, a inicialização do cluster falharia.
Os tipos de nós flexíveis removem essa restrição. Quando um tipo de instância preferencial não está disponível, o Databricks recorre automaticamente a uma alternativa compatível que partilha a mesma forma de computação. Em outras palavras, o cluster é iniciado com êxito usando uma combinação de tipos de instância semelhantes, em vez de falhar completamente.
Para equipes que precisam de controle mais rígido, elas também podem definir uma lista de substitutos personalizada por meio da API, incluindo quais tipos de instância tentar e em que ordem.
Principais benefícios
Menos lançamentos de cluster com falha durante picos de demanda
Os tipos de nós flexíveis reduzem a frequência e a gravidade das falhas relacionadas à capacidade. Quando um provedor de nuvem não consegue atender ao tipo de instância preferido, o Databricks recorre automaticamente a alternativas compatíveis, permitindo que os clusters sejam iniciados em vez de gerar erros.
Uso otimizado de instâncias spot
Para clusters configurados com Spot com fallback, os tipos de nós flexíveis tentam adquirir capacidade Spot em toda a lista de fallback antes de reverter para instâncias sob demanda. Isso aumenta a parte do cluster em execução no Spot, ajudando a reduzir os custos de computação e ao mesmo tempo priorizando lançamentos bem-sucedidos.
Visibilidade clara e controle preciso
As equipes podem inspecionar exatamente quais tipos de nós são adquiridos usando a tabela de sistema node_timeline. Além disso, um pedido de fallback personalizado pode ser definido por meio da API, permitindo controle preciso sobre o custo e o comportamento do desempenho.
Início rápido
Os administradores do espaço de trabalho podem ativar facilmente o recurso nas configurações de administrador (Documentos: AWS, Azul, GCP). A partir daí, o recurso se aplica imediatamente a todos os novos lançamentos de cluster. Os clusters de longa duração adotarão o recurso na próxima reinicialização, e os futuros clusters de trabalhos criados para trabalhos existentes utilizarão o recurso automaticamente.
Listas de fallback personalizadas podem ser configuradas por meio da API, independentemente da configuração do espaço de trabalho.
Detalhes adicionais
Consulte a documentação para obter mais detalhes sobre como configurar tipos de nós flexíveis com swimming pools de instâncias, cobrança, cotas de tipo de nó e ativação/desativação seletiva (Documentos: AWS, Azul, GCP).
Os tipos de nós flexíveis são projetados para tornar sua plataforma de dados mais resiliente e econômica. Os administradores podem ativar esse recurso com um clique hoje mesmo nas configurações de administração do espaço de trabalho seguindo as instruções na documentação.