Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Architektur
Das folgende Diagramm zeigt die Architektur der in diesem Handbuch beschriebenen Lösung. Ein AWS Glue Job liest Daten aus einem Amazon Simple Storage Service (Amazon S3) -Bucket, einem cloudbasierten Objektspeicher-Service, der Sie beim Speichern, Schützen und Abrufen von Daten unterstützt. Sie können den AWS Glue Spark SQL Job über die AWS-Managementkonsole, AWS Command Line Interface (AWS CLI) oder die AWS Glue API initiieren. Der AWS Glue Spark SQL Job verarbeitet die Rohdaten in einem Amazon S3 S3-Bucket und speichert die verarbeiteten Daten dann in einem anderen Bucket.
In diesem Handbuch wird beispielsweise ein einfacher AWS GlueSpark SQLJob beschrieben, der in Python und Spark SQL (PySpark) geschrieben ist. Dieser AWS Glue Job dient dazu, bewährte Verfahren für das Spark SQL Tuning zu demonstrieren. Obwohl sich dieser Leitfaden auf Amazon EMR-Jobs konzentriert AWS Glue, gelten die Best Practices in diesem Leitfaden auch für Amazon Spark SQL EMR-Jobs.
Das folgende Diagramm zeigt den Lebenszyklus einer Spark SQL Abfrage. Der Spark SQL Catalyst Optimizer generiert einen Abfrageplan. Ein Abfrageplan besteht aus einer Reihe von Schritten, wie Anweisungen, die für den Zugriff auf die Daten in einem relationalen SQL-Datenbanksystem verwendet werden. Um einen leistungsoptimierten Spark
SQL Abfrageplan zu entwickeln, besteht der erste Schritt darin, den EXPLAIN Plan anzusehen, ihn zu interpretieren und dann den Plan zu optimieren. Sie können die Spark SQL Benutzeroberfläche (UI) oder den Spark SQL History Server verwenden, um den Plan zu visualisieren.
SparkCatalyst Optimizer konvertiert den ursprünglichen Abfrageplan wie folgt in einen optimierten Abfrageplan:
-
Analyse und deklarative APIs — Die Analysephase ist der erste Schritt. Der ungelöste logische Plan, bei dem Objekte, auf die in der SQL-Abfrage verwiesen wird, nicht bekannt sind oder keiner Eingabetabelle zugeordnet sind, wird mit ungebundenen Attributen und Datentypen generiert. Der Spark SQL Catalyst Optimizer wendet dann eine Reihe von Regeln an, um einen logischen Plan zu erstellen. Der SQL-Parser kann einen SQL Abstract Syntax Tree (AST) generieren und diesen als Eingabe für den logischen Plan bereitstellen. Bei der Eingabe kann es sich auch um einen Datenrahmen oder ein Datensatzobjekt handeln, das mithilfe einer API erstellt wurde. Die folgende Tabelle zeigt, wann Sie SQL, Datenrahmen oder Datensätze verwenden sollten.
SQL Datenframes Datensätze Syntaxfehler Laufzeit Zeit der Kompilierung Zeit zum Kompilieren Fehler bei der Analyse Laufzeit Laufzeit Zeit zum Kompilieren Weitere Informationen zu den Eingabetypen finden Sie in den folgenden Abschnitten:
-
Eine Datensatz-API stellt eine typisierte Version bereit. Dies reduziert die Leistung, da stark von benutzerdefinierten Lambda-Funktionen abhängig ist. RDD oder Datensätze sind statisch typisiert. Wenn Sie beispielsweise ein RDD definieren, müssen Sie die Schemadefinition explizit angeben.
-
Eine Datenrahmen-API bietet untypisierte relationale Operationen. Datenrahmen werden dynamisch typisiert. Ähnlich wie bei RDD bleibt das Schema unverändert, wenn Sie einen Datenrahmen definieren. Die Daten sind immer noch strukturiert. Diese Informationen sind jedoch nur zur Laufzeit verfügbar. Auf diese Weise kann der Compiler im Handumdrehen SQL-like Anweisungen schreiben und neue Spalten definieren. Beispielsweise kann er Spalten an einen vorhandenen Datenrahmen anhängen, ohne dass für jede Operation eine neue Klasse definiert werden muss.
-
Eine Spark SQL Abfrage wird während der Laufzeit auf Syntax- und Analysefehler überprüft, was zu schnelleren Laufzeiten führt.
-
-
Katalog — Spark SQLwird verwendetApache Hive Metastore (HMS), um die Metadaten persistenter relationaler Entitäten wie Datenbanken, Tabellen, Spalten und Partitionen zu verwalten.
-
Optimierung — Der Optimierer schreibt den Abfrageplan mithilfe von Heuristiken und Kosten neu. Er führt die folgenden Schritte aus, um einen optimierten logischen Plan zu erstellen:
-
Pflaumen, Säulen
-
Drückt Prädikate nach unten
-
Ordnet Verknüpfungen neu
-
-
Physische Pläne und der Planer — Spark SQL Catalyst Optimizer konvertiert den logischen Plan in eine Reihe von physischen Plänen. Das heißt, es konvertiert das Was in das Wie.
-
Ausgewählte physische Pläne — Spark SQL Catalyst Optimizer wählt den kostengünstigsten physischen Plan aus.
-
Optimierter Abfrageplan — Spark SQL führt den leistungs- und kostenoptimierten Abfrageplan aus. Spark SQL Memory Management verfolgt die Speichernutzung und verteilt den Speicher zwischen Aufgaben und Operatoren. Die Spark SQL Tungsten-Engine kann die Speicher- und CPU-Effizienz für Spark SQL Anwendungen erheblich verbessern. Sie implementiert auch die Verarbeitung binärer Datenmodelle und arbeitet direkt mit Binärdaten. Dadurch wird die Notwendigkeit einer Deserialisierung umgangen und der mit der Datenkonvertierung und Deserialisierung verbundene Aufwand erheblich reduziert.
