背景
去年10月,我们(去哪网)在 Mesos 资源管理框架上实现了 Spark 1.5.2 版本的运行。Spark 版本更新后又对其进行了小升级,沿用之前修改过的代码重新编译,替换一下包,把历史任务全部发一遍就能很好地升级到现在的1.6.1集群版本,1.6.2改动不大也就没有继续升级。到现在正好一年的时间,线上已注册了44个 Spark 任务,其中28个 Streaming 任务。在运行这些任务的过程中我们遇到了很多问题,其中最大的一点是动态扩容问题,即当业务线增加了更复杂的代码逻辑时或者业务增长导致处理量上升时,Spark 会面临计算资源不足的情况,这时如果没有做流量控制那 Spark 任务会因内存承受不了而失败,如果做了流量控制则 Kafka 的 Lag 会有堆积,这时就需要增加 executor 来处理,但是数量的多少不好判断,因此要反复修改并重新发布来找到合理的配置。
我们在 Marathon 上使用 Logstash 时也有过类似问题。接入的日志较大时,流量会急剧增加从而导致 Logstash 无法应对,Kafka 的 Lag 产生堆积,这时只需点击 Marathon 界面的 Scale 然后填入更大的实例数字就能启动 Logstash 实例自动处理了。发现慢结点时,只需把 Marathon 对应的任务 Kill 掉就会自动补发替代任务。那么 Spark 可以实现 Logstash 的这些功能吗?我们决定在 Spark 2.0 版本中进行尝试,同时改进其它一些问题,另外 Spark2.0 是一次较大的版本升级,配置与之前的1.6.1不同,不能通过所有任务重发一遍来做到全部升级。