LIVE-schema (äldre)

Den här artikeln innehåller en översikt över den äldre syntaxen och beteendet för det LIVE virtuella schemat.

Det LIVE virtuella schemat är en äldre funktion i DLT-pipelines och anses vara inaktuell. Du kan fortfarande använda äldre publiceringsläge och det virtuella schemat LIVE för pipelines som skapades i detta läge.

Stöd för äldre LIVE virtuellt schema och äldre publiceringsläge tas bort i en framtida version av Azure Databricks.

Notera

Pipelines för äldre publiceringsläge anges i fältet Sammanfattning i användargränssnittet för DLT-pipelineinställningar. Du kan också bekräfta att en pipeline använder äldre publiceringsläge om fältet target anges i JSON-specifikationen för pipelinen.

Du kan inte använda pipelinekonfigurationsgränssnittet för att skapa nya pipelines med det äldre publiceringsläget. Om du behöver distribuera nya pipelines med hjälp av äldre LIVE syntax kontaktar du din Databricks-kontorepresentant.

Vad är det virtuella LIVE-schemat?

Not

Det LIVE virtuella schemat behövs inte längre för att analysera datamängdsberoende i standardpubliceringsläget för DLT.

Schemat LIVE är ett programmeringskoncept i DLT som definierar en virtuell gräns för alla datauppsättningar som skapats eller uppdaterats i en pipeline. Schema LIVE är avsiktligen inte direkt kopplat till dataset i ett publicerat schema. I stället tillåter LIVE-schemat att logik i en pipeline planeras och köras även om en användare inte vill publicera datauppsättningar i ett schema.

I pipelines för äldre publiceringsläge kan du använda nyckelordet LIVE för att referera till andra datasamlingar i den aktuella pipelinen vid läsning, till exempel SELECT * FROM LIVE.bronze_table. I standardpubliceringsläget för nya DLT-pipelines ignoreras den här syntaxen tyst, vilket innebär att okvalificerade identifierare använder det aktuella schemat. Se Ange målkatalogen och schemat.

äldre publiceringsläge för pipelines

Det LIVE virtuella schemat används med det äldre publiceringsläget för DLT-pipelines. Alla tabeller som skapats före den 5 februari 2025 använder äldre publiceringsläge som standard.

I följande tabell beskrivs beteendet för alla materialiserade vyer och strömmande tabeller som skapats eller uppdaterats i en pipeline i det äldre publiceringsläget:

Lagringsalternativ	Lagringsplats eller katalog	Målschema	Uppförande
Hive-metaarkiv	Inget angett	Inte specificerat	Datauppsättningsmetadata och data lagras i DBFS-roten. Inga databasobjekt registreras i Hive-metaarkivet.
Hive-metaarkiv	En URI eller filsökväg till molnobjektlagring.	Inget angivet	Metadata för datauppsättningar och data lagras på den angivna lagringsplatsen. Inga databasobjekt registreras i Hive-metaarkivet.
Hive-metadatalager	Inget specificerat	Ett befintligt eller nytt schema i Hive-metaarkivet.	Datauppsättningsmetadata och data lagras i DBFS-roten. Alla materialiserade vyer och strömmande tabeller i pipelinen publiceras till det angivna schemat i Hive-metaarkivet.
Hive-metadataförråd	En URI eller filsökväg till molnobjektlagring.	Ett befintligt eller nytt schema i Hive-metaarkivet.	Datauppsättningsmetadata och data lagras på den angivna lagringsplatsen. Alla materialiserade vyer och strömmande tabeller i pipelinen publiceras till det angivna schemat i Hive-metaarkivet.
Unity-katalog	En befintlig Unity-katalogkatalog.	Ingen specificerat	Datauppsättningsmetadata och data lagras på den standardlagringsplats som är associerad med målkatalogen. Inga databasobjekt har registrerats i Unity-katalogen.
Unity-katalog	En befintlig Unity Catalog-katalog.	Ett befintligt eller nytt schema i Unity Catalog.	Datauppsättningsmetadata och data lagras på den standardlagringsplats som är associerad med målschemat eller katalogen. Alla materialiserade vyer och strömmande tabeller i pipelinen publiceras till det angivna schemat i Unity Catalog.

