Partilhar via

Práticas recomendadas para computação sem servidor

Siga estas recomendações para maximizar a produtividade, reduzir custos e melhorar a fiabilidade ao utilizar computação serverless para portáteis, trabalhos e pipelines no Azure Databricks.

Migrando cargas de trabalho para computação sem servidor

Para garantir o isolamento do código do usuário no ambiente de computação compartilhado sem servidor, o Azure Databricks utiliza o Lakeguard para isolar o código do usuário do mecanismo Spark e de outros usuários.

Por isso, algumas cargas de trabalho exigem alterações de código para continuar trabalhando na computação sem servidor. Para obter uma lista de limitações, consulte Limitações de computação sem servidor.

Certas cargas de trabalho são mais fáceis de migrar do que outras. As cargas de trabalho que atendem aos seguintes requisitos serão as mais fáceis de migrar:

  • Os dados que estão sendo acessados devem ser armazenados no Catálogo Unity.
  • A carga de trabalho deve ser compatível com a computação padrão.
  • A carga de trabalho deve ser compatível com o Databricks Runtime 14.3 ou superior.

Para testar se uma carga de trabalho funcionará em computação sem servidor, execute-a em um recurso de computação clássico com modo de acesso padrão e um Databricks Runtime de 14.3 ou superior. Se a execução for bem-sucedida, a carga de trabalho estará pronta para a migração.

O Azure Databricks recomenda priorizar a compatibilidade de computação serverless ao criar novas cargas de trabalho. Para cargas de trabalho existentes que exigem alterações de código, migre-as incrementalmente como parte do seu ciclo regular de desenvolvimento e manutenção.

Especificar versões do pacote Python

Ao migrar para computação sem servidor, fixe seus pacotes Python em versões específicas para garantir ambientes reproduzíveis. Se você não especificar uma versão, o pacote poderá ser resolvido para uma versão diferente com base na versão do ambiente sem servidor, o que pode aumentar a latência à medida que novos pacotes precisam ser instalados.

Por exemplo, seu requirements.txt arquivo deve incluir versões específicas do pacote, como esta:

numpy==2.2.2
pandas==2.2.3

Use nomes únicos para vistas temporárias

A computação serverless utiliza o Spark Connect, uma arquitetura cliente-servidor que avalia vistas temporárias de forma preguiçosa. Este comportamento difere da arquitetura clássica do Spark e pode causar erros quando o código reutiliza o mesmo nome temporário de visualização, como num ciclo.

Para evitar erros, use nomes únicos para todas as visualizações temporárias no seu código.

Rede e conectividade

A computação serverless não suporta peering VPC, que é uma forma comum de ligar a computação clássica do Databricks a fontes de dados na sua conta na nuvem. Como alternativa, utilize configurações de conectividade de rede para gerir endpoints, firewalls e conectividade a serviços externos.

Por exemplo, pode adicionar um conjunto de IPs de saída estáveis em VPCs externas a uma lista de permissões para permitir a conectividade de e para a computação serverless do Azure Databricks. Para se ligar a aplicações empresariais (como o Salesforce) ou bases de dados geridas (como o MySQL), utilize o Lakeflow Connect.

Para restringir e monitorizar o tráfego de saída da computação serverless, configure os controlos de saída para o seu espaço de trabalho. Consulte Gerenciar políticas de rede para controle de saída sem servidor.

Versões de ambiente sem servidor

A computação serverless utiliza versões do ambiente em vez das versões tradicionais do Databricks Runtime. Isto representa uma mudança na forma como gere a compatibilidade da carga de trabalho:

  • Abordagem em tempo de execução do Databricks: Seleciona uma versão específica do Databricks para a sua carga de trabalho e gere as atualizações manualmente para manter a compatibilidade.
  • Abordagem serverless: escreve-se código contra uma versão do ambiente, e o Azure Databricks atualiza independentemente o servidor subjacente.

As versões do ambiente fornecem uma API cliente estável que garante que a sua carga de trabalho se mantém compatível, enquanto o Azure Databricks oferece de forma independente melhorias de desempenho, reforços de segurança e correções de bugs, sem exigir alterações de código às suas cargas de trabalho.

Cada versão do ambiente inclui bibliotecas de sistema atualizadas, funcionalidades e correções de bugs, mantendo a compatibilidade retroativa para cargas de trabalho. O Azure Databricks suporta cada versão do ambiente durante três anos a partir da sua data de lançamento, proporcionando um ciclo de vida previsível para planear atualizações.

Para selecionar um ambiente base para a sua carga de trabalho serverless, veja Selecionar um ambiente base. Para detalhes sobre as versões disponíveis do ambiente e as suas funcionalidades, veja Versões do ambiente serverless.

