sector/sphere：设计和实现高水平数据云

翻译：哈尔滨工程大学08硕士 李海波  邮箱：[e-mail]。QQ：956270284。任何人转载必须声明出处。

Sector and Sphere:The Design and Implementation of a High Performance Data Cloud

 SS：Sector/Sphere

   MapReduce：MR

   Sector storage cloud:云端存储

   Sphere compute cloude:云端计算

4. 关心热点

 

5. 理论分析（算法、图表、新术语、定义、定理）

概述：

云计算被证明在处理大的数据集的时候是非常有效的编程架构。包括谷歌在内的GFS/MR和hadoop，都开始去存储和处理海量数据集，特别是和WEB相关的应用。在这片论文李，我们提出一个新的云计算模型，包括云端存储、云端计算。相对于现存的云计算模型，云端存储提供的不仅仅是存储的数据中心，也提供数据的分布式垮广域网传输。另一方面，云端计算提供了一种流处理规则，去支持数据的密集应用。他支持所有的能够用MR解决的应用，但是更简单、更直接的去使用，并且2倍以hadoop的速度运行。我们发布了ss的开源版本并进行真实世界的各种使用。

介绍：

提到云，我们马上会联想到这是一个提供按需分配资源的或者服务的互联网上的基础设施，一般都是依托大规模的可靠的数据中心。云端存储提供存储服务（块I/O，或者文件服务），数据云端提供数据管理服务（基于记录的、基于列的或者基于对象的），云端计算提供计算服务。这些组合起来组成云计算的平台，去开发云级别的应用。

例如谷歌的GFS，BigTable和MR，Amazon的s3，simpleDB ，和EC2，还有hadoop系统，HDFS，hadoop的MR，和HBase，一个BigTable的实现。

简单的推理：高性能的计算系统中处理器是一个稀缺资源，因此是共享的。当处理器可用，数据迁移到处理器。简单的说，这就是超级云计算的模型。另外一个方法是存储数据并找出数据的共同计算。简单的来说，这就是数据中心模型。

云计算平台（GFS,MR,BigTable，Hadoop）有两个重要的限制：第一个是云计算系统假设云端的所有的节点都在同一节点，要么是同一数据中心，要么是相对小的贷款在地理上分散的包含数据的集群间。

第二个，这些云假设单个的输入或者输出是非常小的，尽管聚集数据管理和处理非常的大。这样可以理解因为大部分云应用都是处理相对小的web网页，将web网页作为输入的收集和处理，输出包括查询和返回相对小的数据集。尽管有些电子科学应用拥有这些特色，但是其他必摄取相对大的数据集作为返回。

相对的，我们假设，这里有高速的网络（10Gbps或者更高）连接各种各样的地理上分散的集群，这里的云必须支持摄取和返回交大的数据集。

这篇论文里，我们描述一个云端存储系sector和云端计算sphere。他们的开源地址在：http://sector.sourceforge.net.

Sector是一个分布式存储系统，能够应用在广域网环境下，并且允许用户以高速度从任何地理上分散的集群间摄取和下载大的数据集。另外，Sector自动的复制文件有更高的可靠性、方便性和访问吞吐率。Sector已经被分布式的Sloan Digital Sky Survey数据系统所使用。

Sphere是一个计算服务构建在sector之上，并为用户提供简单的编程接口去进行分布式的密集型数据应用。Sphere支持流操作语义，这通常被应用于GPU何多核处理器。流操作规则能够实现在支持MR计算的应用系统上。

本文的其余部分将分别描述sector和sphere在第2和第3节。第4节介绍了一些实验研究。第5节介绍有关的工作和第6条的摘要和结论。
    这是一个扩大版的会议论文相对于[22]文件：1）描述了一个更高版本的sector，包括安全，b）包括其他信息如sector如何工作，包括如何设计安全和调度设计，及c）描述了新的实验研究。

2 Sector

2.1 概述

Sector是一个云存储系统。具体的，sector提供一个高并行性和可靠性的穿越互联网的数据中心提供存储服务，sector有三个条件：

