Spark Code Organisation und Best Practices

Question

Also, ich habe viele Jahre in einer objektorientierten Welt mit Code-Wiederverwendung, Design Patterns und Best Practices immer berücksichtigt, ich finde mich etwas mit Code-Organisation und Code-Wiederverwendung in der Welt von Spark kämpfen.

Wenn ich versuche, Code auf wiederverwendbare Weise zu schreiben, kommt es fast immer zu Leistungseinbußen und am Ende schreibe ich alles neu, was für meinen speziellen Anwendungsfall optimal ist. Diese Konstante "schreibe, was für diesen speziellen Anwendungsfall optimal ist" wirkt sich auch auf die Code-Organisation aus, da das Teilen von Code in verschiedene Objekte oder Module schwierig ist, wenn "alles wirklich zusammengehört" und ich somit sehr wenige "Gott" -Objekte länge Ketten komplexer Transformationen. Tatsächlich denke ich häufig, dass ich, wenn ich mir den Großteil des Spark-Codes, den ich gerade schreibe, während ich in der objektorientierten Welt arbeitete, angeschaut hätte und ihn als "Spaghetti-Code" abgetan hätte.

Ich habe im Internet gesurft und versucht, eine Art Entsprechung zu den Best Practices der objektorientierten Welt zu finden, aber ohne viel Glück. Ich kann einige "Best Practices" für die funktionale Programmierung finden, aber Spark fügt nur eine zusätzliche Ebene hinzu, weil die Leistung hier eine wichtige Rolle spielt.

Also meine Frage an Sie ist, habe jemand von euch Spark Gurus gefunden einige Best Practices zum Schreiben von Spark-Code, den Sie empfehlen können?

EDIT

Wie in einem Kommentar geschrieben, ich hatte nicht erwartet, tatsächlich jemand eine Antwort auf schreiben, wie dieses Problem zu lösen, sondern ich hatte gehofft, dass jemand in dieser Gemeinschaft über einige gekommen war Martin Fowler, der irgendwo in Artikeln oder Blogposts geschrieben hatte, wie man Probleme mit der Code-Organisation in der Welt von Spark angehen kann.

@DanielDarabos schlug vor, dass ich ein Beispiel für eine Situation geben könnte, in der Code-Organisation und Leistung widersprüchlich sind. Während ich feststelle, dass ich in meiner täglichen Arbeit häufig Probleme damit habe, finde ich es ein bisschen schwierig, es auf ein gutes minimales Beispiel zu reduzieren;) aber ich werde es versuchen.

In der objektorientierten Welt bin ich ein großer Fan des Single-Responsibility-Prinzips, also würde ich sicherstellen, dass meine Methoden nur für eine Sache verantwortlich sind. Es macht sie wiederverwendbar und leicht testbar. Wenn ich zum Beispiel die Summe einiger Zahlen in einer Liste berechnen müsste (die einige Kriterien erfüllt) und ich den Durchschnitt derselben Zahl berechnen müsste, würde ich definitiv zwei Methoden erstellen - eine, die die Summe berechnet und eine berechnete den Durchschnitt. Wie folgt aus:

