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.

Dimensionamento vertical, dimensionamento horizontal e escalabilidade linear

Antes de discutir as práticas recomendadas, vamos primeiro examinar alguns conceitos sobre computação distribuída: dimensionamento horizontal e vertical e escalabilidade linear:

  • Dimensionamento vertical adicionando ou removendo recursos de um único computador, geralmente CPUs, memória ou GPUs. Normalmente, isso significa interromper a carga de trabalho, movê-la para uma máquina maior e reiniciá-la novamente. A escala vertical tem limites: pode não haver uma máquina maior ou o preço da próxima máquina maior é proibitivamente alto.

  • Dimensionamento horizontal ao adicionar ou remover nós de um sistema distribuído: Quando os limites do escalonamento vertical são atingidos, o escalonamento horizontal é a solução: A computação distribuída usa sistemas com várias máquinas (chamadas clusters) para executar as cargas de trabalho. É essencial entender que, para que isso seja possível, as cargas de trabalho devem ser preparadas para execução paralela, conforme suportado pelos mecanismos do Databricks lakehouse, Apache Spark e Photon. Isso permite combinar várias máquinas com preços razoáveis em um sistema de computação maior. Se for necessário mais compute recurso, o escalonamento horizontal adiciona mais nós aos clusters e os remove quando não forem mais necessários. Embora tecnicamente não haja limite (e o mecanismo do Spark assuma a parte complexa da distribuição das cargas), um grande número de nós aumenta a complexidade do gerenciamento.

  • Escalabilidade linear, ou seja, quando você adiciona mais recursos a um sistema, a relação entre a Taxa de transferência e o recurso utilizado é linear. Isto 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 nos clusters para cálculos adicionais. Esta 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 sempre terá alguma sobrecarga no gerenciamento da distribuição e troca 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 Databricks Data Intelligence fornece computação flexível (nó único e distribuída) para atender às necessidades exclusivas de suas cargas de trabalho.

Use arquiteturas sem servidor

Usar computação sem servidor

Com a serverless compute na Databricks Data Intelligence Platform, a compute camada de execução na Databricks account do cliente. workspace Os administradores podem criar um armazém SQL serverless que habilita o compute instantâneo e é gerenciado pelo Databricks. Um serverless SQL warehouse usa o compute clusters hospedado no Databricks cliente account. Use-os com as consultas Databricks SQL como o senhor faria normalmente com os armazéns Databricks SQL originais. serverless compute vem com um tempo de inicialização muito rápido para o SQL warehouse (10s e abaixo), e a infraestrutura é gerenciada por Databricks.

Isso leva a uma maior produtividade:

  • os administradores cloud não precisam mais gerenciar ambientes cloud complexos, por exemplo, ajustando cotas, criando e mantendo ativos de rede e ingressando em fontes de cobrança.

  • Os usuários se beneficiam de tempos de espera quase zero para clusters começarem e melhor simultaneidade em suas query.

  • os administradores cloud podem reorientar seu tempo em projetos de maior valor, em vez de gerenciar componentes cloud de baixo nível.

Projete 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 a pontos" ou "varredura versus pesquisa" - se comportam de maneira diferente, dependendo do tamanho dos dados. Arquivos grandes são mais eficientes para consulta de query e arquivos menores são melhores para pesquisa, pois você precisa ler menos dados para localizar 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 você pode simplesmente isolar a seção de dados. Manter os dados agrupados e isoláveis na ingestão é importante: considere manter uma ordem de classificação de tempo natural e aplique tantos filtros quanto possível à tabela de destino de ingestão. Para cargas de trabalho de ingestão somente anexar e sobrescrever, não há muito a considerar, pois esta é uma operação relativamente barata.

Os padrões de ingestão e acesso geralmente apontam para uma provisão de dados e clusters óbvios. Caso contrário, decida o que é mais importante para o seu negócio e invista em como resolver melhor esse objetivo.

Use computação paralela onde for benéfico

O tempo até o valor é uma dimensão importante ao trabalhar com dados. Embora muitos casos de uso possam ser facilmente implementados em uma única máquina (pequenos dados, poucos e simples passos de computação), frequentemente surgem casos de uso que:

  • Necessidade de processar grandes conjuntos de dados.

  • Têm tempos de execução longos devido a algoritmos complicados.

  • Deve ser repetido 100 e 1000 vezes.

