Spark 3-Leitfaden für SQL Server-Big Data-Cluster

Gilt für: SQL Server 2019 (15.x)

In diesem Artikel finden Sie wichtige Informationen und einen Leitfaden für die Workload-Migration von Apache Spark 2.4 zu Spark Version 3.1. Dies ist für Upgrades von Big Data-Cluster für SQL Server CU12 auf CU13 und höher erforderlich.

Einführung von Apache Spark 3 auf Big Data-Cluster für SQL Server

Bis zum kumulativen Update 12 (CU12) beruhten Big Data-Cluster auf der Apache Spark 2.4-Reihe, die im Mai 2021 auslief. Im Einklang mit unserer Zusage an stetige Verbesserungen von Big Data- und Machine Learning-Funktionen durch die Apache Spark-Engine, wird mit CU13 Apache Spark Version 3.1.2 veröffentlicht.

Eine neue Leistungsbaseline

Diese neue Version von Apache Spark bietet Leistungsvorteile gegenüber Workloads der Big Data-Verarbeitung. In unseren Tests wurde die Referenzworkload TCP-DS 10TB eingesetzt. So konnte die Laufzeit von 4,19 Stunden auf 2,96 Stunden reduziert werden. Diese Verbesserung von 29,36 % wurde nur durch das Switching von Engines unter Verwendung des gleichen Hardware- und Konfigurationsprofils auf Big Data-Cluster für SQL Server und ohne zusätzliche App-Optimierungen erzielt. Der Verbesserungsmittelwert einzelner Abfragelaufzeiten liegt bei 36 %.

Upgradeleitfaden

Spark 3 ist eine Hauptversion und enthält Breaking Changes. Es wird empfohlen, die gleiche bewährte Methode für den SQL Server anzuwenden:

1. Lesen Sie den Artikel vollständig durch.
2. Lesen Sie den offiziellen Apache Spark 3-Migrationsleitfaden.
3. Führen Sie eine nebeneinander ausgeführte Bereitstellung eines neuen Big Data-Cluster Version CU13 in Ihrer aktuellen Umgebung durch.
4. (Optional) Nutzen Sie die neue Funktion Verteilte Kopie des azdata HDFS, um eine Teilmenge Ihrer Daten für die Überprüfung abzurufen.
5. Prüfen Sie ihre aktuelle Workload vor dem Upgrade mit Spark 3.
6. Bewerten Sie erzwungene Spark-Optimierungen in Ihren Code- und Tabellendefinitionsstrategien neu. Spark 3 bietet Ihnen neue Erweiterungen für Shuffling, Partitionierung und adaptive Abfrageausführung. Dies ist eine gute Möglichkeit, frühere Entscheidungen neu zu bewerten und zu versuchen, die vorgefertigten Features der neuen Engine zu nutzen.

Was geschieht beim Clusterupgrade?

Beim Clusterupgrade wird die neue Version und die aktualisierte Runtime für Apache Spark für Spark-Pods bereitgestellt. Nach dem Upgrade gibt es keine Spark 2.4-Komponenten mehr.

Beständige Konfigurationsänderungen, die über das Konfigurationsframework vorgenommen wurden, werden beibehalten.

Benutzerbibliotheken und Artefakte, die direkt in HDFS geladen wurden, werden beibehalten. Stellen Sie jedoch sicher, dass diese Bibliotheken und Artefakte mit Spark 3 kompatibel sind.

Aktuelle Änderungen

Spark 3 ist nicht vollständig abwärtskompatibel mit 2.4. Die Breaking Changes werden hauptsächlich durch drei Teile verursacht:

• Scala 2.12, das von Spark 3 verwendet wird, ist nicht mit Scala 2.11 kompatibel, das von Spark 2.4 verwendet wird
• Änderungen und Verwerfungen der Spark 3-API
• SQL Server Big Data-Cluster Runtime für Apache Spark-Bibliotheksupdates

Scala 2.12, das von Spark 3 verwendet wird, ist nicht mit Scala 2.11 kompatibel

Wenn Sie Spark-Aufträge basierend auf Scala 2.11-JAR-Dateien ausführen, müssen Sie sie mit Scala 2.12 neu erstellen. Scala 2.11 und 2.12 sind größtenteils quellkompatibel, aber nicht binärkompatibel. Weitere Informationen finden Sie unter Scala 2.12.0.

Folgende Änderungen sind erforderlich:

1. Ändern Sie die Scala-Version für alle Scala-Abhängigkeiten.
2. Ändern Sie die Spark-Version für alle Spark-Abhängigkeiten.
3. Ändern Sie alle Spark-Abhängigkeiten, die Umfang bereitgestellt haben, mit Ausnahme externer Abhängigkeiten wie spark-sql-kafka-0-10.

Ein Beispiel für eine pom.xml-Datei wie unten gezeigt:

  <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>

Änderungen und Verwerfungen der Spark 3-API

Lesen Sie den offiziellen Apache Spark 3-Migrationsleitfaden,der alle API-Änderungen im Detail behandelt.

Einige wichtige Punkte sind:

Runtime von SQL Server Big Data-Cluster für Apache Spark-Bibliotheksupdates

Alle Python-, R- und Scala-Standardbibliotheken wurden, wie von der Spezifikation für die Runtime von SQL Server Big Data-Cluster für Apache Spark abgedeckt, im CU13-Release aktualisiert. Zudem wurden viele Bibliotheken hinzugefügt, um eine optimierte Benutzerumgebung zu bieten.

1. Stellen Sie sicher, dass Ihre Workload mit dem neueren Bibliothekssatz funktioniert.
2. Überprüfen Sie, ob eine benutzerdefiniert geladene Bibliothek jetzt Teil der Standard-Paketbaseline ist. Passen Sie Ihre Auftragsspezifikationen an, um die benutzerdefinierte Bibliothek zu entfernen, damit der Auftrag die ausgelieferte Bibliothek verwenden kann.

Häufig gestellte Fragen

Lösen ungewöhnlicher java.lang.NoSuchMethodError- oder java.lang.ClassNotFoundException-Fehler

Dieser Fehler wird wahrscheinlich durch einen Spark- oder Scala-Versionskonflikt verursacht. Gehen Sie die folgenden Schritte durch, und erstellen Sie Ihr Projekt neu.

1. Überprüfen Sie, dass alle Scala-Versionen aktualisiert wurden.
2. Überprüfen Sie, dass alle Spark-Abhängigkeiten mit den passenden Scala- und Spark-Versionen aktualisiert wurden.
3. Überprüfen Sie, dass alle Spark-Abhängigkeiten mit Ausnahme von spark-sql-kafka-0-10 den Umfang bereitgestellt haben.

SparkUpgradeException aufgrund einer Änderung des Kalendermodus

Es gibt Änderungen beim Spark 3.0-Kalendermodell. Möglicherweise wird Ihnen beim Eintragen einer Kalenderspalte in Spark SQL eine Ausnahme wie die folgende angezeigt:

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.

Lösung: Legen Sie die Konfiguration spark.sql.legacy.parquet.int96RebaseModeInWrite, wie oben beschrieben, als „LEGACY“ oder „CORRECTED“ fest. Hier finden Sie eine mögliche Lösung im PySpark-Code:

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

Nächste Schritte

Weitere Informationen finden Sie hier: Einführung in Big Data-Cluster für SQL Server.