Użyj Unity Catalog z potokami Delta Live Tables

Ważne

Obsługa funkcji Delta Live Tables dla Unity Catalog jest dostępna w publicznej wersji zapoznawczej.

Databricks zaleca konfigurowanie potoków Delta Live Tables za pomocą Unity Catalog.

Potoki skonfigurowane za pomocą Unity Catalog publikują wszystkie zdefiniowane zmaterializowane widoki i tabele strumieniowe do określonego katalogu i schematu. Potoki Unity Catalog mogą odczytywać z innych tabel i dysków Unity Catalog.

Aby zarządzać uprawnieniami w tabelach utworzonych przez potok Unity Catalog, użyj GRANT i REVOKE.

Uwaga

W tym artykule omówiono funkcjonalność bieżącego domyślnego trybu publikowania dla potoków. Rurociągi utworzone przed 5 lutego 2025 r. mogą korzystać ze starszego trybu publikowania i wirtualnego schematu LIVE. Zobacz live schema (starsza wersja).

Wymagania

Aby utworzyć tabele strumieniowe i zmaterializowane widoki w docelowym schemacie w Unity Catalog, musisz mieć następujące uprawnienia do schematu i katalogu nadrzędnego:

• USE CATALOG uprawnienia w katalogu docelowym.
• Uprawnienia CREATE MATERIALIZED VIEW i USE SCHEMA do schematu docelowego, jeśli potok tworzy zmaterializowane widoki.
• Uprawnienia CREATE TABLE i USE SCHEMA na docelowym schemacie, jeśli potok tworzy tabele przesyłania strumieniowego .

Jeśli pipeline tworzy nowe schematy, musisz mieć uprawnienia USE CATALOG i CREATE SCHEMA w katalogu docelowym.

Moc obliczeniowa wymagana do uruchomienia potoku z włączonym Unity Catalog:

• Klastry trybu dostępu współdzielonego. Potok z obsługą Unity Catalog nie może działać na klastrze pojedynczego użytkownika (klaster "przypisanego"). Zobacz ograniczenia trybu dostępu współdzielonego w Unity Catalog.

Obliczenia wymagane do zapytań do tabel utworzonych przez potok Delta Live Tables przy użyciu katalogu Unity (w tym tabel strumieniowania i zmaterializowanych widoków) obejmują dowolne z następujących elementów:

• Magazyny SQL
• Klastry trybu dostępu współdzielonego w środowisku Databricks Runtime 13.3 LTS lub nowszym.
• Klastry trybu dostępu pojedynczego użytkownika (lub "przypisane"), jeśli w klastrze pojedynczego użytkownika jest włączona szczegółowa kontrola dostępu (czyli klaster działa w środowisku Databricks Runtime 15.4 lub nowszym, a dla obszaru roboczego jest włączona bezserwerowa funkcja obliczeniowa). Aby uzyskać więcej informacji, zobacz Szczegółowe informacje dotyczące kontroli dostępu w obliczeniach pojedynczego użytkownika.
• Klastry w trybie dostępu pojedynczego użytkownika (lub "przypisane") w wersjach od 13.3 LTS do 15.3, tylko jeśli zapytanie uruchamia właściciel tabeli.

Obowiązują dodatkowe ograniczenia obliczeniowe. Zobacz sekcję poniżej.

Ograniczenia

Poniżej przedstawiono ograniczenia dotyczące używania Unity Catalog z Delta Live Tables:

• Domyślnie tylko właściciel potoku i administratorzy obszaru roboczego mogą wyświetlać logi sterowników z klastra, który uruchamia potok obsługujący Unity Catalog. Aby umożliwić innym użytkownikom dostęp do dzienników sterownika, zapoznaj się z Zezwalaj użytkownikom niebędącym administratorem na wyświetlanie dzienników sterownika z potoku z włączonym Katalogiem Unity.

• Istniejących potoków korzystających z magazynu metadanych Hive nie można zaktualizować do użycia Unity Catalog. Aby przeprowadzić migrację istniejącego potoku zapisującego do magazynu metadanych Hive, należy utworzyć nowy potok i ponownie pozyskać dane ze źródeł danych. Zobacz Utwórz potok Unity Catalog, klonując potok metastore Hive.

