Pular para o conteúdo principal

Práticas recomendadas para otimização de custos

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

1. Escolha o recurso ideal​

Usar formatos de dados com desempenho otimizado​

Para tirar o máximo proveito da Databricks Data Intelligence Platform, o senhor deve usar o Delta Lake como estrutura de armazenamento. Ele ajuda a criar um pipeline ETL mais simples e confiável 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. Consulte Recomendações de otimização em Databricks. Se a carga de trabalho também estiver sendo executada em um Job compute, isso se traduz diretamente em um tempo de atividade mais curto do compute recurso, o que leva a custos mais baixos.

Usar trabalho compute​

Um Job é uma forma de executar código não interativo em uma instância do Databricks compute . Por exemplo, o senhor pode executar uma carga de trabalho de extração, transformação e carregamento (ETL) interativamente ou em um programa. Obviamente, o senhor também pode executar o Job de forma interativa na interface do usuário do Notebook. No entanto, no Job compute, as cargas de trabalho não interativas custarão significativamente menos do que no compute. Veja a visão geral de preços para comparar a computação para trabalhos e a computação para todos os fins.

Um benefício adicional para alguns trabalhos é que cada trabalho ou fluxo de trabalho pode ser executado em uma nova instância do compute, isolando as cargas de trabalho umas das outras. No entanto, o fluxo de trabalho multitarefa também pode reutilizar o recurso compute para todas as tarefas, de modo que o tempo compute startup ocorre apenas uma vez por fluxo de trabalho. Consulte Configurar compute para o trabalho.

Use o site SQL warehouse para cargas de trabalho SQL​

Para cargas de trabalho SQL interativas, o Databricks SQL warehouse é o mecanismo mais econômico. Veja a visão geral de preços. Todos os depósitos SQL vêm com Photon por default, o que acelera suas chamadas existentes SQL e DataFrame API e reduz seu custo geral por carga de trabalho.

Além disso, o armazém serverless SQL suporta o gerenciamento inteligente de carga de trabalho (IWM), um conjunto de recursos que aprimora a capacidade do Databricks SQL serverless de processar um grande número de consultas de forma rápida e econômica.

Use tempos de execução atualizados para suas cargas de trabalho​

A plataforma Databricks oferece diferentes tempos de execução que são otimizados para a tarefa de engenharia de dados (Databricks Runtime) ou tarefa de aprendizado de máquina (Databricks Runtime for Machine Learning). Os tempos de execução são criados para fornecer a melhor seleção de bibliotecas para a tarefa e para garantir que todas as bibliotecas fornecidas estejam atualizadas e funcionem em conjunto de forma otimizada. Os tempos de execução do Databricks são lançados em uma cadência regular, proporcionando melhorias de desempenho entre as principais versões. Essas melhorias de desempenho geralmente resultam em economia de custos devido ao uso mais eficiente do compute recurso.

Use apenas GPUs para as cargas de trabalho certas​

As máquinas virtuais com GPUs podem acelerar drasticamente os cálculos para aprendizagem profunda, mas são significativamente mais caras do que as máquinas somente com CPU. Use instâncias de GPU somente para cargas de trabalho que tenham biblioteca acelerada por GPU.

A maioria das cargas de trabalho não usa biblioteca acelerada por GPU, portanto, não se beneficia de instâncias habilitadas para GPU. Os administradores do espaço de trabalho podem restringir as máquinas de GPU e compute recurso para evitar o uso desnecessário. Veja a postagem no blog "As GPUs são realmente caras? Benchmarking GPUs for Inference on Databricks clustering".

Use o serverless serviço para suas cargas de trabalho​

BI As cargas de trabalho normalmente consomem dados em rajadas e geram várias consultas simultâneas. Por exemplo, alguém que usa uma ferramenta de BI pode atualizar um painel ou escrever uma consulta e, em seguida, simplesmente analisar os resultados sem interagir mais com a plataforma. Nesse cenário, a plataforma de dados:

  • Termina parado compute recurso para economizar custos.
  • Fornece rapidamente o recurso compute quando o usuário solicita dados novos ou atualizados com a ferramenta BI.

