Melhores práticas para eficiência de desempenho

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

1. Dimensionamento vertical, dimensionamento horizontal e escalabilidade linear

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

• Dimensionamento vertical: dimensione verticalmente adicionando ou removendo recursos de uma única máquina, normalmente CPUs, memória ou GPUs. Isso normalmente significa parar a carga de trabalho, movê-la para uma máquina maior e reiniciá-la. Há limites para o dimensionamento vertical: pode não haver uma máquina maior, ou o preço da próxima máquina maior pode ser proibitivo.
• Dimensionamento horizontal: dimensione horizontalmente adicionando ou removendo nós de um sistema distribuído. Quando os limites do dimensionamento vertical são atingidos, a solução é dimensionar horizontalmente: a computação distribuída usa sistemas com várias máquinas (chamados clusters) para executar cargas de trabalho. É importante entender que, para que isso seja possível, as cargas de trabalho devem estar 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 recursos de computação são necessários, o dimensionamento horizontal adiciona mais nós ao cluster e os remove quando não são mais necessários. Embora tecnicamente não haja limite (e o mecanismo Spark faz 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. Isto só é possível se as tarefas paralelas forem independentes. Caso contrário, 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. Esta troca de dados entre nós envolve o transporte dos resultados através da rede de um conjunto de nós para outro conjunto de nós, o que leva tempo considerável. Em geral, a computação distribuída tem alguma sobrecarga para gerir a distribuição e o intercâmbio de dados. Como resultado, pequenas cargas de trabalho de conjuntos 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 inteligência de dados Databricks fornece computação flexível (nó único e distribuído) para atender às necessidades exclusivas de suas cargas de trabalho.

2. Use arquiteturas sem servidor

Usar computação sem servidor

Com a computação sem servidor na Databricks Data Intelligence Platform, a camada de computação é executada na conta do Azure Databricks do cliente. Os serviços são totalmente gerenciados e continuamente aprimorados pela 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 ajustar cotas, criar e manter recursos de rede e conectar-se a 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 de latência de inicialização de cluster quase nula e simultaneidade de consulta aprimorada.

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

• Armazéns SQL sem servidor para cargas de trabalho SQL

  Os administradores de espaço de trabalho podem criar armazéns SQL sem servidor que permitem a computação instantânea e são gerenciados pelo Databricks. Use-os com consultas Databricks SQL como faria normalmente com os armazéns SQL Databricks originais. A computação sem servidor vem com um tempo de inicialização muito rápido para armazéns 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 seu trabalho Databricks sem configurar e implantar a infraestrutura. Com a computação sem servidor, você se concentra na implementação de seus pipelines de processamento e análise de dados, e o Databricks gerencia recursos de computação de forma eficiente, incluindo a otimização e o dimensionamento da computação para suas cargas de trabalho. O dimensionamento automático e o Photon são ativados automaticamente para os recursos de computação que executam seu trabalho.

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

• Computação sem servidor para notebooks

  Se o espaço de trabalho estiver habilitado para computação interativa sem servidor, todos os usuários no espaço de trabalho terão acesso à computação sem servidor para blocos de anotações. Não são necessárias permissões adicionais.

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

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

O serviç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 diminui automaticamente para atender às mudanças de demanda, economizando custos de infraestrutura e otimizando o desempenho de latência. Essa funcionalidade usa computação sem servidor.

3. Projetar cargas de trabalho para desempenho

Compreender os seus padrões de ingestão e acesso a dados

Do ponto de vista do desempenho, os padrões de acesso a dados - como "agregações versus acesso ao ponto" ou "varredura 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 a(s) linha(s) específica(s).

Para padrões de ingestão, é comum o uso de instruções DML. As instruções DML são mais eficientes quando os dados sã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 de tempo natural e aplique o maior número possível de filtros à tabela de destino de ingestão. Para cargas de trabalho de ingestão somente de apêndice e substituição, 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 o seu negócio e foque em como alcançar melhor esse objetivo.

Use computação paralela onde for benéfico

O tempo de valorização é uma dimensão importante quando se trabalha com dados. Embora muitos casos de uso possam ser facilmente implementados em uma única máquina (pequenos dados, poucos e simples passos 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 100 e 1000 vezes.

O ambiente de cluster da plataforma Databricks é um ótimo 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. Sob o capô, os motores Apache Spark e Photon analisam as consultas, determinam a maneira ideal de execução paralela e gerenciam a execução distribuída de forma resiliente.

Da mesma forma que as tarefas em lote, o Streaming Estruturado distribui trabalhos de streaming pelo 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, em seguida, o Delta Live Tables lida com o planejamento de execução, a configuração eficiente da infraestrutura, a execução do trabalho e o monitoramento.

Para cientistas de dados, 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, o Pandas não se expande para big data. A API do Pandas no Spark preenche essa lacuna fornecendo APIs equivalentes a pandas que funcionam no Apache Spark.

Além disso, a plataforma vem com algoritmos de aprendizado de máquina paralelos na biblioteca de aprendizado de máquina padrão MLlib. Ele suporta o uso de várias GPUs pronto para uso. 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 gasodutos ou padrões de consumo envolve uma cadeia de sistemas. Por exemplo, com 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.

Prefira clusters maiores

Planeje clusters maiores, especialmente se a carga de trabalho for dimensionada linearmente. Nesse caso, usar um cluster grande para uma carga de trabalho não é mais caro do que usar um cluster menor. É apenas mais rápido. A chave é que você alugue o cluster durante a carga de trabalho. Então, se você criar dois grupos de trabalhadores e demorar uma hora, você está pagando por esses trabalhadores pela hora inteira. Da mesma forma, se você girar um cluster de quatro trabalhadores e isso demorar apenas meia hora (é aqui que entra a escalabilidade linear), os custos são os mesmos. Se os custos são o principal driver com um SLA muito flexível, um cluster de dimensionamento automático é geralmente o mais barato, mas não necessariamente o mais rápido.

Nota

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

Usar operações nativas do Spark

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

• Spark SQL
• PySpark

Motivos:

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

Se as funções nativas estiverem faltando e devem ser implementadas como UDFs do Python, use UDFs do Pandas. O Apache Arrow garante que os dados se movam de forma eficiente entre o Spark e o Python.

Usar mecanismos de plataforma nativos

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

O Photon faz parte de um tempo de execução de alto desempenho que executa suas chamadas de API SQL e DataFrame existentes mais rapidamente, reduzindo o custo total por carga de trabalho. O Photon é utilizado por predefinição nos armazéns SQL do Databricks.

Compreender o hardware e o 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 serem importantes. Há 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. Existem também diferenças nos mercados "spot". Isso deve ser entendido antes de decidir sobre o melhor tipo de VM para sua carga de trabalho.

Nota

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

Usar cache

O cache armazena dados acessados com frequência em uma mídia mais rápida, 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 de um aplicativo. Ao minimizar o número de solicitações para a 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 bancos de dados pay-per-use. Ele pode ajudar a distribuir a carga de forma mais uniforme pelo sistema, evitando gargalos e possíveis períodos de inatividade.

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

• Usar 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 deteta automaticamente quando os arquivos de dados são criados ou excluídos e atualiza seu conteúdo de acordo. A maneira recomendada (e mais fácil) de usar o cache de disco é escolher um tipo de trabalho com volumes SSD ao configurar seu cluster. Esses trabalhadores são habilitados e configurados para cache de disco.

• Evite o Spark Caching

  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 usado nos locais errados em uma consulta, ele pode consumir toda a memória e pode até mesmo diminuir significativamente as consultas. Como regra geral, evite o cache do Spark, a menos que você saiba exatamente qual será o impacto.

• Cache de Resultados de Consulta

  Por cache de cluster de resultados de consulta para todas as consultas por meio de armazéns SQL. Para se beneficiar do cache de resultados de consulta, 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 SQL Warehouses retornará o resultado diretamente do cache de resultados da consulta.

• Cache da interface do usuário SQL do Databricks

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

Use a compactação

O Delta Lake no Azure Databricks pode melhorar a velocidade de leitura de consultas de uma tabela. Uma maneira é aglutinar arquivos pequenos em arquivos maiores. Você aciona a compactação executando o comando OTIMIZE. Consulte Otimizar layout de arquivo de dados.

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

• A compactação automática combina pequenos arquivos dentro de partições de tabela Delta para reduzir automaticamente pequenos problemas de arquivos. A compactação automática ocorre depois que uma gravação em uma tabela é bem-sucedida e é executada de forma síncrona no cluster que executou a gravação. A compactação automática compacta apenas 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 pequenos arquivos gravados em cada partição.

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

Usar pulo de dados

O salto de dados pode melhorar significativamente o desempenho da consulta ignorando dados que não atendem aos critérios de 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 conseguir isso, as informações de pulo de dados são coletadas automaticamente quando você grava dados em uma tabela Delta (por padrão, o Delta Lake no Azure Databricks coleta estatísticas nas primeiras 32 colunas definidas em seu esquema de tabela). O Delta Lake no Azure Databricks usa essas informações (valores mínimos e máximos) no momento da consulta para fornecer consultas mais rápidas. Consulte Pulo de dados para Delta Lake.

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

Ou use o Liquid Clustering mais recente, que simplifica as decisões de layout de dados e otimiza o desempenho da consulta. Ele substituirá o particionamento e a ordenação z ao longo do tempo. A Databricks recomenda o agrupamento líquido para todas as novas tabelas delta. O Liquid Clustering oferece a flexibilidade de redefinir chaves de clustering sem reescrever dados existentes, permitindo que o layout de dados evolua com as necessidades analíticas ao longo do tempo. A Databricks recomenda o agrupamento líquido para todas as novas tabelas delta.

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

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

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

Habilite a otimização preditiva para o Delta Lake

A otimização preditiva elimina a necessidade de gerenciar manualmente as operações de manutenção de tabelas Delta no Databricks. Com a otimização preditiva ativada, o Databricks identifica automaticamente as tabelas que se beneficiariam das operações de manutenção e as executa para o usuário. As operações de manutenção são executadas apenas conforme necessário, eliminando execuções desnecessárias para operações de manutenção e a carga associada ao rastreamento e ao desempenho de solução de problemas.

Evite o particionamento excessivo

No passado, o particionamento era a maneira mais comum de pular dados. No entanto, o particionamento é estático e se manifesta como uma hierarquia de sistema de arquivos. Não há uma maneira fácil de alterar partições à medida que os padrões de acesso mudam ao longo do tempo. Muitas vezes, o particionamento leva ao particionamento excessivo - em outras palavras, muitas partições com arquivos muito pequenos, resultando em um desempenho de consulta ruim.

O Databricks recomenda que você não particione tabelas abaixo de 1 TB de tamanho e que você só particione por uma coluna se esperar que os dados em cada partição tenham pelo menos 1 GB.

Enquanto isso, uma escolha melhor do que particionar é a ordenação em Z ou o Agrupamento Líquido mais recente (veja acima).

Otimizar o desempenho das associações

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

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

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

  A execução de consultas adaptável (AQE) é a reotimização da consulta que ocorre durante a execução de consultas. Tem 4 características principais:

  • Altera dinamicamente a associação de intercalação de ordenação para associação hash de difusão.
  • Aglutina dinamicamente as partições após a troca aleatória.
  • Manipula dinamicamente a inclinação na junção de mesclagem de classificação e a junção de hash aleatória.
  • Deteta e propaga dinamicamente relações vazias.

  Recomenda-se manter o AQE ativado. Diferentes recursos podem ser configurados separadamente.

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

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

A ANALYZE TABLE instrução 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, selecionando o lado de compilação correto em uma junção de hash ou calibrando a ordem de junção em uma junção multidirecional.

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

4. Executar testes de desempenho no âmbito do desenvolvimento

Ensaio em dados representativos dos 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, pois isso tem um impacto significativo no desempenho.

Considere o pré-aquecimento de recursos

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

• Clusters pré-aquecidos: os recursos de cluster precisam ser inicializados em várias camadas. É possível pré-aquecer clusters: os pools 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 ociosas, os tempos de inicialização e dimensionamento automático do cluster são reduzidos.
• Caches pré-aquecidos: quando o cache faz parte da configuração, a primeira execução garante que os dados estejam no cache, acelerando os trabalhos subsequentes. Os caches podem ser pré-aquecidos executando consultas específicas para inicializar caches (por exemplo, após a reinicialização de um cluster). Isso pode melhorar significativamente o desempenho das primeiras consultas.

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

Identificar 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. Monitore o desempenho

Monitorar o desempenho da consulta

O monitoramento do desempenho da consulta ajuda a entender como os recursos estão sendo usados por diferentes consultas. Você pode identificar consultas que estão sendo executadas lentamente, permitindo que você identifique gargalos de desempenho em seu sistema. Você também pode identificar consultas que estão consumindo recursos significativos do sistema, potencialmente levando à instabilidade ou ao tempo de inatividade. Essas informações ajudam a otimizar a alocação de recursos, reduzir o desperdício e garantir que os recursos estejam sendo usados de forma eficiente.

A Plataforma de Inteligência de Dados Databricks 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 gargalos de desempenho durante a execução da consulta. Ele fornece visualização de cada tarefa de consulta e métricas relacionadas, como tempo gasto, número de linhas processadas e memória usada.
• Monitoramento do SQL Warehouse: monitore armazéns SQL exibindo estatísticas em tempo real, gráficos de contagem de pico de consultas, gráficos de clusters em execução e tabela de histórico de consultas

Monitorar cargas de trabalho de streaming

O monitoramento de streaming permite que você analise dados e detete problemas à medida que eles ocorrem, fornecendo informações em tempo real sobre o desempenho e o comportamento do seu sistema. Ao analisar dados de streaming, você pode identificar tendências, padrões e oportunidades de otimização. Isso pode ajudá-lo a ajustar seu sistema, melhorar a utilização de recursos e reduzir custos.

Para consultas de streaming, use o monitoramento interno de Streaming estruturado na interface do usuário do Spark ou envie métricas por push para serviços externos usando a interface Apache Spark Streaming Query Listener.

Monitore o desempenho do trabalho

O monitoramento de tarefas ajuda você a identificar e resolver problemas em seus trabalhos do Databricks, como falhas, atrasos ou gargalos de desempenho. O monitoramento de tarefas fornece informações sobre o desempenho do trabalho, permitindo otimizar a utilização de recursos, reduzir o desperdício e melhorar a eficiência geral.