Omówienie cyklu życia zapytań

Przyjrzyjmy się, w jaki sposób Unity Catalog zarządza wykonywaniem zapytań, ze szczególnym uwzględnieniem zabezpieczeń i kontroli administracyjnych. Omówimy krok po kroku, co się stanie po przesłaniu zapytania względem tabeli Unity Catalog, obejmując interakcje między zasobami obliczeniowymi, płaszczyzną sterowania, płaszczyzną danych i przechowywaniem danych w chmurze.

Cykl życia zapytania w katalogu Unity Catalog

Na poniższym diagramie przedstawiono ogólny przepływ zapytania, gdy przechodzi przez różne składniki Unity Catalogu.

Krok 1. Przesyłanie zapytań

Ten cykl życia rozpoczyna się, gdy podmiot (tożsamość użytkownika lub usługi) generuje zapytanie. Zapytania mogą pochodzić na różne sposoby:

• Analityk danych może używać klastra ogólnego przeznaczenia na potrzeby interaktywnych obciążeń języka Python lub SQL.
• Jednostka usługi może uruchamiać zaplanowany potok lub zadanie w klastrze zadań.
• Analityk danych może wysłać zapytanie za pośrednictwem usługi Databricks SQL przy użyciu usługi SQL Warehouse.
• Narzędzie analizy biznesowej połączone z usługą SQL Warehouse może również wygenerować żądanie.

W każdym przypadku zasób obliczeniowy — klaster lub magazyn — odbiera zapytanie i rozpoczyna wykonywanie.

Krok 2: Weryfikacja w katalogu Unity

Zasób obliczeniowy przekazuje żądanie do Unity Catalog. Unity Catalog działa jako świat kontroli na potrzeby zabezpieczeń i ładu. Rejestruje żądanie w dzienniku inspekcji i sprawdza, czy użytkownik ma niezbędne uprawnienia do dostępu do obiektów, do których odwołuje się zapytanie. Jeśli uprawnienia zostaną odrzucone, zapytanie zostanie zablokowane, a odmowa zostanie zarejestrowana. Jeśli dostęp zostanie udzielony, żądanie przejdzie do przodu.

Krok 3. Przypisanie poświadczeń do chmury

W przypadku każdego obiektu, do którego odwołuje się zapytanie, Unity Catalog przyjmuje odpowiednie poświadczenia chmury skojarzone z tym obiektem. Te poświadczenia są konfigurowane przez administratora chmury.

• W przypadku tabel zarządzanych poświadczenie zwykle wskazuje na magazyn w chmurze powiązany z metastore Unity Catalog.
• W przypadku tabel zewnętrznych lub plików poświadczenie jest przypisane do lokalizacji zewnętrznej zarządzanej za pomocą zdefiniowanego poświadczenia magazynowego.

Krok 4. Wystawianie tokenów o określonym zakresie

Po zweryfikowaniu poświadczeń Unity Catalog generuje tymczasowy token dostępu o określonym zakresie dla każdego obiektu. Wraz z tokenem zapewnia on bezpieczny adres URL dostępu. To pozwala zasobowi obliczeniowemu odczytywać bezpośrednio z przechowywania, bez ujawniania długotrwałych poświadczeń.

Krok 5. Dostęp do danych z magazynu

