Lagra Postgres-ändringar i ett lakehouse

Note

Funktionen Ändra dataflöde i Lakebase finns i offentlig förhandsversion.

Konfigurera Lakebase Change Data Feed (CDF) i en Postgres-tabell och se sedan hur ändringar på radnivå visas i deltatabellen för mål.

Steg: ① Aktivera ändringsinsamling → ② Starta flödet → ③ Följ en rad in i lakehouse → ④ Ändra raden och se hur den flödar igenom

Note

Det här är en snabbstart. Fullständig dokumentation finns i Lakebase Change Data Feed.

Innan du börjar

  • Kontrollera att du har slutfört Hämta en Postgres-databas. Du behöver ett Lakebase-projekt med exempeltabellen playing_with_lakebase .
  • En katalog i Unity Catalog och ett schema där du har behörigheten CREATE TABLE.

Steg 1: Aktivera ändringsinsamling

Postgres behöver fullständiga raddata i loggen för att CDF ska fungera. Om du anger replikidentiteten till full uppmanas Postgres att registrera både det gamla och nya radtillståndet för varje ändring.

I SQL-redigeraren i Lakebase kör du:

ALTER TABLE playing_with_lakebase REPLICA IDENTITY FULL;

Läs mer: Ange replikidentitet för alla tabeller i ett schema och tillämpa den automatiskt på nya tabeller

Steg 2: Starta flödet

Lakebase CDF konfigureras på schemanivå. Varje aktuell och framtida tabell i källschemat inkluderas automatiskt, så du väljer inte enskilda tabeller.

Från produktionsgrenen öppnar du Översikt över grenen genom att klicka på grennamnet i den översta sökvägen, öppna fliken Lakebase CDF och klicka på Start. Välj public som källschema och välj sedan en unity catalog-målkatalog och ett schema. Den första ögonblicksbilden påbörjas omedelbart och lb_playing_with_lakebase_history visas som en Delta-tabell i måldestinationen.

Starta dialogrutan med val av källa och mål.

Läs mer: Starta ändringsdataflödet

Steg 3: Följ en rad in i sjöhuset

Välj en rad från Lakebase. Ta en titt på raden id=2:

SELECT * FROM playing_with_lakebase WHERE id = 2;

Leta nu upp samma rad i tabellen Deltahistorik. Växla till ett Databricks SQL-datalager eller en notebook och kör:

SELECT * FROM <catalog>.<schema>.lb_playing_with_lakebase_history
WHERE id = 2;

Ersätt <catalog> och <schema> med det mål som du valde i steg 2. Du ser rad id=2 med samma name och value som i Lakebase, plus extra kolumner. Den första ögonblicksbilden skrev varje befintlig rad till Delta som en insert händelse, vilket är vad den raden representerar.

Dessa extra kolumner beskriver vilken typ av händelse varje rad representerar (_pg_change_type), när det hände (_timestamp) och Postgres-beställningsinformationen (_pg_lsn, _pg_xid).

Läs mer: Måltabellschema | Datatypsmappning

Steg 4: Ändra rad, se hur ändringen slår igenom

Tillbaka i Lakebase SQL-redigeraren uppdaterar du raden id=2:

UPDATE playing_with_lakebase SET value = 55.5 WHERE id = 2;

Vänta några sekunder tills ändringen visas i feeden och fråga sedan historiktabellen igen:

SELECT id, value, _pg_change_type, _timestamp
FROM <catalog>.<schema>.lb_playing_with_lakebase_history
WHERE id = 2
ORDER BY _pg_lsn DESC;

Deltahistoriktabell som visar tre rader för id=2: update_preimage, update_postimage och infoga

Rad id=2 visas nu tre gånger: det ursprungliga insert, ett update_preimage med det gamla värdet och ett update_postimage med det nya värdet. Varje ändring av raden blir en ny historikrad, så du har alltid en fullständig spårningslogg. Borttagningar fungerar på samma sätt, genom att lägga till en rad med _pg_change_type = 'delete'.

Läs mer: Vanliga ändringsmönster | Skapa underordnade pipelines

Nästa steg

  • Last updated on