O ambiente de cluster da plataforma Databricks é um ótimo ambiente para distribuir essas cargas de trabalho de forma eficiente. 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. 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 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 são Delta Live Tables. Você declara as tarefas e dependências de um Job em SQL ou Python e, em seguida, o Delta Live Tables assume o planejamento da execução, a configuração eficiente da infraestrutura, a execução Job 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 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 paralelizados para machine learning chamados MLlib. Ele oferece suporte para uso imediato, alavancando multi-GPU e compute de aprendizagem profunda distribuída, como por Horovod Runner. Veja HorovodRunner: aprendizagem profunda distribuída com Horovod. As bibliotecas específicas que também acompanham a plataforma ajudam a distribuir tarefas massivamente repetidas para todos os nós clusters , reduzindo o tempo de valorização de maneira quase linear. Por exemplo, Hyperopt para otimização paralela de hiperparâmetros em ML.

Analise toda a cadeia de execução

A maioria dos pipelines ou padrões de consumo usa uma cadeia de sistemas. Por exemplo, para 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 onde a ferramenta de BI envia a query.

Para obter o melhor desempenho da categoria, toda a cadeia precisa ser levada em account e selecionada/ajustada para obter o melhor desempenho.

Prefira clusters maiores

Observação

serverless compute gerenciar clusters automaticamente, portanto, isso não é necessário para serverless compute.

Planeje clusters maiores, especialmente quando a carga de trabalho aumentar linearmente. Nesse caso, não é mais caro usar clusters grandes para uma carga de trabalho do que usar clusters menores. É apenas mais rápido. A key é que você está alugando os clusters pela duração da carga de trabalho. Portanto, se você criar dois clusters worker e levar uma hora, estará pagando por esses worker pela hora inteira. Da mesma forma, se você criarclusters de quatro worker e levar apenas meia hora (aqui entra em jogo a escalabilidade linear), os custos serão os mesmos. Se os custos são o principal driver com um SLA muito flexível, um clusters autoscale quase sempre será o mais barato, mas não necessariamente o mais rápido.

Use operações nativas do Spark

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:

Razões:

  • Para transferir dados entre Python e Spark, a serialização é necessária. Isso diminui drasticamente a velocidade query.

  • Maiores esforços para implementar e testar funcionalidades já existentes 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 Photon

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 Runtime de alto desempenho que executa suas chamadas de API SQL e DataFrame existentes mais rapidamente e reduz o custo total por carga de trabalho. Photon é usado por default no Databricks SQL warehouse.

Entenda seu tipo de hardware e carga de trabalho

Observação

serverless compute gerenciar clusters automaticamente, portanto, isso não é necessário para serverless compute.

Nem todas as VMs cloud são criadas igualmente. As diferentes famílias de máquinas oferecidas pelos provedores cloud são diferentes o suficiente para fazer diferença. 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”. Isso deve ser entendido antes de decidir sobre o melhor tipo de VM para sua carga de trabalho.

Usar cache

Há dois tipos de cache disponíveis no Databricks: cache de disco e cache do Spark. Veja a seguir 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 quando o senhor configurar seu cluster. Esses trabalhadores estão habilitados e configurados para cache de disco.

  • Evite o Cache Spark

    O cache Spark (usando .persist() e .unpersist()) pode armazenar o resultado de quaisquer dados de subconsulta e dados armazenados em formatos diferentes de Parquet (como CSV, JSON e ORC). No entanto, se usado nos locais errados em uma query, pode consumir toda a memória e até mesmo tornar query substancialmente mais lenta. Como regra geral, evite o cache do Spark, a menos que você saiba exatamente o impacto. Consulte Cache do Spark.

  • cache de resultados query

    Armazenamento em cache por clusters dos resultados das consultas para todas as consultas por meio do SQL warehouse. 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 SQL warehouse retornará o resultado diretamente do cache de resultados da consulta.

  • Cache da interface do usuário do Databricks SQL

    Armazenamento em cache por usuário de todos os resultados de consultas e painéis herdados na interface do usuárioDatabricks SQL .

  • clusterspré-aquecidos

    Observação

    serverless compute gerenciar clusters automaticamente, portanto, isso não é necessário para serverless compute.

    Independentemente do formato da consulta e dos dados, a primeira consulta em um cluster sempre será mais lenta do que as consultas subsequentes. Isso tem a ver com todos os diferentes subsistemas que serão iniciados e lerão todos os dados de que precisam. O senhor pode levar isso em account para o benchmarking de desempenho. Também é possível anexar um cluster a um pool pronto para uso. Consulte pool referência de configuração.

Usar compactação

