Was kommt?

Erfahren Sie mehr über Features und Verhaltensänderungen in bevorstehenden Azure Databricks-Versionen.

Die von Azure Databricks bereitgestellten MCP-Dienste werden bald allgemein verfügbar sein

Azure Databricks bereitgestellten MCP-Dienste für SaaS-Anwendungen wie Slack, GitHub, Atlassian und Google Drive werden bald allgemein verfügbar sein, wobei sowohl Lese- als auch Schreibvorgänge standardmäßig aktiviert sind. Administratoren und Benutzer können MCP-Dienste und einzelne Tools im Unity AI-Gateway deaktivieren.

Weitere Informationen finden Sie unter Verbinden von Agents mit Tools von Drittanbietern mit MCP-Diensten.

SharePoint Connector in Lakeflow Connect wird bald allgemein verfügbar sein

Der SharePoint Connector in Lakeflow Connect wird bald allgemein verfügbar sein. Sie können Dateien und strukturierte Daten von SharePoint-Websites in Azure Databricks importieren, um sie für Transformation, Analyse und nachgelagerte Pipelines zu nutzen.

Siehe SharePoint Connector.

Google Drive Connector in Lakeflow Connect wird bald allgemein verfügbar sein

Der Google Drive-Connector in Lakeflow Connect wird bald allgemein verfügbar sein. Sie können Dateien von Google Drive in Azure Databricks für Transformation, Analyse und downstream Pipelines aufnehmen.

Siehe Google Drive-Connector.

Änderung des Standard-Pipeline-Editors für Arbeitsbereiche, bei denen das Compliance-Sicherheitsprofil aktiviert ist

Der Lakeflow Pipelines Editor ist seit Mai 2026 allgemein verfügbar. Im August wird es zum Standardeditor für die Entwicklung und das Debuggen von Pipelines in Arbeitsbereichen mit aktiviertem Compliance-Sicherheitsprofil. Zu diesem Zeitpunkt wird der Legacy-Editor entfernt.

Weitere Informationen zum Lakeflow Pipelines Editor finden Sie unter Entwickeln und Debuggen von ETL-Pipelines mit dem Lakeflow Pipelines Editor. Wenn Sie Fragen zu diesem Übergang haben, wenden Sie sich an Ihr Kontoteam.

Verhaltensänderungen für fortlaufende Aufträge und Pipelines

Anfang August 2026 werden kontinuierliche Lakeflow-Pipelines und Jobs aktualisiert, um die Konfiguration und Zustandsverwaltung zu vereinfachen.

Kontinuierliche Pipelines

Sie können einen fortlaufenden Zeitplan direkt über die Pipelineseite konfigurieren, einschließlich Einstellungen auf Auftragsebene wie z. B. dem Leistungsmodus. Auf diese Weise wird die Pipeline durch das Konfigurieren eines kontinuierlichen Zeitplans in einen kontinuierlichen Job eingebettet.

Databricks empfiehlt, kontinuierliche Pipelines mit einem kontinuierlichen Job statt mit der integrierten Einstellung der Pipeline für den kontinuierlichen Betrieb auszuführen. Wenn ein fortlaufender Auftrag eine Pipeline umschließt, verwaltet der Auftrag den Ausführungslebenszyklus der Pipeline. Die integrierte fortlaufende Einstellung wird nicht entfernt, aber neue fortlaufende Pipelines sollten das fortlaufende Auftragsmuster verwenden.

Fortlaufende Aufträge

Die Statusverwaltung für kontinuierliche Jobs wird vereinfacht. Die folgenden Änderungen werden wirksam:

• Durch das Hinzufügen eines fortlaufenden Zeitplans zu einem Auftrag werden alle aktiven Vorgänge abgebrochen, unabhängig davon, ob der Zeitplan angehalten oder unterbrochen wird.
• Durch das Entfernen eines fortlaufenden Zeitplans aus einem Auftrag werden alle aktiven Ausführungsläufe abgebrochen.
• Wenn Sie einen pausierten kontinuierlichen Auftrag ausführen, wird er fortgesetzt.
• Wenn Sie einen fortlaufenden Auftrag anhalten, wird auch die aktive Ausführung abgebrochen.
• Wenn Sie die aktive Ausführung eines kontinuierlichen Auftrags beenden, wird der Auftrag ebenfalls pausiert.

Ein neues schreibgeschütztes API-Feld wird den Status eines kontinuierlichen Auftrags nachverfolgen.

Überprüfen Sie alle Automatisierungen oder Workflows, die auf den aktuellen Verhaltensweisen kontinuierlicher Jobs basieren, und aktualisieren Sie sie vor diesem Release.

SQL-Warnungsaufgabe in Lakeflow-Aufträgen ist standardmäßig verfügbar

Die SQL-Warnungsaufgabe in Lakeflow-Aufträgen ist allgemein verfügbar und ist standardmäßig in Ihrem Arbeitsbereich verfügbar. Verwenden Sie die Aufgabe, um eine DATAbricks SQL-Warnung als Teil eines Lakeflow-Auftrags auszuwerten. Der Vorgang gibt den Auswertungsstatus als Ausgabewert eines Vorgangs zurück, sodass nachgeschaltete Vorgänge auf das Ergebnis verzweigen können.

Siehe SQL-Warnungsaufgabe für Aufträge.

Klassische Arbeitsbereichserstellung mit einem Azure Databricks verwalteten VNet wird bald veraltet sein

In einer zukünftigen Version plant Azure Databricks, die klassische Erstellung von Arbeitsbereichen mit einem von Azure Databricks verwalteten VNet einzustellen. Für neue Arbeitsbereiche empfiehlt Azure Databricks einen serverlosen Arbeitsbereich für den einfachsten Schnellstart oder die VNet-Einfügung, wenn Sie einen klassischen Arbeitsbereich benötigen. Ein detaillierter Migrationszeitplan wird separat mitgeteilt.

Weitere Informationen finden Sie unter Netzwerke auf der klassischen Computeebene.

Sichere Clusterkonnektivität wird bald obligatorisch für klassische Arbeitsbereiche

In einer zukünftigen Version plant Azure Databricks, sichere Clusterkonnektivität für alle klassischen Arbeitsbereiche vorzuschreiben. Arbeitsbereiche, die mit enableNoPublicIp auf false festgelegt erstellt wurden, werden künftig nicht mehr unterstützt, und der Parameter wird verbindlich. Ein detaillierter Migrationszeitplan wird separat mitgeteilt.

Siehe Aktivieren der sicheren Clusterkonnektivität.

Bevorstehende Azure Abrechnungsänderungen für OpenSharing SecureConnect

Azure Databricks wird Anbietern, die OpenSharing SecureConnect verwenden, bald Gebühren für regionenübergreifenden und über das öffentliche Internet erfolgenden Datenausgang berechnen.

Gebühren gelten, wenn:

• Der Empfänger befindet sich in einer anderen Region als der Anbieterspeicher.
• Der Datenverkehr geht ins öffentliche Internet.

Für den eingehenden Datenverkehr zu SecureConnect sowie für den ausgehenden Datenverkehr zurück an Empfänger in derselben Region fallen keine Gebühren an.

Informationen zu Preisen und häufig gestellten Fragen finden Sie unter Datenübertragung und Konnektivitätspreise.

Zerobus Ingest wird in Kürze standardmäßig für Arbeitsbereiche mit aktivierten Compliancesicherheitsprofilen verfügbar sein.

Der Zerobus Ingest-Connector in Lakeflow Connect wird Mitte Juli 2026 standardmäßig für Arbeitsbereiche aktiviert, in denen das Sicherheitsprofil für Compliance aktiviert ist.

