O Que Fazer Quando a Capacidade do Azure Databricks Bate no Teto: Engajar, Mitigar, Planejar
TL;DR: Restrições de capacidade no Azure Databricks não são falhas do produto, mas sim limitações de infraestrutura do Azure na região. O caminho mais rápido é engajar o time de contas da Microsoft com dados precisos. Mitigações imediatas incluem trocar de VM SKU, rodar fora do pico e otimizar workloads Spark. A longo prazo, serverless compute e estratégia multi-região são as recomendações mais sólidas para empresas brasileiras que dependem de analytics em nuvem.
Cloud Architects da Microsoft: Paul Singh (PaulSingh), Eduardo Dos Santos (eduardomdossantos), Chris Walk (cwalk), Peter Lo (PeterLo), Tim Orentlikher, Ajmal Hossain (ajmalhossain), Chris Haynes (Chris_Haynes) e Rafia Aqil (Rafia_Aqil).
Comece por aqui: Engaje a Microsoft
Restrições de capacidade no Azure Databricks não são um problema do produto Azure Databricks. O Azure Databricks não possui ou reserva computação; ele provisiona dinamicamente VMs do Azure quando clusters são criados ou escalados. Isso significa que a criação de clusters, o autoscaling ou a execução de jobs podem travar quando os VM SKUs subjacentes estão sob restrição no nível regional. O caminho mais rápido para a resolução é uma conversa estruturada com seu time de contas da Microsoft, que pode acionar o processo de intake de capacidade do Azure em seu nome.
Abra um Quota Support Ticket via Suporte Microsoft e leve as informações abaixo para seu time de contas, junto com o número do ticket. Cada campo mapeia diretamente o que as equipes de intake de capacidade solicitarão; campos ausentes atrasam a solicitação.
O que preparar antes de contatar seu time de contas
| Campo | O que o Capacity Intake precisa | Exemplo |
|---|---|---|
| Subscription IDs | As assinaturas exatas do Azure que hospedarão os workspaces e clusters | 7ebee83d-7923-426c-8449-59fd4dff25ab |
| Região(ões) | Região primária, mais alternativas aceitáveis | East US 2 |
| Família de VM / SKU | Série e versão específica solicitada | Eadsv5, ESv4, DSv4, DSv2 |
| Contagem de cores / novo limite | Total de vCPUs ou cores por SKU | 10.000 cores para Eadsv5 |
| Característica do workload | CPU-bound vs. memory/shuffle-heavy vs. IO-heavy; batch vs. streaming vs. SQL | "ETL com uso intenso de memória, com grandes joins e shuffles" |
| Escala e timing | Quando precisa, perfil de ramp, pico vs. estado estável | "Preciso até o fim do mês; ramp de 2.000 para 9.650 cores durante o Q3" |
| Contexto de negócio | Caso de uso do negócio | "Migração do AWS" |
O que "capacidade" realmente significa: um modelo mental em camadas
Antes de mergulhar em soluções, é importante entender o que está acontecendo nos bastidores. As restrições de capacidade podem ocorrer em três camadas distintas, e resolvê-las exige abordar cada uma.
Camada 1: Infraestrutura do Azure
Esta é a camada que a maioria dos times subestima. A capacidade aqui é governada por:
- Disponibilidade de VM SKU na região. As séries D e E, as duas famílias de workers mais comuns do Databricks, repetidamente atingiram restrições de capacidade em várias regiões do Azure, causando falhas na criação de clusters, stalls de autoscale e atrasos no provisionamento.
- Restrições de oferta regional, que são dinâmicas e compartilhadas entre todos os tenants do Azure.
- Quotas e limites de vCPU por assinatura, que são separados da oferta regional. Quota é o limite da sua assinatura para implantar recursos (como um limite de cartão de crédito); capacidade regional é a infraestrutura subjacente disponível. Ambos devem ser suficientes.
Camada 2: Plataforma Azure Databricks
O plano de controle do Azure Databricks tem seus próprios tetos publicados que sua arquitetura deve respeitar proativamente. Limites-chave da documentação oficial de limites de recursos do Azure Databricks:
| Recurso | Limite | Escopo |
|---|---|---|
| Jobs criados por hora | 10.000 | Workspace |
| Tasks rodando simultaneamente | 2.000 | Workspace (excluindo tasks pai Run Job e For Each) |
| Tasks pai rodando simultaneamente (Run Job / For Each) | 750 | Workspace |
| SQL warehouses | 1.000 | Workspace |
| Notebooks anexados ou contextos de execução | 145 | Cluster |
| Máquinas virtuais | 25.000 | Por assinatura por região |
Nota: Para limites marcados como não fixos na documentação oficial, você pode solicitar um aumento através do seu time de contas do Azure Databricks. Referência: https://learn.microsoft.com/en-us/azure/databricks/resources/limits
Camada 3: Workload (Execução Spark)
Mesmo quando as duas camadas inferiores cooperam, o modelo de execução do Spark pode produzir sintomas semelhantes a problemas de capacidade:
- Paralelismo e distribuição de tasks, que determinam quantos cores um job pode consumir de forma útil.
- Pressão de memória de joins, shuffles e chaves skew.
- Demanda de IO e comportamento de cache, incluindo a eficácia do Delta cache e o uso indevido do Spark cache.
Entender essas camadas é crítico. Retries às vezes funcionam porque a capacidade é dinâmica: à medida que outros workloads são concluídos, os nós são liberados de volta para o Azure e ficam brevemente disponíveis.
Como reconhecer quando você atingiu o limite de capacidade
Problemas de capacidade raramente se apresentam como um único erro claro. Em vez disso, aparecem como comportamentos inconsistentes:
- Clusters presos no estado Pending
- Autoscaling falha ou nunca atinge o tamanho desejado
- Jobs falham intermitentemente ao iniciar
- Tentativas de retry às vezes funcionam
Essas inconsistências ocorrem porque a capacidade é compartilhada entre todos os tenants do Azure e flutua ao longo do dia. Executar workloads fora do horário comercial de pico no fuso horário da região impactada é uma das mitigações de curto prazo mais eficazes.
Ações imediatas: como desbloquear seus workloads
Quando você está enfrentando restrições de capacidade ativamente, a velocidade importa. Entre em contato com seu time de contas da Microsoft e tente estas mitigações, ordenadas da mais rápida para a mais complexa.
- Retry e execução durante horários de baixa demanda
A disponibilidade de capacidade muda ao longo do dia à medida que workloads são concluídos e liberam VMs. Executar fora do horário comercial de pico para a região impactada melhora significativamente as taxas de sucesso.
- Troque o VM SKU ou a família de VM
Se um VM SKU específico está sob restrição, trocar para outro pode desbloquear o provisionamento imediatamente.
- Mova-se dentro da mesma família (por exemplo, DSv4 → DSv5)
- Ou troque de família completamente (por exemplo, série D → série F ou série L)
Esta é uma das abordagens mais eficazes, mas muitas vezes subutilizada.
Escolhendo a família de VM certa
A maioria dos ambientes Databricks usa como padrão as séries D (uso geral) e E (otimizada para memória). Estas também são as famílias de VM mais usadas e com maior restrição de capacidade. Considere alternativas com base no seu workload:
| Família de VM | Melhor para | Quando usar | Trade-off |
|---|---|---|---|
| Série D | Workloads gerais | Escolha padrão | Frequentemente sob restrição em regiões de alta demanda |
| Série E | Jobs Spark com uso intenso de memória | Joins, shuffles, analytics | Alta demanda; custo mais alto |
| Série F | Jobs com uso intenso de CPU | Parsing, transformações | Menos memória por core |
| Série L | Workloads com uso intenso de IO | Delta caching, grandes datasets | Custo mais alto; grande NVMe local |
Framework de decisão prático:
- Workloads com uso intenso de memória (joins, shuffles): Mude da série E para a série L. Memória similar por core, mais grande NVMe local para Delta caching.
- Workloads com uso intenso de CPU: Mude da série D para a série F. Maior desempenho de CPU a um custo menor.
- Workloads com uso intenso de IO ou sensíveis a cache: A série L pode melhorar significativamente o desempenho e reduzir a pressão de shuffle.
Projetar com uma única família de VM é um dos maiores riscos de produção em ambientes Azure Databricks.
- Implemente diversidade regional no seu workload Databricks
- Como as restrições de capacidade do Azure são específicas de região e SKU, é importante construir flexibilidade arquitetural em suas implantações Databricks.
- Para workloads críticos ou de grande escala, considere implantar múltiplos workspaces Databricks em diferentes regiões do Azure para reduzir a dependência da capacidade de uma única região.
- Esta abordagem permite:
- Maior resiliência a restrições regionais de capacidade
- Maior flexibilidade no posicionamento do workload
Importante: A implantação multi-região requer arquitetura deliberada, incluindo a implantação de workspaces separados e a replicação de dados e configurações entre regiões — não é automática.
Por que adicionar mais nós nem sempre é a resposta
Quando os jobs ficam lentos, o instinto é escalar o compute. Com Spark, mais nós nem sempre resolvem o problema.
Problemas comuns de workload que se disfarçam de problemas de capacidade:
- Data skew
- Operações excessivas de shuffle
- Particionamento ineficiente
- Uso excessivo de UDFs
Em workloads reais, as operações de shuffle podem crescer significativamente mais do que os dados de entrada, colocando pressão pesada tanto no compute quanto na memória, que mais nós não conseguem aliviar.
Estratégias de otimização mais inteligentes:
- Reduza o shuffle através de reparticionamento e otimização de queries
- Habilite o Photon para execução mais rápida
- Otimize tabelas Delta usando Z-ordering e compactação
- Use caching estrategicamente (não apenas o Spark cache: use o cache Delta/disk)
Essas otimizações podem reduzir sua dependência da escassa capacidade de VM completamente.
O que fazer quando sua capacidade for aprovada
Depois que o Azure aprovar sua solicitação de capacidade, retê-la requer passos ativos. Como a capacidade do Azure é dinâmica e compartilhada, a capacidade aprovada é mantida apenas enquanto o compute permanece ativamente implantado e em execução. Isso é especialmente importante em regiões altamente restritas. A Microsoft recomenda o seguinte:
Configure um Instance Pool
Para workloads que ainda não podem usar serverless compute, configure um Azure Databricks Instance Pool com um número mínimo de nós ociosos alinhados aos seus requisitos de produção.
Um instance pool pré-aloca e mantém um conjunto de instâncias de VM ociosas e prontas para uso. Quando um cluster é criado a partir do pool, ele utiliza esses nós "quentes", eliminando a necessidade de solicitar novas VMs do pool de capacidade regional do Azure entre execuções de jobs.
Comportamentos-chave:
- O pool mantém um número mínimo de nós continuamente, mantendo-os aquecidos e imediatamente disponíveis.
- Clusters anexados ao pool puxam de nós quentes, evitando a reaquisição do Azure entre execuções.
- Nenhum custo de DBU é aplicado enquanto os nós estão ociosos no pool.
- Os custos de infraestrutura de VM do Azure se aplicam para todas as instâncias ociosas mínimas. Dimensione o pool de forma conservadora, alinhado apenas à necessidade de produção, para equilibrar a retenção de capacidade com o custo contínuo.
Importante: Instance pools mantêm nós ociosos em regime de best-effort. Eventos periódicos da plataforma podem reciclar nós do pool, fazendo com que ele fique temporariamente abaixo do mínimo configurado enquanto o Azure realoca novos nós. Pools melhoram significativamente a disponibilidade e a latência de inicialização, mas não mudam o fato de que as VMs subjacentes ainda são solicitadas do Azure sob demanda. Eles não são uma reserva firme.
Referência: https://learn.microsoft.com/en-us/azure/databricks/compute/pools
Projetando para resiliência: melhores práticas de longo prazo
Para evitar problemas recorrentes de capacidade, sua arquitetura precisa evoluir além de mitigações reativas.
- Planeje a capacidade com antecedência
- Entenda as quotas e limites de VM antes de precisar deles, não depois que uma restrição ocorrer.
- Evite projetar com um único SKU. Construa flexibilidade nas configurações de cluster para que você possa trocar de famílias sem reengenharia de jobs.
- Padronize as configurações de compute
Ambientes consistentes e orientados por políticas facilitam a adaptação quando ocorrem restrições de capacidade. Use Databricks Cluster Policies para restringir a criação de clusters a famílias de VM aprovadas e disponíveis, evitando que times solicitem SKUs sob restrição inadvertidamente.
- Migre para serverless sempre que possível
Serverless compute abstrai o gerenciamento de capacidade do cliente. À medida que a plataforma Databricks expande o suporte a serverless, migrar workloads elegíveis é a estratégia de longo prazo mais durável. O Azure continua expandindo a capacidade de infraestrutura, mas não há prazos garantidos para alívio em regiões sob restrição.
Nota: Se seu workload suporta serverless compute, a Databricks recomenda o uso de serverless em vez de pools ou clusters clássicos com VM. Serverless remove a dependência de SKUs de VM específicos e capacidade regional: o escalonamento é gerenciado pela plataforma com disponibilidade significativamente melhorada. Referência: https://learn.microsoft.com/en-us/azure/databricks/serverless-compute. Para workloads elegíveis, incluindo Databricks Jobs (fluxos de trabalho automatizados), Databricks SQL Warehouses e Delta Live Tables, o serverless compute elimina completamente a dependência de VM SKU.
- Estratégia multi-região para workloads críticos
Para os workloads mais críticos, avalie uma implantação multi-região como parte do planejamento de continuidade de negócios. Este é um investimento arquitetural significativo, mas é a única abordagem que fornece verdadeira redundância regional. Coordene isso com seu time de contas da Microsoft.
Principais conclusões
- Problemas de capacidade são restrições de infraestrutura, não falhas do produto Databricks
- A seleção da família de VM é crítica: não confie apenas nas séries D e E
- A otimização do workload pode reduzir a dependência de recursos escassos antes de solicitar mais capacidade
- Serverless compute é a recomendação de longo prazo preferida da Microsoft para workloads elegíveis
- As reservas de capacidade sob demanda do Azure fornecem capacidade garantida para cenários de missão crítica, distintas de instance pools (best-effort) e Reserved Instances (apenas desconto de faturamento)
- Flexibilidade arquitetural — consciência multi-SKU e multi-região — é sua melhor defesa contra restrições futuras
Perguntas Frequentes
-
Por que as tentativas de retry às vezes funcionam?
- A capacidade nas regiões do Azure é compartilhada entre todos os tenants e flutua ao longo do dia conforme workloads são concluídos e liberam VMs. Um retry bem-sucedido ocorre quando a capacidade é temporariamente liberada. Tentar durante horários de baixa demanda (fora do pico comercial da região) aumenta significativamente a taxa de sucesso.
-
Por que instance pools não são uma reserva firme de capacidade?
- Instance pools mantêm nós ociosos em regime de best-effort. Eventos periódicos da plataforma podem reciclar nós do pool, fazendo com que ele fique temporariamente abaixo do mínimo configurado enquanto o Azure realoca novas VMs. Eles melhoram a latência de inicialização e a disponibilidade, mas não garantem capacidade no nível da infraestrutura do Azure.
-
Qual a diferença entre serverless e clusters clássicos para capacidade?
- Serverless compute remove o controle do cliente sobre SKUs de VM específicas. O Databricks gerencia a capacidade subjacente em um pool compartilhado. Mitigações como troca de SKU ou pools não se aplicam. Do lado do cliente, as alavancas se resumem a retry e agendamento fora do pico. A troca é que serverless é a opção mais simples e confiável quando o workload suporta.
-
Por que trocar de região é considerado um último recurso?
- Trocar de região exige a reimplantação do workspace do Azure Databricks e a migração de todos os artefatos dependentes: jobs, clusters, bibliotecas, configurações de rede (private endpoints, VNet injection), atribuições do Unity Catalog, identidades e dados de origem. A região de destino precisa ser validada para o mesmo SKU e configuração zonal. Por isso, deve ser coordenada com o time de contas da Microsoft e tentada apenas após esgotar as mitigações preferenciais.
-
O que o time de contas da Microsoft faz exatamente?
- Eles roteiam a solicitação para o processo de intake de capacidade do Azure, aconselham SKUs e regiões alternativas, expõem considerações zonais vs. regionais e fornecem visibilidade sobre restrições conhecidas. O trabalho do cliente é trazer um perfil de workload completo e preciso para que o time possa advogar efetivamente. Também é recomendado abrir um ticket de suporte do Azure para rastreamento.
Artigo originalmente publicado por Rafia_Aqil em Azure Updates - Latest from Azure Charts.
