Optimalizace úložiště dat pro Apache Spark

  • Článek

Tento článek popisuje strategie optimalizace úložiště dat pro efektivní spouštění úloh Apache Sparku ve službě Azure HDInsight.

Přehled

Spark podporuje mnoho formátů, jako jsou csv, json, xml, parquet, orc a avro. Spark je možné rozšířit tak, aby podporoval mnoho dalších formátů s externími zdroji dat – další informace najdete v tématu Balíčky Apache Spark.

Nejlepší formát pro zajištění výkonu je parquet s kompresí snappy, což je výchozí hodnota ve Sparku 2.x. Parquet ukládá data ve sloupcových formátech a je vysoce optimalizovaný ve Sparku.

Volba abstrakce dat

Starší verze Sparku používají sady RDD k abstrakci dat, Spark 1.3 a 1.6 zavedl datové rámce a datové sady v uvedeném pořadí. Zvažte následující relativní výhody:

  • Datové rámce
    • Nejlepší volba ve většině situací.
    • Poskytuje optimalizaci dotazů prostřednictvím Catalyst.
    • Generování kódu v celé fázi.
    • Přímý přístup do paměti.
    • Nízká režijní náklady na uvolňování paměti
    • Nejsou tak vhodné pro vývojáře jako datové sady, protože neexistují žádné kontroly kompilace ani programování objektů domény.
  • Soubory
    • Vhodné ve složitých kanálech ETL, kde je dopad na výkon přijatelný.
    • Není dobré v agregacích, kde může být dopad na výkon značný.
    • Poskytuje optimalizaci dotazů prostřednictvím Catalyst.
    • Vhodné pro vývojáře tím, že poskytuje programování objektů domény a kontroly v době kompilace.
    • Přidá režii serializace/deserializace.
    • Vysoká režie uvolňování paměti.
    • Přeruší generování kódu celé fáze.
  • Sady RDD
    • Sady RDD nemusíte používat, pokud nepotřebujete vytvořit novou vlastní sadu RDD.
    • Žádná optimalizace dotazů prostřednictvím Catalyst.
    • Žádné generování kódu celé fáze.
    • Vysoká režie uvolňování paměti.
    • Musí používat starší verze rozhraní API Sparku 1.x.

Vyberte výchozí úložiště.

Při vytváření nového clusteru Spark můžete jako výchozí úložiště clusteru vybrat Azure Blob Storage nebo Azure Data Lake Storage. Obě možnosti poskytují výhodu dlouhodobého úložiště pro přechodné clustery. Proto se vaše data při odstranění clusteru automaticky neodstraní. Můžete znovu vytvořit přechodný cluster a stále přistupovat ke svým datům.

Store Type Systém souborů Rychlost Přechodná Případy použití
Azure Blob Storage wasb://url/ Standard Yes Přechodný cluster
Azure Blob Storage (zabezpečené) wasbs://url/ Standard Yes Přechodný cluster
Azure Data Lake Storage Gen2 abfs://url/ Rychlejší Yes Přechodný cluster
Azure Data Lake Storage Gen 1 adl://url/ Rychlejší Yes Přechodný cluster
Místní HDFS hdfs://url/ Nejrychlejší No Interaktivní nepřetržitý cluster

Úplný popis možností úložiště najdete v tématu Porovnání možností úložiště pro použití s clustery Azure HDInsight.

Použití mezipaměti

Spark poskytuje vlastní nativní mechanismy ukládání do mezipaměti, které je možné použít různými metodami, jako .persist()jsou , .cache()a CACHE TABLE. Toto nativní ukládání do mezipaměti je efektivní u malých datových sad a v kanálech ETL, kde potřebujete ukládat do mezipaměti mezilehlé výsledky. Nativní ukládání do mezipaměti Sparku ale v současné době nefunguje dobře s dělením, protože tabulka uložená v mezipaměti neuchovává data dělení. Obecnější a spolehlivější metodou ukládání do mezipaměti je ukládání do mezipaměti vrstvy úložiště.

  • Nativní ukládání sparku do mezipaměti (nedoporučuje se)

    • Vhodné pro malé datové sady.
    • Nefunguje s dělením, které se může v budoucích verzích Sparku změnit.

  • Ukládání do mezipaměti na úrovni úložiště (doporučeno)

    • Ve službě HDInsight je možné ji implementovat pomocí funkce vstupně-výstupní mezipaměti .
    • Používá ukládání do mezipaměti v paměti a ssd.

  • Místní HDFS (doporučeno)

    • hdfs://mycluster Cestu.
    • Používá mezipaměť SSD.
    • Při odstranění clusteru dojde ke ztrátě dat uložených v mezipaměti, což vyžaduje opětovné sestavení mezipaměti.

Optimalizace serializace dat

Úlohy Sparku se distribuují, takže pro nejlepší výkon je důležitá odpovídající serializace dat. Pro Spark existují dvě možnosti serializace:

  • Výchozí je serializace Java.
  • Kryo serializace je novější formát a může vést k rychlejší a kompaktnější serializaci než Java. Kryo vyžaduje, abyste zaregistrovali třídy v programu, a to ještě nepodporuje všechny serializovatelné typy.

Použití rozdělování do kbelíků

Dělení na oddíly je podobné dělení dat. Každý kbelík ale může obsahovat sadu hodnot sloupců, a ne jenom jednu. Tato metoda funguje dobře při dělení na velké (miliony nebo více) počtech hodnot, jako jsou identifikátory produktů. Kbelík se určí hashováním klíče kbelíku řádku. Tabulky v intervalech nabízejí jedinečné optimalizace, protože ukládají metadata o tom, jak byly roztříděny a seřazeny.

Mezi pokročilé funkce dělení do kontejnerů patří:

  • Optimalizace dotazů na základě rozdělení metainformací.
  • Optimalizované agregace.
  • Optimalizovaná spojení.

Můžete použít dělení na oddíly a dělení na kontejnery současně.

Další kroky