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 os recursos corretos

Usar Delta Lake

O Delta Lake vem com muitas melhorias de desempenho que podem acelerar significativamente uma carga 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 for executada em clusters Job, isso levará diretamente a um Runtime mais curto dos clusters e a custos mais baixos.

Usar clusters Job

Um Job é uma forma de execução de código não interativo em clusters Databricks. Por exemplo, você pode executar uma carga de trabalho extrair, transformar e carregar (ETL) interativamente ou em um programar. Claro, você também pode executar Job interativamente na IU Notebook . No entanto, em clusters Job , as cargas de trabalho não interativas custarão significativamente menos do que em clusters todo-propósito. Consulte a visão geral de preços para comparar " compute de tarefas" e " compute para todos os fins".

Uma vantagem adicional é que cada execução Job ou fluxo de trabalho em novos clusters, isolando as cargas de trabalho umas das outras.

Observação

Os fluxos de trabalho multitarefa podem reutilizar recursos compute para todas as tarefas, de modo que o tempo startup clusters apareça apenas uma vez por fluxo de trabalho. Consulte usar a computação do databricks com seu Job.

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.

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 para o 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 garantir que todas as bibliotecas fornecidas estejam atualizadas e funcionem juntas de forma ideal. O Databricks Runtime é lançado em uma cadência regular e oferece melhorias de desempenho entre as principais versões. Essas melhorias no desempenho geralmente levam à economia de custos devido ao uso mais eficiente dos clusters de recursos.

Use GPUs apenas para as cargas de trabalho certas

As máquinas virtuais com GPUs podem acelerar drasticamente os processos computacionais para aprendizagem profunda, mas têm um preço significativamente mais alto do que as máquinas apenas com CPU. Use instâncias de GPU apenas para cargas de trabalho que tenham bibliotecas aceleradas por GPU.

A maioria das cargas de trabalho não usa bibliotecas aceleradas por GPU e não se beneficia de instâncias habilitadas para GPU. os administradores workspace podem restringir máquinas e clusters de GPU para evitar o uso desnecessário. Veja a postagem no blogs “As GPUs são realmente caras? GPUs de benchmarking para inferência em clusters Databricks”.

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

As instâncias Spot usam o recurso de excesso de máquinas virtuais em nuvem que estão disponíveis a um preço mais barato. Para economizar custos, o Databricks suporta a criação de clusters usando instâncias pontuais. Recomenda-se sempre ter a primeira instância (driver do Spark) como uma máquina virtual sob demanda. As instâncias spot são uma ótima opção para cargas de trabalho quando é aceitável demorar mais porque uma ou mais instâncias spot foram despejadas pelo provedor de nuvens.

2. Alocar e desalocar recursos dinamicamente

Aproveite a computação de escalonamento automático

autoscale permite que suas cargas de trabalho usem a quantidade certa de compute necessária para concluir seu Job.

Observação

compute O dimensionamento automático 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. Consulte Otimizar a utilização do pipeline cluster do Delta Live Tables com o Enhanced autoscale.

Consulte Confiabilidade - Design para dimensionamento automático:

Habilite autoscale para cargas de trabalho de lotes.
Habilite autoscale para SQL warehouse.
Use autoscale aprimorada Delta Live Tables.

Usar rescisão automática

O Databricks fornece vários recursos para ajudar a controlar os custos, reduzindo os recursos do parado e controlando quando os recursos compute podem ser implantados.

Configurar a terminação automática para todos os clusters interativos. Após um tempo de parada especificado, o site cluster é desligado. Veja o perfil da instância.
Para casos de uso em que os clusters são necessários apenas durante o horário comercial, os clusters podem ser configurados com encerramento automático e um processo agendado pode reiniciar o cluster (e possivelmente pré-aquecer os dados, se necessário) pela manhã, antes que os usuários retornem às suas áreas de trabalho. Consulte SELEÇÃO DE CACHE.
Se um tempo de início significativamente menor do que um início de clusters completo for aceitável, considere o uso de um pool de clusters. Veja as práticas recomendadas do Pool. O pool do Databricks reduz o tempo de início e de dimensionamento automático dos clusters, mantendo um conjunto de instâncias paradas e prontas para uso. Quando um cluster é anexado a um pool, os nós de clusters são criados usando as instâncias parado do pool. Se o pool não tiver instâncias paradas, o pool se expande alocando uma nova instância do provedor de instâncias para acomodar a solicitação dos clusters. Quando um cluster libera uma instância, ela retorna ao pool e fica livre para ser usada por outros clusters. Somente os clusters anexados a um pool podem usar as instâncias parado desse pool.

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

Use política de clusters para controlar custos

A política de cluster pode impor muitas restrições específicas de custo para clusters. Consulte Excelência Operacional - Use política de clusters. 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.
Garantir que somente instâncias de VM econômicas possam ser selecionadas. Siga as práticas recomendadas para a configuração de clusters. Consulte Práticas recomendadas de configuração da computação.
Aplique uma estratégia de instância pontual.

