Что дальше?

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

Службы MCP от Azure Databricks в ближайшее время станут общедоступными

Azure Databricks-предоставляемые службы MCP для приложений SaaS, таких как Slack, GitHub, Atlassian и Google Drive, в ближайшее время будут общедоступными, причем операции чтения и записи включены по умолчанию. Администраторы и пользователи могут отключить службы MCP и отдельные средства в шлюзе ИИ Unity.

См. статью "Подключение агентов к сторонним средствам с помощью служб MCP".

соединитель SharePoint в Lakeflow Connect скоро станет общедоступным

Соединитель SharePoint в Lakeflow Connect скоро станет общедоступным. Вы можете загружать файлы и структурированные данные с сайтов SharePoint в Azure Databricks для преобразования, анализа и последующей обработки в конвейерах.

См. коннектор SharePoint.

Соединитель Google Drive в Lakeflow Connect скоро станет общедоступным

Соединитель Google Drive в Lakeflow Connect скоро станет общедоступным. Вы можете загружать файлы из Google Drive в Azure Databricks для преобразования, анализа и последующих конвейеров обработки.

См. соединитель Google Drive.

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

Lakeflow Pipelines Editor доступен для общего пользования с мая 2026 года. В августе он станет редактором по умолчанию для разработки и отладки конвейеров в рабочих областях с включенным профилем безопасности соответствия . В то время устаревший редактор будет удален.

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

Изменения поведения для непрерывных заданий и конвейеров

В начале августа 2026 года непрерывные конвейеры Lakeflow и задания получат обновления, призванные упростить настройку и управление состоянием.

Непрерывные конвейеры

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

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

Непрерывные задания

Управление состоянием для непрерывных заданий будет упрощено. Следующие критические изменения вступают в силу:

  • Добавление непрерывного расписания для задания отменит все активные запуски, независимо от того, приостановлено расписание или нет.
  • Удаление непрерывного расписания из задания приведет к отмене всех активных запусков.
  • Запуск приостановленного непрерывного задания возобновит его выполнение.
  • Приостановка непрерывного задания также отменяет активный запуск.
  • Остановка активного выполнения непрерывного задания также приостанавливает задание.

Новое поле API только для чтения отслеживает состояние непрерывного задания.

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

Задача оповещения SQL в заданиях Lakeflow будет доступна по умолчанию

Задача оповещения SQL в Заданиях Lakeflow общедоступна и будет доступна по умолчанию в рабочей области. Используйте задачу для оценки оповещения SQL Databricks в рамках задания Lakeflow. Задача возвращает состояние оценки в качестве выходного значения задачи, поэтому подчиненные задачи могут ветвить в результатах.

См. задачу оповещения SQL для заданий.

Создание классической рабочей области с помощью виртуальной сети, управляемой Azure Databricks, скоро будет устарело.

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

См. сведения о классической сети плоскости вычислений.

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

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

См. раздел "Включить безопасное подключение к кластеру".

Предстоящие изменения в выставлении счетов Azure для OpenSharing SecureConnect

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

Плата применяется при:

  • Получатель находится в другом регионе, отличном от хранилища поставщика.
  • Трафик выходит в общедоступный Интернет.

Плата не взимается за входящий трафик в SecureConnect или за исходящий трафик обратно получателям в том же регионе.

Цены и часто задаваемые вопросы см. в разделе о ценах на передачу данных и подключение.

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

Соединитель Ingest Zerobus в Lakeflow Connect будет включен по умолчанию для рабочих областей с профилем безопасности соответствия требованиям , включенным в середине июля 2026 года.

Zerobus Ingest — это API приема на основе push-уведомлений, который записывает данные непосредственно в таблицы Delta каталога Unity. Ознакомьтесь с обзором соединителя Ingest Zerobus.

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

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

Lakeflow Designer — это визуальная среда без программирования для подготовки и преобразования данных на холсте с функцией перетаскивания, где все рабочие процессы опираются на готовый к промышленной эксплуатации код под управлением Unity Catalog.