• Nie można utworzyć potoku z włączonym katalogiem Unity w obszarze roboczym dołączonym do magazynu metadanych utworzonego podczas publicznej wersji zapoznawczej Unity Catalog. Zobacz Uaktualnianie do dziedziczenia uprawnień.

• Pliki JAR nie są obsługiwane. Obsługiwane są tylko biblioteki języka Python innych firm. Zobacz Zarządzanie zależnościami języka Python dla potoków tabel Delta Live.

• Zapytania języka manipulowania danymi (DML), które modyfikują schemat tabeli przesyłania strumieniowego, nie są obsługiwane.

• Zmaterializowany widok utworzony w potoku Delta Live Tables nie może być używany jako źródło strumieniowe poza tym potokiem, na przykład w innym potoku lub notatniku podrzędnym.

• Dane dotyczące zmaterializowanych widoków i tabel przesyłania strumieniowego są przechowywane w lokalizacji przechowywania zawierającego schemat. Jeśli nie określono lokalizacji przechowywania schematu, tabele są przechowywane w lokalizacji przechowywania katalogu. Jeśli nie określono lokalizacji przechowywania schematu i katalogu, tabele są przechowywane w głównej lokalizacji magazynu metadanych.

• Karta Historia w Eksploratorze Katalogu nie wyświetla historii zmaterializowanych widoków.

• Właściwość LOCATION nie jest obsługiwana podczas definiowania tabeli.

• Potoki danych z włączonym katalogiem Unity nie mogą publikować w metastore Hive.

• Obsługa funkcji UDF języka Python jest dostępna w publicznej wersji zapoznawczej.

• Nie można użyć Delta Sharing z zmaterializowanym widokiem Delta Live Tables ani z tabelą przesyłania strumieniowego opublikowaną w Unity Catalog.

• Nie można użyć funkcji tabeli o wartości danych 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 w tabeli event_log z innymi użytkownikami.

Uwaga

Pliki bazowe obsługujące zmaterializowane widoki mogą zawierać dane z tabel nadrzędnych (w tym możliwe dane osobowe), które nie są wyświetlane w zmaterializowanej definicji widoku. Dane te są automatycznie dodawane do bazowej pamięci masowej w celu obsługi przyrostowego odświeżania zmaterializowanych widoków.

Ponieważ podstawowe pliki zmaterializowanego widoku mogą spowodować ujawnienie danych z tabel nadrzędnych, które nie są częścią zmaterializowanego schematu widoku, usługa Databricks zaleca, aby nie udostępniać bazowego magazynu niezaufanym użytkownikom podrzędnym.

Załóżmy na przykład, że zmaterializowana definicja widoku zawiera klauzulę COUNT(DISTINCT field_a) . Mimo że zmaterializowana definicja widoku zawiera tylko klauzulę agregacji COUNT DISTINCT, pliki bazowe będą zawierać listę rzeczywistych wartości field_a.

Czy można używać razem potoków Hive metastore i Unity Catalog?

Obszar roboczy może zawierać potoki, które wykorzystują Unity Catalog i starszy magazyn metadanych Hive. Jednak pojedynczy potok nie może zapisywać do magazynu metadanych Hive i katalogu Unity. Nie można uaktualnić istniejących potoków zapisujących do magazynu metadanych Hive, aby korzystać z Unity Catalogu. Aby przeprowadzić migrację istniejącego potoku zapisującego do magazynu metadanych Hive, należy utworzyć nowy potok i ponownie pozyskać dane ze źródeł danych. Zobacz Utwórz potok Unity Catalog, klonując potok metastore Hive.

Istniejące potoki, które nie korzystają z Unity Catalog, nie są dotknięte przy tworzeniu nowych potoków skonfigurowanych z Unity Catalog. Te potoki nadal utrwalają dane w magazynie metadanych Hive przy użyciu skonfigurowanej lokalizacji magazynu.