def main(implicit args: Array[String]): Unit = { 
    val list = List(("DK", 1.2), ("DK", 1.4), ("SE", 1.5)) 

    println("Summed weights for DK = " + summedWeights(list, "DK") 
    println("Averaged weights for DK = " + averagedWeights(list, "DK") 
} 

def summedWeights(list: List, country: String): Double = { 
    list.filter(_._1 == country).map(_._2).sum 
} 

def averagedWeights(list: List, country: String): Double = { 
    val filteredByCountry = list.filter(_._1 == country) 
    filteredByCountry.map(_._2).sum/ filteredByCountry.length 
} 

Ich kann natürlich auch weiterhin SRP in Funken zu ehren:

def main(implicit args: Array[String]): Unit = { 
    val df = List(("DK", 1.2), ("DK", 1.4), ("SE", 1.5)).toDF("country", "weight") 

    println("Summed weights for DK = " + summedWeights(df, "DK") 
    println("Averaged weights for DK = " + averagedWeights(df, "DK") 
} 


def avgWeights(df: DataFrame, country: String, sqlContext: SQLContext): Double = { 
    import org.apache.spark.sql.functions._ 
    import sqlContext.implicits._ 

    val countrySpecific = df.filter('country === country) 
    val summedWeight = countrySpecific.agg(avg('weight)) 

    summedWeight.first().getDouble(0) 
} 

def summedWeights(df: DataFrame, country: String, sqlContext: SQLContext): Double = { 
    import org.apache.spark.sql.functions._ 
    import sqlContext.implicits._ 

    val countrySpecific = df.filter('country === country) 
    val summedWeight = countrySpecific.agg(sum('weight)) 

    summedWeight.first().getDouble(0) 
} 

Aber weil meine df Milliarden Zeilen enthalten würde ich lieber nicht die filter zweimal ausführen müssen. Tatsächlich ist die Leistung direkt an die EMR-Kosten gekoppelt, also will ich das wirklich nicht. Um das zu beheben, ich entscheiden, was zu SRP zu verletzen und einfach gesagt, die beiden Funktionen in ein und stellen Sie sicher, ich rufe beharren auf dem Land gefilterten DataFrame, wie folgt aus:

def summedAndAveragedWeights(df: DataFrame, country: String, sqlContext: SQLContext): (Double, Double) = { 
    import org.apache.spark.sql.functions._ 
    import sqlContext.implicits._ 

    val countrySpecific = df.filter('country === country).persist(StorageLevel.MEMORY_AND_DISK_SER) 
    val summedWeights = countrySpecific.agg(sum('weight)).first().getDouble(0) 
    val averagedWeights = summedWeights/countrySpecific.count() 

    (summedWeights, averagedWeights) 
} 

nun dieses Beispiel wenn natürlich eine riesige Vereinfachung dessen, was im wirklichen Leben angetroffen wird.Hier könnte ich es einfach durch Filtern und Persistent dfvor Übergabe an die Summe und avg Funktionen (die auch mehr SRP wäre) lösen, aber im wirklichen Leben gibt es eine Reihe von Zwischenberechnungen gehen, die wieder und benötigt werden nochmal. Mit anderen Worten, die filter Funktion hier ist nur ein Versuch, ein Beispiel für etwas zu machen, das davon profitieren wird, dauerhaft zu sein. In der Tat denke ich, Anrufe an persist ist ein Schlüsselwort hier. Wenn ich persist anrufe, wird das meinen Job enorm beschleunigen, aber die Kosten sind, dass ich den gesamten Code, der von der persistenten DataFrame abhängt, fest koppeln muss - auch wenn sie logisch getrennt sind.

Answer 1

Ich denke, Sie können Apache Spark, databricks Kanal auf Youtube abonnieren, mehr zuhören und mehr wissen, vor allem für die Erfahrungen und Lektionen von anderen.

• Apache Spark
• databricks
• Spark Technology Center

hier einige Videos empfohlen:

• SparkUI Visualization

• slide SparkUI Visualization

• Spark in Production: Lessons from 100+ Production Users

• slide Spark in Production: Lessons from 100+ Production Users

• Spark Tuning for Enterprise System Administrators

• Spark Tuning for Enterprise System Administrators

• Building, Debugging, and Tuning Spark Machine Learning Pipelines - Joseph Bradley (Databricks)

• slide Building, Debugging, and Tuning Spark Machine Learning Pipelines

• Top 5 Mistakes When Writing Spark Applications

• slide Top 5 mistakes when writing Spark applications

• Tuning and Debugging Apache Spark

• slide Tuning and Debugging Apache Spark

• A Deeper Understanding of Spark Internals - Aaron Davidson (Databricks)

• slide A Deeper Understanding of Spark Internals - Aaron Davidson (Databricks)

und ich habe geschrieben und Aktualisierung immer noch auf meinem GitHub und Blog:

• github post
• blog post

Hoffnung dies kann Ihnen helfen, ~