Что дальше?

Узнайте о функциях и изменениях в поведении в предстоящих выпусках Azure Databricks.

Power BI подключения перейдут на ADBC

Power BI собирается перенести все подключения Power BI на Arrow Database Connectivity (ADBC) в июле 2026 года. Чтобы избежать сбоев, Databricks рекомендует переключить семантические модели разработки и промежуточные модели на ADBC сейчас и проверить рабочие нагрузки.

Драйвер ADBC для Power BI на Azure Databricks был в общедоступной предварительной версии с октября 2025 года. С февраля 2026 года все новые подключения в Power BI Desktop и служба Power BI по умолчанию используют ADBC. Существующие подключения продолжают использовать ODBC, если их не обновить вручную.

См. раздел Конфигурация драйвера ADBC или ODBC для Power BI.

Авторизация пользователей для приложений Databricks вскоре будет доступна для рабочих областей с включенным профилем безопасности соответствия требованиям

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

См. авторизацию пользователей.

Разрешения объекта рабочей области вскоре будут унаследованы от всех групп учетных записей

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

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

Диаграмма осиротевших разрешений.

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

Блокнот анализа осиротевших разрешений

Получите ноутбук

Маркеры личного доступа с ограниченным доступом вскоре будут автоматически доступны для рабочих областей с активированным профилем безопасности для соблюдения требований.

Личные токены доступа с заданной областью видимости будут доступны по умолчанию для рабочих областей с включенным профилем безопасности соответствия требованиям в конце мая 2026 года.

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

См. Аутентификация с использованием личных токенов доступа Azure Databricks (устаревшая версия).

Группы систем рабочей среды вскоре получат установленные права доступа.

В предстоящем выпуске группы систем рабочей области (users и admins) будут иметь фиксированные права доступа, которые нельзя изменить. Когда это изменение вступает в силу:

  • Группа users не будет иметь прав.
  • Группа admins будет иметь все права рабочей области.
  • Существующие права в users группе автоматически переносятся в клонированную группу, поэтому текущие пользователи сохраняют свой доступ.

Это критическое изменение для клиентов, использующих автоматизацию (Terraform, API SCIM рабочей области или скрипты) для управления правами в системных группах. Вместо этого эти рабочие процессы необходимо обновить, чтобы они были нацелены на обычные группы.

В ближайшее время появится параметр согласия. Дополнительные сведения см. в разделе "Изменение доступа к рабочей области по умолчанию на потребительский доступ".

ai_parse_document скоро будет доступен по умолчанию для рабочих областей с включенным профилем безопасности соответствия

"ai_parse_document будет по умолчанию доступен для рабочих областей с включенным профилем безопасности соответствия и элементами управления HIPAA, HITRUST, C5 и TISAX, выбранными в середине мая 2026 года."

Используйте ai_parse_document для анализа структурированного содержимого из неструктурированных документов, включая PDF-файлы, изображения, Word документы и файлы PowerPoint.

См. ai_parse_document функцию.

Предстоящее изменение поведения: VOID столбцы, включенные в таблицу Delta, считываются.

С середины июня 2026 года Delta Lake будет полностью поддерживать столбцы VOID. Ранее столбцы VOID незаметно пропускались при операциях чтения DataFrame на основе пути (например, spark.read.format("delta").load(path)) и запросах временного перехода. После этого изменения эти запросы включают VOID столбцы в выходные данные.

Запросы, зависящие от количества столбцов или позиций, например INSERT INTO ... SELECT *, могут завершиться ошибкой или создать неверные результаты после этого изменения. Просмотрите все запросы, которые считываются из таблиц Delta Lake с VOID столбцами, чтобы обеспечить правильную обработку дополнительных столбцов.

См. тип VOID.

Предстоящее важное изменение: дефолтное поведение при удалении потока каталога Unity

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

Поле cascade доступно сейчас. Чтобы сохранить текущее поведение удаления всех таблиц при удалении конвейера, обновите код, чтобы задать cascade=true.

См. "Удаление конвейера" и "Удаление конвейера".

Развертывание на основе Git для Приложений Databricks скоро будет доступно для рабочих областей с включенным профилем безопасности соответствия

В начале мая 2026 г. развертывание на основе Git для приложений Databricks будет автоматически включено для рабочих областей с включенным профилем безопасности соответствия . Разверните приложения непосредственно из репозитория Git, чтобы упростить рабочий процесс CI/CD.

См. раздел "Развертывание приложения Databricks".

Новая версия редактора SQL включается по умолчанию; ретирование устаревшего редактора SQL

Новый редактор SQL общедоступен с октября 2025 года. В рамках перехода к новому редактору планируется следующее изменение:

  • Начиная с конца мая 2026 г. новый редактор SQL будет включен по умолчанию для всех рабочих областей. Возможность отключения функции на уровне рабочей области больше не будет доступна. Отдельные пользователи по-прежнему смогут переключать свои запросы в устаревший редактор SQL после начала этого периода.
  • Начиная с конца июля 2026 г.: устаревший редактор SQL будет прекращен. Все пользователи будут использовать новый редактор SQL, и отдельный отказ больше не будет доступен.

