Compartilhar via

Melhores práticas de otimização de custos

  • Artigo

Este artigo aborda as melhores práticas que dão suporte aos princípios de otimização de custos, organizadas por princípio.

1. Escolher recursos ideais

Usar formatos de dados otimizados para desempenho

Para aproveitar ao máximo a Plataforma de Inteligência de Dados do Databricks, você deve usar o Delta Lake como estrutura de armazenamento. Ele ajuda a criar pipelines de ETL mais simples e confiáveis e vem com muitos aprimoramentos de desempenho que podem acelerar significativamente as cargas de trabalho em comparação com o uso de Parquet, ORC e JSON. Confira Recomendações de otimização no Azure Databricks. Se a carga de trabalho também estiver em execução em uma computação de trabalho, isso se traduzirá diretamente em um tempo de atividade mais curto dos recursos de computação, levando a custos mais baixos.

Usar computação de trabalho

Um trabalho é uma maneira de executar código não interativo em uma instância de computação do Databricks. Por exemplo, você pode executar uma carga de trabalho de ETL (extração, transformação e carregamento) interativamente ou com agendamento. Obviamente, você também pode executar trabalhos de maneira interativa na interface do usuário do notebook. No entanto, na computação de trabalho, as cargas de trabalho não interativas custarão consideravelmente menos do que em computação para todas as finalidades. Confira a visão geral de preços para comparar a Computação de Trabalhos com a Computação para Todas as Finalidades.

Um benefício adicional para alguns trabalhos é que cada trabalho ou fluxo de trabalho pode ser executado em uma nova instância de computação, isolando cargas de trabalho umas das outras. No entanto, fluxos de trabalho multitarefa também podem reutilizar recursos de computação para todas as tarefas, de modo que o tempo de inicialização da computação ocorra apenas uma vez por fluxo de trabalho. Confira Configurar computação para trabalhos.

Usar um SQL warehouse para cargas de trabalho do SQL

Para cargas de trabalho do SQL interativas, um SQL warehouse do Databricks é o mecanismo mais econômico. Confira a visão geral de preços. Todos os warehouses de SQL vêm com o Photon por padrão, o que acelera suas chamadas de API SQL e DataFrame existentes e reduz o custo geral por carga de trabalho.

Além disso, os warehouses de SQL sem servidor são compatíveis com IWM (gerenciamento inteligente de carga de trabalho), um conjunto de recursos que aprimora a capacidade do Databricks SQL sem servidor para processar um grande número de consultas de forma rápida e econômica.

Usar runtimes atualizados para suas cargas de trabalho

A plataforma Azure Databricks fornece diferentes runtimes otimizados para tarefas de engenharia de dados (Databricks Runtime) ou tarefas de machine learning (Databricks Runtime para Machine Learning). Os runtimes são criados para fornecer a melhor seleção de bibliotecas para as tarefas e garantir que todas as bibliotecas fornecidas estejam atualizadas e trabalhem juntas de maneira ideal. Os Runtimes do Databricks são lançados em uma cadência regular, fornecendo melhorias de desempenho entre as principais versões. Essas melhorias de desempenho geralmente resultam em economia devido ao uso mais eficiente de recursos de computação.

Usar apenas GPUs para as cargas de trabalho corretas

Máquinas virtuais com GPUs podem acelerar muito os cálculos para aprendizado profundo, mas são significativamente mais caras do que as máquinas somente de CPU. Use as instâncias de GPU somente para cargas de trabalho que têm bibliotecas aceleradas por GPU.

A maioria das cargas de trabalho não usa bibliotecas aceleradas por GPU, portanto não se beneficia das instâncias habilitadas para GPU. Os administradores do workspace podem restringir computadores com GPU e recursos de computação para evitar o uso desnecessário. Confira a postagem no blog “Are GPUs Really Expensive? Benchmarking GPUs for Inference on Databricks Clusters” (As GPUs são realmente caras? Parâmetro de comparação de GPUs quanto à inferência em clusters do Databricks).

