Запрос данных

Запрос данных — это базовый шаг для выполнения практически всех задач на основе данных в Azure Databricks. Независимо от используемого языка или инструмента рабочие нагрузки начинаются с определения запроса к таблице или другому источнику данных, а затем выполняют действия для получения аналитических сведений от данных. В этой статье описаны основные понятия и процедуры выполнения запросов в различных предложениях продуктов Azure Databricks, а также примеры кода, которые можно адаптировать для вашего варианта использования.

Данные можно запрашивать в интерактивном режиме с помощью:

• Записные книжки
• Редактор SQL
• Редактор файлов
• Панели мониторинга

Вы также можете выполнять запросы как часть конвейеров или рабочих процессов delta Live Tables.

Общие сведения о потоковых запросах в Azure Databricks см. в разделе "Запрос потоковой передачи данных".

Какие данные можно запрашивать с помощью Azure Databricks?

Azure Databricks поддерживает запросы данных в нескольких форматах и корпоративных системах. Данные, которые вы запрашиваете с помощью Azure Databricks, попадают в одну из двух общих категорий: данные в databricks lakehouse и внешних данных.

Какие данные есть в Databricks lakehouse?

Платформа аналитики данных Databricks хранит все данные в lakehouse Databricks по умолчанию.

Это означает, что при выполнении базового CREATE TABLE оператора для создания новой таблицы вы создали таблицу Lakehouse. Данные Lakehouse имеют следующие свойства:

• Хранится в формате Delta Lake.
• Хранится в облачном хранилище объектов.
• Управляется каталогом Unity.

Большинство данных Lakehouse в Azure Databricks зарегистрированы в каталоге Unity в качестве управляемых таблиц. Управляемые таблицы предоставляют самый простой синтаксис и ведут себя так же, как и другие таблицы в большинстве систем управления реляционными базами данных. Управляемые таблицы рекомендуется для большинства вариантов использования и подходят для всех пользователей, которые не хотят беспокоиться о реализации хранилища данных.

Неуправляемая таблица или внешняя таблица является таблицей, зарегистрированной LOCATION в указанном формате. Термин внешний может быть вводящим в заблуждение, так как внешние таблицы Delta по-прежнему являются данными lakehouse. Неуправляемые таблицы могут быть предпочтительнее пользователями, которые напрямую обращаются к таблицам из других клиентов чтения Delta. Общие сведения о различиях в семантике таблиц см. в разделе "Что такое таблица?".

Некоторые устаревшие рабочие нагрузки могут взаимодействовать исключительно с данными Delta Lake через пути к файлам и не регистрировать таблицы вообще. Эти данные по-прежнему являются lakehouse, но могут быть более сложными для обнаружения, так как они не зарегистрированы в каталоге Unity.

Примечание.

Возможно, администратор рабочей области не обновил управление данными, чтобы использовать каталог Unity. Вы по-прежнему можете получить множество преимуществ Озера Databricks без каталога Unity, но не все функции, перечисленные в этой статье или в документации по Azure Databricks.

Какие данные считаются внешними?

Любые данные, которые не относятся к Databricks lakehouse, можно считать внешними данными. Ниже приведены некоторые примеры внешних данных:

• Иностранные таблицы, зарегистрированные в Федерации Lakehouse.
• Таблицы в хранилище метаданных Hive, поддерживаемые Parquet.
• Внешние таблицы в каталоге Unity, поддерживаемые JSON.
• CSV-данные, хранящиеся в облачном хранилище объектов.
• Потоковая передача данных из Kafka.

Azure Databricks поддерживает настройку подключений ко многим источникам данных. Ознакомьтесь с Подключение источниками данных.

Хотя вы можете использовать каталог Unity для управления доступом к таблицам и определения таблиц для данных, хранящихся в нескольких форматах и внешних системах, Delta Lake является требованием для рассмотрения данных в lakehouse.

Delta Lake предоставляет все гарантии транзакций в Azure Databricks, которые являются важными для поддержания целостности и согласованности данных. Если вы хотите узнать больше о гарантиях транзакций в данных Azure Databricks и почему они важны, см. сведения о гарантиях ACID в Azure Databricks?.

Большинство пользователей Azure Databricks запрашивают сочетание данных Lakehouse и внешних данных. Подключение с внешними данными всегда является первым шагом для приема данных и конвейеров ETL, которые переносят данные в lakehouse. Сведения о приеме данных см . в разделе "Прием данных" в databricks lakehouse.

Запрос таблиц по имени

