Práticas recomendadas para eficiência de desempenho

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

1. Escalonamento vertical, escalonamento horizontal e escalonamento linear

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

Escalonamento vertical: escalonamento vertical ao adicionar ou remover recursos de uma única máquina, geralmente CPUs, memória ou GPUs. Normalmente, isso significa interromper a carga de trabalho, movê-la para uma máquina maior e reiniciá-la. Há limites para o escalonamento 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 (chamadas clusters) para executar as 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 de baixo custo sejam combinadas em um sistema de computação maior. Quando mais compute recursos 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 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 cluster para continuar o cálculo. Essa troca de dados entre os 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 arquiteturas sem servidor

Usar computação sem servidor

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:

cloud Os administradores não precisam mais gerenciar ambientes cloud 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 baixo nível do cloud.
Os usuários se beneficiam da latência quase nula do cluster startup e da melhor simultaneidade de consultas.

Databricks fornece serviço gerenciado para diferentes cargas de trabalho:

serverless SQL Armazém para SQL cargas de trabalho

workspace Os administradores podem criar um depósito serverless SQL que habilita o compute instantâneo e é gerenciado pelo 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. serverless compute O senhor tem um tempo de startup muito rápido para o armazém SQL, e a infraestrutura é gerenciada e otimizada pelo Databricks.
serverless fluxo de trabalho para um fluxo de trabalho eficiente e confiável

serverless compute O for fluxo de trabalho permite que o senhor execute seu Databricks Job sem configurar e implantar infraestrutura. Com o serverless compute, o senhor se concentra na implementação de seu pipeline analítico e de processamento de dados e Databricks gerencia com eficiência o compute recurso, incluindo a otimização e o dimensionamento compute para suas cargas de trabalho. O autoscale e o Photon são ativados automaticamente para o recurso compute que executa o seu Job.

O senhor pode monitorar o custo do trabalho que usa o site serverless compute para fluxo de trabalho consultando a tabela do sistema de uso faturável.
serverless compute para Notebook

Se o seu workspace estiver habilitado para o serverless interativo compute, todos os usuários no workspace terão acesso ao serverless compute para Notebook. Não são necessárias permissões adicionais.

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

Mosaic AI Model Serving oferece uma interface unificada para implantar, administrar e consultar modelos de 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

Entenda 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 o senhor precisa ler menos dados para encontrar a(s) linha(s) específica(s).

Para padrões de ingestão, é comum usar instruções DML. As instruções DML têm melhor desempenho quando os dados são agrupados e o usuário 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 em tempo natural e aplique o maior número possível de filtros à tabela de destino da ingestão. Para cargas de trabalho de ingestão de append-only e overwrite, não há muito o que 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 onde for benéfico

