Udostępnij za pośrednictwem

Zapytania o dane

  • Artykuł

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

Zapytania można również uruchamiać w ramach potoków lub zadań delty tabel na żywo.

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 CREATE TABLE instrukcji 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 aparatu Unity.

Większość danych usługi Lakehouse w usłudze Azure Databricks jest rejestrowana w wykazie aparatu Unity 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 jest tabelą zarejestrowaną w określonej tabeliLOCATION. 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 wykazie aparatu Unity.

Uwaga

Administrator obszaru roboczego mógł nie uaktualnić ładu danych w celu korzystania z wykazu aparatu Unity. Nadal możesz uzyskać wiele korzyści z usługi Databricks Lakehouse bez wykazu aparatu Unity, ale nie wszystkie funkcje wymienione w tym artykule lub w całej 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 obce zarejestrowane w federacji Lakehouse.
  • Tabele w magazynie metadanych Hive wspierane przez Parquet.
  • Tabele zewnętrzne w wykazie aparatu Unity wspierane przez kod 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żyć wykazu aparatu Unity do zarządzania dostępem do tabel i definiowania ich względem danych przechowywanych w wielu formatach i systemach zewnętrznych, usługa Delta Lake jest wymaganiem, aby dane mogły być brane pod uwagę w usłudze 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 Databricks Lakehouse.

Wykonywanie zapytań względem tabel 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 wykazu aparatu Unity, tabele używają trójwarstwowej przestrzeni nazw o następującym formacie: <catalog-name>.<schema-name>.<table-name>.

Bez wykazu aparatu 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")

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 Łączenie z magazynem obiektów w chmurze i usługami przy użyciu wykazu aparatu Unity.

W poniższych przykładach pokazano, jak używać ścieżek woluminów wykazu aparatu 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 wykazu aparatu Unity, można wykonywać zapytania dotyczące danych bezpośrednio przy użyciu identyfikatorów 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 są włączone dla wykazu aparatu Unity, magazyny SQL zawsze używają wykazu aparatu Unity do zarządzania dostępem do źródeł danych.

Większość zapytań uruchamianych w tabelach docelowych usługi SQL Warehouse. Zapytania docelowe plików danych powinny używać woluminów wykazu aparatu Unity do zarządzania dostępem do lokalizacji magazynu.

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.