Pular para o conteúdo principal

Habilitar o acompanhamento da história (SCD type 2)

Aplica-se a : cheque marcado sim Criação de pipeline baseado em API

A configuração história acompanhamento, também conhecida como a configuração dimensões que mudam lentamente (SCD) (SCD), determina como lidar com as alterações nos dados ao longo do tempo. Desative o acompanhamento da história (SCD type 1) para sobrescrever registros desatualizados à medida que são atualizados e excluídos na fonte. Ative o acompanhamento do histórico (SCD type 2) para manter um histórico dessas alterações. A exclusão de uma tabela ou coluna na origem não exclui esses dados do destino, mesmo quando o SCD tipo 1 está selecionado.

Por exemplo, digamos que você ingere a tabela a seguir:

Exemplo de tabela de origem

Digamos também que a cor favorita de Alice mude para roxo em 2 de janeiro.

Se o acompanhamento da história estiver desativado (SCD type 1), a próxima execução da ingestão pipeline atualiza essa linha na tabela de destino.

Exemplo de SCD tipo 1

Se o acompanhamento da história estiver ativado (SCD type 2), a ingestão pipeline mantém a linha antiga e adiciona a atualização como uma nova linha. Ele marca a linha antiga como inativa para que você saiba qual linha está atualizada.

Exemplo de SCD tipo 2

Nem todos os conectores são compatíveis com SCD tipo 2. Para obter uma lista dos conectores compatíveis, consulte Compatibilidade de recurso.

Exemplo: Google analítica

O SCD tipo 2 é compatível com as tabelas users e pseudonymous_users usando last_updated_date como a coluna do cursor. Não há suporte para tabelas em nível de evento, que são somente para anexos.

Em default, o acompanhamento da história está desativado (SCD tipo 1). Você pode usar o exemplo de arquivo YAML a seguir para alterar essa configuração em um pacote:

YAML
resources:
pipelines:
pipeline_ga4:
name: <pipeline>
catalog: <destination-catalog>
schema: <destination-schema>
ingestion_definition:
connection_name: <connection>
objects:
- table:
source_url: <project-id>
source_schema: <property-name>
destination_catalog: <destination-catalog>
destination_schema: <destination-schema>
table_configuration:
scd_type: SCD_TYPE_2

Exemplo: SQL Server

A coluna de sequência que o senhor especifica na configuração do pipeline (por exemplo, last_updated, modified_at ou version_number) determina o intervalo de tempo em que cada versão de linha estava ativa (registrada nas colunas __START_AT e __END_AT na tabela de destino).

Os seguintes tipos de coluna sequence_by são suportados:

  • Carimbo de data/hora
  • Data
  • Integer
  • Long
  • String

Em default, o acompanhamento da história está desativado (SCD tipo 1). Para alterar essa configuração em um pacote, use o seguinte exemplo de arquivo YAML:

YAML
resources:
pipelines:
pipeline_sqlserver:
name: <pipeline>
catalog: <destination-catalog>
schema: <destination-schema>
ingestion_definition:
connection_name: <connection>
objects:
- table:
source_catalog: <source-catalog>
source_schema: <source-schema>
source_table: <source-table>
destination_catalog: <destination-catalog>
destination_schema: <destination-schema>
table_configuration:
scd_type: SCD_TYPE_2
sequence_by: <sequence-column>

Exemplo: Dia de trabalho

Em default, o acompanhamento da história está desativado (SCD tipo 1). O exemplo de YAML a seguir altera essa configuração usando Databricks ativo Bundles.

YAML
resources:
pipelines:
pipeline_workday:
name: <pipeline>
catalog: <destination-catalog>
schema: <destination-schema>
ingestion_definition:
connection_name: <connection>
objects:
- report:
source_url: <report-url>
destination_catalog: <destination-catalog>
destination_schema: <destination-schema>
table_configuration:
scd_type: SCD_TYPE_2

Limitações

A execução de um refresh completo substitui a tabela inteira. Isso remove todas as versões anteriores da linha. A nova história é rastreada a partir do ponto refresh.