Partager via


Étapes suivantes ?

Découvrez les fonctionnalités et les changements comportementaux dans les prochaines versions d’Azure Databricks.

Changement de comportement pour l’option de liste de répertoires incrémentielle du Chargeur Automatique

Remarque

L'option Chargeur Automatique cloudFiles.useIncrementalListing est obsolète. Bien que cette note traite d’une modification de la valeur par défaut des options et de la façon de continuer à l’utiliser après cette modification, Databricks recommande de remplacer l’utilisation de cette option par mode de notification 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. Définir cette valeur sur false entraîne Auto Loader à effectuer une liste complète du répertoire à chaque exécution. 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 true. Lorsque vous définissez cette valeur sur true, le chargeur automatique effectue une liste complète une fois toutes les 7 listes incrémentielles.

Pour plus d’informations sur les options de liste des répertoires d’Auto Loader, consultez Options d’Auto Loader.

Gestion des statistiques activée par défaut avec optimisation prédictive

À partir du 21 janvier, Databricks commencera à activer la gestion des statistiques pour tous les comptes dont l’optimisation prédictive est activée. La gestion des statistiques étend les fonctionnalités d’optimisation prédictive existantes en ajoutant une collection de statistiques en écriture et en exécutant automatiquement des commandes ANALYZE pour les tables gérées de Unity Catalog. Pour plus d’informations sur l’optimisation prédictive, consultez Optimisation prédictive pour les tables managées d’Unity Catalog.

Calcul serverless pour obtenir la prise en charge du Kit de développement logiciel (SDK) Scala pour les informations d’identification du service

Une mise à jour du calcul serverless prendra en charge l’authentification gouvernée par Unity Catalog pour les services cloud externes en utilisant les informations d’identification du service avec le Kit de développement logiciel (SDK) Scala. La prise en charge Scala de l'authentification par principal de service, déjà disponible dans Databricks Runtime 16.2 et versions ultérieures, complète la prise en charge de l'authentification avec les identifiants de service à l'aide du SDK Python. Consultez Gérer l’accès aux services cloud externes en utilisant des informations d’identification de service.

Modification du comportement lorsque les définitions de jeu de données sont supprimées d’un pipeline Delta Live Tables

Une prochaine version de Delta Live Tables modifie 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.

Les notebooks IPYNB deviendront le format de notebook par défaut pour Azure Databricks

Actuellement, Databricks crée tous les nouveaux notebooks au format « Databricks source » par défaut, qui capture uniquement du code. En janvier 2025, le nouveau format de notebook par défaut sera IPYNB (.ipynb), qui capture également l’environnement de notebook, les définitions de visualisation et les widgets de notebook. Cette nouvelle valeur par défaut peut être modifiée dans le volet utilisateur Paramètres de l’espace de travail. Pour plus d’informations sur les formats de carnets, consultez formats de carnets.

Les fichiers d’espace de travail seront activés pour tous les espaces de travail Azure Databricks le 1er février 2025

Databricks activera les fichiers d’espace de travail pour tous les espaces de travail Azure Databricks le 1er février 2025. Cette modification débloque l'utilisation, par les utilisateurs de l'espace de travail, des nouvelles fonctionnalités de fichiers dans l'espace de travail. Après le 1er février 2025, vous ne pourrez pas désactiver les fichiers d’espace de travail en utilisant la propriété enableWorkspaceFilesystem avec l’API REST Azure Databricks pour activer et désactiver des fonctionnalités d’espace de travail. Pour plus d’informations sur les fichiers d’espace de travail, consultez Qu’est-ce que les fichiers d’espace de travail ?.

Les tables sont partagées avec l’historique par défaut dans le partage Delta

Databricks prévoit de modifier le paramètre par défaut pour les tables partagées à l’aide du partage Delta pour inclure l’historique par défaut. Auparavant, le partage d’historique était désactivé par défaut. Le partage de l’historique des tables améliore les performances de lecture et fournit une prise en charge automatique des optimisations Delta avancées.

Réduction des coûts et plus de contrôle des performances par rapport au coût de votre calcul serverless pour les charges de travail des workflows

