Nouvelles fonctionnalités de spark3.0

Document réimprimé: après
près de deux ans, la version officielle d'Apache Spark 3.0.0 est enfin disponible

Élagage de partition dynamique (élagage de partition dynamique)

La coupe de partition dite dynamique est basée sur les informations déduites au moment de l'exécution (exécution) pour poursuivre la coupe de partition. Par exemple, nous avons la requête suivante:

SELECT * FROM dim_iteblog 
JOIN fact_iteblog 
ON (dim_iteblog.partcol = fact_iteblog.partcol) 
WHERE dim_iteblog.othercol > 10

En supposant que dim_iteblog.othercol> 10 de la table dim_iteblog filtre moins de données, mais comme la version précédente de Spark ne peut pas calculer dynamiquement le coût, la table fact_iteblog peut analyser une grande quantité de données non valides. Avec la réduction de partition dynamique, les données inutiles de la table fact_iteblog peuvent être filtrées lors de l'exécution. Après cette optimisation, les données pour l'analyse des requêtes sont considérablement réduites et les performances sont améliorées de 33 fois.

Configuration associée:

Pour activer l'élagage de partition dynamique, vous devez définir le paramètre spark.sql.optimizer.dynamicPartitionPruning.enabled sur true (par défaut), autres paramètres associés:

• spark.sql.optimizer.dynamicPartitionPruning.useStats ： true （默认） ， Lorsque true, des statistiques de comptage distinctes seront utilisées pour calculer la taille des données de la table partitionnée après l'élagage de partition dynamique, afin d'évaluer s'il vaut la peine d'ajouter une sous-requête supplémentaire comme filtre d'élagage si la réutilisation par diffusion n'est pas applicable.
• spark.sql.optimizer.dynamicPartitionPruning.fallbackFilterRatio ： 0,5 ， Lorsque les statistiques ne sont pas disponibles ou configurées pour ne pas être utilisées, cette configuration sera utilisée comme rapport de filtre de repli pour calculer la taille des données de la table partitionnée après l'élagage de partition dynamique, dans l'ordre pour évaluer s'il vaut la peine d'ajouter une sous-requête supplémentaire comme filtre d'élagage si la réutilisation de diffusion n'est pas applicable.
• spark.sql.optimizer.dynamicPartitionPruning.reuseBroadcast ： 默认 为 true ， Lorsque cet élément est défini sur true, l'élagage de partition dynamique cherchera à réutiliser les résultats de diffusion d'une opération de jointure de hachage de diffusion.

Pour plus de détails, veuillez consulter:
https://www.iteblog.com/archives/8589.html
https://www.iteblog.com/archives/8590.html

Exécution adaptative des requêtes (exécution adaptative des requêtes)

L'exécution adaptative des requêtes (également appelée optimisation adaptative des requêtes ou optimisation adaptative) est l'optimisation des plans d'exécution des requêtes, permettant à Spark Planner d'exécuter des plans d'exécution facultatifs au moment de l'exécution. Ces plans seront optimisés en fonction des statistiques d'exécution.
Dès 2015, la communauté Spark a proposé l'idée de base de l'exécution adaptative. Dans le DAGScheduler de Spark, une interface pour soumettre une seule étape de carte a été ajoutée et une tentative a été faite pour ajuster le nombre de partitions aléatoires au moment de l'exécution. Cependant, l'implémentation actuelle présente certaines limites. Dans certains scénarios, plus de brassages seront introduits, c'est-à-dire plus d'étapes, et elle ne peut pas gérer la situation où trois tables se rejoignent au même stade; et l'actuelle Il est difficile pour le framework d'implémenter de manière flexible d'autres fonctions dans l'exécution adaptative, comme la modification du plan d'exécution ou la gestion des jointures inclinées au moment de l'exécution.

Le cadre AQE fournit actuellement trois fonctions:

• Fusionner dynamiquement les partitions de lecture aléatoire;
• Ajuster dynamiquement la stratégie de jointure;
• Optimisation dynamique des jointures obliques (jointures obliques).

Sur la base du benchmark TPC-DS de 1 To sans statistiques, Spark 3.0 peut augmenter la vitesse de q77 de 8 fois, la vitesse de q5 de 2 fois et la vitesse de 26 autres requêtes de plus de 1,1 fois. AQE peut être activé en définissant la configuration SQL spark.sql.adaptive = true, la valeur par défaut de ce paramètre est false.

Planification compatible avec les accélérateurs