3. Monitorar e controlar custos

Monitorar custos

O console da conta permite visualizar o uso faturável. Como Databricks account proprietário ou account administrador, o senhor também pode usar o console account para download faturar o uso logs. Para acessar esses dados de forma programática, o senhor também pode usar o account API para download o logs. Como alternativa, o senhor pode configurar a entrega diária de logs de uso faturáveis em formato de arquivo CSV para um bucket de armazenamento do AWS S3.

Como prática recomendada, os custos totais (incluindo VMs, armazenamento e infraestrutura de rede) devem ser monitorados. Isso pode ser obtido por meio de ferramentas de gerenciamento de custos de provedores cloud ou adicionando ferramentas de terceiros.

Avalie o Photon para suas cargas de trabalho

Photon fornece desempenho query extremamente rápido e baixo custo – desde ingestão de dados, ETL, transmissão, ciência de dados e query interativa – diretamente em seu data lake. Photon é compatível com APIs Apache Spark, então começar é tão fácil quanto ativá-lo – sem alterações de código e sem aprisionamento. Comparado ao Apache Spark, o Photon oferece uma aceleração adicional de 2x conforme medido pelo benchmark TPC-DS 1TB. Os clientes observaram acelerações de 3 a 8 vezes em média, com base em suas cargas de trabalho, em comparação com as versões mais recentes do DBR.

De uma perspectiva de custo, as cargas de trabalho Photon usam cerca de 2 a 3 vezes mais DBUs por hora do que as cargas de trabalho Spark. Dado o aumento de velocidade observado, isso pode levar a economias de custos significativas, e Job que executam regularmente devem ser avaliados se eles são não apenas mais rápidos, mas também mais baratos com o Photon.

Use sem servidor para suas cargas de trabalho

As cargas de trabalho de BI normalmente usam dados em rajadas e geram várias query concorrentes. Por exemplo, alguém que usa uma ferramenta de BI pode atualizar um painel, escrever uma query ou simplesmente analisar os resultados query sem interagir mais com a plataforma. Este exemplo demonstra dois requisitos:

Encerre os clusters durante os períodos de parada para economizar custos.
Disponibilize recursos compute rapidamente (tanto para começar quanto para escalar) para satisfazer query do usuário quando ele solicitar dados novos ou atualizados com a ferramenta de BI.

Os armazénsDatabricks SQL sem serverless 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 parado. Por outro lado, serverless SQL warehouse começa e escala em segundos, de modo que tanto a disponibilidade imediata quanto o encerramento durante os tempos de parado podem ser alcançados. Isso resulta em uma ótima experiência do usuário e economia geral de custos.

Além disso, SQL warehouse serverless é escalado antes dos armazéns semserverless , resultando em custos mais baixos.

4. Analisar e atribuir despesas

Clusters de tags para atribuição de custos

Para monitorar o custo e atribuir com precisão o uso do Databricks às unidades e equipes de negócios da sua organização (por exemplo, para estornos), você pode tags clusters e pools. Essas tags se propagam para relatórios detalhados de uso de DBU e para VMs de provedor cloud e instâncias de armazenamento de blob para análise de custo.

Certifique-se de que o controle de custos e a atribuição já estejam em mente ao configurar workspace e clusters para equipes e casos de uso. Isso agiliza tags e melhora a precisão das atribuições de custo.

Para os custos gerais, a máquina virtual DBU, o disco e quaisquer custos de rede associados devem ser considerados. Para SQL warehouse serverless , isso é mais simples, pois os custos da DBU já incluem os custos da máquina virtual e do disco.

Consulte Monitorar o uso usando tags.

5. Otimize cargas de trabalho, busque custos escaláveis

Equilibre a transmissão sempre ativa e acionada

Tradicionalmente, quando as pessoas pensam em transmissão, termos como “tempo real”, “24/7” ou “always on” vêm à mente. Se a ingestão de dados ocorrer em “tempo real”, os clusters subjacentes precisam ser executados 24 horas por dia, 7 dias por semana, produzindo custos de consumo a cada hora do dia.

No entanto, nem todo caso de uso baseado em uma transmissão contínua de eventos precisa que esses eventos sejam adicionados ao conjunto de dados analíticos imediatamente. Se o requisito de negócios para o caso de uso precisar apenas de dados atualizados a cada poucas horas ou todos os dias, esse requisito poderá ser atendido com apenas várias execuções por dia, levando a uma redução significativa do custo da carga de trabalho. Databricks recomenda o uso de transmissão estruturada com gatilho AvailableNow para cargas de trabalho incrementais que não possuem requisitos de baixa latência. Consulte Configurando o processamento de lotes incrementais.

Escolha o tamanho clusters 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:

Núcleos totais do executor (computação): o número total de núcleos em todos os executores. Isso determina o paralelismo máximo de um cluster.
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.

Considerações adicionais incluem tipo e tamanho da instância worker , que também influenciam os fatores anteriores. Ao dimensionar seus clusters, 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 tamanho dos clusters.