O ile nie określono inaczej w tym dokumencie, wszystkie istniejące źródła danych i funkcjonalności Delta Live Tables są obsługiwane w potokach korzystających z Unity Catalog. Interfejsy języka Python i SQL są obsługiwane przez potoki korzystające z Unity Catalog.

Zmiany istniejących funkcji

Skonfigurowanie funkcji Delta Live Tables do przechowywania danych w Unity Catalog powoduje, że cyklem życia tabeli zarządza potok Delta Live Tables. Ponieważ potok zarządza cyklem życia i uprawnieniami tabeli:

• Gdy tabela zostanie usunięta z definicji potoku Delta Live Tables, odpowiedni zmaterializowany widok lub wpis tabeli przesyłania strumieniowego zostanie usunięty z Unity Catalog podczas następnej aktualizacji potoku. Rzeczywiste dane są przechowywane przez pewien okres, aby można je było odzyskać, jeśli zostaną usunięte przez pomyłkę. Dane można odzyskać, dodając zmaterializowany widok lub tabelę przesyłania strumieniowego z powrotem do definicji potoku.
• Usunięcie potoku Delta Live Tables powoduje usunięcie wszystkich tabel zdefiniowanych w tym potoku. Ze względu na tę zmianę interfejs użytkownika Delta Live Tables jest aktualizowany, aby wyświetlić monit o potwierdzenie usunięcia potoku.
• Wewnętrzne tabele kopii zapasowych, w tym te używane do obsługi APPLY CHANGES INTO, nie są bezpośrednio dostępne dla użytkowników.

Zapisz tabele do katalogu Unity z potoku Delta Live Tables

Aby zapisać tabele w Katalogu Unity, należy skonfigurować potok danych do pracy z nim za pośrednictwem swojego obszaru roboczego. Po utworzeniu potokuwybierz pozycję Wykaz aparatu Unity w obszarze Opcje magazynuwybierz katalog w menu rozwijanym katalogu , a następnie wybierz istniejący schemat lub wprowadź nazwę nowego schematu w menu rozwijanym Schemat docelowy . Aby dowiedzieć się więcej o katalogach usługi Unity Catalog, zobacz Co to są katalogi w usłudze Azure Databricks?. Aby dowiedzieć się więcej o schematach w Unity Catalog, zobacz Co to są schematy w usłudze Azure Databricks?.

Przetwarzanie danych do potoku Unity Catalog

Potok danych skonfigurowany do używania Unity Catalog może odczytywać dane z:

• Tabele zarządzane i zewnętrzne Unity Catalog, widoki, widoki zmaterializowane oraz tabele przesyłania strumieniowego.
• Tabele i widoki magazynu metadanych Hive.
• Automatyczny ładownik przy użyciu funkcji read_files() do odczytu z zewnętrznych lokalizacji katalogu Unity.
• Apache Kafka i Amazon Kinesis.

Poniżej przedstawiono przykłady odczytywania z tabel Unity Catalog i Hive metastore.

Wsadowe pozyskiwanie danych z tabeli Unity Catalog

SQL

CREATE OR REFRESH MATERIALIZED VIEW
  table_name
AS SELECT
  *
FROM
  my_catalog.my_schema.table1;

Python

@dlt.table
def table_name():
  return spark.read.table("my_catalog.my_schema.table")

Przesyłanie strumieniowe zmian z tabeli katalogu Unity

SQL

CREATE OR REFRESH STREAMING TABLE
  table_name
AS SELECT
  *
FROM
  STREAM(my_catalog.my_schema.table1);

Python

@dlt.table
def table_name():
  return spark.readStream.table("my_catalog.my_schema.table")

Pozyskiwanie danych z magazynu metadanych Hive

Potok przetwarzania używający katalogu Unity może odczytywać dane z tabel magazynu metadanych Hive przy użyciu katalogu hive_metastore.

SQL

CREATE OR REFRESH MATERIALIZED VIEW
  table_name
AS SELECT
  *
FROM
  hive_metastore.some_schema.table;

Python

@dlt.table
def table3():
  return spark.read.table("hive_metastore.some_schema.table")

Pozyskiwanie danych z modułu ładującego automatycznego

SQL

CREATE OR REFRESH STREAMING TABLE
  table_name
