Ich habe immer noch Schwierigkeiten, die volle Leistungsfähigkeit der kürzlich eingeführten Spark Datasets zu verstehen.
Gibt es Best Practices für die Verwendung von RDDs und die Verwendung von Datasets?
Databricks erklärt in ihrer Ankündigung , dass Datasets erstaunliche Reduzierungen in beiden verwenden Laufzeit und Speicher können erreicht werden. Dennoch wird behauptet, dass Datasets so konzipiert sind, dass sie neben der bestehenden RDD-API funktionieren.
Ist dies nur ein Hinweis auf die Abwärtskompatibilität oder gibt es Szenarien, in denen man RDDs gegenüber Datasets bevorzugen würde?
In diesem Moment (Spark 1.6.0) DataSet API ist nur eine Vorschau und nur eine kleine Teilmenge von Features ist implementiert, so dass es nicht möglich ist, etwas über Best Practices zu sagen.
Konzeptionell ist Spark DataSet nur ein DataFrame mit zusätzlicher Typensicherheit (oder wenn Sie ein Blick in die Zukunft DataFrame ist DataSet[Row] ). Es bedeutet, dass Sie alle Vorteile von Catalyst und Tungsten . Es umfasst logische und physische Planoptimierung, vektorisierte Operationen und Low-Level-Speicherverwaltung.
Was Sie verlieren, ist Flexibilität und Transparenz.
Zunächst müssen Ihre Daten codiert werden, bevor sie mit DataSet verwendet werden können. Spark stellt Encoder für primitive Typen und Produkte / Fallklassen bereit, und für die API, die für die Definition einer benutzerdefinierten Serialisierung erforderlich ist, steht derzeit keine API zur Verfügung. Wahrscheinlich wird es der UDT-API relativ ähnlich sein (siehe zum Beispiel Wie definiert man ein Schema für einen benutzerdefinierten Typ in Spark SQL? , Serialisieren / Deserialisieren der vorhandenen Klasse für Spark-SQL-Datenframe ) mit all seinen Problemen. Es ist relativ ausführlich, erfordert zusätzlichen Aufwand und kann bei komplexen Objekten nicht offensichtlich sein. Außerdem berührt es einige Aspekte der API auf niedrigerer Ebene, die nicht sehr gut dokumentiert sind.
Was die Transparenz anbelangt, handelt es sich um das gleiche Problem wie bei einem Planer in einem typischen RDBMS. Es ist großartig, bis es nicht ist. Es ist ein erstaunliches Werkzeug, es kann Ihre Daten analysieren, intelligente Transformationen durchführen, aber als jedes Werkzeug kann es einen falschen Weg einschlagen und lässt den Ausführungsplan durchblicken und versucht herauszufinden, wie die Dinge funktionieren.
Basierend auf einer Vorschau würde ich sagen, dass es irgendwo zwischen DataFrame API und RDD API platziert werden kann. Es ist flexibler als DataFrames , bietet jedoch ähnliche Optimierungen und eignet sich gut für allgemeine Datenverarbeitungsaufgaben. Es bietet nicht die gleiche Flexibilität (zumindest ohne einen tieferen Einblick in die Catalyst-Interna) wie eine RDD-API.
Ein anderer Unterschied, der momentan hypothetisch ist, ist eine Art, wie er mit Gastsprachen interagiert (R, Python). Ähnlich wie DataFrame , DataSet gehört zu JVM. Es bedeutet, dass jede mögliche Interaktion zu einer von zwei Kategorien gehören kann: native JVM-Operation (wie DataFrame -Ausdrücke) und Gast-Seiten-Code (wie Python UDF). Leider erfordert der zweite Teil einen kostspieligen Hin- und Rückflug zwischen JVM und einer Gastumgebung.
Siehe auch:
Tags und Links apache-spark rdd apache-spark-dataset