S3 服务(Simple Storage Service简单存储服务) 简介(与hdfs同一级)

                          图1  spark 相关

 

亚马逊云存储之S3(Simple Storage Service简单存储服务)

(转 )

 

S3是Simple Storage Service的缩写，即简单存储服务。亚马逊的名词缩写也都遵循这个习惯，例如Elastic Compute Cloud缩写为EC2等等。其余组织相似的命名有W3C，若是咱们也follow这个习惯则IEEE会被写为IE3，CCTV就是C2TV，好像有点罗嗦了。

S3说的玄乎一点能够叫云存储，通俗一点就是大网盘。其概念相似于分布式文家系统，同Google的GFS应该在一个层面。

S3的定义以下

Amazon S3 is a web service that enables you to store data in the cloud. You can then download the data or use the data with other AWS services, such as Amazon Elastic Cloud Computer (EC2).

看来除了作网盘只用，S3存储的数据还能够被其余的亚马逊高层服务直接引用，这一点比国内的简单的网盘提供商高很多，亚马逊大网盘是其总体Solution中的有机组成部分。

基本概念

1。bucket – 类比于文件系统的目录

A bucket is a Container for objects stored in Amazon S3. Every object is contained in a bucket. For example, if the object named photos/puppy.jpg is stored in the johnsmith bucket, then it is addressable using the URL http://johnsmith.s3.amazonaws.com/photos/puppy.jpg

彷佛目录不能嵌套，也就是不能有子目录，官方的说法是起到namespace的做用，是访问控制的基本单位，其实丫仍是个目录。

2。Object – 类比文件系统的文件

对象中带有对象名名，对象属性，对象自己最大5G，其实也仍是个文件。

目前object有Versioning的属性（即对象不一样历史版本的cache概念），这个是文件系统不具有的，在早期看到的S3资料中没有这一律念，应该是演进的结果，其面对的应该是有版本控制的需求的用户。

3。Keys – 类比文件名

key的样式也是URL，记住亚马逊的服务都是使用Web Service或REST方式访问的。

例如，http://doc.s3.amazonaws.com/2006-03-01/AmazonS3.wsdl

其中‘doc’就是目录名（桶名），”2006-03-01/AmazonS3.wsdl”是文件名（对象名）。

若是引入了version则bucket + key + version惟一标示一个版本的文件。

4。Versioning – 类比CVS中的一个版本

下面是一些实现原理的描述。

<图片缺失...>

同名文件的写入，并不覆盖已有文件而是增长了一个最新的文件版本。

一样下面的删除也不真正删除，而是mark了删除标记。

<图片缺失...>

当最新版本mark为deleted以后，对该对象的get操做返回404错误，除非明确指定一个历史版本。

固然也能够指定版本永久删除其中一个拷贝。

5。Regions – 文件存储的地理位置 

这个也是文件系统中不存在的，就是不一样的地理区域，用户能够指定将文件存在某个国家的服务器。我我的认为，这不是一个很好的概念，做为云的提供商，应该对于应用屏蔽这些部署细节。工程实现同技术理想仍是有差距。目前其能够指定的server位置有美国、爱尔兰、新加坡等地。

接口API

经常使用的API就是读、写、增、删、改、查等等。使用标准的SOAP和REST定义。

尤为一提的是对于对象的获取，除了用http直接按照C/S方式获取以外，亚马逊支持BT协议，也就是说提供种子。从用户角度想，亚马逊会 charge更少的钱，但同时亚马逊自身也会减负。bt下载的速度就不太稳定了，基本取决于种子“质量”也就是取决于对文件感兴趣的人的多寡。例如命名为 “XX门”估计文件下载可以快不少。

数据有什么用

当数据上传到aws云以后，能够不少服务可使用例如。

Amazon ElasticCompute Cloud

Amazon Elastic MapReduce

Amazon Import/Export等。

一点遗憾

没有看到如何实现分布式文件系统的资料，这是了解其Scale以及可靠性等的关键，或许亚马逊没有google大方，没有提供相似GFS之类的底层机制实现文档。

