遗憾的是，目前MapReduce运行时引擎的Hadoop实现无法提供上述的共享式服务功能。这归因于Hadoop作业跟踪器(Hadoop JobTracker)的基本架构设计——Hadoop作业跟踪器是一个管理层，在运行期间为MapReduce作业提供必要的服务。

目前的Hadoop作业跟踪器还无法把作业调度逻辑与资源管理逻辑分离开来，这直接导致了下列重大缺陷：

缺少企业级能力。在任何一个时间，只有一个MapReduce应用可以在集群上运行。因而，资源变成了静态的和用途单一的;而应用也是串行执行，而不是并行执行，导致无法有效利用的资源、形成烟囱式的IT环境，限制了可扩展性。

作业跟踪器成为单一故障点。如果作业跟踪器出现故障，所有运行中的作业都将停止。

很显然，目前Hadoop作业跟踪器能力有限，无法提供IT部门在生产级环境中部署MapReduce应用所需的共享式服务功能。

借助Platform Symphony MapReduce提供共享式服务

Platform Symphony MapReduce是一种生产级、分布式的运行时引擎，用于管理规模化的大数据应用。Platform Symphony MapReduce为企业运行大数据应用提供了下列独特好处：

能够为IT部门带来一种共享式服务平台

提高资源利用率，加大基础架构方面的投资回报

能够在企业里实现完善的服务水平协议

提供更高的性能、缩短获得结果的时间

简化IT管理，降低管理复杂IT环境的总成本

加强IT敏捷性

如何部署共享式服务模型?

企业应该视不同的业务要求使用以下方法部署共享式服务模型：

1. “烟囱式共享模型”——为不同的业务部门提供有保障的资源。IT部门根据不同业务部门的特定需求，为它们提供有保障的资源。业务部门向集中式IT部门请求 一定数量的资源，专门供自己使用。然后，那些请求被定义为策略，加入到资源分配方案中。不同业务部门之间不共享资源。集中式IT部门负责管理资源分配、系 统监控和故障排除。

2. “代理式共享模型”——企业内部跨各职能领域的资源共享。企业内部的不同职能部门共享一组通用的IT资源，资源共享策略根据不同业务部门的特定需求来予以 定义，然后加入到资源分配方案中。不是为某个业务部门单独分配静态资源，而是通过动态共享整个基础架构，从而为用户提供有保障的资源。