随着大数据时代的来临,信息成爆炸式的增长,互联网以及移动设备每天都会产生大量数据。同时,用户提出了新的需求,如何在可接受的时间范围内从海量数据中挖掘出用户想要的、有价值的信息。后来,hadoop、spark等大数据计算框架出现在了人们的视野中,其中,spark成为大数据分析的主流工具,基本满足人们对性能的要求。很多公司加入到开源spark社区中,希望借由spark建立起对大数据领域的影响。Ibm就是众多公司中的一个,并宣传道“spark是ibm未来十年最重要的事,将安排3500名开发人员参与到spark相关的项目研发中”。Spark on ego团队就是其中的一支队伍,我们对开源spark进行了深度定制,将spark集成在了 ibm自己的资源调度框架ego上,使得spark在资源调度方面有了更好的性能和功能。同时,spark on ego团队开发了更多的功能,比如基于用户层级的资源调度等等,为用户提供了更好的服务。基于ego的spark master节点高可用特性是spark on ego项目的子模块,总体目标是实现master节点的高度可靠,当master节点出现故障宕机之后,master进程能够从故障中恢复过来,恢复到宕机前的状态,继续为集群提供服务。Spark on ego项目本身是开源spark版本的定制版,有很多功能是从开源spark中直接集成来的。而master节点高可用特性实际在开源spark中已经实现了,因此,我们主要通过参考开源spark中master节点高可用特性的实现,并结合spark on ego本身和开源的不同之处,如不同的master端类结构、不同的任务调度和资源分配流程,来实现我们自己的基于ego的spark master节点高可用特性。基于ego的spark master节点高可用特性的工作流程是,master节点宕机后,会根据用户配置的故障恢复策略,采取不同的启动方式。若用户配置为zookeeper模式,master宕机后,zookeeper将从用户事先配置好的备用master节点中选举产生新的leader master节点,然后进入故障恢复流程;若用户配置为fileSystem模式,需要用户手动启动master进程,随后进入故障恢复流程。Master进入故障恢复流程之后,首先会读取存储在外部设备中的元数据信息,判断该不该进行故障恢复,判断的标准是外部存储设备中是否存储了要恢复的application信息和driver信息,若有,则继续进行故障恢复;若没有,则直接进入master的正常工作状态。Master继续进行故障恢复后,会从资源管理器ego端以及driver端获取master端需要的任务调度信息和资源分配信息。当所有需要的数据获取到后,master进程会优先使用正常任务调度和资源分配流程中的操作,对这些数据进行同步,即重构master进程各对象中任务调度信息和资源分配信息相关的数据,使得master进程中的数据和master宕机前进程中的数据保持一致,继续为集群提供服务。