Zwischenspeicherung von Spark-Ergebnisfragmenten - Amazon EMR

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.

Zwischenspeicherung von Spark-Ergebnisfragmenten

Amazon EMR 6.6.0 und höher enthalten die optionale Spark-Funktion zum Zwischenspeichern von Ergebnisfragmenten, die Ergebnisfragmente automatisch zwischenspeichert. Diese Ergebnisfragmente sind Teile von Ergebnissen aus Teilbäumen von Abfragen, die in einem Amazon S3 S3-Bucket Ihrer Wahl gespeichert sind. Die gespeicherten Abfrageergebnisfragmente werden bei nachfolgenden Abfrageausführungen wiederverwendet, was zu schnelleren Abfragen führt.

Das Zwischenspeichern von Ergebnisfragmenten funktioniert, indem Ihre Spark-SQL-Abfragen analysiert und geeignete Ergebnisfragmente an Ihrem angegebenen S3-Speicherort zwischengespeichert werden. Bei nachfolgenden Abfrageläufen werden die verwendbaren Abfrageergebnisfragmente automatisch erkannt und aus S3 abgerufen. Das Zwischenspeichern von Ergebnisfragmenten unterscheidet sich vom Result Set Caching, bei dem nachfolgende Abfragen exakt mit der ursprünglichen Abfrage übereinstimmen müssen, um Ergebnisse aus dem Cache zurückzugeben. Wenn es für Abfragen verwendet wird, die wiederholt auf eine statische Teilmenge Ihrer Daten abzielen, beschleunigt das Zwischenspeichern von Ergebnisfragmenten die Leistung erheblich.

Stellen Sie sich die folgende Abfrage vor, die Bestellungen bis zum Jahr 2022 zählt:

select l_returnflag, l_linestatus, count(*) as count_order from lineitem where l_shipdate <= current_date and year(l_shipdate) == '2022' group by l_returnflag, l_linestatus

Im Laufe der Zeit muss diese Abfrage täglich ausgeführt werden, um den Gesamtumsatz für das Jahr zu melden. Ohne das Zwischenspeichern von Ergebnisfragmenten müssen die Ergebnisse für alle Tage des Jahres täglich neu berechnet werden. Die Abfrage wird mit der Zeit langsamer und am Ende des Jahres am langsamsten sein, wenn alle Ergebnisse für 365 Tage neu berechnet werden müssen.

Wenn Sie das Zwischenspeichern von Ergebnisfragmenten aktivieren, verwenden Sie die Ergebnisse aller vorangegangenen Tage des Jahres aus dem Cache. Jeden Tag darf das Feature nur einen Tag mit Ergebnissen neu berechnen. Nachdem das Feature das Ergebnisfragment berechnet hat, speichert das Feature das Fragment im Cache. Dadurch sind Cache-fähige Abfragezeiten schnell und bleiben für jede nachfolgende Abfrage konstant.

Spark-Ergebnisfragment-Caching aktivieren

Führen Sie die folgenden Schritte durch, um das Zwischenspeichern von Spark Result Fragment Caching zu aktivieren:

  1. Erstellen Sie einen Cache-Bucket in Amazon S3 und autorisieren Sie den Lese-/Schreibzugriff für EMRFS. Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf EMRFS-Daten in Amazon S3.

  2. Stellen Sie die EMR Spark-Konfiguration ein, um die Funktion zu aktivieren.

    spark.subResultCache.enabled = true spark.subResultCache.fs.root.path = s3://DOC-EXAMPLE-BUCKET/cache_dir/
  3. Aktivieren Sie das S3-Lifecycle-Management für den Bucket, um Cache-Dateien automatisch zu bereinigen.

  4. Konfigurieren Sie optional die maxBufferSize Eigenschaften reductionRationThreshold und, um die Funktion weiter zu optimieren.

    spark.sql.subResultCache.reductionRatioThreshold spark.sql.subResultCache.maxBufferSize

Überlegungen zur Verwendung von Result Fragment-Caching

Die Kostenersparnis, wenn Sie bereits in Amazon S3 zwischengespeicherte Ergebnisse verwenden, anstatt sie erneut zu berechnen, wächst mit der Häufigkeit, mit der dieselben zwischengespeicherten Ergebnisse verwendet werden können. Abfragen mit großen Tabellenscans, gefolgt von Filtern oder Hash-Aggregationen, die die Ergebnisgröße um einen Faktor von mindestens 8 reduzieren (d. h. ein Verhältnis von mindestens 8:1 in der Eingabegröße: Ergebnisse), werden am meisten von dieser Funktion profitieren. Je größer das Reduktionsverhältnis zwischen Input und Ergebnissen ist, desto größer ist der Kostenvorteil. Abfragen mit geringeren Reduktionsraten, die jedoch teure Rechenschritte zwischen Tabellenscan und Filter oder Aggregationen beinhalten, profitieren ebenfalls, sofern die Kosten für die Erstellung der Ergebnisse höher sind als die Kosten für deren Abruf aus Amazon S3. Standardmäßig wird das Zwischenspeichern von Ergebnisfragmenten nur wirksam, wenn erkannt wird, dass ein Reduktionsverhältnis mindestens 8:1 beträgt.

