Schemat LIVE (starsza wersja)

Ten artykuł zawiera omówienie dziedzicznej składni i charakterystyki schematu wirtualnego LIVE.

Schemat wirtualny LIVE jest starszą funkcją potoków DLT i jest uważany za przestarzałą. Nadal można używać starszego trybu publikowania i wirtualnego schematu LIVE dla potoków utworzonych w tym trybie.

Obsługa starszego schematu wirtualnego LIVE i starszego trybu publikowania zostanie usunięta w przyszłej wersji usługi Azure Databricks.

Notatka

Starsze potoki trybu publikowania są wskazywane w polu Podsumowanie interfejsu użytkownika ustawień potoku DLT. Możesz również potwierdzić, że potok używa starszego trybu publikowania, jeśli pole target jest ustawione w specyfikacji JSON tego potoku.

Nie można za pomocą interfejsu konfiguracji potoków utworzyć nowych potoków w starszym trybie publikacji. Jeśli musisz wdrożyć nowe potoki przy użyciu starszej składni LIVE, skontaktuj się z przedstawicielem konta usługi Databricks.

Jaki jest schemat wirtualny LIVE?

Notatka

Schemat wirtualny LIVE nie jest już potrzebny do analizowania zależności zestawu danych w domyślnym trybie publikowania dla biblioteki DLT.

Schemat LIVE to koncepcja programowania w DLT, która definiuje granicę wirtualną dla wszystkich zestawów danych utworzonych lub zaktualizowanych w ścieżce przetwarzania. Zgodnie z projektem schemat LIVE nie jest powiązany bezpośrednio z zestawami danych w opublikowanym schemacie. Zamiast tego schemat LIVE umożliwia zaplanowanie i uruchomienie logiki w potoku, nawet jeśli użytkownik nie chce publikować zestawów danych do schematu.

W starszych potokach trybu publikowania możesz użyć słowa kluczowego LIVE, aby odwołać się do innych zestawów danych w bieżącym potoku podczas odczytu, na przykład SELECT * FROM LIVE.bronze_table. W domyślnym trybie publikowania dla nowych potoków DLT ta składnia jest dyskretnie ignorowana, co oznacza, że niekwalifikowane identyfikatory używają bieżącego schematu. Zobacz Ustaw katalog docelowy i schemat.

starszego trybu publikowania dla potoków

Schemat wirtualny LIVE jest używany ze starszym trybem publikowania dla potoków DLT. Wszystkie tabele utworzone przed 5 lutego 2025 r. domyślnie używają starszego trybu publikowania.

W poniższej tabeli opisano zachowanie wszystkich zmaterializowanych widoków i tabel przesyłania strumieniowego, które zostały utworzone lub zaktualizowane w potoku działającym w starszym trybie publikowania.

Opcja magazynu	Lokalizacja magazynu lub katalog	Schemat docelowy	Zachowanie
"Metastore Hive"	Brak określenia	Nie określono	Metadane i dane zestawu danych są przechowywane w katalogu głównym DBFS. Żadne obiekty bazy danych nie są zarejestrowane w magazynie metadanych Programu Hive.
Magazyn metadanych Hive	Identyfikator URI lub ścieżka pliku do magazynu obiektów w chmurze.	Nie określono	Metadane i dane zestawu danych są przechowywane w określonej lokalizacji przechowywania. Żadne obiekty bazy danych nie są zarejestrowane w magazynie metadanych Programu Hive.
Magazyn metadanych Hive	Nie określono	Istniejący lub nowy schemat w magazynie metadanych Hive.	Metadane i dane zestawu danych są przechowywane w katalogu głównym systemu plików DBFS. Wszystkie zmaterializowane widoki i tabele przesyłania strumieniowego w potoku są publikowane w określonym schemacie w magazynie metadanych Hive.
Magazyn metadanych Hive	Identyfikator URI lub ścieżka pliku do przechowywania obiektów w chmurze.	Istniejący lub nowy schemat w katalogu metadanych Hive.	Metadane i dane zestawu danych są przechowywane w określonej lokalizacji przechowywania. Wszystkie zmaterializowane widoki i tabele strumieniowe w potoku są publikowane w określonym schemacie w Hive Metastore.
Unity Catalog	Istniejący katalog Unity Catalog.	Nie określono	Metadane i dane zestawu danych są przechowywane w domyślnej lokalizacji przechowywania skojarzonej z docelowym katalogiem. Żadne obiekty bazy danych nie są zarejestrowane w Unity Catalog.
Katalog Unity	Istniejący katalog Unity Catalog.	Istniejący lub nowy schemat w katalogu Unity Catalog.	Metadane i dane zestawu danych są przechowywane w domyślnej lokalizacji pamięci powiązanej ze schematem lub katalogiem docelowym. Wszystkie zmaterializowane widoki i tabele strumieniowe w potoku są publikowane w określonym schemacie w katalogu Unity.

