Поделиться через

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

  • Статья

Запрос данных — это базовый шаг для выполнения практически всех задач на основе данных в 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. Сведения о приеме данных см. в прием данных вAzure 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")

Разрешение идентификатора в каталоге Unity

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

В следующей таблице описано поведение частично квалифицированных и неквалифицированных идентификаторов:

Шаблон идентификатора Поведение
catalog_name.schema_name.object_name Ссылается на объект базы данных, указанный идентификатором.
schema_name.object_name Ссылается на объект базы данных, связанный с указанными schema_name и object_name в текущем каталоге.
object_name Ссылается на объект базы данных, связанный с указанным object_name в текущем каталоге и схеме.

Что такое текущий каталог и схема?

В интерактивных вычислительных средах используйте current_catalog() и current_schema() для подтверждения текущего каталога и схемы.

Все рабочие области, настроенные с помощью каталога Unity, имеют каталог по умолчанию на уровне рабочей области. См. Управление каталогом по умолчанию.

В следующей таблице описаны конфигурации для продуктов Databricks, которые могут переопределить каталог рабочей области по умолчанию:

Продукт Конфигурация
Вычисления всех целей или заданий Задайте конфигурацию Spark spark.databricks.sql.initial.catalog.namespace при настройке вычислений.
Таблицы Delta Live Каталог и схема, указанные во время настройки конвейера, переопределяют значения рабочей области по умолчанию для всей логики конвейера.

Примечание.

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

Используйте синтаксис USE CATALOG или USE SCHEMA, чтобы указать текущий каталог или схему для текущего сеанса. Текущий каталог или схема используются, когда запрос или оператор использует частично квалифицированный или неквалифицированный идентификатор.

Заявление Результат
USE CATALOG catalog_name Задает текущий каталог с помощью предоставленного catalog_name. Задает текущую схему для default.
USE SCHEMA schema_name Задает текущую схему с помощью предоставленного schema_name в текущем каталоге.
USE SCHEMA catalog_name.schema_name Установите текущий каталог с помощью предоставленного catalog_name и текущую схему с помощью предоставленного schema_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, который требует обработки вычислений в порядке перед передачей результатов в следующий метод.

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

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