某个线上服务，访问量每天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, 作为缺乏调优经验的我们，还是让等算法团队吃螃蟹吧…
btw: 隔壁team在类似问题上原型是PHP单进程(sigh)，后来改用golang来解决的计算性能问题，我觉得这个选择其实是为了玩golang (逃
btw2: 好像databrick在尝试把计算过程的内存管理不再交给jvm而是像c一样管理，期望这个做好了能解决gc的麻烦
由 udpwork.com 聚合
|
评论: 0
|
要! 要! 即刻! Now!