См. конструктор Lakeflow.

Декларативные пакеты автоматизации скоро по умолчанию будут использовать подсистему прямого развертывания

24 июля 2026 г. декларативные пакеты автоматизации начнут использовать подсистему прямого развертывания по умолчанию вместо подсистемы развертывания Terraform. Это приведет к активации миграции для всех пакетов, которые по-прежнему используют модуль развертывания Terraform.

Дополнительные сведения о подсистеме прямого развертывания и миграции из подсистемы развертывания Terraform см. в разделе "Миграция в подсистему прямого развертывания".

Модуль развертывания Terraform в конечном итоге будет удален и больше недоступен.

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

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

Используется ai_extract для извлечения структурированных полей из неструктурированного текста в определяемой пользователем схеме. Используйте ai_classify для классификации текста в определяемые пользователем метки для маршрутизации, тегов и рабочих процессов классификации документов. Вы также можете использовать Agent Bricks для создания агента извлечения информации и агента классификации.

Предстоящее изменение поведения: выбор прав при добавлении субъектов в рабочие области

Databricks меняет порядок предоставления субъектам безопасности прав доступа к рабочей области. После этого изменения вы явно предоставляете права при добавлении субъекта в рабочую область вместо того, чтобы полагаться на наследование из системной users группы. Администраторы рабочей области могут принять участие с 15 июня 2026 г., и новое поведение применяется для всех рабочих областей 14 сентября 2026 г.

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

Что меняется

Каждая рабочая область имеет две системные группы: usersкоторая включает всех субъектов, которым предоставлен доступ к рабочей области, и adminsкоторая включает администраторов рабочей области. Сегодня каждый субъект, добавленный в рабочую область, наследует предоставленные права users. По умолчанию это:

  • Доступ к рабочей области — создание и использование записных книжек, заданий, конвейеров, приложений и т. д.
  • Доступ к Databricks SQL — создание и использование панелей мониторинга, агентов Genie, оповещений и т. д.

После изменений:

  • Группа users не будет иметь прав. Группа admins будет иметь все права рабочей области. Права обеих групп заблокированы.
  • При добавлении новых субъектов в рабочую область им необходимо явно назначать права доступа.
  • users и admins не могут быть вложены в качестве членов других групп.

Существующие субъекты сохраняют текущий уровень доступа. Databricks автоматически переносит разрешения, ранее предоставленные users, в новую локальную для рабочей области группу-клон с именем users-clone-<TIMESTAMP> (где <TIMESTAMP> — время миграции). Вы управляете группой-клоном, как и любой другой локальной группой рабочей области, и можете изменить её название, если участвуете в программе раннего доступа. Для admins группы не требуется миграция.

Необходимые действия

  • Если вы управляете правами группы системы с помощью автоматизации (Terraform, API SCIM рабочей области или пользовательские скрипты), обновите рабочие процессы до целевых стандартных групп учетных записей, а не системных групп. После включения нового поведения попытка изменить права системной группы завершится ошибкой.
  • Если users или admins вложен(а) в другую группу, уберите вложенность. Вложение не допускается в соответствии с новым поведением.
  • Если синхронизация SCIM удаляет группы рабочего пространства, которые не распознаёт, обновите её конфигурацию, чтобы сохранить группу-клон для миграции (users-clone-<TIMESTAMP>). Если синхронизация удаляет группу клонирования, субъекты, перенесенные в нее, теряют свои права.

Timeline

  • 15 июня 2026 г. — включение в параметрах рабочей области в разделе "Расширенный > контроль доступа".
  • 27 июля 2026 г. — автоматически включается для рабочих областей, которые не выбрали ни включение, ни отказ. Возможность отказаться остается доступной.
  • 14 сентября 2026 г. — для всех рабочих пространств введено новое поведение. Отказ удален.

Вы управляете новым поведением в параметрах рабочей области в разделе "Расширенный > контроль доступа":

Параметр рабочей области управления доступом в устаревшем состоянии перед согласием или миграцией.

