5 ms·
Ray user here. Their adoption is exponential. Much faster than Spark when it was "the same age." It's not limited to AI workloads, that's just its flagship use
by vonnik 7y ago
Ray user here. Their adoption is exponential. Much faster than Spark when it was "the same age." It's not limited to AI workloads, that's just its flagship use case with RLlib.
- choppaface 7y agoHas Ray grown beyond reinforcement learning? Ray appears to lack a datastore or locality mechanism for at-rest distributed data, which is really important for ETL and SQL workloads. So far Ray looks like it has some nice features that are missing from the Spark RDD API, but for ETL / SQL it looks like you’d only choose Ray there for your own entertainment. It would be compelling if Ray were to provide Horovod support versus the authors re-applying some of same research in their own thing. Ray programming API + code distribution + Horovod performance primitives is what the community probably wants.
- namibj 7y agoCan you compare these to https://github.com/TimelyDataflow/timely-dataflow https://github.com/TimelyDataflow/timely-dataflow ? It seems Spark is rolling on inertia more than being a modular system for low-latency cluster computing.
- agibsonccc 7y agoIt's still pretty early days for ray yet. That being said, spark never really got the hang of doing machine learning properly. It "works" but not for newer workloads which ray is trying to support. It's good someone is building a company around it. I could see them building services on top of it and build a SAAS like databricks did with spark. I'll be curious to see how ray matures.
- choppaface 7y agoI agree that ML on Spark was only a limited hit—- iterative jobs would actually be feasible versus Hadoop—- I still have yet to find a better ETL and SQL tool, and that’s a big part of most ML projects. I’m worried about Ray as a SAAS Co because so far it looks to me like they’re riding reinforcement learning hype. They’d need to really penetrate the users of Horovod and Tensorflow Distributed to get beyond a beach head. And what if TPUs and Cerebras become more common? Because then the maker for multi-machine workloads becomes smaller (definitely not zero though).
- agibsonccc 7y agoYour concerns are right on point. I agree that spark is a great sql/etl tool. My thinking was on the "math execution" part. Ray is able to doa bit more there. I do feel like there is a bit of hype riding going on here as well. One interesting thing that could happen is the hardware gets better, and then these distributed schedulers might not be able to keep up with all the different options on the market. There is also the tension of the hardware vendors wanting to give away things that only run on their chips vs the software makers who want things to run on every chip. It seems like there will be a lot of competition among the various infra players in the next few years now that nvidia is starting to have real competition now (even if it's not big yet)
- choppaface 7y agoJust to qualify that "math execution" part, the beauty of Ray is that you get threadpool-like features to speed up arbitrary python code. So not just parallelism, but state/variable sharing for relatively small data. So this is great for some optimizers and definitely RL (where your "math" is some really complicated simulation / loss logic), but Ray wouldn't make much sense for BLAS stuff. Am I missing something here? Ray shows expertise in multi-machine that's lacking in stuff like Jax, Tensorflow, and PyTorch. Horovod nailed down a lot of the performance issues for SGD in particular, but is missing the sort of rapid deployment / distribution stuff in Ray. If only they could all work together ...
- richardliaw 7y agoInteresting. What do you mean when you say: "versus the authors re-applying some of same research in their own thing." And does "code distribution" just mean to release as open source?
- choppaface 7y agocode distribution I mean like cloudpickle. Which Ray has, but I wonder about an equivalent to Spark files (torrented and cached). A Kubernetes runner is also important ... I wish the Ray peeps would consider just trying to merge some with the Spark RDD API. Reynold (at Databricks) is kinda hard to deal with, but so far to me it looks like the aim of having Ray team build things from the ground up has simply re-validated a lot of the systems work (but not all) that’s already in Spark.