Udostępnij za pośrednictwem

Używanie Catalog Unity z potokami usługi Delta Live Tables

  • Artykuł

Ważne

Usługa Delta Live Tables obsługuje Unity Catalog w publicznej wersji zapoznawczej .

Usługa Databricks zaleca skonfigurowanie potoków usługi Delta Live Tables za pomocą środowiska Unity Catalog.

Linie przetwarzania skonfigurowane w programie Unity Catalog publikują wszystkie zdefiniowane materiałowe views i przesyłane strumieniowo tables do określonych catalog i schema. Potoki Unity Catalog mogą odczytywać z innych potoków Unity Catalog,tables i volumes.

Aby zarządzać uprawnieniami do tables, które zostały utworzone przez potok Catalog Unity, użyj GRANT i REVOKE.

Wymagania

Uprawnienia wymagane do utworzenia tables w środowisku Unity Catalog z potoku usługi Delta Live Tables:

  • uprawnienia USE CATALOG do docelowego catalog
  • Uprawnienia CREATE MATERIALIZED VIEW i USE SCHEMA na docelowym schema, jeśli twój potok tworzy zmaterializowane views.
  • CREATE TABLE i uprawnienia USE SCHEMA na docelowy schema, jeśli twój potok tworzy przesyłanie strumieniowe tables.
  • Jeśli nie określono celu schema w ustawieniach potoku, musisz mieć uprawnienia CREATE MATERIALIZED VIEW lub CREATE TABLE do co najmniej jednego schema w docelowym catalog.

Moc obliczeniowa wymagana do uruchomienia potoku z obsługą Unity Catalog:

Obliczenia wymagane do wykonywania zapytań dotyczących tables utworzonych przez potok Delta Live Tables za pomocą Unity Catalog (w tym przesyłanie strumieniowe tables i zmaterializowane views) obejmuje dowolny 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 od 13.3 LTS do 15.3, tylko wtedy, gdy właściciel table uruchamia zapytanie.

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 danych oraz administratorzy obszaru roboczego mogą wyświetlać logi sterownika z klastra uruchamiającego potok danych z funkcją Unity Catalog-enabled. Aby zezwolić innym użytkownikom na dostęp do dzienników sterowników, zobacz , jak umożliwić użytkownikom niebędącym administratorami dostęp do dzienników sterowników w potoku obsługiwanym przez Unity Catalog.

  • Nie można uaktualnić istniejących potoków korzystających z magazynu metadanych Hive, aby korzystały z 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.

  • Nie można utworzyć Unity Catalog-włączonego potoku 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 Delta Live Tables.

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

  • Zmaterializowany widok utworzony w potoku usługi 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 rurociąg publikuje w schema z zarządzaną lokalizacją przechowywania, schema można zmienić w kolejnym update, ale tylko wtedy, gdy zaktualizowana schema używa tej samej lokalizacji przechowywania, co wcześniej określona schema.

  • Tables są przechowywane w docelowej lokalizacji przechowywania dla schema. Jeśli nie określono lokalizacji magazynu schema, tables są przechowywane w lokalizacji magazynu catalog. Jeśli nie określono lokalizacji magazynu schema i catalog, tables są przechowywane w głównej lokalizacji magazynu metadanych.

  • Karta Historia Eksploratora nie pokazuje historii zmaterializowanej .

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

  • Potoki danych z obsługą Unity Catalognie mogą publikować w Metastore Hive.

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

  • Nie można używać Delta Sharing z zmaterializowanym widokiem Delta Live Tables ani z przesyłaniem strumieniowym table opublikowanym w Unity Catalog.

  • Nie można użyć event_logtable wartościowanej funkcji w potoku lub zapytaniu w celu uzyskania dostępu do dzienników zdarzeń wielu potoków.

  • Nie można udostępnić widoku utworzonego na funkcji wartościowanej event_logtable innym użytkownikom.

Uwaga

Pliki źródłowe obsługujące zmaterializowane views mogą zawierać dane z nadrzędnego tables (w tym możliwe dane osobowe), które nie są wyświetlane w zmaterializowanej definicji widoku. Te dane są automatycznie dodawane do zasobów bazowych dla obsługi przyrostowego odświeżania zmaterializowanego views.

Ponieważ pliki bazowe zmaterializowanego widoku mogą spowodować ujawnienie danych z zasobów nadrzędnych tables, które nie są częścią zmaterializowanego widoku schema, usługa Databricks zaleca, aby nie udostępniać bazowego magazynu niezaufanym odbiorcom 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 rzeczywistej valuesfield_a.

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