До подтверждения согласия действует прежнее поведение.

Параметр рабочей области управления доступом после включения нового поведения активен.

После явного включения пользователем или автоматической активации: начинает действовать новое поведение.

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

Профиль безопасности соответствия требованиям, необходимый для HIPAA, HITRUST и IRAP

Начиная с 1 сентября 2026 г. профиль безопасности соответствия будет необходим для обработки данных, защищенных под HIPAA, HITRUST и IRAP.

См. профиль безопасности соответствия требованиям .

Предстоящее изменение: переход на автомасштабирование Lakebase

Azure Databricks переводит все экземпляры Lakebase Provisioned на платформу Lakebase Autoscaling. Обновления для клиентов, которые подали соответствующий запрос, начнутся в июне 2026 г., а обновление остальных экземпляров продолжится в последующие недели. Администраторы рабочей области получат сообщение электронной почты с датами обновления до начала обновления.

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

После обновления применяются следующие изменения:

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

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

    • Существующие строки подключения: подготовленные строки подключения (без региона) продолжают работать через существующий входящий Приватный канал и не требуютService Direct Приватный канал.
    • Новая региональная строка подключения: если вы используете Приватный канал и подключаетесь к Lakebase из-за пределов рабочей области Azure Databricks, необходимо настроить входящий Приватный канал для ресурсоёмких служб, чтобы использовать новую региональную строку подключения.
  • Чтобы использовать новые функции автомасштабирования, такие как масштабирование до нуля в декларативных пакетах автоматизации и конфигурациях Terraform, обновите их, чтобы использовать семантику автомасштабирования.

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

  • После обновления функции Forward ETL и REST API Private Preview в Lakebase Provisioned отключаются. Им на смену пришли Lakebase Change Data Feed и Data API, доступные на платформе Autoscaling.

Lakebase Autoscaling добавляет автомасштабирование и масштабирование до нуля, восстановление к определенному моменту времени и моментальные снимки, планирование окна обслуживания, ветвление базы данных и другие улучшения. Дополнительные сведения о том, что ожидать, какие изменения и какие действия следует предпринять, см. в разделе "Обновление до автомасштабирования".

Чтобы запросить ускоренное обновление или если у вас возникли вопросы, обратитесь в свою группу учетных записей или Azure Databricks службу поддержки.

Databricks Runtime 19 будет использовать единую модель выпуска

Начиная с версии 19 среда выполнения Databricks будет использовать единую модель выпуска. Вместо нескольких версий компонентов (например, 19.0, 19.1, 19.2) каждая основная версия будет иметь одну страницу заметок о выпуске.

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

Databricks Runtime 18 — это переходный выпуск. Страницы версий 18.0, 18.1 и 18.2 остаются доступными для справки, а Databricks Runtime 18 LTS станет последней унифицированной версией в линейке 18.x.

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 рекомендует проводить проверку разрешений в вашей рабочей области. Используйте следующую записную книжку, чтобы определить неактивные разрешения в рабочих областях:

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

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

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

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

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

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

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

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

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

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

Изменения в токенах открытых получателей OpenSharing (прежнее название — Delta Sharing)

Замечание

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

OpenSharing для открытых получателей перейдет в новый формат URL-адреса для конкретного получателя. Новые маркеры, созданные после даты перехода, автоматически будут использовать новый формат URL-адреса. Это изменение повышает безопасность сети и позволяет получателям настраивать политики сети и правила брандмауэра для конкретных получателей.

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

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

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

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

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

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

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

Databricks рекомендует поставщикам данных начать перевод своих получателей данных на новый формат URL-адресов. Хотя дата перехода ещё не назначена, перейдите сейчас, чтобы осталось время на устранение неполадок. После перехода поставщики могут найти новый URL-адрес в пользовательском интерфейсе OpenSharing. После прекращения использования старого формата URL-адреса он больше недействителен.

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

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

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

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

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

См. сведения о хранилище по умолчанию в 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-адреса исходящего контрольного тракта продолжают поддерживаться.

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

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

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