Zasób obliczeniowy (klaster lub magazyn SQL) używa tokenu i adresu URL dostarczonego przez Unity Catalog do żądania danych bezpośrednio z docelowych punktów końcowych usługi ADLS Gen2 (za pośrednictwem abfss:// lub dfs.core.windows.net adresu URL)

Krok 6. Transfer danych

Magazyn w chmurze zwraca żądane dane do zasobu obliczeniowego. Ten proces jest powtarzany dla każdego obiektu, do których odwołuje się zapytanie.

Krok 7. Szczegółowe filtrowanie

Katalog Unity wymusza filtry na poziomie wierszy i kolumn na samym zasobie obliczeniowym. Dzięki temu użytkownicy będą widzieć tylko konkretny podzbiór danych, do których mają dostęp.

• Filtrowanie na poziomie wiersza wprowadza warunki, które są oceniane w czasie wykonywania zapytań wewnątrz aparatu obliczeniowego. Mimo że bazowy system magazynowania może zwrócić szerszy zestaw danych, Unity Catalog gwarantuje, że tylko wiersze pasujące do zdefiniowanych warunków są widoczne dla żądającego głównego użytkownika. Dzięki temu wielu użytkowników może wykonywać zapytania dotyczące tej samej tabeli, ale każdy z nich otrzymuje spersonalizowany, ograniczony widok danych. Funkcja filtrowania wierszy jest w zasadzie predykatem (wyrażenie SQL lub funkcja zdefiniowana przez użytkownika), która jest oceniana podczas wykonywania zapytania.

• Filtrowanie na poziomie kolumny działa podobnie, ale na poziomie atrybutu. Określone kolumny mogą być maskowane lub przekształcane tak, aby dane poufne były ukryte lub zanonimizowane, w zależności od uprawnień głównego użytkownika. Dzięki temu można szeroko udostępniać zestawy danych przy jednoczesnym zapewnieniu, że poufne pola są w pełni widoczne tylko dla tych, którzy mają odpowiednią autoryzację.

Krok 8. Zwracanie wyniku

Filtrowany wynik zapytania jest zwracany z zasobu obliczeniowego do wywołującego użytkownika, zadania lub aplikacji.

Jak działają zapytania z usługą Apache Hive

Unity Catalog został zaprojektowany tak, aby usprawnić zarządzanie, ale zapewnia również zgodność z tradycyjnym metastore Hive. Po przypisaniu obszaru roboczego do metastore Unity Catalog, Hive będzie widoczny jako specjalny katalog o nazwie hive_metastore. Tabele przechowywane tam nadal mogą być odpytywane przez odwoływanie się do tego wykazu w przestrzeni nazw.

Cykl życia zapytania względem tabeli Hive różni się od Unity Catalog na kilka sposobów:

• Hive nie zapewnia scentralizowanego, szczegółowego ładu. Zamiast tego administratorzy często muszą zarządzać kontami usług, kluczami tajnymi lub profilami instancji w celu uwierzytelniania i autoryzacji.
• Dostęp do danych może obejmować konfigurowanie punktów montowania, uwierzytelniania typu passthrough lub polityk przechowywania, z których każda wymaga dodatkowej konfiguracji.
• Logowanie audytu i kontrole dostępu są mniej zintegrowane w porównaniu z Unity Catalog, co może prowadzić do niespójności w egzekwowaniu zabezpieczeń.

Krok 1. Przesyłanie zapytań

Podmiot (użytkownik lub usługa) wysyła zapytanie do klastra lub punktu końcowego bazy danych SQL. Jest to punkt wyjścia dla wszystkich zapytań Hive.

Krok 2. Sprawdzanie dostępu

Klaster sprawdza zapytanie względem list kontroli dostępu do tabel (ACL). Te ACL określają, czy podmiot żądający ma prawo dostępu do określonej tabeli.

Krok 3. Wyszukiwanie lokalizacji

Jeśli dostęp zostanie udzielony, klaster skonsultuje się z magazynem metadanych Hive , aby znaleźć lokalizację magazynu tabeli. Magazyn metadanych zawiera metadane dotyczące tabel, w tym ich schematy i ścieżki przechowywania.

Krok 4. Zwrócona ścieżka

Magazyn metadanych Hive zwraca ścieżkę przechowywania do klastra, zwykle jako identyfikator URI (na przykład abfss://...). Ta ścieżka określa fizyczne miejsce danych tabeli w magazynie danych w chmurze.

Krok 5. Żądanie danych

Klaster próbuje odczytać dane z magazynu w chmurze. Na tym etapie musi uwierzytelniać się przy użyciu jednego z kilku mechanizmów, takich jak zasada usługi, przekazywanie uwierzytelniania lub profil instancji. Administratorzy często muszą z wyprzedzeniem konfigurować te poświadczenia, tak jak tajne dane i punkty montowania.

Krok 6. Zwrócone dane

Magazyn w chmurze wysyła żądane dane z powrotem do klastra.

Krok 7. Wymuszanie zasad

Klaster wymusza filtrowanie końcowych elementów w celu usunięcia danych, których podmiot nie powinien widzieć. Może to obejmować stosowanie ograniczeń na poziomie wiersza lub kolumny w czasie wykonywania zapytania.

Krok 8. Dostarczanie wyników

Końcowy wynik zapytania jest przekazywany z powrotem do głównego podmiotu, który wystawił żądanie.

W praktyce oznacza to, że wykonywanie zapytań dotyczących programu Hive wymaga bardziej ręcznych kroków administracyjnych i ciągłej konserwacji. Unity Catalog zmniejsza to obciążenie, automatyzując obsługę poświadczeń, dostarczając tokeny o zdefiniowanym zakresie i spójnie wymuszając zasady we wszystkich obiektach.