1）首先，sector假设他要访问大量的计算机集群（也叫做节点），这些节点可能在数据中心里面，也可能跨数据中心存在。

2）第二，sector假设这里有一个高速网络连接各个节点。例如，试验数据表明：节点在 1 rack 的网络连接速度是 1Gbps，而2 racks的一个数据中心则是 10 Gbps，那么，两个不同的数据中心共同连接 10Gbps。（没太懂，原文如下：For example, in

the experimental studies described below, the nodes within

a rack are connected by 1 Gbps networks, two racks within

a data center are connected by 10 Gbps networks, and two

different data centers are connected by 10 Gbps networks.）

3）sector假设数据集存储在一个或者多个分离的文件中，这叫做sector 分片。不同的文件组成一个数据集被复制或者分散在多个节点上，但是统一被sector管理。例如，一个呗sector管理的文件，试验研究将一个1.3TB的数据集分片成64个文件，每一个大约20..3GB。

           图1 sector系统的架构

           图1展示了sector的总体架构。安全服务器包括用户账户、用户密码和文件访问信息。他还包括一系列奴机slave的IP地址，所以非法主机不能够假如到系统中来并发送信息来干扰系统。

           主机 master 维护文件的元数据信息，控制所有运行的slave 节点。并且回应客户的请求。Master同安全服务器交互去认证slaves、clients和用户。

Slaves是存储文件的节点，并且处理数据应答其上的sector client。Slaves通常运行在

一个或者多个数据中心的一组计算机集群上。

2.2 文件系统管理

Sector并不是本地的文件系统，另外，他依赖于每一个slave 节点的文帝文件系统去存储分片。设计sector的一个关键因素是每一个sector分片都存储在一个本地文件系统的单独一个文件中去。这就是说，sector并不将sector 分片继续进行分片。这种设计极大的简化了sector系统并提供几个优势：首先，这种方法，sector可以检索所有的元数据，通过简单扫描每一台节点的数据目录。第二个，sector能够连接到单一的从机节点去下载或者上传文件。相反，如果云存储管理在块级水平，那么，一个用户必须连接存储一个文件的分块的所有从机，hadoop系统就是这样的一个例子文件管理在块级水平。第三，sector可以操纵本地文件系统。

这种方法的缺点就是他不允许用户将大的数据集撕裂为多个文件或者用一个utility去实现这个。Sector假设任何用户能够开发足够的代码去应付大数据集并分类为多个文件。

Master维护元数据索引，这些元数据可能随后被sector或者支持的文件查询所访问，例如文件查找和目录服务。

Master维护所有slaves的信息和系统的拓扑，这是为了更好的性能和资源利用。

目前的实现假设sector装载一个分层拓扑上，计算节点在多个数据中心的机架内，该拓扑结构手动指定一个主配置文件的服务器。

Master周期性的检查每个文件的副本。如果数量低于一个门限，则master选择一个slave创建一个新的文件的副本。新的文件副本位置根据slaves的网络拓扑来存放。当一个client请求一个文件，master会选择一个离client最近而且不忙的slave给client使用。

2.2 安全性

Sector运行一个独立的安全服务器。这种设计允许不同的安全服务提供商进行配置（例如LDAP和Kerberos）。另外，多个sector masters（为了更高的可靠性和可用性）能够使用安全服务。

Client登陆master 服务器是经由ssl连接的。用户名、密码送到master。Master于是建立ssl连接给安全服务器，并去认证client的信任度。安全认证服务器检查它的用户数据库并且发送结果反馈给master，一同的还有一个独一无二的session ID和client的文件访问权限。除了密码之外，用户的的client的IP地址也是要经过检查的。SSL连接也需要凭证和认证。

如果一个client需要访问文件，那么master会检查哪一个用户有访问那个文件的权限。如果允许，则master选择一个slave节点为client提供服务。Slave和client建立一个独一无二的数据连接，中间是要经过master协调的。目前，数据连接并不是加密的，但是我们将来会增加加密功能。

