1.绪论

本周安装了Hadoop，根据教程简单跑了一下，看起来还是很酷炫。下图是我在Centos中安装的Hadoop2.4版本，通过谷歌浏览器，可以通过特定端口查看Hadoop文件系统目录。

在Hadoop安装好后进行圆周率的计算 hadoop集群计算圆周率_任务调度


安装包中自带了示例程序，可以运行wordcount之类的程序。

在Hadoop安装好后进行圆周率的计算 hadoop集群计算圆周率_mesos_02

代码如下：

hadoop jar hadoop-mapreduce-example-2.4.1.jar pi 50 50 #求圆周率的值
hadoop jar hadoop-mapreduce-example-2.4.1.jar wordcount  /wordcount/input  /wordcount/output
#wordcount程序

现在进入Mesos正题。
商用服务器集群已经成为一个主要的计算平台，为大型互联网服务和越来越多的数据密集型科学应用提供动力。在这些应用程序的驱动下，研究人员和从业人员一直在开发各种各样的集群计算框架，以简化集群编程。突出的例子包括MapReduce，Dryad，MapReduce Online（支持流媒体作业），Pregel（图形计算的专用框架）。新的集群计算框架将不断出现，并且没有任何框架对所有应用都是最佳的。因此，可以在同一个集群中运行多个框架，为每个应用程序选择最佳框架。在框架之间复用集群可提高利用率，并允许应用程序共享对大型数据集的访问，这些数据集可能太大而无法跨集群进行复制。目前共享集群的两种常见解决方案是静态分区集群并为每个分区运行一个框架，或者为每个框架分配一组VM。不幸的是，这些解决方案既没有实现高利用率，也没有实现高效的数据共享。主要问题是这些解决方案的分配粒度与现有框架之间的不匹配。许多框架，如Hadoop和Dryad，采用了一种细化的资源共享模型，其中节点被细分为“槽”，而作业由与槽匹配的短任务(short tasks)组成。任务的短暂持续时间和每个节点运行多个任务的能力允许作业实现较高数据局部性，因为每个作业将很快有机会在存储其输入数据的节点上运行。短任务还允许框架实现高利用率，因为当新节点可用时，作业可以快速扩展。遗憾的是，由于这些框架是独立开发的，因此无法跨框架进行细化共享，因此很难在它们之间有效地共享集群和数据。
Mesos，一个简洁的资源共享层，通过为框架提供访问集群资源的通用接口，实现跨多种集群计算框架的细粒度共享。Mesos是一个在多种不同的集群计算框架（如Hadoop和MPI）之间共享商品集群的平台。共享（sharing）可提高集群利用率并避免每个框架的数据复制。Mesos以细粒度的方式共享资源，允许框架通过轮流读取存储在每台机器上的数据来实现数据本地化。为了支持当今框架的复杂调度程序，Mesos介绍了一种称为resource offers的两级调度机制。Mesos决定为每个框架提供多少资源，而框架决定接受哪些资源以及在其上运行哪些计算。结果表明，当在不同框架之间共享集群时，Mesos可以实现接近最优的数据局部性，可以扩展到50,000个（模拟的）节点，并且可以抵御集群故障。
Mesos的主要设计问题是如何构建一个可扩展且高效的系统，该系统支持各种当前和未来的框架。这是相当困难的。首先，每个框架基于其编程模型，通信模式，任务依赖性和数据空间，都将具有不同的调度需求。其次，调度系统必须扩展到数万个节点的集群，这些节点运行数百个具有数百万个任务的作业。
最后，因为集群中的所有应用程序都依赖于Mesos，所以系统必须具有容错性和高可用性。
一种方法是Mesos实现集中式调度程序，假设在mesos中输入框架需求，资源可用性和组织策略作，然后计算所有任务的全局调度。虽然这种方法可以优化跨框架的调度，但它面临着一些挑战。首先是复杂性，调度程序需要提供一个足够富有表现力的API来捕获所有框架的需求，并解决数百万个任务的在线优化问题。即使这样的调度程序是可行的，这种复杂性也会对其可伸缩性和容错性产生负面影响。其次，随着新框架和当前框架的新调度策略不断发展，我们是否已经完全具备框架要求的规范尚不清楚。第三，许多现有框架实现了他们自己的复杂调度，将此功能移动到全局调度程序将需要昂贵的重构。
相反，Mesos采用了不同的方法：将对调度的控制委托给框架。这是通过一种称为resource offers的新抽象来实现的，该抽象封装了框架可以在集群节点上分配以运行任务的资源包。Mesos基于组织策略（例如公平共享）决定为每个框架提供多少资源，而框架决定接受哪些资源以及在其上运行哪些任务。虽然这种分散式调度模型可能并不总能导致全局最优调度，但它在实践中表现出色，能够允许框架几乎完美地满足数据局部性等目标。此外，resource offers可以简单而有效地实现，使Mesos具有高度可扩展性和对故障的鲁棒性。
使用10,000行C ++代码实现了Mesos。系统可扩展到50,000个（模拟的）节点，并使用ZooKeeper来保证容错性。为了评估Mesos，移植了三个集群计算系统来运行它：Hadoop，MPI和Torque批处理调度程序。为了验证假设，即专用框架提供了超过一般框架的价值，在Mesos之上构建了一个名为Spark的新框架，针对迭代作业进行了优化，其中数据集在许多并行操作中被重用，结果表明Spark在迭代机器学习工作负载中可以胜过Hadoop 10倍。

