Pular para o conteúdo principal

Práticas recomendadas: Delta Lake

Este artigo descreve as práticas recomendadas ao usar o Delta Lake.

A Databricks recomenda o uso da otimização preditiva. Consulte Otimização preditiva para Unity Catalog gerenciar tabelas.

Ao excluir e recriar uma tabela no mesmo local, você deve sempre usar uma instrução CREATE OR REPLACE TABLE. Consulte Soltar ou substituir uma mesa Delta.

Remover as configurações Delta legadas​

A Databricks recomenda remover a maioria das configurações Delta legadas explícitas das configurações do Spark e das propriedades da tabela ao atualizar para uma nova versão do Databricks Runtime. As configurações herdadas podem impedir que novas otimizações e valores default introduzidos pelo Databricks sejam aplicados às cargas de trabalho migradas.

Use o clustering líquido para otimizar a omissão de dados​

Databricks recomenda o uso do líquido clustering em vez de particionamento, Z-order, ou outras estratégias de organização de dados para otimizar a disposição dos dados para o salto de dados. Consulte Usar clustering líquido para tabelas Delta.

Arquivos compactos​

Otimização preditiva executando automaticamente OPTIMIZE e VACUUM comando em Unity Catalog gerenciar tabelas. Consulte Otimização preditiva para Unity Catalog gerenciar tabelas.

A Databricks recomenda a execução frequente do comando OPTIMIZE para compactar arquivos pequenos.

nota

Essa operação não remove os arquivos antigos. Para removê-los, execute o vacuum comando.

Substituir o conteúdo ou o esquema de uma tabela​

Ocasionalmente, você pode querer substituir uma tabela Delta. Por exemplo:

  • Você descobre que os dados na tabela estão incorretos e deseja substituir o conteúdo.
  • Você deseja regravar toda a tabela para fazer alterações incompatíveis no esquema (como alterar os tipos de coluna).

Embora você possa excluir todo o diretório de uma tabela Delta e criar uma nova tabela no mesmo caminho, ela não é recomendada porque:

  • Excluir um diretório não é eficiente. Um diretório que contém arquivos muito grandes pode levar horas ou até dias para ser excluído.

  • Você perde todo o conteúdo dos arquivos excluídos; é difícil recuperá-lo se você excluir a tabela errada.

  • A exclusão do diretório não é atômica. Enquanto você estiver excluindo a tabela, uma consulta simultânea lendo a tabela pode falhar ou ver uma tabela parcial.

  • Você pode ter problemas de consistência em potencial no S3, que é consistente apenas eventualmente.

Se o senhor não precisar alterar o esquema da tabela, poderá excluir os dados de uma tabela Delta e inserir os novos dados, ou atualizar a tabela para corrigir os valores incorretos.

Se quiser alterar o esquema da tabela, você pode substituir toda a tabela atomicamente. Por exemplo:

Python
dataframe.write \
  .mode("overwrite") \
  .option("overwriteSchema", "true") \
  .saveAsTable("<your-table>") # Managed table

dataframe.write \
  .mode("overwrite") \
  .option("overwriteSchema", "true") \
  .option("path", "<your-table-path>") \
  .saveAsTable("<your-table>") # External table

Existem vários benefícios com essa abordagem:

  • Substituir uma tabela é muito mais rápido porque ela não precisa listar o diretório recursivamente ou excluir nenhum arquivo.

  • A versão antiga da tabela ainda existe. Se o senhor excluir a tabela errada, poderá recuperar facilmente o antigo uso de dados da viagem do tempo. Consulte Work with Delta Lake table história.

  • É uma operação atômica. Consultas simultâneas ainda podem ler a tabela enquanto você exclui a tabela.

  • Devido às garantias de transação do Delta Lake ACID, se a substituição da tabela falhar, ela estará em seu estado anterior.

  • Você não enfrentará problemas de consistência no S3 porque não exclui arquivos.

Além disso, se o senhor quiser excluir arquivos antigos para economizar custos de armazenamento depois de substituir a tabela, poderá usar vacuum para excluí-los. Ele é otimizado para exclusão de arquivos e geralmente é mais rápido do que excluir todo o diretório.

Armazenamento em cache do Spark​

A Databricks não recomenda que o senhor use o cache do Spark pelos seguintes motivos:

  • Você perde qualquer perda de dados que possa vir de filtros adicionais adicionados ao cache DataFrame.
  • Os dados que são armazenados em cache podem não ser atualizados se a tabela for acessada usando um identificador diferente.

