Como funcionam as tabelas de transmissão

Uma tabela de transmissão é uma tabela Delta normal com suporte extra para transmissão ou processamento incremental de dados.

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.

As tabelas de transmissão são definidas e atualizadas por um único site Delta Live Tables pipeline. Ao criar um Delta Live Tables pipeline, o senhor pode definir explicitamente tabelas de transmissão no código-fonte do pipeline. Essas tabelas são então definidas por esse pipeline e não podem ser alteradas ou atualizadas por nenhum outro pipeline. Quando o senhor cria uma tabela de transmissão em Databricks SQL, Databricks cria uma Delta Live Tables pipeline que é usada para atualizar essa tabela.

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.

Full refresh faz com que as tabelas de transmissão reprocessem dados que já foram processados. A ação refresh completa faz com que uma tabela de transmissão reprocesse todas as entradas, inclusive as que já foram processadas anteriormente.

O exemplo a seguir mostra como usar uma tabela de transmissão para ingerir novos arquivos do armazenamento cloud. Quando o senhor usa uma ou mais invocações spark.readStream em uma definição dataset, isso faz com que o site Delta Live Tables trate o dataset como uma tabela de transmissão em vez de uma tabela materializada view.

import dlt

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

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

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 o site RocksDB para 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 novo arquivo é 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 Delta Live Tables pipeline falhe devido à pressão da memória.

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, pois a tabela de dimensão estática foi capturada quando a transmissão foi iniciada.

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 very_large_fact_table():
  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 small_dimension_table():
  return spark.read.table("customers")

@dlt.table
def stream_static_join():
  facts = spark.readStream.table("very_large_fact_table")
  dims = spark.read.table("small_dimension_table")

  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 vê uma linha apenas 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 veja os dados que foram vistos novamente.

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

• A união não se recompõe: Ao contrário da visualização materializada, cujos resultados estão sempre corretos porque se recompõem automaticamente, as uniões em tabelas de transmissão não se recompõem quando as dimensões mudam. Essa característica pode ser boa para cenários “rápidos, mas errados”.