Дополнительные сведения о новом редакторе SQL см. в статье "Написание запросов" и изучение данных в новом редакторе SQL. Если у вас есть вопросы об этом переходе, обратитесь к команде, которая занимается вашей учетной записью.

Изменение порядка сортировки списков в API панелей мониторинга

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

Это изменение, нарушающее совместимость, для пользователей, которые используют next_page_token для разбиения результатов на страницы. Маркеры, созданные предыдущей версией API, недействительны в новой версии. Если вы используете маркер из предыдущей версии, API возвращает ошибку:

Invalid page_token: this token was generated by a previous/different API version. Please retry without page_token.

Чтобы продолжить разбиение на страницы после этого изменения, запустите новый запрос без next_page_token.

Lakebase будет включен по умолчанию для рабочих областей с профилем безопасности соответствия требованиям

Начиная с 30 апреля 2026 г. Lakebase будет активирована по умолчанию для рабочих пространств с профилем безопасности соответствия, когда для стандарта соответствия установлен HIPAA, C5, TISAX или None.

См. соответствие Lakebase.

Изменения в токенах получателей Delta Sharing

Delta Sharing для открытых получателей перейдет к новому формату URL-адреса, специфичного для получателя. Дата перехода обновлена и теперь — 1 июля 2026 г. Новые токены, созданные 1 июля 2026 г. или позже, автоматически будут использовать новый формат URL-адреса. Это изменение повышает безопасность сети и позволяет получателям настраивать политики сети и правила брандмауэра для конкретных получателей.

Для Azure Китая переход будет объявлен позже.

Новые URL-адреса включают идентификатор получателя в домен:

https://<recipient-id>.delta-sharing.westus.azuredatabricks.net/api/2.0/delta-sharing/metastores/<metastore-id>

Для справки URL-адреса, созданные перед этим изменением, не содержат идентификатор получателя.

https://westus.azuredatabricks.net/api/2.0/delta-sharing/metastores/<metastore-id>

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

Общий доступ к федерации OIDC:

Поставщики данных должны убедиться, что их получатели используют новый формат URL-адреса до 1 июля 2027 года. Начиная с 1 июля 2026 года, поставщики смогут найти новый URL в интерфейсе Delta Sharing. После 1 июля 2027 г. старый формат URL-адреса не будет допустимым.

Общий доступ маркера носителя:

Дата создания токена Формат URL-адреса Дата окончания срока действия маркера Рекомендуемое действие
До 1 июля 2026 г. Старый формат Год от даты создания или 8 декабря 2026 г., в зависимости от того, какая из этих дат будет позже. Поставщики данных должны сменить маркеры до истечения срока действия, чтобы перейти в новый формат URL-адреса. Чтобы предоставить получателям время перейти, настройте окно простоя, назначив дату окончания срока действия текущего маркера во время ротации. В течение этого периода поддерживаются как старые, так и новые форматы URL-адресов.
После 1 июля 2026 г. Новый формат В соответствии с вашей конфигурацией, до одного года с даты создания. Нет

Классификация данных скоро будет доступна по умолчанию для некоторых рабочих областей с включенным профилем безопасности соответствия

В середине марта 2026 года классификация данных будет доступна по умолчанию для рабочих областей с включенным профилем безопасности соответствия и выбранными элементами управления HIPAA.

Поддержка EventBridge скоро будет доступна для событий файлов, предоставленных очередями

В конце февраля 2026 г. поддержка EventBridge будет доступна для событий файлов, связанных с очередями для расположений S3. В настоящее время события файлов можно настроить только с помощью SNS или путем маршрутизации событий хранения непосредственно в SQS.

См. Использование предоставленных очередей для S3.

Новая логика срезов для таблиц временной шкалы заданий

Начиная с 19 января 2026 г., таблицы временных шкал заданий используют новую логику нарезки, выровненную по часам. Срезы времени теперь соответствуют стандартным границам часов (17:00-18:00, 18:00-19:00 и так далее) вместо промежутков в один час на основе времени начала выполнения. Новые строки будут использовать новую логику срезов, а существующие строки остаются неизменными.

См. логику нарезки с выравниванием по часам.

Обновления навигации обозревателя каталогов

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

Упрощенная навигация:

Вкладка "Дублирующиеся каталоги" удаляется, чтобы уменьшить избыточность и сосредоточиться на единой системе навигации по каталогам. DBFS и Отправка отзыва перемещаются в значок меню «Кебаб». для более аккуратной компоновки.

Новый предлагаемый раздел:

Новая вкладка «Предлагаемое» на целевой странице обозревателя каталогов выделяет часто используемые объекты, примеры объектов для новых пользователей и избранные объекты пользователей. Это помогает быстро повторно взаимодействовать с важными ресурсами или обнаруживать полезные начальные точки.

Объединенные точки входа:

Связанные возможности группируются под более четкими категориями для снижения визуального шума и повышения удобства поиска:

  • Управление — точка входа для управляемых тегов, администрирования хранилища метаданных и классификации данных
  • Подключение — точки входа для внешних расположений, внешних данных, учетных данных и соединений
  • Общий доступ — точки входа для Delta Sharing и Clean Rooms