Zerobus Ingest ist eine push-basierte Erfassungs-API, die Daten direkt in Unity Catalog Delta-Tabellen einfügt. Siehe Überblick über Zerobus Ingest-Connector.

Lakeflow Designer wird in Kürze standardmäßig für Arbeitsbereiche verfügbar sein, für die das Compliancesicherheitsprofil aktiviert ist

Lakeflow Designer wird Ende Juli 2026 standardmäßig für Arbeitsbereiche mit aktiviertem Compliance-Sicherheitsprofil verfügbar sein.

Lakeflow Designer ist eine visuelle, codefreie Oberfläche zum Vorbereiten und Transformieren von Daten auf einem Drag-and-Drop-Canvas mit allen Workflows, die von produktionsbereitem Code unterstützt werden, der vom Unity-Katalog gesteuert wird.

Siehe Lakeflow Designer.

Deklarative Automatisierungspakete verwenden in Kürze standardmäßig das direkte Bereitstellungsmodul.

Ab dem 24. Juli 2026 verwenden deklarative Automatisierungspakete standardmäßig das direkte Bereitstellungsmodul anstelle des Terraform-Bereitstellungsmoduls. Dadurch wird eine Migration für alle Pakete ausgelöst, die noch das Terraform-Bereitstellungsmodul verwenden.

Weitere Informationen zum direkten Bereitstellungsmodul und zur Migration vom Terraform-Bereitstellungsmodul finden Sie unter Migrieren zum direkten Bereitstellungsmodul.

Die Terraform-Bereitstellungsmaschine wird schließlich entfernt und ist nicht mehr verfügbar.

ai_extract und ai_classify wird bald standardmäßig für Arbeitsbereiche mit aktivierten Compliancesicherheitsprofilen verfügbar sein

Die SQL AI-Funktionen ai_extract und ai_classify werden standardmäßig Mitte Juli 2026 für Arbeitsbereiche verfügbar sein, in denen das Compliance-Sicherheitsprofil aktiviert ist und die Kontrollen HIPAA, HITRUST, C5 und TISAX ausgewählt sind.

Verwenden Sie ai_extract, um strukturierte Felder aus unstrukturiertem Text anhand eines benutzerdefinierten Schemas zu extrahieren. Verwenden Sie ai_classify, um Text in benutzerdefinierte Labels für Routing-, Tagging- und Dokumentkategorisierungs-Workflows zu klassifizieren. Sie können Agent Bricks auch verwenden, um einen Informationsextraktions-Agent und einen Klassifizierungs-Agent zu erstellen.

Bevorstehende Verhaltensänderung: Berechtigungen beim Hinzufügen von Prinzipalen zu Arbeitsbereichen auswählen

Databricks ändert, wie Prinzipale Arbeitsbereichsberechtigungen erhalten. Nach dieser Änderung gewähren Sie Berechtigungen explizit, wenn Sie einen Prinzipal zu einem Arbeitsbereich hinzufügen, anstatt sich auf die Vererbung aus der users-Systemgruppe zu verlassen. Arbeitsbereichsadministratoren können sich ab dem 15. Juni 2026 anmelden, und das neue Verhalten wird für alle Arbeitsbereiche am 14. September 2026 erzwungen.

Mit dieser Änderung können Sie Sicherheitsprinzipale auf jeder Zugriffsebene hinzufügen, einschließlich bei Benutzern, die ausschließlich Consumer-Zugriff haben, ohne dass diesen automatisch Erstellungsrechte zugewiesen werden.

Was ändert sich?

Jeder Arbeitsbereich verfügt über zwei Systemgruppen: users, die alle Prinzipale umfasst, denen Zugriff auf den Arbeitsbereich gewährt wurde, und admins, die die Arbeitsbereichsadministratoren umfasst. Heute erbt jeder Prinzipal, der einem Arbeitsbereich hinzugefügt wurde, die Berechtigungen, die users gewährt werden. Standardmäßig sind dies:

• Arbeitsbereichszugriff – Erstellen und Verwenden von Notizbüchern, Aufträgen, Pipelines, Apps und mehr.
• Databricks SQL-Zugriff – Erstellen und Verwenden von Dashboards, Genie Agents, Warnungen und mehr.

Nach der Änderung:

• Die users Gruppe wird keine Ansprüche haben. Die admins Gruppe verfügt über alle Arbeitsbereichsberechtigungen. Die Berechtigungen beider Gruppen sind gesperrt.
• Neuen Prinzipalen müssen Berechtigungen explizit erteilt werden, wenn sie einem Arbeitsbereich hinzugefügt werden.
• users und admins können nicht als Mitglieder in andere Gruppen verschachtelt werden.

Vorhandene Prinzipale behalten ihre aktuelle Zugriffsebene bei. Databricks migriert automatisch die Berechtigungen, die zuvor users gewährt wurden, zu einer neuen, arbeitsbereichslokalen Klongruppe mit dem Namen users-clone-<TIMESTAMP> (wobei <TIMESTAMP> der Zeitpunkt der Migration ist). Sie verwalten die Klongruppe wie jede andere arbeitsbereichslokale Gruppe, und Sie können den Namen anpassen, wenn Sie sich frühzeitig anmelden. Die admins Gruppe erfordert keine Migration.

Aktion erforderlich

• Wenn Sie Systemgruppenberechtigungen über Automatisierung (Terraform, Workspace SCIM-APIs oder benutzerdefinierte Skripts) verwalten, aktualisieren Sie Ihre Workflows auf Standardkontogruppen, nicht auf Systemgruppen. Nachdem das neue Verhalten aktiviert wurde, schlagen Versuche zum Ändern von Systemgruppenberechtigungen fehl.
• Wenn users oder admins in eine andere Gruppe verschachtelt ist, heben Sie die Verschachtelung auf. Das Verschachteln ist unter dem neuen Verhalten nicht zulässig.
• Wenn Ihre SCIM-Synchronisierung Workspace-Gruppen löscht, die sie nicht erkennt, aktualisieren Sie ihre Konfiguration, um die Migrationsklongruppe (users-clone-<TIMESTAMP>) beizubehalten. Wenn die Synchronisierung die Klongruppe entfernt, verlieren Prinzipale, die zu ihr migriert wurden, ihre Berechtigungen.

Zeitachse

• 15. Juni 2026 – Die Aktivierung ist in den Arbeitsbereichseinstellungen unter Erweitert > Zugriffssteuerung möglich.
• 27. Juli 2026 – Wird automatisch für Arbeitsbereiche aktiviert, die sich weder dafür noch dagegen entschieden haben. Eine Deaktivierung bleibt weiterhin möglich.
• 14. September 2026 – Neues Verhalten, das für alle Arbeitsbereiche erzwungen wird. Opt-out entfernt.

Sie verwalten das neue Verhalten über Ihre Arbeitsbereichseinstellungen unter "Erweiterte > Zugriffssteuerung":

Vor der Zustimmung: Das bisherige Verhalten ist aktiv.

Nach dem Opt-in oder der automatischen Aktivierung: das neue Verhalten ist aktiv.

Weitere Informationen finden Sie unter Migrieren der Berechtigungssteuerung für Arbeitsbereiche.

Compliance-Sicherheitsprofil erforderlich für HIPAA, HITRUST und IRAP

Ab dem 1. September 2026 muss das Compliance-Sicherheitsprofil Daten verarbeiten, die unter HIPAA, HITRUST und IRAP geschützt sind.

Weitere Informationen finden Sie unter Compliancesicherheitsprofil.

Bevorstehende Änderung: Upgrade auf Lakebase Autoscaling