En plus des optimisations automatiques des performances actuellement prises en charge, les améliorations apportées au calcul serverless pour les fonctionnalités d’optimisation des workflows vous permettent de mieux contrôler si les charges de travail sont optimisées pour les performances ou pour les coûts. Pour plus d’informations, consultez Économies sur le calcul serverless pour les notebooks, les travaux et les pipelines.

Modifications apportées à la prise en charge des versions de tableau de bord héritées

Databricks recommande d’utiliser des tableaux de bord AI/BI (anciennement appelés tableaux de bord Lakeview). Les versions antérieures des tableaux de bord, précédemment appelées tableaux de bord Databricks SQL, sont désormais appelées tableaux de bord hérités. Databricks déconseille de créer des tableaux de bord hérités. Les tableaux de bord IA/BI offrent des fonctionnalités améliorées par rapport à la version héritée, notamment la création assistée par l’IA, les modes brouillons et publiés et le filtrage croisé.

Chronologie de fin de prise en charge des anciens tableaux de bord

  • le 7 avril 2025: La prise en charge officielle de la version ancienne des tableaux de bord se terminera. Seuls les problèmes de sécurité critiques et les pannes de service sont résolus.
  • 3 novembre 2025 : Databricks commencera à archiver les tableaux de bord hérités qui n’ont pas été accessibles au cours des six derniers mois. Les tableaux de bord archivés ne seront plus accessibles et le processus d’archivage se produira de manière propagée. L’accès aux tableaux de bord activement utilisés reste inchangé.

Databricks collaborera avec les clients pour développer des plans de migration pour les tableaux de bord hérités actifs après le 3 novembre 2025.

Pour faciliter la transition vers des tableaux de bord AI/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 tutoriels sur la création et la gestion de tableaux de bord avec l’API REST, consultez Utiliser les API Azure Databricks pour gérer des tableaux de bord.

Modifications apportées à l’attribution de charge de travail de calcul serverless

Actuellement, votre table système d’utilisation facturable peut inclure des enregistrements de facturation de référence SKU serverless avec des valeurs nulles pour run_as, job_id, job_run_id et notebook_id. Ces enregistrements représentent les coûts associés à des ressources partagées qui ne sont pas directement attribuables à une charge de travail particulière.

Pour simplifier la création de rapports sur les coûts, Databricks attribuera prochainement ces coûts partagés aux charges de travail spécifiques les ayant subis. Vous ne verrez plus d’enregistrements de facturation avec des valeurs nulles dans les champs d’identificateur de charge de travail. À mesure que vous augmentez votre utilisation du calcul serverless et que vous ajoutez davantage de charges de travail, la proportion de ces coûts partagés sur votre facture va diminuer, car ils seront partagés entre davantage de charges de travail.

Pour plus d’informations sur la surveillance des coûts du calcul serverless, consultez Surveiller le coût du calcul serverless.

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, Databricks peut arrêter sa journalisation.

JDK8 et JDK11 ne seront pas pris en charge.

Azure Databricks prévoit de supprimer la prise en charge de JDK 8 avec la prochaine version majeure de Databricks Runtime, à l’occasion de la publication de Spark 4.0. Azure Databricks prévoit de supprimer la prise en charge de JDK 11 avec la prochaine version LTS de Databricks Runtime 14.x.

Activation automatique d’Unity Catalog pour les nouveaux espaces de travail

Databricks a commencé à activer automatiquement Unity Catalog pour les nouveaux espaces de travail. Ceci évite aux administrateurs de compte de devoir configurer Unity Catalog après la création d’un espace de travail. Le lancement se fait progressivement sur les comptes.

Mise à niveau de sqlite-jdbc

Databricks Runtime prévoit de mettre à niveau la version sqlite-jdbc de 3.8.11.2 vers 3.42.0.0 dans toutes les versions de maintenance de Databricks Runtime. Les API de la version 3.42.0.0 ne sont pas entièrement compatibles avec la version 3.8.11.2. Vérifiez que vos méthodes et le type de retour utilisent la version 3.42.0.0.

Si vous utilisez sqlite-jdbc dans votre code, consultez le rapport de compatibilité de sqlite-jdbc.