Sector 的slave 节点仅仅允许sector的命令。Sector clients和其他slave节点都不能发送命令直接给slave。所有的主从节点和从机-从机节点数据传输都必须经过master的协调。

最后，安全服务控制是否一个slave可以加入到系统。安全服务器支持IP列表和IP段控制，在这个范围内的计算机才能够加入变成slave。

2.4 管理和数据传输

   Sector使用udp作为信息（message）的传输，而是用udt作为数据的传输。Udp传输速度高于tcp因为他不需要简历连接。我们开发一个可靠的信息传输库叫做GMP（group messaging protocol）用在了sector中。对于数据传输，一个sector slave会同client建立一个udt连接，这个udt连接使用会和连接模式：rendezvous，并且通过master进行协调。Udt是一个高性能的数据传输协议，在高带宽长距离连接上优于TCP。

   一个单独的udp端口使负责传输message，其他的udp端口负责所有的数据连接。一定数量的线程处理udp数据包，独立于连接，这使得系统的可扩展性很强。（此处不是很通）。

3 SPHERE

3.1 概述

   回忆一下sphere是一个计算云覆盖在sector的上面。为了介绍sphere，考虑下面的例子。假设我们有1亿billion的太空图像，来自 sloan digital sky surver(sdds)，目标是找出褐矮行星。假设平均的图片大小是 1MB所以总体数据 1TB。SDSS数据集被存储在64个文件中，命名为 SDSS1.DAT，………….SDDS64.DAT,每一个包括一个或者多个图片。

   为了去随即访问一个数据集中的图片（一共64个文件），我们建立一个索引文件为每一个文件。索引文件指示着文件的偏移量：起始点和终止点。索引文件命名规则：数据文件名后面加上idx，如：SDSS1.DAT.IDX，等。

   去使用sphere，用户写一个函数”findBrownDwarf”去发现褐矮星，从所有图片里面查找。这个函数，输入是一个图片，输出是褐矮星。

   findBrownDwarf(input, output);

   一个标准的穿行程序可能如下：

  for each file F in (SDSS slices)

for each image I in F

findBrownDwarf(I, …);

   使用sphere的client API，相应的伪代码如下：

   SphereStream sdss;

sdss.init(/*list of SDSS slices*/);

SphereProcess myproc;

Myproc.run(sdss, "findBrownDwarf");

Myproc.read(result);

下面的伪代码片段，“sdss”是一个sector流数据结构，存储sector分片的元数据。应用通过一系列文件名进行流的初始化操作，sphere从sector网络里自动检索元数据，最后三行简单的开始作业并且等待输出结果。这些不需要用户区定位或者移动数据，也不需要他们去关心什么调度、信息处理和容错等。

3.2 计算模型

  如同上面所说的那样，sphere使用流处理计算模型。流处理模型是最为通用的方式，GPU和多核处理器都在使用。在sphere中，每一个slave处理器都被考虑为GPU重的ALU，或者一个多核中的一个CPU。在流处理模型中，每一个输入数据流中的元素都是被多道计算单元以独立的方式用的同样的处理函数处理，这个模型也叫做SPMD(单指令流多数据流)。

  我们开始阐述sphere使用的 key：键值抽象。回忆sector数据集里面有无数的物理文件。一个流在sphere中式iyge抽象的存在并且很可能是一个或者几个数据集。Sphere使用流作为输入并且使用流作为输出。一个sphere流包括多个数据段，这些数据段被 SPE(sphere processing engines)处理，一个SPE能够处理段的一个数据记录，一组数据记录，或者整个段。

   图2说明了一个sphere如何处理流中的段。通常SPE中有很多数据段，这里会提供一个简单的机制维护加载平衡，较慢的SPE会处理少量的段。每一个SPE从流中接收一个短作为输入，产生一个段作为流的输出。这些输出段可以作为另外一个SPE的处理输入。

 

