Práticas recomendadas para eficiência de desempenho

Este artigo aborda as melhores práticas para eficiência de desempenho , organizadas pelos princípios arquitetônicos listados nas seções a seguir.

1. Escalabilidade vertical, escala horizontal e escalabilidade linear

Antes de entrarmos nas melhores práticas, vamos examinar alguns conceitos de computação distribuída: escala horizontal, escala vertical e escalabilidade linear.

• Escalonamento vertical: escalonamento vertical ao adicionar ou remover recursos de uma única máquina, geralmente CPUs, memória ou GPUs. Isso normalmente significa interromper a carga de trabalho, movê-la para uma máquina maior e reiniciá-la. Há limites para a escala vertical: pode não haver uma máquina maior ou o preço da próxima máquina maior pode ser proibitivo.
• Escalonamento horizontal : escalonamento horizontal, adicionando ou removendo nós de um sistema distribuído. Quando os limites do escalonamento vertical são atingidos, a solução é escalonar horizontalmente: A computação distribuída usa sistemas com várias máquinas (chamados de clustering) para executar cargas de trabalho. É importante entender que, para que isso seja possível, as cargas de trabalho devem ser preparadas para execução paralela, conforme suportado pelos mecanismos da Databricks Data Intelligence Platform, Apache Spark e Photon. Isso permite que várias máquinas baratas sejam combinadas em um sistema de computação maior. Quando mais compute recursos são necessários, o escalonamento horizontal adiciona mais nós ao clustering e os remove quando não são mais necessários. Embora tecnicamente não haja limite (e o mecanismo Spark faça a parte complexa do balanceamento de carga), um grande número de nós aumenta a complexidade do gerenciamento.
• Escalabilidade linear , o que significa que, quando o senhor adiciona mais recursos a um sistema, a relação entre a taxa de transferência e o recurso usado é linear. Isso só é possível se as tarefas paralelas forem independentes. Caso contrário, os resultados intermediários em um conjunto de nós serão necessários em outro conjunto de nós no clustering para cálculos adicionais. Essa troca de dados entre nós envolve o transporte dos resultados pela rede de um conjunto de nós para outro conjunto de nós, o que leva um tempo considerável. Em geral, a computação distribuída tem alguma sobrecarga para gerenciar a distribuição e a troca de dados. Como resultado, as cargas de trabalho de pequenos conjuntos de dados que podem ser analisadas em um único nó podem ser ainda mais lentas quando executadas em um sistema distribuído. A Databricks Data Intelligence Platform oferece computação flexível (nó único e distribuída) para atender às necessidades exclusivas de suas cargas de trabalho.

2. Use as arquiteturas serverless

Use o site serverless compute

Com a serverless compute na Databricks Data Intelligence Platform, a execução da camada compute no site do cliente Databricks account. O serviço é totalmente gerenciado e continuamente aprimorado pelo site Databricks. Além de os clientes pagarem apenas pelo que usam, isso resulta em maior produtividade:

• Os administradores de nuvem não precisam mais gerenciar ambientes de nuvem complexos, como ajuste de cotas, criação e manutenção de recursos de rede e conexão com fontes de faturamento. Eles podem concentrar seu tempo em projetos de maior valor em vez de gerenciar componentes de nuvem de baixo nível.
• Os usuários se beneficiam do clustering quase nulo startup latência e melhor simultaneidade de consulta.

Databricks Oferece um armazém sem servidor SQL para cargas de trabalho SQL: os administradores do espaço de trabalho podem criar um armazém serverless SQL que permite o acesso instantâneo compute e é gerenciado por Databricks. Use-os com as consultas do site Databricks SQL da mesma forma que o senhor usaria normalmente com os armazéns originais do site Databricks SQL. O compute sem servidor vem com um tempo startup muito rápido para o armazém SQL e a infraestrutura é gerenciada e otimizada pelo Databricks.

Use um modelo de serviço de nível empresarial

