Optymalizacja magazynu danych dla platformy Apache Spark

  • Artykuł

W tym artykule omówiono strategie optymalizacji magazynu danych w celu wydajnego wykonywania zadań platformy Apache Spark w usłudze Azure HDInsight.

Omówienie

Platforma Spark obsługuje wiele formatów, takich jak csv, json, xml, parquet, orc i avro. Platforma Spark może zostać rozszerzona, aby obsługiwać wiele formatów z zewnętrznymi źródłami danych — aby uzyskać więcej informacji, zobacz Pakiety platformy Apache Spark.

Najlepszym formatem wydajności jest parquet z kompresją snappy, która jest domyślna w spark 2.x. Parquet przechowuje dane w formacie kolumnowym i jest wysoce zoptymalizowany na platformie Spark.

Wybieranie abstrakcji danych

Wcześniejsze wersje platformy Spark używają rdD do abstrakcji danych, platformy Spark 1.3 i 1.6, odpowiednio wprowadzonych ramek danych i zestawów danych. Rozważ następujące względne zalety:

  • Ramki danych
    • Najlepszy wybór w większości sytuacji.
    • Zapewnia optymalizację zapytań za pośrednictwem katalizatora.
    • Generowanie kodu na całym etapie.
    • Bezpośredni dostęp do pamięci.
    • Niskie obciążenie związane z odzyskiwaniem pamięci (GC).
    • Nie tak przyjazne dla deweloperów, jak zestawy danych, ponieważ nie ma kontroli czasu kompilacji ani programowania obiektów domeny.
  • Zestawach danych
    • Dobre w złożonych potokach ETL, w których wpływ na wydajność jest akceptowalny.
    • Nie jest dobra w agregacjach, w których wpływ na wydajność może być znaczny.
    • Zapewnia optymalizację zapytań za pośrednictwem katalizatora.
    • Przyjazny dla deweloperów, zapewniając programowanie obiektów domeny i sprawdzanie czasu kompilacji.
    • Dodaje obciążenie serializacji/deserializacji.
    • Wysokie obciążenie GC.
    • Przerywa generowanie kodu na całym etapie.
  • RDD
    • Nie musisz używać RDD, chyba że musisz utworzyć nowy niestandardowy rdD.
    • Brak optymalizacji zapytań za pośrednictwem katalizatora.
    • Brak generowania kodu na całym etapie.
    • Wysokie obciążenie GC.
    • Musi używać starszych interfejsów API platformy Spark 1.x.

Wybierz magazyn domyślny

Podczas tworzenia nowego klastra Spark możesz wybrać Azure Blob Storage lub Azure Data Lake Storage jako domyślny magazyn klastra. Obie opcje zapewniają korzyści z długoterminowego magazynowania dla klastrów przejściowych. W związku z tym dane nie są automatycznie usuwane po usunięciu klastra. Możesz ponownie utworzyć przejściowy klaster i nadal uzyskiwać dostęp do danych.

Typ sklepu System plików Szybkość Przejściowy Przypadki użycia
Azure Blob Storage wasb://url/ Standardowa Tak Klaster przejściowy
Azure Blob Storage (bezpieczne) wasbs://url/ Standardowa Tak Klaster przejściowy
Azure Data Lake Storage Gen 2 abfs://url/ Szybciej Tak Klaster przejściowy
Azure Data Lake Storage Gen 1 adl://url/ Szybciej Tak Klaster przejściowy
Lokalny system plików HDFS hdfs://url/ Najszybszy Nie Interaktywny klaster 24/7

Aby uzyskać pełny opis opcji magazynowania, zobacz Porównanie opcji magazynu do użycia z klastrami usługi Azure HDInsight.

Korzystanie z pamięci podręcznej

Platforma Spark udostępnia własne natywne mechanizmy buforowania, które mogą być używane za pomocą różnych metod, takich jak .persist(), .cache()i CACHE TABLE. Ta natywna pamięć podręczna jest skuteczna w przypadku małych zestawów danych i w potokach ETL, w których trzeba buforować wyniki pośrednie. Jednak buforowanie natywne platformy Spark obecnie nie działa dobrze z partycjonowaniem, ponieważ buforowana tabela nie przechowuje danych partycjonowania. Bardziej ogólną i niezawodną techniką buforowania jest buforowanie warstwy magazynu.

  • Buforowanie natywnej platformy Spark (niezalecane)

    • Dobre dla małych zestawów danych.
    • Nie działa z partycjonowaniem, co może ulec zmianie w przyszłych wersjach platformy Spark.

  • Buforowanie na poziomie magazynu (zalecane)

    • Można zaimplementować w usłudze HDInsight przy użyciu funkcji pamięci podręcznej we/wy .
    • Używa buforowania w pamięci i ssd.

  • Lokalny system plików HDFS (zalecane)

    • hdfs://mycluster Ścieżka.
    • Używa buforowania SSD.
    • Dane buforowane zostaną utracone po usunięciu klastra, co wymaga ponownego skompilowania pamięci podręcznej.

Optymalizowanie serializacji danych

Zadania platformy Spark są dystrybuowane, więc odpowiednia serializacja danych jest ważna dla najlepszej wydajności. Istnieją dwie opcje serializacji platformy Spark:

  • Serializacja języka Java jest domyślna.
  • Kryo serializacja jest nowszym formatem i może spowodować szybszą i bardziej kompaktową serializacji niż Java. Kryo program wymaga zarejestrowania klas w programie i nie obsługuje jeszcze wszystkich typów serializowalnych.

Korzystanie z zasobników

Zasobniki są podobne do partycjonowania danych. Jednak każdy zasobnik może przechowywać zestaw wartości kolumn, a nie tylko jeden. Ta metoda dobrze sprawdza się w przypadku partycjonowania na dużych (w milionach lub więcej) liczb wartości, takich jak identyfikatory produktów. Zasobnik jest określany przez utworzenie skrótu klucza zasobnika wiersza. Tabele zasobnikowe oferują unikatowe optymalizacje, ponieważ przechowują metadane dotyczące sposobu ich zasobnika i sortowania.

Oto niektóre zaawansowane funkcje zasobnika:

  • Optymalizacja zapytań oparta na zasobnikach metadanych.
  • Zoptymalizowane agregacje.
  • Zoptymalizowane sprzężenia.

Można używać partycjonowania i zasobnika w tym samym czasie.

Następne kroki