Azure Databricks stellt alle bereitgestellten Lakebase-Instanzen auf die Lakebase-Autoscaling-Plattform um. Upgrades beginnen im Juni 2026 für Kunden, die sie angefordert haben, wobei die verbleibenden Instanzupgrades in den folgenden Wochen fortgesetzt werden. Arbeitsbereichsadministratoren erhalten eine E-Mail mit Upgradeterminen, bevor das Upgrade beginnt.

Das Upgrade erfolgt automatisch. Verbindungen werden während des Übergangs kurz neu gestartet, und vorhandene Verbindungszeichenfolgen, API-Aufrufe, deklarative Automatisierungsbündel und Terraform-Konfigurationen funktionieren ohne Änderung weiterhin.

Nach dem Upgrade gelten die folgenden Änderungen:

• Ihre Instanzen werden Funktionen für die automatische Skalierung unterstützen und können sowohl über die neue UI für automatische Skalierung als auch über die vertraute Provisioned UI verwaltet werden, die bis zum 1. September 2026 verfügbar bleibt.

• Jede Instanz erhält eine neue regionale Verbindungszeichenfolge, die einen optimierten eingehenden Datenverkehr bereitstellt:

  • Vorhandene Verbindungszeichenfolgen: Bereitgestellte Verbindungszeichenfolgen (ohne Region) funktionieren weiterhin über den vorhandenen eingehenden Private Link und erfordern keinenService Direct Private Link.
  • Neue regionale Verbindungszeichenfolge: Wenn Sie Private Link verwenden und von außerhalb des Azure Databricks-Arbeitsbereichs eine Verbindung mit Lakebase herstellen, müssen Sie den eingehenden Private Link für leistungsintensive Dienste konfigurieren, um die neue regionale Verbindungszeichenfolge zu verwenden.

• Um neue Autoscaling-Funktionen wie Scale-to-Zero in Ihren Declarative Automation Bundles und Terraform-Konfigurationen zu verwenden, aktualisieren Sie diese, sodass sie die Autoscaling-Semantik verwenden.

• Die Preise für Lakebase GA gelten. Bei der flexiblen Berechnung, die Instanzen mit fester Größe ersetzt, sehen die meisten Kunden eine Reduzierung der Berechnungskosten.

• Die Features "Forward ETL" und "REST API Private Preview" auf Lakebase Provisioned werden nach dem Upgrade deaktiviert. Ihre Ersetzungen, Lakebase Change Data Feed und die Daten-API, sind auf der Automatischen Skalierungsplattform verfügbar.

Die automatische Lakebase-Skalierung fügt automatische Skalierung und Skalierung auf Null, Zeitpunktwiederherstellung und Momentaufnahmen, Wartungsfensterplanung, Datenbankverzweigung und andere Erweiterungen hinzu. Ausführliche Informationen zu den Erwartungen, zu den Änderungen und zu den zu ergreifenden Aktionen finden Sie unter Upgrade auf automatische Skalierung.

Wenn Sie ein beschleunigtes Upgrade anfordern oder Fragen haben, wenden Sie sich an Ihr Kontoteam oder Azure Databricks Support.

Databricks Runtime 19 verwendet ein einheitliches Releasemodell

Ab Version 19 verwendet Databricks Runtime ein einheitliches Releasemodell. Anstelle mehrerer Featureversionen (z. B. 19.0, 19.1, 19.2) verfügt jede Hauptversion über eine einzelne Versionshinweiseseite.

Nach einer ersten Betaversion wird jede Databricks-Runtime-Version als allgemein verfügbar (GA) gestartet und erhalten ungefähr wöchentlich neue Features und Fixes, wobei Updates nach Datum auf einer einzelnen Seite unterschieden werden. Cluster erhalten Updates, wenn sie neu gestartet werden. Nach ungefähr sechs Monaten geht die Version in den Long-Term Support (LTS) mit drei Jahren Support über.

Databricks Runtime 18 ist die Übergangsversion. Die Seiten zu den Feature-Versionen 18.0, 18.1 und 18.2 bleiben zu Referenzzwecken verfügbar, und Databricks Runtime 18 LTS wird die endgültige einheitliche Version in der 18.x-Reihe sein.

