Co to jest katalog Unity?

Katalog Unity to zintegrowane rozwiązanie do zarządzania danymi i sztuczną inteligencją wbudowane bezpośrednio w platformę Azure Databricks. Jest to omówienie kluczowych pojęć w Unity Catalog oraz sposobu używania Unity Catalog do zarządzania danymi.

Najważniejsze filary Unity Catalog obejmują:

• Ujednolicona kontrola dostępu: Unity Catalog oferuje jednolite miejsce do zarządzania uprawnieniami do tabel, plików, modeli i innych obiektów za pomocą jednego interfejsu.
• Odnajdywanie danych: Katalog Unity umożliwia użytkownikom odnajdywanie i zrozumienie zasobów danych poprzez interfejs z możliwością wyszukiwania, wzbogacony tagami, opisami i metadanymi.
• Zautomatyzowane śledzenie pochodzenia: Automatycznie śledź przepływ danych oraz ich przekształcanie od źródła do końcowych widoków i paneli kontrolnych.
• Inspekcji: Zachowaj pełny rekord wszystkich działań dotyczących dostępu do danych i systemu, aby spełnić wymagania dotyczące zabezpieczeń i zgodność z przepisami.
• Monitorowanie jakości danych: Proaktywne śledzenie kondycji zasobów danych za pomocą wbudowanego profilowania i alertów, które przechwytują anomalie przed dotarciem do odbiorców podrzędnych.
• Bezpieczne udostępnianie danych: Bezpiecznie wymieniaj dane na żywo między organizacjami i chmurami przy użyciu otwartego protokołu delta sharing, eliminując konieczność złożonego etL lub kopiowania danych.

Katalog Unity jest również dostępny jako implementacja open-source. Zapoznaj się z blogiem z ogłoszeniami i publicznym repozytorium GitHub Unity Catalog.

Model obiektów Katalogu Unity

W Unity Catalog każdy zasób, którym zarządzasz, jest modelowany jako obiekt. W szczególności te obiekty są nazywane obiektami możliwymi do zabezpieczenia w Unity Catalog. Zasady kontroli dostępu i metadane, takie jak tagi, umożliwiają zarządzanie tymi zabezpieczanymi obiektami.

Zabezpieczane obiekty znajdują się w hierarchii modelu obiektów Unity Catalog, u podstaw której leży specjalny obiekt nazywany metastore. W tym obszarze zasoby danych, takie jak tabele, widoki, woluminy, funkcje i modele, są zgodne z trzy-poziomową przestrzenią nazw (catalog.schema.object). Inne obiekty, takie jak poświadczenia magazynu, lokalizacje zewnętrzne, połączenia i udziały, znajdują się bezpośrednio w magazynie metadanych.

Ta hierarchia jest podstawą sposobu, w jaki Unity Catalog organizuje zasoby i egzekwuje zarządzanie. Aby lepiej zrozumieć model obiektów Unity Catalog i każdy obiekt z możliwością zabezpieczenia, zobacz Referencja do obiektów z możliwością zabezpieczenia w Unity Catalog. Aby dowiedzieć się, jak działa model uprawnień w kontekście modelu obiektowego Katalogu Unity, zobacz Pojęcia dotyczące modelu uprawnień Katalogu Unity.

Role administracyjne

Administratorzy są odpowiedzialni za nadzorowanie zarządzania w katalogu Unity. Poniżej przedstawiono różne poziomy ról administratora i ich uprawnienia domyślne:

• Administratorzy kont mogą tworzyć magazyny metadanych, łączyć obszary robocze z magazynami metadanych, dodawać użytkowników i przypisywać uprawnienia do magazynów metadanych.
• Administratorzy obszaru roboczego mogą dodawać użytkowników do obszaru roboczego i zarządzać wieloma obiektami specyficznymi dla obszaru roboczego, takimi jak zadania i notesy. W zależności od obszaru roboczego administratorzy obszaru roboczego mogą również mieć wiele uprawnień do magazynu metadanych dołączonego do obszaru roboczego.
• Administratorzy magazynu metadanych to opcjonalne role, które mogą zarządzać magazynem tabel i woluminów na poziomie magazynu metadanych. Jest również wygodne, jeśli chcesz centralnie zarządzać danymi w wielu obszarach roboczych w regionie.

