Guide de mise à niveau des Clusters Big Data SQL Server Spark 3

Article
03/21/2023

S’applique à : SQL Server 2019 (15.x)

Important

Le module complémentaire Clusters Big Data Microsoft SQL Server 2019 sera mis hors service. La prise en charge de la plateforme Clusters Big Data Microsoft SQL Server 2019 se terminera le 28 février 2025. Tous les utilisateurs existants de SQL Server 2019 avec Software Assurance seront entièrement pris en charge sur la plateforme, et le logiciel continuera à être maintenu par les mises à jour cumulatives SQL Server jusqu’à ce moment-là. Pour plus d’informations, consultez le billet de blog d’annonce et les Options Big Data sur la plateforme Microsoft SQL Server.

Cet article contient des informations importantes et des conseils pour migrer les charges de travail Apache Spark 2.4 vers Spark version 3.1. Cette migration est nécessaire pour effectuer la mise à niveau des Clusters Big Data SQL Server CU12 vers CU13 et ultérieur.

Présentation d’Apache Spark 3 sur les Clusters Big Data SQL Server

Jusqu’à la mise à jour cumulative 12 (CU12), les clusters Big Data reposent sur la ligne Apache Spark 2.4, qui a atteint sa fin de vie en mai 2021. Conformément à notre engagement d’apporter des améliorations continues aux fonctionnalités de Big Data et Machine Learning offertes par le moteur Apache Spark, CU13 intègre la version actuelle d’Apache Spark : 3.1.2.

Une nouvelle base de référence des performances

Cette nouvelle version d’Apache Spark offre des avantages en matière de performances par rapport aux charges de travail de traitement du Big Data. En utilisant la charge de travail TCP-DS 10 To de référence dans nos tests, nous avons pu réduire la durée d’exécution de 4,19 heures à 2,96 heures, une amélioration de 29,36 % obtenue seulement en basculant les moteurs et en utilisant le même matériel et le même profil de configuration sur des Clusters Big Data SQL Server, aucune autre optimisation d’application n’a été nécessaire. La moyenne d’amélioration de la durée d’exécution de chaque requête est de 36 %.

Conseils de mise à niveau

Spark 3 est une version principale qui contient des changements cassants. En suivant les bonnes pratiques établies dans l’univers SQL Server, nous vous recommandons de :

Lire cet article en entier.
Consulter le Guide de migration d’Apache Spark 3 officiel.
Effectuer un déploiement côte à côte d’un nouveau cluster Big Data version CU13 avec votre environnement actuel.
(Facultatif) Tirer parti de la nouvelle fonctionnalité azdata de copie distribuée HDFS afin d’avoir un sous-ensemble de vos données à utiliser pour la validation.
Valider votre charge de travail actuelle avec Spark 3 avant la mise à niveau.
Réévaluer les optimisations Spark appliquées dans vos stratégies de définition de code et de table. Spark 3 apporte de nouvelles améliorations en matière de lecture aléatoire, de partitionnement et d’exécution de requêtes adaptatives. C’est une bonne occasion de réévaluer les décisions précédentes et de tirer parti des dernières fonctionnalités prêtes à l’emploi du moteur.

Que se passe-t-il pendant la mise à niveau du cluster ?

Le processus de mise à niveau de cluster déploie des pods Spark avec la nouvelle version et le runtime pour Apache Spark actualisé. Après la mise à niveau, il n’y a plus aucun composant Spark 2.4.

Les changements de configuration persistants effectués en utilisant le framework de configuration sont conservés.

Les bibliothèques utilisateur et les artefacts chargés directement dans HDFS sont conservés. Toutefois, vérifiez que ces bibliothèques et artefacts sont compatibles avec Spark 3.

Avertissement

Les personnalisations effectuées directement sur les pods sont perdues, validez-les et réappliquez-les si elles sont toujours applicables à Spark 3.

Changements cassants

Spark 3 n’offre pas une compatibilité descendante complète avec 2.4, les changements cassants sont principalement liés à trois raisons :

Scala 2.12 utilisé par Spark 3 est incompatible avec Scala 2.11 utilisé par Spark 2.4
Changements et dépréciations de l’API Spark 3
Mises à jour de la bibliothèque du runtime des Clusters Big Data SQL Server pour Apache Spark

Scala 2.12 utilisé par Spark 3 est incompatible avec Scala 2.11

Si vous exécutez des travaux Spark basés sur des fichiers jar Scala 2.11, vous devez les reconstruire avec Scala 2.12. Scala 2.11 et 2.12 ont une compatibilité source quasi totale, mais pas de compatibilité binaire. Pour plus d’informations, consultez Scala 2.12.0.

Les changements ci-dessous sont nécessaires :

Changez la version Scala pour toutes les dépendances Scala.
Changez la version Spark pour toutes les dépendances Spark.
Changez toutes les dépendances Spark qui ont l’étendue fournie, à l’exception des dépendances externes comme spark-sql-kafka-0-10.

