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

Tópicos avançados do AUTO CDC

Além das APIs básicas AUTO CDC e AUTO CDC FROM SNAPSHOT, você pode executar DML em tabelas de destino, ler feeds de dados alterados de destinos CDC e monitorar métricas de processamento. Para uma introdução às AUTO CDC APIs, consulte As APIs AUTO CDC: Simplifique a captura de dados de alterações (CDC) com pipelines.

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.

É possível ler o feed de dados alterados de uma tabela de transmissão de destino que foi criada em LakeFlow Spark Declarative pipelines da mesma forma que a leitura de um feed de dados alterados de outras tabelas Delta. Para saber mais sobre como usar a funcionalidade de feed de dados de alteração do Delta, incluindo exemplos em Python e SQL, consulte Usar o feed de dados de alteração do Delta 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.

Nesta página