De nos jours, big data et machine learning ont été fortement combinés.Dans le machine learning, le temps d'itération des calculs pouvant être très long, les développeurs choisissent généralement d'utiliser GPU, FPGA ou TPU pour accélérer le calcul. Dans la version Apache Hadoop 3.1, la prise en charge native du GPU et du FPGA a commencé. En tant que moteur informatique à usage général, Spark n'est certainement pas en reste. Les ingénieurs de Databricks, NVIDIA, Google et Alibaba ajoutent une prise en charge native de la planification GPU à Apache Spark. Cette solution comble le vide dans la planification des tâches de Spark des ressources GPU, de manière organique. Il intègre le traitement du Big Data et les applications d'IA, et élargit les scénarios d'application de Spark dans le deep learning, le traitement du signal et diverses applications Big Data.

Actuellement, les gestionnaires de ressources YARN et Kubernetes pris en charge par Apache Spark prennent déjà en charge le GPU. Pour que Spark prenne également en charge les GPU, deux changements majeurs doivent être apportés au niveau technique:

Au niveau du gestionnaire de cluster, les gestionnaires de cluster doivent être mis à niveau pour prendre en charge le GPU. Et fournissez aux utilisateurs des API associées, afin que les utilisateurs puissent contrôler l'utilisation et l'allocation des ressources GPU.
Dans Spark, des modifications doivent être apportées au niveau du planificateur afin que le planificateur puisse identifier la demande de GPU dans la demande de tâche utilisateur, puis terminer l'allocation en fonction de l'offre de GPU sur l'exécuteur.
Comme il s'agit d'une fonctionnalité relativement importante qu'Apache Spark prend en charge le GPU, le projet est divisé en plusieurs étapes. Dans la version Apache Spark 3.0, il prendra en charge la prise en charge des GPU sous les gestionnaires de ressources autonomes, YARN et Kubernetes, et n'aura fondamentalement aucun impact sur les opérations normales existantes. La prise en charge de TPU, la prise en charge du GPU dans Mesos Explorer et la prise en charge du GPU sur la plate-forme Windows ne seront pas l'objectif de cette version. De plus, la planification fine au sein d'une carte GPU ne sera pas prise en charge dans cette version; la version Apache Spark 3.0 traitera une carte GPU et sa mémoire comme une unité inséparable.

Apache Spark DataSource V2

L'API de source de données définit comment lire et écrire les interfaces API associées à partir du système de stockage, telles que InputFormat / OutputFormat de Hadoop, Serde de Hive, etc. Ces API conviennent parfaitement aux utilisateurs pour utiliser la programmation RDD dans Spark. Bien que la programmation avec ces API puisse résoudre nos problèmes, le coût pour les utilisateurs est encore assez élevé et Spark ne peut pas les optimiser. Afin de résoudre ces problèmes, la version Spark 1.3 a commencé à introduire l'API Data Source V1, grâce à cette API, nous pouvons facilement lire les données de diverses sources, et Spark utilise certains moteurs d'optimisation des composants SQL pour optimiser la lecture des sources de données. Tels que le recadrage de colonnes, le filtrage push-down et ainsi de suite.

L'API de source de données V1 résume une série d'interfaces pour nous, et la plupart des scénarios peuvent être réalisés à l'aide de ces interfaces. Cependant, au fur et à mesure que le nombre d'utilisateurs augmentait, certains problèmes sont apparus progressivement:

• Une partie de l'interface dépend de SQLContext et DataFrame
• La capacité d'expansion est limitée, il est difficile de faire baisser les autres opérateurs
• Manque de prise en charge des lectures de stockage en colonne
• Manque de partitionnement et de tri des informations
• L'opération d'écriture ne prend pas en charge les transactions
• Ne prend pas en charge le traitement des flux

Afin de résoudre certains problèmes de Data Source V1, à partir de la version Apache Spark 2.3.0, la communauté a introduit l'API Data Source V2. En plus de conserver les fonctions d'origine, il a également résolu certains des problèmes de l'API Data Source V1, comme ne plus S'appuyant sur l'API de niveau supérieur, la capacité d'extension est améliorée.

Pour plus de détails, veuillez consulter:
https://www.iteblog.com/archives/2578.html
https://www.iteblog.com/archives/2579.html

API et fonctions riches

• UDF pandas amélioré

• Un ensemble complet d'indices de jointure
  Bien que la communauté continue d'améliorer l'intelligence du compilateur, elle ne peut garantir que le compilateur puisse toujours prendre la meilleure décision pour chaque situation. Le choix de l'algorithme de jointure est basé sur des statistiques et des heuristiques. Lorsque le compilateur ne peut pas faire le meilleur choix, les utilisateurs peuvent toujours utiliser des indices de jointure pour influencer l'optimiseur à choisir un meilleur plan. Apache Spark 3.0 étend les indices de jointure existants en ajoutant de nouveaux indices: SHUFFLE_MERGE, SHUFFLE_HASH et SHUFFLE_REPLICATE_NL

