Fabric Runtime 1.2 (GA)

Microsoft Fabric Runtime est une plateforme intégrée à Azure basée sur Apache Spark qui permet l’exécution et la gestion d’expériences d’ingénierie des données et de science des données. Ce document couvre les composants et versions du Runtime 1.2.

Les principaux composants de Runtime 1.2 sont les suivants :

• Apache Spark 3.4.1
• Système d’exploitation : Mariner 2.0
• Java : 11
• Scala : 2.12.17
• Python : 3.10
• Delta Lake : 2.4.0
• R: 4.2.2

Microsoft Fabric Runtime 1.2 est fourni avec une collection de packages de niveau par défaut, y compris une installation complète d’Anaconda et des bibliothèques couramment utilisées pour Java/Scala, Python et R. Ces bibliothèques sont automatiquement incluses lors de l’utilisation de notebooks ou de travaux dans la plateforme Microsoft Fabric. Reportez-vous à la documentation pour obtenir la liste complète des bibliothèques. Microsoft Fabric déploie régulièrement des mises à jour de maintenance pour Runtime 1.2, fournissant des correctifs de bogues, des améliorations des performances et des correctifs de sécurité. Rester à jour garantit des performances et une fiabilité optimales pour vos tâches de traitement des données.

Nouvelles fonctionnalités et améliorations de la version 3.4.1 de Spark

Apache Spark 3.4.0 est la cinquième version de la ligne 3.x. Cette version, pilotée par la communauté open source, a résolu plus de 2 600 tickets Jira. Elle introduit un client Python pour Spark Connect, améliore la diffusion de flux structuré avec le suivi de progression asynchrone et le traitement avec état Python. Elle étend la couverture de l’API Pandas avec la prise en charge des entrées NumPy, simplifie la migration à partir d’entrepôts de données traditionnels par le biais de la conformité ANSI et de nouvelles fonctions intégrées. Elle améliore également la productivité et la capacité de débogage du développement avec le profilage de la mémoire. En outre, Runtime 1.2 est basé sur Apache Spark 3.4.1, une version de maintenance axée sur les correctifs de stabilité.

Points clés

Lisez la version complète des notes de publication d’une version spécifique d’Apache Spark en visitant Spark 3.4.0 et Spark 3.4.1.

Nouvelles optimisations de requête personnalisées

Prise en charge des écritures simultanées dans Spark

La présence d’une erreur 404 avec le message « Échec de l’opération : le chemin spécifié n’existe pas » est un problème courant lors de l’exécution d’insertions de données parallèles dans la même table à l’aide d’une requête SQL INSERT INTO. Cette erreur peut entraîner une perte de données. Notre nouvelle fonctionnalité, l’algorithme de commiteur de sortie de fichier, résout ce problème, ce qui permet aux clients d’effectuer en toute transparence l’insertion de données parallèles.

Pour accéder à cette fonctionnalité, activez l’indicateur de fonctionnalité spark.sql.enable.concurrentWrites, qui est activé par défaut à partir de Runtime 1.2 (Spark 3.4). Bien que cette fonctionnalité soit également disponible dans d’autres versions de Spark 3, elle n’est pas activée par défaut. Cette fonctionnalité ne prend pas en charge l’exécution parallèle de requêtes INSERT OVERWRITE où chaque travail simultané remplace les données sur différentes partitions de la même table de manière dynamique. À cet effet, Spark offre une autre fonctionnalité, qui peut être activée en configurant le paramètre spark.sql.sources.partitionOverwriteMode sur dynamique.

Lectures actives, qui ignorent les fichiers des travaux ayant échoué

Dans le système de commiteur Spark actuel, lorsqu’une insertion dans un travail de table échoue mais que certaines tâches réussissent, les fichiers générés par les tâches réussies coexistent avec les fichiers du travail ayant échoué. Cette coexistence peut entraîner une confusion pour les utilisateurs, car il devient difficile de distinguer les fichiers appartenant à des travaux réussis et non réussis. En outre, lorsqu’un travail lit à partir d’une table tandis qu’un autre insère des données simultanément dans la même table, le travail de lecture peut accéder aux données non commitées. En cas d’échec d’un travail d’écriture, le travail de lecture peut traiter des données incorrectes.