Diferenças entre o Delta Lake e o Parquet no Apache Spark​

O Delta Lake lida com as seguintes operações automaticamente. Você nunca deve executar estas operações manualmente:

  • REFRESH TABLE : As tabelas delta sempre retornam as informações mais atualizadas, portanto, não há necessidade de ligar REFRESH TABLE manualmente após as alterações.
  • Adicionar e remover partições : o Delta Lake rastreia automaticamente o conjunto de partições presentes em uma tabela e atualiza a lista à medida que os dados são adicionados ou removidos. Como resultado, não há necessidade de executar ALTER TABLE [ADD|DROP] PARTITION ou MSCK.
  • Carregar uma única partição : não é necessário ler partições diretamente. Por exemplo, você não precisa executar o spark.read.format("parquet").load("/data/date=2017-01-01"). Em vez disso, utilize uma cláusula WHERE para pular dados, como spark.read.table("<table-name>").where("date = '2017-01-01'").
  • Não modifique manualmente os arquivos de dados : o Delta Lake usa o log de transações para confirmar as alterações na tabela atomicamente. Não modifique, adicione ou exclua arquivos de dados Parquet diretamente em uma tabela Delta, porque isso pode levar à perda de dados ou à corrupção da tabela.

Melhorar o desempenho para Delta Lake merge​

O senhor pode reduzir o tempo necessário para acessar merge usando as seguintes abordagens:

  • Reduza o espaço de busca por correspondências : por padrão, a merge operação pesquisa toda a tabela Delta para encontrar correspondências na tabela de origem. Uma forma de acelerar merge é reduzir o espaço de pesquisa adicionando restrições conhecidas na condição de correspondência. Por exemplo, suponha que você tenha uma tabela particionada por country date e e queira usar merge para atualizar as informações do último dia e de um país específico. Adicionar a condição a seguir torna a consulta mais rápida, pois ela procura correspondências somente nas partições relevantes:

    SQL
    events.date = current_date() AND events.country = 'USA'

    Além disso, essa consulta também reduz as chances de conflitos com outras operações concorrente. Consulte Níveis de isolamento e conflitos de gravação em Databricks para obter mais detalhes.

  • Arquivos compactos : se os dados estiverem armazenados em muitos arquivos pequenos, a leitura dos dados para pesquisar correspondências pode ficar lenta. O senhor pode compactar arquivos pequenos em arquivos maiores para melhorar a leitura do Taxa de transferência. Para obter detalhes, consulte Otimizar a disposição do arquivo de dados.

  • Controle as partições aleatórias para gravações : a operação merge embaralha dados várias vezes para calcular e gravar os dados atualizados. O número de tarefas usadas para embaralhar é controlado pela configuração da sessão do Spark spark.sql.shuffle.partitions. A definição desse parâmetro não apenas controla o paralelismo, mas também determina o número de arquivos de saída. Aumentar o valor aumenta o paralelismo, mas também gera um número maior de arquivos de dados menores.

  • Habilitar gravações otimizadas : para tabelas particionadas, merge pode produzir um número muito maior de arquivos pequenos do que o número de partições aleatórias. Isso ocorre porque cada tarefa de embaralhamento pode gravar vários arquivos em várias partições, o que pode se tornar um gargalo de desempenho. Você pode reduzir o número de arquivos ativando gravações otimizadas. Consulte Gravações otimizadas para Delta Lake em Databricks.

  • Ajuste o tamanho dos arquivos na tabela : O Databricks pode detectar automaticamente se uma tabela Delta tem operações merge frequentes que reescrevem arquivos e pode optar por reduzir o tamanho dos arquivos reescritos em antecipação a outras reescritas de arquivos no futuro. Consulte a seção sobre ajuste de tamanhos de arquivos para obter detalhes.

  • Low Shuffle merge : A mesclagem Low Shuffle oferece uma implementação otimizada do site MERGE que proporciona melhor desempenho para as cargas de trabalho mais comuns. Além disso, ele preserva as otimizações de disposição de dados existentes, como Z-ordering em dados não modificados.

gerenciar a recência de dados​

