| Code in a transformation
(i.e. inside the function passed to RDD.map() or RDD.filter()) will run
on workers, not the driver. They will run in parallel. In Spark, the
driver actually doesn't do much -- it just builds up a description of
the computation to be performed and then sends it off to the cluster
master when you perform an action that actually triggers computation (so
long as you use RDD transformations to do most of the work). In your
example, the bold items are running on workers and are properly
distributed since they all occur in the transformation functions. As for Scala collections in RDDs, my impression is that the problems usually arise with respect to the size of the data. A Seq may take much more memory than a plain old Array. In some cases it is worth it to make sure you store the right type. That said, keep in mind that this is really only an issue if you're *caching* or *shuffling* that data. For example, if you load data and then do a map() and filter() and a map(), those will all be processed together because none of them require a shuffle. Any *intermediate* types won't be stores, just processed and garbage collected. Unless you generate a lot of garbage, these probably won't be a major issue. Personally, I tend to use Scala collections as usual, but then pay attention to bottlenecks at shuffle and cache points in the pipeline. In some cases it makes sense to make sure I use Arrays instead of a Seq. But these are the same type of optimizations you should probably be making at the time you decide whether to store data serialized or unserialized when caching, i.e. you probably shouldn't worry about it until you actually have some profiling data in hand to inform your decisions. -Ewen
|
- new user question on using scala collections inside ... Peter
- Re: new user question on using scala collection... Ewen Cheslack-Postava