Mosaic AI Model Serving oferece uma interface unificada para implantar, administrar e consultar modelos AI. Cada modelo que o senhor atende está disponível como uma API REST que pode ser integrada ao seu aplicativo da Web ou cliente.

O servindo modelo fornece 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, economizando custos de infraestrutura e otimizando o desempenho da latência. Essa funcionalidade usa o site serverless compute.

3. Projetar cargas de trabalho para desempenho

Compreender sua ingestão de dados e padrões de acesso

Do ponto de vista do desempenho, os padrões de acesso a dados, como "agregações versus acesso pontual" ou "varredura versus pesquisa", comportam-se de maneira diferente dependendo do tamanho dos dados. Arquivos grandes são mais eficientes para consultas de varredura, e arquivos menores são melhores para pesquisas, porque você precisa ler menos dados para encontrar as linhas específicas.

Para padrões de ingestão, é comum usar declarações DML. As instruções DML têm melhor desempenho quando os dados estão agrupados e você pode simplesmente isolar a seção de dados. É importante manter os dados agrupados e isoláveis durante a ingestão: considere manter uma ordem de classificação temporal natural e aplicar o máximo de filtros possível à tabela de destino da ingestão. Para cargas de trabalho de ingestão de append-only e overwrite, não há muito a considerar, pois são operações relativamente baratas.

Os padrões de ingestão e acesso geralmente apontam para uma disposição óbvia dos dados e clustering. Caso contrário, decida o que é mais importante para sua empresa e concentre-se em como atingir melhor essa meta.

Use computação paralela quando for benéfica

O tempo de valorização é uma dimensão importante ao trabalhar com dados. Embora muitos casos de uso possam ser facilmente implementados em uma única máquina (dados pequenos, poucas e simples etapas computacionais), muitas vezes há casos de uso que precisam processar grandes conjuntos de dados, têm longos tempos de execução devido a algoritmos complicados ou precisam ser repetidos centenas e milhares de vezes.

O ambiente de clustering da plataforma Databricks é um ótimo ambiente para distribuir com eficiência essas cargas de trabalho. Ele paraleliza automaticamente as consultas SQL em todos os nós de um clustering e fornece biblioteca para Python e Scala para fazer o mesmo. Nos bastidores, os mecanismos Apache Spark e Photon analisam as consultas, determinam a forma ideal de execução paralela e gerenciam a execução distribuída de forma resiliente.

Da mesma forma que os lotes tarefa, a transmissão estruturada distribui o trabalho de transmissão pelo clustering para obter o melhor desempenho.

Uma das maneiras mais fáceis de usar a computação paralela é com o DLT. O senhor declara a tarefa e as dependências de um trabalho em SQL ou Python e, em seguida, a DLT cuida do planejamento da execução, da configuração eficiente da infraestrutura, da execução do trabalho e do monitoramento.

Para data scientists, Pandas é um pacote Python que fornece estruturas de dados fáceis de usar e ferramentas de análise de dados para a linguagem de programação Python. No entanto, Pandas não escala para big data. Pandas API em Spark preenche essa lacuna fornecendo Pandas equivalente a APIs que funciona em Apache Spark.

Além disso, a plataforma vem com algoritmos de aprendizado de máquina paralelizados na biblioteca padrão de aprendizado de máquina MLlib. Ele suporta o uso imediato de várias GPUs. A aprendizagem profunda também pode ser paralelizada usando o DeepSpeed Distributor ou o TorchDistributor.

Analise toda a cadeia de execução

A maioria dos padrões de pipeline ou consumo envolve uma cadeia de sistemas. Por exemplo, com as ferramentas de BI, o desempenho é afetado por vários fatores:

• A própria ferramenta de BI.
• O conector que conecta a ferramenta de BI e o mecanismo SQL.
• O mecanismo SQL para o qual a ferramenta de BI envia a consulta.

Para obter o melhor desempenho da categoria, toda a cadeia deve ser considerada e selecionada/ajustada para obter o melhor desempenho.

Prefere clustering maior