No início de cada consulta, as tabelas Delta são atualizadas automaticamente para a versão mais recente da tabela. Este processo pode ser observado em cadernos quando o status do comando relata: Updating the Delta table's state. No entanto, ao executar a análise histórica em uma tabela, talvez você não precise necessariamente de dados atualizados até o último minuto, especialmente para tabelas em que os dados de transmissão estão sendo ingeridos com frequência. Nesses casos, as consultas podem ser executadas em instantâneos obsoletos da tabela Delta. Essa abordagem pode reduzir a latência para obter resultados de consultas.

O senhor pode configurar a tolerância para dados obsoletos definindo a configuração da sessão Spark spark.databricks.delta.stalenessLimit com um valor de cadeia de tempo, como 1h ou 15m (para 1 hora ou 15 minutos, respectivamente). Essa configuração é específica da sessão e não afeta outros clientes que acessam a tabela. Se o estado da tabela tiver sido atualizado dentro do limite de obsolescência, uma consulta na tabela retornará resultados sem esperar pela atualização mais recente da tabela. Essa configuração nunca impede que sua tabela seja atualizada e, quando dados obsoletos são retornados, a atualização é processada em segundo plano. Se a última atualização da tabela for anterior ao limite de obsolescência, a consulta não retornará resultados até que a atualização do estado da tabela seja concluída.

Pontos de verificação aprimorados para consultas de baixa latência​

O Delta Lake grava checkpoints como um estado agregado de uma tabela Delta em uma frequência otimizada. Esses pontos de verificação servem como ponto de partida para compute o estado mais recente da tabela. Sem os pontos de controle, Delta Lake teria que ler uma grande coleção de arquivos JSON (arquivos "delta") representando o commit da transação log para compute o estado de uma tabela. Além disso, as estatísticas em nível de coluna que o Delta Lake usa para executar a omissão de dados são armazenadas no ponto de verificação.

important

Delta Lake são diferentes dos pontos de controle da transmissão estruturada. Veja os pontos de controle de transmissão estruturada.

As estatísticas no nível da coluna são armazenadas como um struct e um JSON (para compatibilidade com versões anteriores). O formato struct torna as leituras do Delta Lake muito mais rápidas, porque:

  • Delta Lake não executa análise JSON cara para obter estatísticas em nível de coluna.
  • Os recursos de remoção da coluna Parquet reduzem significativamente a E/S necessária para ler as estatísticas de uma coluna.

O formato struct possibilita uma série de otimizações que reduzem a sobrecarga das operações de leitura do Delta Lake de segundos para dezenas de milissegundos, o que diminui significativamente a latência para consultas rápidas.

gerenciar estatísticas em nível de coluna em pontos de controle​

Você gerencia como as estatísticas são gravadas nos pontos de verificação usando as propriedades da tabela delta.checkpoint.writeStatsAsJson e delta.checkpoint.writeStatsAsStruct. Se ambas as propriedades da tabela forem false, Delta Lake não poderá ignorar dados.

  • As gravações em lote registram estatísticas em ambos os formatos JSON e struct.delta.checkpoint.writeStatsAsJson é true.
  • delta.checkpoint.writeStatsAsStruct é indefinido por padrão.
  • Os leitores usam a coluna struct quando disponível e, caso contrário, voltam a usar a coluna JSON.
important

Pontos de verificação aprimorados não quebram a compatibilidade com leitores Delta Lake de código aberto. No entanto, falsedefinir delta.checkpoint.writeStatsAsJson como false pode ter implicações em leitores exclusivos do Delta Lake.Entre em contato com seus fornecedores para saber mais sobre as implicações de desempenho.

Ativar pontos de verificação aprimorados para consultas de transmissão estruturada​

Se suas cargas de trabalho de transmissão estruturada não tiverem requisitos de baixa latência (latências de subminuto), você poderá habilitar pontos de verificação aprimorados executando o seguinte comando SQL:

SQL
ALTER TABLE <table-name> SET TBLPROPERTIES
('delta.checkpoint.writeStatsAsStruct' = 'true')

Você também pode melhorar a latência de gravação do ponto de verificação configurando as seguintes propriedades da tabela:

SQL
ALTER TABLE <table-name> SET TBLPROPERTIES
(
 'delta.checkpoint.writeStatsAsStruct' = 'true',
 'delta.checkpoint.writeStatsAsJson' = 'false'
)

Se a omissão de dados não for útil em seu aplicativo, você pode definir ambas as propriedades como falso. Então, nenhuma estatística é coletada ou escrita. A Databricks não recomenda essa configuração.

Última atualização em