Usar serviços sem servidor para suas cargas de trabalho

Casos de uso de BI

Normalmente, as cargas de trabalho de BI consomem dados de maneira intermitente e geram várias consultas simultâneas. Por exemplo, alguém que usa uma ferramenta de BI pode atualizar um dashboard ou escrever uma consulta e, em seguida, simplesmente analisar os resultados sem interação adicional com a plataforma. Nesse cenário, a plataforma de dados:

  • Encerra recursos de computação ociosos para economizar nos custos.
  • Fornece rapidamente os recursos de computação quando o usuário solicita dados novos ou atualizados com a ferramenta de BI.

Os SQL warehouses que não usam o modelo sem servidor do Azure Databricks têm um tempo de inicialização de alguns minutos. Ou seja, muitos usuários tendem a aceitar o custo mais alto e não encerram os warehouses durante períodos ociosos. Por outro lado, os warehouses de SQL sem servidor são iniciados e escalam verticalmente em segundos, de modo que a disponibilidade imediata e o encerramento por ociosidade possam ser alcançados. Isso resulta em uma ótima experiência do usuário e em uma economia geral nos custos.

Além disso, os warehouses de SQL sem servidor reduzem verticalmente mais cedo do que os warehouses que não usam o modelo sem servidor, resultando em custos mais baixos.

Entrega de modelo de ML e IA

A maioria dos modelos são entregues como uma API REST para integração ao seu aplicativo Web ou cliente; o serviço de entrega do modelo recebe cargas variadas de solicitações ao longo do tempo e uma plataforma de serviço de modelo sempre deve fornecer recursos suficientes, mas apenas aqueles forem realmente necessários (upscaling e downscaling).

O Serviço de Modelo do Mosaic AI usa a computação sem servidor e fornece um serviço altamente disponível e de baixa latência para a implementação de modelos. O serviço aumenta ou reduz verticalmente automaticamente para atender mudanças na demanda, reduzindo custos de infraestrutura e otimizando o desempenho de latência.

Usar o tipo de instância ideal

O uso da última geração de tipos de instância de nuvem quase sempre oferece benefícios de desempenho, pois elas oferecem o melhor desempenho e os recursos mais recentes.

Com base em suas cargas de trabalho, também é importante escolher a família de instância certa para obter a melhor taxa de desempenho/preço. Algumas regras simples são:

  • Memória otimizada para ML, cargas de trabalho com muita mistura e despejo
  • Computação otimizada para cargas de trabalho de streaming estruturadas e trabalhos de manutenção (como Optimize e Vacuum)
  • Armazenamento otimizado para cargas de trabalho que se beneficiam do cache, como análise de dados ad hoc e interativa
  • GPU otimizada para cargas de trabalho de ML e DL específicas
  • Uso geral na ausência de requisitos específicos

Escolher o tamanho de computação mais eficiente

O Azure Databricks executa um executor por nó de trabalho. Portanto, os termos executor e trabalho são usados de forma intercambiável no contexto da arquitetura do Azure Databricks. As pessoas geralmente pensam no tamanho do cluster em termos do número de trabalhos, mas há outros fatores importantes a considerar:

  • Total de núcleos de executor (computação): o número total de núcleos em todos os executores. Isso determina o paralelismo máximo de uma instância de 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 despejados no disco.
  • Armazenamento local do executor: o tipo e a quantidade de armazenamento em disco local. O disco local usado principalmente no caso de despejos durante embaralhamentos e cache.

Entre as considerações adicionais estão o tipo e o tamanho da instância de trabalho, que também influenciam os fatores descritos anteriormente. Ao redimensionar a computação, considere o seguinte:

  • Quantos dados sua carga de trabalho consumirá?
  • Qual é a complexidade computacional de sua carga de trabalho?
  • De onde você está lendo dados?
  • Como os dados são particionados no armazenamento externo?
  • De quanto paralelismo você precisa?

