Was kommt?

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

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

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 Benutzern mit ausschließlichem Consumer-Zugriff, ohne dass diesen automatisch Erstellungsberechtigungen 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 usersgewä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-Räumen, 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.
• Neue Prinzipale 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 Schachteln 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.

Embed Genie Space wird in Kürze standardmäßig für Arbeitsbereiche mit aktiviertem Compliance-Sicherheitsprofil verfügbar sein.

Das Einbetten eines Genie Space als IFrame wird ab Juni 2026 standardmäßig für Arbeitsbereiche verfügbar sein, für die das Compliance-Sicherheitsprofil aktiviert ist.

Durch ein Einbetten eines Genie Space können Geschäftsbenutzer direkt in Ihren internen Tools oder Portalen mit Genie interagieren, ohne zu Azure Databricks zu navigieren.

Siehe "Einbetten eines Genie Space" in einer externen App.

Databricks SQL-Warnungen werden bald standardmäßig in Arbeitsbereichen mit aktiviertem Compliance-Sicherheitsprofil verfügbar sein.

Databricks SQL-Warnungen werden ab Juni 2026 standardmäßig für Arbeitsbereiche verfügbar sein, in denen das Compliance-Sicherheitsprofil aktiviert ist.

Verwenden Sie Databricks SQL-Warnungen, um Daten und KPIs zu überwachen, indem Sie Abfragen nach einem Zeitplan ausführen, Bedingungen auswerten und Empfänger benachrichtigen, wenn Bedingungen erfüllt sind. Häufige Anwendungsfälle sind das Überwachen von KPI-Drifts, das Erkennen von Anomalien und das Erkennen von Problemen mit der Datenqualität.

Siehe Databricks SQL-Warnungen.

Genie Chat wird in Kürze standardmäßig für Arbeitsbereiche mit aktiviertem Compliance-Sicherheitsprofil verfügbar sein

Genie Chat wird im Juni 2026 standardmäßig für Arbeitsbereiche verfügbar sein, bei denen das Compliance-Sicherheitsprofil aktiviert ist.

Genie Chat bietet eine einheitliche Vollbild-Schnittstelle zum Stellen von Datenfragen in natürlicher Sprache. Es verwendet vorhandene Dashboards, Abfragen, Genie Spaces und Metrikansichten, um Ihre Fragen mit allen verfügbaren Daten zu beantworten.

Siehe Genie-Chat.

Einheitliches Berechtigungsmodell für Projekte, die mit der Datenbankinstanz-API erstellt wurden

Zwischen dem 11. und dem 21. Mai 2026 führt Lakebase Autoscaling ein einheitliches Berechtigungsmodell für neue Projekte aus, die mit der Datenbankinstanz-API oder verwandten Tools (CLI, SDKs, Terraform, DABs) erstellt wurden. Bestehende Projekte sind nicht betroffen.

Nach dem Rollout werden Instanz- und Projektberechtigungen von einer einheitlichen Berechtigungsschicht anstelle von zwei unabhängigen ACL-Sätzen verwaltet. Vorhandene Automatisierung, die die Datenbankinstanz-API verwendet, funktioniert weiterhin ohne Änderungen.

Siehe Berechtigungen (ACLs).

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.

Lakebase Autoscaling fügt automatische Skalierung und Skalierung bis Null, Punkt-in-Time-Wiederherstellung und Momentaufnahmen, Wartungsfensterplanung, Datenbankverzweigung und andere Verbesserungen 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.

Excel Unterstützung für Dateiformate wird in Kürze standardmäßig verfügbar sein

Excel Unterstützung für Dateiformate ist standardmäßig für alle Arbeitsbereiche Anfang Juni 2026 verfügbar. Sie können .xls, .xlsx und .xlsm-Dateien dank integrierter Unterstützung direkt importieren, analysieren und abfragen, ohne externe Bibliotheken oder manuelle Konvertierungen. Arbeitsbereichsadministratoren können sie jetzt unter Settings>Previews>Excel Dateiformatunterstützung aktivieren. Erfordert Databricks Runtime 17.1 oder höher.

Siehe Lesen von Excel-Dateien.

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.