Planeje um clustering maior, especialmente se a carga de trabalho escalar linearmente. Nesse caso, usar um clustering grande para uma carga de trabalho não é mais caro do que usar um clustering menor. É apenas mais rápido. O key é que o senhor aluga o clustering para a duração da carga de trabalho. Portanto, se o senhor ativar dois worker clustering e isso levar uma hora, estará pagando por esses trabalhadores durante a hora inteira. Da mesma forma, se o senhor ativar um clustering de quatro worker e isso levar apenas meia hora (é aqui que entra a escalabilidade linear), os custos serão os mesmos. Se os custos forem o principal fator com uma SLA muito flexível, um clustering de autoescala geralmente é o mais barato, mas não necessariamente o mais rápido.

nota

A preferência por clustering grande não é necessária para o serverless compute porque ele gerencia automaticamente o clustering.

Usar operações nativas do Spark

As funções definidas pelo usuário (UDFs) são uma ótima maneira de ampliar a funcionalidade do Spark SQL. Entretanto, não use UDFs Python ou Scala se houver uma função nativa:

• Spark SQL
• PySpark

Motivos:

• A serialização é necessária para transferir dados entre o Python e o Spark. Isso diminui significativamente a velocidade das consultas.
• Maior esforço para implementar e testar a funcionalidade que já existe na plataforma.

Se as funções nativas estiverem ausentes e precisarem ser implementadas como UDFs do Python, use as UDFs do Pandas. O Apache Arrow garante que os dados sejam movimentados com eficiência entre o Spark e o Python.

Use mecanismos de plataforma nativos

Photon é o mecanismo do site Databricks que oferece desempenho rápido de consultas a baixo custo - desde a ingestão de dados, ETL, transmissão, ciência de dados e consultas interativas - diretamente em seu site data lake. 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 Photon faz parte de um tempo de execução de alto desempenho que executa mais rapidamente suas chamadas de API SQL e DataFrame existentes, reduzindo o custo total por carga de trabalho. Photon é usado pelo site default em Databricks SQL warehouses.

Entenda seu hardware e tipo de carga de trabalho

Nem todas as VMs na nuvem são criadas da mesma forma. As várias famílias de máquinas oferecidas pelos provedores de nuvem são diferentes o suficiente para importar. Existem diferenças óbvias - RAM e núcleos - e diferenças mais sutis - tipo e geração de processador, garantias de largura de banda de rede e armazenamento local de alta velocidade versus disco local versus disco remoto. Também existem diferenças nos mercados “spot”. Eles devem ser entendidos antes de decidir sobre o melhor tipo de VM para sua carga de trabalho.

nota

Isso não é necessário para serverless compute porque serverless compute gerencia automaticamente o clustering.

Use o armazenamento em cache

O armazenamento em cache armazena dados acessados com frequência em um meio mais rápido, reduzindo o tempo necessário para recuperá-los em comparação com o acesso à fonte de dados original. Isso resulta em menor latência e tempos de resposta mais rápidos, o que pode melhorar significativamente o desempenho geral de um aplicativo e a experiência do usuário. Ao minimizar o número de solicitações à fonte de dados original, o armazenamento em cache ajuda a reduzir o tráfego de rede e os custos de transferência de dados. Esse ganho de eficiência pode ser particularmente benéfico para aplicativos que dependem de APIs externas ou bancos de dados pagos por uso. Isso pode ajudar a distribuir a carga de maneira mais uniforme pelo sistema, evitando gargalos e possíveis períodos de inatividade.

Há vários tipos de cache disponíveis no Databricks. Aqui estão as características de cada tipo:

• Use cache de disco

  O cache de disco (anteriormente conhecido como "cache Delta") armazena cópias de dados remotos nos discos locais (por exemplo, SSD) das máquinas virtuais. Ele pode melhorar o desempenho de uma ampla gama de consultas, mas não pode ser usado para armazenar os resultados de subconsultas arbitrárias. O cache de disco detecta automaticamente quando os arquivos de dados são criados ou excluídos e atualiza seu conteúdo adequadamente. A maneira recomendada (e mais fácil) de usar o cache de disco é escolher um tipo worker com volumes SSD ao configurar o clustering. Esses trabalhadores são ativados e configurados para cache de disco.

