Geplante Neuerungen

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

Veröffentlichen in mehreren Katalogen und Schemas im Unity-Katalog aus Ihren Delta Live Tables-Pipelines

Eine bevorstehende Version von Delta Live Tables umfasst erweiterte Funktionen zum Veröffentlichen und Lesen von Datasets aus Ihren Pipelines:

• Wenn Sie Tabellen aus einer einzigen Pipeline in Unity-Katalog veröffentlichen, sind Sie nicht mehr auf die Angabe eines einzelnen Katalogs und Schemas beschränkt. Stattdessen können Sie in mehreren Katalogen und Schemas aus einer einzigen Pipeline veröffentlichen, indem Sie vollqualifizierte Tabellennamen (catalog.schema.table) angeben.
• Die Syntax USE CATALOG und USE SCHEMA wird ebenfalls unterstützt.
• Die Verwendung des Schlüsselworts LIVE zum Verweisen auf interne Datasets ist nicht mehr erforderlich.

Dies ist ein Nonbreaking Change. Diese neue Funktionalität wird angewendet, wenn Sie eine neue Delta Live Tables-Pipeline erstellen, ihre vorhandenen Pipelines werden jedoch weiterhin mit ihrer aktuellen Konfiguration ausgeführt.

Die Statistikverwaltung ist standardmäßig mit prädiktiven Optimierungen aktiviert

Ab dem 21. Januar wird Databricks mit der Aktivierung der Statistikverwaltung für alle Konten beginnen, wobei die Vorhersageoptimierung aktiviert ist. Die Statistikverwaltung erweitert die vorhandene prädiktive Optimierungsfunktionalität, indem eine Sammlung von Statistiken beim Schreiben hinzugefügt und automatisch ANALYZE-Befehle für verwaltete Tabellen im Unity-Katalog ausgeführt werden. Weitere Informationen zur prädiktiven Optimierung finden Sie unter Predictive Optimization für verwaltete Tabellen im Unity-Katalog.

Verhaltensänderung, wenn Datasetdefinitionen aus einer Delta Live Tables-Pipeline entfernt werden

Eine bevorstehende Version von Delta Live Tables ä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.

IPYNB-Notizbücher werden zum Standardnotizbuchformat für Azure Databricks

Derzeit erstellt Databricks standardmäßig alle neuen Notizbücher im "Databricks-Quellformat", die nur Code erfasst. Im Januar 2025 wird das neue Standardnotizbuchformat IPYNB (.ipynb) sein, das auch die Notizbuchumgebung, Visualisierungsdefinitionen und Notizbuch-Widgets erfasst. Diese neue Standardeinstellung kann im Bereich "Einstellungen" des Benutzer-Arbeitsbereichs geändert werden. Weitere Informationen zu Notizbuchformaten finden Sie unter Notizbuchformate.

Arbeitsbereichsdateien werden für alle Azure Databricks-Arbeitsbereiche am 1. Februar 2025 aktiviert

Databricks aktiviert Arbeitsbereichsdateien für alle Azure Databricks-Arbeitsbereiche am 1. Februar 2025. Diese Änderung hebt die Blockierung der Benutzer im Arbeitsbereich auf und ermöglicht ihnen die Nutzung neuer Funktionen für Arbeitsbereichsdateien. Nach dem 1. Februar 2025 können Sie Arbeitsbereichsdateien nicht mithilfe der enableWorkspaceFilesystem-Eigenschaft mit der Azure Databricks-REST-API zum Aktivieren und Deaktivieren von Arbeitsbereichsfeatures deaktivieren. Weitere Informationen zu Arbeitsbereichsdateien finden Sie unter Was sind Arbeitsbereichsdateien?.

Tabellen werden standardmäßig mit der Verlaufshistorie in Delta Sharing geteilt.

Databricks plant, die Standardeinstellung für Tabellen zu ändern, die mithilfe von Delta Sharing geteilt werden, um den Verlauf standardmäßig einzubeziehen. Zuvor war die Verlaufsfreigabe standardmäßig deaktiviert. Das Teilen der Tabellenhistorie verbessert die Leseleistung und bietet automatische Unterstützung für erweiterte Delta-Optimierungen.

Reduzierte Kosten und mehr Kontrolle über die Leistung im Vergleich zu Kosten für die serverlose Berechnung für Workflows-Workloads

Zusätzlich zu den derzeit unterstützten automatischen Leistungsoptimierungen erhalten Sie durch Verbesserungen der serverlosen Berechnung für Workflows Optimierungsfeatures mehr Kontrolle darüber, ob Workloads für Leistung oder Kosten optimiert sind. Weitere Informationen finden Sie unter Kosteneinsparungen beim serverlosen Berechnen von Notizbüchern, Aufträgen und Pipelines.

Änderungen an der Legacy-Dashboardversionsunterstützung

