Share via


Geavanceerde AUTO CDC-onderwerpen

Deze pagina bevat geavanceerde onderwerpen voor het werken met AUTO CDC en AUTO CDC FROM SNAPSHOT doeltabellen, waaronder DML-bewerkingen, het lezen van wijzigingengegevensfeeds en het bewaken van metrische gegevens voor verwerking. Zie AUTO CDC.

Gegevens toevoegen, wijzigen of verwijderen in een doelstreamingtabel

Als uw pijplijn tabellen publiceert naar Unity Catalog, kunt u DML-instructies ( Data Manipulat Language ) gebruiken, zoals invoeg-, update-, verwijder- en samenvoeginstructies om de doelstreamingtabellen te wijzigen die zijn gemaakt door AUTO CDC ... INTO instructies.

Opmerking

  • DML-instructies die het tabelschema van een streamingtabel wijzigen, worden niet ondersteund. Zorg ervoor dat uw DML-instructies niet proberen het tabelschema te ontwikkelen.
  • DML-instructies die een streamingtabel bijwerken, kunnen alleen worden uitgevoerd in een gedeeld Unity Catalog-cluster of een SQL-warehouse met Databricks Runtime 13.3 LTS en hoger.
  • Omdat streaming uitsluitend gegevensbronnen die alleen toevoegen vereist, stelt u bij het lezen van de bronstreamingtabel de vlag SkipChangeCommits in, als er gestreamd moet worden vanuit een streamingtabel met wijzigingen (bijvoorbeeld door DML-instructies). Wanneer skipChangeCommits is ingesteld, worden transacties die records in de brontabel verwijderen of wijzigen genegeerd. Als voor uw verwerking geen streamingtabel is vereist, kunt u een gerealiseerde weergave (die niet beschikt over de beperking voor alleen toevoegen) gebruiken als doeltabel.

Omdat declaratieve pijplijnen van Lakeflow Spark een opgegeven SEQUENCE BY kolom gebruiken en de juiste volgordewaarden doorgeven aan de __START_AT en __END_AT kolommen van de doeltabel (voor SCD-type 2), moet u ervoor zorgen dat DML-instructies geldige waarden voor deze kolommen gebruiken om de juiste volgorde van records te behouden. Zie Hoe AUTO CDC werkt.

Zie Gegevens toevoegen, wijzigen of verwijderen in een streamingtabel voor meer informatie over het gebruik van DML-instructies met streamingtabellen.

In het volgende voorbeeld wordt een actieve record ingevoegd met een beginvolgorde van 5:

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

Aanbeveling

Als u de __START_AT en __END_AT kolommen in uw SCD Type 2-doeltabel moet hernoemen (bijvoorbeeld om aan de vereisten van downstreamschemas te voldoen), maakt u een weergave over de doeltabel:

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

Een wijzigingsgegevensstroom lezen uit een AUTO CDC-doeltabel

In Databricks Runtime 15.2 en hoger kunt u een gegevensfeed voor wijzigingen lezen uit een streamingtabel die het doel is van AUTO CDC of AUTO CDC FROM SNAPSHOT query's op dezelfde manier als u een gegevensfeed van andere Delta-tabellen leest. Het volgende is vereist om de wijzigingsgegevensfeed te kunnen lezen uit een streamingdoeltabel.

  • De doelstreamingtabel moet worden gepubliceerd naar Unity Catalog. Zie Unity Catalog gebruiken met pijplijnen.
  • Als u de wijzigingengegevensfeed wilt lezen uit de doelstreamingtabel, moet u Databricks Runtime 15.2 of hoger gebruiken. Als u de wijzigingengegevensfeed in een andere pijplijn wilt lezen, moet de pijplijn zijn geconfigureerd voor het gebruik van Databricks Runtime 15.2 of hoger.