• Evitar o cache do Spark

  O cache do Spark (usando .persist() e .unpersist()) pode armazenar o resultado de qualquer dado de subconsulta e dados armazenados em formatos diferentes do Parquet (como CSV, JSON e ORC). No entanto, se usado nos locais errados em uma consulta, ele pode consumir toda a memória e até mesmo tornar as consultas significativamente mais lentas. Como regra geral, evite o armazenamento em cache do Spark, a menos que o senhor saiba exatamente qual será o impacto.

• Cache de resultados da consulta

  Armazenamento em cache por clustering dos resultados das consultas para todas as consultas por meio do SQL warehouse. Para se beneficiar do armazenamento em cache de resultados de consultas, concentre-se em consultas determinísticas que, por exemplo, não usam predicados como = NOW(). Quando uma consulta é determinística e os dados subjacentes estão no formato Delta e inalterados, o armazém SQL retornará o resultado diretamente do cache de resultados da consulta.

• Databricks SQL Armazenamento em cache da interface do usuário

  Armazenamento em cache por usuário de todas as consultas e resultados de painéis legados na interface do usuárioDatabricks SQL.

Use compactação

O Delta Lake no Databricks pode melhorar a velocidade de leitura de consultas de uma tabela. Uma maneira é unir arquivos pequenos em arquivos maiores. O senhor aciona a compactação executando o comando OPTIMIZE. Consulte Otimizar a disposição do arquivo de dados.

O Delta Lake oferece opções para configurar automaticamente o tamanho do arquivo de destino para gravações e para operações OPTIMIZE. Databricks ajusta automaticamente muitas dessas configurações e habilita recursos que melhoram automaticamente o desempenho da tabela, buscando o tamanho correto dos arquivos:

• A compactação automática combina arquivos pequenos em partições da tabela Delta para reduzir automaticamente os problemas de arquivos pequenos. A compactação automática ocorre depois que uma gravação em uma tabela é bem-sucedida e é executada de forma síncrona no clustering que realizou a gravação. A compactação automática compacta somente os arquivos que não foram compactados anteriormente.
• As gravações otimizadas melhoram o tamanho do arquivo à medida que os dados são gravados e beneficiam as leituras subsequentes na tabela. As gravações otimizadas são mais eficazes para tabelas particionadas, pois reduzem o número de arquivos pequenos gravados em cada partição.

Consulte Configurar o Delta Lake para controlar o tamanho do arquivo de dados para obter mais detalhes.

Use o salto de dados

A omissão de dados pode melhorar significativamente o desempenho da consulta, ignorando os dados que não atendem aos critérios da consulta. Isso reduz a quantidade de dados que precisam ser lidos e processados, levando a tempos de execução de consultas mais rápidos.

Para isso, as informações de data skipping são coletadas automaticamente quando o senhor grava dados em uma tabela Delta (por default Delta Lake em Databricks coleta estatísticas sobre as primeiras 32 colunas definidas no esquema da tabela). Delta Lake em Databricks usa essas informações (valores mínimo e máximo) no momento da consulta para oferecer consultas mais rápidas. Veja Data skipping para o Delta Lake.

As técnicas a seguir podem ser aplicadas para pular dados:

• Z-orderingA técnica de colocação de informações relacionadas no mesmo conjunto de arquivos. Essa co-localidade é usada automaticamente nos Databricks pelos algoritmos de pulo de dados do Delta Lake. Esse comportamento reduz significativamente a quantidade de dados que o Delta Lake precisa ler.

