去哪儿网Spark2.0动态扩容实践：基于Marathon管理

"去哪儿网基于Marathon管理Spark2.0实现动态扩容实践" 在去哪儿网的IT系统中，他们面临着如何有效地管理和扩展Spark集群以适应不断变化的业务需求的挑战。原先，他们将Spark1.5.2部署在Mesos上，随着Spark新版本的发布，他们将系统升级至1.6.1。尽管升级过程相对平滑，但随着时间的推移，线上注册的44个Spark任务（其中28个为Streaming任务）在应对业务增长和复杂度增加时，遇到了计算资源不足的问题。 动态扩容成为了一个关键的需求。当业务量增加导致Spark任务内存不足时，如果不进行流量控制，任务可能会失败；反之，如果使用流量控制，Kafka的Lag则会积累。手动调整executor数量以寻找最佳配置不仅耗时，而且难以精确判断。这与他们使用Marathon管理Logstash时的自动化扩容形成了鲜明对比，Logstash可以通过简单地增加实例数量来处理流量增加，甚至可以自动替换低效节点。 因此，去哪儿网决定在引入Spark2.0时实现动态扩容功能。Spark2.0作为一个重大版本更新，其配置与之前的1.6.1有显著差异，不能直接通过重发任务的方式完成升级。Mesos-dispatcher作为Spark在Mesos上的资源调度组件，它负责管理Spark任务的分配和执行。Marathon同样作为一个Mesos上的Framework，能够实现应用的自动扩展和故障恢复。 在Mesos架构中，Framework是资源分配和调度的核心。Spark-mesos-dispatcher作为Spark的特定实现，负责在Mesos集群中为Spark作业请求和分配资源。而Marathon则是一个持续运行的服务，它监控和管理应用程序的生命周期，包括自动扩展和容错能力。通过借鉴Marathon的动态扩容机制，去哪儿网期望能够在Spark2.0中实现类似的功能，以自动化解决因业务增长带来的资源需求变化问题。 为了实现这一目标，去哪儿网可能需要深入理解Spark2.0的资源管理模型，如动态资源分配（DRF）、弹性调度等特性，并结合Marathon的API，设计出一套能够根据任务负载动态调整executor数量的解决方案。这可能涉及到监控系统、自动化脚本以及对现有Spark任务配置的优化。 此外，升级至Spark2.0还需要考虑兼容性和稳定性，确保所有现有的Spark任务在新的环境下能正常运行，而不会出现数据丢失或处理错误。这可能需要进行详尽的测试和验证，包括性能测试、压力测试以及在不同工作负载下的行为模拟。 总结来说，去哪儿网面临的挑战是构建一个能够自动适应业务增长的Spark2.0集群，通过集成Marathon的动态扩容能力，实现高效、自动化的资源管理。这将涉及对Mesos、Spark和Marathon的深入理解，以及对现有工作流的改造，以确保系统的稳定性和灵活性。