Uppdatera källkoden från LIVE-schemat

Pipelines som konfigurerats för att köras med det nya standardpubliceringsläget ignorerar tyst LIVE schemasyntax. Som standard använder alla tabellläsningar den katalog och det schema som anges i pipelinekonfigurationen.

För de flesta befintliga pipelines har den här beteendeändringen ingen inverkan, eftersom det äldre LIVE virtuella schemabeteendet även dirigerar läsningar till katalogen och schemat som anges i pipelinekonfigurationen.

Viktig

Äldre kod med läsningar som utnyttjar arbetsytans standardkatalog och schema kräver koduppdateringar. Överväg följande materialiserade vydefinition:

CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM raw_data

I äldre publiceringsläge använder en okvalificerad läsning från raw_data-tabellen arbetsytans standardkatalog och schema, till exempel main.default.raw_data. I det nya standardpipelineläget är katalogen och schemat som används som standard de som konfigurerats i pipelinekonfigurationen. För att säkerställa att den här koden fortsätter att fungera som förväntat uppdaterar du referensen för att använda den fullständigt kvalificerade identifieraren för tabellen, som i följande exempel:

CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM main.default.raw_data

Arbeta med händelseloggen för pipelines för äldre publiceringslägen i Unity Catalog

Viktig

event_log TVF är tillgänglig för pipelines i äldre publiceringsläge som publicerar tabeller till Unity Catalog. Standardbeteendet för nya pipelines publicerar händelseloggen till målkatalogen och schemat som konfigurerats för pipelinen. Se Granska händelseloggen.

Tabeller som konfigurerats med Hive-metaarkivet har också olika stöd och beteende för händelseloggar. Se Arbeta med händelseloggen för Hive-metaarkivpipelines.

Om din pipeline publicerar tabeller till Unity Catalog med äldre publiceringsläge måste du använda funktionen event_logtabellvärde (TVF) för att hämta händelseloggen för pipelinen. Du hämtar händelseloggen för en pipeline genom att skicka pipeline-ID:t eller ett tabellnamn till TVF:n. Om du till exempel vill hämta händelseloggposterna för pipelinen med ID 04c78631-3dd7-4856-b2a6-7d84e9b2638b:

SELECT * FROM event_log("04c78631-3dd7-4856-b2a6-7d84e9b2638b")

Så här hämtar du händelseloggposterna för pipelinen som skapade eller äger tabellen my_catalog.my_schema.table1:

SELECT * FROM event_log(TABLE(my_catalog.my_schema.table1))

Om du vill anropa TVF måste du använda ett delat kluster eller ett SQL-lager. Du kan till exempel använda en notebook-fil som är kopplad till ett delat kluster eller använda SQL-redigeraren ansluten till ett SQL-lager.

För att förenkla frågehändelser för en pipeline kan pipelinens ägare skapa en vy över event_log TVF. I följande exempel skapas en vy över händelseloggen för en pipeline. Den här vyn används i exempelfrågorna i händelseloggen som ingår i den här artikeln.

Not

• event_log TVF kan bara anropas av pipelineägaren.
• Du kan inte använda funktionen med tabellvärde event_log i en rörledning eller fråga för att komma åt händelseloggarna för flera rörledningar.
• Du kan inte dela en vy som skapats över funktionen event_log tabellvärde med andra användare.

CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");

Ersätt <pipeline-ID> med den unika identifieraren för DLT-pipelinen. Du hittar ID:t i Pipeline-detaljer-panelen i DLT-användargränssnittet.

Varje instans av en pipelinekörning kallas för en uppdatering. Du vill ofta extrahera information för den senaste uppdateringen. Kör följande fråga för att hitta identifieraren för den senaste uppdateringen och spara den i den latest_update_id tillfälliga vyn. Den här vyn används i exempelfrågorna i händelseloggen som ingår i den här artikeln:

CREATE OR REPLACE TEMP VIEW latest_update AS SELECT origin.update_id AS id FROM event_log_raw WHERE event_type = 'create_update' ORDER BY timestamp DESC LIMIT 1;