l******n 发帖数: 9344 | 1 有些数据想要用spark处理,都是sensor 数据,每分钟有72m数据,一年大概37T左右。
主要就是parse data,然后放到数据库。
现在的process一个9台机器的cluster,360g memory要半年才能处理完。我现在要加速
这个处理过程,哪位给点下手的方向
谢谢 |
e*******o 发帖数: 4654 | |
c*********e 发帖数: 16335 | 3 整天就是用别人写的工具,这和用microsoft office有什么区别?
【在 l******n 的大作中提到】 : 有些数据想要用spark处理,都是sensor 数据,每分钟有72m数据,一年大概37T左右。 : 主要就是parse data,然后放到数据库。 : 现在的process一个9台机器的cluster,360g memory要半年才能处理完。我现在要加速 : 这个处理过程,哪位给点下手的方向 : 谢谢
|
l******n 发帖数: 9344 | 4 这个parser是一个consultant写的,CTO告诉我速度很快, 我一听这么牛逼,怎么还慢
得一塌糊涂
而且马上要deploy到客户哪里,怕没有时间重新写了
【在 e*******o 的大作中提到】 : 难道不是应该首先优化你的parser?
|
l******n 发帖数: 9344 | 5 别人的工具?都是我们自己的东西,哪里来的别人的工具?你不会说spark?这个没几
个能自己写一个
【在 c*********e 的大作中提到】 : 整天就是用别人写的工具,这和用microsoft office有什么区别?
|
e*******o 发帖数: 4654 | 6 spark没用过 感觉你这个就是要并行一下
我觉得每分钟几十m的data 单机应该能搞定
你单机多少个核 并行一下 看能否搞得定 不行再考虑spark
【在 l******n 的大作中提到】 : 这个parser是一个consultant写的,CTO告诉我速度很快, 我一听这么牛逼,怎么还慢 : 得一塌糊涂 : 而且马上要deploy到客户哪里,怕没有时间重新写了
|
d****n 发帖数: 12461 | 7 花500租个aws一星期估计能搞定?
【在 l******n 的大作中提到】 : 有些数据想要用spark处理,都是sensor 数据,每分钟有72m数据,一年大概37T左右。 : 主要就是parse data,然后放到数据库。 : 现在的process一个9台机器的cluster,360g memory要半年才能处理完。我现在要加速 : 这个处理过程,哪位给点下手的方向 : 谢谢
|
l******n 发帖数: 9344 | 8 客户数据要放到aws上去,第一程序很复杂,第二需要加密解密和load,现在公司网络
也不给力,也是非常慢的一个过程
【在 d****n 的大作中提到】 : 花500租个aws一星期估计能搞定?
|
l******n 发帖数: 9344 | 9 cto告诉我已经并行了,不知道那些consultant干了些啥
【在 e*******o 的大作中提到】 : spark没用过 感觉你这个就是要并行一下 : 我觉得每分钟几十m的data 单机应该能搞定 : 你单机多少个核 并行一下 看能否搞得定 不行再考虑spark
|
l******n 发帖数: 9344 | 10 我们自己的colo 6k一个月
【在 d****n 的大作中提到】 : 花500租个aws一星期估计能搞定?
|
|
|
w***g 发帖数: 5958 | 11 你是要parse 37T数据用半年吧? 这么大量的数据处理一般瓶颈都在I/O.
你确定一下数据有没有fully distributed, 随便挑一台机器用iostat
看看磁盘I/O是不是用足了.
9台机器每台接4个4T硬盘, 一共9 * 4 * 4 = 144T, 差不多刚好一年的数据
三倍冗余的样子. 吞吐量是 9 * 4 * 100M = 3.5G/s,
全速读37T数据的话3个小时. 算上各种overhead, 我觉得两天也应该算出来了.
我这边colo, 9台机器 $500/月. AWS太贵, 特别是要大规模存储的,
光存储开销每月就不止$1000了, 而且还没法自己优化I/O. 不过要是自己
做不了/不愿意做sysadmin, 那这些开销还不如雇人的零头.
如果三星的16T SSD能降点价, 应该对你们非常有用.
【在 l******n 的大作中提到】 : 有些数据想要用spark处理,都是sensor 数据,每分钟有72m数据,一年大概37T左右。 : 主要就是parse data,然后放到数据库。 : 现在的process一个9台机器的cluster,360g memory要半年才能处理完。我现在要加速 : 这个处理过程,哪位给点下手的方向 : 谢谢
|
w****w 发帖数: 521 | 12 每分钟72MB没多少吧?我现在每秒钟处理4GB放到greenplum,俩台机器32个job同时跑,
没压力。 |
e*******o 发帖数: 4654 | 13 楼主应该找wdong 这样的当CTO。
这种问题,关键地方找人看一下,就大不一样。
【在 w***g 的大作中提到】 : 你是要parse 37T数据用半年吧? 这么大量的数据处理一般瓶颈都在I/O. : 你确定一下数据有没有fully distributed, 随便挑一台机器用iostat : 看看磁盘I/O是不是用足了. : 9台机器每台接4个4T硬盘, 一共9 * 4 * 4 = 144T, 差不多刚好一年的数据 : 三倍冗余的样子. 吞吐量是 9 * 4 * 100M = 3.5G/s, : 全速读37T数据的话3个小时. 算上各种overhead, 我觉得两天也应该算出来了. : 我这边colo, 9台机器 $500/月. AWS太贵, 特别是要大规模存储的, : 光存储开销每月就不止$1000了, 而且还没法自己优化I/O. 不过要是自己 : 做不了/不愿意做sysadmin, 那这些开销还不如雇人的零头. : 如果三星的16T SSD能降点价, 应该对你们非常有用.
|
l******n 发帖数: 9344 | 14 主要瓶颈实在i/o
【在 w***g 的大作中提到】 : 你是要parse 37T数据用半年吧? 这么大量的数据处理一般瓶颈都在I/O. : 你确定一下数据有没有fully distributed, 随便挑一台机器用iostat : 看看磁盘I/O是不是用足了. : 9台机器每台接4个4T硬盘, 一共9 * 4 * 4 = 144T, 差不多刚好一年的数据 : 三倍冗余的样子. 吞吐量是 9 * 4 * 100M = 3.5G/s, : 全速读37T数据的话3个小时. 算上各种overhead, 我觉得两天也应该算出来了. : 我这边colo, 9台机器 $500/月. AWS太贵, 特别是要大规模存储的, : 光存储开销每月就不止$1000了, 而且还没法自己优化I/O. 不过要是自己 : 做不了/不愿意做sysadmin, 那这些开销还不如雇人的零头. : 如果三星的16T SSD能降点价, 应该对你们非常有用.
|
l******n 发帖数: 9344 | 15 cto是个50来岁的离婚老美,比较会忽悠,很能侃,技术能力趋近于0,被consultant随
便忽悠。。。
我可以内推公司职位swe,我们在南家,小公司,人少,做工业大数据,ceo sales 能
力还是很强的。seed fund valuation 10m,可能会1-2内卖掉。有意思的联系我。
近期还需要一些contractor,如果有同学想挣点外快,请联系我。
做backend,kafka, spark, cassandra, memsql都用。C++/java, python主要工具
【在 e*******o 的大作中提到】 : 楼主应该找wdong 这样的当CTO。 : 这种问题,关键地方找人看一下,就大不一样。
|
N*****m 发帖数: 42603 | 16 必须是local吗?
【在 l******n 的大作中提到】 : cto是个50来岁的离婚老美,比较会忽悠,很能侃,技术能力趋近于0,被consultant随 : 便忽悠。。。 : 我可以内推公司职位swe,我们在南家,小公司,人少,做工业大数据,ceo sales 能 : 力还是很强的。seed fund valuation 10m,可能会1-2内卖掉。有意思的联系我。 : 近期还需要一些contractor,如果有同学想挣点外快,请联系我。 : 做backend,kafka, spark, cassandra, memsql都用。C++/java, python主要工具
|
w***g 发帖数: 5958 | 17 我猜楼主是咽不下给consultant擦屁股还要让他们拿credit的气.
不然优化这种东西还不是分分钟的事情. 先把问题暴露出来大家
都看到了, 然后再fix, 这样楼主就有功劳了.
这种CEO其实很好. 你要能力强得到了他得信任, 那就是真得信任.
不像那些半懂的, 非要你按他的技术方案来.
【在 l******n 的大作中提到】 : 主要瓶颈实在i/o
|
w***g 发帖数: 5958 | 18 对不起看错了. 原来不是CEO是CTO. 这个就郁闷了.
自己技术差还得防着手下人...
【在 w***g 的大作中提到】 : 我猜楼主是咽不下给consultant擦屁股还要让他们拿credit的气. : 不然优化这种东西还不是分分钟的事情. 先把问题暴露出来大家 : 都看到了, 然后再fix, 这样楼主就有功劳了. : 这种CEO其实很好. 你要能力强得到了他得信任, 那就是真得信任. : 不像那些半懂的, 非要你按他的技术方案来.
|
l******n 发帖数: 9344 | 19 ceo和board现在也都意识到问题,在改变。
到一月份就要让这几个consultant走人
【在 w***g 的大作中提到】 : 我猜楼主是咽不下给consultant擦屁股还要让他们拿credit的气. : 不然优化这种东西还不是分分钟的事情. 先把问题暴露出来大家 : 都看到了, 然后再fix, 这样楼主就有功劳了. : 这种CEO其实很好. 你要能力强得到了他得信任, 那就是真得信任. : 不像那些半懂的, 非要你按他的技术方案来.
|
S***s 发帖数: 104 | 20 这个级别的数据绝对不需要半年啊
平时就应该往kafka里送,然后放hbase, hive, hdfs,s3之类
要集中batch处理只能多开node了
【在 l******n 的大作中提到】 : 有些数据想要用spark处理,都是sensor 数据,每分钟有72m数据,一年大概37T左右。 : 主要就是parse data,然后放到数据库。 : 现在的process一个9台机器的cluster,360g memory要半年才能处理完。我现在要加速 : 这个处理过程,哪位给点下手的方向 : 谢谢
|
|
|
S***s 发帖数: 104 | 21 没球用,好点靠谱的有大数据处理经验的人不好找,至少200k起
找到了,尤其是consultant,人看你不懂行还不把你当猴玩
【在 l******n 的大作中提到】 : ceo和board现在也都意识到问题,在改变。 : 到一月份就要让这几个consultant走人
|
S***s 发帖数: 104 | 22 9台机器的cluster搞毛,大job都是弄aws搞上百node跑
【在 w***g 的大作中提到】 : 你是要parse 37T数据用半年吧? 这么大量的数据处理一般瓶颈都在I/O. : 你确定一下数据有没有fully distributed, 随便挑一台机器用iostat : 看看磁盘I/O是不是用足了. : 9台机器每台接4个4T硬盘, 一共9 * 4 * 4 = 144T, 差不多刚好一年的数据 : 三倍冗余的样子. 吞吐量是 9 * 4 * 100M = 3.5G/s, : 全速读37T数据的话3个小时. 算上各种overhead, 我觉得两天也应该算出来了. : 我这边colo, 9台机器 $500/月. AWS太贵, 特别是要大规模存储的, : 光存储开销每月就不止$1000了, 而且还没法自己优化I/O. 不过要是自己 : 做不了/不愿意做sysadmin, 那这些开销还不如雇人的零头. : 如果三星的16T SSD能降点价, 应该对你们非常有用.
|
l******n 发帖数: 9344 | 23 这个是历史数据,包含50个sensor,还有一个客户有500个sensor的数据要migrate
【在 S***s 的大作中提到】 : 这个级别的数据绝对不需要半年啊 : 平时就应该往kafka里送,然后放hbase, hive, hdfs,s3之类 : 要集中batch处理只能多开node了
|
l******n 发帖数: 9344 | 24 我们客户数据全在colo,不能上aws,这个没有办法
自己建info,很花钱的
【在 S***s 的大作中提到】 : 9台机器的cluster搞毛,大job都是弄aws搞上百node跑
|
S***s 发帖数: 104 | 25 先拿sample数据写好处理程序
然后把数据全部拷贝到s3,开emr crank it.
【在 l******n 的大作中提到】 : 这个是历史数据,包含50个sensor,还有一个客户有500个sensor的数据要migrate
|
S***s 发帖数: 104 | 26 如果不是什么硬的限制,应该说服取消这个限制
aws的好处就在这个地方
【在 l******n 的大作中提到】 : 我们客户数据全在colo,不能上aws,这个没有办法 : 自己建info,很花钱的
|
l******n 发帖数: 9344 | 27 行业限制,现阶段不可能,就别考虑这个了
【在 S***s 的大作中提到】 : 如果不是什么硬的限制,应该说服取消这个限制 : aws的好处就在这个地方
|
w***g 发帖数: 5958 | 28 用s3的话, 他的9台机器配好了确实能顶emr上的100台.
【在 S***s 的大作中提到】 : 先拿sample数据写好处理程序 : 然后把数据全部拷贝到s3,开emr crank it.
|
c*********e 发帖数: 16335 | 29 很多cto其实是外行,狗屁都不是。公司里这种人太多了,都见怪不怪了,哈哈。
【在 w***g 的大作中提到】 : 对不起看错了. 原来不是CEO是CTO. 这个就郁闷了. : 自己技术差还得防着手下人...
|
c*********e 发帖数: 16335 | 30 同意,s3就是搞这个的。
【在 w***g 的大作中提到】 : 用s3的话, 他的9台机器配好了确实能顶emr上的100台.
|
|
|
w********m 发帖数: 1137 | 31 个人经验,sensor数据很多是重复的
去重一下,会小很多 |
w***g 发帖数: 5958 | 32 如果是text, 上一个快点的压缩算法可能比自己写code好.
没有查hdfs/spark是不是支持snappy. 我上次玩的时候,
gzip/deflate啥的还是有点太占CPU.
【在 w********m 的大作中提到】 : 个人经验,sensor数据很多是重复的 : 去重一下,会小很多
|
l******n 发帖数: 9344 | 33 binary
【在 w***g 的大作中提到】 : 如果是text, 上一个快点的压缩算法可能比自己写code好. : 没有查hdfs/spark是不是支持snappy. 我上次玩的时候, : gzip/deflate啥的还是有点太占CPU.
|
w***g 发帖数: 5958 | 34 binary通用压缩算法就没用了. 可以去草了.
【在 l******n 的大作中提到】 : binary
|
p***o 发帖数: 1252 | 35 其实binary还是text无所谓, 这种sensor数据大量重复的pattern, LZ系列的都好用。
【在 w***g 的大作中提到】 : binary通用压缩算法就没用了. 可以去草了.
|
l*******m 发帖数: 1096 | 36 在JVM慢的程序很多都是new 太多的objects造成的, 差别能有几十倍。改进就是reuse
,做一个object pool
【在 l******n 的大作中提到】 : 有些数据想要用spark处理,都是sensor 数据,每分钟有72m数据,一年大概37T左右。 : 主要就是parse data,然后放到数据库。 : 现在的process一个9台机器的cluster,360g memory要半年才能处理完。我现在要加速 : 这个处理过程,哪位给点下手的方向 : 谢谢
|
d****n 发帖数: 12461 | 37 看来我满足90%
【在 l******n 的大作中提到】 : cto是个50来岁的离婚老美,比较会忽悠,很能侃,技术能力趋近于0,被consultant随 : 便忽悠。。。 : 我可以内推公司职位swe,我们在南家,小公司,人少,做工业大数据,ceo sales 能 : 力还是很强的。seed fund valuation 10m,可能会1-2内卖掉。有意思的联系我。 : 近期还需要一些contractor,如果有同学想挣点外快,请联系我。 : 做backend,kafka, spark, cassandra, memsql都用。C++/java, python主要工具
|
d****n 发帖数: 12461 | 38 其实你这个量根本不算啥,瓶颈在两个方面:
1. parse数据从binary到text,其实可能是无用功
2. 放到数据库里面,瓶颈在数据库写上面
其实做sensor data,有一个用c*的例子,不知道你看了没有,就是把数据按照一定的
地理位置和时间分段以后写成一条记录,一条记录里面记录的可能是60秒甚至5分钟内
的全部数据。因为c*列可以扩展,所以可以一条记录有30个记录点,一条记录有200个
记录点。
如果是rdbms,那样就得看看到底是写多读少还是写少读多,然后具体案例具体分析。
【在 l******n 的大作中提到】 : 有些数据想要用spark处理,都是sensor 数据,每分钟有72m数据,一年大概37T左右。 : 主要就是parse data,然后放到数据库。 : 现在的process一个9台机器的cluster,360g memory要半年才能处理完。我现在要加速 : 这个处理过程,哪位给点下手的方向 : 谢谢
|
a*****s 发帖数: 1121 | 39 单从你的数据量上看,九个节点已经不错了。aws上的都是VM instance,100个不一定
有你的9个物理机器快。
wdong分析的很到位,个人感觉你的程序需要并行,spark有两级并行,选择executor的
数量,然后,选择每个executor上多少parallelism,spark prefer 大内存fat node,
如果你的机器内存不大, 恐怕效果一般,跟写mapreduce相差不多(你只是parsing),
如果可能,用SSD替换硬盘,加大内存。检查网络速度,是10GE还是1GE,压缩你的数据
(HDFS支持snappy)
用AWS从S3到本地HDFS就把你时间耗去大半,不划算。
光spark的tuning就有很多可做的,而且用spark的目的也就是为了并行。
楼主贴些详细信息,大家也可以帮你分析分析 |
a*****s 发帖数: 1121 | 40 放HBASE上,写速度还行10ms/ops level,基本上可以赶上in memory database
【在 d****n 的大作中提到】 : 其实你这个量根本不算啥,瓶颈在两个方面: : 1. parse数据从binary到text,其实可能是无用功 : 2. 放到数据库里面,瓶颈在数据库写上面 : 其实做sensor data,有一个用c*的例子,不知道你看了没有,就是把数据按照一定的 : 地理位置和时间分段以后写成一条记录,一条记录里面记录的可能是60秒甚至5分钟内 : 的全部数据。因为c*列可以扩展,所以可以一条记录有30个记录点,一条记录有200个 : 记录点。 : 如果是rdbms,那样就得看看到底是写多读少还是写少读多,然后具体案例具体分析。
|
|
|
B*****g 发帖数: 34098 | 41 要远程打酱油的吗?
【在 l******n 的大作中提到】 : 有些数据想要用spark处理,都是sensor 数据,每分钟有72m数据,一年大概37T左右。 : 主要就是parse data,然后放到数据库。 : 现在的process一个9台机器的cluster,360g memory要半年才能处理完。我现在要加速 : 这个处理过程,哪位给点下手的方向 : 谢谢
|
n*******0 发帖数: 2002 | 42 找个会调优的线帮你把参数和jvm啥的调明白吧。一分钟72MB只是parse的话肯定用不到
9个node那样的cluster。
【在 l******n 的大作中提到】 : 有些数据想要用spark处理,都是sensor 数据,每分钟有72m数据,一年大概37T左右。 : 主要就是parse data,然后放到数据库。 : 现在的process一个9台机器的cluster,360g memory要半年才能处理完。我现在要加速 : 这个处理过程,哪位给点下手的方向 : 谢谢
|