w***g 发帖数: 5958 | 1 四台机器,每台给48G内存,一个52G的dataset读不进去,跑了十几分钟自动重试无数
次最后失败。换乘一个16G的dataset,好歹读进去了。先repartition,然后cache,然
后count(),然后再count(),然后再count(),每次count()还是要40多秒。看UI,每台
机器内存也都用上了,我这是怎么回事?离亚秒级还有光年远啊。呼唤牛人帮我看看。
(说得是spark)
更新:上scala后实现亚秒了, 0.3秒光速跑完。
Tips:
1. 往狠里加内存。文本文件的overhead在350%的样子。10G的数据得准备35G的内存,
外加spark貌似在cache之外没台机器hold了10G内存的样子。如果是10G数据4台机器,
每台得给20G内存才能跑通畅。这个反正java世界的一直都这样,我也认了。
2. 往狠里加临时目录。我一开始没设,一直用的/tmp,一跑起来整个机器基本上就
freeze了。后来每台机器弄了两个大磁盘,repartition那步就比较通畅了。
我们最大的log还是太大,即使内存全上也cache不住,但是豫处理后应该可以不用导到
一台机器上算了。 |
p*****2 发帖数: 21240 | 2 cache之后肯定会快很多
你把代码发出来看看
我的感觉你没cache上
你这个size自己写程序处理最快 没必要上spark
【在 w***g 的大作中提到】 : 四台机器,每台给48G内存,一个52G的dataset读不进去,跑了十几分钟自动重试无数 : 次最后失败。换乘一个16G的dataset,好歹读进去了。先repartition,然后cache,然 : 后count(),然后再count(),然后再count(),每次count()还是要40多秒。看UI,每台 : 机器内存也都用上了,我这是怎么回事?离亚秒级还有光年远啊。呼唤牛人帮我看看。 : (说得是spark) : 更新:上scala后实现亚秒了, 0.3秒光速跑完。 : Tips: : 1. 往狠里加内存。文本文件的overhead在350%的样子。10G的数据得准备35G的内存, : 外加spark貌似在cache之外没台机器hold了10G内存的样子。如果是10G数据4台机器, : 每台得给20G内存才能跑通畅。这个反正java世界的一直都这样,我也认了。
|
p*****2 发帖数: 21240 | 3 不过很高兴看到大牛做各种实验 比空谈强很多
【在 p*****2 的大作中提到】 : cache之后肯定会快很多 : 你把代码发出来看看 : 我的感觉你没cache上 : 你这个size自己写程序处理最快 没必要上spark
|
w***g 发帖数: 5958 | 4 上scala后实现亚秒了(0.3秒),绝对牛x! 我服了。
python就这么台不起。
【在 w***g 的大作中提到】 : 四台机器,每台给48G内存,一个52G的dataset读不进去,跑了十几分钟自动重试无数 : 次最后失败。换乘一个16G的dataset,好歹读进去了。先repartition,然后cache,然 : 后count(),然后再count(),然后再count(),每次count()还是要40多秒。看UI,每台 : 机器内存也都用上了,我这是怎么回事?离亚秒级还有光年远啊。呼唤牛人帮我看看。 : (说得是spark) : 更新:上scala后实现亚秒了, 0.3秒光速跑完。 : Tips: : 1. 往狠里加内存。文本文件的overhead在350%的样子。10G的数据得准备35G的内存, : 外加spark貌似在cache之外没台机器hold了10G内存的样子。如果是10G数据4台机器, : 每台得给20G内存才能跑通畅。这个反正java世界的一直都这样,我也认了。
|
z****e 发帖数: 54598 | 5 cpython就是这么慢撒
【在 w***g 的大作中提到】 : 上scala后实现亚秒了(0.3秒),绝对牛x! 我服了。 : python就这么台不起。
|
s***o 发帖数: 2191 | 6 上java呢?有点好奇
【在 w***g 的大作中提到】 : 上scala后实现亚秒了(0.3秒),绝对牛x! 我服了。 : python就这么台不起。
|
z****e 发帖数: 54598 | 7 10个包子打赌差不了多少
我看他只是在count,估计做的是word count
这个用啥jvm上语言都不会有太大影响
【在 s***o 的大作中提到】 : 上java呢?有点好奇
|
w***g 发帖数: 5958 | 8 同样的程序java的似乎要比scala/python的长一倍,还没有interactive shell。
上java有点自虐的感觉。性能应该和scala一样吧。
【在 s***o 的大作中提到】 : 上java呢?有点好奇
|
z****e 发帖数: 54598 | 9 上eclipse了
scala在某些程序上可以优化效率
但是你这种简单的word count
估计没啥太大区别
【在 w***g 的大作中提到】 : 同样的程序java的似乎要比scala/python的长一倍,还没有interactive shell。 : 上java有点自虐的感觉。性能应该和scala一样吧。
|
w***g 发帖数: 5958 | 10 我是在做count。主要是看除了实打实计算以外部分的overhead。
真正的计算部分用啥环境实现都得这么多,C++比java快2倍的样子,java比python快10
倍的样子,很容易reason。spark能把overhead做到一秒以内还是很值得尊敬的。
【在 z****e 的大作中提到】 : 10个包子打赌差不了多少 : 我看他只是在count,估计做的是word count : 这个用啥jvm上语言都不会有太大影响
|
|
|
z****e 发帖数: 54598 | 11 我以前做count的时候
java用了.6秒,不过我用了hashmap,其他人用了list,效率就很低了
python的dic也比较慢,当时我看我的效率如此之快
都怀疑自己是不是搞错了,要求叫兽换dataset
后来看其他人都要等几十分钟,就觉得有些问题
当时我还是在本机做的,后来用了hpc,觉得好像更慢了
主要是进queue等待的时间比较久
10
【在 w***g 的大作中提到】 : 我是在做count。主要是看除了实打实计算以外部分的overhead。 : 真正的计算部分用啥环境实现都得这么多,C++比java快2倍的样子,java比python快10 : 倍的样子,很容易reason。spark能把overhead做到一秒以内还是很值得尊敬的。
|
z****e 发帖数: 54598 | 12 不过话说你能不能不要老拿这么入门级的例子来说啊?
数完行数数字数,你这是逗转行的玩吗?
除了搬运数据和数数以外,做点复杂度高一点的好不好?
老看这种例子觉得很无聊的说
10
【在 w***g 的大作中提到】 : 我是在做count。主要是看除了实打实计算以外部分的overhead。 : 真正的计算部分用啥环境实现都得这么多,C++比java快2倍的样子,java比python快10 : 倍的样子,很容易reason。spark能把overhead做到一秒以内还是很值得尊敬的。
|
z****e 发帖数: 54598 | |
N*****m 发帖数: 42603 | 14 不错,应该mark
【在 w***g 的大作中提到】 : 四台机器,每台给48G内存,一个52G的dataset读不进去,跑了十几分钟自动重试无数 : 次最后失败。换乘一个16G的dataset,好歹读进去了。先repartition,然后cache,然 : 后count(),然后再count(),然后再count(),每次count()还是要40多秒。看UI,每台 : 机器内存也都用上了,我这是怎么回事?离亚秒级还有光年远啊。呼唤牛人帮我看看。 : (说得是spark) : 更新:上scala后实现亚秒了, 0.3秒光速跑完。 : Tips: : 1. 往狠里加内存。文本文件的overhead在350%的样子。10G的数据得准备35G的内存, : 外加spark貌似在cache之外没台机器hold了10G内存的样子。如果是10G数据4台机器, : 每台得给20G内存才能跑通畅。这个反正java世界的一直都这样,我也认了。
|
w***g 发帖数: 5958 | 15 数数这个基本问题打通了,各种统计基本上就没问题了,
无非是分类别数数而已。在这个版打口水仗的乐趣在于那桔子跟苹果比,而不在于讨论
技术细节。
【在 z****e 的大作中提到】 : 不过话说你能不能不要老拿这么入门级的例子来说啊? : 数完行数数字数,你这是逗转行的玩吗? : 除了搬运数据和数数以外,做点复杂度高一点的好不好? : 老看这种例子觉得很无聊的说 : : 10
|
l*********s 发帖数: 5409 | |
n******t 发帖数: 4406 | 17 这么搞法,和把HDFS全部跑在ram disk上比起来优势在哪里?
【在 w***g 的大作中提到】 : 四台机器,每台给48G内存,一个52G的dataset读不进去,跑了十几分钟自动重试无数 : 次最后失败。换乘一个16G的dataset,好歹读进去了。先repartition,然后cache,然 : 后count(),然后再count(),然后再count(),每次count()还是要40多秒。看UI,每台 : 机器内存也都用上了,我这是怎么回事?离亚秒级还有光年远啊。呼唤牛人帮我看看。 : (说得是spark) : 更新:上scala后实现亚秒了, 0.3秒光速跑完。 : Tips: : 1. 往狠里加内存。文本文件的overhead在350%的样子。10G的数据得准备35G的内存, : 外加spark貌似在cache之外没台机器hold了10G内存的样子。如果是10G数据4台机器, : 每台得给20G内存才能跑通畅。这个反正java世界的一直都这样,我也认了。
|
z****e 发帖数: 54598 | 18 你真无聊,wdong啊
其他人在datasciences发的那篇clustering的论文我看spark上mllib还没有实现
现在mllib只有最简单的k means
你可以考虑一下做出来嘛
青史留名的东西哦
比你在这里灌这种算术的废水那是要强太多了
那篇论文你应该能看到,你的大学应该会帮你
实在看不到,我可以发给你
还有plsi和lda也都没实现
bm25也没看到
【在 w***g 的大作中提到】 : 数数这个基本问题打通了,各种统计基本上就没问题了, : 无非是分类别数数而已。在这个版打口水仗的乐趣在于那桔子跟苹果比,而不在于讨论 : 技术细节。
|
z****e 发帖数: 54598 | 19 我就说嘛,老是做这种算术操作,迟早被人骂
猴屁股这种level就没那么容易忽悠
最好的方式干脆对比kmeans,用mllib做一次kmeans
然后对比全部跑在ram上的hdfs的kmeans
那个应该可以用scala做一定程度上的优化
就是coltzhao说的那些优化手段
【在 n******t 的大作中提到】 : 这么搞法,和把HDFS全部跑在ram disk上比起来优势在哪里?
|
z****e 发帖数: 54598 | 20 猴屁股,我说说我的理解
虽然说spark的idea很容易理解
无非建cache,把硬盘上的数据读入内存
但是后续的操作,往往需要频繁滴access这些数据
比如mllib里面的k means, svd, vsm这些
都需要频繁滴access data,如果你自己去建cache
当然也可以,但是有工具帮你做这些事,何乐而不为不是?
更何况,现在mllib这些pkg已经放到spark上了
如果自己做,那就需要自己去找这些pkg,然后自己去动手去做整合
那这里面狗血的事情经常发生,所以spark能提供一些简易的工具是好事
另外我听说scala能够优化执行效率
这个因为俺从来都懒得研究字节码这些东西
怎么优化实在没力气投入,所以他们说是这样,那就是吧
这里面有优化的空间,有人能够优化,而且又不收费,为啥不要呢?
这是我觉得spark的两个主要意义
【在 n******t 的大作中提到】 : 这么搞法,和把HDFS全部跑在ram disk上比起来优势在哪里?
|
|
|
w***g 发帖数: 5958 | 21 别人写open source都有公司/学校在背后发工资,我又没拿钱瞎掺和什么。
等着用免费的轮子才是王道。我劳动力贱,implement这个东西也得收$10k吧,不然你
问问goodbug他会不会干。
pLSA和LDA需要用gibbs sampling/variational method实现,目前并行化的方法
是用mini batch。问题是batch一大收敛速度就会下降,而batch不大的话又没发发挥
并行计算的优势。我觉得spark上那个SGD可能都挺勉强的。
【在 z****e 的大作中提到】 : 你真无聊,wdong啊 : 其他人在datasciences发的那篇clustering的论文我看spark上mllib还没有实现 : 现在mllib只有最简单的k means : 你可以考虑一下做出来嘛 : 青史留名的东西哦 : 比你在这里灌这种算术的废水那是要强太多了 : 那篇论文你应该能看到,你的大学应该会帮你 : 实在看不到,我可以发给你 : 还有plsi和lda也都没实现 : bm25也没看到
|
p*****2 发帖数: 21240 | 22
用spark就上scala,没啥好说的。我这么不喜欢scala的都上了。
【在 s***o 的大作中提到】 : 上java呢?有点好奇
|
p*****2 发帖数: 21240 | 23
上python不是找虐吗?
【在 w***g 的大作中提到】 : 上scala后实现亚秒了(0.3秒),绝对牛x! 我服了。 : python就这么台不起。
|
w***g 发帖数: 5958 | 24 我专门研究过kmeans,kmeans在某些情况下是可以达到CPU/硬盘吞吐量的平衡的。
因为kmeans需要算nearest neighbor,计算量随着维度和k的上升而上升。上升
到一定的程度就可以和磁盘吞吐量达到平衡(~100MB/disk/second)。这时候就可以
用out-of-core的算法来实现,内存大小不会成为瓶颈。我还写过MPI代码做这个事情。
不过我估计我的代码在机群上可能也干不过spark。MPI同步那块死慢,有一半时间
在同步数据,算得再快也没用。
【在 z****e 的大作中提到】 : 猴屁股,我说说我的理解 : 虽然说spark的idea很容易理解 : 无非建cache,把硬盘上的数据读入内存 : 但是后续的操作,往往需要频繁滴access这些数据 : 比如mllib里面的k means, svd, vsm这些 : 都需要频繁滴access data,如果你自己去建cache : 当然也可以,但是有工具帮你做这些事,何乐而不为不是? : 更何况,现在mllib这些pkg已经放到spark上了 : 如果自己做,那就需要自己去找这些pkg,然后自己去动手去做整合 : 那这里面狗血的事情经常发生,所以spark能提供一些简易的工具是好事
|
z****e 发帖数: 54598 | 25 wdong
人活着不全是为了money
要有理想
当然这是左逼的思维方式
你大可以不接受
【在 w***g 的大作中提到】 : 别人写open source都有公司/学校在背后发工资,我又没拿钱瞎掺和什么。 : 等着用免费的轮子才是王道。我劳动力贱,implement这个东西也得收$10k吧,不然你 : 问问goodbug他会不会干。 : pLSA和LDA需要用gibbs sampling/variational method实现,目前并行化的方法 : 是用mini batch。问题是batch一大收敛速度就会下降,而batch不大的话又没发发挥 : 并行计算的优势。我觉得spark上那个SGD可能都挺勉强的。
|
k*******n 发帖数: 190 | 26 内存的问题,我们现在在整 flatbuffer,调入内存大概和压缩过的csv比是2:1, 这已
经是非常好的结果了,1000台机器已经降到了300台。 |