Tópicos Avançados do AUTO CDC

Esta página aborda tópicos avançados para trabalhar com AUTO CDC e AUTO CDC FROM SNAPSHOT tabelas de alvo, incluindo operações DML, leitura de feeds de dados de alterações e monitorização de métricas de processamento. Para uma introdução às AUTO CDC APIs, veja As APIs AUTO CDC: Simplificar a captura de dados de alterações com pipelines.

Adicionar, alterar ou excluir dados em uma tabela de streaming de destino

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

Observação

• Não há suporte para instruções DML que modificam o esquema de tabela de uma tabela de streaming. Certifique-se de que suas instruções DML não tentem evoluir o esquema da tabela.
• As instruções DML que atualizam uma tabela de streaming podem ser executadas somente em um cluster compartilhado do Catálogo Unity ou em um armazém SQL usando o Databricks Runtime 13.3 LTS e superior.
• Como o streaming requer fontes de dados que apenas permitem acréscimos, se o seu processamento exigir streaming a partir de uma tabela de streaming de origem com alterações (por exemplo, por instruções DML), defina o sinalizador skipChangeCommits ao ler a tabela de origem no streaming. Quando skipChangeCommits é definido, as transações que excluem ou modificam registros na tabela de origem são ignoradas. Se o processamento não exigir uma tabela de streaming, poderá usar uma vista materializada (que não tem a restrição de apenas acrescentar) como tabela de destino.

Como o Lakeflow Spark Declarative Pipelines utiliza uma coluna especificada SEQUENCE BY e propaga valores de sequenciação apropriados para as __START_AT colunas e __END_AT da tabela alvo (para SCD Tipo 2), deve garantir que as instruções DML usam valores válidos para estas colunas para manter a ordem correta dos registos. Veja como funciona o AUTO CDC.

Para obter mais informações sobre como usar instruções DML com tabelas de streaming, consulte Adicionar, alterar ou excluir dados em uma tabela de streaming.

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

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

Sugestão

Se precisar de renomear as colunas __START_AT e __END_AT na sua tabela de destino SCD Tipo 2 (por exemplo, para corresponder aos requisitos do esquema a jusante), crie uma visão sobre a tabela de destino.

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

Ler um fluxo de dados de alteração de uma tabela de destino do AUTO CDC

No Databricks Runtime 15.2 e superior, pode ler um fluxo de dados de alteração de uma tabela de fluxo contínuo que é o alvo de consultas AUTO CDC ou AUTO CDC FROM SNAPSHOT, da mesma forma que lê um fluxo de dados de alteração de outras tabelas Delta. Para ler a alimentação de dados de alteração de uma tabela de transmissão alvo, são necessários os seguintes requisitos:

• A tabela de streaming de destino deve ser publicada no Catálogo Unity. Consulte Utilizar o catálogo Unity com pipelines.
• Para ler o feed de dados de alteração da tabela de streaming de destino, você deve usar o Databricks Runtime 15.2 ou superior. Para ler o feed de dados de alteração num pipeline diferente, é necessário que o pipeline seja configurado para usar o Databricks Runtime 15.2 ou superior.

Você lê o feed de dados de alteração de uma tabela de streaming de destino que foi criada no Lakeflow Spark Declarative Pipelines da mesma forma que lê um feed de dados de alteração de outras tabelas Delta. Para saber mais sobre como usar a funcionalidade de feed de dados de alteração Delta, incluindo exemplos em Python e SQL, consulte Usar feed de dados de alteração Delta Lake no Azure Databricks.

Observação

O registro de feed de dados de alteração inclui metadados que identificam o tipo de evento de alteração. Quando um registo é atualizado numa tabela, os metadados dos registos de alterações associados geralmente incluem valores _change_type definidos como update_preimage e eventos update_postimage.

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

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

Tipo SCD	Chave primária
SCD tipo 1 e a interface Python para pipelines	A chave primária é o valor do keys parâmetro na create_auto_cdc_flow() função. Para a interface SQL, a chave primária são as colunas definidas pela KEYS cláusula na AUTO CDC ... INTO instrução.
SCD tipo 2	A chave primária é o keys parâmetro ou KEYS cláusula mais o valor de retorno da coalesce(__START_AT, __END_AT) operação, onde __START_AT e __END_AT são as colunas correspondentes da tabela de streaming de destino.

Obter dados sobre registos processados por uma consulta de CDC em pipelines

Observação

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

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

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

A métrica num_output_rows, resultado para fluxos não-CDC, não é capturada nas consultas AUTO CDC.

Quais objetos de dados são usados para processamento CDC num pipeline?

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

• Um modo de exibição usando o nome atribuído à tabela de destino.
• Uma tabela de suporte interna usada pelo pipeline para gerenciar o processamento CDC. Esta tabela é nomeada por preceder __apply_changes_storage_ o nome da tabela de destino.

Por exemplo, se declarar uma tabela alvo chamada dp_cdc_target, verá uma vista nomeada dp_cdc_target e uma tabela nomeada __apply_changes_storage_dp_cdc_target na metastore. Consulta a visualização para aceder aos dados processados. Não modifiquem diretamente a mesa de apoio.

Observação

Estas estruturas de dados aplicam-se apenas ao processamento AUTO CDC, e não ao processamento AUTO CDC FROM SNAPSHOT. Também se aplicam apenas à metastore Hive, não ao Catálogo Unity.