Os armazéns nãoserverless Databricks SQL têm um tempo de startup de minutos, portanto, muitos usuários tendem a aceitar o custo mais alto e não os encerram durante os períodos de parada. Por outro lado, o armazémserverless SQL começa e escala em segundos, de modo que é possível obter disponibilidade instantânea e término parado. Isso resulta em uma ótima experiência do usuário e em uma economia geral de custos.

Além disso, o armazém serverless SQL escala para baixo mais cedo do que os armazéns que não sãoserverless, resultando novamente em custos mais baixos.

ML e AI servindo modelo

A maioria dos modelos é servida como um REST API para integração em seu aplicativo da Web ou cliente; o serviço de modelo de serviço recebe cargas variáveis de solicitações ao longo do tempo, e uma plataforma de modelo de serviço deve sempre fornecer recurso suficiente, mas apenas o quanto for realmente necessário (upscaling e downscaling).

Mosaic AI Model Serving utiliza o site serverless compute e oferece um serviço altamente disponível e de baixa latência para modelos implantados. O serviço aumenta ou diminui automaticamente para atender às mudanças na demanda, reduzindo os custos de infraestrutura e otimizando o desempenho da latência.

Use o tipo de instância correto​

Usar a última geração de tipos de instância de nuvem quase sempre proporciona benefícios de desempenho, pois eles oferecem o melhor desempenho e o recurso mais recente.

Com base em suas cargas de trabalho, também é importante escolher a família de instâncias correta para obter a melhor relação desempenho/preço. Algumas regras básicas simples são:

  • Memória otimizada para ML, cargas de trabalho pesadas de shuffle e spill
  • Computação otimizada para cargas de trabalho de transmissão estruturada e trabalhos de manutenção (como optimize e vacuum)
  • Armazenamento otimizado para cargas de trabalho que se beneficiam do armazenamento em cache, como análise de dados ad-hoc e interativa
  • GPU otimizada para cargas de trabalho específicas de ML e DL
  • Propósito geral na ausência de requisitos específicos

Escolha o tamanho mais eficiente do compute​

O Databricks executa um executor por nó worker. Portanto, os termos executor e worker são usados alternadamente no contexto da arquitetura do Databricks. As pessoas costumam pensar no tamanho do cluster em termos de número de workers, mas há outros fatores importantes a serem considerados:

  • Total de núcleos executor (compute): O número total de núcleos em todos os executores. Isso determina o paralelismo máximo de uma instância do site compute.
  • 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.

Outras considerações incluem o tipo e o tamanho da instância worker, que também influenciam os fatores anteriores. Ao dimensionar seu compute, considere o seguinte:

  • Quantos dados sua carga de trabalho consumirá?
  • Qual é a complexidade computacional de 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?

Detalhes e exemplos podem ser encontrados em considerações sobre o dimensionamento do cálculo.

Avaliar mecanismos de consulta com desempenho otimizado​

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

O aumento de velocidade observado pode levar a uma economia de custos significativa, e os trabalhos que são executados regularmente devem ser avaliados para ver se não são apenas mais rápidos, mas também mais baratos com o Photon.

2. Alocar dinamicamente o recurso​

Usar escalonamento automático compute​

Com o autoscale, o Databricks realoca dinamicamente o trabalhador para o account de acordo com as características do seu trabalho. Certas partes do seu pipeline podem ser mais intensivas em termos de computação do que outras, e o Databricks adiciona automaticamente um trabalhador adicional durante essas fases do seu trabalho (e os remove quando não são mais necessários). A autoescala pode reduzir os custos gerais em comparação com uma instância compute de tamanho estático.

O dimensionamento automático da computação tem limitações ao reduzir o tamanho do clustering para cargas de trabalho de transmissão estruturada. Databricks recomenda o uso de DLT com autoescala aprimorada para cargas de trabalho de transmissão.

Use a terminação automática​