• O Liquid clustering simplifica as decisões de disposição de dados e otimiza o desempenho das consultas. Com o tempo, ele substituirá o particionamento e o Z-ordering. A Databricks recomenda o clustering líquido para todas as novas tabelas delta. O Liquid clustering oferece a flexibilidade de redefinir a chave clustering sem reescrever os dados existentes, permitindo que a disposição dos dados evolua com as necessidades analíticas ao longo do tempo. A Databricks recomenda o clustering líquido para todas as novas tabelas delta.

  As tabelas com as seguintes características se beneficiam do clustering líquido:

  • Filtrado por colunas com alta cardinalidade.
  • Com distribuição de dados significativamente distorcida.
  • Isso cresce rapidamente e exige esforços de manutenção e ajuste.
  • Com solicitações de gravação concorrente.
  • Com padrões de acesso que mudam com o tempo.
  • Onde uma partição típica key poderia deixar a tabela com muitas ou poucas partições.

Para obter mais detalhes e técnicas, consulte o Guia abrangente para otimizar as cargas de trabalho Databricks, Spark e Delta Lake.

Permitir a otimização preditiva para o Delta Lake

A otimização preditiva elimina a necessidade de gerenciar manualmente as operações de manutenção das tabelas Delta no Databricks. Com a otimização preditiva ativada, o Databricks identifica automaticamente as tabelas que se beneficiariam de operações de manutenção e as executa para o usuário. As operações de manutenção são executadas apenas quando necessário, eliminando tanto a execução desnecessária de operações de manutenção quanto o ônus associado ao acompanhamento e à solução de problemas de desempenho.

Evite o particionamento excessivo

No passado, o particionamento era a forma mais comum de ignorar dados. No entanto, o particionamento é estático e se manifesta como uma hierarquia do sistema de arquivos. Não há uma maneira fácil de alterar partições, pois os padrões de acesso mudam com o tempo. Muitas vezes, o particionamento leva a um excesso de particionamento, ou seja, muitas partições com arquivos muito pequenos, o que resulta em um desempenho ruim da consulta.

Databricks recomenda que o senhor não particione tabelas com menos de 1 TB de tamanho e que só faça a partição por coluna se esperar que os dados em cada partição tenham pelo menos 1 GB.

Nesse meio tempo, uma opção melhor do que o particionamento é o Z-ordering ou o mais recente Liquid clustering (consulte acima).

Otimize join desempenho

• Considere a otimização do intervalo join .

  Um intervalo join ocorre quando duas relações são unidas usando uma condição de ponto no intervalo ou de sobreposição de intervalo. O suporte à join otimização do Databricks Runtime intervalo em pode melhorar o desempenho da consulta em ordens de magnitude, mas requer um ajuste manual cuidadoso.

• Use a execução adaptativa de consultas .

  A execução adaptativa de consultas (AQE) é a reotimização de consultas que ocorre durante a execução da consulta. Ele tem 4 recursos principais:

  • Altera dinamicamente a classificação merge join para broadcast hash join.
  • Coalesce dinamicamente as partições após a troca aleatória.
  • Manipula dinamicamente a distorção na classificação merge join e embaralha o hash join.
  • Detecta e propaga dinamicamente relações vazias.

  É recomendável manter o AQE ativado. Diferentes recursos podem ser configurados separadamente.

Para obter mais detalhes, consulte o Guia abrangente para otimizar as cargas de trabalho Databricks, Spark e Delta Lake.

execução analyze table para coletar estatísticas da tabela

A instrução ANALYZE TABLE coleta estatísticas sobre tabelas em um esquema especificado. Essas estatísticas são usadas pelo otimizador de consultas para gerar um plano de consulta ideal, selecionando o tipo correto de join, selecionando o lado correto da compilação em um hash-join ou calibrando a ordem join em um join multidirecional.

Otimização preditiva executada automaticamente ANALYZE (Public Preview), um comando para coletar estatísticas, em Unity Catalog gerenciar tabelas. Databricks recomenda habilitar a otimização preditiva para todas as tabelas gerenciais do Unity Catalog para simplificar a manutenção de dados e reduzir os custos de armazenamento. Consulte Otimização preditiva para Unity Catalog gerenciar tabelas.

4. execução de testes de desempenho no escopo do desenvolvimento

Teste em dados representativos dos dados de produção