Tabellarische Anhänge in E-Mail-Abonnements für Dashboards in Arbeitsbereichen mit aktiviertem Compliance-Sicherheitsprofil

Tabellarische Anhänge in E-Mail-Abonnements für Dashboards werden im Juni 2026 standardmäßig für Arbeitsbereiche verfügbar sein, in denen das Compliance-Sicherheitsprofil aktiviert ist.

E-Mail-Abonnenten erhalten einen PDF-Schnappschuss und optional tabellarische Daten aus ausgewählten Dashboard-Widgets als CSV-, TSV- oder Excel-Dateien im Anhang.

Power BI Verbindungen wechseln zu ADBC

Power BI plant, alle Power BI Verbindungen zu Arrow Database Connectivity (ADBC) im Juli 2026 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.

Die Benutzerautorisierung für Databricks-Apps wird in Kürze für Arbeitsbereiche mit aktivierten Compliancesicherheitsprofilen verfügbar sein.

Anfang Juni 2026 wird die Benutzerautorisierung für Databricks-Apps automatisch in Arbeitsbereichen aktiviert, die das Compliancesicherheitsprofil verwenden. Mit der Benutzerautorisierung können Apps mit der Identität des App-Benutzers handeln, sodass Apps im Namen des Benutzers auf Ressourcen zugreifen können, während die vorhandenen Berechtigungen des Benutzers erzwungen werden.

Siehe Benutzerautorisierung.

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 Zuschüsse 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

Bereichsbezogene persönliche Zugriffstoken sind in Kürze standardmäßig für Arbeitsbereiche verfügbar, für die das Compliancesicherheitsprofil aktiviert ist.

Bereichsbezogene persönliche Zugriffstoken sind standardmäßig für Arbeitsbereiche mit aktiviertem Compliancesicherheitsprofil ab Ende Mai 2026 verfügbar.

Bereichsbezogene persönliche Zugriffstoken beschränken die Berechtigungen eines PAT auf bestimmte API-Vorgänge, indem sie einen oder mehrere API-Bereiche zuweisen, anstatt den vollständigen Arbeitsbereichszugriff der Identität zu gewähren.

Siehe Authentifizieren mit persönlichen Zugriffstokens von Azure Databricks (Legacy).

Bevorstehende Verhaltensänderung: VOID Spalten, die in delta-Tabellenlesungen enthalten sind

Mitte Juni 2026 wird Delta Lake VOID Spalten vollständig unterstützen. Zuvor wurden VOID Spalten von pfadbasierten DataFrame-Lesevorgängen (z. B. spark.read.format("delta").load(path)) und Zeitreiseabfragen unbemerkt übersprungen. Nach dieser Änderung schließen diese Abfragen VOID Spalten in die Ausgabe ein.

Abfragen, die von der Spaltenanzahl oder -position abhängen, INSERT INTO ... SELECT *können nach dieser Änderung fehlschlagen oder falsche Ergebnisse erzeugen. Überprüfen Sie alle Abfragen, die aus Delta Lake-Tabellen mit VOID Spalten gelesen werden, um sicherzustellen, dass sie die zusätzlichen Spalten ordnungsgemäß verarbeiten.

Siehe VOID Typ.

Bevorstehende Unterbrechungsänderung: Standardverhalten beim Löschen einer Unity-Katalogpipeline

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 Feld auf cascadetrue 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 und Aktivierung des neuen SQL-Editors und Ausserbetriebnahme 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.

Änderung der Sortierreihenfolge der Listendashboard-API

Am 4. Mai 2026 ändert eine neue Version der Listendashboard-API die Sortierreihenfolge der Ergebnisse. Dashboards werden in umgekehrter chronologischer Reihenfolge nach dem Datum der letzten Änderung zurückgegeben, wobei das zuletzt geänderte Dashboard zuerst statt alphabetisch nach Titel erfolgt.

Dies ist eine einschneidende Änderung für Benutzer, die Ergebnisse mithilfe von next_page_token paginieren. Token, die von einer früheren Version der API generiert wurden, sind mit der neuen Version ungültig. Wenn Sie ein Token aus einer früheren Version verwenden, gibt die API einen Fehler zurück:

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

Um das Paginieren nach dieser Änderung fortzusetzen, starten Sie eine neue Anforderung ohne eine next_page_token.

