Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Découvrez les fonctionnalités et les changements comportementaux dans les prochaines versions d’Azure Databricks.
Les URL publiques pour les téléchargements de pilotes ODBC sont désactivées
Dans une prochaine version, les URL publiques pour les téléchargements automatisés de pilotes ODBC Apache Spark seront désactivées. Après cette modification, tous les téléchargements de pilotes, y compris les processus automatisés, nécessitent l’authentification. Cela interrompt les processus automatisés qui téléchargent les pilotes ODBC Apache Spark à l’aide de liens publics directs sans authentification.
Mises à jour de navigation de l’Explorateur de catalogues
L’Explorateur catalogue recevra bientôt des améliorations de navigation pour simplifier les flux de travail et vous aider à découvrir et à gérer plus efficacement les ressources de données.
Navigation simplifiée :
L’onglet Catalogues duplicatifs est supprimé pour réduire la redondance et se concentrer sur une seule surface de navigation de catalogue.
DBFS et l'action Envoyer des commentaires se déplacent dans le Pour une disposition plus propre.
Nouvelle section Suggérée :
Un nouvel onglet Suggéré de la page d’accueil de l’Explorateur de catalogue met en évidence les objets fréquemment utilisés, par exemple les objets pour les utilisateurs de première fois et les favoris des utilisateurs. Cela vous permet de vous réengager rapidement avec des actifs importants ou de trouver des points de départ utiles.
Points d’entrée consolidés :
Les fonctionnalités connexes sont regroupées sous des catégories plus claires pour réduire le bruit visuel et améliorer la détectabilité :
- Gouverner : point d’entrée pour les étiquettes régies, l’administration du métastore et la classification des données
- Connexion : points d’entrée pour les emplacements externes, les données externes, les informations d’identification et les connexions
- Partager : points d’entrée pour le partage Delta et les salles propres
Ces regroupements remplacent les sous-onglets dispersés et créent une architecture d’informations plus intuitive et évolutive.
Modifications apportées à l’ouverture des jetons de destinataire du partage Delta
Le partage Delta pour les destinataires ouverts passe à un nouveau format d’URL spécifique au destinataire utilisé pour se connecter au serveur de partage Delta. Cette modification améliore la sécurité réseau et les configurations de pare-feu, en s’alignant sur les meilleures pratiques pour le partage de points de terminaison.
Jetons de destinataire créés le ou après le 9 mars 2026 :
À compter du 9 mars 2026, les nouveaux jetons de destinataire ouverts utilisent un nouveau format d’URL spécifique au destinataire pour améliorer la sécurité et le filtrage réseau. Cette modification s’applique aux jetons émis ou après cette date ; les jetons antérieurs peuvent continuer à utiliser le format d’URL plus ancien jusqu’à ce qu’ils expirent. Consultez la nouvelle stratégie de durée de vie de l’expiration du jeton dans la section suivante.
Pour Azure Chine, la transition sera annoncée ultérieurement.
Pour OIDC, les destinataires doivent passer au nouveau format d’URL d’ici le 9 mars 2027. À compter du 9 mars 2026, les fournisseurs pourront afficher le nouveau format d’URL pour les destinataires existants dans la page Partage Delta à partager avec les destinataires.
Les nouvelles URL seront au format suivant :
https://2d4b0370-9d5c-4743-9297-72ba0f5caa8d.delta-sharing.westus.azuredatabricks.net
Nouvelle stratégie de durée de vie d’expiration des jetons :
À compter du 8 décembre 2025, tous les nouveaux jetons de destinataire de partage ouvert seront émis avec une expiration maximale d’un an à compter de la date de création. Les jetons dont la validité est plus longue ou illimitée ne peuvent plus être créés.
Pour les jetons créés à l’aide du format d’URL du destinataire précédent entre le 8 décembre 2025 et le 9 mars 2026, chaque jeton expire automatiquement un an après sa création. Lors de la rotation des jetons, les fournisseurs peuvent configurer une fenêtre de temps d’arrêt pour permettre aux destinataires de migrer. Pendant cette fenêtre, les URL des anciens et nouveaux destinataires continuent de fonctionner.
Si vous utilisez actuellement des jetons de destinataire avec des durées de vie longues ou illimitées, passez en revue vos intégrations et n’oubliez pas de faire pivoter les jetons chaque année si nécessaire, car les jetons expireront le 8 décembre 2026.
Voyage dans le temps et VACUUM modifications comportementales pour les tables gérées par Unity Catalog
En janvier 2026, le voyage dans le temps et les changements de comportement introduits dans Databricks Runtime 18.0 s’étendront au calcul serverless, à Databricks SQL et à Databricks Runtime 12.2 et versions ultérieures pour les VACUUM.
Ces modifications sont les suivantes :
- Les requêtes de voyage dans le temps sont bloquées si elles dépassent
delta.deletedFileRetentionDuration. -
delta.logRetentionDurationdoit être supérieur ou égal àdelta.deletedFileRetentionDuration.
Notifications par e-mail pour l’expiration des jetons d’accès personnels
Azure Databricks enverra bientôt des notifications par e-mail aux utilisateurs de l’espace de travail environ sept jours avant l’expiration de leurs jetons d’accès personnels. Les notifications sont envoyées uniquement aux utilisateurs de l’espace de travail (et non aux principaux de service) avec des noms d’utilisateur basés sur les e-mails. Tous les jetons arrivant à expiration dans le même espace de travail sont regroupés dans un seul e-mail.
Consultez Surveiller et révoquer des jetons d’accès personnels.
Le mode agent Génie Recherche peut bientôt utiliser des modèles servis via Amazon Bedrock
Le mode agent Genie Research sera bientôt en mesure d’utiliser des modèles servis via Amazon Bedrock lorsque les fonctionnalités d’IA optimisées par les partenaires sont activées.
Mise à jour de la chronologie de fin de prise en charge pour les tableaux de bord hérités
- La prise en charge officielle de la version héritée des tableaux de bord a pris fin le 7 avril 2025. Seuls les problèmes de sécurité critiques et les pannes de service sont résolus.
- 3 novembre 2025 : Databricks a commencé à présenter aux utilisateurs une boîte de dialogue d’avertissement qu'il est possible de fermer lors de l’accès à un tableau de bord hérité. La boîte de dialogue rappelle aux utilisateurs que l’accès aux tableaux de bord hérités se termine le 12 janvier 2026 et fournit une option en un clic pour migrer vers l’IA/BI.
- 12 janvier 2026 : les tableaux de bord et LES API hérités ne seront plus directement accessibles. Toutefois, ils fourniront toujours la possibilité de mettre à jour sur place l’IA/BI. La page de migration sera disponible jusqu’au 2 mars 2026.
Pour faciliter la transition vers des tableaux de bord IA/BI, les outils de mise à niveau sont disponibles à la fois dans l’interface utilisateur et l’API. Pour obtenir des instructions sur l’utilisation de l’outil intégré de migration de l’interface utilisateur, consultez Cloner un ancien tableau de bord sur un tableau de bord alimenté par IA/BI. Pour obtenir des didacticiels sur la création et la gestion de tableaux de bord à l’aide de l’API REST, consultez Utiliser les API Azure Databricks pour gérer les tableaux de bord.
Partage de fédération Lakehouse et stockage par défaut
Delta Sharing sur Lakehouse Federation est en version bêta, ce qui permet aux fournisseurs de données Delta Sharing de partager des catalogues et des tables externes. Par défaut, les données doivent être temporairement matérialisées et stockées sur le stockage par défaut (préversion privée). Actuellement, les utilisateurs doivent activer manuellement le partage Delta pour le stockage par défaut : fonctionnalité d’accès étendu dans la console de compte pour utiliser le partage de fédération Lakehouse.
Une fois le partage Delta pour le stockage par défaut : l’accès étendu est activé par défaut pour tous les utilisateurs Azure Databricks, le partage Delta sur Lakehouse Federation sera automatiquement disponible dans les régions où le stockage par défaut est pris en charge.
Consultez Stockage par défaut dans Databricks et Ajouter des schémas ou des tables étrangers à un partage.
Recharger la notification dans les espaces de travail
Dans une prochaine version, un message pour recharger l’onglet de votre espace de travail s’affiche si l’onglet de votre espace de travail a été ouvert depuis longtemps sans actualisation. Cela vous aidera à vous assurer que vous utilisez toujours la dernière version de Databricks avec les dernières fonctionnalités et correctifs.
SAP Business Data Cloud (BDC) Connector pour Azure Databricks sera bientôt disponible en disponibilité générale
Le connecteur SAP Business Data Cloud (BDC) pour Azure Databricks est une nouvelle fonctionnalité qui vous permet de partager des données de SAP BDC vers Azure Databricks et d’Azure Databricks vers SAP BDC à l’aide du partage Delta. Cette fonctionnalité sera généralement disponible à la fin de septembre.
Le partage delta pour les tables sur le stockage par défaut sera bientôt activé par défaut (bêta)
Cette mise à jour de stockage par défaut pour le partage Delta a développé des fonctionnalités de partage, ce qui permet aux fournisseurs de partager des tables sauvegardées par défaut sur n’importe quel destinataire delta Sharing (ouvert ou Azure Databricks), y compris les destinataires utilisant le calcul classique. Cette fonctionnalité est actuellement en version bêta et nécessite que les fournisseurs activent manuellement le partage Delta pour le stockage par défaut – Accès étendu dans la console de compte. Bientôt, cette option sera activée par défaut pour tous les utilisateurs.
Voir Limitations.
Mises à jour des adresses IP publiques du plan de gestion des flux sortants
Azure Databricks met à jour les adresses IP publiques du plan de contrôle sortant et les balises de service Azure pour améliorer la sécurité et la disponibilité des zones. Ces modifications font partie d’une mise à jour du plan de contrôle qui a commencé à être déployée le 20 mai 2025.
Si votre organisation utilise des pare-feu de ressources pour contrôler l’accès entrant :
- Si vos règles de pare-feu référencent la balise de service Azure Databricks, aucune action n’est requise.
- Si vous autorisez des adresses IP publiques de plan de contrôle spécifiques, vous devez ajouter toutes les adresses IP du plan de contrôle sortant avant le 26 septembre 2025.
Les adresses IP du plan de contrôle sortant précédentes continuent d’être prises en charge.
Modification du comportement pour l'option de liste de répertoire incrémentielle de l'Auto Loader
Remarque
L'option Chargeur Automatique cloudFiles.useIncrementalListing est obsolète. Bien que cette note traite d'une modification de la valeur par défaut de l'option et de la manière de continuer à l'utiliser après ce changement, Databricks recommande de ne pas utiliser cette option au profit du mode de notification de fichier avec des événements de fichier.
Dans une prochaine version de Databricks Runtime, la valeur de l’option de chargement automatique déconseillée cloudFiles.useIncrementalListing sera définie par défaut sur false. La définition de cette valeur false entraîne l’exécution d’un répertoire complet à chaque exécution du chargeur automatique. Actuellement, la valeur par défaut de l’option cloudFiles.useIncrementalListing est auto, demandant au chargeur automatique d’effectuer une tentative optimale pour détecter si une liste incrémentielle peut être utilisée avec un répertoire.
Pour continuer à utiliser la fonctionnalité de liste incrémentielle, définissez l’option cloudFiles.useIncrementalListing sur auto. Lorsque vous définissez cette valeur sur auto, Auto Loader tente d’effectuer une liste complète toutes les sept listes incrémentielles, ce qui correspond au comportement de cette option avant cette modification.
Pour en savoir plus sur la liste des répertoires d'Auto Loader, consultez Flux d'Auto Loader avec mode de liste des répertoires.
Modification du comportement lorsque les définitions de jeu de données sont supprimées des pipelines déclaratifs Spark Lakeflow
Une prochaine version des pipelines déclaratifs Lakeflow Spark modifiera le comportement lorsqu’une vue matérialisée ou une table de diffusion en continu est supprimée d’un pipeline. Avec cette modification, la vue matérialisée supprimée ou la table de diffusion en continu ne sera pas supprimée automatiquement lors de l’exécution de la prochaine mise à jour du pipeline. Au lieu de cela, vous pourrez utiliser la commande DROP MATERIALIZED VIEW pour supprimer une vue matérialisée ou la commande DROP TABLE pour supprimer une table de diffusion en continu. Après avoir supprimé un objet, l’exécution d’une mise à jour de pipeline ne récupère pas automatiquement l’objet. Un nouvel objet est créé si une vue matérialisée ou une table de diffusion en continu avec la même définition est re-ajoutée au pipeline. Toutefois, vous pouvez récupérer un objet à l’aide de la commande UNDROP.
Le champ sourceIpAddress dans les journaux d’audit n’inclut plus de numéro de port.
En raison d’un bogue, certains journaux d’audit d’autorisation et d’authentification incluent un numéro de port en plus de l’adresse IP dans le champ sourceIPAddress (par exemple, "sourceIPAddress":"10.2.91.100:0"). Le numéro de port, qui est enregistré en tant que 0, ne fournit aucune valeur réelle et n’est pas cohérent avec le reste des journaux d’audit Databricks. Pour améliorer la cohérence des journaux d’audit, Databricks prévoit de modifier le format de l’adresse IP pour ces événements de journal d’audit. Cette modification sera progressivement déployée à partir de début août 2024.
Si le journal d’audit contient une sourceIpAddress dont la valeur est 0.0.0.0, il est possible que Databricks arrête sa journalisation.