Power BI Verbindungen wechseln zu ADBC

Power BI plant, im August 2026 alle Power BI Verbindungen zu Arrow Database Connectivity (ADBC) zu übertragen. Um Unterbrechungen zu vermeiden, empfiehlt Databricks, Ihre Entwicklungs- und Stagingsemantikmodelle jetzt auf ADBC zu wechseln und Ihre Workloads zu validieren.

Der ADBC-Treiber für Power BI auf Azure Databricks befindet sich seit Oktober 2025 in der öffentlichen Vorschau. Seit Februar 2026 verwenden alle neuen Verbindungen in Power BI Desktop und die Power BI-Dienst ADBC standardmäßig. Vorhandene Verbindungen verwenden weiterhin ODBC, es sei denn, Sie aktualisieren sie manuell.

Siehe Konfigurieren von ADBC- oder ODBC-Treibern für Power BI.

Arbeitsbereichsobjektberechtigungen werden bald von allen Kontogruppen geerbt

In einer bevorstehenden Version werden die Berechtigungen für Arbeitsbereichsobjekte von allen Kontogruppen geerbt, nicht nur von den Gruppen, die dem Arbeitsbereich direkt zugewiesen sind. Prinzipale erben Berechtigungen für Arbeitsbereichsobjekte, z. B. Aufträge, Notizbücher, Ordner, Abfragen und Dashboards, von allen Kontogruppen, deren Mitglied sie sind, unabhängig davon, ob diese Gruppen dem Arbeitsbereich zugewiesen sind. Benutzer müssen dem Arbeitsbereich weiterhin zugewiesen werden, um diese Berechtigungen zu verwenden.

Diese Änderung aktiviert auch inaktive ("verwaiste") Berechtigungserteilungen. Dies sind Berechtigungserteilungen, die in einer Gruppe verbleiben, nachdem diese aus einem Arbeitsbereich entfernt wurde. Es werden keine neuen Berechtigungen hinzugefügt, aber vorhandene verwaiste Zuweisungen werden aktiv, wodurch Arbeitsbereichsmitglieder möglicherweise unerwarteten Zugriff erhalten. Wenn z. B. eine Gruppe "Auftragnehmer" aus einem Arbeitsbereich entfernt wurde, aber dennoch Bearbeitungszugriff auf einen Ordner hat, erhält jedes Arbeitsbereichsmitglied in "Auftragnehmer" Zugriff auf diesen Ordner.

Databricks empfiehlt, Ihre Arbeitsbereichsberechtigungen zu überprüfen. Verwenden Sie das folgende Notizbuch, um inaktive Berechtigungserteilungen in Ihren Arbeitsbereichen zu identifizieren:

Notizbuch für verwaiste Berechtigungen

Notebook abrufen

Bevorstehender Breaking Change: Standardverhalten beim Löschen einer Unity Catalog-Pipeline

In einer bevorstehenden Version ändert sich das Standardverhalten beim Löschen einer Unity-Katalogpipeline. Derzeit entfernt das Löschen einer Pipeline auch alle zugeordneten materialisierten Ansichten, Streamingtabellen und Ansichten. Nach dieser Änderung werden verknüpfte Tabellen beibehalten, aber nach dem Entfernen der Pipeline deaktiviert. Die API wird ebenfalls so geändert, dass Tabellen standardmäßig beibehalten werden, jedoch wird dieses Verhalten außer Kraft gesetzt und das aktuelle Verhalten beibehalten, wenn das cascade-Feld auf true gesetzt wird.

Das cascade Feld ist jetzt verfügbar. Um das aktuelle Verhalten des Entfernens aller Tabellen beim Löschen einer Pipeline beizubehalten, aktualisieren Sie Ihren Code, sodass cascade=true eingestellt wird.

Siehe Löschen einer Pipeline und Löschen einer Pipeline.

