Pular para o conteúdo principal
Última atualização em

Tópicos avançados do AUTO CDC

Esta página aborda tópicos avançados para trabalhar com tabelas de destino AUTO CDC e AUTO CDC FROM SNAPSHOT , incluindo operações DML, leitura de feeds de dados de alterações e monitoramento de métricas de processamento. Para obter uma introdução às APIs AUTO CDC , consulte APIs AUTO CDC : Simplifique a captura de dados de alterações (CDC) com pipeline.

Adicionar, alterar ou excluir dados em uma tabela de transmissão de destino.​

Se o seu pipeline publicar tabelas no Unity Catalog, você poderá usar instruções de linguagem de manipulação de dados (DML), incluindo instruções insert, update, delete e merge , para modificar as tabelas de transmissão de destino criadas pelas instruções AUTO CDC ... INTO .

nota
  • As declarações DML que modificam o esquema de tabela de uma tabela de streaming não são suportadas. Certifique-se de que suas instruções DML não tentem evoluir o esquema da tabela.
  • Instruções DML que atualizam uma tabela de transmissão só podem ser executadas em um cluster Unity Catalog compartilhado ou em um SQL warehouse usando Databricks Runtime 13.3 LTS ou superior.
  • Como a transmissão requer uma fonte de dados somente para anexação, se o seu processamento exigir transmissão de uma tabela de transmissão de origem com alterações (por exemplo, por meio de instruções DML), defina o sinalizador skipChangeCommits ao ler a tabela de transmissão de origem. Quando skipChangeCommits está definido, as transações que excluem ou modificam registros na tabela de origem são ignoradas. Se o seu processamento não exigir uma tabela de transmissão, você pode usar uma view materializada (que não possui a restrição de somente acréscimo) como tabela de destino.

Como o pipeline LakeFlow Spark Declarative usa uma coluna SEQUENCE BY especificada e propaga os valores de sequenciamento apropriados para as colunas __START_AT e __END_AT da tabela de destino (para SCD Tipo 2), você deve garantir que as instruções DML usem valores válidos para essas colunas para manter a ordem correta dos registros. Veja como funciona o AUTO CDC.

Para obter mais informações sobre o uso de instruções DML com tabelas de transmissão, consulte Adicionar, alterar ou excluir dados em uma tabela de transmissão.

O exemplo seguinte insere um registro ativo com uma sequência inicial de 5:

SQL
INSERT INTO my_streaming_table (id, name, __START_AT, __END_AT) VALUES (123, 'John Doe', 5, NULL);
dica

Se você precisar renomear as colunas __START_AT e __END_AT na sua tabela de destino SCD Tipo 2 (por exemplo, para corresponder aos requisitos do esquema subsequente), crie uma view sobre a tabela de destino:

SQL
CREATE VIEW my_employees_view AS
SELECT
  *,
  __START_AT AS valid_from,
  __END_AT AS valid_to
FROM my_scd2_target_table;

Leia um feed de dados de alterações de uma tabela de metas AUTO CDC.​

No Databricks Runtime 15.2 e versões superiores, você pode ler um feed de dados de alteração de uma tabela de transmissão que é o alvo de consultas AUTO CDC ou AUTO CDC FROM SNAPSHOT da mesma forma que você lê um feed de dados de alteração de outras tabelas Delta . Os seguintes itens são necessários para ler o fluxo de dados de alterações de uma tabela de transmissão de destino:

  • A tabela de transmissão de destino deve ser publicada no Unity Catalog. Consulte Usar Unity Catalog com o pipeline.
  • Para ler o fluxo de dados de alterações da tabela de transmissão de destino, você precisa usar Databricks Runtime 15.2 ou superior. Para ler o fluxo de dados de alterações em um pipeline diferente, o pipeline deve ser configurado para usar Databricks Runtime 15.2 ou superior.

Você lê o fluxo de dados de alterações de uma tabela de transmissão de destino criada no pipeline declarativo LakeFlow Spark da mesma forma que lê um fluxo de dados de alterações de outras tabelas Delta . Para saber mais sobre como usar a funcionalidade de feed de dados de alterações do Delta, incluindo exemplos em Python e SQL, consulte Usar o feed de dados de alterações do Delta Lake no Databricks.

nota

O registro do feed de dados de alteração inclui metadados que identificam o tipo de evento de alteração. Quando um registro é atualizado em uma tabela, os metadados para os registros de alteração associados normalmente incluem valores _change_type definidos para eventos update_preimage e update_postimage .

No entanto, os valores _change_type são diferentes se forem feitas atualizações na tabela de transmissão de destino que incluam a alteração dos valores key primária. Quando as alterações incluem atualizações na chave primária, os campos de metadados _change_type são definidos para os eventos insert e delete . As alterações na chave primária podem ocorrer quando atualizações manuais são feitas em um dos campos key com uma instrução UPDATE ou MERGE ou, para tabelas SCD tipo 2, quando o campo __start_at muda para refletir um valor de sequência de início anterior.

A consulta AUTO CDC determina os valores key primária, que diferem para o processamento SCD tipo 1 e SCD tipo 2:

SCD Type

Primary key

SCD type 1, and the pipelines Python interface

The primary key is the value of the keys parameter in the create_auto_cdc_flow() function. For the SQL interface the primary key is the columns defined by the KEYS clause in the AUTO CDC ... INTO statement.

SCD type 2

The primary key is the keys parameter or KEYS clause plus the return value from the coalesce(__START_AT, __END_AT) operation, where __START_AT and __END_AT are the corresponding columns from the target streaming table.

Obtenha dados sobre registros processados por uma consulta CDC em andamento.​

nota

As seguintes métricas são capturadas apenas por consultas AUTO CDC e não por consultas AUTO CDC FROM SNAPSHOT .

As seguintes métricas são capturadas por consultas AUTO CDC :

  • num_upserted_rows : O número de linhas de saída inseridas no dataset durante uma atualização.
  • num_deleted_rows : O número de linhas de saída existentes excluídas do dataset durante uma atualização.

As métricas num_output_rows , saída para fluxos não-CDC, não são capturadas para consultas AUTO CDC .

Quais objetos de dados são usados para o processamento do CDC em um pipeline?​

Quando você declara a tabela de destino no Hive metastore, são criadas duas estruturas de dados:

  • Uma visualização usando o nome atribuído à tabela de destino.
  • Uma tabela de suporte interna usada pelo pipeline para gerenciar o processamento do CDC. Esta tabela é nomeada adicionando __apply_changes_storage_ antes do nome da tabela de destino.

Por exemplo, se você declarar uma tabela de destino chamada dp_cdc_target, você verá uma view chamada dp_cdc_target e uma tabela chamada __apply_changes_storage_dp_cdc_target no metastore. Consulte a view para acessar os dados processados. Não modifique a tabela de suporte diretamente.

nota

Essas estruturas de dados se aplicam apenas ao processamento AUTO CDC , não ao processamento AUTO CDC FROM SNAPSHOT . Elas também se aplicam somente ao Hive metastore, não Unity Catalog.