z****e
发帖数: 54598 | 1 这么做是不是因为依赖了akka的缘故？
immutable真是一个十分无聊的设计
对这个feature实在是无爱
flink只要能改掉这个设计，俺们就换flink
要不然一下storm一下spark的，有些蛋疼 |
p*****2
发帖数: 21240 | 2 这个应该是一点关系也没有
【在 z****e 的大作中提到】
: 这么做是不是因为依赖了akka的缘故？
: immutable真是一个十分无聊的设计
: 对这个feature实在是无爱
: flink只要能改掉这个设计，俺们就换flink
: 要不然一下storm一下spark的，有些蛋疼
|
z****e
发帖数: 54598 | 3 那把spark绑死在batch processing上是什么考虑？
【在 p*****2 的大作中提到】
: 这个应该是一点关系也没有
|
w***g
发帖数: 5958 | 4 不是batch的做不出来。要能做出来干嘛要batch。BLAS的性能要发挥出来矩阵得足够大
才行。
【在 z****e 的大作中提到】
: 那把spark绑死在batch processing上是什么考虑？
|
n*****3
发帖数: 1584 | 5 我猜是因为要 尽量reuse 现有的 code base，
大多 user case spa RK steaming 够用的。
瓶颈应该不在这。
IM MU table 在 concurrency 方面 优势还是很大的。clojure same approach
【在 z****e 的大作中提到】
: 那把spark绑死在batch processing上是什么考虑？
|
z****e
发帖数: 54598 | 6 这说的是dataset吧
streaming不就是为了能够real time process而消耗一部分性能么？
硬件开销和响应时间本来就是一个trade off
micro batch最大问题是不能即时反应
目前比较理想的方案就是kafka+storm
spark因为固定在batch上，所以不太行的样子
这一块好新啊，感觉在摸着石头过河，有谁是做streaming的？
古德霸他们弄视频的是不是用这个比较多？
【在 w***g 的大作中提到】
: 不是batch的做不出来。要能做出来干嘛要batch。BLAS的性能要发挥出来矩阵得足够大
: 才行。
|
z****e
发帖数: 54598 | 7 我感觉是rdd这种数据结构限制了他们的发挥
dstream最终还是捆死在rdd上，也就是dstream是rdd的一种
而rdd比较适合dataset，并不十分适合datastream
而spark的基石就是rdd，算法是ml那些，但是数据结构基本上都是rdd
而rdd是为dataset也就是batch处理而设计出来的
为了迁就dataset，硬把datastream的数据结构搞成rdd
这看来不是一个什么很好的选择
当然对于大多数应用来说，micro batch够用
但是总感觉怪怪的，any way，如果flink改掉这个的话
能够结合spark和storm的优点的话，我觉得蛮好
值得一试，比起自己去折腾storm+spark要强
这两个光弄其中一个就已经够呛了
【在 n*****3 的大作中提到】
: 我猜是因为要 尽量reuse 现有的 code base，
: 大多 user case spa RK steaming 够用的。
: 瓶颈应该不在这。
: IM MU table 在 concurrency 方面 优势还是很大的。clojure same approach
|
z****e
发帖数: 54598 | 8 rdd最后一个d就是dataset的意思
datastream跟dataset还是有本质上的区别的
dstream->rdd并不是一个非常make sense的解决方案
还有这两个都用了akka，所以目前python什么其实都比较蛋疼
最主要的还是java和scala，要么就自己去写python那些接口
那就麻烦了，估计flink也不是个头，将来基于vert.x应该会有更好的
能够满足更多脚本的类似spark/flink的数据转换framework出现 |
z****e
发帖数: 54598 | 9 看了下flink
streaming部分的数据结构就是DataStream
不是dataset，这个貌似不错的样子
然后batch的部分数据结构是DataSet
这两个分开比较好，目前streaming部分flink只支持java和scala
dataset两个都有python api
底层都用了akka
然后后面就是map, flatmap, reduce, filter这些 |
z****e
发帖数: 54598 | |
|
|
d******e
发帖数: 2265 | 11 不是有pyhton for j嘛
一点都不蛋疼
【在 z****e 的大作中提到】
: rdd最后一个d就是dataset的意思
: datastream跟dataset还是有本质上的区别的
: dstream->rdd并不是一个非常make sense的解决方案
: 还有这两个都用了akka，所以目前python什么其实都比较蛋疼
: 最主要的还是java和scala，要么就自己去写python那些接口
: 那就麻烦了，估计flink也不是个头，将来基于vert.x应该会有更好的
: 能够满足更多脚本的类似spark/flink的数据转换framework出现
|
g*****g
发帖数: 34805 | 12 Lambda architecture
【在 z****e 的大作中提到】
: 这说的是dataset吧
: streaming不就是为了能够real time process而消耗一部分性能么？
: 硬件开销和响应时间本来就是一个trade off
: micro batch最大问题是不能即时反应
: 目前比较理想的方案就是kafka+storm
: spark因为固定在batch上，所以不太行的样子
: 这一块好新啊，感觉在摸着石头过河，有谁是做streaming的？
: 古德霸他们弄视频的是不是用这个比较多？
|
f********x
发帖数: 99 | 13 解铃还需系铃人:
http://cloud.google.com/dataflow/
【在 z****e 的大作中提到】
: 这么做是不是因为依赖了akka的缘故？
: immutable真是一个十分无聊的设计
: 对这个feature实在是无爱
: flink只要能改掉这个设计，俺们就换flink
: 要不然一下storm一下spark的，有些蛋疼
|
z****e
发帖数: 54598 | 14 不开源，会被lockin在gce上
算了吧，这种lockin一般都不怎么用，除非对这个平台特别有信心
【在 f********x 的大作中提到】
: 解铃还需系铃人:
: http://cloud.google.com/dataflow/
|
j********x
发帖数: 2330 | 15 还好吧
反正依赖google不算大问题
这个内部外部都在用
除非google死了
这个才会完蛋
能活过google的早已经是成功了反正
【在 z****e 的大作中提到】
: 不开源，会被lockin在gce上
: 算了吧，这种lockin一般都不怎么用，除非对这个平台特别有信心
|
f********x
发帖数: 99 | 16 SDK开源，Execution engine不会被lockin。Google其实早有预谋去统一这块市场。
Dataflow over Spark:
http://googlecloudplatform.blogspot.com/2015/01/easily-run-data
Dataflow over Flink:
http://googlecloudplatform.blogspot.com/2015/03/announcing-Goog
Genome analysis pipeline over Dataflow:
http://github.com/googlegenomics/dataflow-java
【在 z****e 的大作中提到】
: 不开源，会被lockin在gce上
: 算了吧，这种lockin一般都不怎么用，除非对这个平台特别有信心
|