Standardaktivierung des neuen SQL-Editors und Außerbetriebnahme des veralteten SQL-Editors

Der neue SQL-Editor ist seit Oktober 2025 allgemein verfügbar. Im Rahmen des Übergangs zum neuen Editor sind die folgenden Änderungen geplant:

• Ab Ende Mai 2026: Der neue SQL-Editor wird standardmäßig für alle Arbeitsbereiche aktiviert. Die Möglichkeit, das Feature auf Arbeitsbereichsebene zu deaktivieren, ist nicht mehr verfügbar. Einzelne Benutzer können ihre Abfragen nach diesem Zeitraum weiterhin in den älteren SQL-Editor wechseln.
• Ab Ende Juli 2026: Der ältere SQL-Editor wird eingestellt. Alle Benutzer verwenden den neuen SQL-Editor, und die individuelle Abmeldung ist nicht mehr verfügbar.

Weitere Informationen zum neuen SQL-Editor finden Sie unter Schreiben von Abfragen und Untersuchen von Daten im neuen SQL-Editor. Wenn Sie Fragen zu diesem Übergang haben, wenden Sie sich an Ihr Kontoteam.

Änderungen an OpenSharing (früher Delta Sharing) öffnen Empfängertoken

Hinweis

Basierend auf Kundenfeedback und der Einführung von OpenSharing wurde diese Änderung vom 1. Juli 2026 verschoben. Das neue Übergangsdatum wird aktualisiert, wenn verfügbar. Es ist kein Eingreifen des Benutzers erforderlich. Vorhandene Empfänger-URLs und Token funktionieren weiterhin wie heute.

OpenSharing für offene Empfänger wechselt zu einem neuen empfängerspezifischen URL-Format. Neue Token, die nach dem Übergangsdatum erstellt wurden, verwenden automatisch das neue URL-Format. Diese Änderung verbessert die Netzwerksicherheit und ermöglicht es den Empfängern, empfängerspezifische Netzwerkrichtlinien und Firewallregeln zu konfigurieren.

Für Azure China wird der Übergang später angekündigt.

Die neuen URLs enthalten die Empfänger-ID in der Domäne:

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

Zur Information: URLs, die vor dieser Änderung erstellt wurden, enthalten keine Empfänger-ID und verwenden den Delta-Sharing-Endpunkt.

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

Die alten URLs funktionieren weiterhin für einen bestimmten Zeitraum. Die spezifische Dauer hängt vom Empfängertyp und dem Erstellungsdatum des Tokens ab. Datenanbieter sollten zum neuen URL-Format wechseln, bevor das alte URL-Format ungültig wird.

Freigabe im OIDC-Verbund:

Databricks empfiehlt, dass Datenanbieter mit dem Übergang ihrer Empfänger in das neue URL-Format beginnen. Obwohl noch kein Übergangsdatum festgelegt wurde, sollten Sie jetzt umstellen, damit genügend Zeit für die Fehlerbehebung bleibt. Nach dem Übergang finden Anbieter die neue URL in der OpenSharing-Benutzeroberfläche. Nachdem das alte URL-Format eingestellt wurde, ist es nicht mehr gültig.

Bearer-Token-Freigabe:

Erstellungsdatum des Tokens	URL-Format	Ablaufdatum des Tokens	Empfohlene Maßnahme
Vor dem Übergangsdatum	Altes Format	Ein Jahr ab Erstellungsdatum oder 8. Dezember 2026, je nachdem, welches Datum in Zukunft weiter ist	Datenanbieter müssen Token ersetzen, bevor sie ablaufen, um zum neuen URL-Format zu migrieren. Um Empfängern Zeit für die Migration bereitzustellen, konfigurieren Sie ein Ausfallzeitfenster, indem Sie während der Drehung ein Ablaufdatum für das aktuelle Token festlegen. Sowohl alte als auch neue URL-Formate werden in diesem Zeitraum unterstützt.
Am oder nach dem Übergangsdatum	Neues Format	Pro Konfiguration bis zu einem Jahr ab Erstellungsdatum.	Nichts