Lakebase wird standardmäßig für Arbeitsbereiche mit dem Compliancesicherheitsprofil aktiviert.

Am oder nach dem 30. April 2026 wird Lakebase standardmäßig für Arbeitsbereiche mit dem Compliancesicherheitsprofil aktiviert, wenn der Compliancestandard auf HIPAA, C5, TISAX oder None festgelegt ist.

Siehe Lakebase Compliance.

Änderungen am Öffnen von Delta-Freigabeempfängertoken

Die Delta-Freigabe für offene Empfänger wechselt zu einem neuen empfängerspezifischen URL-Format. Das Übergangsdatum wurde aktualisiert und ist jetzt der 1. Juli 2026. Neue Token, die am oder nach dem 1. Juli 2026 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>.delta-sharing.westus.azuredatabricks.net/api/2.0/delta-sharing/metastores/<metastore-id>

URLs, die vor dieser Änderung erstellt wurden, enthalten nicht die Empfängerkennung.

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:

Datenanbieter müssen überprüfen, ob ihre Empfänger das neue URL-Format vor dem 1. Juli 2027 verwenden. Ab dem 1. Juli 2026 finden Anbieter die neue URL in der Delta-Freigabe-UI. Nach dem 1. Juli 2027 ist das alte URL-Format ungültig.

Bearer-Token-Freigabe:

Erstellungsdatum des Tokens	URL-Format	Ablaufdatum des Tokens	Empfohlene Maßnahme
Vor dem 1. Juli 2026	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.
Nach dem 1. Juli 2026	Neues Format	Pro Konfiguration bis zu einem Jahr ab Erstellungsdatum.	Nichts

Die Datenklassifizierung wird in Kürze standardmäßig für einige Arbeitsbereiche mit aktiviertem Compliance-Sicherheitsprofil verfügbar sein.

Mitte März 2026 wird die Datenklassifizierung standardmäßig für Arbeitsbereiche mit aktiviertem Compliancesicherheitsprofil und ausgewählten HIPAA-Steuerelementen verfügbar sein.

Die EventBridge-Unterstützung wird bald für Dateiereignisse verfügbar sein, die Warteschlangen bereitgestellt haben.

Ende Februar 2026 steht die EventBridge-Unterstützung für Dateiereignisse zur Verfügung, die Warteschlangen für S3-Standorte vorsehen. Derzeit können Dateiereignisse nur mithilfe von SNS oder durch direktes Routing von Speicherereignissen an SQS eingerichtet werden.

Siehe Verwenden einer bereitgestellten Warteschlange für S3.

Neue Slicing-Logik für Zeitplantabellen für Aufträge

Ab dem 19. Januar 2026 verwenden die Zeitplan-Tabellen für Aufträge eine neue stundenbasierte Schneidelogik. Zeitsegmente richten sich jetzt an Standard-Stundenränder (17:00-18:00 Uhr, 18:00-19:00 Uhr usw.) anstelle von einstündigen Intervallen, die auf der Startzeit eines Durchlaufs basieren. Neue Zeilen verwenden die neue Slicing-Logik, während vorhandene Zeilen unverändert bleiben.

Weitere Informationen finden Sie unter "Uhr-Stunden-ausgerichtete Slicing"-Logik.

Navigationsupdates für Katalog-Explorer

Der Katalog-Explorer erhält bald Navigationsverbesserungen zum Optimieren von Workflows und hilft Ihnen, Datenressourcen effizienter zu erkennen und zu verwalten.

Vereinfachte Navigation:

Die Registerkarte "duplizierte Kataloge" wird entfernt, um Redundanz zu reduzieren und sich auf eine einzelne Katalognavigationsoberfläche zu konzentrieren. DBFS - und Feedbackaktionen werden in das Für ein übersichtliches Layout.

Neuer Vorgeschlagener Abschnitt:

Eine neue Registerkarte " Vorgeschlagen" auf der Zielseite des Katalog-Explorers hebt häufig verwendete Objekte hervor, z. B. Objekte für erstmalige Benutzer und Benutzerfavoriten. Auf diese Weise können Sie schnell wieder mit wichtigen Ressourcen interagieren oder hilfreiche Ausgangspunkte entdecken.