参考

http://aws.amazon.com/s3/#functionality

http://docs.amazonwebservices.com/AmazonS3/2006-03-01/

http://developer.amazonwebservices.com/connect/forum.jspa?forumID=24

 

http://www.kernelchina.org/content/%E4%BA%9A%E9%A9%AC%E9%80%8A%E4%BA%91%E5%AD%98%E5%82%A8%E4%B9%8Bs3simple-storage-service%E7%AE%80%E5%8D%95%E5%AD%98%E5%82%A8%E6%9C%8D%E5%8A%A1

 

三个理由告诉你对象存储替换HDFS还不错  

缘由一：对象存储可提供更好的数据保护 虽然HDFS可以利用内部的服务器级存储，它其实是按照其标准的数据保护策略将全部数据作了三个副本。所以，尽管可使用较便宜的服务器内部的硬盘驱动器，它可能并不像最初但愿的那样经济，由于容量需求要乘以3。

一种替代方案是使用基于对象的存储系统，提供亚马逊简单存储服务（S3）协议访问，这是Hadoop除了HDFS也一样支持的。这些系统能够是纯软件，所以可使用商用服务器和服务器级存储。但不一样于默认的HDFS，许多对象存储系统都提供纠删编码。这种数据保护机制相似于RAID但粒度更细，能够在对象或子对象的层面操做，把数据和奇偶校验位分布到存储集群的各个节点上。其结果是，能够达到类似或更高水平的数据冗余性，而只需大约25％至30％的额外开销。相比之下， HDFS的标准三副本配置下的额外容量开销为200％。

缘由二：HDFS会暴露主节点

 

　　HDFS具备一个主节点和一系列从节点。从节点处理数据并将结果发送给主节点。主节点还须要维护数据复制策略以及基本的集群管理。若是主节点发生故障，集群的其他节点将不能被访问。 HDFS对主节点只提供了有限的保护，因此企业须要采起特殊措施来实现主节点的高可用性。

　　如上所述，在对象存储系统中，主节点与从节点都能受到相同的纠删编码的数据保护。此外，由主节点维护的管理Hadoop集群所需的全部元数据(metadata)均可以存储在集中化的对象存储系统中。这样当主节点发生故障时，从节点或备用节点能够迅速变成为主节点。

 

　　缘由三：HDFS不能进行单独扩展

　　像任何其余架构同样，Hadoop对计算和存储容量也会有不一样程度的需求。问题是，HDFS要求计算能力和存储容量须要按比例进行扩展，这意味着你不能单独对某一种资源进行扩充。

　　要说明这一点最多见的方式是当一个Hadoop架构的存储容量用尽时，由于增长更多容量就意味着加入另外一个装满硬盘的节点，这也增长了更多的计算能力。反之亦如此，做为Hadoop基础设施，每每须要更多的处理能力，但存储空间却很充裕。大多数时候，当购置了一个新的服务器以增长计算能力时，它也带来了新的存储空间。其结果是，Hadoop架构老是在某种资源上浪费金钱，而对另外一种资源却老是缺少。

　　对象存储容许容量和计算能力各自独立地进行扩展。计算节点能够是1U或2U的机箱，经过固态存储引导。对象存储系统能够装满高容量驱动器，从而保持每GB成本最低。更重要的是，随着应用环境的变化，每一层均可以独立扩展。

 

　　HDFS之于Hadoop的主要优势是低成本和高性能，这得益于数据存放于本地。而利用商业存储硬件的对象存储系统一样能够提供相似的低成本，尤为是当采用纠删编码来提升数据保护效率时更是如此。10 GbE的高速网络如今已经很实惠，这些都使HDFS将数据和计算放在一块儿所带来的性能优点不复存在。对象存储提供了一种更具成本效益，更可靠，并且性能至少跟HDFS至关的基础架构，它理所固然应该成为一种可行的HDFS替代解决方案。