Voici un exemple de pom.xml :

  <properties>
    <spark.version>3.1.2</spark.version>
    <scala.version.major>2.12</scala.version.major>
    <scala.version.minor>10</scala.version.minor>
    <scala.version>${scala.version.major}.${scala.version.minor}</scala.version>
  </properties>
 
  <dependencies>
 
    <dependency>
      <groupId>org.scala-lang</groupId>
      <artifactId>scala-library</artifactId>
      <version>${scala.version}</version>
      <scope>provided</scope>
    </dependency>
 
    <dependency>
      <groupId>org.apache.spark</groupId>
      <artifactId>spark-core_${scala.version.major}</artifactId>
      <version>${spark.version}</version>
     <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.spark</groupId>
      <artifactId>spark-sql_${scala.version.major}</artifactId>
      <version>${spark.version}</version>
      <scope>provided</scope>
    </dependency>
 
    <dependency>
      <groupId>org.apache.spark</groupId>
      <artifactId>spark-sql-kafka-0-10_${scala.version.major}</artifactId>
      <version>${spark.version}</version>
    </dependency>
    
  </dependencies>

Changements et dépréciations de l’API Spark 3

Consultez le Guide de migration Apache Spark 3 officiel, qui couvre tous les changements d’API en détail.

Voici quelques-uns des changements effectués :

Modification avec rupture	Action
Les paramètres de `spark-submit`, `yarn-client` et `yarn-clustermodes`, sont supprimés dans Spark 3	Utilisez `spark-submit --master yarn --deploy-mode client` ou `--deploy-mode cluster` à la place. Pour plus d’informations, consultez https://spark.apache.org/docs/latest/running-on-yarn.html
La classe `HiveContext` est supprimée	Utilisation de `SparkSession.builder.enableHiveSupport()` à la place
L’ordre de l’argument est inversé dans la méthode TRIM	Utiliser `TRIM(str, trimStr)` à la place de `TRIM(trimStr, str)`
En raison de la mise à niveau vers Scala 2.12, `DataStreamWriter.foreachBatch` n’est pas une source compatible avec le programme Scala	Mettez à jour votre code source Scala pour faire la distinction entre une fonction Scala et Java lambda.

Mises à jour de la bibliothèque du runtime des Clusters Big Data SQL Server pour Apache Spark

Comme décrit dans la spécification du Runtime des Clusters Big Data SQL Server pour Apache Spark, toutes les bibliothèques par défaut Python, R et Scala ont été mises à jour vers la version CU13. Par ailleurs, de nombreuses bibliothèques ont été ajoutées pour offrir une meilleure expérience prête à l’emploi.

Vérifiez que votre charge de travail fonctionne avec le dernier ensemble de bibliothèques.
Vérifiez si une bibliothèque chargée personnalisée fait maintenant partie de la base de référence du package par défaut et ajustez les spécifications de vos travaux pour supprimer la bibliothèque personnalisée afin d’autoriser le travail à utiliser la bibliothèque fournie.

Forum Aux Questions

Comment résoudre l’erreur étrange Java.lang.NoSuchMethodError ou Java.lang.ClassNotFoundException

Cette erreur est probablement due à un conflit de version Spark ou Scala. Revérifiez ce qui suit et regénérez votre projet.

Vérifiez que toutes les versions Scala sont mises à jour.
Vérifiez que toutes les dépendances Spark sont mises à jour avec la version Scala et la version Spark appropriées.
Vérifiez que toutes les dépendances Spark ont l’étendue fournie, à l’exception de spark-sql-kafka-0-10.

SparkUpgradeException liée au changement de mode de calendrier

Le modèle de calendrier change dans Spark 3.0. Vous pouvez voir une exception de ce type quand vous écrivez une colonne de calendrier dans Spark SQL :

Caused by: org.apache.spark.SparkUpgradeException: 
You may get a different result due to the upgrading of Spark 3.0:
writing dates before 1582-10-15 or timestamps before 1900-01-01T00:00:00Z into Parquet INT96 files can be dangerous,
as the files may be read by Spark 2.x or legacy versions of Hive later, 
which uses a legacy hybrid calendar that is different from Spark 3.0+'s Proleptic Gregorian calendar. 
See more details in SPARK-31404.
You can set spark.sql.legacy.parquet.int96RebaseModeInWrite to 'LEGACY' to 
rebase the datetime values w.r.t. the calendar difference during writing, to get maximum interoperability. 
Or set spark.sql.legacy.parquet.int96RebaseModeInWrite to 'CORRECTED' to 
write the datetime values as it is, if you are 100% sure that the written files 
will only be read by Spark 3.0+ or other systems that use Proleptic Gregorian calendar.

Solution : définissez la configuration sparkpark.sql.legacy.parquet.int96RebaseModeInWrite sur LEGACY ou CORRECTED, comme expliqué ci-dessus. Voici une solution possible dans le code PySpark :

spark.conf.set("spark.sql.legacy.parquet.int96RebaseModeInWrite","CORRECTED")

Étapes suivantes

Pour plus d’informations, consultez Présentation des Clusters Big Data SQL Server.

Partage via