AS SELECT
  *
FROM
  read_files(
    <path-to-uc-external-location>,
    "json"
  )

Python

@dlt.table(table_properties={"quality": "bronze"})
def table_name():
  return (
     spark.readStream.format("cloudFiles")
     .option("cloudFiles.format", "json")
     .load(f"{path_to_uc_external_location}")
 )

Udostępnianie zmaterializowanych widoków

Domyślnie tylko właściciel potoku ma uprawnienia do wykonywania zapytań dotyczących zestawów danych utworzonych przez potok. Możesz dać innym użytkownikom możliwość wykonywania zapytań dotyczących tabeli przy użyciu instrukcji GRANT i można odwołać dostęp do zapytań przy użyciu instrukcji REVOKE. Aby uzyskać więcej informacji na temat uprawnień w Unity Catalog, zobacz Zarządzanie uprawnieniami w Unity Catalog.

Przyznaj uprawnienia SELECT do tabeli

GRANT SELECT ON TABLE
  my_catalog.my_schema.table_name
TO
  `user@databricks.com`

Odbieranie uprawnienia select na tabeli

REVOKE SELECT ON TABLE
  my_catalog.my_schema.table_name
FROM
  `user@databricks.com`

Udzielanie uprawnienia do tworzenia tabeli lub tworzenia zmaterializowanego widoku

GRANT CREATE { MATERIALIZED VIEW | TABLE } ON SCHEMA
  my_catalog.my_schema
TO
  { principal | user }

Wyświetlanie pochodzenia potoku

Pochodzenie tabel w potoku Delta Live Tables jest widoczne w Eksploratorze wykazu. Interfejs użytkownika ścieżki danych w Eksploratorze Katalogu pokazuje tabele nadrzędne i podrzędne dla zmaterializowanych widoków lub tabel przesyłania strumieniowego w potoku obsługującym katalog Unity. Aby dowiedzieć się więcej na temat pochodzenia danych w Unity Catalog, zobacz Przechwytywanie i wyświetlanie pochodzenia danych przy użyciu Unity Catalog.

W przypadku zmaterializowanego widoku lub tabeli przesyłania strumieniowego w potoku Delta Live Tables z aktywowanym katalogiem Unity interfejs użytkownika pochodzenia w Eksploratorze Katalogu będzie również łączyć się z potokiem, który wygenerował zmaterializowany widok lub tabelę przesyłania strumieniowego, jeśli potok jest dostępny z bieżącego obszaru roboczego.

Dodawanie, zmienianie lub usuwanie danych w tabeli strumieniowej

Aby zmodyfikować tabele strumieniowe opublikowane w Unity Catalog, można użyć instrukcji języka manipulacji danymi (DML), w tym instrukcji wstawiania, aktualizowania, usuwania i scalania. Obsługa zapytań DML względem tabel przesyłania strumieniowego umożliwia stosowanie przypadków użycia, takich jak aktualizowanie tabel pod kątem zgodności z ogólnym rozporządzeniem o ochronie danych (RODO).

Uwaga

• Instrukcje DML modyfikujące schemat tabeli przesyłania strumieniowego nie są obsługiwane. Upewnij się, że instrukcje DML nie próbują rozwijać schematu tabeli.
• Instrukcje DML, które aktualizują tabelę strumieniową, mogą być uruchamiane tylko w udostępnionym klastrze Unity Catalog lub w usłudze SQL Warehouse przy użyciu środowiska Databricks Runtime 13.3 LTS lub nowszego.
• Ponieważ przesyłanie strumieniowe wymaga źródeł danych tylko do dołączania, jeśli przetwarzanie wymaga przesyłania strumieniowego ze źródłowej tabeli, w której zachodzą zmiany spowodowane instrukcjami DML, ustaw flagę skipChangeCommits podczas odczytywania tej tabeli przesyłania strumieniowego. Po ustawieniu skipChangeCommits transakcje, które usuwają lub modyfikują rekordy w tabeli źródłowej, są ignorowane. Jeśli przetwarzanie nie wymaga tabeli przesyłania strumieniowego, możesz użyć zmaterializowanego widoku (który nie ma ograniczenia tylko do dołączania) jako tabeli docelowej.