Databricks empfiehlt die Verwendung von KI/BI-Dashboards (ehemals Lakeview-Dashboards). Frühere Versionen von Dashboards, die zuvor als Databricks-SQL-Dashboards bezeichnet werden, werden jetzt als Legacy-Dashboards bezeichnet. Databricks rät davon ab, neue Legacy-Dashboards zu erstellen. AI/BI-Dashboards bieten verbesserte Funktionen im Vergleich zur Legacyversion, einschließlich KI-unterstützter Erstellung, Entwurfs- und veröffentlichter Modi und Kreuzfilterung.

Ende des Unterstützungszeitrahmens für ältere Dashboards

• 7. April 2025: Der offizielle Support für die Legacyversion von Dashboards wird beendet. Es werden nur kritische Sicherheitsprobleme und Dienstausfälle behoben.
• 3. November 2025: Databricks beginnt mit der Archivierung von Legacydashboards, auf die in den letzten sechs Monaten nicht zugegriffen wurde. Auf archivierte Dashboards kann nicht mehr zugegriffen werden, und der Archivierungsprozess findet fortlaufend statt. Der Zugriff auf aktiv verwendete Dashboards bleibt unverändert.

Databricks arbeitet mit Kunden zusammen, um Migrationspläne für aktive Legacydashboards nach dem 3. November 2025 zu entwickeln.

Um den Übergang zu AI/BI-Dashboards zu erleichtern, stehen Upgradetools sowohl auf der Benutzeroberfläche als auch in der API zur Verfügung. Anweisungen zur Verwendung des integrierten Migrationstools auf der Benutzeroberfläche finden Sie unter Klonen eines Legacy-Dashboards mit einem AI/BI-Dashboard. Lernprogramme zum Erstellen und Verwalten von Dashboards mithilfe der REST-API bei Verwendung von Azure Databricks-APIs zum Verwalten von Dashboards.

Änderungen an der Zuordnung einer serverlosen Computeworkload

Derzeit enthält Ihre Systemtabelle für die abrechnungsfähige Nutzung möglicherweise serverlose SKU-Abrechnungsdatensätze mit Nullwerten für run_as, job_id, job_run_id und notebook_id. Diese Datensätze stellen Kosten im Zusammenhang mit gemeinsam genutzten Ressourcen dar, die nicht direkt auf eine bestimmte Workload zurückzuführen sind.

Um die Kostenberichterstattung zu vereinfachen, werden diese gemeinsamen Kosten in Databricks bald den spezifischen Workloads zugeordnet, die sie verursacht haben. Abrechnungsdatensätze mit NULL-Werten werden in Feldern mit Workloadbezeichnern nicht mehr angezeigt. Wenn Sie die Nutzung der serverlosen Berechnung erhöhen und mehr Workloads hinzufügen, verringert sich der Anteil dieser gemeinsam genutzten Kosten auf Ihrer Rechnung, da sie zwischen mehr Workloads verteilt werden.

Weitere Informationen zur Überwachung der Kosten für das serverlose Compute finden Sie unter Überwachen der Kosten für serverlose Berechnung.

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, kann Databricks die Protokollierung möglicherweise beenden.

EOL für Legacy Git-Integration ist der 31. Januar

Nach dem 31. Januar 2024 entfernt Databricks Legacy-Notebook-Git-Integrationen. Dieses Feature hat seit mehr als zwei Jahren den Legacystatus, und seit November 2023 wird in der Produktbenutzeroberfläche ein Hinweis auf seine Veraltung angezeigt.

Ausführliche Informationen zum Migrieren zu Databricks Git-Ordnern (vormals Repos) aus der Legacy-Git-Integration finden Sie unter Wechseln zu Databricks-Repos von der Legacy-Git-Integration. Wenn Sie von dieser Entfernung betroffen sind und eine Verlängerung benötigen, wenden Sie sich an Ihr Databricks Account-Team.

JDK8 und JDK11 werden nicht unterstützt.

Azure Databricks plant, die JDK 8-Unterstützung mit der nächsten wichtigen Databricks Runtime-Version zu entfernen, wenn Spark 4.0 veröffentlicht wird. Azure Databricks plant, die JDK 11-Unterstützung mit der nächsten LTS-Version von Databricks Runtime 14.x einzustellen.

Automatische Aktivierung des Unity-Katalogs für neue Arbeitsbereiche

Databricks hat bereits begonnen, Unity Catalog automatisch für neue Arbeitsbereiche zu aktivieren. Dadurch müssen Kontoadministratoren nicht länger den Unity-Katalog konfigurieren, nachdem ein Arbeitsbereich erstellt wurde. Der Rollout wird schrittweise über Konten hinweg fortgesetzt.

sqlite-jdbc-Upgrade

Databricks Runtime plant das Upgrade der sqlite-jdbc-Version von 3.8.11.2 auf 3.42.0.0 in allen Databricks Runtime-Wartungsreleases. Die APIs der Version 3.42.0.0 sind nicht vollständig mit 3.8.11.2 kompatibel. Vergewissern Sie sich, dass Ihre Methoden und der Rückgabetyp Version 3.42.0.0 verwenden.

Wenn Sie sqlite-jdbc in Ihrem Code verwenden, überprüfen Sie den sqlite-jdbc-Kompatibilitätsbericht.