2.架构

  1. 设计理念：Mesos旨在提供可扩展且具有弹性的核心，以使各种框架能够有效地共享集群。由于集群框架具有高度多样性和快速发展的特点，因此首要设计理念是定义一个最小的接口，以实现跨框架的高效资源共享，并将任务调度和执行的控制交给具体框架之中。
  2. 设计概览：图中展示了Mesos的主要组件。

    Mesos包含一个主进程（Master），用于管理在每个集群节点上运行的从属守护进程（slave），frameworks就在slaves上运行各个task。master使用resource offers跨框架实现细粒度共享。每个资源提供多个slave上的可用资源列表。master根据组织策略（例如公平共享或优先级）决定向每个框架提供多少资源。为了支持各种框架间分配策略，Mesos允许通过可插入分配模块来定义自己的策略。在Mesos上运行的每个框架都包含两个组件：一个向master注册以申请资源的调度程序（scheduler），以及一个在slave上启动以执行框架任务的执行程序进程（executor）。当master确定要为每个框架提供多少资源时，框架的调度程序会选择要使用的资源。当框架接受提供的资源时，它会向Mesos传递要启动的任务的描述。
    下图中展示了一个框架调度来运行task的示例

    为了维持Mesos的灵活性，框架可以拒绝使用提供的资源（reject），直到有满足框架自身的资源出现。同时，Mesos可以使用filters机制，来提前做好规划，将合适的资源提供给框架。
  3. 资源分配：Mesos将分配决策委托给可插拔分配模块，以便可以根据需要定制分配。到目前为止，已经实现了两个分配模块：一个基于多个资源的max-min公平性的泛化策略和实现严格优先级的策略。在正常操作中，Mesos利用了大多数任务都很短的事实，并且只在任务完成时重新分配资源。这通常经常发生，以便新框架能够快速获得对集群的分享。
  4. 资源隔离：Mesos通过利用现有的OS隔离机制，在同一个slave上运行的框架执行程序之间提供性能隔离。由于这些机制依赖于平台，因此通过可插拔隔离模块支持多种隔离机制。目前使用OS容器技术，特别是Linux容器和Solaris项目来隔离资源。这些技术可以限制CPU，内存，网络带宽和（在新的Linux内核中）进程树的I / O使用。这些隔离技术并不完美，但使用容器已经优于Hadoop等框架。
  5. 架构容错：由于所有框架都依赖于Mesos的master，因此使master容错是至关重要的。为实现这一目标，我们将master设计为软（soft）状态，以便新master可以从slave和框架调度程序所拥有的信息中完全重建其内部状态。特别是，master的唯一状态是活动的slave，活动框架和正在运行的任务的列表。
    此信息足以计算每个框架使用的资源数量并运行分配策略。 我们使用ZooKeeper在热备份配置中运行多个master以进行选举。当正在进行的master发生故障时，slave和调度程序将连接到下一个选定的master并重新填充其状态。
  6. API汇总：以下为Mesos的API

    “callback”列列出了框架必须实现的功能，而“Actions”是它们可以调用的操作。

3.实现

Mesos是用10000行C++代码实现的。可以运行在Linux、Solaris和OS X上，支持使用C++、java和python写成的框架。
为了降低实现的复杂性，使用一个名为libprocess的C ++库，它使用有效的异步I / O机制（epoll，kqueue等）提供基于actor的编程模型。还使用ZooKeeper来执行领导者选举。Mesos可以使用Linux容器或Solaris
projects来隔离任务，目前隔离CPU核心和内存。在Mesos之上实现了四个框架。首先，已经移植了三个现有的集群计算系统：Hadoop ，Torque资源调度器和MPI的MPICH2实现。这些端口都不需要更改这些框架的API，因此所有这些端口都可以运行未经修改的用户程序。此外，为Spark创建了一个专门的迭代作业框架。

  1. Hadoop Port：将Hadoop移植在Mesos上运行需要相对较少的修改，因为Hadoop的细粒度的map和reduce任务完全映射到Mesos任务。此外，Hadoop主服务器（称为JobTracker）和Hadoop从服务器（称为TaskTrackers）自然地作为框架调度程序和执行程序进入Mesos模型。使用延迟调度，通过等待包含任务输入数据的节点上的插槽来实现数据局部性。此外，可以重用Hadoop的现有逻辑来重新调度失败的任务和推测执行（straggler mitigation）总的来说，实现Hadoop端口使用了1500行代码。
  2. Torque和MPI Port：Torque集群资源管理器已经可以移植到Mesos上作为框架运行。该框架由一个Mesos调度程序和执行程序组成，用360行python代码编写，用于启动和管理Torque的不同组件。此外，论文作者团队修改了3行Torque源代码，以允许它根据队列中的作业在Mesos上弹性地向上和向下扩展。由于在Torque（例如，MPI）上运行的作业可能不具有容错能力，因此Torque可以通过不接受超出其保证分配的资源来避免其任务被撤销。除了Torque框架之外，我们还创建了一个Mesos MPI的“wrapper”框架，用200行Python代码编写，用于直接在Mesos上运行MPI作业。
  3. Spark框架：Mesos支持创建针对工作负载优化的专用框架，为了验证简单专业框架提供价值的假设，确定了一类在实验室的机器学习研究人员发现在Hadoop上表现不佳的工作：迭代工作，（iterative jobs）其中数据集在多次迭代中重复使用。为这些工作负载构建了一个名为Spark的专用框架。在之前的博客中分享过相关的Spark内容，本文中也继续提到了逻辑回归的应用。
    下一篇：Hive- A Warehousing Solution Over a Map-Reduce Framework