Udostępnij za pośrednictwem

Używanie Unity Catalog z potokami Delta Live Tables

  • Artykuł

Ważne

Obsługa tabel Delta Live Tables dla wykazu aparatu Unity jest dostępna w publicznej wersji zapoznawczej.

Usługa Databricks zaleca konfigurowanie potoków delty tabel na żywo za pomocą wykazu aparatu Unity.

Potoki skonfigurowane za pomocą wykazu aparatu Unity publikują wszystkie zdefiniowane zmaterializowane widoki i tabele przesyłania strumieniowego do określonego wykazu i schematu. Potoki wykazu aparatu Unity mogą odczytywać z innych tabel i woluminów wykazu aparatu Unity.

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

Wymagania

Uprawnienia wymagane do tworzenia tabel w wykazie aparatu Unity z potoku delta live tables:

  • USE CATALOG uprawnienia w wykazie docelowym.
  • CREATE MATERIALIZED VIEW i USE SCHEMA uprawnienia w schemacie docelowym, jeśli potok tworzy zmaterializowane widoki.
  • CREATE TABLE i USE SCHEMA uprawnienia w schemacie docelowym, jeśli potok tworzy tabele przesyłania strumieniowego.
  • Jeśli schemat docelowy nie jest określony w ustawieniach potoku, musisz mieć CREATE MATERIALIZED VIEW CREATE TABLE lub uprawnienia co najmniej jednego schematu w wykazie docelowym.

Środowisko obliczeniowe wymagane do uruchomienia potoku obsługującego wykaz aparatu Unity:

