Optimering av datalagring för Apache Spark

Den här artikeln beskriver strategier för att optimera datalagring för effektiv Körning av Apache Spark-jobb i Azure HDInsight.

Översikt

Spark stöder många format, till exempel csv, json, xml, parquet, orc och avro. Spark kan utökas för att stödja många fler format med externa datakällor – mer information finns i Apache Spark-paket.

Det bästa formatet för prestanda är parquet med snabb komprimering, vilket är standard i Spark 2.x. Parquet lagrar data i kolumnformat och är mycket optimerad i Spark.

Välj dataabstraktion

Tidigare Spark-versioner använder RDD för att abstrahera data, Spark 1.3 och 1.6 introducerade DataFrames respektive DataSets. Tänk på följande relativa fördelar:

  • DataFrames
    • Bästa valet i de flesta situationer.
    • Tillhandahåller frågeoptimering via Catalyst.
    • Kodgenerering i hela stadiet.
    • Direkt minnesåtkomst.
    • Låg skräpinsamling (GC) overhead.
    • Inte lika utvecklarvänligt som DataSets, eftersom det inte finns några kompileringstidskontroller eller domänobjektprogrammering.
  • Datamängder
    • Bra i komplexa ETL-pipelines där prestandapåverkan är acceptabel.
    • Inte bra i sammansättningar där prestandapåverkan kan vara betydande.
    • Tillhandahåller frågeoptimering via Catalyst.
    • Utvecklarvänlig genom att tillhandahålla domänobjektprogrammering och kompileringstidskontroller.
    • Lägger till serialisering/deserialiseringskostnader.
    • Höga GC-omkostnader.
    • Bryter kodgenereringen i hela fasen.
  • RDD:er
    • Du behöver inte använda RDD:er, såvida du inte behöver skapa en ny anpassad RDD.
    • Ingen frågeoptimering via Catalyst.
    • Ingen kodgenerering i hela fasen.
    • Höga GC-omkostnader.
    • Måste använda äldre API:er för Spark 1.x.

Välj standardlagring

När du skapar ett nytt Spark-kluster kan du välja Azure Blob Storage eller Azure Data Lake Storage som standardlagring för klustret. Båda alternativen ger dig fördelen med långsiktig lagring för tillfälliga kluster. Så dina data tas inte bort automatiskt när du tar bort klustret. Du kan återskapa ett tillfälligt kluster och fortfarande komma åt dina data.

Butikstyp Filsystem Hastighet Tillfälligt Användningsfall
Azure Blob Storage wasb://url/ Standard Ja Tillfälligt kluster
Azure Blob Storage (säker) wasbs://url/ Standard Ja Tillfälligt kluster
Azure Data Lake Storage Gen 2 abfs://url/ Snabbare Ja Tillfälligt kluster
Azure Data Lake Storage Gen 1 adl://url/ Snabbare Ja Tillfälligt kluster
Lokal HDFS hdfs://url/ Snabbaste Inga Interaktivt 24/7-kluster

En fullständig beskrivning av lagringsalternativ finns i Jämför lagringsalternativ för användning med Azure HDInsight-kluster.

Använd cachen

Spark har egna interna cachelagringsmekanismer som kan användas via olika metoder som .persist(), .cache()och CACHE TABLE. Den här interna cachelagringen är effektiv med små datauppsättningar och i ETL-pipelines där du behöver cachelagra mellanliggande resultat. Den inbyggda Spark-cachelagringen fungerar dock för närvarande inte bra med partitionering, eftersom en cachelagrad tabell inte behåller partitioneringsdata. En mer allmän och tillförlitlig cachelagringsteknik är cachelagring av lagringslager.

  • Intern Spark-cachelagring (rekommenderas inte)

    • Bra för små datamängder.
    • Fungerar inte med partitionering, vilket kan ändras i framtida Spark-versioner.
  • Cachelagring på lagringsnivå (rekommenderas)

    • Kan implementeras på HDInsight med hjälp av IO Cache-funktionen .
    • Använder minnesintern cachelagring och SSD-cachelagring.
  • Lokal HDFS (rekommenderas)

    • hdfs://mycluster Sökvägen.
    • Använder SSD-cachelagring.
    • Cachelagrade data går förlorade när du tar bort klustret, vilket kräver att cacheminnet återskapas.

Optimera dataserialiseringen

Spark-jobb distribueras, så lämplig dataserialisering är viktig för bästa prestanda. Det finns två serialiseringsalternativ för Spark:

  • Java-serialisering är standard.
  • Kryo serialisering är ett nyare format och kan resultera i snabbare och mer kompakt serialisering än Java. Kryo kräver att du registrerar klasserna i ditt program och att det ännu inte stöder alla Serializable-typer.

Använd bucket

Bucketing liknar datapartitionering. Men varje bucket kan innehålla en uppsättning kolumnvärden i stället för bara en. Den här metoden fungerar bra för partitionering på stora (i miljoner eller fler) värden, till exempel produktidentifierare. En bucket bestäms genom att du hashar bucketnyckeln för raden. Bucketade tabeller erbjuder unika optimeringar eftersom de lagrar metadata om hur de bucketades och sorterades.

Några avancerade bucketing-funktioner är:

  • Frågeoptimering baserat på bucketing meta-information.
  • Optimerade sammansättningar.
  • Optimerade kopplingar.

Du kan använda partitionering och bucketing samtidigt.

Nästa steg