Zapytania o dane
Wykonywanie zapytań dotyczących danych jest podstawowym krokiem do wykonywania prawie wszystkich zadań opartych na danych w usłudze Azure Databricks. Niezależnie od używanego języka lub narzędzia obciążenia zaczynają się od zdefiniowania zapytania względem tabeli lub innego źródła danych, a następnie wykonywania akcji w celu uzyskania szczegółowych informacji z danych. W tym artykule opisano podstawowe pojęcia i procedury uruchamiania zapytań w różnych ofertach produktów usługi Azure Databricks oraz przykłady kodu, które można dostosować do danego przypadku użycia.
Dane można wykonywać interaktywnie przy użyciu:
- Notesy
- Edytor SQL
- Edytor plików
- Pulpity nawigacyjne
Można również uruchamiać zapytania w ramach potoków lub zadań Delta Live Tables.
Aby zapoznać się z omówieniem zapytań przesyłanych strumieniowo w usłudze Azure Databricks, zobacz Query streaming data (Wykonywanie zapytań dotyczących danych przesyłanych strumieniowo).
Jakie dane można wykonywać za pomocą usługi Azure Databricks?
Usługa Azure Databricks obsługuje wykonywanie zapytań dotyczących danych w wielu formatach i systemach przedsiębiorstwa. Dane, które wykonujesz za pomocą usługi Azure Databricks, należą do jednej z dwóch szerokich kategorii: danych w usłudze Databricks lakehouse i danych zewnętrznych.
Jakie dane są w magazynie lakehouse usługi Databricks?
Platforma analizy danych usługi Databricks domyślnie przechowuje wszystkie dane w usłudze Databricks Lakehouse.
Oznacza to, że po uruchomieniu podstawowej instrukcji CREATE TABLE w celu utworzenia nowej tabeli utworzono tabelę lakehouse. Dane usługi Lakehouse mają następujące właściwości:
- Przechowywane w formacie usługi Delta Lake.
- Przechowywane w magazynie obiektów w chmurze.
- Podlega katalogowi Unity Catalog.
Większość danych Lakehouse w Azure Databricks jest rejestrowana w Unity Catalog jako tabele zarządzane. Tabele zarządzane zapewniają najłatwiejszą składnię i zachowują się jak inne tabele w większości systemów zarządzania relacyjnymi bazami danych. Tabele zarządzane są zalecane w większości przypadków użycia i są odpowiednie dla wszystkich użytkowników, którzy nie chcą martwić się o szczegóły implementacji magazynu danych.
Tabela niezarządzana lub tabela zewnętrzna to tabela zarejestrowana w określonym LOCATION. Termin zewnętrzny może być mylący, ponieważ zewnętrzne tabele delty są nadal danymi typu lakehouse. Tabele niezarządzane mogą być preferowane przez użytkowników, którzy uzyskują bezpośredni dostęp do tabel z innych klientów czytnika delty. Aby zapoznać się z omówieniem różnic w semantyce tabel, zobacz Co to są tabele i widoki?.
Niektóre starsze obciążenia mogą korzystać wyłącznie z danych usługi Delta Lake za pośrednictwem ścieżek plików i w ogóle nie rejestrować tabel. Te dane są nadal danymi lakehouse, ale mogą być trudniejsze do odnalezienia, ponieważ nie są zarejestrowane w Unity Catalog.
Uwaga
Administrator obszaru roboczego mógł nie zaktualizować zarządzania danymi, aby korzystać z Unity Catalog. Nadal możesz uzyskać wiele korzyści z usługi Databricks Lakehouse bez Unity Catalog, ale nie wszystkie funkcje wymienione w tym artykule ani w całości dokumentacji usługi Azure Databricks są obsługiwane.
Jakie dane są uznawane za zewnętrzne?
Wszelkie dane, które nie są w usłudze Databricks Lakehouse, można traktować jako dane zewnętrzne. Oto kilka przykładów danych zewnętrznych:
- Tabele zewnętrzne zarejestrowane w federacji Lakehouse.
- Tabele w magazynie metadanych Hive wspierane przez Parquet.
- Tabele zewnętrzne w katalogu Unity oparte na JSON.
- Dane CSV przechowywane w magazynie obiektów w chmurze.
- Dane przesyłane strumieniowo z platformy Kafka.
Usługa Azure Databricks obsługuje konfigurowanie połączeń z wieloma źródłami danych. Zobacz Nawiązywanie połączenia ze źródłami danych.
Chociaż można używać Unity Catalog do zarządzania dostępem do tabel i ich definiowania w kontekście danych przechowywanych w wielu formatach i systemach zewnętrznych, konieczne jest użycie Delta Lake, aby dane mogły być brane pod uwagę w lakehouse.
Usługa Delta Lake zapewnia wszystkie gwarancje transakcyjne w usłudze Azure Databricks, które mają kluczowe znaczenie dla utrzymania integralności i spójności danych. Jeśli chcesz dowiedzieć się więcej na temat gwarancji transakcyjnych dotyczących danych usługi Azure Databricks i dlaczego są one ważne, zobacz Co to są gwarancje ACID w usłudze Azure Databricks?.
Większość użytkowników usługi Azure Databricks wykonuje zapytania dotyczące kombinacji danych typu lakehouse i danych zewnętrznych. Nawiązywanie połączenia z danymi zewnętrznymi jest zawsze pierwszym krokiem w przypadku pozyskiwania danych i potoków ETL, które wprowadzają dane do magazynu typu lakehouse. Aby uzyskać informacje na temat pozyskiwania danych, zobacz pozyskiwanie danych do usługi Azure Databricks lakehouse.
Tabele zapytań według nazwy
W przypadku wszystkich danych zarejestrowanych jako tabela usługa Databricks zaleca wykonywanie zapytań przy użyciu nazwy tabeli.
Jeśli używasz Unity Catalog, tabele korzystają z trójwarstwowej przestrzeni nazw w następującym formacie: <catalog-name>.<schema-name>.<table-name>.
Bez katalogu Unity identyfikatory tabel używają formatu <schema-name>.<table-name>.
Uwaga
Usługa Azure Databricks dziedziczy znaczną część składni SQL z platformy Apache Spark, która nie rozróżnia wartości SCHEMA i DATABASE.
Wykonywanie zapytań według nazwy tabeli jest obsługiwane we wszystkich kontekstach wykonywania usługi Azure Databricks i obsługiwanych językach.
SQL
SELECT * FROM catalog_name.schema_name.table_name
Python
spark.read.table("catalog_name.schema_name.table_name")
rozwiązywanie identyfikatora Katalogu Unity
Usługa Databricks zaleca używanie w pełni kwalifikowanych identyfikatorów w przypadku interakcji zapytań lub obciążeń z obiektami bazy danych przechowywanymi w wielu schematach lub katalogach.
W poniższej tabeli przedstawiono zachowania częściowo kwalifikowanych i niekwalifikowanych identyfikatorów:
| Wzorzec identyfikatora | Zachowanie |
|---|---|
catalog_name.schema_name.object_name |
Odwołuje się do obiektu bazy danych określonego przez identyfikator. |
schema_name.object_name |
Odwołuje się do obiektu bazy danych związanego z określonym schema_name i object_name w bieżącym katalogu. |
object_name |
Odwołuje się do obiektu bazy danych skojarzonego z określonym object_name w bieżącym katalogu i schemacie. |
Jaki jest bieżący wykaz i schemat?
W interaktywnych środowiskach obliczeniowych użyj current_catalog() i current_schema(), aby potwierdzić bieżący katalog i schemat.
Wszystkie obszary robocze skonfigurowane za pomocą Unity Catalog mają domyślny katalog ustawiony na poziomie obszaru roboczego. Zobacz Zarządzanie domyślnym katalogiem.
W poniższej tabeli opisano konfiguracje produktów usługi Databricks, które mogą zastąpić domyślny wykaz obszarów roboczych:
| Produkt | Konfiguracja |
|---|---|
| Obliczenia uniwersalne lub dla zadań | Ustaw konfigurację Spark spark.databricks.sql.initial.catalog.namespace podczas konfigurowania obliczeń. |
| Tabele na żywo delty | Wykaz i schemat określony podczas konfiguracji potoku zastępują wartości domyślne obszaru roboczego dla całej logiki potoku. |
Uwaga
Domyślny wykaz lub schemat mogą być również ustawiane przez konfiguracje JDBC podczas nawiązywania połączenia z systemami zewnętrznymi lub magazynami metadanych. Skontaktuj się z administratorem odpowiedzialnym za skonfigurowanie zasobów obliczeniowych i zintegrowanych systemów usługi Databricks, jeśli wystąpi nieoczekiwane zachowanie domyślne.
Użyj składni USE CATALOG lub USE SCHEMA, aby określić bieżący wykaz lub schemat dla bieżącej sesji. Bieżący katalog lub schemat jest używany, gdy zapytanie lub instrukcja używa częściowo kwalifikowanego lub niekwalifikowanego identyfikatora.
| Wypowiedź | Wynik |
|---|---|
USE CATALOG catalog_name |
Ustawia bieżący wykaz przy użyciu podanego catalog_name. Ustawia bieżący schemat na default. |
USE SCHEMA schema_name |
Ustawia bieżący schemat przy użyciu podanego schema_name w bieżącym katalogu. |
USE SCHEMA catalog_name.schema_name |
Ustaw bieżący katalog przy użyciu podanego catalog_name oraz bieżący schemat przy użyciu podanego schema_name. |
Uwaga
Zapytania i polecenia korzystające z w pełni kwalifikowanych identyfikatorów do interakcji z obiektami, takimi jak tabele, widoki, funkcje lub modele, nie zmieniają bieżącego wykazu lub schematu i zawsze odwołują się do określonego obiektu.
Wykonywanie zapytań o dane według ścieżki
Zapytania dotyczące danych ustrukturyzowanych, częściowo ustrukturyzowanych i nieustrukturyzowanych można wykonywać przy użyciu ścieżek plików. Większość plików w usłudze Azure Databricks jest wspierana przez magazyn obiektów w chmurze. Zobacz Praca z plikami w usłudze Azure Databricks.
Usługa Databricks zaleca skonfigurowanie całego dostępu do magazynu obiektów w chmurze przy użyciu katalogu aparatu Unity i zdefiniowanie woluminów dla lokalizacji magazynu obiektów, które są bezpośrednio odpytywane. Woluminy udostępniają aliasy czytelne dla człowieka do lokalizacji i plików w magazynie obiektów w chmurze przy użyciu nazw katalogów i schematów ścieżki plików. Zobacz Połącz się z chmurową pamięcią obiektową i usługami za pomocą Unity Catalog.
W poniższych przykładach pokazano, jak używać ścieżki woluminów katalogu Unity do odczytywania danych JSON.
SQL
SELECT * FROM json.`/Volumes/catalog_name/schema_name/volume_name/path/to/data`
Python
spark.read.format("json").load("/Volumes/catalog_name/schema_name/volume_name/path/to/data")
W przypadku lokalizacji w chmurze, które nie są skonfigurowane jako woluminy Unity Catalog, można wykonywać zapytania dotyczące danych bezpośrednio przy użyciu URI. Należy skonfigurować dostęp do magazynu obiektów w chmurze w celu wykonywania zapytań dotyczących danych przy użyciu identyfikatorów URI. Zobacz Konfigurowanie dostępu do magazynu obiektów w chmurze dla usługi Azure Databricks.
W poniższych przykładach pokazano, jak używać identyfikatorów URI do wykonywania zapytań dotyczących danych JSON w usłudze Azure Data Lake Storage Gen2, GCS i S3:
SQL
SELECT * FROM json.`abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data`;
SELECT * FROM json.`gs://bucket_name/path/to/data`;
SELECT * FROM json.`s3://bucket_name/path/to/data`;
Python
spark.read.format("json").load("abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data")
spark.read.format("json").load("gs://bucket_name/path/to/data")
spark.read.format("json").load("s3://bucket_name/path/to/data")
Wykonywanie zapytań dotyczących danych przy użyciu usługi SQL Warehouse
Usługa Azure Databricks używa magazynów SQL do obliczeń w następujących interfejsach:
- Edytor SQL
- Zapytania SQL usługi Databricks
- Pulpity nawigacyjne
- Starsze pulpity nawigacyjne
- Alerty SQL
Opcjonalnie można używać magazynów SQL z następującymi produktami:
- Notesy usługi Databricks
- Edytor plików usługi Databricks
- Zadania usługi Databricks
Podczas wykonywania zapytań dotyczących danych za pomocą usługi SQL Warehouse można używać tylko składni SQL. Inne języki programowania i interfejsy API nie są obsługiwane.
W przypadku obszarów roboczych, które mają włączony Unity Catalog, magazyny SQL zawsze używają Unity Catalog do zarządzania dostępem do źródeł danych.
Większość zapytań uruchamianych w magazynach SQL jest kierowana do tabel. Zapytania skierowane do plików danych powinny używać woluminów katalogu Unity do zarządzania dostępem do lokalizacji przechowywania.
Używanie identyfikatorów URI bezpośrednio w zapytaniach uruchamianych w usłudze SQL Warehouse może prowadzić do nieoczekiwanych błędów.
Wykonywanie zapytań dotyczących danych przy użyciu obliczeń obliczeniowych lub zadań ogólnego przeznaczenia
Większość zapytań uruchamianych z notesów, przepływów pracy usługi Databricks i edytora plików jest uruchamiana względem klastrów obliczeniowych skonfigurowanych za pomocą środowiska Databricks Runtime. Te klastry można skonfigurować tak, aby działały interaktywnie lub wdrażać je jako zadania obliczeniowe , które zasilają przepływy pracy. Usługa Databricks zaleca, aby zawsze używać zadań obliczeniowych dla obciążeń nieinterakcyjnych.
Obciążenia interakcyjne i nieinterakcyjne
Wielu użytkowników uważa, że pomocne jest wyświetlanie wyników zapytań podczas przetwarzania przekształceń podczas opracowywania. Przeniesienie interakcyjnego obciążenia z obliczeń typu all-purpose do zadań obliczeniowych pozwala zaoszczędzić czas i koszty przetwarzania, usuwając zapytania, które wyświetlają wyniki.
Platforma Apache Spark używa leniwego wykonywania kodu, co oznacza, że wyniki są obliczane tylko w razie potrzeby, a wiele przekształceń lub zapytań względem źródła danych można zoptymalizować jako pojedyncze zapytanie, jeśli nie wymusisz wyników. Jest to kontrast z trybem wykonywania chętnego używanego w bibliotece pandas, który wymaga przetworzenia obliczeń w kolejności przed przekazaniem wyników do następnej metody.
Jeśli twoim celem jest zapisanie oczyszczonych, przekształconych, zagregowanych danych jako nowego zestawu danych, należy usunąć zapytania, które wyświetlają wyniki z kodu przed zaplanowaniem jego uruchomienia.
W przypadku małych operacji i małych zestawów danych czas i oszczędności kosztów mogą być marginalne. Mimo to przy dużych operacjach można zmarnować znaczne ilości czasu na obliczanie i drukowanie wyników do notesu, który może nie być ręcznie sprawdzany. Te same wyniki mogą być prawdopodobnie odpytywane z zapisanych danych wyjściowych przy prawie żadnym koszcie po ich zapisaniu.