L’indicateur spark.sql.auto.cleanup.enabled contrôle notre nouvelle fonctionnalité, en répondant à ce problème. Lorsqu’il est activé, Spark ignore automatiquement la lecture des fichiers qui n’ont pas été commités lorsqu’il effectue spark.read ou sélectionne des requêtes à partir d’une table. Les fichiers écrits avant l’activation de cette fonctionnalité continuent d’être lus comme d’habitude.

Voici les modifications visibles :

• Tous les fichiers incluent désormais un identificateur tid-{jobID} dans leurs noms de fichiers.
• Au lieu du marqueur _success généralement créé à l’emplacement de sortie lors de la réussite de la tâche, un nouveau marqueur _committed_{jobID} est généré. Ce marqueur associe les ID des travaux réussis à des noms de fichiers spécifiques.
• Nous avons introduit une nouvelle commande SQL que les utilisateurs peuvent exécuter régulièrement pour gérer le stockage et nettoyer les fichiers non commités. La syntaxe de cette commande est la suivante :
  • Pour nettoyer un répertoire spécifique : CLEANUP ('/path/to/dir') [RETAIN number HOURS];
  • Pour nettoyer une table spécifique : CLEANUP [db_name.]table_name [RETAIN number HOURS]; Dans cette syntaxe, path/to/dir représente l’URI d’emplacement où le nettoyage est requis et number est une valeur de type double représentant la période de rétention. La période de rétention par défaut est définie à sept jours.
• Nous avons introduit une nouvelle option de configuration appelée spark.sql.deleteUncommittedFilesWhileListing, définie sur false par défaut. L’activation de cette option entraîne la suppression automatique de fichiers non commités pendant les lectures, mais ce scénario peut ralentir les opérations de lecture. Il est recommandé d’exécuter manuellement la commande de nettoyage lorsque le cluster est inactif au lieu d’activer cet indicateur.

Guide de migration de Runtime 1.1 vers Runtime 1.2

Lors de la migration de Runtime 1.1 avec Apache Spark 3.3, vers Runtime 1.2 avec Apache Spark 3.4, passez en revue le guide de migration officiel.

Améliorations et nouvelles fonctionnalités de Delta Lake 2.4

Delta Lake est un projet open source qui permet de créer une architecture lakehouse au-dessus des lacs de données. Delta Lake propose des transactions ACID et une gestion des métadonnées scalable, et il unifie le traitement de données en streaming et par lots par-dessus les lacs de données existants.

Plus précisément, Delta Lake offre :

• Transactions ACID sur Spark : les niveaux d’isolation sérialisables garantissent que les lecteurs ne voient jamais des données incohérentes.
• Gestion des métadonnées scalable : utilise la puissance de traitement distribuée Spark pour gérer toutes les métadonnées des tables à l’échelle du pétaoctet avec des milliards de fichiers en toute simplicité.
• Unification de la diffusion en continu et du traitement par lots : une table dans Delta Lake est une table de lots ainsi qu’une source et un récepteur de diffusion en continu. L’ingestion de données de streaming, le renvoi d’historique de lot et les requêtes interactives fonctionnent sans nécessiter de configuration.
• Mise en œuvre de schéma : gère automatiquement les variations de schéma afin d’empêcher l’insertion d’enregistrements incorrects lors de l’ingestion.
• Voyage dans le temps : le versioning de données autorise les restaurations, les pistes d’audit historiques complètes et les expériences de Machine Learning reproductibles.
• Upserts et suppressions : prend en charge les opérations de fusion, de mise à jour et de suppression pour activer des cas d’usage complexes tels que les opérations de capture des changements de données, les opérations de dimension à évolution lente (SCD), la diffusion en continu d’upserts, ainsi de suite.

Lisez la version complète des notes de publication pour Delta Lake 2.4.

Packages de niveau par défaut pour les bibliothèques Java, Scala, Python

Pour obtenir la liste de tous les packages de niveau par défaut pour Java, Scala, Python et leurs versions respectives, consultez les notes de publication.

Contenu connexe

• Consultez Runtimes Apache Spark dans Fabric : vue d’ensemble, contrôle de version, prise en charge de plusieurs runtimes et mise à niveau du protocole Delta Lake