Leistungsabfall für eine große Anzahl von Spalten. Pyspark

9

Ich habe das Problem mit der Verarbeitung von Spark-Wide-Datenrahmen (etwa 9000 Spalten und manchmal mehr) getroffen.
Aufgabe:

  1. Erstellen Sie einen breiten DF über groupBy und pivot.
  2. Transformieren Sie Spalten in Vektor und verarbeiten Sie sie in KMeans von pyspark.ml.

Also habe ich einen extensiven Frame gemacht und versucht Vector mit VectorAssembler zu erstellen, zwischengespeichert und darauf KMeans trainiert. Es dauerte etwa 11 Minuten für die Montage und 2 Minuten für KMeans für 7 verschiedene Anzahl von Clustern auf meinem PC im Standalone-Modus für Frame ~ 500x9000. Eine andere Seite dieser Verarbeitung in Pandas (Pivot df und iterieren 7 Cluster) dauert weniger als eine Minute.
Offensichtlich Ich verstehe Overhead und Leistung für Standalone-Modus und Caching und so weiter, aber es ist wirklich entmutigen mich.
Könnte jemand erklären, wie ich diesen Overhead vermeiden kann?
Wie arbeiten Menschen mit einem breiten DF statt mit Vectorasembler und abnehmender Leistung?
Formalere Frage (für Sofortregeln) klingt wie - Wie kann ich diesen Code beschleunigen?

%Vor%

Konfig:

%Vor%     
Anton Alekseev 20.02.2018, 08:39
quelle

2 Antworten

0

Tatsächlich wurde die Lösung in Karte für rdd gefunden.

  1. Zuerst werden wir eine Wertekarte erstellen.
  2. Extrahiere auch alle verschiedenen Namen.
  3. Vorletzter Schritt, wir suchen jeden Wert der Zeilenmap in dict von Namen und Rückgabewert oder 0, wenn nichts gefunden wurde.
  4. Vector Assembler für Ergebnisse.

Vorteile:

  1. Sie müssen keinen großen Datenrahmen mit einer großen Anzahl von Spalten erstellen und somit Overhead vermeiden. (Geschwindigkeit wurde von 11 Minuten auf 1 erhöht.)
  2. Sie arbeiten immer noch am Cluster und führen Ihren Code im Paradigma von spark aus.

Beispielcode: scala-Implementierung .

    
Anton Alekseev 28.03.2018, 08:46
quelle
2

Die VectorAssembler-Transformationsfunktion verarbeitet alle Spalten und speichert Metadaten zu jeder Spalte zusätzlich zu den Originaldaten. Das kostet Zeit und beansprucht auch RAM.

Um genau zu sagen, wie viel Dinge zugenommen haben, können Sie Ihren Datenrahmen vor und nach der Transformation als Parkettdateien ablegen und vergleichen. Meiner Erfahrung nach kann ein Feature-Vektor, der von Hand oder mit anderen Feature-Extraktionsmethoden im Vergleich zu einem von VectorAssembler gebauten Feature-Vektor erstellt wurde, eine Größenzunahme von 10x verursachen und dies für eine logistische Regression mit nur 10 Parametern. Die Dinge werden viel schlimmer mit einem Datensatz mit so vielen Spalten wie Sie haben.

Einige Vorschläge:

  • Sehen Sie, ob Sie Ihren Feature-Vektor auf andere Weise erstellen können. Ich bin mir nicht sicher, wie leistungsfähig das in Python wäre, aber ich habe in Scala viel von diesem Ansatz. Ich habe etwas wie einen 5x-6x Leistungsunterschied zwischen logistischen Regressionen (10 params) für manuell erstellte Vektoren oder Vektoren, die mit anderen Extraktionsmethoden (TF-IDF) gebaut wurden, als mit VectorAssembled-Vektoren.
    • festgestellt
  • Sehen Sie, ob Sie Ihre Daten umformen können, um die Anzahl der Spalten zu reduzieren, die von VectorAssembler verarbeitet werden müssen.
  • Sehen Sie, ob die Erhöhung des für Spark verfügbaren RAMs hilft.
fny 28.02.2018 22:00
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Der MongoDB-Index wird nicht verwendet