Gerenciar dependências

A computação serverless não suporta scripts de inicialização (init scripts). Em vez disso, use ambientes sem servidor para instalar e gerir bibliotecas para as suas cargas de trabalho sem servidor. Os ambientes armazenam em cache pacotes instalados, o que reduz a latência de arranque para execuções subsequentes.

Para usar bibliotecas de um repositório privado, configure URLs pré-assinados para acesso autenticado a repositórios nas definições do seu ambiente.

Escolha um modo de performance

A computação serverless do Azure Databricks oferece dois modos de desempenho que lhe permitem equilibrar velocidade e custo consoante o tipo de carga de trabalho, da seguinte forma:

  • Modo otimizado para desempenho (por defeito): Ideal para cargas de trabalho interativas que exigem tempos de arranque rápidos. O Azure Databricks mantém um conjunto de recursos de computação quentes pronto para minimizar o tempo de espera.
  • Modo padrão: Ideal para trabalhos automatizados em lote e pipelines que toleram tempos de arranque mais longos, de 4 a 6 minutos. O modo Standard pode reduzir custos até 70% comparado com o modo otimizado para desempenho. O modo Standard está disponível para Lakeflow Jobs e Lakeflow Spark Declarative Pipelines, mas não para notebooks.

Escolhe o modo que melhor se adequa às tuas necessidades de carga de trabalho. Para trabalhos agendados onde a latência de arranque não é crítica, o modo Standard normalmente oferece o melhor custo-benefício. Para detalhes atuais de preços, consulte a página de preços da Databricks.

Otimizar cargas de trabalho de streaming

A computação serverless suporta streaming estruturado com as seguintes considerações:

  • O modo de disparo Trigger.AvailableNow é suportado para todos os trabalhos e pipelines sem servidor. Intervalos de gatilho baseados em tempo não são suportados.

  • Ao usar Trigger.AvailableNow, cada trigger processa todos os dados disponíveis na fonte, o que pode resultar em micro-lotes maiores do que um trigger baseado no tempo. Para evitar erros de falta de memória e manter um desempenho previsível, limite a quantidade de dados processados por micro-lote definindo maxFilesPerTrigger ou maxBytesPerTrigger.

Depurar cargas de trabalho serverless

A interface do Spark não está disponível em computação serverless. Em vez disso, use o perfil de consulta para analisar o desempenho das consultas e resolver problemas das cargas de trabalho. O perfil de consulta fornece informações detalhadas de execução e é acessível a partir do histórico de consultas na interface do Azure Databricks.

Ingerir dados de sistemas externos

Estratégias alternativas que você pode usar para ingestão incluem:

  • Blocos de construção baseados em SQL, como tabelas de streaming COPY INTO e .

Alternativas de ingestão

Ao usar a computação sem servidor, você também pode usar os seguintes recursos para consultar seus dados sem movê-los.

  • Se você quiser limitar a duplicação de dados ou garantir que está consultando os dados mais recentes possíveis, o Databricks recomenda o uso do Delta Sharing. Consulte O que é Delta Sharing?.
  • Para trabalho de relatórios ad hoc e prova de conceito, a Lakehouse Federation permite-lhe consultar bases de dados externas diretamente a partir do Azure Databricks sem mover dados, governado pelo Unity Catalog. Consulte O que é Lakehouse Federation?.

Experimente um ou ambos os recursos e veja se eles atendem aos requisitos de desempenho da sua consulta.

Sumidouras sem suporte

Se um sistema sink não for suportado como destino direto de escrita a partir de computação serverless, pode usar o Catálogo Iceberg REST do Unity Catalog para permitir que esse sistema leia diretamente das tabelas Azure Databricks. Por exemplo, o Snowflake não é um sink sem servidor suportado, mas pode ser configurado como um cliente Iceberg para ler tabelas geridas pelo Unity Catalog.

Esta abordagem evita a duplicação de dados e mantém o Unity Catalog como camada de governação para todas as leituras. Para clientes suportados e passos de configuração, consulte as tabelas Access Azure Databricks dos clientes Apache Iceberg.

Configurações do Spark suportadas

Para automatizar a configuração do Spark na computação sem servidor, o Azure Databricks removeu o suporte para definir manualmente a maioria das configurações do Spark. Para exibir uma lista de parâmetros de configuração do Spark suportados, consulte Configurar propriedades do Spark para blocos de anotações e trabalhos sem servidor.

O trabalho executado em computação sem servidor falhará se você definir uma configuração do Spark sem suporte.

Monitore o custo da computação sem servidor

Há vários recursos que você pode usar para ajudá-lo a monitorar o custo da computação sem servidor:

  • Last updated on