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
Casos de uso de BI
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.
Por exemplo, as instâncias do Amazon EC2 baseadas em Graviton2 podem oferecer um preço-desempenho significativamente melhor do que instâncias comparáveis do Amazon EC2.
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:
- Habilite a autoescala de clustering com um número mínimo definido de nós worker.
- Habilite o encerramento automático do clustering com um valor razoável (por exemplo, 1 hora) para evitar pagar por tempos de parada.
- Garanta que somente instâncias de VM econômicas possam ser selecionadas. Siga as práticas recomendadas para a configuração de clustering. Consulte as recomendações de configuração da computação.
- Aplique uma estratégia de instância spot.
3. Monitore e controle os custos
O gerenciamento de custos no Databricks é um aspecto fundamental para otimizar os gastos com a nuvem e, ao mesmo tempo, manter o desempenho. O processo pode ser dividido em três áreas key:
- Configuração
- Monitoramento
- Gestão
As melhores práticas a seguir abrangem essas três áreas.
Configurar a marcação 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 (por exemplo, para estornos na sua organização), o senhor pode marcar o espaço de trabalho, o clustering, o SQL warehouse e o pool.
Na fase de configuração, as organizações devem implementar práticas eficazes de marcação. Isso envolve a criação de convenções de nomenclatura de tags em toda a organização. É importante usar tanto tags gerais que atribuem o uso a grupos de usuários específicos quanto tags mais granulares que fornecem percepções altamente específicas, por exemplo, com base em funções, produto ou serviço.
Começar a marcar desde o início do uso do site Databricks. Além das tagsdefault definidas por Databricks, no mínimo, configure as tags personalizadas _Business Units_
e _Projects_
e as preencha para sua organização específica. Se o senhor precisar diferenciar entre desenvolvimento, garantia de qualidade e custos de produção, considere adicionar a tag Environment
ao espaço de trabalho e compute recurso.
As tags se propagam tanto para o site logs quanto para o recurso do provedor de nuvem para análise de custos. Os custos totais incluem DBUs (Databricks Units ), além de máquina virtual, disco e custos de rede associados. Observe que para serverless serviço, o custo de DBU já inclui os custos da máquina virtual.
Como a adição de tags afeta apenas o uso futuro, é melhor começar com uma estrutura de tags mais detalhada. Sempre é possível ignorar as tags se o uso prático ao longo do tempo mostrar que elas não têm impacto na compreensão e na atribuição de custos. Mas as tags ausentes não podem ser adicionadas a eventos anteriores.
Configure orçamentos e alertas para permitir o monitoramento dos gastos em account
Os orçamentos permitem que o senhor monitore o uso em todo o site account. Eles oferecem uma maneira de definir metas financeiras e permitem que o senhor acompanhe os gastos em todo o site accountou aplique filtros para acompanhar os gastos de equipes, projetos ou espaços de trabalho específicos. Se o seu account usa serverless compute, certifique-se de usar as políticas de orçamento para atribuir o uso do account's serverless. Consulte Atributo serverless uso com políticas orçamentárias.
Recomenda-se que o senhor configure as notificações do site email quando o orçamento mensal for atingido para evitar gastos excessivos inesperados.
Monitore os custos para alinhar os gastos com as expectativas
Os painéis de observabilidade de custos ajudam a visualizar os padrões de gastos e as políticas orçamentárias ajudam a atribuir o uso do serverless compute a usuários, grupos ou projetos específicos, permitindo uma alocação de custos mais precisa. Para manter o controle dos gastos, o site Databricks oferece uma série de ferramentas e recursos para rastrear e analisar os custos:
-
Monitore o uso no console account : Databricks oferece painéis de gerenciamento de custos AI/BI no console account, que podem ser importados pelos administradores account para qualquer workspace habilitado para o Catálogo Unity em seu account. Isso permite que o senhor monitore o uso do site account ou de um único workspace.
-
Use os orçamentos para monitorar os gastos do account: Os orçamentos permitem que o senhor monitore o uso em seu account.
As políticas de orçamento podem ser usadas para atribuir o uso do serverless aplicando tags a qualquer atividade do serverless compute incorrida por um usuário atribuído à política. -
Monitorar e gerenciar os custos de saída do Delta Sharing: Ao contrário de outras plataformas de compartilhamento de dados, o Delta Sharing não exige 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.
-
Monitore os custos usando tabelas do sistema: A tabela do sistema
system.billing.usage
permite monitorar os custos. As tags personalizadas aplicadas ao espaço de trabalho e ao recurso compute são propagadas para essa tabela do sistema. O senhor pode monitorar os custos de serverless compute , custos de trabalho e custos de manutenção do modelo. -
download do uso faturável para análise local : O senhor pode usar a conta REST APIpara download o registro de uso faturável no formato CSV para o account e o intervalo de datas especificados.
gerenciar custos para alinhar o uso com as necessidades organizacionais
O gerenciamento de custos vai além da implementação técnica para incluir estratégias organizacionais mais amplas:
- Desenvolver e programar um trabalho de limpeza para aplicar ou limpar tags (de forma incremental). O trabalho precisa ser resiliente para não ser interrompido por problemas de um único recurso. Todas as alterações devem ser gravadas em uma auditoria log.
- Realizar auditorias regulares de custos para analisar todos os recursos ativos, seus gastos e seu alinhamento com as necessidades organizacionais. O compartilhamento de relatórios mensais de custos ajuda a rastrear aumentos e anomalias de consumo e incentiva o gerenciamento proativo de custos em todas as equipes.
- Otimize a alocação de recursos por meio de estratégias como autoscale e auto-terminação, que alocam dinamicamente os recursos com base nos requisitos da carga de trabalho; consulte as outras práticas recomendadas neste capítulo.
- Instruir as equipes sobre as implicações de custo do uso de recursos e treiná-las nas práticas recomendadas para otimização de custos.
- Use as políticas docompute como uma ferramenta para controlar o tipo e o tamanho do recurso compute que determinados usuários podem criar e acessar.
No geral, a otimização de custos precisa ser vista como um processo contínuo e as estratégias precisam ser revisadas regularmente em caso de escalabilidade, novos projetos ou picos inesperados de custos. Use os recursos nativos de gerenciamento de custos da Databricks e ferramentas de terceiros para obter controle e otimização abrangentes.
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 Spot 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. As instâncias spot são uma boa opção para cargas de trabalho em que é aceitável levar mais tempo porque uma ou mais instâncias spot foram removidas pelo provedor de nuvem.
Além disso, considere usar o tipo de instância Fleet. Se um clustering usar um desses tipos de instância de frota, o site Databricks selecionará os tipos de instância física AWS correspondentes com o melhor preço e disponibilidade para uso em seu clustering.