Obliczenia wymagane do wykonywania zapytań dotyczących tabel utworzonych przez potok delta Live Tables przy użyciu wykazu aparatu Unity (w tym tabel przesyłania strumieniowego 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 trybu dostępu pojedynczego użytkownika (lub "przypisane") w wersji 13.3 LTS do 15.3, tylko wtedy, gdy właściciel tabeli uruchamia zapytanie.

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

Ograniczenia

Poniżej przedstawiono ograniczenia dotyczące używania wykazu aparatu Unity z tabelami delta Live Tables:

  • Domyślnie tylko właściciel potoku i administratorzy obszaru roboczego mogą wyświetlać dzienniki sterowników z klastra, który uruchamia potok z obsługą wykazu aparatu Unity. Aby zezwolić innym użytkownikom na dostęp do dzienników sterowników, zobacz Zezwalanie użytkownikom niebędącym administratorem na wyświetlanie dzienników sterowników z potoku obsługującego wykaz aparatu Unity.

  • Istniejących potoków korzystających z magazynu metadanych Hive nie można uaktualnić do korzystania z wykazu aparatu Unity. 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.

  • Nie można utworzyć potoku obsługującego wykaz aparatu Unity w obszarze roboczym dołączonym do magazynu metadanych utworzonego podczas publicznej wersji zapoznawczej wykazu aparatu Unity. Zobacz Uaktualnianie do dziedziczenia uprawnień.

  • Pliki JAR nie są obsługiwane. Obsługiwane są tylko biblioteki języka Python innych firm. Zobacz Manage Python dependencies for Delta Live Tables pipelines (Zarządzanie zależnościami języka Python dla potoków tabel na żywo funkcji Delta).

  • 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 przesyłania strumieniowego poza tym potokiem, na przykład w innym potoku lub notesie podrzędnym.

  • Jeśli potok publikuje w schemacie z zarządzaną lokalizacją magazynu, schemat można zmienić w kolejnej aktualizacji, ale tylko wtedy, gdy zaktualizowany schemat używa tej samej lokalizacji magazynu co wcześniej określony schemat.

  • Tabele są przechowywane w lokalizacji przechowywania schematu docelowego. 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 eksploratora wykazu nie pokazuje historii zmaterializowanych widoków.

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

  • Potoki obsługujące wykaz aparatu Unity nie mogą publikować w magazynie metadanych Hive.

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

  • Nie można używać funkcji udostępniania różnicowego z tabelami delta live zmaterializowanym widokiem lub tabelą przesyłania strumieniowego opublikowaną w wykazie aparatu Unity.

  • Nie można użyć event_log funkcji z wartością tabeli w potoku lub zapytaniu, aby uzyskać dostęp do dzienników zdarzeń wielu potoków.

  • Nie można udostępnić widoku utworzonego nad funkcją event_log o wartości tabeli innym użytkownikom.

  • Klastry z jednym węzłem nie są obsługiwane w potokach z obsługą wykazu aparatu Unity. Ponieważ tabele delta live mogą utworzyć klaster z jednym węzłem do uruchamiania mniejszych potoków, potok może zakończyć się niepowodzeniem z komunikatem o błędzie odwołującym single-node modesię do . W takim przypadku określ co najmniej jeden proces roboczy podczas konfigurowania obliczeń. Zobacz Configure compute for a Delta Live Tables pipeline (Konfigurowanie obliczeń dla potoku tabel na żywo delty).

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. Te dane są automatycznie dodawane do bazowego magazynu 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 field_awartości .

Czy można używać razem potoków magazynu metadanych Hive i wykazu aparatu Unity?

Obszar roboczy może zawierać potoki korzystające z wykazu aparatu Unity i starszego magazynu metadanych Hive. Jednak pojedynczy potok nie może zapisywać w magazynie metadanych Hive i katalogu aparatu Unity. Nie można uaktualnić istniejących potoków zapisujących do magazynu metadanych Hive w celu korzystania z wykazu aparatu Unity.

Nie ma to wpływu na istniejące potoki, które nie korzystają z wykazu aparatu Unity, przez utworzenie nowych potoków skonfigurowanych w wykazie aparatu Unity. 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 funkcje delta live tables są obsługiwane z potokami korzystającymi z wykazu aparatu Unity. Interfejsy Języka Python i SQL są obsługiwane w przypadku potoków korzystających z wykazu aparatu Unity.

Zmiany istniejących funkcji

Po skonfigurowaniu funkcji Delta Live Tables do utrwalania danych w wykazie aparatu Unity cykl życia tabeli jest zarządzany przez 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 wykazu aparatu Unity w 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 >wróć 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 tabel delta Live Tables jest aktualizowany w celu wyświetlenia monitu o potwierdzenie usunięcia potoku.
  • Wewnętrzne tabele kopii zapasowych, w tym te używane do obsługi APPLY CHANGES INTOprogramu , nie są bezpośrednio dostępne dla użytkowników.

Zapisywanie tabel w wykazie aparatu Unity z potoku delta Live Tables

Uwaga

Jeśli nie wybierzesz wykazu i schematu docelowego dla potoku, tabele nie zostaną opublikowane w wykazie aparatu Unity i będą dostępne tylko przez zapytania w tym samym potoku.

Aby zapisać tabele w wykazie aparatu Unity, należy skonfigurować potok do pracy z nim za pośrednictwem obszaru roboczego. Podczas tworzenia potoku wybierz pozycję Katalog aparatu Unity w obszarze Opcje magazynu, wybierz katalog w menu rozwijanym Wykaz , a następnie wybierz istniejący schemat lub wprowadź nazwę nowego schematu w menu rozwijanym Schemat docelowy. Aby dowiedzieć się więcej o katalogach wykazu aparatu Unity, zobacz Co to są wykazy w usłudze Azure Databricks?. Aby dowiedzieć się więcej o schematach w wykazie aparatu Unity, zobacz Co to są schematy w usłudze Azure Databricks?.

Pozyskiwanie danych do potoku wykazu aparatu Unity

Potok skonfigurowany do używania wykazu aparatu Unity może odczytywać dane z:

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

Poniżej przedstawiono przykłady odczytywania z tabel wykazu unity i magazynu metadanych Hive.

Pozyskiwanie wsadowe z tabeli wykazu aparatu Unity

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 wykazu aparatu 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 używający wykazu aparatu Unity może odczytywać dane z tabel magazynu metadanych Hive przy użyciu hive_metastore wykazu:

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 wykazie aparatu Unity, zobacz Zarządzanie uprawnieniami w wykazie aparatu Unity.

Udzielanie wyboru w tabeli

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

Odwoływanie zaznacznia w 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 pochodzenia eksploratora wykazu przedstawia tabele nadrzędne i podrzędne dla zmaterializowanych widoków lub tabel przesyłania strumieniowego w potoku obsługującym wykaz aparatu Unity. Aby dowiedzieć się więcej na temat pochodzenia wykazu aparatu Unity, zobacz Przechwytywanie i wyświetlanie pochodzenia danych przy użyciu wykazu aparatu Unity.

W przypadku zmaterializowanego widoku lub tabeli przesyłania strumieniowego w potoku tabel delta live tables z obsługą wykazu aparatu Unity interfejs użytkownika pochodzenia eksploratora wykazu 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 przesyłania strumieniowego

Instrukcje języka manipulowania danymi (DML), w tym instrukcje wstawiania, aktualizowania, usuwania i scalania, umożliwiają modyfikowanie tabel przesyłania strumieniowego publikowanych w wykazie aparatu Unity. 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ę przesyłania strumieniowego, mogą być uruchamiane tylko w udostępnionym klastrze wykazu aparatu Unity 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 przesyłania strumieniowego ze zmianami (na przykład instrukcjami DML), ustaw flagę skipChangeCommits podczas odczytywania źródłowej tabeli przesyłania strumieniowego. Po skipChangeCommits ustawieniu 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 porzucane za pomocą instrukcji CREATE OR REFRESH .

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

Zachowanie

Poniżej przedstawiono ważne szczegóły dotyczące używania filtrów wierszy lub masek kolumn w potokach tabel na żywo delty:

  • Odśwież jako właściciel: gdy aktualizacja potoku odświeża zmaterializowany widok lub tabelę przesyłania strumieniowego, funkcje filtru wierszy i maski kolumn są uruchamiane z prawami właściciela potoku. Oznacza to, że odświeżanie tabeli używa kontekstu zabezpieczeń użytkownika, który utworzył potok. 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 (na przykład 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 aktualnych danych i definicji.

Wgląd w informacje

INFORMATION_SCHEMAUżyj DESCRIBE EXTENDED, lub 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.