June 2015 Archives

乌云安全

| No Comments | No TrackBacks

xss http://xss.pkav.net/xss/

wiki http://wiki.wooyun.org/

尝试spark

| No Comments | No TrackBacks

某个线上服务,访问量每天N亿, output种类异常丰富,依赖内部服务众多,出现问题的概率相对较大,故搞了某准实时分析系统,  用于分析性能和定(bu)位(bei)问(hei)题(guo)。

作为最接近DSL的优秀的prototype language, 我们开始是用PHP写了个多进程模型来跑, kafka传输数据,每分钟计算一次做归并, 速度基本可以满足需求。

跟广告算法团队沟通后, 某同学用scala重写了一遍,之后决定尝试下spark,然后悲催的发现在公司集群上的速度居然没有单机spark快, CPU稍微好点的机器上的PHP多进程也比它快....另外在公司集群上被高优先级任务干掉也是经常出现的...

讨论了下原因,似乎很简单。原始数据每分钟就没多少量,这个场景下并不是那么的合适,考虑了下数据分发并开始执行计算任务的时间,单机就计算的差不多了, 或许只有在做CF的时候才适合用hadoop/spark

我所了解的, spark作为目前被鼓吹的银弹,本质上是由于hadoop对计算的抽象不够,每一步都要落地到磁盘io上,导致在机器学习(比如ctr预估)这种需要多轮迭代的场景上,spark提供的RDD模型从理论上可以有效加速。但是实际工程上,作为一个工程技术人员,我们应该有足够的理智去看待一个所谓的灵丹妙药,技术选型的时候要看有那些feature但是更要了解disadvantage, 毕竟选型的本质是均衡和妥协。

以微博用户的量级做CF, hadoop和spark的scale out解决方案是必然, 但并不是优势。从spark的角度来看, MLLib目前还是属于占坑阶段, 典型的Berkeley风格, 比如线性代数的BLAS居然是fortran翻译的Java。另外,spark本身的参数调优也很重要,据说可以差一个数量级,尝试了不同版本的spark,速度明显有差异。

更为坑爹的是RDD,我们在尝试的时候经常就跑挂了,因为估算RDD几轮计算之后会变多大,spark在这块本质上是个糊涂账。

另外就是最近很火热的borg论文,离线和实时计算混跑的话题。spark在这块直接用的yarn,分配多少资源,task大小,分配速度,完成速度,这些只能靠经验来参数调优。这种QOS的事情spark直接回避掉了。而大家在优化参数的时候尽可能的会去压榨机器性能,但是CPU用满了,加上jvm的gc,会导致系统线程运行不流畅,甚至能触发heartbeat timeout的程度,最后触发fault safe,丢弃已经算了一半的任务,丢弃还能用的资源,还要再分配资源去重新去计算,给系统造成了更大的压力, 很多跑到最后跑挂掉的问题都是这样导致的。

结论: 作为一个scale out方案,如何保证效率,稳定性和可控才是最重要的, 对我们来说,spark还需要大量的人肉调优,算法参数和系统参数,在目前可预知的应用场景上,我团队用C++变相scale up来解决性能问题...至于spark, 作为缺乏调优经验的我们,还是让等算法团队吃螃蟹吧...

clink-gow

| No Comments | No TrackBacks

CLink - Bash Style Line Editing for cmd.exe 

Gow - Lightweight alternative to Cygwin

About this Archive

This page is an archive of entries from June 2015 listed from newest to oldest.

February 2015 is the previous archive.

March 2016 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.7