Práticas recomendadas para eficiência de desempenho

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

1. Escala vertical, dimensionamento horizontal e escalabilidade linear

Antes de abordar as práticas recomendadas, confira alguns conceitos de computação distribuída: dimensionamento horizontal, dimensionamento vertical e escalabilidade linear.

• Dimensionamento vertical: faça o dimensionamento vertical adicionando ou removendo recursos de um único computador, normalmente CPUs, memória ou GPUs. Isso normalmente significa interromper a carga de trabalho, movê-la para um computador com mais capacidade e reiniciá-la. Há limites para o dimensionamento vertical: pode não haver um computador com mais capacidade ou o preço dele pode ser muito alto.
• Dimensionamento horizontal: faça o dimensionamento horizontal adicionando ou removendo nós de um sistema distribuído. Quando os limites do dimensionamento vertical são atingidos, a solução é ajustar a escala horizontalmente: a computação distribuída usa sistemas com diversos computadores (chamados de clusters) para executar as cargas de trabalho. É importante entender que para que isso seja possível, as cargas de trabalho devem estar preparadas para execução paralela, com o suporte dos mecanismos da plataforma Databricks Data Intelligence, do Apache Spark e do Photon. Isso permite que diversos computadores mais baratos sejam combinados em um sistema de computação maior. Quando são necessários mais recursos de computação, o dimensionamento horizontal adiciona mais nós ao cluster e os remove quando eles não são mais necessários. Embora não haja limite do ponto de vista técnico (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 você adiciona mais recursos a um sistema, a relação entre a taxa de transferência e os recursos usados ​​é linear. Isso só será 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 cluster para computação adicional. 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 apresenta alguma sobrecarga no gerenciamento da distribuição e da troca de dados. Como resultado, pequenas cargas de trabalho de conjunto de dados que podem ser analisadas em um único nó podem ser ainda mais lentas quando executadas em um sistema distribuído. A Plataforma de Data Intelligence do Databricks fornece computação flexível (nó único e distribuído) para atender às necessidades exclusivas de suas cargas de trabalho.

2. Usar arquiteturas sem servidor

Usar computação sem servidor

Com a computação sem servidor na plataforma Databricks Data Intelligence, a camada de computação é executada na conta do cliente no Azure Databricks. Os serviços são totalmente gerenciados e continuamente aprimorados pela Databricks. Além disso, os clientes pagam somente pelo que usam, o que resulta em maior produtividade:

• Os administradores de nuvem não precisam mais gerenciar ambientes de nuvem complexos, incluindo o ajuste de cotas, a criação e manutenção de recursos de rede e a conexão com fontes de cobrança. 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 da inicialização do cluster com latência quase zero e da melhor simultaneidade de consulta.

O Databricks fornece serviços gerenciados para diferentes cargas de trabalho:

• Warehouses SQL sem servidor para cargas de trabalho SQL

  Os administradores de workspace podem criar os SQL warehouses sem servidor que habilitam a computação instantânea e são gerenciados pelo Databricks. Use-os com consultas do Databricks SQL, assim como você faria normalmente com os warehouses SQL originais do Databricks. A computação sem servidor fornece um tempo de inicialização muito rápido para warehouses SQL, e a infraestrutura é gerenciada e otimizada pelo Databricks.

• Trabalhos sem servidor para fluxos de trabalho eficientes e confiáveis

  A computação sem servidor para trabalhos permite que você execute o trabalho do Databricks sem configurar e implantar a infraestrutura. Com ela, você se concentra na implementação dos pipelines de análise e processamento de dados e o Databricks gerencia com eficiência os recursos de computação, incluindo a otimização e o dimensionamento da computação para as cargas de trabalho. O dimensionamento automático e o Photon são habilitados automaticamente para os recursos de computação que executam o trabalho.

  Você pode monitorar o custo de trabalhos que usam computação sem servidor para trabalhos consultando a tabela sistema de uso faturável.

• Computação sem servidor para notebooks

  Se o workspace estiver habilitado para computação interativa sem servidor, todos os usuários no workspace terão acesso à computação sem servidor para notebooks. Nenhuma permissão adicional é necessária.

Usar um serviço corporativo de veiculação de modelos

O Mosaic AI Model Serving fornece uma interface unificada para implantar, controlar e consultar modelos de IA. Cada modelo que você atende está disponível como uma API REST que você pode integrar ao seu aplicativo Web ou cliente.

A veiculação de modelos fornece um serviço altamente disponível e de baixa latência para a implantação de modelos. O serviço aumenta ou reduz verticalmente automaticamente para atender às alterações de demanda, economizando custos de infraestrutura ao otimizar o desempenho de latência. Essa funcionalidade usa computação sem servidor.

3. Projetar cargas de trabalho para desempenho

Entender seus padrões de ingestão de dados e acesso

De uma perspectiva de desempenho, os padrões de acesso a dados - como "agregações versus acesso a pontos" ou "verificação versus pesquisa" - se comportam de forma 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 linhas específicas.

Para os padrões de ingestão, é comum usar instruções DML. As instruções DML são mais eficazes quando os dados são clusterizados e você pode simplesmente isolar a seção de dados. É importante manter os dados agrupados e poder isolá-los ​​durante a ingestão: considere manter uma ordem de classificação de tempo natural e aplicar o máximo de filtros possível à tabela de destino de ingestão. Para cargas de trabalho de ingestão de substituição e somente de acréscimo, não há muito a considerar porque é uma operação relativamente barata.

Os padrões de ingestão e acesso geralmente apontam para um layout de dados óbvio e clustering. Caso contrário, decida o que é mais importante para os seus negócios e concentre-se em como atingir melhor esse objetivo.

Usar a computação paralela em que ela é benéfica

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

O ambiente de cluster da plataforma Databricks é um excelente ambiente para distribuir eficientemente essas cargas de trabalho. Ele paraleliza automaticamente consultas SQL em todos os nós de um cluster e fornece bibliotecas para Python e Scala fazerem 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 maneira resiliente.

Da mesma forma que as tarefas em lote, o Streaming Estruturado distribui trabalhos de streaming no cluster para obter o melhor desempenho.

Uma das maneiras mais fáceis de usar a computação paralela é com Delta Live Tables. Você declara as tarefas e dependências de um trabalho em SQL ou Python e a Delta Live Tables se responsabiliza pelo planejamento da execução, pela configuração eficiente da infraestrutura, pela execução do trabalho e pelo monitoramento.

Para cientistas de dados, o pandas é um pacote do Python que fornece estruturas de dados fáceis de usar e ferramentas de análise de dados para a linguagem de programação do Python. No entanto, o Pandas não escala horizontalmente para Big Data. A API do Pandas no Spark preenche esse espaço fornecendo APIs equivalentes ao pandas que funcionam no Apache Spark.

Além disso, a plataforma fornece algoritmos de machine learning paralelizados na biblioteca padrão de machine learning MLlib. Ela dá suporte ao uso de diversas GPUs prontas para uso. O deep learning também pode ser paralelizado usando DeepSpeed Distributor ou TorchDistributor.

Analisar toda a cadeia de execução

A maioria dos pipelines ou padrões de consumo envolve uma cadeia de sistemas. Por exemplo, o desempenho é impactado por diversos fatores ao usar ferramentas de BI:

• 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.

Preferir clusters maiores

Planeje o uso de clusters maiores, em especial se a carga de trabalho for dimensionada linearmente. Nesse caso, o uso de um cluster grande para uma carga de trabalho não é mais caro do que o uso de um cluster menor. É mais rápido. O segredo é alugar o cluster para a duração da carga de trabalho. Portanto, se você ativar dois clusters de trabalho e isso levar uma hora, você pagará esses trabalhos pela hora inteira. Da mesma forma, se você ativar um cluster de quatro trabalhos e isso levar apenas meia hora (a escalabilidade linear é útil neste caso), os custos serão os mesmos. Se os custos são o principal fator com um SLA muito flexível, um cluster de dimensionamento automático geralmente será o mais barato, mas não necessariamente o mais rápido.

Observação

A preferência por clusters grandes não é necessária para a computação sem servidor porque ela gerencia os clusters automaticamente.

Usar operações nativas do Spark

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

• Spark SQL
• PySpark

Razões:

• A serialização é necessária para transferir dados entre Python e Spark. Isso atrasa significativamente as consultas.
• Maior esforço para implementar e testar funcionalidades já existentes na plataforma.

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

Usar mecanismos de plataforma nativos

O Photon é o mecanismo do Azure Databricks que fornece desempenho rápido de consulta a baixo custo – da ingestão de dados, ETL, streaming, ciência de dados e consultas interativas – diretamente no data lake. O Photon é compatível com as APIs do Apache Spark, ou seja, começar a usá-lo é tão fácil quanto ativá-lo – sem alterações de código e sem bloqueio.

O Photon faz parte de um runtime de alto desempenho que executa suas chamadas de API SQL e DataFrame existentes com mais rapidez, a fim de reduzir o custo total por carga de trabalho. O Photon é usado por padrão no SQL do Databricks Warehouses.

Entender o tipo de hardware e carga de trabalho

Nem todas as VMs na nuvem são criadas iguais. As diversas famílias de computadores oferecidas pelos provedores de nuvem são diferentes o suficiente para fazer diferença. Há diferenças óbvias - RAM e núcleos - e diferenças mais sutis - tipo de processador e geração, garantias de largura de banda de rede e armazenamento local de alta velocidade versus disco local versus disco remoto. Há também diferenças nos mercados "spot". Eles devem ser compreendidos antes de decidir sobre o melhor tipo de VM para sua carga de trabalho.

Observação

Isso não é necessário para a computação sem servidor porque ela gerencia os clusters automaticamente.

Usar o cache

O cache armazena os 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 e a experiência do usuário com um aplicativo. Ao minimizar o número de solicitações à fonte de dados original, o 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 de bancos de dados pagos conforme o uso. Isso pode ajudar a distribuir a carga de maneira mais uniforme pelo sistema, e evita gargalos e possíveis tempos de inatividade.

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

• Usar o 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. Eles podem melhorar o desempenho de uma ampla variedade de consultas, mas não podem ser usados para armazenar resultados de subconsultas arbitrárias. O cache de disco detecta automaticamente quando os arquivos de dados são criados ou excluídos e atualiza o conteúdo armazenado de acordo com isso. A maneira recomendada (e mais fácil) de usar o cache de disco é escolher um tipo de trabalho com volumes SSD ao configurar o cluster. Esses trabalhos são habilitados e configurados para o armazenamento em cache de disco.

• Evitar Cache do Spark

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

• Cache de Resultados da Consulta

  Cache de resultados da consulta por cluster de todas as consultas, por meio de warehouses de SQL. Para se beneficiar do armazenamento de resultados de consulta em cache, concentre-se em consultas determinísticas que, por exemplo, não usam predicados como = NOW(). Quando uma consulta for determinística e os dados subjacentes estiverem no formato Delta e inalterados, os SQL Warehouses retornarão o resultado diretamente do cache de resultados da consulta.

• Cache da interface do usuário do Databricks SQL

  O armazenamento em cache por usuário de todos os resultados de consultas e do painel herdado resulta na interface do usuário do Databricks SQL.

Usar compactação

O Delta Lake no Azure Databricks pode aumentar a velocidade da leitura de consultas de uma tabela. Uma forma é unir arquivos pequenos em arquivos maiores. Você dispara a compactação executando o comando OPTIMIZE. Confira Otimizar o layout do arquivo de dados.

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

• A compactação automática combina arquivos pequenos em partições de tabelas Delta para reduzir automaticamente os problemas com arquivos pequenos. A compactação automática ocorre depois que uma gravação em uma tabela é bem-sucedida e executada de maneira síncrona no cluster que realizou a gravação. A compactação automática compacta somente 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. Gravações otimizadas são mais eficientes para tabelas particionadas, pois reduzem o número de pequenos arquivos gravados em cada partição.

Confira Configurar o Delta Lake para controlar o tamanho do arquivo de dados para saber mais.

Usar ignorar dados

Ignorar dados pode melhorar significativamente o desempenho da consulta, porque é possível ignorar dados que não atendem aos critérios dela. 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 sobre os dados ignorados são coletadas automaticamente quando você grava dados em uma tabela Delta (por padrão, o Delta Lake no Azure Databricks coleta estatísticas sobre as primeiras 32 colunas definidas no esquema da tabela). O Delta Lake no Azure Databricks utiliza estas informações (valores mínimos e máximos) no momento da consulta para fornecer consultas mais rápidas. Consulte Ignorar dados no Delta Lake.

Para ter resultados melhores, use a ordenação Z, uma técnica para colocar informações relacionadas no mesmo conjunto de arquivos. Essa colocalidade é usada automaticamente por algoritmos que ignoram dados do Delta Lake no Azure Databricks. Esse comportamento reduz significativamente a quantidade de dados que o Delta Lake precisa ler.

Também é possível usar o mais novo clustering líquido, que simplifica as decisões de layout de dados e otimiza o desempenho das consultas. Ele substituirá o particionamento e a ordenação z ao longo do tempo. A Databricks recomenda o clustering líquido para todas as novas tabelas Delta. O clustering líquido oferece a flexibilidade de redefinir chaves de cluster sem reescrever os dados atuais, permitindo que o layout de dados evolua ao longo do tempo de acordo com as necessidades de análise. A Databricks recomenda o clustering líquido para todas as novas tabelas Delta.

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

• Filtradas por colunas com alta cardinalidade.
• Com distribuição de dados significativamente distorcida.
• Que crescem rapidamente e exigem manutenção e esforço de ajuste.
• Com solicitações de gravação simultâneas.
• Com padrões de acesso que mudam ao longo do tempo.
• Em que uma chave de partição típica pode deixar a tabela com muitas ou poucas partições.

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

Habilitar a otimização preditiva para Delta Lake

A otimização preditiva elimina a necessidade de gerenciar manualmente as operações de manutenção para tabelas Delta no Databricks. Com a otimização preditiva habilitada, 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 as execuções desnecessárias de operações de manutenção quanto a carga associada ao acompanhamento e à solução de problemas de desempenho.

Evitar o excesso de particionamento

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

A Databricks recomenda que você não particione tabelas com tamanho menor que 1 TB e que você faça o particionamento somente por coluna se quiser que os dados em cada partição tenham pelo menos 1 GB.

Enquanto isso, uma escolha melhor do que o particionamento é a ordenação Z ou o mais novo clustering líquido (confira acima).

Otimizar o desempenho de junção

• Considere a otimização de junção de intervalo.

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

• Use a execução de consulta adaptável.

  A Execução de consulta adaptável (AQE) é a reotimização da consulta que ocorre durante a execução da consulta. Ela tem quatro recursos principais:

  • Altera dinamicamente a junção de mesclagem de classificação na junção hash de difusão.
  • Uni partições dinamicamente após a troca aleatória.
  • Manipula dinamicamente a distorção na junção de mesclagem de classificação e na junção de hash aleatório.
  • Detecta e propaga dinamicamente as relações vazias.

  É recomendável manter a AQE habilitada. Diferentes recursos podem ser configurados separadamente.

Para saber mais, confira o Guia abrangente para otimizar cargas de trabalho do Databricks, do Spark e do Delta Lake.

Executar a tabela de análise para coletar estatísticas de tabela

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

Para aproveitar adequadamente essas otimizações de consulta, o comando ANALYZE TABLE precisa ser executado regularmente (de preferência uma vez por dia ou quando os dados sofrerem mutações em mais de 10%, o que ocorrer primeiro).

4. Executar testes de desempenho no escopo de desenvolvimento

Testar dados representativos de dados de produção

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

Considerar a ativação prévia dos recursos

Independentemente da consulta e do formato dos dados, a primeira consulta em um cluster é sempre mais lenta do que as subsequentes. Isso ocorre porque todos os diferentes subsistemas estão sendo inicializados e lendo todos os dados necessários. A ativação prévia tem um impacto significativo nos resultados dos testes de desempenho:

• Clusters ativados previamente: os recursos do cluster precisam ser inicializados em diversas camadas. É possível fazer a ativação prévia de clusters: os pools do Databricks são um conjunto de instâncias ociosas e prontas para uso. Quando nós de cluster são criados usando essas instâncias, os tempos de inicialização e dimensionamento automático do cluster são reduzidos.
• Fazer a ativação prévia de caches: quando o cache faz parte da configuração, a primeira execução garante que os dados estejam nele, o que acelera os trabalhos subsequentes. É possível fazer a ativação prévia dos caches executando consultas específicas para inicializá-los (por exemplo, após uma reinicialização do cluster). 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 a ativação prévia e das execuções subsequentes.

Identificar gargalos

Gargalos são áreas na carga de trabalho que podem degradar o desempenho geral à medida que a carga aumenta na produção. Identificá-los em tempo de design e testar em cargas de trabalho mais altas ajudará a manter as cargas de trabalho estáveis em produção.

5. Monitorar desempenho

Monitorar o desempenho da consulta

Monitorar o desempenho da consulta ajuda você a entender como os recursos estão sendo usados ​​por diferentes consultas. É possível identificar consultas que estão sendo executadas lentamente, a fim de localizar os gargalos de desempenho no sistema. Também é possível identificar consultas que estão consumindo recursos significativos do sistema, o que pode levar à instabilidade ou ao tempo de inatividade. Essas informações ajudam você a otimizar a alocação de recursos, reduzir o desperdício e garantir que os recursos sejam usados ​​de maneira eficiente.

A plataforma Databricks Data Intelligence tem diversos recursos de monitoramento (confira Excelência operacional – Configurar o monitoramento, a geração de alertas e a geração de logs), alguns dos quais podem ser usados ​​para o monitoramento do desempenho:

• Perfil de consulta: use o recurso de perfil de consulta para solucionar gargalos de desempenho durante a execução da consulta. Ele fornece uma exibição de cada tarefa da consulta e das métricas relacionadas, como tempo gasto, número de linhas processadas e memória usada.
• Monitoramento de warehouse SQL: monitore warehouses SQL conferindo estatísticas em tempo real, gráficos de contagem de pico de consultas, gráficos de clusters em execução e tabelas de histórico de consultas

Monitorar cargas de trabalho de streaming

O monitoramento de streaming permite que você analise dados e detecte problemas conforme eles ocorrem, fornecendo insights em tempo real sobre o desempenho e o comportamento do sistema. Ao analisar dados de streaming, é possível identificar tendências, padrões e oportunidades de otimização. Isso pode ajudar você a ajustar o sistema, melhorar a utilização de recursos e reduzir os custos.

Para consultas de streaming, use o monitoramento de streaming estruturado integrado na interface do usuário do Spark ou efetue push de métricas para serviços externos usando a interface do ouvinte de consultas de streaming do Apache Spark.

Monitorar o desempenho do trabalho

O monitoramento de trabalhos ajuda a identificar e resolver problemas em trabalhos do Databricks, como falhas, atrasos ou gargalos de desempenho. Ele fornece insights sobre o desempenho dos trabalhos e permite otimizar a utilização de recursos, reduzir o desperdício e melhorar a eficiência geral.