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