Delen via

LIVE-schema (verouderd)

Dit artikel bevat een overzicht van de verouderde syntaxis en het gedrag voor het LIVE virtuele schema.

Het LIVE virtuele schema is een verouderde functie van Lakeflow Spark-declaratieve pijplijnen en wordt beschouwd als afgeschaft. U kunt nog steeds de verouderde publicatiemodus en het LIVE virtuele schema gebruiken voor pijplijnen die met deze modus zijn gemaakt.

Databricks raadt aan om alle pijplijnen te migreren naar de nieuwe publicatiemodus. U hebt twee opties voor migratie:

  • Verplaats tabellen (inclusief gerealiseerde weergaven en streamingtabellen) van een verouderde pijplijn naar een pijplijn die gebruikmaakt van de standaardpublicatiemodus. Zie Tabellen verplaatsen tussen pijplijnen voor meer informatie over het verplaatsen van tabellen tussen pijplijnen.
  • Schakel de standaardpublicatiemodus in in een pijplijn die momenteel gebruikmaakt van de verouderde publicatiemodus. Zie De standaardpublicatiemodus inschakelen in een pijplijn.

Beide methoden zijn eenrichtingsmigraties. U kunt tabellen niet terug migreren naar de verouderde modus.

Ondersteuning voor verouderde LIVE virtuele schema en verouderde publicatiemodus wordt verwijderd in een toekomstige versie van Azure Databricks.

Opmerking

Verouderde publicatiemoduspijplijnen worden aangegeven in het veld Samenvatting van de gebruikersinterface van de declaratieve pijplijnen van Lakeflow Spark. U kunt ook controleren of een pijplijn gebruikmaakt van de verouderde publicatiemodus als het veld target is ingesteld in de JSON-specificatie voor de pijplijn.

U kunt de gebruikersinterface voor pijplijnconfiguratie niet gebruiken om nieuwe pijplijnen te maken met de verouderde publicatiemodus. Als u nieuwe pijplijnen wilt implementeren met behulp van verouderde LIVE syntaxis, neemt u contact op met de vertegenwoordiger van uw Databricks-account.

Wat is het virtuele LIVE-schema?

Opmerking

Het LIVE virtuele schema is niet meer nodig om de afhankelijkheid van de gegevensset te analyseren in de standaardpublicatiemodus voor Lakeflow Spark-declaratieve pijplijnen.

Het LIVE schema is een programmeerconcept in Lakeflow Spark Declarative Pipelines waarmee een virtuele grens wordt gedefinieerd voor alle gegevenssets die in een pijplijn zijn gemaakt of bijgewerkt. Het LIVE schema is standaard niet rechtstreeks gekoppeld aan gegevenssets in een gepubliceerd schema. In plaats daarvan kan met het LIVE schema logica in een pijplijn worden gepland en uitgevoerd, zelfs als een gebruiker geen gegevenssets naar een schema wil publiceren.

In verouderde publicatiemoduspijplijnen kunt u het trefwoord LIVE gebruiken om te verwijzen naar andere gegevenssets in de huidige pijplijn voor leesbewerkingen, bijvoorbeeld SELECT * FROM LIVE.bronze_table. In de standaardpublicatiemodus voor nieuwe Lakeflow Spark-declaratieve pijplijnen wordt deze syntaxis op de achtergrond genegeerd, wat betekent dat niet-gekwalificeerde id's gebruikmaken van het huidige schema. Zie De doelcatalogus en het schema instellen.

verouderde publicatiemodus voor pijplijnen

Het LIVE virtuele schema wordt gebruikt met de verouderde publicatiemodus voor Lakeflow Spark-declaratieve pijplijnen. Alle tabellen die vóór 5 februari 2025 zijn gemaakt, gebruiken standaard de verouderde publicatiemodus.

In de volgende tabel wordt het gedrag beschreven voor alle gematerialiseerde views en streamingtabellen die zijn aangemaakt of bijgewerkt in een pijplijn in de klassieke publicatiemodus.

Opslagoptie Opslaglocatie of catalogus Doelschema Gedrag
Hive metastore Geen opgegeven Geen opgegeven Metagegevens en gegevens van gegevenssets worden opgeslagen in de DBFS-hoofdmap. Er zijn geen databaseobjecten geregistreerd bij de Hive-metastore.
Hive metastore Een URI of bestandspad naar de opslag van cloudobjecten. Geen opgegeven Metagegevens en gegevens van gegevenssets worden opgeslagen op de opgegeven opslaglocatie. Er zijn geen databaseobjecten geregistreerd bij de Hive-metastore.
Hive metastore Geen opgegeven Een bestaand of nieuw schema in de Hive-metastore. Metagegevens en gegevens van gegevenssets worden opgeslagen in de DBFS-hoofdmap. Alle gerealiseerde weergaven en streamingtabellen in de pijplijn worden gepubliceerd naar het opgegeven schema in de Hive Metastore.
Hive metastore Een URI of bestandspad naar de opslag van cloudobjecten. Een bestaand of nieuw schema in de Hive-metastore. Metagegevens en gegevens van gegevenssets worden opgeslagen op de opgegeven opslaglocatie. Alle gerealiseerde weergaven en streamingtabellen in de pijplijn worden gepubliceerd naar het opgegeven schema in de Hive Metastore.
Unity Catalogus Een bestaande Unity Catalog-catalogus. Geen opgegeven Metagegevens en gegevens van gegevenssets worden opgeslagen op de standaardopslaglocatie die is gekoppeld aan de doelcatalogus. Er zijn geen databaseobjecten geregistreerd bij de Unity Catalog.
Unity Catalogus Een bestaande Unity Catalog-catalogus. Een bestaand of nieuw schema in Unity Catalog. Metagegevens en gegevens van gegevenssets worden opgeslagen in de standaardopslaglocatie die is gekoppeld aan het doelschema of de doelcatalogus. Alle gerealiseerde weergaven en streamingtabellen in de pijplijn worden gepubliceerd naar het opgegeven schema in Unity Catalog.