Poniżej przedstawiono przykłady instrukcji DML do modyfikowania rekordów w tabeli przesyłania strumieniowego.

Usuń rekordy z określonym identyfikatorem:

DELETE FROM my_streaming_table WHERE id = 123;

Aktualizuj rekordy przy użyciu określonego identyfikatora:

UPDATE my_streaming_table SET name = 'Jane Doe' WHERE id = 123;

Publikowanie tabel z filtrami wierszy i maskami kolumn

Ważne

Ta funkcja jest dostępna w publicznej wersji zapoznawczej.

filtry wierszy umożliwiają określenie funkcji, która ma zastosowanie jako filtr za każdym razem, gdy skanowanie tabeli pobiera wiersze. Te filtry zapewniają, że kolejne zapytania zwracają tylko wiersze, dla których predykat filtru daje wartość true.

maski kolumn umożliwiają maskowanie wartości kolumny za każdym razem, gdy skanowanie tabeli pobiera wiersze. Przyszłe zapytania dla tej kolumny zwracają wynik ocenianej funkcji zamiast oryginalnej wartości kolumny. Aby uzyskać więcej informacji na temat używania filtrów wierszy i masek kolumn, zobacz Filtrowanie poufnych danych tabeli przy użyciu filtrów wierszy i masek kolumn.

Zarządzanie filtrami wierszy i maskami kolumn

Filtry wierszy i maski kolumn w zmaterializowanych widokach i tabelach przesyłania strumieniowego powinny być dodawane, aktualizowane lub usuwane za pomocą instrukcji CREATE OR REFRESH.

Aby uzyskać szczegółową składnię dotyczącą definiowania tabel z filtrami wierszy i maskami kolumn, zobacz dokumentację języka SQL Delta Live Tables i dokumentację języka Python Delta Live Tables.

Zachowanie

Poniżej przedstawiono ważne szczegóły dotyczące używania filtrów wierszy lub masek kolumn w potokach Delta Live Tables:

• Odśwież jako właściciel: Gdy aktualizacja potoku odświeża zmaterializowany widok lub tabelę strumieniową, funkcje filtru wierszy i maskowania kolumn są uruchamiane z prawami właściciela potoku. Oznacza to, że aktualizacja tabeli korzysta z kontekstu zabezpieczeń użytkownika, który utworzył pipeline. Funkcje sprawdzające kontekst użytkownika (na przykład CURRENT_USER i IS_MEMBER) są oceniane przy użyciu kontekstu użytkownika właściciela potoku.
• zapytanie: podczas wykonywania zapytań dotyczących zmaterializowanego widoku lub tabeli przesyłania strumieniowego funkcje sprawdzające kontekst użytkownika (takie jak CURRENT_USER i IS_MEMBER) są oceniane przy użyciu kontekstu użytkownika wywołującego. Takie podejście wymusza zabezpieczenia danych specyficzne dla użytkownika i mechanizmy kontroli dostępu na podstawie kontekstu bieżącego użytkownika.
• Podczas tworzenia zmaterializowanych widoków w tabelach źródłowych zawierających filtry wierszy i maski kolumn odświeżanie zmaterializowanego widoku jest zawsze pełnym odświeżaniem. Pełne odświeżanie ponownie przetwarza wszystkie dane dostępne w źródle przy użyciu najnowszych definicji. Ten proces sprawdza, czy zasady zabezpieczeń w tabelach źródłowych są oceniane i stosowane przy użyciu najbardziej up-to—data danych i definicji.

Wgląd w informacje

Użyj DESCRIBE EXTENDED, INFORMATION_SCHEMAlub Eksploratora wykazu, aby zbadać istniejące filtry wierszy i maski kolumn, które mają zastosowanie do danego zmaterializowanego widoku lub tabeli przesyłania strumieniowego. Ta funkcja umożliwia użytkownikom przeprowadzanie inspekcji i przeglądania środków dostępu do danych i ochrony w przypadku zmaterializowanych widoków i tabel przesyłania strumieniowego.