Databricks Runtime 19 (bêta)

Cette page contient des notes de publication unifiées pour Databricks Runtime 19, alimentée par Apache Spark 4.2.0. Il répertorie toutes les fonctionnalités, modifications comportementales et correctifs fournis tout au long du cycle de publication de Databricks Runtime 19. Les clusters reçoivent des mises à jour quand ils redémarrent.

Pour plus d’informations sur le cycle de vie de support databricks Runtime, consultez Les cycles de vie de support databricks.

Databricks Runtime 19 (bêta) : 26 juin 2026

Changements comportementaux

• Disponibilité des variables d’environnement limitée en mode d’accès standard : en mode d’accès standard, seul un ensemble prédéfini de variables d’environnement est disponible pour le moteur Spark et les scripts init. Cet ensemble inclut des variables de configuration courantes, telles que les paramètres proxy (HTTP_PROXY), les informations d’identification cloud (AWS_ACCESS_KEY_ID, AZURE_CLIENT_IDet les variables de catalogue).CATALOG Les autres variables que vous définissez dans un cluster restent disponibles pour le code de l’utilisateur, y compris les UDF, mais ne sont en revanche pas accessibles au moteur Spark ni aux scripts d’initialisation. Auparavant, toutes les variables d’environnement de cluster étaient disponibles pour le moteur Spark et les scripts init. Consultez les limitations des variables d’environnement.
• Configurations Spark restreintes en mode d’accès standard : en mode d’accès standard, vous ne pouvez plus définir certaines propriétés de configuration Spark. La création ou la modification d’un cluster qui définit une propriété restreinte (mise en correspondance par préfixe) échoue avec une erreur. Les propriétés restreintes incluent spark.driver.extraJavaOptions, , spark.executor.extraJavaOptionsspark.jarsspark.files, spark.executorEnv.*, et spark.kubernetes.*, entre autres. Auparavant, vous pouviez définir ces propriétés en mode d’accès standard. Supprimez-les de la configuration de votre cluster avant la mise à niveau. Pour obtenir la liste complète, consultez les limitations de configuration Spark.

Databricks Runtime 19 (bêta) : 15 juin 2026

Databricks Runtime 19 est désormais disponible en version bêta, avec Apache Spark 4.2.0.

Changements comportementaux

• JDK 17 supprimé : Databricks Runtime 19 prend uniquement en charge JDK 21. Auparavant, Databricks Runtime 18 incluait JDK 17 comme option de secours qui pouvait être sélectionnée à l’aide de la variable d’environnement JNAME . Cette solution de repli n’est plus disponible dans Databricks Runtime 19. Les clusters qui définissent JNAME=zulu17-ca-amd64 (ou l’équivalent ARM) doivent supprimer cette variable d’environnement avant la mise à niveau.
• Python packages supprimés : par rapport à Databricks Runtime 18, environ 90 packages d’exécution standard sont supprimés dans Databricks Runtime 19. Les suppressions notables incluent plotly, seaborn, openai, langchain-core, langchain-openai, huggingface_hub, psycopg2, et pyodbc. Le serveur groupé JupyterLab est fractionné de l’image de base, supprimant environ 54 packages liés à Jupyter. Les charges de travail qui dépendent de ces packages doivent les installer explicitement à l’aide d’une bibliothèque de cluster ou d’un script init. Pour obtenir la liste complète des packages inclus dans Databricks Runtime 19, consultez Les bibliothèques installées Python. Pour connaître les suppressions spécifiques au runtime ML, consultez Databricks Runtime 19 pour Machine Learning (bêta).
• Propriété pipelines.pipelineIdde table réservée : Databricks Runtime 19 réserve la pipelines.pipelineId propriété de table sur toutes les tables. Si vous tentez de définir cette propriété manuellement, une erreur s’affiche. Supprimez toutes les affectations explicites de pipelines.pipelineId dans votre DDL de table avant la mise à niveau.
• Décalage du watermark en mode temps réel augmenté de +1 ms : dans les requêtes de streaming en mode temps réel (RTM), lorsque le watermark progresse en cours de lot via la propagation du watermark en temps réel, un enregistrement dont l’heure de l’événement est égale au watermark actuel était auparavant considéré comme tardif et supprimé. Le délai de filigrane au moment de l’événement est maintenant décalé de +1 ms, de sorte que la vérification des enregistrements en retard est effectivement stricte et les enregistrements dont l’heure d’événement est égale à la filigrane actuelle sont maintenant conservés. Le mode micro-batch n’est pas affecté.
• Liste d’autorisation des classes pour les checkpoints DStream requise pour les types personnalisés : Apache Spark 4.2.0 introduit un contrôle de sécurité pour la désérialisation des checkpoints DStream. Les utilisateurs qui utilisent des types personnalisés ou tiers dans des clôtures DStream doivent définir spark.streaming.checkpoint.allowedClasses comme une liste séparée par des virgules de noms de classes entièrement qualifiés ou de motifs génériques avant de tenter la récupération à partir du point de contrôle. La liste d’autorisation intégrée par défaut couvre uniquement les types standard de Spark.

