- 主题:dask的成功是不是说明spark设计的远超必要的复杂了？
相比起来dask轻量简单的多，但是除了只支持Python之外，似乎dask并没有哪比spark弱。
--
FROM 47.56.237.*
不一样的场景啊。spark 跟存储结合，而 dask 是纯粹的计算。
【 在 Erlang (拿起笔做刀枪) 的大作中提到: 】
: 相比起来dask轻量简单的多，但是除了只支持Python之外，似乎dask并没有哪比spark弱。
--
FROM 110.81.40.*
就说跟存储结合这个需求本来就是虚假的吧，dask也不妨碍你用任何storage layer去scale
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 不一样的场景啊。spark 跟存储结合，而 dask 是纯粹的计算。
--
FROM 47.56.237.*
互联网后端很多时候并没有什么计算，而是分布式地合并大量数据。这时候 spark 就有用了。
dask 虽然可以从多种存储后端去拿数据。但它在派发计算任务的时候，不会把任务派发到离计算近的地方——这是我以前了解到的，不知道现在能不能实现？
【 在 Erlang (拿起笔做刀枪) 的大作中提到: 】
: 就说跟存储结合这个需求本来就是虚假的吧，dask也不妨碍你用任何storage layer去scale
--
FROM 110.81.40.*
可能对自建Hadoop这种情况有点卵用，现在都是云原生搞到对象存储上，没啥离得近离得远了
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 互联网后端很多时候并没有什么计算，而是分布式地合并大量数据。这时候 spark 就有用了。
: dask 虽然可以从多种存储后端去拿数据。但它在派发计算任务的时候，不会把任务派发到离计算近的地方——这是我以前了解到的，不知道现在能不能实现？
--
FROM 47.56.237.*
那用 dask 就很合适了。celery/dask 都是 python 后端的神器。
【 在 Erlang (拿起笔做刀枪) 的大作中提到: 】
: 可能对自建Hadoop这种情况有点卵用，现在都是云原生搞到对象存储上，没啥离得近离得远了
--
修改:hgoldfish FROM 110.81.40.*
FROM 110.81.40.*
再说随着网络带宽和磁盘带宽的提升，就算是自建存储，可能这个调度的意义也不太大了，因为这样调度的成本太高了。
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 那用 dask 就很合适了。celery/dask 都是 python 后端的神器。
--
FROM 47.56.237.*
这个把计算派发到离存储近的地方的假设，应该来自Hadoop吧
感觉现在云计算的话，搞一个Hadoop集群不太经济，直接访问s3之类的对象存储，就不需要考虑上述假设了
【 在 hgoldfish 的大作中提到: 】
: 互联网后端很多时候并没有什么计算，而是分布式地合并大量数据。这时候 spark 就有用了。
: dask 虽然可以从多种存储后端去拿数据。但它在派发计算任务的时候，不会把任务派发到离计算近的地方——这是我以前了解到的，不知道现在能不能实现？
:
--
FROM 123.112.22.*
场景不一样，估计一半用spark的都是写sql查hive
【 在 Erlang 的大作中提到: 】
: 相比起来dask轻量简单的多，但是除了只支持Python之外，似乎dask并没有哪比spark弱。
--
FROM 49.7.47.*
你做什么大数据分析，都已经上到Dask了。
【 在 hgoldfish 的大作中提到: 】
: 那用 dask 就很合适了。celery/dask 都是 python 后端的神器。
:
--
修改:dhcn FROM 120.245.22.*
FROM 120.245.22.*