Моделирование данных

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

Внимание

Эта статья относится исключительно к таблицам, поддерживаемым Delta Lake, которые включают все управляемые таблицы каталога Unity.

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

Основные понятия управления базами данных

Lakehouse, построенный с помощью Azure Databricks, использует множество компонентов и концепций с другими корпоративными системами хранения данных. При проектировании модели данных рассмотрите следующие понятия и функции.

Транзакции в Azure Databricks

Azure Databricks ограничивает транзакции отдельными таблицами. Это означает, что Azure Databricks не поддерживает операции с несколькими таблицами (также называемые многооператорными транзакциями).

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

Первичные и внешние ключи в Azure Databricks

Первичные и внешние ключи являются информационными и не применяются. Эта модель распространена во многих корпоративных облачных системах баз данных, но отличается от многих традиционных реляционных систем баз данных. См. Ограничения в Azure Databricks.

Присоединение к Azure Databricks

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

См. статью "Работа с соединениями в Azure Databricks".

Примечание.

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

Работа с вложенными и сложными типами данных

Azure Databricks поддерживает работу с полуструктурированных источников данных, включая JSON, Avro и ProtoBuff, а также хранение сложных данных в виде структур, строк JSON и карт и массивов. См. Моделирование полуструктурированных данных.

Нормализованные модели данных

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

Если вы создаёте архитектуру нового «lakehouse» или добавляете наборы данных в существующую среду, Azure Databricks рекомендует не использовать сильно нормализованную модель, такую как третья нормальная форма (3NF).

Модели, такие как схема звездочки или схема «снежинки», хорошо работают в Azure Databricks, так как в стандартных запросах присутствует меньше соединений и меньше ключей для синхронизации. Кроме того, наличие большего числа полей данных в одной таблице позволяет оптимизатору запросов пропускать значительные объемы данных с помощью статистики на уровне файла. Дополнительные сведения о пропусках данных см. в разделе " Пропуск данных".