Correctifs et améliorations d’Apache Spark

Databricks Runtime 19 inclut Apache Spark 4.2.0. Cette version inclut tous les correctifs spark et améliorations inclus dans Databricks Runtime 18, ainsi que les correctifs de bogues et améliorations supplémentaires suivants apportés à Spark :

• is_valid_variant expression : SQL prend désormais en charge is_valid_variant(expr), qui retourne true si l’entrée est une valeur bien formée VARIANT et false sinon. Utilisez-la pour valider les données variant avant le traitement en aval.
• Syntaxe INSERT INTO ... REPLACE ON/USING : SQL prend désormais en charge les syntaxes INSERT INTO ... REPLACE ON <columns> et INSERT INTO ... REPLACE USING <subquery>, permettant des opérations d’upsert qui remplacent les lignes existantes sur la base de valeurs de colonnes correspondantes.
• Gestion des transactions DSv2 : les catalogues de source de données v2 prennent désormais en charge la gestion des transactions, ce qui permet d’écrire des tables multiples atomiques et de lire de manière cohérente entre les opérations de catalogue.
• Post-traitement CDC par lots avec ChangelogTable : SQL prend désormais en charge la lecture de la sortie de capture de données modifiées (CDC) sous forme de journal de modifications et le calcul des modifications nettes en mode batch. L’analyseur ResolveChangelogTable valide le schéma de journal des modifications et calcule les résultats fusionnés à partir de lignes CDC brutes.
• Échantillonnage par blocs TABLESAMPLE SYSTEM avec pushdown DSv2 : TABLESAMPLE SYSTEM est désormais pris en charge pour les tables Data Source v2, ce qui permet de pousser vers la source de données un échantillonnage au niveau des blocs fondé sur un pourcentage, afin d’améliorer les performances.
• CREATE VIEW et ALTER VIEW pour les catalogues DSv2 : les catalogues Data Source v2 prennent désormais en charge les instructions CREATE VIEW et ALTER VIEW, apportant la parité DDL des vues aux catalogues non-Hive.
• CREATE METRIC VIEW sur les catalogues V2: CREATE METRIC VIEW est désormais pris en charge sur les catalogues Data Source V2.
• Les fonctions quantile KLL dans SQL : SQL prend désormais en charge en mode natif les fonctions de croquis quantile KLL optimisées par Apache DataSketches, notamment les fonctions d’agrégation et de calcul CDF pour les requêtes quantile approximatives.
• Les fonctions Tuple Sketch dans SQL : SQL prend désormais en charge en mode natif les fonctions d’agrégation de croquis Apache Tuple, ce qui permet d’effectuer des opérations d’intersection et d’union approximatives sur des charges utiles typées arbitrairement.
• withSchemaEvolution() dans l’API enregistreur DataFrame : l’API enregistreur DataFrame inclut withSchemaEvolution()désormais , ce qui permet l’évolution automatique du schéma lors de l’écriture dans des tables qui le prennent en charge.
• Dataset.zipWithIndex dans l’API Scala : l’API Scala Dataset inclut désormais zipWithIndex, qui associe chaque élément à sa position d’index, en cohérence avec les API Python et Java existantes.
• Fonctions scalaires définies par l’utilisateur dans les arguments de fonctions retournant une table : SQL prend désormais en charge l’utilisation de fonctions scalaires définies par l’utilisateur comme arguments de fonctions retournant une table, ce qui permet un paramétrage plus avancé.
• DataFrameGroupBy.cov dans l’API pandas de Spark : l’API pandas de Spark prend désormais en charge DataFrameGroupBy.cov, c’est-à-dire le calcul de la covariance par paires des colonnes au sein de chaque groupe.
• SeriesGroupBy.describe dans l’API pandas sur Spark : l’API pandas sur Spark prend désormais en charge SeriesGroupBy.describe, générant des statistiques descriptives pour chaque groupe.
• Liens de téléchargement de plan dans l’interface utilisateur Spark : la page d’exécution de l’interface utilisateur Spark inclut désormais des liens de téléchargement pour les plans de requête dans les formats SVG, DOT et TXT.
• Prise en charge de pa.ChunkedArray dans createDataFrame : createDataFrame() gère désormais correctement les DataFrame pandas contenant des colonnes PyArrow ChunkedArray, évitant ainsi les erreurs de type lors de l’utilisation de données pandas reposant sur Arrow.
• Prise en charge de la génération de code pour les fonctions d’ordre supérieur sur les tableaux : Les fonctions d’ordre supérieur sur les tableaux, telles que filter, transform et aggregate, bénéficient désormais de la génération du bytecode JVM lors de la compilation des requêtes, ce qui améliore les performances des charges de travail qui utilisent intensivement ces fonctions.
• Correctif : cohérence de exceptAll après dropDuplicates avec sous-ensemble de colonnes : correction d’un bogue où df.dropDuplicates(subset).exceptAll(other) produisait des résultats incorrects. Le correctif garantit que la logique de suivi en double gère correctement la déduplication du sous-ensemble.
• Correctif : l’analyseur SQL conserve les instructions se terminant par les commentaires de bloc : un bogue est résolu où les instructions SQL se terminant par un commentaire de bloc ont été supprimées silencieusement par le séparateur de points-virgules. Toutes les instructions sont désormais analysées correctement, quel que soit le style de commentaire de fin.
• Correctif : cohérence des jointures flux-flux dans le format d’état V4 : correction d'un bogue dans les jointures flux-flux avec prédicats de fenêtre temporelle lors de l’utilisation du format de stockage d’état RocksDB V4, évitant des résultats incorrects dans les requêtes de streaming avec état.

Mises à niveau de la bibliothèque

Les bibliothèques sont mises à niveau uniquement lorsqu’il existe un risque de sécurité avec une version antérieure. Lorsqu’une vulnérabilité est identifiée, Databricks effectue une mise à niveau vers la version la plus ancienne qui résout le problème. Si une bibliothèque a été mise à niveau pendant ce cycle de publication en raison d’un correctif de sécurité confirmé, la version précédente est également répertoriée pour documenter la transition.

Python

R

Java

Prise en charge du pilote ODBC/JDBC Databricks

Databricks prend en charge les pilotes ODBC/JDBC publiés au cours des 2 dernières années. Téléchargez les pilotes et la mise à niveau récemment publiés (téléchargez ODBC, téléchargez JDBC).

Environnement du système

• Système d’exploitation : Ubuntu 24.04.4 LTS
• Java : Zulu21.48+15-CA
• Scala : 2.13.16
• Python : 3.12.3
• R : 4.6.0
• Delta Lake : 4.2.0

Bibliothèques Python installées

Bibliothèques R installées

Les bibliothèques R sont installées à partir de l'instantané CRAN du gestionnaire de packages sur PACKAGES.

Bibliothèques Java et Scala installées (version du cluster Scala 2.13)