w********m
发帖数: 1137 | 1 搞startup一开始就是一个连EC2的SSH
最少要搭个demo出来，骗骗投资人吧
要搞java的话，估计只有到印度新德里搬运烙印，明年十月上班，谁能撑那么久
现在大部分大学毕业生都懂点python，注意--不是CS专业的
startup顺便拉个人就可以开工
以前的storm，shark也不是不好，太复杂了，没人会用
databricks的人从Berkeley出来的，知道现状，于是把spark上面的python搞好，到处
用ipython notebook作介绍，大家一看都会，马上火爆了。
到hdfs上查个log，没人愿意用java现写个类库。所以，现在的大趋势是java做轮子，
python用轮子。 |
|
w********m
发帖数: 1137 | 2 不是hadoop和spark的committer，没兴趣关心jvm。用轮子的真不觉得轮子怎么做很重
要。
测试过scala和python在spark上的表现，没觉得你说的后者比前者慢几十倍。主要瓶颈
是RDD到hdfs的IO，这跟语言有什么关系。
另外，spark上怎么用groovy。 |
|
|
|
c******o
发帖数: 1277 | 5 基本上我们和二爷的完全不一样。。。
kinesis + mesos + hdfs
二爷是
kafka + yarn + Cassandra
我们也在找办法用Cassandra. |
|
c******o
发帖数: 1277 | 6 我这个组做的不是游戏，是平台。
tracking/reward/payment/website/BI
我们用mongo做 tracking/reward， HDFS/C*做BI |
|
|
z****e
发帖数: 54598 | 8 为啥要jdbc connector？
你把nosql当db用了？
这个有些问题呀
spark那个没办法
新东西，问题总是多多
我用hdfs也有不少问题 |
|
z****e
发帖数: 54598 | 9 为啥要jdbc connector？
你把nosql当db用了？
这个有些问题呀
spark那个没办法
新东西，问题总是多多
我用hdfs也有不少问题 |
|
w***g
发帖数: 5958 | 10 weka有性能瓶颈。如果你一次训练的数据量要上10G，weka肯定就不行了。
还是scipy更靠谱点。至于数据库，如果是单机的话还不如直接存文件系统。
多机的用话用轮子确实是HDFS+spark比较靠谱。不图别的，就图能全都
load到内存里。如果虽然数据总量有200G，但是每次训练只有几G几十G，
还是单机更靠谱。
上集群都是没办法才上的，如果买台好点的机器可以满足需求，就不要上
集群。Hadoop啥的都是没办法的办法。 |
|
o******1
发帖数: 1046 | 11 多谢回复！
是不是我原先把mapper数理解错了？这里mapper数是不同mapper function的个数，不
是执行map method的计算单元的个数。其实我就一个hdfs file，但是可以很大，会存
在不同的datanode上。
我想问的是如何设置processor数目（类似mpi里调用MPI_Comm_size函数得到的process
count），或者core的个数因为现在的processor都是多核的，或者也许是node数如果
hadoop不能设置到处理器的话。总之是想设置最小的可设置的计算单元，看看程序的
scalability with # of processes(or cores or nodes)，1个计算单元需要多少时间
，2个4个8个16个...各自需要多少计算时间。这个改怎么设置呢？
谢谢！
input |
|
o******1
发帖数: 1046 | 12 在与hard drive并行i/o的时候用mapper没问题。但是还有其它的需要啊，比如说node
i想送一段数据给node j，mapreduce唯一的办法就是node i写到hdfs上，然后node j再
去读。如果允许节点间的直接数据传输，是内存进网络再进内存，省去了硬盘的读写，
效率肯定更高啊。
tasks. |
|
|
v*****r
发帖数: 2325 | 14 spark beginner trying out the buzz tech
input 200GB uncompressed data file stored in hdfs
37 worker nodes, each has 24 cores
using java map reduce, 6-8 minutes
using spark, 37 minutes, 2 18 minute-stage
"lightning fast cluster computing, 100x faster" ???!!!!
Big bulls please advise!
#sortMapper sort values for each key, then do some iteration for the grouped
values
text = sc.textFile(input,1776) #24*37*2
text.map(mapper).filter(lambda x: x!=None).groupByKey().map(sortMapper).
filter(lambda x: x... 阅读全帖 |
|
z****e
发帖数: 54598 | 15 除了spark以外，其他的选择比较少
都是legacy了
要么就是python的scipy这些
要么就是java的weka这些
这两个都不是针对分布式设计的
多数都是单结点计算
而且你要自己去处理跟hdfs的接口之类的
很麻烦
目前看，比较合适的framework就是spark
当然spark上面的libs还很少，目前只有mllib
你要想做其他的，需要你自己去实现 |
|
z****e
发帖数: 54598 | 16 spark还要求你安装python的东西呢
你前面不是说java压根没用么？
spark和hdfs是啥？
,
need |
|
z****e
发帖数: 54598 | 17 所以说一堆人就是嘴巴上吹牛可以
扯蛋什么fp之类的在行
真遇到问题，还是要看java党怎么搞
r看spark r
http://amplab-extras.github.io/SparkR-pkg/
目前做到的是可以从r里面call spark的func
spark有了，你自然就可以搞hdfs了
deep learning你要自己实现
spark目前还没有这个lib
但是r有不少统计库，你可以用
however
你要小心，r的io狠蛋疼，经常全部读入内存
big data这样搞内存直接爆了
所以说r目前只是一个toy，你别太当真
另外jvm上的renjin你也可以看看，但是离开下放prod还有很久的距离 |
|
|
w***g
发帖数: 5958 | 19 hadoop的mapreduce已经过气了。但是HDFS, Yarn以及上面的各种东西像hive, spark之
类的几年内不会过气。 |
|
z****e
发帖数: 54598 | 20 需要汇总数据，所以用vert.x比较容易解决这个需求
其他server的话，汇总数据要自己写，bus要自己建，vert.x自己就有bus
可以直接用
然后latency这个需求，这个用异步可以很容易解决
看看rxjava的subscribe，把你需要callback的部分放到subscribe中去就好了
这样一旦建模完成就可以callback回来，然后你要怎么弄就怎么弄了
唯一的问题是这两个刚做出来没多久，可以参考的文档不多
不过本身你这个需求就比较另类，没有太多的轮子可以直接用
所以如果不怕文档少的话，就放手做吧
spark用起来比vertx麻烦不少，而且spark主要是建模容易
跟hdfs等数据源的接口比较容易做
如果你是自己建模的话，不用spark也没啥大不了的
做吧
N |
|
w**z
发帖数: 8232 | 21 和hadoop integrate 容易， 都是hdfs |
|
z****e
发帖数: 54598 | 22
打好包就行了
你说的慢主要是并行上的优化处理
r什么都不管，一甩手掌柜，不管内存不管硬盘不管网络
自然慢，傻瓜是足够傻瓜了
关键是现在分布式的persistence主要是建立在hdfs这些基础之上
其实只要存储的这些定下来，很多优化都有办法做
关键是这些东西变来变去，导致经常要改，所以很多傻瓜化的工具就比较少
当然你要说简单容易，自然还是r这些容易
最理想的就是在hadoop eco上建r engine这些
但是目前这些东西都还只是一个概念或者prototype
没有十年左右的发展，估计没戏，当然也正是因为这块没啥东东
所以机会才多 |
|
z****e
发帖数: 54598 | 23 我的感觉基本上整个欧洲的学术界的工具都在往scala上转移
我们这边跟欧洲关系远比美帝的关系要密切得多
绝大多数叫兽都是欧洲人，可以明显感觉到，scala的火热
不管做啥，只要欧洲来的叫兽坐阵，语言你就得用scala
尤其是big data相关的东西，都是scala，当然这个刚开始做没多久
很多工具肯定不如那些几十年做下来的傻瓜容易，比如r
但是这个是future，现在统计应用就是big data上需要嘛
你问的线性代数估计就是相似度判断，vsm那些东西
用scala，spark这些吧，包括hdfs什么都是你可能会用到的工具
看了你的主贴还在扯蛋数值计算的基本上都是不懂big data的 |
|
u*******g
发帖数: 224 | 24 我是生物转行做 data warehouse的。 一直在自学。 现在想请教大牛们下一步学习的
priority – 多谢啦。
Option 1: 拿 Hadoop certificate。已经跟着一个online 课程学完了。 理解 HDFS,
MapReduce etc. 但是要拿到certificate， 还得好好读那本definite guide的书， 多
写MapReduce Java codes 等等。
Option 2: 学 coursera 的那个data science系列的课. 课程包括 R,Statistical
Inference, Machine Learning 等等.
我的背景： 有个十年前的CS master. 生物研究中也有用machine learning 的tools。
会一点点R。 也有一些统计背景。
我的理解是hadoop提供海量数据分析的复杂平台。 那在时间有限的情况下， 先学搭建
这个平台呢， 还是数据分析（data science）?
多谢建议。 |
|
|
S***w
发帖数: 1014 | 26 F的message设计，类似hdfs
有一个Directory, 当master
有n个data nodes
我的理解是
用户被分到其中data nodes中.
这个信息存在directory中
当发信给user_id， 要做
1. 连接directory service, 查找user_id的node
2. 把信存到user_id@node的记录里
有个问题
directory service 需要内存
假设1.5B user, 每个mapping 用10 byte
15B byte = 15G 内存
但是这么多request都到了directory service,
只是读还好， 可以load balancer
但是写怎么办
这里需要一个 concurrent hashmap,
lock, etc
性能总有限制啊? |
|
z****e
发帖数: 54598 | 27 可能hdfs也值得带走吧
hbase就算了吧，不太想用
postgre+cassandra+flink
应该可以满足绝大多数需要了
flink可以替换掉yarn, spark, storm & hdmr
cassandra，postgre可以替换掉hbase，mongo
剩下的交给vert.x
酱紫大概用4-5个框架，就可以解决几乎所有目前已知需求
sql/db, nosql/batch, streaming, script, web, web service, thread pool etc.
如果将来有一个vert.x based & flink-like system
而非akka based systems(spark&flink)
那就是一个终极解决方案，要有人这么搞就太好了
话说nosql真麻烦啊
一般db的话，一个jdbc就搞掂了，顶多说异步的话，需要启一个worker
但是nosql还要折腾mr，yarn, spark, flink这些，麻烦不少 |
|
|
z****e
发帖数: 54598 | 29
你说的是zookeeper吗？
如果你需要zookeeper的话，那就单独剥离出来用吧
hadoop主要是hdfs, hdmr, yarn这些，我觉得这几个好像没啥必要的
这几个我都不用，目前还没遇到啥问题 |
|
|
w***g
发帖数: 5958 | 31 确实是这样。spark程序可以用yarn或者mesos调度，也可以啥都不用裸跑。
spark本身是链接hadoop库的，但背后不一定需要读写dfs://...，可以读写
本地数据，C*或者s3啥的。但是高性能读写大量数据我觉得最好的还是dfs。
因为输入数据往往远大于输出数据，所以输入数据最好也存在dfs上。
最终计算的结果直接写入C*或者s3啥的，可以省掉来回倒腾。
我手里的生产系统用的是yarn调度，因为反正要用hadoop。不过机器比较少，
也没啥调度可言，基本上一个app跑上去内存就用满了，都是独占模式。
我没用hadoop/spark读过C*或者s3。我怀疑C*的读写性能会远差于HDFS。
希望用过的同学过来说说。（上面我有帖子说C*性能比HBase好，那个context
不一样，是说当数据库用的性能) |
|
N*****m
发帖数: 42603 | 32 是的，主要还是看应用
比如，如果用spark stream，基本上没必要hdfs/hadoop |
|
p*****2
发帖数: 21240 | 33 hdfs有locality 性能是最好的
c需要加一个ring专门做分析 不然性能影响很大 |
|
S*******e
发帖数: 525 | 34 不用yarn/mesos, how can you run two or more jobs at the same time?
我有一个项目用standalone （over hdfs)，我把20个“jobs" 放在一个进程，不是很
好，但勉强能工作。 我另外一个ETL项目， 有260 jobs，无法这么做。 |
|
z****e
发帖数: 54598 | 35
yarn主要是给hadoop/hdfs用的
c*我没用过yarn
对于c*来说，yarn不是必需的，甚至我觉得是多余的
etl这种多半是streaming的事
你可以通过storm什么来搞
而且java有的是处理并发的api啥的
你自己写一个也不难啊
job调度我通过vert.x来搞
多线程，异步什么能搞很多东西 |
|
f*******t
发帖数: 7549 | 36 不用啊，hdfs默认复制3份，replication factor甚至可以设成1 |
|
z*******3
发帖数: 13709 | 37
你用的log方式落伍了，直接上cassandra，把log丢到c*里面去
虽然涉及了io，但是会好很多，多数nosql最初的例子都是用来存log
log4j什么都太慢了，如果要用async，上worker
所有log通过bus发送给worker，然后由worker写入c*或者hdfs
反正log都是immutable，通过bus传输无压力
也可以通过shared object来发送 |
|
z*******3
发帖数: 13709 | 38
用swift伪码来解释就是
dispatch_async(queue){
//task 1 -> update b/c&update a
}
dispatch_async(queue){
//task 2 -> update b/c&update a
}
dispatch_async(queue){
//task 3 -> update b/c&update a
}
这三个tasks结束的顺序可能是213, 123或者其他什么
然后存a=b+c的时候，一个task需要存两次
一次存b/c，一次存a
当某个task update b/c之后，还没update a的时候，那么完成的b和c的任务总数会等
于a+1
同时，当某两个tasks同时update a的时候，两个都取到a，然后两个都+1之后再update
最后的结果就不是a+2，而是a+1
数据库常见的读写lock，什么dirty read之类的并发问题
用transaction可以搞定，如果是hdfs的话，用zookeeper，如果是内存的话
用java.util.concurrency，如果是vert.x的话，用worker t... 阅读全帖 |
|
|
z*******3
发帖数: 13709 | 40 过时是不会的
就像db，你觉得db过时了吗？
没有嘛，到处都还在用
这种nosql以及处理nosql的frameworks
现在还在大面积使用，但是市场上将来会有更多的竞争者加入
也很正常，java世界就是这样，里面什么都有
是不是很好玩？ |
|
z*******3
发帖数: 13709 | 41 akka和hadoop给我的感觉就像当年的ejb一样复杂难懂
各种乱七八糟的概念满天飞，好像很fashion，其实也就是那么一回事
相比之下，vert.x，c*的哲学我很喜欢
不跟你扯概念，扯理论，从最简单的入手，慢慢作难起来
还有就是hadoop是一个很大的eco，应该具体问题具体分析
hadoop mapreduce就已经被取代了，虽然over yarn还是很多人用
但是这个就犹如隔靴扰痒痒，很不爽的说
其实很多frameworks都太复杂了，包括akka
一些很简单的概念，被说得复杂异常
从历史上看，simplicity always wins
更不要说新生代的东西，更加兼容
就比如ap可以tune成cp，反过来就不行，那显然ap系统前景广阔
同样的，vert.x可以当akka&node用，反过来就不行
这就是区别，简单是一回事，兼容性是另外一回事
一般这两个方面同时占据上风的话，后面就很容易想了
其他的，gradle对于maven也是如此，android studio就用了gradle，而非maven
简单不仅仅是对于用户是种需求，对于开发人员同样也是需求 |
|
f******2
发帖数: 2455 | 42 赵老师你在澳大利亚？（怎么感觉时间不对呀？）你这个经验的在湾区随便出去转一圈
儿就能收3～5个30万的offer，没考虑动动？ |
|
l*******m
发帖数: 1096 | 43 30万对于有经验的实在太一般了吧，再说澳洲工资也很高 |
|
z*******3
发帖数: 13709 | 44 spark的streaming的对比看这个slides
http://www.slideshare.net/ptgoetz/apache-storm-vs-spark-streami
flink还没推出，但是从设计上看，应该不会有类似的问题
我感觉最近streaming的需求越来越强烈
需要一个针对前后端都能够搞streaming的东东
vert.x是一个很不错的选择，但是vert.x对付c*之类的nosql，还显得工具偏少
另外mllib这些lib目前只能host在spark,flink这些上面，vert.x还缺少类似的libs
vert.x毕竟更为general一些，但其实你自己琢磨琢磨也没啥难的
无非那么一回事了，mapreduce那些api，跟rxjava有很大重叠
可以用rxjava实现一遍，主要是算法，mllib部分，clustering，svm etc.
api的话，什么flatmap，streaming之类的rx都有了，vert.x成熟之后大有可为
vert.x, rxjava, flink这些逐步走向成熟，过程值得学习和参考
当然spark之类已经取得巨大成功的更值得... 阅读全帖 |
|
z*******3
发帖数: 13709 | 45
其实不发散，server内存计算从来都是一大块
不管用来做mllib还是用来搞游戏server
persistence未必算，但是mllib这些从本质上说就应该归类到内存运算中去
spark就强调内存计算而非存储嘛，就离一般的vert.x做的那些很近了
这个你看db历史就知道，最早server那些都被认为是db的映射
后来ejb什么出来改变了这个局面，现在nosql也是如此
最早都被认为是hdfs等的映射，现在慢慢脱离这个依赖 |
|
z*******3
发帖数: 13709 | 46
目前能够提供比较reliable的，适合streaming处理的datasource只有kafka
其他都不行，要自己对付丢包等问题，hdfs等persistence基本上batch够用了
streaming主要来自living server提供的数据，比如网络，bus这种publish的data |
|
z*******3
发帖数: 13709 | 47 一般streaming的datasource都是kafka之类的
或者是web service，jms这些
hdfs等persistence不太强调streaming |
|
z*******3
发帖数: 13709 | 48
nosql目前api什么都不统一，你用什么都会被产品所lockin
稍微好一点的话，那就用hdfs和c*吧
db部分比较统一，有jdbc和jpa可以防lockin
所以你可以用Amazon RDS来替代s3 |
|
|
z*******3
发帖数: 13709 | 50 因为rdbms的格式远比nosql的格式要工整许多
table，column什么都很工整，都是structured data
数据工整了，自然可以把很多操作傻瓜起来
就不需要high order functions你也可以通过一些脚本做出你需要的运算
比如简单的crud，一些aggregation
一开始连工整的数据都没搞定的时候，没功夫思考不工整的数据怎么搞
但是nosql的数据格式很混乱，经常需要处理数据，所以需要更general的工具
而这种工具你事先并不知道用户会输入什么样的func
所以需要一种方式能够把函数当成参数来输入
来处理数据然后反馈给用户
hadoop没有做到spark纯粹是因为hadoop忙着解决hdfs的事情了
你要做出这种系统来，首先第一步先用一个统一的接口封装所有的file system
至于hdmr，没想那么复杂，因为第一步已经够麻烦的了
然后spark的作者觉得，这里有提升的空间，所以就搞出了spark
同样的，spark的batch做得不错，但是至于streaming，没想那么多
所以flink出来说，诶，你这个streaming做得不行，我能够做得更... 阅读全帖 |
|