Broncode bijwerken vanuit LIVE-schema

Pijplijnen die zijn geconfigureerd om te worden uitgevoerd met de nieuwe standaardpublicatiemodus negeren de syntaxis van het LIVE schema. Standaard gebruiken alle tabelleesbewerkingen de catalogus en het schema die zijn opgegeven in de pijplijnconfiguratie.

Voor de meeste bestaande pijplijnen heeft deze gedragswijziging geen invloed, omdat het verouderde LIVE virtuele schemagedrag ook leesbewerkingen doorgeeft aan de catalogus en het schema dat is opgegeven in de pijplijnconfiguratie.

Belangrijk

Verouderde code met leesbewerkingen die gebruikmaken van de standaardcatalogus en het schema van de werkruimte vereisen code-updates. Bekijk de volgende gerealiseerde weergavedefinitie:

CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM raw_data

In de verouderde publicatiemodus maakt een niet-gekwalificeerde leesbewerking uit de raw_data tabel gebruik van de standaardcatalogus en het standaardschema van de werkruimte, bijvoorbeeld main.default.raw_data. In de nieuwe standaardpijplijnmodus zijn de catalogus en het schema die standaard worden gebruikt, geconfigureerd in de pijplijnconfiguratie. Als u ervoor wilt zorgen dat deze code blijft werken zoals verwacht, werkt u de verwijzing bij om de volledig gekwalificeerde id voor de tabel te gebruiken, zoals in het volgende voorbeeld:

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

Werken met gebeurtenislogboeken voor Unity Catalog-pijplijnen in de verouderde publicatiemodus

Belangrijk

De event_log TVF is beschikbaar voor pijplijnen in de verouderde publicatiemodus die tabellen naar Unity Catalog publiceren. Standaardgedrag voor nieuwe pijplijnen publiceert het gebeurtenislogboek naar de doelcatalogus en het schema dat is geconfigureerd voor de pijplijn. Zie Het gebeurtenislogboek opvragen.

Tabellen die zijn geconfigureerd met Hive-metastore hebben ook verschillende ondersteuning en gedrag voor gebeurtenislogboeken. Zie Werken met gebeurtenislogboek voor Hive-metastore-pijplijnen.

Als uw pijplijn tabellen naar Unity Catalog publiceert met de verouderde publicatiemodus, moet u de functie event_logfunctie met tabelwaarde (TVF) gebruiken om het gebeurtenislogboek voor de pijplijn op te halen. U haalt het gebeurtenislogboek voor een pijplijn op door de pijplijn-id of een tabelnaam door te geven aan de TVF. Als u bijvoorbeeld de gebeurtenislogboekrecords voor de pijplijn wilt ophalen met id 04c78631-3dd7-4856-b2a6-7d84e9b2638b:

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

De gebeurtenislogboek records ophalen voor de pijplijn die de tabel my_catalog.my_schema.table1heeft gemaakt of waarvan deze eigenaar is.

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

Als u de TVF wilt aanroepen, moet u een gedeeld cluster of een SQL Warehouse gebruiken. U kunt bijvoorbeeld de SQL-editor gebruiken die is verbonden met een SQL-warehouse.

Om het opvragen van gebeurtenissen voor een pijplijn te vereenvoudigen, kan de eigenaar van de pijplijn een weergave maken over de event_log TVF. In het volgende voorbeeld wordt een weergave gemaakt van het gebeurtenislogboek voor een pijplijn. Deze weergave wordt gebruikt in de voorbeeldquery's voor gebeurtenislogboeken die zijn opgenomen in dit artikel.

Opmerking

  • De event_log TVF kan alleen worden aangeroepen door de eigenaar van de pijplijn.
  • U kunt de event_log tabelwaardefunctie niet gebruiken in een pijplijn of query om toegang te krijgen tot de gebeurtenislogboeken van meerdere pijplijnen.
  • U kunt een weergave die is gemaakt via de event_log tabelwaardefunctie niet delen met andere gebruikers.
CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");

Vervang door <pipeline-ID> de unieke id voor de pijplijn. U vindt de id in het deelvenster Pijplijndetails in de gebruikersinterface van Lakeflow Spark Declarative Pipelines.

Elk exemplaar van een pijplijnrun wordt een updategenoemd. U wilt vaak informatie extraheren voor de meest recente update. Voer de volgende query uit om de id voor de meest recente update te vinden en op te slaan in de latest_update_id tijdelijke weergave. Deze weergave wordt gebruikt in de voorbeeldquery's voor gebeurtenislogboeken die zijn opgenomen in dit artikel:

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;
  • Last updated on