Lakehouse-Verbundfreigabe und Standardspeicher

Delta Sharing in der Lakehouse Federation befindet sich in der Betaversion, sodass Delta Sharing-Datenanbieter externe Kataloge und Tabellen freigeben können. Standardmäßig müssen Daten vorübergehend materialisiert und im Standardspeicher (private Vorschau) gespeichert werden. Derzeit müssen Benutzer die Delta-Freigabe für Standardspeicher manuell aktivieren – Erweitertes Zugriffsfeature in der Kontokonsole, um die Lakehouse Federation-Freigabe zu verwenden.

Nachdem Delta-Freigabe für Standardspeicher – Erweiterter Zugriff für alle Azure Databricks Benutzer aktiviert ist, ist die Delta-Freigabe im Lakehouse-Verbund automatisch in Regionen verfügbar, in denen standardspeicher unterstützt wird.

Siehe Standardspeicher in Databricks und Fremde Schemata oder Tabellen zu einer Freigabe hinzufügen.

Delta-Freigabe für Tabellen im Standardspeicher wird standardmäßig in Kürze aktiviert (Beta)

Dieses Standardspeicher-Update für die Delta-Freigabe hat die Freigabefunktionen erweitert und ermöglicht es Anbietern, Tabellen, die durch Standardspeicher unterstützt werden, an jeden Delta-Freigabeempfänger (offen oder Azure Databricks), einschließlich Empfängern, die klassische Rechnerumgebungen verwenden, zu teilen. Dieses Feature befindet sich derzeit in Der Betaversion und erfordert, dass Anbieter die Delta-Freigabe für Den Standardspeicher manuell aktivieren – erweiterter Zugriff in der Kontokonsole. In Kürze wird dies standardmäßig für alle Benutzer aktiviert.

Informationen finden Sie unter Einschränkungen.

Aktualisierung der öffentlichen IPs der ausgehenden Steuerungsebene

Azure Databricks aktualisiert die outbound control plane public IPs und Azure Servicetags für verbesserte Sicherheits- und Zonenverfügbarkeit. Diese Änderungen sind Teil eines Steuerungsebenenupdates, das am 20. Mai 2025 begonnen hat.

Wenn Ihre Organisation Ressourcenfirewalls verwendet, um den eingehenden Zugriff zu steuern:

• Wenn Ihre Firewallregeln auf das tag Azure Databricks service verweisen, ist keine Aktion erforderlich.
• Wenn Sie bestimmte öffentliche Steuerebenen-IPs zulassen, müssen Sie alle Ausgehenden Steuerebenen-IPs bis zum 26. September 2025 hinzufügen.

Die vorherigen IPs der ausgehenden Steuerebene werden weiterhin unterstützt.

Das Feld für die Quell-IP-Adresse (sourceIpAddress) in Überwachungsprotokollen enthält keine Portnummer mehr.

Aufgrund eines Fehlers enthalten bestimmte Überwachungsprotokolle für Autorisierung und Authentifizierung zusätzlich zur IP-Adresse im Feld sourceIPAddress eine Portnummer (z. B. "sourceIPAddress":"10.2.91.100:0"). Die Portnummer, die als 0 protokolliert wird, stellt keinen echten Wert bereit und ist mit den restlichen Databricks-Überwachungsprotokollen inkonsistent. Um die Konsistenz von Überwachungsprotokollen zu verbessern, plant Databricks, das Format der IP-Adresse für diese Überwachungsprotokollereignisse zu ändern. Diese Änderung wird ab Anfang August 2024 schrittweise eingeführt.

Wenn das Überwachungsprotokoll eine sourceIpAddress mit dem Wert 0.0.0.0 enthält, beendet Databricks die Protokollierung möglicherweise.