w***g 发帖数: 5958 | 1 在mapr上的spark vs hive,数文件行数。四台服务器一共330134452行。
hive 49.162s
spark-shell 43.590s
pyspark 67.182s
也就一般般而已。 |
N*****m 发帖数: 42603 | 2 只跑一次,本来就差不多
因为你这是把spark当hadoop用
spark重点是iterative
【在 w***g 的大作中提到】 : 在mapr上的spark vs hive,数文件行数。四台服务器一共330134452行。 : hive 49.162s : spark-shell 43.590s : pyspark 67.182s : 也就一般般而已。
|
e***m 发帖数: 92 | 3 数文件行数主要是disk I/O bounded.体现不了spark的优势. 对于某些iterative的,用
到的输入数据不是特别大的机器学习的算法,spark优势较大.
【在 w***g 的大作中提到】 : 在mapr上的spark vs hive,数文件行数。四台服务器一共330134452行。 : hive 49.162s : spark-shell 43.590s : pyspark 67.182s : 也就一般般而已。
|
x***4 发帖数: 1815 | 4 正解
【在 e***m 的大作中提到】 : 数文件行数主要是disk I/O bounded.体现不了spark的优势. 对于某些iterative的,用 : 到的输入数据不是特别大的机器学习的算法,spark优势较大.
|
w***g 发帖数: 5958 | 5 好歹可以不用mahout了。
【在 e***m 的大作中提到】 : 数文件行数主要是disk I/O bounded.体现不了spark的优势. 对于某些iterative的,用 : 到的输入数据不是特别大的机器学习的算法,spark优势较大.
|
k*******n 发帖数: 190 | 6 用1000台机器,5T的数据,就得出完全不同的结论了。
map reduce 需要一个小时的工作,spark 可以在亚秒级的时间内给出答案。 |
n******t 发帖数: 4406 | 7 什么狗屁事情5T数据要1000台机器?钱可以这么烧吗?
【在 k*******n 的大作中提到】 : 用1000台机器,5T的数据,就得出完全不同的结论了。 : map reduce 需要一个小时的工作,spark 可以在亚秒级的时间内给出答案。
|
z****e 发帖数: 54598 | 8 ft
越简单的东西越没有意义
就像你从web上搬运数据的话
用js/groovy/ruby/python这些都不会有太大区别
本质上一样的
数行数本质是从硬盘上挨个数过去
怎么做都那样
spark的优势在于对于复杂度比较高的运算
它会先将数据读入内存,做成cache
然后每次计算你就不需要去access硬盘了
所以你的算法越复杂,复杂度越高,spark优势越大
【在 w***g 的大作中提到】 : 在mapr上的spark vs hive,数文件行数。四台服务器一共330134452行。 : hive 49.162s : spark-shell 43.590s : pyspark 67.182s : 也就一般般而已。
|
z****e 发帖数: 54598 | 9 需要多少台机器也跟复杂度相关
而不仅仅取决于数据量有多大
搞计算那个博导他们操作的数据多数就没有5t
这1000台机器还没有他们用的hpc一半贵
他们用的consultant一天的要价就可以买个node了
【在 n******t 的大作中提到】 : 什么狗屁事情5T数据要1000台机器?钱可以这么烧吗?
|
f******2 发帖数: 2455 | 10 spark本身就是被过于神话了,热度应该在3年左右,参考hadoop
【在 w***g 的大作中提到】 : 在mapr上的spark vs hive,数文件行数。四台服务器一共330134452行。 : hive 49.162s : spark-shell 43.590s : pyspark 67.182s : 也就一般般而已。
|
|
|
z****e 发帖数: 54598 | 11 任何tech都有一个潮起潮落的过程
无论什么东西,能不能把握住这头几年,是一个tech startup胜败的关键
等潮落了之后,就没戏了
【在 f******2 的大作中提到】 : spark本身就是被过于神话了,热度应该在3年左右,参考hadoop
|
z****e 发帖数: 54598 | 12 你做一下clustering
随便什么算法
再对比hadoop
【在 w***g 的大作中提到】 : 在mapr上的spark vs hive,数文件行数。四台服务器一共330134452行。 : hive 49.162s : spark-shell 43.590s : pyspark 67.182s : 也就一般般而已。
|
l*****t 发帖数: 2019 | 13 可能是他的算法要反复比对同一数据,那倒是很和spark的。
【在 n******t 的大作中提到】 : 什么狗屁事情5T数据要1000台机器?钱可以这么烧吗?
|
w***g 发帖数: 5958 | 14 平均一台机器处理5G数据,很了不起吗?用1/10的硬件性能得出的数据没有多大实际意
义。5T数据用100台机器,或者50T数据1000台机器,假设每台机器有128G内存,加上
overhead差不多能用掉百分之七八十的内存,这样的话得出的性能数据才比较靠谱。也
有可能
aws的硬件要打折扣,一台机器只能当1/10台用,那个我就不得而知了。
你说的1000台机器亚秒级给出答案我不是很信。即使啥东西不算,1000台机器同步一下
就得亚秒级吧。
我发这个帖子是因为有人号称即使从硬盘读spark也比hadoop快10倍。拿内存和硬盘比
快100倍没啥surprising的。
我目前帮忙做的一家,日志有几个T吧,但是处理干净了要送去跑ML算法的时候也就几
个G十几个G了。Hadoop和hive啥的都用来做数据清洗特征抽取了,都是线性复杂度过一
遍的事情。一大个cluster用来存日志和做豫处理,然后弄出来一点点干净的数据,在
一台机器上跑需要迭代的算法。你说的1000台机器处理5T数据,我只能做一下猜测:
1. 算法是CPU bound,内存都不是瓶颈。所以会出现平均一台机器只处理5G的情形。这
个和你的亚秒级给出答案不符。
2. 你们有钱摆阔气,这个我服。我上次算过,即使AWS一千台机器跑一天也是上万刀的
问题。
3. 如果真心有给出用1000台机器算5T数据这种方案的engineer,我觉得这人是
incompetent的。考虑到工资开销和硬件开销的比例,我觉得应该hire一个更加明白事
的人。硬件省一半一年也是100w。
这年头IT业太多的人拿钱打水漂了,动不动就是几个billion收购,几千台机器算东西。
我觉得这不是好现象。
【在 k*******n 的大作中提到】 : 用1000台机器,5T的数据,就得出完全不同的结论了。 : map reduce 需要一个小时的工作,spark 可以在亚秒级的时间内给出答案。
|
n******t 发帖数: 4406 | 15 我感觉这东西基本上在走圈钱路数,不过我觉得it多少是能忽悠到一些东西的。
原因和我之前说的一样,这么个方案,砸钱+东西至少不会明显变慢,有大公司
会被忽悠的。
【在 z****e 的大作中提到】 : 任何tech都有一个潮起潮落的过程 : 无论什么东西,能不能把握住这头几年,是一个tech startup胜败的关键 : 等潮落了之后,就没戏了
|
w***g 发帖数: 5958 | 16 这东西有一个切实的好处,就是编程比hadoop更简单灵活。很多人其实不怎么在乎
几倍时间的演示,但是要是能简化编程,engineer还是喜闻乐见的。
圈钱绝对是圈钱。
【在 n******t 的大作中提到】 : 我感觉这东西基本上在走圈钱路数,不过我觉得it多少是能忽悠到一些东西的。 : 原因和我之前说的一样,这么个方案,砸钱+东西至少不会明显变慢,有大公司 : 会被忽悠的。
|
f******2 发帖数: 2455 | 17 Cloudera, mapr, hortonworks, databricks都是圈钱的,
不过它们留下来的东西是有用处的
【在 w***g 的大作中提到】 : 这东西有一个切实的好处,就是编程比hadoop更简单灵活。很多人其实不怎么在乎 : 几倍时间的演示,但是要是能简化编程,engineer还是喜闻乐见的。 : 圈钱绝对是圈钱。
|
z****e 发帖数: 54598 | 18 圈钱也只有这个时候有机会了,再等五六年,所有人都会了
开源的东西也完善了,就没戏了,技术的轮子都是有时效性的
你看现在fb开源了一堆,有用么?基本上社区都是死气沉沉的
原因也很简单,那些轮子应用的领域已经充斥着各种开源的,收费的轮子
市场早就饱和了,再造也没有意义了,技术轮子要造就要造别人没造过的
才有机会,ml市场还比较空旷,没啥人在做,这就是他们的机会
【在 n******t 的大作中提到】 : 我感觉这东西基本上在走圈钱路数,不过我觉得it多少是能忽悠到一些东西的。 : 原因和我之前说的一样,这么个方案,砸钱+东西至少不会明显变慢,有大公司 : 会被忽悠的。
|
z****e 发帖数: 54598 | 19 spark是apache的开源项目,你用spark又不用付钱,只要你会用
apache你还信不过?datastax的产品才是用来卖钱的
市场刚培育出来的时候,因为会的人不多,所以这个时候卖服务
会有很多人去买,以后等市场上会的人多了,这个利润就下来了
所以技术轮子都有时效性的,以前os,db,ejb,nosql这些都是如此
【在 w***g 的大作中提到】 : 这东西有一个切实的好处,就是编程比hadoop更简单灵活。很多人其实不怎么在乎 : 几倍时间的演示,但是要是能简化编程,engineer还是喜闻乐见的。 : 圈钱绝对是圈钱。
|
z****e 发帖数: 54598 | 20 分布式的钱烧不了多少
用的都是烂机器
对比人家用的consultants+hpc组合
那真的是小儿科
hpc那才是真烧钱
那个博导还嘲笑我们南半球最powerful的hpc
在世界ranking排不到top50呢
【在 w***g 的大作中提到】 : 平均一台机器处理5G数据,很了不起吗?用1/10的硬件性能得出的数据没有多大实际意 : 义。5T数据用100台机器,或者50T数据1000台机器,假设每台机器有128G内存,加上 : overhead差不多能用掉百分之七八十的内存,这样的话得出的性能数据才比较靠谱。也 : 有可能 : aws的硬件要打折扣,一台机器只能当1/10台用,那个我就不得而知了。 : 你说的1000台机器亚秒级给出答案我不是很信。即使啥东西不算,1000台机器同步一下 : 就得亚秒级吧。 : 我发这个帖子是因为有人号称即使从硬盘读spark也比hadoop快10倍。拿内存和硬盘比 : 快100倍没啥surprising的。 : 我目前帮忙做的一家,日志有几个T吧,但是处理干净了要送去跑ML算法的时候也就几
|
|
|
j****y 发帖数: 684 | 21 大牛说说spark的市场还能好多少年?现在是刚开始吧。
而且公司hadoop也不都迁移到spark吧,那以前搞hadoop的人都重新学spark?
【在 z****e 的大作中提到】 : spark是apache的开源项目,你用spark又不用付钱,只要你会用 : apache你还信不过?datastax的产品才是用来卖钱的 : 市场刚培育出来的时候,因为会的人不多,所以这个时候卖服务 : 会有很多人去买,以后等市场上会的人多了,这个利润就下来了 : 所以技术轮子都有时效性的,以前os,db,ejb,nosql这些都是如此
|
z****e 发帖数: 54598 | 22 3-5年吧
现在是刚开始
hadoop和spark有啥冲突的
hdfs这些还得用啊,spark又不管这些
【在 j****y 的大作中提到】 : 大牛说说spark的市场还能好多少年?现在是刚开始吧。 : 而且公司hadoop也不都迁移到spark吧,那以前搞hadoop的人都重新学spark?
|
w***g 发帖数: 5958 | 23 我觉得10台烂机器不如一台牛机器好使啊。我说的也不是啥HPC,现在主流的1U服务器
,128G内存+dual 6 core的服务器,再插上些1T的SSD或者4T的HDD,其实很能算一些东
西了。IBM那些所谓的超算,未必比Intel牛多少。机器越多通信成本就越高。别说1000
台,一个柜子撑死放50台机器,100台机器交换机之间的通信就成瓶颈了,就只能做带
reduce的算法了。你用烂机器,也是一台机器占1U,用的差不多也是1份电,并行了以
后性能还要打折扣,其实得不偿失。
【在 z****e 的大作中提到】 : 分布式的钱烧不了多少 : 用的都是烂机器 : 对比人家用的consultants+hpc组合 : 那真的是小儿科 : hpc那才是真烧钱 : 那个博导还嘲笑我们南半球最powerful的hpc : 在世界ranking排不到top50呢
|
w***g 发帖数: 5958 | 24 spark的市场好不好其实跟你我没太大关系。现在出来的东西一个比一个容易用,做大
数据的都烂大街了。想赚钱得看下一波的方向了。
【在 j****y 的大作中提到】 : 大牛说说spark的市场还能好多少年?现在是刚开始吧。 : 而且公司hadoop也不都迁移到spark吧,那以前搞hadoop的人都重新学spark?
|
z****e 发帖数: 54598 | 25 你这个本质上还是分布式堆机器的思路
人家hpc多牛逼的东西,哪里看得起你这种思路
人家比的都是我一台机器多powerful,能搞定多大的计算量
你啥时间见到hpc guys说n>=3的机器过了?
顶多弄多一台机器做个热备,也就这样了
分布式不如hpc好使,那不是显然嘛,人家机器强大,还配备有consultants
能不比这种破机器强么?所以博导成天牛逼哄哄不是没有道理的
1000
【在 w***g 的大作中提到】 : 我觉得10台烂机器不如一台牛机器好使啊。我说的也不是啥HPC,现在主流的1U服务器 : ,128G内存+dual 6 core的服务器,再插上些1T的SSD或者4T的HDD,其实很能算一些东 : 西了。IBM那些所谓的超算,未必比Intel牛多少。机器越多通信成本就越高。别说1000 : 台,一个柜子撑死放50台机器,100台机器交换机之间的通信就成瓶颈了,就只能做带 : reduce的算法了。你用烂机器,也是一台机器占1U,用的差不多也是1份电,并行了以 : 后性能还要打折扣,其实得不偿失。
|
z****e 发帖数: 54598 | 26 当然有关系,有本事的去ml弄钱
没本事的堆点spark,混口饭吃,向boss多要点工资还是可以的
【在 w***g 的大作中提到】 : spark的市场好不好其实跟你我没太大关系。现在出来的东西一个比一个容易用,做大 : 数据的都烂大街了。想赚钱得看下一波的方向了。
|
w***g 发帖数: 5958 | 27 我的意思是说如果不愿意三天两头学个新东西玩玩的人其实不适合搞IT。像我这种特别
鄙视hadoop和spark的,好歹也要装上玩玩才行,一不小心解决了个实际问题那是赚了
,那叫技多不压身。有这功夫纠结学不学,文档都看完了。
【在 z****e 的大作中提到】 : 当然有关系,有本事的去ml弄钱 : 没本事的堆点spark,混口饭吃,向boss多要点工资还是可以的
|
z****e 发帖数: 54598 | 28 java->j2ee->hadoop(big data/nosql)->spark(ml)
这是java程序员常见的自我增值的一个path
【在 w***g 的大作中提到】 : 我的意思是说如果不愿意三天两头学个新东西玩玩的人其实不适合搞IT。像我这种特别 : 鄙视hadoop和spark的,好歹也要装上玩玩才行,一不小心解决了个实际问题那是赚了 : ,那叫技多不压身。有这功夫纠结学不学,文档都看完了。
|
c******o 发帖数: 1277 | 29 spark 不是 hadoop的竞争者。
是mapreduce的替代品。我们的stack就是hdfs+spark+aws s3,可能会用 Cassandra 替
代hdfs.
对我们来说,hadoop (以前的BI系统),换成spark的好处有很多:
1. unified system =》 成为真正的pipeline, easy to program, modern, and
reliable, less maintenance.
2. much much faster (really, really fast for most BI use cases) , BI 最关心
的是最近,即使是历史数据,也是会对一段时间多加分析。反正测试是很快
3. uniformed way to do stream/interactive/batch/sql/ML/graph calculation, 很
多你在interactive/batch弄的东西,直接就可以用到stream, 常见的就是interactive
试验一下,成功了,转成 batch/stream,持续监视。
对一一个大型的数据分析系统 (前后几十个子系统,因为持续开发一大堆补丁, 加上
一大堆自己都不知道的cron job/node), 能换成一个统一,简单,快速的系统实在是太
大的诱惑了,你那些东一榔头,西一棒槌得零星测试根本没法描述spark的好处。
现在我们唯一的blocker 就是必须要一个jdbc server 给datameer用,不知道1.1的好
不好用。 |
z****e 发帖数: 54598 | 30 re这个
interactive
【在 c******o 的大作中提到】 : spark 不是 hadoop的竞争者。 : 是mapreduce的替代品。我们的stack就是hdfs+spark+aws s3,可能会用 Cassandra 替 : 代hdfs. : 对我们来说,hadoop (以前的BI系统),换成spark的好处有很多: : 1. unified system =》 成为真正的pipeline, easy to program, modern, and : reliable, less maintenance. : 2. much much faster (really, really fast for most BI use cases) , BI 最关心 : 的是最近,即使是历史数据,也是会对一段时间多加分析。反正测试是很快 : 3. uniformed way to do stream/interactive/batch/sql/ML/graph calculation, 很 : 多你在interactive/batch弄的东西,直接就可以用到stream, 常见的就是interactive
|
|
|
z****e 发帖数: 54598 | 31 spark其实就是一个big data的统一接口
其本质跟jdbc,hibernate没有太大区别
统一了接口之后,后续所有的开发都好办了
以前又是hive又是pig的,乱七八糟
烦,现在好了,都dump掉,全转spark,省得啰嗦
spark sql,spark r还有spark ml都是非常有前途的东西
interactive
【在 c******o 的大作中提到】 : spark 不是 hadoop的竞争者。 : 是mapreduce的替代品。我们的stack就是hdfs+spark+aws s3,可能会用 Cassandra 替 : 代hdfs. : 对我们来说,hadoop (以前的BI系统),换成spark的好处有很多: : 1. unified system =》 成为真正的pipeline, easy to program, modern, and : reliable, less maintenance. : 2. much much faster (really, really fast for most BI use cases) , BI 最关心 : 的是最近,即使是历史数据,也是会对一段时间多加分析。反正测试是很快 : 3. uniformed way to do stream/interactive/batch/sql/ML/graph calculation, 很 : 多你在interactive/batch弄的东西,直接就可以用到stream, 常见的就是interactive
|
c****e 发帖数: 1453 | 32 simple IO显不出来。HIVE用了0.13? HIVE实现stinger initiative以后,本来就快了
差不多50倍。Cloudera当时想放弃HIVE, 专心推Imapla现在也被迫回头了。
Hortonworks给Windows提供HDInsight有点结盟的意思,微软贡献了SQL query
optimization到HIVE,还有column file compression format. 这些东西都加上去,和
Spark差别没那么大。一般的逻辑处理,不是极端的算法,5倍到10倍撑死了。
Spark除了RDD, 说到底是继承了Dryad的paper, 用operator做处理比纯粹的MR效率高很
多,再加上中间i/o不要都写到硬盘上,速度一下子上来了。HIVE stinger也是搬这一
套,普通的商业逻辑处理差别只会越来越小。
迭代的算法Spark优势会比较大,但是ML-Lib东西还比较少。没有用过,有用过的出来
说说perf吗?比如我跑个vowpal-wabbit会快多少倍?
【在 w***g 的大作中提到】 : 在mapr上的spark vs hive,数文件行数。四台服务器一共330134452行。 : hive 49.162s : spark-shell 43.590s : pyspark 67.182s : 也就一般般而已。
|
n******t 发帖数: 4406 | 33 您给说说spark为什么会快?
interactive
【在 c******o 的大作中提到】 : spark 不是 hadoop的竞争者。 : 是mapreduce的替代品。我们的stack就是hdfs+spark+aws s3,可能会用 Cassandra 替 : 代hdfs. : 对我们来说,hadoop (以前的BI系统),换成spark的好处有很多: : 1. unified system =》 成为真正的pipeline, easy to program, modern, and : reliable, less maintenance. : 2. much much faster (really, really fast for most BI use cases) , BI 最关心 : 的是最近,即使是历史数据,也是会对一段时间多加分析。反正测试是很快 : 3. uniformed way to do stream/interactive/batch/sql/ML/graph calculation, 很 : 多你在interactive/batch弄的东西,直接就可以用到stream, 常见的就是interactive
|
c******o 发帖数: 1277 | 34 原来刚出来的时候很前卫, 大量利用内存缓存。
work set(不是一开始的data set)就可以在内存重复存取。现在已经比较普遍了。
我记得spark还大量利用了 scala的continuation 来对中间过程进行优化,可以在一定
情况skip 一些中间过程。
【在 n******t 的大作中提到】 : 您给说说spark为什么会快? : : interactive
|
z****e 发帖数: 54598 | 35 减少io操作
网络io速度尤其慢,wdong上面说的优化手段其实就是减少网络io
spark减少对硬盘的io操作,自然就快了
我知道你会问,为啥不增加l1l2 cache,那不是更快?
well,比起那种cache,内存增加是更有可能实现的目标不是?
虽然spark的东西没啥特别的,理论上很容易
但是这个东西是一个方向不是?有人做了并开源,总比自己去折腾强
我们懒汉就喜欢直接down轮子用
这种开源轮子一旦出现在市场上,效率做到一定程度
就预示着这个市场已经无利可图了,是时候转战下一个领域了
spark推开了一扇门,也同时关上了很多窗
【在 n******t 的大作中提到】 : 您给说说spark为什么会快? : : interactive
|
z****e 发帖数: 54598 | 36 具体的实现没功夫看
但是我看renjin也说用scala优化了操作过程
俺就assume他们说的是对的了,真没啥兴趣去阅读源代码
尤其还是scala代码
【在 c******o 的大作中提到】 : 原来刚出来的时候很前卫, 大量利用内存缓存。 : work set(不是一开始的data set)就可以在内存重复存取。现在已经比较普遍了。 : 我记得spark还大量利用了 scala的continuation 来对中间过程进行优化,可以在一定 : 情况skip 一些中间过程。
|
g*****g 发帖数: 34805 | 37 MapReduce本来就是做 IO bound的。你要做高维矩阵运算之类的,当然是hpc合适。
1000
【在 w***g 的大作中提到】 : 我觉得10台烂机器不如一台牛机器好使啊。我说的也不是啥HPC,现在主流的1U服务器 : ,128G内存+dual 6 core的服务器,再插上些1T的SSD或者4T的HDD,其实很能算一些东 : 西了。IBM那些所谓的超算,未必比Intel牛多少。机器越多通信成本就越高。别说1000 : 台,一个柜子撑死放50台机器,100台机器交换机之间的通信就成瓶颈了,就只能做带 : reduce的算法了。你用烂机器,也是一台机器占1U,用的差不多也是1份电,并行了以 : 后性能还要打折扣,其实得不偿失。
|
w***g 发帖数: 5958 | 38 你这个信息可真及时!mapr的hive-0.13 9月5日才放出,赶紧去装一下。
【在 c****e 的大作中提到】 : simple IO显不出来。HIVE用了0.13? HIVE实现stinger initiative以后,本来就快了 : 差不多50倍。Cloudera当时想放弃HIVE, 专心推Imapla现在也被迫回头了。 : Hortonworks给Windows提供HDInsight有点结盟的意思,微软贡献了SQL query : optimization到HIVE,还有column file compression format. 这些东西都加上去,和 : Spark差别没那么大。一般的逻辑处理,不是极端的算法,5倍到10倍撑死了。 : Spark除了RDD, 说到底是继承了Dryad的paper, 用operator做处理比纯粹的MR效率高很 : 多,再加上中间i/o不要都写到硬盘上,速度一下子上来了。HIVE stinger也是搬这一 : 套,普通的商业逻辑处理差别只会越来越小。 : 迭代的算法Spark优势会比较大,但是ML-Lib东西还比较少。没有用过,有用过的出来 : 说说perf吗?比如我跑个vowpal-wabbit会快多少倍?
|
c***d 发帖数: 996 | 39 你这个假设是gigaE 链接, 人家要玩cpu bound的并行计算可能就不是用gigaE了。 绝
大多数应用还是io bound.
1000
【在 w***g 的大作中提到】 : 我觉得10台烂机器不如一台牛机器好使啊。我说的也不是啥HPC,现在主流的1U服务器 : ,128G内存+dual 6 core的服务器,再插上些1T的SSD或者4T的HDD,其实很能算一些东 : 西了。IBM那些所谓的超算,未必比Intel牛多少。机器越多通信成本就越高。别说1000 : 台,一个柜子撑死放50台机器,100台机器交换机之间的通信就成瓶颈了,就只能做带 : reduce的算法了。你用烂机器,也是一台机器占1U,用的差不多也是1份电,并行了以 : 后性能还要打折扣,其实得不偿失。
|
w***g 发帖数: 5958 | 40 cpu bound的话就没事了。问题是大范围内存交换。一千台机器就是10 gigaE也扛不住
啊。我有个实际的问题,你要有好办法给推荐一下。我不要1000台,100台能下来就行。
【在 c***d 的大作中提到】 : 你这个假设是gigaE 链接, 人家要玩cpu bound的并行计算可能就不是用gigaE了。 绝 : 大多数应用还是io bound. : : 1000
|
|
|
c***d 发帖数: 996 | 41 啥问题阿。 以前低延迟的集群不都用myrinet或者infiniband连么。 你要多少
bandwidth, 什么样的延迟阿。
行。
【在 w***g 的大作中提到】 : cpu bound的话就没事了。问题是大范围内存交换。一千台机器就是10 gigaE也扛不住 : 啊。我有个实际的问题,你要有好办法给推荐一下。我不要1000台,100台能下来就行。
|
w***g 发帖数: 5958 | 42 myrinet多少年前的东西了,以前我管实验室设备的时候整出来n多myrinet卡,上一辈
人用PC机搭distributed shared memory机群用的,不知道扔也不是不扔也不是。
其实IT业就是几个循环,从内存到硬盘从硬盘到内存,从单机到机群从机群到单机。三
十年河东三十年河西短板轮流转。说不定要现在再搞个fault resilient的distributed
shared memory又能有新应用。
看了一眼目前最快的确实是infiniband。300Gbit/s。
【在 c***d 的大作中提到】 : 啥问题阿。 以前低延迟的集群不都用myrinet或者infiniband连么。 你要多少 : bandwidth, 什么样的延迟阿。 : : 行。
|
B*****g 发帖数: 34098 | 43 大牛讲讲用卡桑取代hdfs的理由
interactive
【在 c******o 的大作中提到】 : spark 不是 hadoop的竞争者。 : 是mapreduce的替代品。我们的stack就是hdfs+spark+aws s3,可能会用 Cassandra 替 : 代hdfs. : 对我们来说,hadoop (以前的BI系统),换成spark的好处有很多: : 1. unified system =》 成为真正的pipeline, easy to program, modern, and : reliable, less maintenance. : 2. much much faster (really, really fast for most BI use cases) , BI 最关心 : 的是最近,即使是历史数据,也是会对一段时间多加分析。反正测试是很快 : 3. uniformed way to do stream/interactive/batch/sql/ML/graph calculation, 很 : 多你在interactive/batch弄的东西,直接就可以用到stream, 常见的就是interactive
|
p*****2 发帖数: 21240 | 44 简单 简单 简单
【在 B*****g 的大作中提到】 : 大牛讲讲用卡桑取代hdfs的理由 : : interactive
|
f****3 发帖数: 77 | 45 想用JDBC之前可用shark,1.1之后spark sql应该也支持了。
好奇大牛的BI系统在换成了spark之后,有多少的perf提升,另外,spark查询的准确性
好想还是有些问题
interactive
【在 c******o 的大作中提到】 : spark 不是 hadoop的竞争者。 : 是mapreduce的替代品。我们的stack就是hdfs+spark+aws s3,可能会用 Cassandra 替 : 代hdfs. : 对我们来说,hadoop (以前的BI系统),换成spark的好处有很多: : 1. unified system =》 成为真正的pipeline, easy to program, modern, and : reliable, less maintenance. : 2. much much faster (really, really fast for most BI use cases) , BI 最关心 : 的是最近,即使是历史数据,也是会对一段时间多加分析。反正测试是很快 : 3. uniformed way to do stream/interactive/batch/sql/ML/graph calculation, 很 : 多你在interactive/batch弄的东西,直接就可以用到stream, 常见的就是interactive
|
d*******r 发帖数: 3299 | 46
distributed
被你说的, 好像搞时尚, 流行的款式循环着来 :D
【在 w***g 的大作中提到】 : myrinet多少年前的东西了,以前我管实验室设备的时候整出来n多myrinet卡,上一辈 : 人用PC机搭distributed shared memory机群用的,不知道扔也不是不扔也不是。 : 其实IT业就是几个循环,从内存到硬盘从硬盘到内存,从单机到机群从机群到单机。三 : 十年河东三十年河西短板轮流转。说不定要现在再搞个fault resilient的distributed : shared memory又能有新应用。 : 看了一眼目前最快的确实是infiniband。300Gbit/s。
|