Databricks fornece vários recursos para ajudar a controlar os custos, reduzindo o recurso parado e controlando quando o recurso compute pode ser implantado.

  • Configure a terminação automática para todos os compute recursos interativos. Após um tempo de parada especificado, o compute recurso é desligado. Consulte Rescisão automática.
  • Para casos de uso em que o compute é necessário somente durante o horário comercial, o recurso compute pode ser configurado com encerramento automático e um processo agendado pode reiniciar o compute (e possivelmente pré-aquecer os dados, se necessário) pela manhã, antes que os usuários voltem aos seus desktops. Consulte CACHE SELECT.
  • Se os tempos de compute startup forem muito longos, considere o uso de um pool de clustering; consulte as práticas recomendadas de pool. Databricks são um conjunto de instâncias paradas e prontas para uso. Quando os nós de clustering são criados usando as instâncias de parado, os tempos de início de clustering e de escalonamento automático são reduzidos. Se o pool não tiver instâncias parado, ele se expandirá alocando uma nova instância do provedor de instâncias para acomodar a solicitação do clustering.

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

Use as políticas do compute para controlar os custos​

As políticas de computação podem impor muitas restrições específicas de custo para compute recurso. Consulte Excelência operacional - Use as políticas do site compute. Por exemplo:

3. Monitore e controle os custos​

Monitore os custos​

O console da conta fornece um view sobre o uso faturável. Consulte Painéis de uso. O senhor também pode usar a conta API para download o logs.

Agrupamento de tags para atribuição de custos​

Para monitorar os custos em geral e atribuir com precisão o uso do Databricks às unidades de negócios e equipes da sua organização para fins de estorno, o senhor pode marcar o clustering, o SQL warehouse e o pool. Essas tags se propagam para as unidadesDatabricks detalhadas (DBU) e para o uso de armazenamento de blob e VM do provedor de nuvem para análise de custos.

Certifique-se de que o controle de custos e a atribuição sejam considerados ao configurar o espaço de trabalho e o clustering para equipes e casos de uso. Isso simplifica a marcação e melhora a precisão da atribuição de custos.

Os custos totais incluem a máquina virtual DBU, o disco e todos os custos de rede associados. Para o armazém serverless SQL , o custo DBU já inclui os custos da máquina virtual e do disco.

Implemente a observabilidade para rastrear e estornar os custos​

Ao trabalhar com ecossistemas técnicos complexos, entender proativamente as incógnitas é key para manter a estabilidade da plataforma e controlar os custos. A observabilidade fornece uma maneira 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.

Databricks oferece ótimos recursos de observabilidade usando tabelas do sistema que são armazenamentos analíticos hospedados no site Databricksdos dados operacionais de um cliente accountencontrados no catálogo do sistema. Eles oferecem observabilidade histórica no site account e incluem informações tabulares de fácil utilização sobre a telemetria da plataforma.

Veja os blogs: Equilibre de forma inteligente a otimização de custos e a confiabilidade em Databricks

Compartilhe relatórios de custos regularmente​

Gere relatórios mensais de custos para acompanhar o crescimento e as anomalias do consumo. Compartilhe esses relatórios por caso de uso ou equipe com as equipes que possuem as cargas de trabalho usando o Cluster Tag. Isso elimina surpresas e permite que as equipes ajustem proativamente suas cargas de trabalho se os custos ficarem muito altos.

Monitorar e gerenciar os custos de saída do Delta Sharing​

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

4. Projete cargas de trabalho econômicas​

Equilíbrio entre transmissão sempre ativa e acionada​

Tradicionalmente, quando se pensa em transmissão, vêm à mente termos como "tempo real", "24/7" ou "always on". Se a ingestão de dados ocorrer em tempo real, o recurso compute subjacente deverá ser executado 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 uma transmissão contínua de eventos exigem que esses eventos sejam imediatamente adicionados ao conjunto de dados analíticos. Se o requisito comercial do caso de uso exigir apenas dados atualizados a cada poucas 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. Databricks recomenda o uso da transmissão estruturada com o acionador AvailableNow para cargas de trabalho incrementais que não tenham requisitos de baixa latência. Consulte Configuração do processamento de lotes incrementais.

Equilíbrio entre instâncias sob demanda e excesso de capacidade​

As instâncias preemptivas aproveitam o excesso de recursos de máquinas virtuais na nuvem que estão disponíveis a um preço mais baixo. Para economizar custos, o site Databricks suporta a criação de clustering usando instâncias pontuais. Recomenda-se que a primeira instância (o driver do Spark) seja sempre uma máquina virtual sob demanda. Instâncias preemptivas são uma boa opção para cargas de trabalho em que é aceitável demorar mais porque uma ou mais instâncias spot foram removidas pelo provedor de nuvem.

Última atualização em