Wenn Ihre Abfragen wiederholt zwischengespeicherte Ergebnisse wiederverwenden, sind die Vorteile dieser Funktion am größten. Rollende und inkrementelle Fensterabfragen sind gute Beispiele. Beispielsweise müsste eine 30-tägige Rolling-Window-Abfrage, die bereits 29 Tage lang ausgeführt wurde, nur 1/30 der Zieldaten aus ihrer ursprünglichen Eingabequelle abrufen und zwischengespeicherte Ergebnisfragmente für die 29 vorangegangenen Tage verwenden. Eine inkrementelle Fensterabfrage würde noch mehr profitieren, da der Anfang des Fensters unverändert bleibt: Bei jedem Aufruf der Abfrage muss ein kleinerer Prozentsatz der Verarbeitung aus der Eingabequelle gelesen werden.

Bei der Verwendung von Result Fragment Caching sind die folgenden zusätzlichen Überlegungen zu beachten:

  • Abfragen, die nicht auf dieselben Daten mit denselben Abfragefragmenten abzielen, haben eine niedrige Cache-Trefferrate und profitieren daher nicht von dieser Funktion.

  • Abfragen mit niedrigen Reduktionsraten, die keine teuren Berechnungsschritte enthalten, führen zu zwischengespeicherten Ergebnissen, deren Lesen ungefähr so teuer ist wie ihre anfängliche Verarbeitung.

  • Die erste Abfrage zeigt aufgrund der Kosten für das Schreiben in den Cache immer eine geringfügige Regression.

  • Die Funktion zum Zwischenspeichern von Ergebnisfragmenten funktioniert ausschließlich mit Parquet-Dateien. Andere Dateiformate werden nicht unterstützt.

  • Die Feature-Puffer für das Zwischenspeichern von Ergebnisfragmenten versuchen nur, Scans mit Dateiaufteilungsgrößen von 128 MB oder mehr zwischenzuspeichern. In der Standardkonfiguration von Spark wird das Zwischenspeichern von Ergebnisfragmenten deaktiviert, wenn die Scangröße (Gesamtgröße aller gescannten Dateien) geteilt durch die Anzahl der Executor-Cores weniger als 128 MB beträgt. Wenn eine der unten aufgeführten Spark-Konfigurationen festgelegt ist, beträgt die Größe der Dateiaufteilung:

    min(maxPartitionBytes, max(openCostInBytes, scan size / minPartitionNum))
    • spark.sql. leafNodeDefaultParallelität (der Standardwert ist spark.default.parallelism)

    • spark.sql.files. minPartitionNum (Der Standardwert ist spark.sql. leafNodeDefaultParallelität)

    • spark.sql.files. openCostInBytes

    • spark.sql.files. maxPartitionBytes

  • Die Funktion zum Zwischenspeichern von Ergebnisfragmenten wird an der Granularität der RDD-Partition zwischengespeichert. Das zuvor beschriebene Reduktionsverhältnis, das standardmäßig 8:1 ist, wird pro RDD-Partition bewertet. Bei Workloads mit Reduktionsverhältnissen pro RDD, die sowohl größer als auch kleiner als 8:1 sind, können geringere Leistungsvorteile erzielt werden als bei Workloads mit Reduktionsverhältnissen pro RDD, die durchweg unter 8:1 liegen.

  • Die Funktion zum Zwischenspeichern von Ergebnisfragmenten verwendet standardmäßig einen 16-MB-Schreibpuffer für jede zwischengespeicherte RDD-Partition. Wenn mehr als 16 MB pro RDD-Partition zwischengespeichert werden, können die Kosten für die Feststellung, dass ein Schreibvorgang nicht möglich ist, zu einer Leistungsrückgang führen.

  • Standardmäßig versucht Result Fragment Caching zwar nicht, RDD-Partitionsergebnisse mit einem Reduktionsverhältnis von weniger als 8:1 zwischenzuspeichern, und begrenzt seinen Schreibpuffer auf 16 MB. Beide Werte sind jedoch über die folgenden Konfigurationen einstellbar:

    spark.sql.subResultCache.reductionRatioThreshold (default: 8.0) spark.sql.subResultCache.maxBufferSize (default: 16MB, max: 64MB)
  • Mehrere Cluster, die dieselbe EMR-Version verwenden, können denselben Cache-Speicherort gemeinsam nutzen. Um die Richtigkeit der Ergebnisse zu gewährleisten, verwendet Result Fragment Caching keine Cache-Ergebnisse, die von verschiedenen Versionen von EMR geschrieben wurden.

  • Das Zwischenspeichern von Ergebnisfragmenten wird automatisch für Spark-Streaming-Anwendungsfälle deaktiviert oder wenn RecordServer Apache Ranger oder verwendetAWS Lake Formation wird.

  • Beim Lesen/Schreiben des Ergebnisfragment-Cache werden EMRFS- und Amazon S3 S3-Buckets verwendet. Die CSE/SSE S3/SSE KMS-Verschlüsselung wird unterstützt.