Aby uzyskać więcej informacji, zobacz Uprawnienia administratora w Unity Catalog.

Udzielanie i odwołowanie dostępu do zabezpieczanych obiektów

Uprzywilejowani użytkownicy mogą udzielać i odwoływać dostęp do zabezpieczanych obiektów na dowolnym poziomie w hierarchii, w tym samego magazynu metadanych. Dostęp do obiektu niejawnie udziela tego samego dostępu wszystkim elementom podrzędnym tego obiektu, chyba że dostęp zostanie cofnięty.

Można używać typowych poleceń ANSI SQL do udzielania i odwoływania dostępu do obiektów w Unity Catalog. Na przykład:

GRANT CREATE TABLE ON SCHEMA mycatalog.myschema TO `finance-team`;

Do zarządzania uprawnieniami obiektów można również użyć Eksploratora wykazu, interfejsu wiersza polecenia usługi Databricks i interfejsów API REST.

Administratorzy magazynu metadanych, właściciele obiektu i użytkownicy z MANAGE privilege obiektem na obiekcie mogą udzielać i odwoływać dostęp. Aby dowiedzieć się, jak zarządzać uprawnieniami w Unity Catalog, zobacz Zarządzanie uprawnieniami w Unity Catalog.

Domyślny dostęp do obiektów bazy danych w katalogu Unity Catalog

Katalog Unity działa na zasadzie najmniejszych uprawnień, gdzie użytkownicy mają niezbędne minimum dostępu, którego potrzebują do wykonywania wymaganych zadań. Po utworzeniu obszaru roboczego użytkownicy niebędący administratorami mają dostęp tylko do automatycznie aprowizowanego katalogu obszarów roboczych, co sprawia, że ten katalog jest wygodnym miejscem dla użytkowników w celu wypróbowania procesu tworzenia i uzyskiwania dostępu do obiektów bazy danych w katalogu Unity. Zobacz Uprawnienia katalogu obszarów roboczych.

Zarządzane i zewnętrzne tabele i woluminy

Tabele i wolumeny mogą być zarządzane albo zewnętrzne.

• Tabele zarządzane są w pełni zarządzane przez Unity Catalog, co oznacza, że Unity Catalog zarządza zarówno zarządzaniem, jak i bazowymi plikami danych dla każdej zarządzanej tabeli. Tabele zarządzane są przechowywane w lokalizacji zarządzanej przez Unity Catalog w magazynie w chmurze. Tabele zarządzane zawsze używają formatu usługi Delta Lake. Tabele zarządzane można przechowywać na poziomach magazynu metadanych, katalogu lub schematu.
• Tabele zewnętrzne to tabele, których dostęp z usługi Azure Databricks jest zarządzany przez Unity Catalog, ale których cykl życia danych i układ plików są zarządzane za pomocą dostawcy chmury oraz innych platform danych. Zazwyczaj używasz tabel zewnętrznych do rejestrowania dużych ilości istniejących danych w usłudze Azure Databricks lub jeśli potrzebujesz również dostępu do zapisu do danych przy użyciu narzędzi spoza usługi Azure Databricks. Tabele zewnętrzne są obsługiwane w wielu formatach danych. Po zarejestrowaniu tabeli zewnętrznej w metasklepie Unity Catalog, możesz zarządzać dostępem i przeprowadzać audyt dostępu w usłudze Azure Databricks---i pracować z nią---dokładnie tak jak w przypadku tabel zarządzanych.
• Woluminy zarządzane są w pełni zarządzane przez Unity Catalog, co oznacza, że Unity Catalog zarządza dostępem do lokalizacji magazynu woluminu na koncie dostawcy chmury. Tworząc wolumin zarządzany, jest on automatycznie przechowywany w zarządzanej lokalizacji magazynu, przypisanej do powiązanego schematu.
• Woluminy zewnętrzne reprezentują istniejące dane w lokalizacjach przechowywania zarządzanych poza Azure Databricks, ale zarejestrowane w Unity Catalogu w celu kontrolowania i audytowania dostępu z wewnątrz Azure Databricks. Podczas tworzenia woluminu zewnętrznego w usłudze Azure Databricks należy określić jego lokalizację, która musi znajdować się na ścieżce zdefiniowanej w lokalizacji zewnętrznej aparatu Unity Catalog.