Encontre detalhes e exemplos em Considerações sobre dimensionamento de computação.

Avaliar mecanismos de consulta com otimização de desempenho

O Photon é um mecanismo de consulta vetorizado nativo do Databricks de alto desempenho que acelera suas cargas de trabalho SQL e chamadas à API do DataFrame (para ingestão de dados, ETL, streaming, ciência de dados e consultas interativas). O Photon é compatível com as APIs do Apache Spark, ou seja, começar a usá-lo é tão fácil quanto ativá-lo – sem alterações de código e sem bloqueio.

A aceleração observada pode resultar em uma economia significativa nos custos, e os trabalhos executados regularmente devem ser avaliados quanto a estarem mais rápidos, além de mais baratos com o Photon.

2. Alocar recursos de maneira dinâmica

Usar computação de dimensionamento automático

Com o dimensionamento automático, o Databricks realoca dinamicamente trabalhos para atender às características do seu trabalho. Determinadas partes do pipeline podem ser mais exigentes computacionalmente do que outras, e o Databricks adiciona automaticamente outros trabalhos durante essas fases do seu trabalho (e as remove quando não são mais necessárias). O dimensionamento automático pode reduzir os custos gerais em comparação com uma instância de computação de tamanho estática.

O dimensionamento automático de computação tem limitações ao reduzir o tamanho do cluster para cargas de trabalho de streaming estruturado. O Databricks recomenda o uso do Delta Live Tables com dimensionamento automático aprimorado para cargas de trabalho de streaming.

Usar o encerramento automático

O Azure Databricks fornece uma série de recursos para ajudar a controlar os custos, reduzindo recursos ociosos e controlando os períodos em que os recursos de computação podem ser implantados.

  • Configure o encerramento automático para todos os recursos de computação interativos. Depois de um tempo ocioso especificado, o recurso de computação é desligado. Confira Encerramento automático.
  • Para casos de uso em que a computação é necessária somente durante o horário comercial, os recursos de computação podem ser configurados com o encerramento automático e um processo agendado pode reiniciar a computação (e possivelmente pré-ativar dados, se necessário) pela manhã, antes que os usuários estejam de volta em suas áreas de trabalho. Veja CACHE SELECT.
  • Se os tempos de inicialização de computação forem muito longos, considere o uso de pools de clusters; consulte Práticas recomendadas de pool. Os pools do Azure Databricks são um conjunto de instâncias ociosas e prontas para uso. Quando os nós de cluster são criados usando as instâncias ociosas, os tempos de início e dimensionamento automático do cluster são reduzidos. Se os pools não tiverem instâncias ociosas, eles se expandirão alocando uma nova instância do provedor de instância para atender à solicitação do cluster.

O Azure Databricks não cobra as DBUs (Unidades de Databricks) enquanto as instâncias estão ociosas no pool, resultando em economia nos custos. A cobrança do provedor de instâncias se aplica.

Usar políticas de computação para controlar custos

As políticas de computação podem impor muitas restrições específicas de custo para recursos de computação. Confira Excelência operacional – usar políticas de computação. Por exemplo:

3. Monitorar e controlar os custos

Monitorar custos

Use o Gerenciador de Custos do Azure para analisar os custos do Azure Databricks. As marcas Computação e Workspace também são entregues ao Gerenciador de Custos do Azure. Confira Marcar clusters para atribuição de custos.

Marcar clusters para atribuição de custos

Para monitorar os custos em geral e atribuir com precisão o uso do Azure Databricks às unidades de negócios e às equipes da sua organização para fins de estorno, você pode marcar clusters, warehouses de SQL e pools. Essas marcas se propagam para DBUs (Unidades do Databricks) detalhadas e uso de VM e armazenamento de blobs do provedor de nuvem para análise de custos.