Obszar roboczy może zawierać potoki korzystające z Unity Catalog i starszego magazynu metadanych Hive. Jednak pojedynczy potok nie może zapisywać w metastore Hive i w środowisku Unity Catalog. Nie można zaktualizować istniejących rurociągów zapisujących do magazynu metadanych Hive, aby używać systemu Unity Catalog.

Istniejące potoki, które nie używają aparatu Unity Catalog, pozostają bez wpływu przy tworzeniu nowych potoków skonfigurowanych z użyciem aparatu 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 funkcje usługi Delta Live Tables są obsługiwane z potokami używającymi aparatu Unity Catalog. Interfejsy Python i SQL są obsługiwane z potokami z wykorzystaniem Unity Catalog.

Zmiany istniejących funkcji

Gdy usługa Delta Live Tables jest skonfigurowana do utrwalania danych na platformie Unity Catalog, cykl życia table jest zarządzany przez potok Delta Live Tables. Ponieważ potok danych zarządza cyklem życia i uprawnieniami table.

  • Po usunięciu table z definicji potoku Delta Live Tables odpowiedni zmaterializowany widok lub wpis table przesyłania strumieniowego zostanie usunięty z Unity Catalog podczas następnego potoku update. 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 przesyłanie strumieniowe table z powrotem do definicji potoku.
  • Usunięcie potoku Delta Live Tables powoduje usunięcie wszystkich tables zdefiniowanych w tym potoku. Ze względu na tę zmianę interfejs użytkownika usługi Delta Live Tables jest aktualizowany w celu wyświetlenia monitu o potwierdzenie usunięcia potoku.
  • Wewnętrzne pomocnicze tables, w tym te używane do obsługi APPLY CHANGES INTO, nie są bezpośrednio dostępne dla użytkowników.

zapisywanie tables na platformie Unity Catalog z potoku usługi Delta Live Tables

Uwaga

Jeśli nie wykonasz selectcatalog i nie ustawisz docelowego schema dla potoku, tables nie są publikowane w środowisku Unity Catalog i mogą być dostępne tylko poprzez zapytania w tym samym potoku.

Aby zapisać twój tables w Unity Catalog, musisz skonfigurować potok do działania z nim za pośrednictwem swojego obszaru roboczego. Po utworzeniupotoku Unity w obszarze Opcje magazynu w menu rozwijanym i istniejącą lub wprowadź nazwę nowej w menu rozwijanym Target . Aby dowiedzieć się więcej o Unity Catalogcatalogs, zobacz Co to są catalogs w usłudze Azure Databricks?. Aby dowiedzieć się więcej o schematach w usłudze Unity Catalog, zobacz Co to są schematy w usłudze Azure Databricks?.

Importowanie danych do potoku Catalog Unity

Potok skonfigurowany do korzystania z aparatu Unity Catalog może odczytywać dane z:

  • Catalog zarządzane i zewnętrzne tables, views, zmaterializowane views i tablesstrumieniowanie.
  • Magazyn metadanych Hive tables i views.
  • Automatyczne ładowanie, używając funkcji read_files(), do odczytu z zewnętrznych lokalizacji w Unity Catalog.
  • Apache Kafka i Amazon Kinesis.

Poniżej przedstawiono przykłady odczytu z Catalog unity i magazynu metadanych Hive tables.

Wsadowe pobieranie danych z systemu Unity Catalogtable

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")

Przekaz zmian z Unity Catalogtable

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 danych używający Catalog aparatu Unity może odczytywać dane z magazynu metadanych Hive tables przy użyciu hive_metastorecatalog:

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ępnij zmaterializowaną views

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 table przy użyciu instrukcji GRANT, a dostęp do zapytań można revoke przy użyciu instrukcji REVOKE. Aby uzyskać więcej informacji na temat uprawnień w usłudze Unity Catalog, zobacz Zarządzanie uprawnieniami w programie Unity Catalog.

Grant select w table

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

Revoke select w table

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

Grant utworzyć table lub utworzyć zmaterializowane uprawnienia widoku

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

Wyświetlanie pochodzenia potoku

Pochodzenie tables w przepływie usługi Delta Live Tables jest widoczne w Eksploratorze Catalog. Interfejs użytkownika linii produktów Catalog Explorer pokazuje strumienie w górę i w dół tables dla zmaterializowanych views lub przesyłania strumieniowego tables w potoku z obsługą Unity Catalog. Aby dowiedzieć się więcej na temat pochodzenia aparatu Unity, zobacz Capture and view data lineage using Unity (Przechwytywanie i wyświetlanie pochodzenia danych przy użyciu aparatu Unity ).

