tabelas de transmissão

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

As tabelas de transmissão são uma boa opção para a ingestão de dados pelos seguintes motivos:

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

As tabelas de transmissão também são uma boa opção para transformações de transmissão de baixa latência pelos seguintes motivos:

• Razão sobre linhas e janelas de tempo
• Lide com grandes volumes de dados
• Baixa latência

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

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

As tabelas de transmissão são definidas e atualizadas por um único site DLT pipeline. Ao criar um DLT pipeline, o senhor define explicitamente as tabelas de transmissão no código-fonte do pipeline. As tabelas definidas por um pipeline não podem ser alteradas ou atualizadas por nenhum outro pipeline. O senhor pode definir vários fluxos para anexar a uma única tabela de transmissão.

Quando o senhor cria uma tabela de transmissão fora de um pipeline em Databricks SQL, Databricks cria um DLT pipeline oculto que é usado para atualizar essa tabela.

Para obter mais informações sobre fluxos, consulte Carregar e processar dados de forma incremental com os fluxos do site DLT.

tabelas de transmissão para ingestão

As tabelas de transmissão são projetadas para fontes de dados apenas anexadas e processam entradas apenas uma vez.

O exemplo a seguir mostra como usar uma tabela de transmissão para ingerir novos arquivos do armazenamento em nuvem.

Python

Python

import dlt

# create a streaming table
@dlt.table
def customers_bronze():
  return (
    spark.readStream.format("cloudFiles")
     .option("cloudFiles.format", "json")
     .option("cloudFiles.inferColumnTypes", "true")
     .load("/Volumes/path/to/files")
  )

Quando o senhor usa a função spark.readStream em uma definição dataset, isso faz com que DLT trate o dataset como uma transmissão e a tabela criada é uma tabela de transmissão.

SQL

SQL

-- create a streaming table
CREATE OR REFRESH STREAMING TABLE customers_bronze
AS SELECT * FROM STREAM read_files(
  "/volumes/path/to/files",
  format => "json"
);

Para obter mais detalhes sobre o carregamento de dados na tabela de transmissão, consulte Carregar dados com DLT.

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

Uma linha que já tenha sido anexada a uma tabela de transmissão não será consultada novamente com atualizações posteriores no site 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 maiúsculas. O senhor pode acionar um refresh completo para consultar novamente todos os dados anteriores da tabela de origem para atualizar todas as linhas da tabela de transmissão.

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 em estados limitados. As tabelas de transmissão usam gerenciamento de pontos de verificação, o que as torna adequadas para transmissão de baixa latência. No entanto, eles esperam que a transmissão seja naturalmente limitada ou limitada por uma marca d'água.

Uma transmissão naturalmente limitada é produzida por uma fonte de transmissão de dados que tem um início e um fim bem definidos. Um exemplo de transmissão naturalmente limitada é a leitura de dados de um diretório de arquivos em que nenhum arquivo novo é adicionado após a colocação de um lote inicial de arquivos. A transmissão é considerada limitada porque o número de arquivos é finito e, portanto, a transmissão termina depois que todos os arquivos tiverem sido processados.

O senhor também pode usar uma marca d'água para vincular uma transmissão. Uma marca d'água em Spark transmissão estruturada é um mecanismo que ajuda a lidar com dados atrasados, especificando quanto tempo o sistema deve esperar por eventos atrasados antes de considerar a janela de tempo como completa. Uma transmissão sem limites que não tenha uma marca d'água pode fazer com que o site DLT pipeline falhe devido à pressão da memória.

Para obter mais informações sobre o processamento de transmissão com estado, consulte Otimizar o processamento com estado em DLT com marcas d'água.

transmissão-Snapshot join

Transmissão-Snapshot join são uniões entre uma transmissão e uma dimensão que é instantânea quando a transmissão começa. Essas uniões não serão recomputadas se a dimensão for alterada após a transmissão ter começado, porque a tabela de dimensões é tratada como um Snapshot no tempo e as alterações na tabela de dimensões após a transmissão começar não serão refletidas, a menos que o senhor recarregue ou acesse refresh a tabela de dimensões. Esse comportamento é razoável se o senhor puder aceitar pequenas discrepâncias em um join. Por exemplo, um join aproximado é aceitável quando o número de transações é muitas ordens de magnitude maior do que o número de clientes.

No exemplo de código a seguir, join uma tabela de dimensão, clientes, com duas linhas com um número cada vez maior de dataset, transações. Materializamos um join entre esses dois conjuntos de dados em uma tabela chamada sales_report. Observe que, se um processo externo atualizar a tabela de clientes adicionando uma nova linha (customer_id=3, name=Zoya), essa nova linha NÃO estará presente no site join porque a tabela de dimensão estática foi capturada quando a transmissão foi iniciada.

Python

import dlt

@dlt.view
# assume this table contains an append-only stream of rows about transactions
# (customer_id=1, value=100)
# (customer_id=2, value=150)
# (customer_id=3, value=299)
# ... <and so on> ...
def v_transactions():
  return spark.readStream.table("transactions")

# assume this table contains only these two rows about customers
# (customer_id=1, name=Bilal)
# (customer_id=2, name=Olga)
@dlt.view
def v_customers():
  return spark.read.table("customers")

@dlt.table
def sales_report():
  facts = spark.readStream.table("v_transactions")
  dims = spark.read.table("v_customers")

  return (
    facts.join(dims, on="customer_id", how="inner"
  )

limitações da tabela de transmissão

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

• Evolução limitada: O senhor pode alterar a consulta sem recalcular todo o site dataset. Como uma tabela de transmissão só vê uma linha uma vez, o senhor pode ter diferentes consultas operando em diferentes linhas. Isso significa que o senhor deve estar ciente de todas as versões anteriores da consulta que estão em execução no seu site dataset. É necessário um refresh completo para que a tabela de transmissão atualize os dados que já foram processados.
• Gerenciamento de estado: as tabelas de transmissão são de baixa latência, portanto, o senhor precisa garantir que as transmissões sobre as quais elas operam sejam naturalmente limitadas ou limitadas com marca d'água. Para obter mais informações, consulte Otimizar o processamento com estado em DLT com marcas d'água.
• join don't recompute: a união em tabelas de transmissão não se recompõe quando as dimensões mudam. Essa característica pode ser boa para cenários “rápidos, mas errados”. Se o senhor quiser que o site view esteja sempre correto, talvez queira usar um site materializado view. As visualizações materializadas estão sempre corretas porque recompõem automaticamente a união quando as dimensões são alteradas. Para obter mais informações, consulte Materialized view.