Recently in ad Category

尝试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, 作为缺乏调优经验的我们,还是让等算法团队吃螃蟹吧...

在看广点通的页面代码,头部有个<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">

查了一下,发现这个是给IE浏览器用的, IE=Edge是IE请使用最新的渲染引擎, chrome=1是激活ChromeFrame 

不过Google已经停止支持Chrome Frame

所以只要IE=Edge就可以了

另外可以不用改代码

Nginx: (server区间内)

add_header "X-UA-Compatible" "IE=Edge";

参考文章:http://www.cnblogs.com/nidilzhang/archive/2010/01/09/1642887.html