Konsolidierte Einstiegspunkte:

Verwandte Funktionen werden nach klareren Kategorien gruppiert, um visuelle Rauschen zu reduzieren und die Auffindbarkeit zu verbessern:

• Verwalten – Einstiegspunkt für verwaltete Tags, Metastoreverwaltung und Datenklassifizierung
• Verbinden – Einstiegspunkte für externe Speicherorte, externe Daten, Anmeldeinformationen und Verbindungen
• Teilen – Einstiegspunkte für Delta Sharing und Saubere Räume

Diese Gruppierungen ersetzen verstreute Unterregisterkarten und erstellen eine intuitivere, skalierbare Informationsarchitektur.

Lakehouse-Föderationsfreigabe 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 Hinzufügen fremder Schemas oder Tabellen zu einer Freigabe.

Benachrichtigung zum Neuladen in Arbeitsbereichen

In einer bevorstehenden Version wird eine Meldung zum erneuten Laden der Arbeitsbereichregisterkarte angezeigt, wenn Ihre Arbeitsbereichsregisterkarte seit langem geöffnet ist, ohne zu aktualisieren. Dadurch wird sichergestellt, dass Sie immer die neueste Version von Databricks mit den neuesten Features und Fixes verwenden.

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.

Verhaltensänderung für die inkrementelle Verzeichnisauflistung der "Auto Loader"-Option

Hinweis

Die Option "Auto Loader cloudFiles.useIncrementalListing " ist veraltet. Obwohl in diesem Hinweis eine Änderung des Standardwerts der Optionen und deren Verwendung nach dieser Änderung erläutert wird, rät Databricks davon ab, diese Option zu verwenden, und empfiehlt stattdessen den Dateibenachrichtigungsmodus mit Dateiereignissen.

In einer bevorstehenden Databricks-Runtime-Version wird der Wert der veralteten Option Auto Loader cloudFiles.useIncrementalListing standardmäßig auf false gesetzt. Wenn Sie diesen Wert auf false festlegen, führt Auto Loader jedes Mal, wenn er ausgeführt wird, eine vollständige Verzeichnisauflistung durch. Derzeit ist der Standardwert der cloudFiles.useIncrementalListing-Option auto. Dadurch wird das automatische Ladeprogramm angewiesen, einen bestmöglichen Versuch zu unternehmen bei der Ermittlung, ob eine inkrementelle Auflistung mit einem Verzeichnis verwendet werden kann.

Wenn Sie die inkrementelle Eintragsfunktion weiterhin verwenden möchten, legen Sie die cloudFiles.useIncrementalListing Option auf auto. Wenn Sie diesen Wert auf auto festlegen, versucht der Autoloader bei jedem siebten inkrementellen Auflisten einmal, eine vollständige Auflistung durchzuführen, was dem Verhalten dieser Option vor dieser Änderung entspricht.

Weitere Informationen zur Verzeichnisauflistung "Auto Loader" finden Sie unter Konfigurieren von Datenströmen für das automatische Laden im Verzeichnisauflistungsmodus.

Verhaltensänderung beim Entfernen von Datasetdefinitionen aus Lakeflow Spark Declarative Pipelines

Eine bevorstehende Version von Lakeflow Spark Declarative Pipelines ändert das Verhalten, wenn eine materialisierte Ansicht oder Streamingtabelle aus einer Pipeline entfernt wird. Bei dieser Änderung wird die entfernte materialisierte Ansicht oder Streamingtabelle nicht automatisch gelöscht, wenn das nächste Pipelineupdate ausgeführt wird. Stattdessen können Sie den Befehl DROP MATERIALIZED VIEW verwenden, um eine materialisierte Ansicht oder den befehl DROP TABLE zum Löschen einer Streamingtabelle zu löschen. Nach dem Ablegen eines Objekts wird durch ausführen einer Pipelineaktualisierung das Objekt nicht automatisch wiederhergestellt. Ein neues Objekt wird erstellt, wenn eine materialisierte Ansicht oder Streamingtabelle mit derselben Definition der Pipeline neu hinzugefügt wird. Sie können jedoch ein Objekt mithilfe des Befehls UNDROP wiederherstellen.

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.