Эти группировки заменяют разбросанные вложенные вкладки и создают более интуитивно понятную масштабируемую архитектуру информационных систем.

Федеративный доступ в Lakehouse и хранилище по умолчанию

Delta Sharing на Lakehouse Federation в бета-версии, что позволяет поставщикам данных Delta Sharing делиться чужими каталогами и таблицами. По умолчанию данные должны быть временно материализованы и храниться в хранилище по умолчанию (частная предварительная версия). В настоящее время пользователи должны вручную включить функцию Delta Sharing для хранилища по умолчанию — расширенный доступ в консоли учетной записи, чтобы использовать Lakehouse Federation.

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

См. сведения о хранилище по умолчанию в Databricks и добавлении внешних схем или таблиц в общую папку.

Уведомление о перезагрузке в рабочих областях

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

Delta Sharing для таблиц в хранилище по умолчанию скоро будет включен по умолчанию (бета-версия)

Это обновление хранилища по умолчанию для Delta Sharing расширило возможности совместного доступа, что позволяет поставщикам предоставлять доступ к таблицам, поддерживаемым хранилищем по умолчанию, любому получателю Delta Sharing (открыто или Azure Databricks), включая получателей, использующих классические вычислительные мощности. Эта функция в настоящее время находится на этапе бета-тестирования и требует, чтобы поставщики вручную включили Delta Sharing для хранилища по умолчанию: расширенный доступ в консоли учетной записи. В ближайшее время это будет включено по умолчанию для всех пользователей.

Смотрите ограничения.

Обновления публичных IP-адресов контрольной плоскости исходящего трафика

Azure Databricks обновляет общедоступные IP-адреса уровня управления и теги службы Azure для повышения безопасности и доступности зон. Эти изменения являются частью обновления уровня управления, которое началось 20 мая 2025 года.

Если в организации используются брандмауэры ресурсов для управления входящим доступом:

  • Если правила брандмауэра ссылаются на тег службы Azure Databricks, никаких действий не требуется.
  • Если вы разрешаете общедоступные IP-адреса определенного уровня управления, необходимо добавить все IP-адреса плоскости исходящего трафикак 26 сентября 2025 года.

Предыдущие IP-адреса исходящего контрольного тракта продолжают поддерживаться.

Изменение поведения для параметра списка добавочных каталогов автозагрузчика

Замечание

Параметр автозагрузчика cloudFiles.useIncrementalListing устарел. Хотя в этой заметке рассматривается изменение значения по умолчанию параметров и как продолжить его использование после этого изменения, Databricks рекомендует не использовать этот параметр, предпочитая режим уведомлений файлов с событиями файлов.

В предстоящем выпуске Databricks Runtime значение нерекомендуемого параметра автозагрузчика cloudFiles.useIncrementalListing по умолчанию будет иметь значение false. Установка этого значения приводит к тому, что false Auto Loader выполняет полный список каталогов при каждом запуске. В настоящее время значение по умолчанию параметра cloudFiles.useIncrementalListing установлено в auto, что заставляет автозагрузчик попытаться наилучшим образом определить, можно ли использовать инкрементное перечисление с каталогом.

Чтобы продолжить использование функции добавочного перечисления, задайте для параметра cloudFiles.useIncrementalListing значение auto. Если для этого значения задано значение auto, автозагрузчик в меру возможностей пытается выполнить полный перечень каждые семь добавочных перечней, что соответствует поведению этого параметра перед этим изменением.

Дополнительные сведения о списке каталогов автозагрузчика см. в разделе "Настройка потоков автозагрузчика" в режиме перечисления каталогов.

Изменение поведения при удалении определений набора данных из декларативных конвейеров Spark Lakeflow

Предстоящий релиз Lakeflow Spark Declarative Pipelines изменит поведение при удалении материализованного представления или потоковой таблицы из потока. При этом изменении удаленное материализованное представление или потоковая таблица не будет автоматически удалена при выполнении следующего обновления конвейера. Вместо этого вы сможете использовать команду DROP MATERIALIZED VIEW для удаления материализованного представления или команды DROP TABLE для удаления таблицы потоковой передачи. После удаления объекта, запуск обновления конвейера не восстановит объект автоматически. Новый объект создается, если материализованное представление или потоковая таблица с тем же определением повторно добавляется в конвейер. Однако можно восстановить объект с помощью команды UNDROP.

Поле sourceIpAddress в журналах аудита больше не будет включать номер порта

Из-за ошибки некоторые журналы аудита авторизации и проверки подлинности включают номер порта в дополнение к IP-адресу в sourceIPAddress поле (например, "sourceIPAddress":"10.2.91.100:0"). Номер порта, который регистрируется как 0, не предоставляет никакого реального значения и не соответствует остальным журналам аудита Databricks. Чтобы повысить согласованность журналов аудита, Databricks планирует изменить формат IP-адреса для этих событий журнала аудита. Это изменение будет постепенно развернуто в начале августа 2024 года.

Если журнал аудита содержит объект sourceIpAddress0.0.0.0, Databricks может прекратить ведение журнала.