U leest de wijzigingengegevensfeed uit een doelstreamingtabel die is gemaakt in Lakeflow Spark-declaratieve pijplijnen op dezelfde manier als het lezen van een wijzigingengegevensfeed uit andere Delta-tabellen. Voor meer informatie over het gebruik van de Delta-wijzigingsgegevensfeed-functionaliteit, waaronder voorbeelden in Python en SQL, zie Lake-wijzigingsgegevensfeeds gebruiken in Azure Databricks.

Opmerking

De record voor de wijzigingengegevensfeed bevat metagegevens waarmee het type wijzigingsevenement wordt geïdentificeerd. Wanneer een record in een tabel wordt bijgewerkt, bevatten de metagegevens voor de gekoppelde wijzigingsrecords doorgaans _change_type waarden die zijn ingesteld op update_preimage en update_postimage gebeurtenissen.

De _change_type waarden verschillen echter als er updates worden aangebracht in de doelstreamingtabel, waaronder het wijzigen van primaire-sleutelwaarden. Wanneer wijzigingen updates voor primaire sleutels bevatten, worden de _change_type metagegevensvelden ingesteld op insert en delete gebeurtenissen. Wijzigingen in primaire sleutels kunnen optreden wanneer handmatige updates worden aangebracht in een van de sleutelvelden met een instructie UPDATE of MERGE, of, voor SCD-type 2-tabellen, wanneer het __start_at-veld wordt gewijzigd om een eerdere beginvolgordewaarde te weerspiegelen.

De AUTO CDC query bepaalt de primaire-sleutelwaarden, die verschillen voor SCD-type 1- en SCD-type 2-verwerking:

SCD Type Primaire sleutel
SCD-type 1 en de Python-interface voor pijplijnen De primaire sleutel is de waarde van de keys parameter in de create_auto_cdc_flow() functie. Voor de SQL-interface is de primaire sleutel de kolommen die zijn gedefinieerd door de KEYS component in de AUTO CDC ... INTO instructie.
SCD-type 2 De primaire sleutel is de keys parameter of KEYS component plus de retourwaarde van de coalesce(__START_AT, __END_AT) bewerking, waarbij __START_AT en __END_AT de bijbehorende kolommen uit de doelstreamingtabel zijn.

Verkrijg gegevens over records die door een CDC-query in pijplijnen worden verwerkt

Opmerking

De volgende metrische gegevens worden alleen vastgelegd door AUTO CDC query's en niet door AUTO CDC FROM SNAPSHOT query's.

De volgende metrische gegevens worden vastgelegd door AUTO CDC query's:

  • num_upserted_rows: Het aantal uitvoerrijen dat tijdens een update in de gegevensset is geüpsert.
  • num_deleted_rows: Het aantal bestaande uitvoerrijen dat tijdens een update uit de gegevensset is verwijderd.

De num_output_rows metrieke, output voor niet-CDC-flows, wordt niet vastgelegd voor AUTO CDC queries.

Welke gegevensobjecten worden gebruikt voor CDC-verwerking in een pijplijn?

Wanneer u de doeltabel in de Hive-metastore opgeeft, worden er twee gegevensstructuren aangemaakt.

  • Een weergave met de naam die is toegewezen aan de doeltabel.
  • Een interne back-uptabel die door de pijplijn wordt gebruikt voor het beheren van CDC-verwerking. De naam van deze tabel wordt gevormd door __apply_changes_storage_ voor de naam van de doeltabel te plaatsen.

Als u bijvoorbeeld een doeltabel met de naam dp_cdc_targetdeclareert, ziet u een weergave met de naam dp_cdc_target en een tabel met de naam __apply_changes_storage_dp_cdc_target in de metastore. Query's uitvoeren op de weergave om toegang te krijgen tot de verwerkte gegevens. Wijzig de backingtabel niet rechtstreeks.

Opmerking

Deze gegevensstructuren zijn alleen van toepassing op AUTO CDC verwerking, niet op AUTO CDC FROM SNAPSHOT verwerking. Ze zijn ook alleen van toepassing op Hive-metastore, niet op Unity Catalog.