Запрос данных
Запрос данных — это базовый шаг для выполнения практически всех задач на основе данных в Azure Databricks. Независимо от используемого языка или инструмента рабочие нагрузки начинаются с определения запроса к таблице или другому источнику данных, а затем выполняют действия для получения аналитических сведений от данных. В этой статье описаны основные понятия и процедуры выполнения запросов в различных предложениях продуктов Azure Databricks, а также примеры кода, которые можно адаптировать для вашего варианта использования.
Данные можно запрашивать в интерактивном режиме с помощью:
- Записные книжки
- Редактор SQL
- Редактор файлов
- Панели управления
Вы также можете выполнять запросы в рамках конвейеров или заданий DLT.
Общие сведения о потоковых запросах в Azure Databricks см. в разделе "Запрос потоковой передачи данных".
Какие данные можно запрашивать с помощью Azure Databricks?
Azure Databricks поддерживает запросы данных в нескольких форматах и корпоративных системах. Данные, которые вы запрашиваете с помощью Azure Databricks, попадают в одну из двух общих категорий: данные в озере данных Databricks и внешние данные.
Какие данные есть в Databricks lakehouse?
Платформа аналитики данных Databricks хранит все ваши данные в озере данных Databricks по умолчанию.
Это означает, что при выполнении базового CREATE TABLE оператора для создания новой таблицы вы создали таблицу Lakehouse. Данные Lakehouse имеют следующие свойства:
- Хранится в формате Delta Lake.
- Хранится в облачном хранилище объектов.
- Под контролем Unity Catalog.
Большинство данных Lakehouse в Azure Databricks зарегистрированы в каталоге Unity в качестве управляемых таблиц. Управляемые таблицы предоставляют самый простой синтаксис и ведут себя так же, как и другие таблицы в большинстве систем управления реляционными базами данных. Управляемые таблицы рекомендуется для большинства вариантов использования и подходят для всех пользователей, которые не хотят беспокоиться о реализации хранилища данных.
Неуправляемая таблица или внешняя таблица является таблицей, зарегистрированной LOCATION в указанном формате.
Термин внешний может быть вводящим в заблуждение, так как внешние таблицы Delta по-прежнему являются данными lakehouse. Неуправляемые таблицы могут быть предпочтительным выбором для пользователей, которые напрямую обращаются к таблицам через других клиентов чтения данных Delta. Общие сведения о различиях в семантике таблиц см. в разделе Что такое таблица?.
Некоторые устаревшие рабочие нагрузки могут взаимодействовать исключительно с данными Delta Lake через пути к файлам и не регистрировать таблицы вообще. Эти данные по-прежнему являются данными lakehouse, но их может быть сложнее обнаружить, так как они не зарегистрированы в каталоге Unity.
Примечание.
Возможно, администратор рабочей области не обновил управление данными, чтобы использовать каталог Unity. Вы по-прежнему можете получить множество преимуществ от использования Озера Databricks без каталога Unity, но не все функции, указанные в этой статье или в документации по Azure Databricks, поддерживаются.
Какие данные считаются внешними?
Любые данные, которые не относятся к Databricks lakehouse, можно считать внешними данными. Ниже приведены некоторые примеры внешних данных:
- Иностранные таблицы, зарегистрированные в «Федерации Лейкхаус».
- Таблицы в хранилище метаданных Hive, поддерживаемые Parquet.
- Внешние таблицы в каталоге Unity, поддерживаемые JSON.
- CSV-данные, хранящиеся в облачном хранилище объектов.
- Чтение потоковых данных из Kafka.
Azure Databricks поддерживает настройку подключений ко многим источникам данных. См. статью "Подключение к источникам данных".
Хотя вы можете использовать каталог Unity для управления доступом и определения таблиц для данных, хранящихся в нескольких форматах и внешних системах, Delta Lake является обязательным требованием для рассмотрения данных в хранилище данных.
Delta Lake предоставляет все гарантии транзакций в Azure Databricks, которые являются важными для поддержания целостности и согласованности данных. Если вы хотите узнать больше о гарантиях транзакций в данных Azure Databricks и почему они важны, см. сведения о гарантиях ACID в Azure Databricks?.
Большинство пользователей Azure Databricks запрашивают сочетание данных Lakehouse и внешних данных. Подключение к внешним данным всегда является первым шагом для процессов приема данных и конвейеров ETL, которые переносят данные в хранилище данных. Сведения о загрузке данных см. в загрузка данных в 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 при настройке вычислений. |
| Технология распределенного реестра (DLT) | Каталог и схема, указанные во время настройки конвейера, переопределяют значения рабочей области по умолчанию для всей логики конвейера. |
Примечание.
Каталог или схема по умолчанию также могут быть заданы конфигурациями 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, который требует, чтобы вычисления обрабатывались по порядку перед передачей результатов в следующий метод.
Если ваша цель состоит в сохранении чистых, преобразованных, агрегированных данных в виде нового набора данных, необходимо удалить запросы, отображающие результаты из кода, прежде чем планировать его выполнение.
Для небольших операций и небольших наборов данных время и экономия затрат могут быть незначительными. Тем не менее, при больших операциях существенное время может быть потрачено на вычисление и печать результатов в записную книжку, которая не может быть проверена вручную. Те же результаты, скорее всего, могут быть запрошены из сохраненных выходных данных практически без затрат после их хранения.