O controle e a atribuição de custos já devem estar considerados ao configurar workspaces e clusters para equipes e casos de uso. Isso simplifica a marcação e aprimora a precisão das atribuições de custos.

Os custos totais incluem a máquina virtual de DBU, o disco e os custos de rede associados. Para warehouses de SQL sem servidor, o custo da DBU já inclui os custos de máquina virtual e disco.

As marcas de recursos do Azure Databricks podem ser usadas nas ferramentas de análise de custos no portal do Azure

Implementar a observabilidade para controlar e estornar custos

Ao trabalhar com ecossistemas técnicos complexos, entender proativamente as incógnitas é fundamental para manter a estabilidade da plataforma e controlar os custos. A observabilidade fornece um meio de analisar e otimizar sistemas com base nos dados que eles geram. Isso é diferente do monitoramento, que se concentra na identificação de novos padrões em vez de acompanhar problemas conhecidos.

O Databricks fornece ótimos recursos de observabilidade usando Tabelas do sistema que são armazenamentos analíticos hospedados pelo Databricks dos dados operacionais de uma conta de cliente encontrados no catálogo do sistema. Elas fornecem observabilidade histórica em toda a conta e incluem informações tabulares fáceis de usar sobre a telemetria da plataforma.

Consulte o Blog: balancear de maneira inteligente a otimização de custos e a confiabilidade no Databricks

Compartilhar relatórios de custos regularmente

Gere relatórios de custos mensais para acompanhar o aumento e as anomalias do consumo. Compartilhe esses relatórios por caso de uso ou equipe com as equipes que têm as cargas de trabalho usando a marcação de cluster. Isso elimina surpresas e permite que as equipes ajustem proativamente suas cargas de trabalho se os custos se tornarem muito altos.

Monitorar e gerenciar custos de saída do Delta Sharing

Diferentemente de outras plataformas de compartilhamento de dados, o Compartilhamento Delta não requer replicação de dados. Esse modelo tem muitas vantagens, mas significa que seu fornecedor de nuvem pode cobrar valores de saída de dados quando você compartilhar dados entre nuvens ou regiões. Consulte Monitorar e gerenciar custos de saída do Delta Sharing (para provedores) para monitorar e gerenciar encargos de saída.

4. Projetar cargas de trabalho econômicas

Balancear o streaming sempre ativado e disparado

Tradicionalmente, quando as pessoas pensam em streaming, termos como “tempo real”, “24 horas por dia, 7 dias por semana” ou “sempre ativado” vêm à mente. Se a ingestão de dados ocorrer em tempo real, os recursos de computação subjacentes deverão ser executados 24 horas por dia, 7 dias por semana, incorrendo em custos a cada hora do dia.

No entanto, nem todos os casos de uso que dependem de um fluxo contínuo de eventos exigem que esses eventos sejam adicionados imediatamente ao conjunto de dados de análise. Se o requisito empresarial para o caso de uso exigir apenas dados novos a certo intervalo de horas ou todos os dias, esse requisito poderá ser atendido com apenas algumas execuções por dia, resultando em uma redução significativa no custo da carga de trabalho. O Databricks recomenda usar o Streaming Estruturado com o gatilho AvailableNow para cargas de trabalho incrementais que não tenham requisitos de baixa latência. Confira Configuração do processamento em lote incremental.

Equilibrar o uso de instâncias sob demanda e de excesso de capacidade

As instâncias spot utilizam o excesso de recursos da máquina virtual na nuvem que estão disponíveis a um preço mais baixo. Para economizar nos custos, o Azure Databricks dá suporte à criação de clusters que usam instâncias spot. O Databricks recomenda que a primeira instância (o driver do Spark) sempre seja uma máquina virtual sob demanda. As instâncias spot são uma ótima opção para cargas de trabalho e, que um tempo maior é aceitável devido a uma ou mais instâncias spot terem sido removidas pelo provedor de nuvem.