图2描绘了一个基本的SPE模型。Sphere也支持这个模型的扩展。

处理多道输入流：首先，多个输入流能够同时被处理（例如，操作A[]+B[]）。注意这里并不是简单的扩展，他可以复杂的拆分输入流，并可以将段赋值给SPE。

经过洗牌的输入流：第二，输出能够被发送到多个位置，而不是写道局部的硬盘。有些时候叫做洗牌。例如，用户定义一个函数被特化为一个 bucket ID，桶ID（这里说的是目的文件，或者在局部或者在远程节点上）对每一个记录进行输出。Sphere会发送SPE’s中的结果，以他们到达时候的次序将他们写道文件中去。也就是说，sphere支持MR风格的计算。

图3现实了一个使用两个sphere处理（每一个处理成为 一个阶段 stage）的例子，第一个阶段将输入数据hash操作进入多个桶中，hash函数扫描整个流并且将每一个元素放到一个合适的桶中。例如：如果被排序的数据是一个整数集合，那么hash函数够将所有小于

T0的数据放入桶B0中，数据T0-T1之间的放入桶B1中，以此类推。

   第二阶段，每一个桶（数据段）都被SPE所排序，注意经过阶段2，整个数据集现在是被排序的了。这是因为所有桶中元素都都是有序的，并且桶之间也是有序的。

   注意，阶段2，SPE处理整个数据段，而不是每一个数据记录。

   SPE可以处理记录或者记录的集合，这个是系统模型的第三个扩展。在sphere中，一个SPE在一定时间内，能够处理多个记录，一个记录，整个数据段，或者整个文件。

3.3 sphere处理引擎

   一旦master接受client的数据处理请求，那么，他发送一系列的slave节点给client。Client选择一些或者所有的slave，并且请求SPE启动这些节点。于是client建立与SPE端的udt连接。流处理函数，以动态链接库的方式发送给各个SPE并且存储在slave的节点上。SPE打开动态链接库并获取各种各样的处理函数。于是以下面四个循环开始运行：

  1）SPE从包含文件名的client接受新的数据段、偏移和需要处理的行数，还有各种各样的参数。

  2）其次，SPE接受新的数据段（还有相应的索引文件）从一个slave的硬盘到另外一个节点中去。

  3）其次，S流处理函数开始处理单一的数据记录，或者一组数据记录，或者整个段，并且将结果写回到合适的目的地。另外，SPE周期性的发送认证给client以实时通告当前处理进展。

  当数据段被完全处理，SPE发送一个认证给client，去规约被处理的当前数据段。

  如果这里没有足够的数据段被处理，那么client关闭SPE的连接，那么SPE被释放。如果client被中断的话，那么，SPE可能超时。

3.4 sphere client

   Sphere client提供一个API的集合：开发者可以利用此写分布式应用。开发者能够使用这些API初始化输入流，加载处理函数，开启sphere处理，并且读处理结果等。

   Client分裂输入流成为多个数据段，所以每一段都可以独立的被SPE处理。SPE能够写本地磁盘，也能够返回处理状态或者返回自己的处理结果。Client跟踪每一段的状态（例如段是否被处理）并且管理最后结果。

Client负责管理每一个sphere进程的运行，sector/sphere的一个设计原则就是：将更多的选择机会交给client去做，所以secotr master能够更为简洁。在sphere中，client负责控制和调度进程的执行。

3.5 scheduler

