Запрос данных
Запрос данных — это базовый шаг для выполнения практически всех задач на основе данных в 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, который требует, чтобы вычисления обрабатывались по порядку перед передачей результатов в следующий метод.
Если ваша цель состоит в сохранении чистых, преобразованных, агрегированных данных в виде нового набора данных, необходимо удалить запросы, отображающие результаты из кода, прежде чем планировать его выполнение.
Для небольших операций и небольших наборов данных время и экономия затрат могут быть незначительными. Тем не менее, при больших операциях существенное время может быть потрачено на вычисление и печать результатов в записную книжку, которая не может быть проверена вручную. Те же результаты, скорее всего, могут быть запрошены из сохраненных выходных данных практически без затрат после их хранения.