W przypadku zmaterializowanego widoku lub przesyłania strumieniowego table w potoku z włączoną obsługą Unity CatalogDelta Live Tables, interfejs pochodzenia w Eksploratorze Catalog będzie również łączyć się z potokiem, który wygenerował zmaterializowany widok lub przesyłanie strumieniowe table, jeśli potok jest dostępny z bieżącego obszaru roboczego.

Dodawanie, zmienianie lub usuwanie danych w table przesyłaniu strumieniowym

Instrukcje języka manipulowania danymi (DML) , w tym instrukcje , , usuwanie i scalanie, umożliwiają modyfikowanie przesyłania strumieniowego opublikowanego na platformie Unity . Obsługa zapytań DML na danych strumieniowych tables umożliwia takie zastosowania, jak aktualizowanie tables w celu zachowania zgodności z ogólnym rozporządzeniem o ochronie danych (RODO).

Uwaga

  • Instrukcje DML modyfikujące tableschematable przesyłania strumieniowego nie są obsługiwane. Upewnij się, że instrukcje DML nie próbują rozwijać tableschema.
  • Instrukcje DML, które update przesyłanie strumieniowe table, mogą być uruchamiane tylko w udostępnionym klastrze Unity Catalog lub w 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łowego ze zmianami (na przykład instrukcjami DML), flagę skipChangeCommits podczas odczytywania źródłowej przesyłania strumieniowego . Gdy skipChangeCommits jest set, transakcje, które usuwają lub modyfikują rekordy w table źródłowym, są ignorowane. Jeśli przetwarzanie nie wymaga przesyłania strumieniowego table, można użyć zmaterializowanego widoku (który nie ma ograniczenia do tylko dołączania) jako docelowego table.

Poniżej przedstawiono przykłady instrukcji DML służących do modyfikacji rekordów w strumieniowym przesyle table.

Usuń rekordy z określonym identyfikatorem:

DELETE FROM my_streaming_table WHERE id = 123;

Update rekordy o określonym identyfikatorze:

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

Publikowanie tables z filtrami wierszy i maskami column

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 table skanowanie pobiera wiersze. Te filtry zapewniają, że kolejne zapytania zwracają tylko wiersze, dla których predykat filtru daje wartość true.

Column maski pozwalają maskować valuescolumnza każdym razem, gdy skanowanie table pobiera wiersze. Przyszłe zapytania dotyczące tej column zwracają wynik ocenianej funkcji zamiast oryginalnej wartości column. Aby uzyskać więcej informacji na temat używania filtrów wierszy i masek column, zobacz Filtruj poufne dane table przy użyciu filtrów wierszy i masek column.

Zarządzanie filtrami wierszy i maskami Column

Filtry wierszy i maski column dla zmaterializowanych views i strumieniowych tables należy dodać, zaktualizować lub usunąć za pomocą instrukcji CREATE OR REFRESH.

Aby uzyskać szczegółową składnię definiowania tables z filtrami wierszy i maskami column, zobacz dokumentację języka Delta Live Tables SQL i dokumentację języka Python usługi Delta Live Tables.

Zachowanie

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

  • Refresh jako właściciel: gdy potok update odświeża zmaterializowany widok lub przesyłanie strumieniowe table, funkcje filtru wierszy oraz maskowania column są uruchamiane z prawami właściciela potoku. Oznacza to, że tablerefresh używa 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 tableprzesył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 zmaterializowanej views nad źródłem tables, które zawierają filtry wierszy i maski column, refresh widoku zmaterializowanego jest zawsze całkowitym refresh. Pełne refresh przetworzenie wszystkich danych dostępnych w źródle z najnowszymi definicjami. Ten proces sprawdza, czy zasady zabezpieczeń w źródłowym tables są oceniane i stosowane na podstawie najnowszych danych i definicji up-to.

Wgląd w informacje

Użyj DESCRIBE EXTENDED, INFORMATION_SCHEMAlub Eksploratora Catalog, aby zbadać istniejące filtry wierszy i maski column, które mają zastosowanie do danego zmaterializowanego widoku lub do transmisji strumieniowej table. Ta funkcja umożliwia użytkownikom przeprowadzanie inspekcji i przeglądu środków dostępu do danych i ochrony w przypadku zmaterializowanych views i przesyłania strumieniowego tables.