3.5.1 数据分段和SPE初始化

   Client首先从sector中定位输入流中的数据文件，如果输入流是先前状态的输出流，那么信息已经在sector流结构内不需要继续分段。

   总体数据大小和记录都是需要被计算，分片成为段。这是sector中基于数据文件的元数据索引。

   Client试图统一的计算输入流给可用的SPE单元，每一个SPE分配的数据是均衡的。然而，考虑到每一台SPE的内存限制，和事物的数据通信代价，sphere限制数据分段的大小，用Smin和Smax来表示。（默认值是8MB-128MB，用户可以自定义）。另外，调度器内存是段倍数的记录不能够被分割。调度器也支持上仅一个文件一个记录的数据。

   作为特殊的例子，应用可能需要每一个数据文件以单独的段被处理，例如，现存应用仅仅涉及给一个处理文件。当数据文件没有索引记录的时候调度器也要进行处理。

 3.5.2 SPE调度

   如果输入流被分段，那么client将每一个段分配给SPE。下面是其规则：

   1）每一个数据段被指派给同一节点的SPE，假如此节点可用的话。

   2）同一个文件的分段同时被处理，除非没有空闲的SPE。

   3）如果讲过 规则1），2）以后仍然有空闲的SPE，给他们一部分数据段去处理。

   规则1试图运行SPE在同样的节点，条件是数据驻留，也就是利用数据的局部性。这个减少了网络流量并且获得更好的吞吐量。第二个规则改进了数据的同步访问因为SPE能够同时的独立的访问多个文件读取数据。

   正如 section 3.3说的那样，SPE周期性的提供处理进程的回馈。如果一个SPE没有在超时范围内提供回馈，那么，client将会抛弃这个SPE。被抛弃的SPE的处理的数据段将会移交给其他的SPE，如果这个SPE可用的话，或者已经返回给未赋值的SPE池中。这个机制就是sphere提供的容错机制。Sphere并不在SPE中使用任何检查点，当处理一个数据段的错误，那么就必须更换另外的SPE。

   当SPE写结果给多个目的地的时候，容错模型是非常复杂的（例如使用桶的时候）。每一个SPE在讲结果返回给其他节点的桶的时候，倾斜结果给本地磁盘。以这这种方式，假如一个节点坏了，那么，结果必须送给同样的桶的其他节点。每一个桶保持输入结果的记录状态，因此假如一个SPE坏了，桶管理器能够继续从另外一个SPE接受正确的数据，并处理相同的数据段。

   假如处理数据段的时候，输入数据或者用户的bug而出现错误，数据段不会被任何SPE所处理。错误报告会被返回给client。因此应用要注意适合的操作。

   在大多数情况下，数据段会超过SPE的数量，例如，数百台机器可能去处理 TG的数据。因此，系统自然会均衡加载因为所有的SPE都保持繁忙在一段时间内。负载不均衡一般会出现在计算的边缘，这时候会有少量数据被处理，导致一些SPE空闲。

   不同的SPE能够允许不同的时间去处理数据段。这里有几个理由：slaves节点可能不是专用的，slaves可能有不同的硬件配置（sector肯以是同构的）；不同的数据段可能有不同的数据处理时间。计算的末端，空闲SPE但是有未完成的数据段的时候，每一个空闲SPE会分配一个未完成数据段。也就是说，剩余的数据段仍然会运行在多个SPE上面，client首先从完成计算的SPE上收集计算结果。这样，sphere避免了SPE之间的进度的不协调。

3.6 与MR模型相对比

Sphere使用的流处理框架还是MR框架都可以是作为简单并行处理的一种方式。应用用户定义的函数（UDF）的方法给进行分段管理比MR的存储分段管理要更为通用（？不太通顺）。Sphere非常容易的具体化一个UDF并随后跟着一个规约UDF。我们下面更为详细的描述之：

