3 ms·
"All in-memory".. yeah and I have 1TB data file to process. How is that going to help?
by mrbonner 12y ago
"All in-memory".. yeah and I have 1TB data file to process. How is that going to help?
- tupshin 12y ago1) Buy a box with 1TB of RAM. Very doable these days, albeit a bit pricey still 2) Scale out. Spark can easily handle hundreds of nodes in a single cluster. Aggregate RAM across all of them can be used. 3) Cache intermediate data sets and/or hot data sets, as opposed to the entire data set.
- sitkack 12y ago256GB machines are the sweet spot right now.
- ironchef 12y agoFor #2 and #3, see here: http://spark.apache.org/docs/latest/programming-guide.html#rdd-persistence http://spark.apache.org/docs/latest/programming-guide.html#r... We typically do #2 at our company and it's been fine so far. The bigger issue isn't a single 1 TB data set. It's multiple large data sets as one then must handle the data shuffles during joins, etc. The ability to keep the RDD in memory through the operations still tends to beat normal long winded hadoop operations anyways...
- rs_atl 12y agoLong winded in more ways than one. I would still use Spark even if it were slower than Hadoop, just to get a sane API.
- rs_atl 12y agoIt can also spill to disk if needed, which is what Hadoop always does.
- mike_ivanov 12y agoUh, not actually. In theory - yes, but not in reality. Try to join two large RDDs and spill the result, you'll see what I mean.
- ConnorBoyd 12y ago10 nodes with 100GB each. 100 nodes with 10GB each. 1000 nodes with 1GB each. Spark is built for scaling out.
- cbsmith 12y agoIf you are using map/reduce for analytics, 1TB is tiny and easily fits in RAM. Get back to me when you are talking petabytes.