y*c
发帖数: 904 | 1 公司不用jvm, 现在领导说要用Spark的python API. 有成功／失败经验的吗? |
z****e
发帖数: 54598 | |
w***g
发帖数: 5958 | 3 有python API。慢得跟翔一样。除了算出来结果是对的（存疑），基本上丧失了spark
的一切好处。我们以前图省事用过，后来还是老实学了scala。
【在 z****e 的大作中提到】
: 不用jvm怎么跑spark？
|
y*c
发帖数: 904 | 4 http://emptypipes.org/2015/01/17/python-vs-scala-vs-spark/
找到这个benchmark数据，除了速度，有没有其他问题？
offline 处理数据速度不是最重要（数据不是超大） |
w***g
发帖数: 5958 | 5 你那个benchmark的数据也就300M，连基本的benchmark诚意也无，没有任何意义。
要做这种benchmark，至少弄个30G数据吧。我说30G，版上估计还有人要笑我呢。
你这个benchmark的事情要是在面试的时候说出来，遇到明白人基本上就没戏了。
你要是只有300M，直接上python就可以了。不需要spark。
【在 y*c 的大作中提到】
: http://emptypipes.org/2015/01/17/python-vs-scala-vs-spark/
: 找到这个benchmark数据，除了速度，有没有其他问题？
: offline 处理数据速度不是最重要（数据不是超大）
|
z****e
发帖数: 54598 | 6 那个就是cpython吧，那个慢正常，我们读书时候做作业
40m都经常搞死电脑，要算几十分钟的很多
我记得hadoop都已经放弃cpython，改成jython了
pypy也许好点
spark
【在 w***g 的大作中提到】
: 有python API。慢得跟翔一样。除了算出来结果是对的（存疑），基本上丧失了spark
: 的一切好处。我们以前图省事用过，后来还是老实学了scala。
|
w***g
发帖数: 5958 | 7 我觉得pypy有兼容性问题，要能跑起来就是撞大运。如果不能跑numpy和scikit-learn，
就是再快也没用。python走的是糙快猛的路数，从语言到程序都不是怎么严谨的。
兼容性问题我觉得无法解决。
下面摘自scikit-learn的文档。
In case you didn’t know, PyPy is the new, fast, just-in-time compiling
Python implementation. We don’t support it. When the NumPy support in PyPy
is complete or near-complete, and SciPy is ported over as well, we can start
thinking of a port. We use too much of NumPy to work with a partial
implementation.
【在 z****e 的大作中提到】
: 那个就是cpython吧，那个慢正常，我们读书时候做作业
: 40m都经常搞死电脑，要算几十分钟的很多
: 我记得hadoop都已经放弃cpython，改成jython了
: pypy也许好点
:
: spark
|
z****e
发帖数: 54598 | 8 用python就是各种撞大运
我以前做作业遇到算一个晚上不出结果的
都是编造点结果上去交差
反正不是论文，老师也不是很在乎作业对错
只要有做，就给分
learn，
PyPy
start
【在 w***g 的大作中提到】
: 我觉得pypy有兼容性问题，要能跑起来就是撞大运。如果不能跑numpy和scikit-learn，
: 就是再快也没用。python走的是糙快猛的路数，从语言到程序都不是怎么严谨的。
: 兼容性问题我觉得无法解决。
: 下面摘自scikit-learn的文档。
: In case you didn’t know, PyPy is the new, fast, just-in-time compiling
: Python implementation. We don’t support it. When the NumPy support in PyPy
: is complete or near-complete, and SciPy is ported over as well, we can start
: thinking of a port. We use too much of NumPy to work with a partial
: implementation.
|
w***g
发帖数: 5958 | 9 靠，这种事情你也敢出来承认。我给你立此存照了。
发20个包子过来我可以删贴。
【在 z****e 的大作中提到】
: 用python就是各种撞大运
: 我以前做作业遇到算一个晚上不出结果的
: 都是编造点结果上去交差
: 反正不是论文，老师也不是很在乎作业对错
: 只要有做，就给分
:
: learn，
: PyPy
: start
|
w********m
发帖数: 1137 | 10 1.3之前pyspark很慢。
1.3之后有了dataFrame，python优化得比scala都快了。重要的是单机的pandas直接移
植。
所以建议无脑上python。 |
|
|
w***g
发帖数: 5958 | 11 都1.3了。看来我落后了。现在世事更新太快，我已经跟不上了。我们那个系统开发的
过程中就经历了好几个版本，最后好像用的是1.1。
【在 w********m 的大作中提到】
: 1.3之前pyspark很慢。
: 1.3之后有了dataFrame，python优化得比scala都快了。重要的是单机的pandas直接移
: 植。
: 所以建议无脑上python。
|
z****e
发帖数: 54598 | 12 dynamic types要能比static types快
这个应该是天方夜谭吧，v8用了各种专利优化，最后还是慢于static types的语言
python的优化估计还不能碰这些专利
【在 w********m 的大作中提到】
: 1.3之前pyspark很慢。
: 1.3之后有了dataFrame，python优化得比scala都快了。重要的是单机的pandas直接移
: 植。
: 所以建议无脑上python。
|
w***g
发帖数: 5958 | 13 这个应该类似SQL和matlab，对于标准操作，后台其实使用scala实现的，
就可以做的很快。如果你非要传进去一个python写的回调函数，势必还是要慢的。
他说的应该是1.3标准操作的范围扩大了很多。
【在 z****e 的大作中提到】
: dynamic types要能比static types快
: 这个应该是天方夜谭吧，v8用了各种专利优化，最后还是慢于static types的语言
: python的优化估计还不能碰这些专利
|
N*****m
发帖数: 42603 | 14 确实啊
https://databricks.com/blog/2015/02/17/introducing-dataframes-in-spark-for-
large-scale-data-science.html
【在 w********m 的大作中提到】
: 1.3之前pyspark很慢。
: 1.3之后有了dataFrame，python优化得比scala都快了。重要的是单机的pandas直接移
: 植。
: 所以建议无脑上python。
|
w********m
发帖数: 1137 | 15 Catalyst optimizer吧，本版的reynold xin大神就是搞这个的。
【在 z****e 的大作中提到】
: dynamic types要能比static types快
: 这个应该是天方夜谭吧，v8用了各种专利优化，最后还是慢于static types的语言
: python的优化估计还不能碰这些专利
|
z****e
发帖数: 54598 | 16 准备上flink吧
streaming好像比较热
rxjava什么都在做这一块
【在 w***g 的大作中提到】
: 都1.3了。看来我落后了。现在世事更新太快，我已经跟不上了。我们那个系统开发的
: 过程中就经历了好几个版本，最后好像用的是1.1。
|
w***g
发帖数: 5958 | 17 这种东西都是用到了才上的。版本升级跟玩似的，学了也是白学。
要用的时候学，也就是半天时间。
【在 z****e 的大作中提到】
: 准备上flink吧
: streaming好像比较热
: rxjava什么都在做这一块
|
z****e
发帖数: 54598 | 18 make sense
把python直接编译成byte code
那就是最后的执行还是在jvm上了
只能说理论上scala也能这样搞
但是估计scala不会针对spark搞一个优化
【在 w********m 的大作中提到】
: Catalyst optimizer吧，本版的reynold xin大神就是搞这个的。
|
z****e
发帖数: 54598 | 19 那你们streaming用什么？
spark的stream是micro batch，有些难用的说
不用flink就只有storm了
【在 w***g 的大作中提到】
: 这种东西都是用到了才上的。版本升级跟玩似的，学了也是白学。
: 要用的时候学，也就是半天时间。
|
z****e
发帖数: 54598 | 20 就是针对api优化了
对于一般的python建模部分的代码，应该不太可能会再做一次优化
那样就等于写一个脚本引擎了都
【在 w***g 的大作中提到】
: 这个应该类似SQL和matlab，对于标准操作，后台其实使用scala实现的，
: 就可以做的很快。如果你非要传进去一个python写的回调函数，势必还是要慢的。
: 他说的应该是1.3标准操作的范围扩大了很多。
|
|
|
w***g
发帖数: 5958 | 21 所有模型都是周期性完整重算，还没到要用streaming的地步。
在线算法用C++写的，同时也负责处理上次模型计算以来新到的数据对模型的影响。
我觉得用C++写计算速度不是最主要的。肯定比scala快，但应该快不了好几倍。
C++的好处是省内存。100G内存可以处理全量用户。然后多台机器纯粹是
replicate增加吞吐量。用scala写在线模块的话，机器数量再加5倍估计都不够，
而且数据一旦出了内存，对吞吐量的影响是灾难性的。
我做的是音频类app的在线推荐，用户量从百度上查出来也有好几千万。同时在线的显
然没那么多。从性能和技术上来说，我可以用一台服务器搞定所有的推荐请求。实际肯定
不会那么做。但是replicate和sharding在实现难易程度上是有很大的差距的。
用C++使得整个在线服务的架构得到非常大的简化，架构简化得到的稳定性提高和维护
开销减少是非常大的。而且就是代码行数上来说，其实也并不吃亏。
离线用spark，看重的是可以很容易地尝试新的算法和模型。当时确实用的很爽。
【在 z****e 的大作中提到】
: 那你们streaming用什么？
: spark的stream是micro batch，有些难用的说
: 不用flink就只有storm了
|
d******e
发帖数: 2265 | 22 赵老师知道什么是平pandas 马
这玩意就是从c代码 numpy 千锤百炼了多少年数值计算
为什么不会比Scala快
【在 z****e 的大作中提到】
: dynamic types要能比static types快
: 这个应该是天方夜谭吧，v8用了各种专利优化，最后还是慢于static types的语言
: python的优化估计还不能碰这些专利
|
z****e
发帖数: 54598 | 23 改变不了python本身慢的事实
你丫往里面丢一个你自己用python写的model试试看
调个api算个p啊，那玩意只需要看个tutorial就可以了
【在 d******e 的大作中提到】
: 赵老师知道什么是平pandas 马
: 这玩意就是从c代码 numpy 千锤百炼了多少年数值计算
: 为什么不会比Scala快
|
z****e
发帖数: 54598 | 24 这种在线推荐应该很容易分治啊
你为啥要用一个100g的node做？
切成n块，每一块丢一个job，最后汇总一下就好了
肯定
【在 w***g 的大作中提到】
: 所有模型都是周期性完整重算，还没到要用streaming的地步。
: 在线算法用C++写的，同时也负责处理上次模型计算以来新到的数据对模型的影响。
: 我觉得用C++写计算速度不是最主要的。肯定比scala快，但应该快不了好几倍。
: C++的好处是省内存。100G内存可以处理全量用户。然后多台机器纯粹是
: replicate增加吞吐量。用scala写在线模块的话，机器数量再加5倍估计都不够，
: 而且数据一旦出了内存，对吞吐量的影响是灾难性的。
: 我做的是音频类app的在线推荐，用户量从百度上查出来也有好几千万。同时在线的显
: 然没那么多。从性能和技术上来说，我可以用一台服务器搞定所有的推荐请求。实际肯定
: 不会那么做。但是replicate和sharding在实现难易程度上是有很大的差距的。
: 用C++使得整个在线服务的架构得到非常大的简化，架构简化得到的稳定性提高和维护
|
w***g
发帖数: 5958 | 25 1个100g的node，在性能上可能是好几倍10个10g的node的总和。
抛开分治需要写额外的代码不提(代码越多，出错的可能性也越多),
没有任何系统可以做到linear scale out。而且随着节点数量的增多，
mean time to failure会急剧缩短。所以总体开销其实会更大。
这个好处只有我自己知道，魏老师可能也知道，没法跟用AWS的人说明白。
我手头production system好几个，要是成天出错需要救火的话，
哪来那么多时间上网灌水。我有一个50多个节点的系统，实在是
数据量太大，没办法的那种。每台机器也有80～100g内存。隔
一两天就要处理一个错误。相比而言，那种两台机器做replicate的
monolithic系统，都是十天半个月都不需要碰一下。
【在 z****e 的大作中提到】
: 这种在线推荐应该很容易分治啊
: 你为啥要用一个100g的node做？
: 切成n块，每一块丢一个job，最后汇总一下就好了
:
: 肯定
|
z****e
发帖数: 54598 | 26 你直接操作内存出错的概率远比你托管了gc加大内存出错的概率要大
大得多，而且这种玩意出错了，比如本该推荐a音频的，你给推荐成了b
这个你老板知道？好像也难吧
【在 w***g 的大作中提到】
: 1个100g的node，在性能上可能是好几倍10个10g的node的总和。
: 抛开分治需要写额外的代码不提(代码越多，出错的可能性也越多),
: 没有任何系统可以做到linear scale out。而且随着节点数量的增多，
: mean time to failure会急剧缩短。所以总体开销其实会更大。
: 这个好处只有我自己知道，魏老师可能也知道，没法跟用AWS的人说明白。
: 我手头production system好几个，要是成天出错需要救火的话，
: 哪来那么多时间上网灌水。我有一个50多个节点的系统，实在是
: 数据量太大，没办法的那种。每台机器也有80～100g内存。隔
: 一两天就要处理一个错误。相比而言，那种两台机器做replicate的
: monolithic系统，都是十天半个月都不需要碰一下。
|
z****e
发帖数: 54598 | 27 你应该丢一个chaos monkey进去砸一顿
测试一下系统的健壮程度
【在 w***g 的大作中提到】
: 1个100g的node，在性能上可能是好几倍10个10g的node的总和。
: 抛开分治需要写额外的代码不提(代码越多，出错的可能性也越多),
: 没有任何系统可以做到linear scale out。而且随着节点数量的增多，
: mean time to failure会急剧缩短。所以总体开销其实会更大。
: 这个好处只有我自己知道，魏老师可能也知道，没法跟用AWS的人说明白。
: 我手头production system好几个，要是成天出错需要救火的话，
: 哪来那么多时间上网灌水。我有一个50多个节点的系统，实在是
: 数据量太大，没办法的那种。每台机器也有80～100g内存。隔
: 一两天就要处理一个错误。相比而言，那种两台机器做replicate的
: monolithic系统，都是十天半个月都不需要碰一下。
|
w***g
发帖数: 5958 | 28 这个就看各人本事了。能把代码写对本来就是一种本事。
我的C++程序deliver之前都要先用valgrind跑过的，连libjpeg里
的那些内存没有初始化的错误我都会给改好。
至于推荐效果，和程序正确性是两个独立问题。
【在 z****e 的大作中提到】
: 你直接操作内存出错的概率远比你托管了gc加大内存出错的概率要大
: 大得多，而且这种玩意出错了，比如本该推荐a音频的，你给推荐成了b
: 这个你老板知道？好像也难吧
|
w***g
发帖数: 5958 | 29 我说的是我自己的情况，包含吹牛的成分。版上不会C++的同学
羡慕一下就可以了，千万别真的上C++了。不然到时候segfault
事小，出了raise condition程序上不了线，bug没法reproduce，
那可真是叫天天不应叫地地不灵了。慎之慎之。
适合C++写的都是那些在线是只读，或者近乎只读的，算法都只
涉及纯算法的情况。碰到那些需要写数据，算法需要处理业务
逻辑的，C++根本不在考虑范围内。我最近去看望博导，他还
跟我谈起他以前公司某牛人写raid logic的事迹，说该君先花了
好几个星期debug state machine，准确无误了才翻译成C代码，
然后在公司悬赏现金让人找bug。说产品卖了这么多年了只找出来
过1个bug。这种才是硬本事。
【在 w***g 的大作中提到】
: 1个100g的node，在性能上可能是好几倍10个10g的node的总和。
: 抛开分治需要写额外的代码不提(代码越多，出错的可能性也越多),
: 没有任何系统可以做到linear scale out。而且随着节点数量的增多，
: mean time to failure会急剧缩短。所以总体开销其实会更大。
: 这个好处只有我自己知道，魏老师可能也知道，没法跟用AWS的人说明白。
: 我手头production system好几个，要是成天出错需要救火的话，
: 哪来那么多时间上网灌水。我有一个50多个节点的系统，实在是
: 数据量太大，没办法的那种。每台机器也有80～100g内存。隔
: 一两天就要处理一个错误。相比而言，那种两台机器做replicate的
: monolithic系统，都是十天半个月都不需要碰一下。
|
n*****3
发帖数: 1584 | 30 second this;
python or R 一个模块 ， function 的下面都是 c／c++， 当然快。
要是整个 system 都比 java 快，
那 c／c++， java 都不要混了。
【在 z****e 的大作中提到】
: 改变不了python本身慢的事实
: 你丫往里面丢一个你自己用python写的model试试看
: 调个api算个p啊，那玩意只需要看个tutorial就可以了
|
|
|
c******o
发帖数: 1277 | 31 这个是肯定的，scala都是对vertical scaling好过horizontal scaling.
主要是有 ceiling,我们一个成功的游戏现在后端db 已经是AWS多个最大的storage
machine了。再往上只能horizontal scaling.
Big data的那些更夸张，最后一算，居然在AWS用的钱爆表了，还不如用BigQuery.
对于错误率，我倒不觉得，多节点就是小错不断，大错没有。 都自动化处理了。
我们有过5x volume increase的，也就最初3分钟有latency问题，然后一切照常，再来
5x也可以。
有过2/3mongodb cluster down的，也是一点事没有，等到30minutes以后failed
instance automatically replaced, 再连来一个2/3mongodb cluster down 也没事。
这个和两个大机器一般没事，有事就是大事不一样。
【在 w***g 的大作中提到】
: 1个100g的node，在性能上可能是好几倍10个10g的node的总和。
: 抛开分治需要写额外的代码不提(代码越多，出错的可能性也越多),
: 没有任何系统可以做到linear scale out。而且随着节点数量的增多，
: mean time to failure会急剧缩短。所以总体开销其实会更大。
: 这个好处只有我自己知道，魏老师可能也知道，没法跟用AWS的人说明白。
: 我手头production system好几个，要是成天出错需要救火的话，
: 哪来那么多时间上网灌水。我有一个50多个节点的系统，实在是
: 数据量太大，没办法的那种。每台机器也有80～100g内存。隔
: 一两天就要处理一个错误。相比而言，那种两台机器做replicate的
: monolithic系统，都是十天半个月都不需要碰一下。
|
N*****m
发帖数: 42603 | 32 后端db用的啥？
【在 c******o 的大作中提到】
: 这个是肯定的，scala都是对vertical scaling好过horizontal scaling.
: 主要是有 ceiling,我们一个成功的游戏现在后端db 已经是AWS多个最大的storage
: machine了。再往上只能horizontal scaling.
: Big data的那些更夸张，最后一算，居然在AWS用的钱爆表了，还不如用BigQuery.
: 对于错误率，我倒不觉得，多节点就是小错不断，大错没有。 都自动化处理了。
: 我们有过5x volume increase的，也就最初3分钟有latency问题，然后一切照常，再来
: 5x也可以。
: 有过2/3mongodb cluster down的，也是一点事没有，等到30minutes以后failed
: instance automatically replaced, 再连来一个2/3mongodb cluster down 也没事。
: 这个和两个大机器一般没事，有事就是大事不一样。
|
g*****g
发帖数: 34805 | 33 他做的是offline系统，健壮性不是最重要的，所以可以接受。我们是出了问题半夜三
点都得起来解决，有问题宁可上班时间出，所以需要猴子。
【在 z****e 的大作中提到】
: 你应该丢一个chaos monkey进去砸一顿
: 测试一下系统的健壮程度
|
w***g
发帖数: 5958 | 34 我也都是线上系统。只是我们用户没你们多，我拿的钱肯定也没你们拿得多，甚至可能
比赵策都要少好多。系统倒没彻底挂过，但偶尔带病运转，拖个10来个小时甚至有时候
过周末了拖二三十个小时才解决的，也没啥大问题。我的好处：不用坐班，不签合同，
活干完了自己想干嘛干嘛。
其实不管用啥技术做系统，都有挂掉的可能，就是Google做到现在偶尔也还会有major
outage。你们netflix的outage可能比google还多点。我的outage可能也就是比你们再
多那么一点。这个跟用大机器还是用AWS没啥太大的关系，和系统设计还有代码质量
关系更大。AWS也就是最近十来年的事情，之前还不都靠大机器。
【在 g*****g 的大作中提到】
: 他做的是offline系统，健壮性不是最重要的，所以可以接受。我们是出了问题半夜三
: 点都得起来解决，有问题宁可上班时间出，所以需要猴子。
|
g*****g
发帖数: 34805 | 35 我们的系统很复杂，复杂在多region，还要active-active failover。美国西部要是地
震停电了我们能半个小时内把用户都搬到东部。99.9%的availability已经不错了。这
个跟用大机器还是AWS关系还是很大的，大机器一旦挂了就是挂了。至于用AWS是因为我
们没钱没时间去做那么多数据中心。
major
【在 w***g 的大作中提到】
: 我也都是线上系统。只是我们用户没你们多，我拿的钱肯定也没你们拿得多，甚至可能
: 比赵策都要少好多。系统倒没彻底挂过，但偶尔带病运转，拖个10来个小时甚至有时候
: 过周末了拖二三十个小时才解决的，也没啥大问题。我的好处：不用坐班，不签合同，
: 活干完了自己想干嘛干嘛。
: 其实不管用啥技术做系统，都有挂掉的可能，就是Google做到现在偶尔也还会有major
: outage。你们netflix的outage可能比google还多点。我的outage可能也就是比你们再
: 多那么一点。这个跟用大机器还是用AWS没啥太大的关系，和系统设计还有代码质量
: 关系更大。AWS也就是最近十来年的事情，之前还不都靠大机器。
|
z****e
发帖数: 54598 | 36 coltzhao不是已经说了么？
【在 N*****m 的大作中提到】
: 后端db用的啥？
|