O Delta Lake no Databricks pode melhorar a velocidade da query de leitura de uma tabela. Uma maneira de melhorar essa velocidade é unir arquivos pequenos em arquivos maiores. Você aciona a compactação executando o comando OPTIMIZE. Consulte Arquivos de dados compactos com otimização no Delta Lake.

Você também pode compactar pequenos arquivos automaticamente usando o Auto Optimize. Consulte Considere o ajuste do tamanho do arquivo.

Usar salto de dados

Ignoração de dados: para conseguir isso, as informações de salto de dados são coletadas automaticamente quando você grava dados em uma tabela Delta (por default , o Delta Lake no Databricks coleta estatísticas nas primeiras 32 colunas definidas em seu esquema de tabela). Delta Lake on Databricks aproveita esta informação (valores mínimos e máximos) no momento da consulta para fornecer consultas mais rápidas. Consulte Ignoração de dados para Delta Lake.

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

Remoção dinâmica de arquivos: a remoção dinâmica de arquivos (DFP) pode melhorar significativamente o desempenho de muitas query em tabelas Delta. O DFP é especialmente eficiente para tabelas não particionadas ou join em colunas não particionadas.

Evite o excesso de particionamento

No passado, o particionamento era a forma mais comum de pular 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 se os padrões de acesso mudarem com o tempo. Freqüentemente, o particionamento leva ao particionamento excessivo - em outras palavras, muitas partições com arquivos muito pequenos, o que resulta em desempenho query ruim. Consulte Partições.

Enquanto isso, uma escolha muito melhor do que o particionamento é a Z-ordering.

Considere o ajuste do tamanho do arquivo

O termo otimização automática às vezes é usado para descrever a funcionalidade controlada pelas configurações delta.autoCompact e delta.optimizeWrite. Este termo foi retirado em favor da descrição de cada configuração individualmente. Consulte Configurar o Delta Lake para controlar o tamanho do arquivo de dados.

A otimização automática é particularmente útil nos seguintes cenários:

  • casos de uso de transmissão onde a latência na ordem de minutos é aceitável.

  • merge INTO é o método preferencial de gravação no Delta Lake.

  • CREATE TABLE AS SELECT ou INSERT INTO são operações comumente usadas.

Otimize o desempenho da junção

  • Considere a otimização join de intervalo. Consulte Otimização de junção de intervalo.

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

  • Considere a otimização join de inclinação.

    A distorção de dados é uma condição na qual os dados de uma tabela são distribuídos de forma desigual entre as partições nos clusters. A distorção de dados pode prejudicar gravemente o desempenho da query, especialmente aquelas com join. join entre tabelas grandes requer embaralhamento de dados e a distorção pode levar a um desequilíbrio extremo de trabalho nos clusters. É provável que a distorção de dados esteja afetando uma query se uma query parecer estar travada, concluindo poucas tarefas. Para melhorar a distorção, o Delta Lake no Databricks SQL aceita dicas de distorção em query. Com as informações de uma dica de inclinação, o Databricks Runtime pode construir um plano query melhor que não sofra com distorção de dados. Existem duas opções:

tabela de análise de execução para coletar estatísticas da tabela

tabela de análise de execução para coletar estatísticas em toda a tabela para o planejador query . Consulte ANALISAR TABELA.

ANALYZE TABLE mytable COMPUTE STATISTICS FOR ALL COLUMNS;

Esta informação é mantida no metastore e ajuda o otimizador query por:

  • Escolhendo o tipo join adequado.

  • Selecionando o lado de construção correto em um hash-join.

  • Calibrando a ordem join em uma join multidirecional.

Deve ser executado junto com OPTIMIZE diariamente e é recomendado em tabelas < 5TB. A única ressalva é que a tabela de análise não é incremental.

testes de desempenho de execução no escopo de desenvolvimento

Teste em dados representativos de dados de produção

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

Leve em consideração o pré-aquecimento dos recursos

A primeira query em novos clusters é mais lenta que todas as outras:

  • Em geral, os recursos clusters precisam ser inicializados em várias camadas.

  • Quando o armazenamento em cache faz parte da configuração, a primeira execução garante que os dados estejam no cache, o que acelera Job subsequente.

Pré-aquecer recursos - executar query específicas para inicializar recursos e preencher caches (por exemplo, após a reinicialização clusters ) - pode aumentar significativamente o desempenho da primeira query. 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.

Dica

Cargas de trabalho interativas, como refresh de painel, podem se beneficiar significativamente do pré-aquecimento. No entanto, isso não se aplica a clusters Job , onde o load by design é executado apenas uma vez.

Identificar gargalos

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