execução de testes de desempenho em dados de produção (somente leitura) ou dados semelhantes. Ao usar dados semelhantes, características como volume, disposição de arquivos e distorção de dados devem ser semelhantes aos dados de produção, pois isso tem um impacto significativo no desempenho.

Considere o recurso de pré-aquecimento

Independentemente da consulta e do formato dos dados, a primeira consulta em um clustering é sempre mais lenta do que as consultas subsequentes. Isso ocorre porque todos os diferentes subsistemas estão sendo inicializados e lendo todos os dados de que precisam. O pré-aquecimento tem um impacto significativo nos resultados dos testes de desempenho:

• Clusterização pré -aquecimento: o recurso de clusterização precisa ser inicializado em várias camadas. É possível pré-aquecer o clustering: Databricks pool é um conjunto de instâncias paradas e prontas para uso. Quando os nós de clustering são criados usando essas instâncias de parado, o clustering startup e os tempos de autoescala são reduzidos.
• Pré-aquecimento de caches : Quando o armazenamento em cache faz parte da configuração, a primeira execução garante que os dados estejam no cache, acelerando o trabalho subsequente. Os caches podem ser pré-aquecidos com a execução de consultas específicas para inicializar os caches (por exemplo, após a reinicialização do clustering). Isso pode melhorar significativamente o desempenho das primeiras consultas.

Portanto, para entender o comportamento dos diferentes cenários, teste o desempenho da primeira execução com e sem pré-aquecimento e das execuções subsequentes.

Identifique gargalos

Os gargalos são áreas em sua carga de trabalho que podem degradar o desempenho geral à medida que a carga aumenta na produção. Identificá-los no momento do projeto e testá-los em relação a cargas de trabalho mais altas ajudará a manter as cargas de trabalho estáveis na produção.

5. Monitorar o desempenho

Monitorar o desempenho da consulta

O monitoramento do desempenho das consultas ajuda o senhor a entender como os recursos estão sendo usados por diferentes consultas. O senhor pode identificar as consultas que estão sendo executadas lentamente, o que lhe permite identificar os gargalos de desempenho em seu sistema. O senhor também pode identificar as consultas que estão consumindo recursos significativos do sistema, o que pode levar à instabilidade ou ao tempo de inatividade. Essas informações ajudam o senhor a otimizar a alocação de recursos, reduzir o desperdício e garantir que os recursos sejam usados de forma eficiente.

A Databricks Data Intelligence Platform tem vários recursos de monitoramento (consulte Excelência operacional - Configurar monitoramento, alerta e registro), alguns dos quais podem ser usados para monitoramento de desempenho:

• Perfil de consulta : Use o recurso de perfil de consulta para solucionar problemas de gargalos de desempenho durante a execução da consulta. Ele fornece a visualização de cada tarefa de consulta e métricas relacionadas, como tempo gasto, número de linhas processadas e memória usada.
• SQL monitoramento do warehouse : Monitore o SQL warehouse visualizando estatísticas ao vivo, gráficos de contagem de consultas de pico, gráficos de clusters em execução e tabela de histórico de consultas

Monitorar as cargas de trabalho de transmissão

O monitoramento da transmissão permite que o senhor analise dados e detecte problemas à medida que eles ocorrem, fornecendo percepções em tempo real sobre o desempenho e o comportamento do seu sistema. Ao analisar os dados de transmissão, o senhor pode identificar tendências, padrões e oportunidades de otimização. Isso pode ajudar o senhor a ajustar seu sistema, melhorar a utilização de recursos e reduzir custos.

Para consultas de transmissão, use o monitoramento integrado de transmissão estruturada no site Spark UI ou envie métricas para um serviço externo usando a Apache interface Spark streaming Query Listener.

Monitorar o desempenho do trabalho

Job O monitoramento ajuda o senhor a identificar e resolver problemas em seu Databricks Job, como falhas, atrasos ou gargalos de desempenho. Job O monitoramento fornece percepções sobre o desempenho do trabalho, permitindo que o senhor otimize a utilização dos recursos, reduza o desperdício e melhore a eficiência geral.