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

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

Внимание

Эта статья относится исключительно к таблицам, поддерживаемым 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 поддерживает работу с частично структурированными источниками данных, включая JSON, Avro и Protobuf, а также хранение сложных данных в виде структур, строк JSON и карт и массивов. См. Моделирование полуструктурированных данных.

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

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

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

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