Hacker News Reader

Comment by insulanian | Hacker News Reader

Usually when I hear about Apache Sparc, there is Scala being mentioned too. Does Scala have the best support for it and what's the situation on .NET side? (F#?)

View on HN

First class language support in Apache Spark:

  * Scala
  * Python
  * Java
  * R

All these languages are equal, but Scala tends to be more equal than others in some areas of the API. I also believe R is mostly restricted to the DataFrame API.

Third-party language support:

  * Clojure [0]

To develop on Spark in a new, non-JVM language, you'd need a bridge to Java. That's how PySpark works [1], and I believe R follows a similar pattern.

[0] https://github.com/yieldbot/flambo

[1] https://cwiki.apache.org/confluence/display/SPARK/PySpark+In...

I am thinking that R is the reason why this is happening. Now that Microsoft has supported and invested in R (Smart thing on their part) R will get more Spark features. Having better R connections to Spark's API would be amazing.

First class support for running dplyr pipelines on Spark would be killer, imho.

Interesting how the whole R thing happened, about three years ago I wouldn't have any idea what R is about and now see it everywhere, even at customer sites.

Haskell: https://github.com/tweag/sparkle

There's also third-party support for .NET via https://github.com/Microsoft/Mobius

Third-party from Spark's perspective, but first-party from C#'s perspective.

Third-party Node.js bindings:

https://github.com/henridf/apache-spark-node https://github.com/EclairJS/eclairjs-node

More like 3 tiers of support:

Scala -- native API

Java -- java wrappers for Scala API, slightly clunky but same implementation

Python+R -- janky process involving forking a process and feeding strings back and forth between JVM and python/R via pipes

You're right about Python and R having to pass data back and forth to the JVM for certain operations, but also keep in mind that native code still runs in the native interpreter. That means you have access to the full ecosystem of the native language.

For example, if I want to convert an RDD of JSON strings into Python dictionaries:

    import json
    rdd_dict = rdd.map(lambda x: json.loads(x))

Same goes for any external Python libraries I install on the cluster and want to use in my Spark job. You can even run your Python code on PyPy [4]!

For me, working in Python generally feels like a first class experience on Spark. There are areas -- like GraphX [0], certain niche features [1] -- where Scala is definitely easier to work with, but with time that is becoming less [2] and less [3] true thanks to the DataFrame API.

[0] https://spark.apache.org/graphx/

[1] http://stackoverflow.com/q/23995040/877069

[2] https://github.com/graphframes/graphframes

[3] http://stackoverflow.com/a/37150604/877069

[4] https://github.com/apache/spark/pull/2144

Has anyone tried running Jython on top of the native API? Would that make any sense?

Spark's written in Scala, so Scala will presumably always be the best-supported language. On the inside Spark's also pretty intimately tied to some Java implementation details (e.g., it uses Java serialization to push code around), so any non-JVM language is always going to have to deal with a bit of friction.

That said, from my experience the Python integration is still first-class. I think it might lag the Scala APIs a bit, but that isn't a huge deal unless you really need to be on the bleeding edge at all times. The only really big downside in my book is that there's a small performance hit you take by choosing to use the Python API instead of the Scala one, and that might compound into something of practical significance if you're using it for really big data tasks.

I assume you'd have similar problems using it with R or a .NET language.

There are some people doing ML and data analysis in F#, mostly financial institutions, but Spark is written in Scala so it is all about the JVM eco-system.

Spark's syntax is basically identical to Scala's, so you can use it as a library with standard Scala functions. In contrast PySpark etc. will still let you get all the same features, but you have to write code that doesn't look like Python, by either using Scala-like code with the RDD API or SQL-like code with the SQL API.

I would be surprised if it didn't end up being C#, but I have no real foundation for that sentiment.

Reply on news.ycombinator.com