一个MR的map处理能够直接被sphere通过输出流到局部存储去进行处理。MR的reduce可以简单的通过hash/桶操作交给sphere。MR模型中，在map阶段，slaves节点之间不可以有数据的交换，每一个reducer在规约阶段从所有的slaves中读数据。而sphere模型中，

   第一个阶段会hash（key，value）对给每一个slave节点的桶，第二阶段，所有数据处理处理reduce阶段都在每一台slave本地处理。

   我们用如何建立倒排索引的方法来说明MR和sphere的区别。输入是包含 词汇的web网页，而输出是是一系列的（词汇，pages）对。词汇是出现在page之中的，pages代表包含某一词汇的所有网页。

   使用sphere建立倒排索引使用两个阶段。在第一个阶段，读入每一个web pages，词汇被检索出来，并且每一个词汇都hash进入一个桶中去。Sphere自动给每一个桶分配一个独立的slave节点进行处理。考虑到这个是hash或者洗牌阶段，那么。更为具体的，所有的以‘a’开始的单词都会被分配给 第0桶，而以b开头的分配给第 1桶，顺次上延。一个更为先进的hash技术是更为防范的分发单词。在第二个阶段，产生一个倒排索引。倒排索引包含多个文件由sector管理。

   例如，假设这里有两个web网页：w1.html,w2.html。假设w1包含单词“bee”，“cow”，w2包含单词“bee”，“camel”..在sphere的第一个阶段，桶1会包含（bee，w1）,(bee,w2),桶2会包含(cow,w1),(camel,w2)。在第二个阶段，每一个桶进行单独处理。桶 1 (bee,(w1,w2)),桶2依然没有变化。这种方式，倒排索引和结果已经处理好了，结果存储在多个文件中。

   在hadoop的MR模型中，map阶段能够产生四个中间文件包括（bee，w1）,(bee,w2), (cow,w1),(camel,w2)。在规约阶段，reducer合并相同键值并产生三个数据项：(bee,(w1,w2))，(cow,w1),(camel,w2)。

4 试验研究

   下面我们给出2个sector/sphere的应用并讨论他们的性能：

4.1 SDSS数据分布

Sector用来分布SDSS的数据结果。我们建立多个sector服务器在Teraflow Testbed，在那里我们用来存储SDSS数据。我们存储13TB的 SDSS数据版本 5（DR5）。包括60个目录文件，64个目录文件以EFG的模式，和257个院士图片数据文件。….以下的没用不译。

我们加载SDSS文件在几个具体的位置目的是更好的覆盖北美和太平洋和欧洲。我们建立一个web站点（sdss。Ncdm。uic.edu）所以用户可以容易的获取sector client应用，并且SDSS文件能够被下载。每一个文件使用MD5校验。这些也在其中用户可以检验文件的完整性。

系统自从2006年5月就是在线的。过去的两年里，我们大约有6000次系统访问大约250TB的数据传输给用户终端。大约80%的用户对目录文件干星期，每一个文件的size在20GB~25GB之间。

图4现实了一次试验中文件下载的平均性能。Clients的连接数据率依然是10Gbps。在这个试验中，瓶颈是 disk I/O的速率。

  图5显示了数据传输的分布在过去十七八个月里实际转移到最终用户的吞吐量。大部分SDSS的下载里，瓶颈是网络连接到Teraflow Testbed的终端用户和简单的使用多道并行系统的下载。SDSS下载分布如下：32来自于美国，37.5来自于欧洲，18.8来自于亚洲，等等。用户的传输吞吐率从 8MB/s到900Mb/s，所有的都经过公共网络。更多的记录能够在网站上发现。

   4.2 Terasort

     我们实现一个Terasort的基准去评价sphere的性能。假设这里有N个节点，有10GB的文件在每一个节点上需要排序 N*10GB的数据。每一个记录包含10字节键值和90字节的值。Sphere实现的桶排序算法如下图3。

试验总结见图1。目前testbed包含4个机柜。每一有32个节点，包括1个NFS服务器，1个头结点，和30个计算/slave节点。头结点是 Dell1950……sector和hadoop都配置在120个节点的广域网上。Sector的master服务器和命名为 node/job tracker的hadoop配置在一个或者多个首节点上。

图1显示了Terasort排序的基准性能。注意这里可以看见长时间的处理时间因为总体的数据一致在增加。

  Secot和hadoop都是安全的复制数据。默认的复制策略都是产生三个副本。他们的复制策略部太相同。Hadoop复制数据在初始的写阶段，sector周期性的检查，如果没有足够数量的副本，那么就进行复制操作。见表1。结果显示sphere2倍速度高于hadoop。如果机柜数量增加，sphere的优势会更大。

5相关工作、结论：略。