Для всех данных, зарегистрированных в качестве таблицы, Databricks рекомендует запрашивать с помощью имени таблицы.

Если вы используете каталог Unity, таблицы используют трехуровневое пространство имен со следующим форматом: <catalog-name>.<schema-name>.<table-name>

Без каталога Unity идентификаторы таблиц используют формат <schema-name>.<table-name>.

Примечание.

Azure Databricks наследует большую часть синтаксиса SQL от Apache Spark, который не отличается от SCHEMA и DATABASE.

Запрос по имени таблицы поддерживается во всех контекстах выполнения Azure Databricks и поддерживаемых языках.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

spark.read.table("catalog_name.schema_name.table_name")

Запрос данных по пути

Структурированные, полуструктурированные и неструктурированные данные можно запрашивать с помощью путей к файлам. Большинство файлов в Azure Databricks поддерживаются облачным хранилищем объектов. См. статью " Работа с файлами в Azure Databricks".

Databricks рекомендует настроить весь доступ к облачному хранилищу объектов с помощью каталога Unity и определить тома для расположений хранилища объектов, которые запрашиваются напрямую. Тома предоставляют доступные для чтения псевдонимы расположения и файлы в хранилище облачных объектов с помощью имен каталога и схем для файлового пути. См. Подключение в облачное хранилище объектов с помощью каталога Unity.

В следующих примерах показано, как использовать пути тома каталога Unity для чтения данных 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")

Для облачных расположений, которые не настроены в качестве томов каталога Unity, можно запрашивать данные непосредственно с помощью URI. Для запроса данных с помощью URI необходимо настроить доступ к облачному хранилищу объектов. Сведения о настройке доступа к облачному хранилищу объектов для Azure Databricks.

В следующих примерах показано, как использовать URI для запроса данных JSON в Azure Data Lake Storage 2-го поколения, GCS и 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")

Запрос данных с помощью хранилищ SQL

Azure Databricks использует хранилища SQL для вычислений в следующих интерфейсах:

• Редактор SQL
• Запросы SQL Databricks
• Панели мониторинга
• Устаревшие панели мониторинга
• Оповещения SQL

При необходимости можно использовать хранилища SQL со следующими продуктами:

• Записные книжки Databricks
• Редактор файлов Databricks
• Рабочие процессы Databricks

При запросе данных с помощью хранилищ SQL можно использовать только синтаксис SQL. Другие языки программирования и API не поддерживаются.

Для рабочих областей, которые включены для каталога Unity, хранилища SQL всегда используют каталог Unity для управления доступом к источникам данных.

Большинство запросов, выполняемых в хранилищах SQL, целевых таблиц. Запросы, предназначенные для файлов данных, должны использовать тома каталога Unity для управления доступом к расположениям хранилища.

Использование URI непосредственно в запросах, выполняемых в хранилищах SQL, может привести к непредвиденным ошибкам.

Запрос данных с помощью всех вычислений или заданий назначения

Большинство запросов, выполняемых из записных книжек Databricks, рабочих процессов и редактора файлов, выполняются в вычислительных кластерах, настроенных с помощью Databricks Runtime. Эти кластеры можно настроить для интерактивного запуска или развертывания в качестве заданий вычислений , которые работают в рабочих процессах. Databricks рекомендует всегда использовать вычисления заданий для неинтерактивных рабочих нагрузок.

Интерактивные и неинтерактивные рабочие нагрузки

Многие пользователи могут просматривать результаты запросов во время обработки преобразований во время разработки. Перемещение интерактивной рабочей нагрузки из вычислений всех целей в вычисления заданий можно сэкономить время и затраты на обработку, удалив запросы, отображающие результаты.

Apache Spark использует отложенное выполнение кода, что означает, что результаты вычисляются только по мере необходимости, а несколько преобразований или запросов к источнику данных можно оптимизировать как один запрос, если вы не принудительно получите результаты. Это отличается от активного режима выполнения, используемого в pandas, который требует обработки вычислений в порядке перед передачей результатов в следующий метод.

Если ваша цель состоит в сохранении чистых, преобразованных, агрегированных данных в виде нового набора данных, необходимо удалить запросы, отображающие результаты из кода, прежде чем планировать его выполнение.

Для небольших операций и небольших наборов данных время и экономия затрат могут быть незначительными. Тем не менее, при больших операциях существенное время может быть потрачено на вычисление и печать результатов в записную книжку, которая не может быть проверена вручную. Те же результаты, скорее всего, могут быть запрошены из сохраненных выходных данных практически без затрат после их хранения.