Schemat LIVE (wersja archiwalna)

Ten artykuł zawiera omówienie przestarzałej składni i zachowania dla wirtualnego schematu LIVE.

Schemat wirtualny LIVE to starsza funkcja potoków Delta Live Tables i jest uważany za przestarzały. Nadal można używać starszego trybu publikowania i schematu wirtualnego LIVE dla potoków, które zostały utworzone w tym trybie. Databricks zaleca migrację wszystkich potoków do nowego trybu publikowania. Obsługa starszego schematu wirtualnego LIVE i starszego trybu publikowania zostanie usunięta w przyszłej wersji usługi Azure Databricks.

Notatka

Nie można użyć interfejsu użytkownika konfiguracji potoku do utworzenia nowych potoków ze starszym trybem publikowania. 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 zbioru danych w trybie publikacji domyślnej dla Tabel Delta Live.

Schemat LIVE to koncepcja programistyczna w Delta Live Tables, która definiuje wirtualną granicę dla wszystkich zestawów danych utworzonych lub zaktualizowanych w strumieniu danych. 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 trybie publikowania potoku starszego typu możesz użyć słowa kluczowego LIVE, aby odwołać się do innych zestawów danych w bieżącym potoku do odczytu, na przykład SELECT * FROM LIVE.bronze_table. W domyślnym trybie publikowania dla nowych potoków Delta Live Tables ta składnia jest cicho ignorowana, co oznacza, że niekwalifikowane identyfikatory używają bieżącego schematu. Zobacz Ustaw katalog docelowy i schemat.

tryb publikowania rurociągu dziedziczenia

Schemat wirtualny LIVE jest używany ze starszym trybem publikowania potoku Delta Live Tables. Wszystkie tabele utworzone przed 5 lutego 2025 r. domyślnie używają starszego trybu publikowania.

Poniższa tabela opisuje zachowanie wszystkich materializowanych widoków i tabel strumieniowych utworzonych lub zaktualizowanych w rurku w starszym trybie publikowania.

Opcja magazynu	Lokalizacja magazynu lub katalog	Schemat docelowy	Zachowanie
Magazyn metadanych 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 przechowywania 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 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 magazynu obiektów w chmurze.	Istniejący lub nowy schemat w magazynie metadanych Hive (metastore).	Metadane i dane zestawu danych są przechowywane w określonej lokalizacji magazynowania. Wszystkie zmaterializowane widoki i tabele strumieniowe w pipeline są publikowane w określonym schemacie w metastore Hive.
Unity Catalog	Istniejący katalog Unity Catalog.	Nie określono	Dane i metadane są przechowywane w domyślnym miejscu przechowywania skojarzonym z katalogiem docelowym. Żadne obiekty bazy danych nie są zarejestrowane w katalogu Unity.
Unity Catalog	Istniejący katalog katalogu Unity.	Istniejący lub nowy schemat bazy danych w katalogu Unity Catalog.	Metadane i dane zestawu danych są przechowywane w domyślnej lokalizacji przechowywania skojarzonej ze schematem lub katalogiem docelowego. Wszystkie zmaterializowane widoki i strumieniowe tabele w potoku są publikowane w określonym schemacie w Unity Catalog.

Przełączanie między trybami publikowania

Potoki utworzone w starszym trybie publikowania mogą wyrazić zgodę na nowy domyślny tryb publikowania, aktualizując konfigurację JSON dla potoku. Potoki można przywrócić do starszego trybu publikowania po włączeniu nowego domyślnego zachowania w razie potrzeby.

Własność	Zachowanie
target	Konfiguruje pipeline do używania trybu starszego publikowania. Określ nazwę schematu docelowego jako ciąg.
schema	Konfiguruje potok tak, aby używał domyślnego trybu publikowania, który obsługuje aktualizowanie zmaterializowanych widoków i tabel przesyłania strumieniowego w wielu schematach. Określ nazwę domyślnego schematu jako ciąg.

Zobacz właściwości Delta Live Tables.

Notatka

Nie trzeba aktualizować właściwości catalog ani storage, których odpowiednio używają potoki Unity Catalog i metadanych Hive.

Aktualizowanie kodu źródłowego ze schematu LIVE

Potoki skonfigurowane do uruchamiania z nowym domyślnym trybem publikowania nie zwracają uwagi na składnię schematu LIVE. Domyślnie wszystkie odczyty tabeli używają wykazu 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 z odczytami wykorzystującymi domyślny katalog i schemat obszaru roboczego wymaga aktualizacji. Rozważmy następującą zmaterializowaną definicję widoku:

CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM raw_data

W trybie publikacji w wersji starszej odczyt niekwalifikowany z tabeli raw_data używa domyślnego katalogu i schematu obszaru roboczego, na przykład main.default.raw_data. W nowym domyślnym trybie potoku domyślnie używane są katalog i schemat zgodne z konfiguracją 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