O tempo até o valor é uma dimensão importante quando se trabalha com dados. Embora muitos casos de uso possam ser facilmente implementados em uma única máquina (dados pequenos, 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 centenas e milhares de vezes.

O ambiente de cluster da plataforma Databricks é um ótimo ambiente para distribuir com eficiência essas cargas de trabalho. Ele paraleliza automaticamente as consultas do SQL em todos os nós de um cluster e fornece biblioteca para Python e Scala para fazer o mesmo. Por trás do capô, 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 lotes de tarefas, a transmissão estruturada distribui Job transmitido entre os clusters para melhor desempenho.

Uma das maneiras mais fáceis de usar a computação paralela é com o Delta Live Tables. O senhor declara a tarefa e as dependências de um Jobem SQL ou Python e, em seguida, Delta Live Tables cuida do planejamento da execução, da configuração eficiente da infraestrutura, da execução do Job e do 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 escala para big data. A API do Pandas no Spark preenche essa lacuna fornecendo APIs equivalentes ao pandas que funcionam no Apache Spark.

Além disso, a plataforma vem com algoritmos machine learning paralelizados na biblioteca padrão do machine learning MLlib. Ele suporta o uso de várias GPUs prontas para uso. A aprendizagem profunda também pode ser paralelizada usando o Horovod Runner, 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.

Prefira clusters maiores

Planeje-se para um clusters maior, especialmente se a carga de trabalho aumentar 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. O key é que o senhor aluga o cluster para a duração da carga de trabalho. Portanto, se o senhor rodar dois worker clusters e isso levar uma hora, estará pagando por esses trabalhadores durante a hora inteira. Da mesma forma, se o senhor fizer um spin up de quatro worker cluster 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, uma cluster de escala automática geralmente é a mais barata, mas não necessariamente a mais rápida.

Observação

A preferência por clusters grandes não é necessária para serverless compute porque gerencia automaticamente clusters.

Use 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:

Razões:

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

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

Usar mecanismos de plataforma nativa

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

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 tipo de hardware e carga de trabalho

Nem todas as VMs do cloud são criadas da mesma forma. As várias famílias de máquinas oferecidas pelos provedores de cloud são suficientemente diferentes 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. Também há diferenças nos mercados "spot". Eles devem ser compreendidos antes de decidir qual é o melhor tipo de VM para sua carga de trabalho.

Observação

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

Usar 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 forma mais uniforme pelo sistema, evitando gargalos e possíveis paralisações.

Há vários tipos de cache disponíveis no 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 detecta 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 worker com volumes SSD ao configurar seu cluster. Esses trabalhadores estão habilitados e configurados para cache de disco.
Evite o Cache 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 query

Por cluster cache de resultados de consultas para todas as consultas por meio do armazém SQL. Para se beneficiar do armazenamento em cache do resultado da consulta, concentre-se em consultas determinísticas que, por exemplo, não usem 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 IU Armazenamento em cache por usuário de todos os resultados de consultas e painéis herdados na IU doDatabricks SQL .

Usar compactação

O Delta Lake no Databricks pode melhorar a velocidade de leitura de consultas de uma tabela. Uma maneira é agrupar 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 site cluster que realizou a gravação. A compactação automática compacta apenas 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.

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

Para obter melhores resultados, use Z-orderinguma técnica para agrupar 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.

Ou use o mais novo Liquid clustering, que simplifica as decisões de disposição de dados e otimiza o desempenho da consulta. 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.
Que crescem rapidamente e exigem manutenção e esforço de 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 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 do sistema de arquivos. Não há uma maneira fácil de alterar as 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.

Enquanto isso, uma opção melhor do que o particionamento é o Z-ordering ou o Liquid Clustering mais recente (veja acima).

Otimize o desempenho da junção

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 à otimização de junção de intervalos no Databricks Runtime pode trazer uma melhoria de ordens de magnitude no desempenho da consulta, mas requer um ajuste manual cuidadoso.
Usar a execução adaptativa de consultas.

A execução adaptável de consultas (AQE) é a re-otimizaçã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.
- Agrupa dinamicamente as partições após a troca de embaralhamento.
- Manipula dinamicamente a distorção na classificação merge join e embaralha o hash join.
- Detecta 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 Databricks, Spark e Delta Lake .

tabela de análise de execução 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.

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 tiverem sofrido uma mutação de mais de 10%, o que ocorrer primeiro).

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

Teste em dados representativos de 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 cluster é sempre mais lenta do que as consultas subsequentes. Isso ocorre porque todos os diferentes subsistemas estão sendo iniciados e lendo todos os dados de que precisam. O pré-aquecimento tem um impacto significativo nos resultados dos testes de desempenho:

Prewarm clusters: cluster recurso precisa ser inicializado em várias camadas. É possível pré-aquecer clusters: Databricks pool é um conjunto de instâncias paradas e prontas para uso. Quando os nós do cluster são criados usando essas instâncias do parado, os tempos do cluster startup e da 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 de um 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 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 com cargas de trabalho maiores 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 warehouse monitoramento: Monitore o warehouse SQL visualizando estatísticas ao vivo, gráficos de contagem de consultas de pico, gráficos 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 interface Apache Spark streaming Query Listener.

Monitorar Job desempenho

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 Job, permitindo que o senhor otimize a utilização do recurso, reduza o desperdício e melhore a eficiência geral.