Boas práticas para otimização de custos

Este artigo aborda as melhores práticas de suporte aos princípios de otimização de custos, organizados 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 menor tempo de atividade do compute recurso, o que leva a custos mais baixos.

Use Job compute

Um Job é uma forma de executar código não interativo em uma instância 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 UI do Notebook. No entanto, em Job compute, as cargas de trabalho não interativas custarão significativamente menos do que em compute. Veja a visão geral de preços para comparar Jobs compute e All-Purpose compute.

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 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 Runtime atualizado 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 machine learning tarefa (Databricks Runtime para aprendizado de máquina). 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 GPUs apenas 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. workspace Os administradores 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 clusters".

Use 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 tanto a disponibilidade instantânea quanto o encerramento parado podem ser alcançados. Isso resulta em uma excelente experiência do usuário e na 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 IA 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

O uso da última geração de tipos de instância do cloud 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 simples são:

Memória otimizada para ML, cargas de trabalho pesadas de shuffle e spill
compute otimizado 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
Finalidade geral na ausência de requisitos específicos

Escolha o tamanho de computação mais eficiente

Databricks executa um executor por nó de worker. Portanto, os termos executor e worker são usados de forma intercambiável no contexto da arquitetura 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 transferidos 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 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 da sua carga de trabalho?
De onde você está lendo os dados?
Como os dados são particionados no armazenamento externo?
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 vetorizado 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 economias de custo significativas, 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 computação de escala automática

Com o autoscale, o site Databricks realoca dinamicamente o trabalhador para o site account de acordo com as características do seu site Job. 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 Job (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 cluster para cargas de trabalho de transmissão estruturada. Databricks recomenda o uso do site Delta Live Tables com autoscale aprimorado para cargas de trabalho de transmissão.

Usar rescisã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 programado 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 do pool cluster, consulte as práticas recomendadas depool . Databricks são um conjunto de instâncias paradas e prontas para uso. Quando os nós do cluster são criados usando as instâncias do parado, o cluster começar e os tempos de escalonamento automático são reduzidos. Se o pool não tiver instâncias paradas, o pool se expandirá alocando uma nova instância do provedor de instâncias para acomodar a solicitação do cluster.

Databricks não cobra Databricks Units (DBUs) enquanto as instâncias estão paradas no pool, resultando em economia de custos. O faturamento do provedor de instância é aplicável.

Use políticas de computação para controlar os custos

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

Habilite autoscale clusters com um número mínimo definido de nós worker .
Habilite o encerramento automáticoclusters com um valor razoável (por exemplo, 1 hora) para evitar o pagamento de tempos de parada.
Garanta que somente instâncias de VM econômicas possam ser selecionadas. Siga as práticas recomendadas para a configuração do cluster. Consulte Recomendações de configuração da computação.
Aplique uma estratégia de instância pontual.

3. Monitorar e controlar custos

Monitorar custos

O console account fornece um view sobre o uso faturável. Consulte Monitorar o uso no console da conta. O senhor também pode usar o account API para download o logs.

Clusters 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 tag clusters, SQL warehouse e pool. Esses tags se propagam para unidadesDatabricks detalhadas (DBU) e cloud VM do provedor e uso de armazenamento de blob 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 site clusters para equipes e casos de uso. Isso simplifica as tags 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 depósito serverless SQL , o custo DBU já inclui os custos da máquina virtual e do disco.

Implementar a observabilidade para rastrear e cobrar o custo

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

4. Projetar cargas de trabalho econômicas

Equilibre a transmissão sempre ativa e acionada

Tradicionalmente, quando as pessoas pensam 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 com excesso de capacidade

As instâncias preemptivas aproveitam o excesso de recursos da máquina virtual na cloud que estão disponíveis a um preço mais baixo. Para economizar custos, o Databricks suporta a criação de clusters usando instâncias pontuais. Recomenda-se que a primeira instância (o driver do Spark) seja sempre uma máquina virtual sob demanda. As 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 pontuais foram despejadas pelo provedor cloud.