Aktualizowanie kodu źródłowego ze schematu LIVE

Potoki konfigurowane do działania z nowym domyślnym trybem publikowania bezgłośnie ignorują składnię schematu LIVE. Domyślnie wszystkie odczyty tabeli używają katalogu i schematu określonego w konfiguracji potoku.

W przypadku większości istniejących potoków ta zmiana zachowania nie ma wpływu, ponieważ starsze zachowanie schematu wirtualnego LIVE również kieruje odczyty do katalogu i schematu określonego w konfiguracji potoku.

Ważny

Starszy kod, który wykorzystuje odczyty z domyślnego katalogu i schematu obszaru roboczego, wymaga aktualizacji. Rozważmy następującą zmaterializowaną definicję widoku:

CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM raw_data

W starszym trybie publikowania odczyt niekwalifikowany z tabeli raw_data korzysta z domyślnego katalogu i schematu obszaru roboczego, na przykład main.default.raw_data. W nowym domyślnym trybie potoku katalog i schemat używany domyślnie są skonfigurowane w konfiguracji potoku. Aby upewnić się, że ten kod nadal działa zgodnie z oczekiwaniami, zaktualizuj odwołanie, aby użyć w pełni kwalifikowanego identyfikatora tabeli, jak w poniższym przykładzie:

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

Praca z dziennikiem zdarzeń dla potoków w trybie publikowania starszej wersji Unity Catalog

Ważny

event_log TVF jest dostępny dla potoków w trybie publikacji w wersji starszej, które publikują tabele do Unity Catalog. Domyślne zachowanie dla nowych potoków publikuje dziennik zdarzeń w wykazie docelowym i schemacie skonfigurowanym dla potoku. Zobacz Wykonywanie zapytań w dzienniku zdarzeń.

Tabele skonfigurowane za pomocą magazynu metadanych Hive mają również odmienną obsługę i zachowanie dziennika zdarzeń. Zobacz Praca z dziennikiem zdarzeń dla potoków magazynu metadanych Hive.

Jeśli potok publikuje tabele w wykazie Unity Catalog ze starszym trybem publikowania, należy użyć funkcji event_logzwracającej tabelę (TVF), aby pobrać dziennik zdarzeń dla potoku. Dziennik zdarzeń dla potoku można pobrać, przekazując identyfikator potoku lub nazwę tabeli do programu TVF. Przykładowo, aby pobrać rekordy dziennika zdarzeń dla przepływu o identyfikatorze 04c78631-3dd7-4856-b2a6-7d84e9b2638b:

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

Aby pobrać rekordy dziennika zdarzeń dla potoku utworzonego lub będącego właścicielem tabeli my_catalog.my_schema.table1:

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

Aby wywołać TVF, należy użyć udostępnionego klastra lub magazynu SQL. Możesz na przykład użyć notesu dołączonego do udostępnionego klastra lub użyć edytora SQL połączonego z usługą SQL Warehouse.

Aby uprościć zapytania dotyczące zdarzeń dla potoku, właściciel potoku może utworzyć widok na event_log TVF. Poniższy przykład tworzy widok dziennika zdarzeń dla potoku. Ten widok jest używany w przykładowych zapytaniach dziennika zdarzeń zawartych w tym artykule.

Notatka

• event_log TVF może być wywoływany tylko przez właściciela pipeline'u.
• Nie można użyć funkcji tabelowanej event_log w potoku lub zapytaniu w celu uzyskania dostępu do dzienników zdarzeń wielu potoków.
• Nie można udostępnić widoku utworzonego na podstawie funkcji tabeli o wartości event_log innym użytkownikom.

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

Zastąp <pipeline-ID> unikatowym identyfikatorem potoku DLT. Identyfikator można znaleźć w panelu szczegółów potoku w interfejsie użytkownika DLT.

Każde wystąpienie uruchomienia potoku jest określane jako aktualizacja. Często chcesz wyodrębnić informacje dotyczące najnowszej aktualizacji. Uruchom następujące zapytanie, aby znaleźć identyfikator najnowszej aktualizacji i zapisać go w widoku tymczasowym latest_update_id. Ten widok jest używany w przykładowych zapytaniach dziennika zdarzeń zawartych w tym artykule:

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;