Pular para o conteúdo principal

Tabelas de transmissão

Uma tabela de transmissão é uma tabela Delta com suporte extra para transmissão ou processamento incremental de dados. Uma tabela de transmissão pode ser alvo de um ou mais fluxos em um pipeline.

Para obter orientações sobre quando usar tabelas de transmissão em vez de views ou views materializadas, consulte O que são pipelines?.

Tabelas de transmissão são uma boa escolha para ingestão de dados pelos seguintes motivos:

  • Cada linha de entrada é processada apenas uma vez, o que representa a grande maioria das cargas de trabalho de ingestão (ou seja, adicionando ou inserindo linhas em uma tabela).
  • Eles podem lidar com grandes volumes de dados somente anexados.

Tabelas de transmissão também são uma boa opção para transformações de transmissão de baixa latência, porque elas podem processar linhas e janelas de tempo, lidar com grandes volumes de dados e proporcionar processamento de baixa latência.

O diagrama a seguir mostra como os fluxos leem de fontes de transmissão e gravam gradualmente em uma tabela de transmissão dentro de um pipeline.

Diagrama que mostra fontes de transmissão S3, Kafka e Pub/Sub, conectadas por fluxos individuais que leem novos dados em um pipeline que contém uma tabela de transmissão.

A cada atualização, os fluxos associados a uma tabela de transmissão leem as informações alteradas em uma fonte de transmissão e adicionam novas informações a essa tabela.

Tabelas de transmissão são gerenciadas e atualizadas por um único pipeline. Define-se explicitamente tabelas de transmissão no código-fonte do pipeline. Tabelas definidas por um pipeline não podem ser alteradas ou atualizadas por qualquer outro pipeline. É possível definir vários fluxos para acrescentar a uma única tabela de transmissão.

A Databricks cria tabelas internas para suportar o processamento de tabelas de transmissão. Essas tabelas aparecem em system.information_schema.tables, mas não estão visíveis no Catalog Explorer ou em outras páginas da interface do usuário do workspace.

nota

Ao criar uma tabela de transmissão independente, fora dos Pipelines Declarativos do Lakeflow Spark, o Databricks cria um pipeline que é usado para atualizar a tabela. Você pode visualizar o pipeline selecionando "Jobs & Pipelines" na navegação à esquerda do seu workspace. Você pode adicionar a coluna Tipo de Pipeline à sua view. As tabelas de transmissão definidas em um pipeline têm um tipo de ETL. As tabelas de transmissão independentes têm um tipo de MV/ST.

Para obter mais informações sobre fluxos, consulte Carregue e processe dados gradualmente com os fluxos do Lakeflow Spark Declarative Pipelines.

Tabelas de transmissão para ingestão

Tabelas de transmissão são projetadas para fontes de dados somente de acréscimo e processam entradas apenas uma vez. Isso os torna ideais para cargas de trabalho de ingestão onde os dados chegam continuamente e devem ser capturados de forma confiável sem reprocessar registros existentes. A Databricks oferece suporte para ingestão em tabelas de transmissão a partir do armazenamento de objetos na cloud (usando o Auto Loader) e de barramentos de mensagens de transmissão como Apache Kafka, Azure Event Hubs e Google Pub/Sub. Para obter instruções passo a passo e exemplos de código de ingestão, consulte Carregar dados em pipelines.

nota

Para transmitir dados de origem que mudam com o tempo — por exemplo, registros que são atualizados ou excluídos na origem — use AUTO CDC para aplicar essas alterações a uma tabela de transmissão em vez de anexá-las. Consulte captura de dados de alterações (CDC) e Snapshot.

O diagrama a seguir ilustra como as tabelas de transmissão somente de anexo funcionam.

Diagrama que mostra como funcionam os fluxos somente de acréscimo

Uma linha que já foi adicionada a uma tabela de transmissão não será consultada novamente em atualizações posteriores do pipeline. Se você modificar a consulta (por exemplo, de SELECT LOWER (name) para SELECT UPPER (name)), as linhas existentes não serão atualizadas para maiúsculas, mas as novas linhas serão. Você pode acionar um refresh completo para buscar novamente todos os dados anteriores da tabela de origem e atualizar todas as linhas na tabela de streaming.

Tabelas de transmissão e transmissão de baixa latência

As tabelas de transmissão são projetadas para transmissão de baixa latência sobre estado limitado. As tabelas de transmissão utilizam o gerenciamento de pontos de verificação, o que as torna bem adequadas para transmissão de baixa latência. No entanto, eles esperam transmissões que sejam naturalmente delimitadas ou delimitadas por uma marca d'água.

Uma transmissão naturalmente limitada é produzido por uma fonte de dados de transmissão que tem um começar e um fim bem definidos. Um exemplo de transmissão naturalmente limitada é a leitura de dados de um diretório de arquivos onde nenhum novo arquivo está sendo adicionado após um lote inicial de arquivos ser inserido. A transmissão é considerada limitada porque o número de arquivos é finito, e a transmissão termina depois que todos os arquivos tiverem sido processados.

Você também pode usar uma marca d'água para delimitar uma transmissão. Uma marca d'água na transmissão estructurada é um mecanismo que ajuda a lidar com dados atrasados ao especificar quanto tempo o sistema deve esperar por eventos atrasados antes de considerar a janela de tempo como concluída. Uma transmissão ilimitada que não tem uma marca d'água pode causar falha no pipeline devido à pressão da memória.

Para cargas de trabalho operacionais que exigem a menor latência possível, você pode executar o pipeline no modo em tempo real para processar registros com latência de ponta a ponta em subssegundos.

Para saber mais, consulte:

Limitações da tabela de transmissão

Tabelas de transmissão têm as seguintes limitações:

  • Evolução limitada: É possível alterar a query sem recalcular o dataset inteiro. Sem um refresh completo, uma tabela de transmissão vê cada linha apenas uma vez, portanto, consultas diferentes terão processado linhas diferentes. Por exemplo, ao adicionar UPPER() a um campo na consulta, apenas as linhas processadas após a alteração estarão em maiúsculas. Isso significa que é preciso estar ciente de todas as versões anteriores da consulta que estão sendo executadas no seu dataset. Para reprocessar linhas existentes que foram processadas antes da alteração, um refresh completo é necessário.
  • Gerenciamento de estado: tabelas de transmissão têm baixa latência e exigem transmissões que sejam naturalmente limitadas ou limitadas por uma marca d'água. Para obter mais informações, consulte Otimize o processamento com estado com marcas d'água.
  • **Junções não recalculam:** As junções em tabelas de transmissão não recalculam quando as dimensões mudam. Essa característica pode ser boa para cenários de "rápido, mas incorreto". Se sua visualização precisar estar sempre correta, talvez seja interessante utilizar uma visualização materializada. Visualizações materializadas são sempre corretas porque elas recalculam automaticamente os joins quando as dimensões mudam. Para obter mais informações, consulte view materializadas. Para um exemplo de join de uma transmissão a uma tabela de dimensão estática, veja Joins de fluxo estático.
  • Sem CLONE suporte para: Tabelas de transmissão não podem ser usadas como fonte ou destino de um clone profundo ou raso. Para outros comandos sem suporte, consulte Limitações.

Recursos adicionais