Usługa Databricks zaleca stosowanie zarządzanych tabel i woluminów w większości przypadków użycia, ponieważ pozwalają one w pełni wykorzystać możliwości zarządzania danymi w katalogu Unity oraz zoptymalizować wydajność. Aby uzyskać informacje na temat typowych przypadków użycia tabel i woluminów zewnętrznych, zobacz Zarządzane i zewnętrzne tabele oraz Woluminy zarządzane i zewnętrzne.

Zobacz również:

• Zarządzane przez Unity Catalog tabele w Azure Databricks dla Delta Lake i Apache Iceberg
• praca z tabelami zewnętrznymi
• Zarządzane i zewnętrzne woluminy.

Magazynowanie w chmurze i izolacja danych

Unity Catalog używa przechowywania w chmurze na dwa podstawowe sposoby:

• Magazyn zarządzany: domyślne lokalizacje dla zarządzanych tabel i woluminów zarządzanych (dane nieustrukturyzowane, inne niż tabelaryczne), które są tworzone w usłudze Azure Databricks. Te zarządzane lokalizacje magazynu można zdefiniować na poziomie magazynu metadanych, katalogu lub schematu. Tworzysz zarządzane lokalizacje magazynu u swojego dostawcy usług w chmurze, ale ich cykl życia jest w pełni zarządzany przez Unity Catalog.
• Miejsca przechowywania, w których przechowywane są zewnętrzne tabele i woluminy. Są to tabele i wolumeny, których dostęp z usługi Azure Databricks jest zarządzany przez Unity Catalog, ale których cykl życia danych i układ plików są zarządzane przy użyciu Twojego dostawcy chmury i innych platform danych. Zazwyczaj używasz tabel zewnętrznych lub woluminów do rejestrowania dużych ilości istniejących danych w usłudze Azure Databricks lub jeśli potrzebujesz również dostępu do zapisu do danych przy użyciu narzędzi spoza usługi Azure Databricks.

Zarządzanie dostępem do magazynu w chmurze przy użyciu lokalizacji zewnętrznych

Zarówno zarządzane lokalizacje magazynu, jak i lokalizacje magazynu, gdzie przechowywane są zewnętrzne tabele i woluminy, używają zabezpieczalnych obiektów lokalizacji zewnętrznych do zarządzania dostępem z usługi Azure Databricks. Obiekty lokalizacji zewnętrznej odwołują się do ścieżki magazynu w chmurze i poświadczeń magazynu wymaganych do uzyskania do niego dostępu. Poświadczenia magazynowe są obiektami zabezpieczalnymi w ramach Unity Catalog, które rejestrują wymagane poświadczenia do uzyskania dostępu do określonej ścieżki magazynowej. Razem te zabezpieczenia zapewniają, że dostęp do magazynu jest kontrolowany i śledzony przez Unity Catalog.

Na poniższym diagramie pokazano, jak lokalizacje zewnętrzne odwołują się do poświadczeń magazynu i lokalizacji magazynu w chmurze.

Na tym diagramie:

• Każda lokalizacja zewnętrzna odwołuje się do poświadczeń magazynu i lokalizacji magazynu w chmurze.
• Wiele lokalizacji zewnętrznych może odwoływać się do tego samego poświadczenia magazynu. Poświadczenie magazynu 1 daje dostęp do wszystkiego w ramach ścieżki bucket/tables/*, więc do niej odwołuje się zarówno lokalizacja zewnętrzna A, jak i lokalizacja zewnętrzna B.

Aby uzyskać więcej informacji, zobacz Jak Unity Catalog zarządza dostępem do pamięci masowej w chmurze?.

Hierarchia lokalizacji magazynu zarządzanego

Poziom, na którym definiujesz zarządzany magazyn w Unity Catalogu, zależy od preferowanego modelu izolacji danych. Organizacja może wymagać przechowywania określonych typów danych na określonych kontach lub zasobnikach w dzierżawie chmury.

Katalog Unity umożliwia konfigurowanie zarządzanych lokalizacji magazynu na poziomie hurtowni danych, katalogu lub schematu w celu spełnienia takich wymagań.

Załóżmy na przykład, że twoja organizacja ma politykę zgodności firmy, która wymaga, aby dane produkcyjne dotyczące zasobów ludzkich były przechowywane w kontenerze abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net. W Unity Catalog można osiągnąć to wymaganie, określając lokalizację na poziomie katalogu, tworząc katalog o nazwie, na przykład hr_prod, i przypisując lokalizację abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog do tego katalogu. Oznacza to, że zarządzane tabele lub woluminy utworzone w wykazie hr_prod (na przykład przy użyciu CREATE TABLE hr_prod.default.table …) przechowują swoje dane w katalogu abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog. Możesz opcjonalnie podać lokalizacje dotyczące poziomu schematu w celu bardziej szczegółowego organizowania danych w hr_prod catalog.

Jeśli izolacja magazynu nie jest wymagana dla niektórych katalogów, możesz opcjonalnie ustawić lokalizację magazynu na poziomie magazynu metadanych. Ta lokalizacja służy jako domyślna lokalizacja dla zarządzanych tabel i woluminów w katalogach i schematach, które nie mają przypisanego magazynu. Zazwyczaj jednak usługa Databricks zaleca przypisanie oddzielnych zarządzanych lokalizacji magazynu dla każdego katalogu.

System ocenia hierarchię lokalizacji magazynu ze schematu do wykazu do magazynu metadanych.

Jeśli na przykład tabela myCatalog.mySchema.myTable jest tworzona w my-region-metastoreprogramie , lokalizacja magazynu tabel jest określana zgodnie z następującą regułą:

1. Jeśli lokalizacja została podana dla mySchema, zostanie tam zapisana.
2. Jeśli nie, a lokalizacja została podana na myCatalog, zostanie tam zapisana.
3. Na koniec, jeśli w lokalizacji myCatalognie podano lokalizacji , zostanie ona zapisana w lokalizacji skojarzonej z elementem my-region-metastore.

Aby uzyskać więcej informacji, zobacz Określanie zarządzanej miejsca przechowywania w Unity Catalog.

Izolacja środowiska przy użyciu powiązania katalogu obszarów roboczych

Domyślnie właściciele katalogu (i administratorzy magazynu metadanych, jeśli są zdefiniowani dla konta) mogą uczynić katalog dostępnym dla użytkowników w wielu dołączonych obszarach roboczych powiązanych z tym samym magazynem metadanych Unity Catalog.

Wymagania dotyczące organizacji i zgodności często określają, że niektóre dane, takie jak dane osobowe, są dostępne tylko w niektórych środowiskach. Możesz również zachować dane produkcyjne odizolowane od środowisk deweloperskich lub upewnić się, że niektóre zestawy danych i domeny nigdy nie są połączone razem.

W usłudze Azure Databricks obszar roboczy jest podstawowym środowiskiem przetwarzania danych, a katalogi są domeną danych podstawowych. Unity Catalog umożliwia administratorom magazynu metadanych, właścicielom katalogu oraz użytkownikom z uprawnieniami MANAGE przypisywanie, czyli „wiążenie”, katalogów z określonymi obszarami roboczymi. Te powiązania obsługujące środowisko umożliwiają zapewnienie, że tylko niektóre wykazy są dostępne w obszarze roboczym, niezależnie od określonych uprawnień do obiektów danych przyznanych użytkownikowi. Jeśli używasz obszarów roboczych do izolowania dostępu do danych użytkowników, możesz jednak ograniczyć dostęp katalogu do określonych obszarów roboczych na koncie, aby upewnić się, że niektóre rodzaje danych są przetwarzane tylko w tych obszarach roboczych. Możesz chcieć oddzielić obszary robocze produkcyjne i programistyczne, na przykład lub oddzielny obszar roboczy do przetwarzania danych osobowych. Jest to nazywane powiązaniem katalogu obszarów roboczych. Zobacz Ograniczanie dostępu katalogu do określonych obszarów roboczych.

Uwaga

W celu zwiększenia izolacji danych można również powiązać dostęp do magazynu w chmurze i dostęp usługi w chmurze do określonych obszarów roboczych. Zobacz (Opcjonalnie) Przypisywanie poświadczeń magazynu do określonych obszarów roboczych, (opcjonalnie) Przypisywanie lokalizacji zewnętrznej do określonych obszarów roboczych i (opcjonalnie) Przypisywanie poświadczeń usługi do określonych obszarów roboczych.

Jak skonfigurować Unity Catalog dla mojej organizacji?

Aby można było korzystać z Unity Catalog, obszar roboczy usługi Azure Databricks musi być włączony do Unity Catalog, co oznacza, że obszar roboczy jest dołączony do metastore Unity Catalog.

Jak obszar roboczy jest powiązany z magazynem metadanych? Zależy to od konta i obszaru roboczego:

• Zazwyczaj podczas tworzenia obszaru roboczego usługi Azure Databricks w regionie po raz pierwszy magazyn metadanych jest tworzony automatycznie i dołączany do obszaru roboczego.
• W przypadku niektórych starszych kont administrator konta musi utworzyć magazyn metadanych i przypisać obszary robocze w tym regionie do magazynu metadanych. Aby uzyskać instrukcje, zobacz Tworzenie katalogu Unity.
• Jeśli konto ma już przypisany magazyn metadanych dla regionu, administrator konta może zdecydować, czy automatycznie dołączyć magazyn metadanych do wszystkich nowych obszarów roboczych w tym regionie. Zobacz Włączanie automatycznego przypisywanie magazynu metadanych do nowych obszarów roboczych.

Czy obszar roboczy został włączony automatycznie dla Unity Catalog, czy nie, należy również wykonać następujące kroki, aby rozpocząć pracę z Unity Catalog:

• Utwórz wykazy i schematy, aby zawierały obiekty bazy danych, takie jak tabele i woluminy.
• Utwórz zarządzone lokalizacje przechowywania do przechowywania zarządzanych tabel i woluminów w tych schematach i katalogach.
• Udziel użytkownikowi dostępu do katalogów, schematów i obiektów bazy danych.

Obszary robocze, które automatycznie są włączane dla Unity Catalog, tworzą wykaz obszarów roboczych z obszernymi uprawnieniami przyznanymi wszystkim użytkownikom obszaru roboczego. Ten katalog jest wygodnym punktem wyjścia do wypróbowania Unity Catalog.

Aby uzyskać szczegółowe instrukcje dotyczące konfiguracji, zobacz Rozpoczęcie pracy z Unity Catalog.

Podniesienie wersji istniejącego obszaru roboczego do Unity Catalog

Aby dowiedzieć się, jak uaktualnić obszar roboczy innych niż Katalog Unity do Katalogu Unity, zobacz Uaktualnianie obszaru roboczego usługi Azure Databricks do Katalogu Unity.

Wymagania i ograniczenia katalogu Unity

Unity Catalog wymaga określonych typów obliczeń i formatów plików, opisanych poniżej. Poniżej wymieniono również niektóre funkcje usługi Azure Databricks, które nie są w pełni obsługiwane w katalogu Unity we wszystkich wersjach Databricks Runtime.

Obsługa regionów

Wszystkie regiony obsługują Unity Catalog. Aby uzyskać szczegółowe informacje, zobacz Regiony usługi Azure Databricks.

Wymagania dotyczące obliczeń

Unity Catalog jest obsługiwany na klastrach z uruchomionym Databricks Runtime 11.3 LTS lub nowszym. Katalog Unity jest domyślnie obsługiwany we wszystkich wersjach obliczeniowych SQL Warehouse.

Klastry działające we wcześniejszych wersjach Databricks Runtime nie zapewniają obsługi wszystkich funkcji i możliwości Unity Catalog w wersji GA.

Aby uzyskać dostęp do danych w Unity Catalog, klastry muszą być skonfigurowane z odpowiednim trybem dostępu. Katalog aparatu Unity jest domyślnie bezpieczny. Jeśli klaster nie jest skonfigurowany w standardowym lub dedykowanym trybie dostępu, nie może uzyskać dostępu do danych w Unity Catalog. Zobacz Tryby dostępu.

Aby uzyskać szczegółowe informacje o zmianach w funkcjonalności Unity Catalog w każdej wersji Databricks Runtime, zobacz uwagi o wersji.

Obsługa formatu pliku

Katalog Unity obsługuje następujące formaty tabel.

• Tabele zarządzane muszą używać delta formatu tabeli lub iceberg .
• Tabele zewnętrzne mogą używać delta, , CSV, JSONavro, parquetORClub text.

Ograniczenia

Katalog Unity ma następujące ograniczenia. Niektóre z nich są specyficzne dla starszych wersji środowiska Databricks Runtime i trybów dostępu obliczeniowego.

Obciążenia strukturalnego przesyłania strumieniowego mają dodatkowe ograniczenia, w zależności od wersji Databricks Runtime i trybu dostępu. Zobacz Wymagania i ograniczenia dotyczące obliczeń standardowych orazwymagania i ograniczenia dotyczące dedykowanych zasobów obliczeniowych.

Usługa Databricks udostępnia nowe funkcje, które regularnie zmniejszają tę listę.

• Nie można używać grup utworzonych wcześniej w obszarze roboczym (czyli grupach na poziomie obszaru roboczego) w instrukcjach wykazu GRANT aparatu Unity. Ma to na celu zapewnienie jednolitego obrazu grup, które mogą rozciągać się na różne obszary robocze. Aby użyć grup w GRANT instrukcjach, utwórz grupy na poziomie konta i zaktualizuj dowolną automatyzację zarządzania podmiotami lub grupami (takimi jak łączniki SCIM, Okta, Microsoft Entra ID oraz Terraform), aby odnosić się do punktów końcowych konta zamiast punktów końcowych obszaru roboczego. Zobacz Źródła grup.

• Obciążenia w języku R nie obsługują używania widoków dynamicznych na poziomie wiersza lub na poziomie kolumny w obliczeniach z uruchomionym środowiskiem Databricks Runtime 15.3 lub starszym.

  • Użyj dedykowanego zasobu obliczeniowego z uruchomionym środowiskiem Databricks Runtime 15.4 LTS lub nowszym dla obciążeń w języku R, które wysyłają zapytania o dynamiczne widoki. Takie obciążenia wymagają również obszaru roboczego, który jest włączony dla bezserwerowych obliczeń. Aby uzyskać szczegółowe informacje, zobacz Szczegółowa kontrola dostępu w dedykowanych obliczeniach.

• Tabelę zarządzaną można płytko sklonować do innej zarządzanej tabeli w środowisku Databricks Runtime 13.3 LTS lub nowszym. Można płytko sklonować tabelę zewnętrzną do innej tabeli zewnętrznej na Databricks Runtime 14.2 lub nowszym. Nie można płytko sklonować tabeli zarządzanej do tabeli zewnętrznej. Ponadto tabela zewnętrzna nie może być płytko sklonowana do zarządzanej tabeli. Aby uzyskać więcej informacji, zobacz Płytkie klonowanie tabel w katalogu Unity.

• Partycjonowanie nie jest obsługiwane w przypadku tabel Unity Catalog. Jeśli wykonasz polecenia, które próbują utworzyć tabelę zgrupowaną w Unity Catalog, zostanie zgłoszony wyjątek.

• Zapisywanie w tej samej lokalizacji lub tabeli usługi Delta Lake z obszarów roboczych w wielu regionach może prowadzić do nieprzewidywalnej wydajności, jeśli niektóre klastry uzyskują dostęp do Unity Catalog, a inne nie.

• Manipulowanie partycjami dla tabel zewnętrznych przy użyciu poleceń, takich jak ALTER TABLE ADD PARTITION wymaga włączenia rejestrowania metadanych partycji. Zobacz Odnajdywanie partycji dla tabel zewnętrznych.

• W przypadku używania trybu zastępowania dla tabel, które nie są w formacie delty, użytkownik musi mieć uprawnienia CREATE TABLE w schemacie nadrzędnym i musi być właścicielem istniejącego obiektu LUB mieć uprawnienie MODIFY w obiekcie.

• Wersje 12.2 LTS i wcześniejsze środowiska Databricks Runtime nie obsługują funkcji zdefiniowanych przez użytkownika w języku Python. Obejmuje to funkcje agregacyjne zdefiniowane przez użytkownika (UDAFs), funkcje tabelaryczne zdefiniowane przez użytkownika (UDTFs) oraz biblioteki Pandas na platformie Spark (applyInPandas i mapInPandas). Skalarne funkcje zdefiniowane przez użytkownika w języku Python są obsługiwane w Databricks Runtime w wersji 13.3 LTS i wyższej.

• Funkcje zdefiniowane przez użytkownika języka Scala nie są obsługiwane w środowisku Databricks Runtime 14.1 i nowszym w środowisku obliczeniowym ze standardowym trybem dostępu. Skalarne funkcje zdefiniowane przez użytkownika są obsługiwane w środowisku Databricks Runtime 14.2 lub nowszym w środowisku obliczeniowym ze standardowym trybem dostępu.

• Pule wątków w języku Scala w wariancie standardowym nie są obsługiwane. Zamiast tego użyj specjalnych pul wątków w org.apache.spark.util.ThreadUtils, na przykład org.apache.spark.util.ThreadUtils.newDaemonFixedThreadPool. Jednak następujące pule wątków w ThreadUtils nie są obsługiwane: ThreadUtils.newForkJoinPool oraz pula wątków w ScheduledExecutorService.

• Dzienniki diagnostyczne platformy Azure rejestrują tylko zdarzenia Unity Catalog na poziomie obszaru roboczego. Aby wyświetlić akcje na poziomie konta, należy użyć tabeli systemu dzienników inspekcji. Zobacz tabela systemu dziennika audytu.

Modele zarejestrowane w Unity Catalog mają dodatkowe ograniczenia. Zobacz Ograniczenia.

Przydziały zasobów

Unity Catalog wymusza limity przydziału zasobów dla wszystkich zabezpieczanych obiektów. Te limity przydziału są wymienione w temacie Limity zasobów. Jeśli spodziewasz się przekroczyć te limity zasobów, skontaktuj się z zespołem konta usługi Azure Databricks.

Można monitorować zużycie limitu przydziałów za pomocą zasobów API Unity Catalog. Zobacz Monitorowanie użycia przydziałów zasobów w Unity Catalog.

Dodatkowe zasoby

• Nadzór nad danymi za pomocą usługi Azure Databricks
• Uaktualnij obszar roboczy usługi Azure Databricks do Unity Catalog
• najlepsze rozwiązania dotyczące katalogu Unity