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替代解決方案。