应对大数据挑战 企业需要共享式服务模型

大数据是当今科技行业发展速度最快的领域之一。大数据具有前所未有的大量化、快速化和多样化三大特点，这些是许多新技术背后的驱动力，这些技术可帮助企业处理大数据带来的多种新问题。

在诸多的新兴解决方案中，Hadoop和MapReduce被视为是两种大有希望的方法，可高效管理和分析大数据。但目前针对MapReduce应用的运行时引擎还无法提供足够功能来满足企业希望在生产环境中部署MapReduce应用的实际需求。

对企业IT部门来说，先进的运行时引擎应该是这样一种管理工具：它可以在满足高标准服务水平协议（SLA）的同时，支持企业里的各业务部门。这类管理工具应该能够支持混合类型的工作负载，包括MapReduce应用及业务部门在共享式网格上智能化提交的其他应用。

此外，如今的IT部门正在经历重大转变。在许多情况下，IT部门不再只是个成本中心，相反，它被视作是支持企业里各业务部门的服务提供者。预算有限、工作负载需求加大，使得IT部门面临巨大的压力，必须进一步充分利用现有的基础架构，最大限度地提高总的资源利用率。

让在基础架构方面的投资迅速获得回报是IT部门在做采购决策时最重要的考量因素之一。能充分利用现有的基础架构，满足更高的工作负载需求，并实时动态地满足需求，进一步节省成本，提高投资回报，无疑是企业希望寻找的解决方案。

为了支持MapReduce应用等新型应用，IT部门迫切需要一种共享式服务运行时平台以获得更好的性能、更高的资源利用率、自动监控和诊断功能，同时也需要IT基础架构能提供更高级的应用生命周期支持。

何谓共享式服务模型？

共享式服务模型是指这样一种基础架构平台：它允许多个应用（无论其类型和要求是什么）能够在共享式基础架构上并行执行。共享式服务模型常常由一种先进的应用调度和资源管理引擎来管理，为它所支持的企业里的多个业务部门提供有保障的服务。

共享式服务IT模型提供以下几个重要好处：

•少花钱多办事
•迅速获得基础架构方面的投资回报
•提供更好的可管理性
•有更好的可扩展性和灵活性以支持不断变化的应用需求
•利用收费政策，让IT部门的角色从成本中心转变成盈利中心

现有的Hadoop MapReduce运行时引擎面临的挑战

遗憾的是，目前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资源，资源共享策略根据不同业务部门的特定需求来予以定义，然后加入到资源分配方案中。不是为某个业务部门单独分配静态资源，而是通过动态共享整个基础架构，从而为用户提供有保障的资源。