Optymalizacja magazynu danych dla platformy Apache Spark

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

Przegląd

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

Najlepszym formatem dla 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

Starsze wersje platformy Spark używają RDD do abstrakcji danych, natomiast w wersjach 1.3 i 1.6 wprowadzono odpowiednio DataFrames i DataSets. 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 pełnoetapowego.
  • Bezpośredni dostęp do pamięci.
  • Niski koszt związany 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.
• Zestawy danych
  • Dobre w złożonych potokach ETL, w których wpływ na wydajność jest akceptowalny.
  • Nie jest to dobre 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 zużycie zasobów przez GC.
  • Przerywa generowanie kodu pełnoetapowego.
• RDD
  • Nie trzeba używać RDD, chyba że trzeba utworzyć nowy niestandardowy RDD.
  • Brak optymalizacji zapytań za pośrednictwem katalizatora.
  • Brak generowania kodu całego etapu.
  • Wysokie obciążenie GC.
  • Musi używać starszych interfejsów API platformy Spark 1.x.

Wybieranie magazynu domyślnego

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

Aby uzyskać pełny opis opcji przechowywania, zobacz Porównanie opcji przechowywania 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 należy buforować wyniki pośrednie. Jednak buforowanie natywne platformy Spark nie działa obecnie w przypadku partycjonowania, ponieważ buforowana tabela nie przechowuje danych partycjonowania. Bardziej ogólną i niezawodną techniką buforowania jest buforowanie warstwy przechowywania.

• 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 wdrożyć na platformie HDInsight dzięki funkcji pamięci podręcznej we/wy.
  • Używa konsolidacji w pamięci i SSD.

• Lokalny system plików HDFS (zalecane)

  • hdfs://mycluster ścieżka.
  • Używa buforowania SSD.
  • Buforowane dane 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 serializacji 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 prowadzić do szybszej i bardziej kompaktowej serializacji niż Java. Kryo wymaga zarejestrowania klas w programie i nie obsługuje jeszcze wszystkich typów serializowalnych.

Korzystanie z zasobników

Grupowanie jest podobne do partycjonowania danych. Jednak każde wiadro może przechowywać zestaw wartości kolumn, a nie tylko jedną. 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. Tablice zsegmentowane oferują unikatowe optymalizacje, ponieważ przechowują metadane dotyczące sposobu ich podziału na segmenty i sortowania.

Niektóre zaawansowane funkcje grupowania to:

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

Można jednocześnie używać partycjonowania i segmentacji.

Następne kroki

• Optymalizowanie przetwarzania danych dla platformy Apache Spark
• Optymalizowanie użycia pamięci dla platformy Apache Spark
• Optymalizowanie konfiguracji klastra dla platformy Apache Spark