• Nouvelles fonctions intégrées L'
  API Scala ajoute 32 nouvelles fonctions intégrées et des fonctions d'ordre supérieur. Parmi ces fonctions intégrées, un ensemble de fonctions intégrées spécifiques pour MAP [transform_key, transform_value, map_entries, map_filter, map_zip_with] a été ajouté pour simplifier le traitement des types de données MAP.

Fonction de surveillance améliorée

• Refonte de l'interface utilisateur de streaming structuré Le streaming
  structuré a été introduit à l'origine dans Spark 2.0. Spark 3.0 a repensé l'interface utilisateur pour surveiller ces tâches de streaming
  
• Commande EXPLAIN améliorée
  Les plans de lecture sont très importants pour comprendre et régler les requêtes. La solution existante semble très déroutante, la représentation sous forme de chaîne de chaque opérateur peut être très large et peut même être tronquée. La version Spark 3.0 utilise un nouveau mode de mise en forme (FORMATÉ) pour l'améliorer et fournit également la fonction de vidage du plan dans un fichier.
• Indicateurs observables
  La surveillance continue des changements dans la qualité des données est une caractéristique très nécessaire pour gérer les pipelines de données. Spark version 3.0 a introduit cette fonctionnalité pour les applications de traitement par lots et par flux. Les indicateurs observables sont nommés comme n'importe quelle fonction d'agrégation (dataframe) qui peut être définie sur la requête. Une fois que l'exécution de la trame de données atteint un point d'achèvement (par exemple, une requête par lots est terminée), un événement nommé est émis qui contient un indicateur des données traitées depuis le dernier point d'achèvement.

Meilleure compatibilité ANSI SQL

PostgreSQL est l'une des bases de données open source les plus avancées. Elle prend en charge la plupart des principales fonctionnalités de SQL: 2011. Parmi les 179 fonctions qui répondent pleinement aux exigences de SQL: 2011, PostgreSQL en satisfait au moins 160. La communauté Spark dispose actuellement d'un ISSUE SPARK-27764 spécial pour résoudre les différences entre Spark SQL et PostgreSQL, y compris les suppléments de fonctionnalités fonctionnelles, les modifications de bogues, etc. Le complément de fonction comprend certaines fonctions prenant en charge ANSI SQL, distinguant les mots-clés réservés SQL et les fonctions intégrées. Ce PROBLÈME correspond à 231 sous-PROBLÈMES. Si cette partie du PROBLÈME est résolue, la différence entre Spark SQL et PostgreSQL ou ANSI SQL: 2011 est encore plus petite.

autre

• Lecture et écriture vectorisées SparkR
• Kafka Streaming includeHeaders prend en charge la configuration de certaines informations d'en-têtes dans le message
• Spark sur K8S: la prise en charge de Spark pour Kubernetes a commencé à partir de la version 2.3, Spark 2.4 a été améliorée et Spark 3.0 ajoutera la prise en charge de Kerberos et de l'allocation dynamique des ressources.
• Service Shuffle à distance: Le Shuffle actuel présente de nombreux problèmes, tels qu'une faible flexibilité, un impact important sur le NodeManager et n'est pas adapté à l'environnement cloud. Afin de résoudre les problèmes ci-dessus, le service de lecture aléatoire à distance sera introduit, voir SPARK-25299 pour plus de détails
• Prise en charge du JDK 11: voir SPARK-24417. La raison du choix direct du JDK 11 est que JDK 8 est sur le point d'atteindre EOL (fin de vie), et JDK9 et JDK10 sont déjà EOL, donc la communauté ignore JDK9 et JDK10 et prend directement en charge JDK11. Cependant, la version préliminaire de Spark 3.0 utilise toujours JDK 1.8 par défaut;
• Supprimer la prise en charge de Scala 2.11, prendre en charge Scala 2.12 par défaut, voir SPARK-26132 pour plus de détails
• Supporte Hadoop 3.2, voir SPARK-23534 pour plus de détails. Hadoop 3.0 est sorti depuis 2 ans (Apache Hadoop 3.0.0-beta1 est officiellement publié, et la prochaine version (GA) peut être utilisée en ligne), il est donc naturel de prendre en charge Hadoop 3.0. Cependant, la version préliminaire de Spark 3.0 utilise toujours Hadoop 2.7.4 par défaut.
• Suppression de la prise en charge de Python 2.x: dès juin 2019, une discussion a eu lieu dans la communauté concernant la suppression de la prise en charge de Python 2 dans Spark 3.0. Actuellement, Spark 3.0.0 prend en charge Python 3.x par défaut. Voir SPARK-27884.
• Spark Graph prend en charge Cypher: Cypher est un langage de requête graphique populaire, et nous pouvons maintenant utiliser Cypher directement dans Spark 3.0.
• Les journaux d'événements Spark prennent en charge Roll, voir "Spark 3.0 prend enfin en charge le roulement des journaux d'événements"