對象存儲hadoop

『壹』 國內外的Hadoop應用現狀

文 | 翟周偉
本文節選自《Hadoop核心技術》一書。
Hadoop是一個開源的高效雲計算基礎架構平台，其不僅僅在雲計算領域用途廣泛，還可以支撐搜索引擎服務，作為搜索引擎底層的基礎架構系統，同時在海量數據處理、數據挖掘、機器學習、科學計算等領域都越來越受到青睞。本文將講述國內外的hadoop應用現狀。
國外Hadoop的應用現狀
1.Yahoo
Yahoo是Hadoop的最大支持者，截至2012年，Yahoo的Hadoop機器總節點數目超過42?000個，有超過10萬的核心CPU在運行Hadoop。最大的一個單Master節點集群有4500個節點(每個節點雙路4核心CPUboxesw，4×1TB磁碟，16GBRAM)。總的集群存儲容量大於350PB，每月提交的作業數目超過1000萬個，在Pig中超過60%的Hadoop作業是使用Pig編寫提交的。
Yahoo的Hadoop應用主要包括以下幾個方面：
支持廣告系統
用戶行為分析
支持Web搜索
反垃圾郵件系統
會員反濫用
內容敏捷
個性化推薦
同時Pig研究並測試支持超大規模節點集群的Hadoop系統。
2.Facebook
Facebook使用Hadoop存儲內部日誌與多維數據，並以此作為報告、分析和機器學習的數據源。目前Hadoop集群的機器節點超過1400台，共計11?200個核心CPU，超過15PB原始存儲容量，每個商用機器節點配置了8核CPU，12TB數據存儲，主要使用StreamingAPI和JavaAPI編程介面。Facebook同時在Hadoop基礎上建立了一個名為Hive的高級數據倉庫框架，Hive已經正式成為基於Hadoop的Apache一級項目。此外，還開發了HDFS上的FUSE實現。
3.A9.com
A9.com為Amazon使用Hadoop構建了商品搜索索引，主要使用StreamingAPI以及C++、Perl和Python工具，同時使用Java和StreamingAPI分析處理每日數以百萬計的會話。A9.com為Amazon構建的索引服務運行在100節點左右的Hadoop集群上。
4.Adobe
Adobe主要使用Hadoop及HBase，同於支撐社會服務計算，以及結構化的數據存儲和處理。大約有超過30個節點的Hadoop-HBase生產集群。Adobe將數據直接持續地存儲在HBase中，並以HBase作為數據源運行MapRece作業處理，然後將其運行結果直接存到HBase或外部系統。Adobe在2008年10月就已經將Hadoop和HBase應用於生產集群。
5.CbIR
自2008年4月以來，日本的CbIR(Content-basedInformationRetrieval)公司在AmazonEC2上使用Hadoop來構建圖像處理環境，用於圖像產品推薦系統。使用Hadoop環境生成源資料庫，便於Web應用對其快速訪問，同時使用Hadoop分析用戶行為的相似性。
6.Datagraph
Datagraph主要使用Hadoop批量處理大量的RDF數據集，尤其是利用Hadoop對RDF數據建立索引。Datagraph也使用Hadoop為客戶執行長時間運行的離線SPARQL查詢。Datagraph是使用AmazonS3和Cassandra存儲RDF數據輸入和輸出文件的，並已經開發了一個基於MapRece處理RDF數據的Ruby框架——RDFgrid。
Datagraph主要使用Ruby、RDF.rb以及自己開發的RDFgrid框架來處理RDF數據，主要使用HadoopStreaming介面。
7.EBay
單集群超過532節點集群，單節點8核心CPU，容量超過5.3PB存儲。大量使用的MapRece的Java介面、Pig、Hive來處理大規模的數據，還使用HBase進行搜索優化和研究。
8.IBM
IBM藍雲也利用Hadoop來構建雲基礎設施。IBM藍雲使用的技術包括：Xen和PowerVM虛擬化的Linux操作系統映像及Hadoop並行工作量調度，並發布了自己的Hadoop發行版及大數據解決方案。
9.Last.Fm
Last.Fm主要用於圖表計算、專利申報、日誌分析、A/B測試、數據集合並等，也使用Hadoop對超過百萬的曲目進行大規模的音頻特徵分析。
節點超過100台機器，集群節點配置雙四核[email protected]@2.13GHz，24GB內存，8TB(4×2TB)存儲。
10.LinkedIn
LinkedIn有多種硬體配置的Hadoop集群，主要集群配置如下：
800節點集群，基於Westmere的惠普SL170X與2×4的核心，24GB內存，6×2TBSATA。
1900節點集群，基於Westmere的超微-HX8DTT，與2×6的核心，24GB內存，6×2TBSATA。
1400節點集群，基於SandyBridge超微與2×6的核心，32GB內存，6×2TBSATA。
使用的軟體如下：
操作系統使用RHEL6.3。
JDK使用SUNJDK1.6.0_32。
Apache的Hadoop0.20.2的補丁和ApacheHadoop的1.0.4補丁。
Azkaban和Azkaban用於作業調度。
Hive、Avro、Kafka等。
11.MobileAnalytic.TV
主要使用Hadoop應用在並行化演算法領域，涉及的MapRece應用演算法如下。
信息檢索和分析。
機器生成的內容——文檔、文本、音頻、視頻。
自然語言處理。
項目組合包括：
移動社交網路。
網路爬蟲。
文本到語音轉化。
音頻和視頻自動生成。
12.Openstat
主要利用Hadoop定製一個網路日誌分析並生成報告，其生產環境下超過50個節點集群(雙路四核Xeon處理器，16GB的RAM，4～6硬碟驅動器)，還有兩個相對小的集群用於個性化分析，每天處理約500萬的事件，每月15億美元的交易數據，集群每天產生大約25GB的報告。
使用的技術主要包括：CDH、Cascading、Janino。
13.Quantcast
3000個CPU核心，3500TB存儲，每日處理1PB以上的數據，使用完全自定義的數據路徑和排序器的Hadoop調度器，對KFS文件系統有突出貢獻。
14.Rapleaf
超過80個節點的集群(每個節點有2個雙核CPU，2TB×8存儲，16GBRAM內存);主要使用Hadoop、Hive處理Web上關聯到個人的數據，並引入Cascading簡化數據流穿過各種處理階段。
15.WorldLingo
硬體上超過44台伺服器(每台有2個雙核CPU，2TB存儲，8GB內存)，每台伺服器均運行Xen，啟動一個虛擬機實例運行Hadoop/HBase，再啟動一個虛擬機實例運行Web或應用程序伺服器，即有88台可用的虛擬機;運行兩套獨立的Hadoop/HBase機群，它們各自擁有22個節點。Hadoop主要用於運行HBase和MapRece作業，掃描HBase的數據表，執行特定的任務。HBase作為一種可擴展的、快速的存儲後端，用於保存數以百萬的文檔。目前存儲了1200萬篇文檔，近期的目標是存儲4.5億篇文檔。
16.格拉斯哥大學的TerrierTeam
超過30個節點的實驗集群(每節點配置XeonQuadCore2.4GHz，4GB內存，1TB存儲)。使用Hadoop促進信息檢索研究和試驗，特別是用於TREC，用於TerrierIR平台。Terrier的開源發行版中包含了基於HadoopMapRece的大規模分布式索引。
17.內布拉斯加大學的HollandComputingCenter
運行一個中等規模的Hadoop機群(共計1.6PB存儲)用於存儲和提供物理數據，以支持緊湊型μ子螺旋型磁譜儀(CompactMuonSolenoid，CMS)實驗的計算。這需要一類能夠以幾Gbps的速度下載數據，並以更高的速度處理數據的文件系統的支持。
18.VisibleMeasures
將Hadoop作為可擴展數據流水線的一個組件，最終用於VisibleSuite等產品。使用Hadoop匯總、存儲和分析與網路視頻觀眾收看行為相關的數據流。目前的網格包括超過128個CPU核心，超過100TB的存儲，並計劃大幅擴容。
國內Hadoop的應用現狀
Hadoop在國內的應用主要以互聯網公司為主，下面主要介紹大規模使用Hadoop或研究Hadoop的公司。
1.網路
網路在2006年就開始關注Hadoop並開始調研和使用，在2012年其總的集群規模達到近十個，單集群超過2800台機器節點，Hadoop機器總數有上萬台機器，總的存儲容量超過100PB，已經使用的超過74PB，每天提交的作業數目有數千個之多，每天的輸入數據量已經超過7500TB，輸出超過1700TB。
網路的Hadoop集群為整個公司的數據團隊、大搜索團隊、社區產品團隊、廣告團隊，以及LBS團體提供統一的計算和存儲服務，主要應用包括：
數據挖掘與分析。
日誌分析平台。
數據倉庫系統。
推薦引擎系統。
用戶行為分析系統。
同時網路在Hadoop的基礎上還開發了自己的日誌分析平台、數據倉庫系統，以及統一的C++編程介面，並對Hadoop進行深度改造，開發了HadoopC++擴展HCE系統。
2.阿里巴巴
阿里巴巴的Hadoop集群截至2012年大約有3200台伺服器，大約30?000物理CPU核心，總內存100TB，總的存儲容量超過60PB，每天的作業數目超過150?000個，每天hivequery查詢大於6000個，每天掃描數據量約為7.5PB，每天掃描文件數約為4億，存儲利用率大約為80%，CPU利用率平均為65%，峰值可以達到80%。阿里巴巴的Hadoop集群擁有150個用戶組、4500個集群用戶，為淘寶、天貓、一淘、聚劃算、CBU、支付寶提供底層的基礎計算和存儲服務，主要應用包括：
數據平台系統。
搜索支撐。
廣告系統。
數據魔方。
量子統計。
淘數據。
推薦引擎系統。
搜索排行榜。
為了便於開發，其還開發了WebIDE繼承開發環境，使用的相關系統包括：Hive、Pig、Mahout、Hbase等。
3.騰訊
騰訊也是使用Hadoop最早的中國互聯網公司之一，截至2012年年底，騰訊的Hadoop集群機器總量超過5000台，最大單集群約為2000個節點，並利用Hadoop-Hive構建了自己的數據倉庫系統TDW，同時還開發了自己的TDW-IDE基礎開發環境。騰訊的Hadoop為騰訊各個產品線提供基礎雲計算和雲存儲服務，其支持以下產品：
騰訊社交廣告平台。
搜搜(SOSO)。
拍拍網。
騰訊微博。
騰訊羅盤。
QQ會員。
騰訊游戲支撐。
QQ空間。
朋友網。
騰訊開放平台。
財付通。
手機QQ。
QQ音樂。
4.奇虎360
奇虎360主要使用Hadoop-HBase作為其搜索引擎so.com的底層網頁存儲架構系統，360搜索的網頁可到千億記錄，數據量在PB級別。截至2012年年底，其HBase集群規模超過300節點，region個數大於10萬個，使用的平台版本如下。
HBase版本：facebook0.89-fb。
HDFS版本：facebookHadoop-20。
奇虎360在Hadoop-HBase方面的工作主要為了優化減少HBase集群的啟停時間，並優化減少RS異常退出後的恢復時間。
5.華為
華為公司也是Hadoop主要做出貢獻的公司之一，排在Google和Cisco的前面，華為對Hadoop的HA方案，以及HBase領域有深入研究，並已經向業界推出了自己的基於Hadoop的大數據解決方案。
6.中國移動
中國移動於2010年5月正式推出大雲BigCloud1.0，集群節點達到了1024。中國移動的大雲基於Hadoop的MapRece實現了分布式計算，並利用了HDFS來實現分布式存儲，並開發了基於Hadoop的數據倉庫系統HugeTable，並行數據挖掘工具集BC-PDM，以及並行數據抽取轉化BC-ETL，對象存儲系統BC-ONestd等系統，並開源了自己的BC-Hadoop版本。
中國移動主要在電信領域應用Hadoop，其規劃的應用領域包括：
經分KPI集中運算。
經分系統ETL/DM。
結算系統。
信令系統。
雲計算資源池系統。
物聯網應用系統。
E-mail。
IDC服務等。
7.盤古搜索
盤古搜索(目前已和即刻搜索合並為中國搜索)主要使用Hadoop集群作為搜索引擎的基礎架構支撐系統，截至2013年年初，集群中機器數量總計超過380台，存儲總量總計3.66PB，主要包括的應用如下。
網頁存儲。
網頁解析。
建索引。
Pagerank計算。
日誌統計分析。
推薦引擎等。
即刻搜索(人民搜索)
即刻搜索(目前已與盤古搜索合並為中國搜索)也使用Hadoop作為其搜索引擎的支撐系統，截至2013年，其Hadoop集群規模總計超過500台節點，配置為雙路6核心CPU，48G內存，11×2T存儲，集群總容量超過10PB，使用率在78%左右，每天處理讀取的數據量約為500TB，峰值大於1P，平均約為300TB。
即刻搜索在搜索引擎中使用sstable格式存儲網頁並直接將sstable文件存儲在HDFS上面，主要使用HadoopPipes編程介面進行後續處理，也使用Streaming介面處理數據，主要的應用包括：
網頁存儲。
解析。
建索引。
推薦引擎。
end

『貳』 對象存儲有什麼優勢

簡單介紹一下藍隊雲對象存儲的優勢：
1、邊緣存儲。
藍隊雲邊緣存儲服務在大規模邊緣節點和用戶側部署服務，加速數據存儲至邊緣，並最終將持久化數據保存至中心，有效解決數據上傳鏈路差，帶寬利用率低等行業痛點，降低本地存儲成本。
2、內容加速分發。
面對視頻、游戲等熱點資源分發的業務場景，您可以使用藍隊雲對象存儲作為源站，搭配藍隊雲 融合CDN 進行加速分發，方便您通過 CDN 節點就近訪問資源，提升用戶體驗。
3、多媒體數據處理。
針對有海量用戶生成內容的場景，藍隊雲對象存儲服務的高並發能力可以靈活應對大流量的業務場景。對存儲在雲端的圖片、音視頻等文件進行數據處理。
4、靜態資源託管。
藍隊雲無縫集合各類第三方擴展插件，如 WordPress、Discuz、Emlog 等，並支持一鍵將各類插件里的靜態資源託管到藍隊雲。
5、備份和歸檔。
藍隊雲提供高可用和高可靠的存儲解決方案來備份和歸檔用戶的關鍵數據，用戶可以設置不同的訪問許可權和級別，保障數據訪問安全。
相較於傳統自建方案，用戶無需采購高昂硬體，無需擔心擴容、安全等問題，從而節省更多的存儲、維護、人力成本。
6、海量數據高並發。
藍隊雲針對海量數據高並發的場景做了深度優化，實現對象存儲訪問協議到 HDFS 協議的轉換。
相較於傳統 Hadoop 方案，用戶可獲得更優的讀取、分析性能，更強的穩定性和更好的擴展性。
7、私有雲存儲
企業客戶可以選擇私有化部署藍隊雲對象存儲系統。
基於公有雲存儲的經驗積累，私有雲存儲解決方案具備高可靠、強安全、易擴展等特性。同時還能提供成熟的系統管理和運維，讓企業以更低廉的產品及維護成本，滿足在容量、性能及穩定性上的需求。
藍隊雲對象存儲跨數據中心的副本冗餘，為用戶數據提供異地容災和資源隔離功能，能夠保障服務的高可用性。能夠實現存儲需求的彈性伸縮，從而提高業務靈活性。並且藍隊雲對象存儲按需購買的便捷性，能夠有效避免存儲及帶寬資源的閑置浪費~您值得信賴~

『叄』 海量圖片存儲用hadoop是否合適存儲在哪個節點上能否由我們自己決定

hadoop可以實現海量數據的存儲，它包含分布式文件系統HDFS，所以您說的一部分存在節點1，一部分存在節點2上肯定可行
當你需要存儲比較大的文件時，HDFS會把它分成多個小塊（塊的大小可以自己定）來進行分布式存儲，而且名位元組點會記錄存的位置，當應用程序請求計算時，會將計算移到相應的數據附近，所以用hadoop，就相信它好了，當然你也可以在它上面附加一些自己的安全管理模塊，或其它中間件等，畢竟hadoop也有不盡人意的地方，還需要改進。
目前facebook，淘寶，yahoo！等都用hadoop構建了自己的數據中心來支持海量數據的存儲

『肆』 Hadoop分布式文件系統HDFS和OpenStack對象存儲系統Swift有何不同

最近在Quora上有人提到一個問題，有關Hadoop分布式文件系統和OpenStack對象存儲的不同。
問題原文如下：
「HDFS （Hadoop分布式文件系統）和OpenStack對象存儲（OpenStack Object Storage）似乎都有著相似的目的：實現冗餘、快速、聯網的存儲。什麼樣的技術特性讓這兩種系統因而不一樣？這兩種存儲系統最終趨於融合是否大有意義？」
問題提出之後，很快有OpenStack的開發者進行了回復。本文在此摘抄了前兩名回復進行翻譯，以供各位參考。
排名第一的答案來自RackSpace的OpenStack Swift開發者Chuck Their：
雖然HDFS與Openstack對象存儲（Swift）之間有著一些相似之處，但是這兩種系統的總體設計卻大不一樣。
1. HDFS使用了中央系統來維護文件元數據（Namenode，名稱節點），而在Swift中，元數據呈分布式，跨集群復制。使用一種中央元數據系統對HDFS來說無異於單一故障點，因而擴展到規模非常大的環境顯得更困難。
2. Swift在設計時考慮到了多租戶架構，而HDFS沒有多租戶架構這個概念。
3. HDFS針對更龐大的文件作了優化（這是處理數據時通常會出現的情況），Swift被設計成了可以存儲任何大小的文件。
4. 在HDFS中，文件寫入一次，而且每次只能有一個文件寫入；而在Swift中，文件可以寫入多次；在並發操作環境下，以最近一次操作為准。
5. HDFS用Java來編寫，而Swift用Python來編寫。
另外，HDFS被設計成了可以存儲數量中等的大文件，以支持數據處理，而Swift被設計成了一種比較通用的存儲解決方案，能夠可靠地存儲數量非常多的大小不一的文件。
排名第二的答案來自Joshua McKenty，他是美國宇航局Nebula雲計算項目的首席架構師，是OpenStack Nova軟體的早期開發者之一，目前是OpenStack項目監管委員會的成員，還是Piston.cc這家基於OpenStack的公司的創始人。
Chuck剛才詳細介紹了兩者的技術差異，但是沒有討論兩者可想而知的融合，OpenStack設計峰會上拋出了融合這個話題。簡而言之，HDFS被設計成可以使用Hadoop，跨存儲環境裡面的對象實現MapRece處理。對於許多OpenStack公司（包括我自己的公司）來說，支持Swift裡面的處理是路線圖上面的一個目標，不過不是每個人都認為MapRece是解決之道。
我們已討論過為HDFS編寫包裝器，這將支持OpenStack內部存儲應用編程介面（API），並且讓用戶可以針對該數據來執行Hadoop查詢。還有一個辦法就是在Swift裡面使用HDFS。但是這些方法似乎沒有一個是理想的。
OpenStack社區方面也在開展研究開發方面的一些工作，認真研究其他替代性的MapRece框架（Riak和CouchDB等）。
最後，現在有別的一些存儲項目，目前「隸屬於」OpenStack社區（SheepDog和HC2）。充分利用數據局部性，並且讓對象存儲變得「更智能」，這是預計會取得進步的一個領域。

『伍』 hadoop和OpenStack有什麼區別，請幫我掃掃盲

OpenStack 是雲計算平台.說白了就是能夠在上面創建虛擬機,管理虛擬機(美其名曰:計算資源虛擬化),管理存儲資源(美其名曰:存儲資源虛擬化).
OpenStack的存儲管理包括兩個工具:一個是分布式文件系統,一個是為虛擬機創建磁碟的工具.
OpenStack可以和hadoop比較的就是分布式文件系統.
hadoop是為了實現大數據量存儲.
OpenStack的存儲工具(名字叫swift)是對象存儲.
我知道的就是這些.具體的區別可以自己上網查查.
總的來說:OpenStack和hadoop不是同一個層次的東西,無法比較.可以比較的是OpenStack的工具swift.

『陸』 Hadoop分布式文件系統和OpenStack對象存儲有何不同

最近在Quora上有人提到一個問題，有關Hadoop分布式文件系統和OpenStack對象存儲的不同。
問題原文如下：
「HDFS （Hadoop分布式文件系統）和OpenStack對象存儲（OpenStack Object Storage）似乎都有著相似的目的：實現冗餘、快速、聯網的存儲。什麼樣的技術特性讓這兩種系統因而不一樣？這兩種存儲系統最終趨於融合是否大有意義？」
問題提出之後，很快有OpenStack的開發者進行了回復。本文在此摘抄了前兩名回復進行翻譯，以供各位參考。
排名第一的答案來自RackSpace的OpenStack Swift開發者Chuck Their：
雖然HDFS與Openstack對象存儲（Swift）之間有著一些相似之處，但是這兩種系統的總體設計卻大不一樣。
1. HDFS使用了中央系統來維護文件元數據（Namenode，名稱節點），而在Swift中，元數據呈分布式，跨集群復制。使用一種中央元數據系統對HDFS來說無異於單一故障點，因而擴展到規模非常大的環境顯得更困難。
2. Swift在設計時考慮到了多租戶架構，而HDFS沒有多租戶架構這個概念。
3. HDFS針對更龐大的文件作了優化（這是處理數據時通常會出現的情況），Swift被設計成了可以存儲任何大小的文件。
4. 在HDFS中，文件寫入一次，而且每次只能有一個文件寫入；而在Swift中，文件可以寫入多次；在並發操作環境下，以最近一次操作為准。
5. HDFS用Java來編寫，而Swift用Python來編寫。
另外，HDFS被設計成了可以存儲數量中等的大文件，以支持數據處理，而Swift被設計成了一種比較通用的存儲解決方案，能夠可靠地存儲數量非常多的大小不一的文件。
排名第二的答案來自Joshua McKenty，他是美國宇航局Nebula雲計算項目的首席架構師，是OpenStack Nova軟體的早期開發者之一，目前是OpenStack項目監管委員會的成員，還是Piston.cc這家基於OpenStack的公司的創始人。
Chuck剛才詳細介紹了兩者的技術差異，但是沒有討論兩者可想而知的融合，OpenStack設計峰會上拋出了融合這個話題。簡而言之，HDFS被設計成可以使用Hadoop，跨存儲環境裡面的對象實現MapRece處理。對於許多OpenStack公司（包括我自己的公司）來說，支持Swift裡面的處理是路線圖上面的一個目標，不過不是每個人都認為MapRece是解決之道。
我們已討論過為HDFS編寫包裝器，這將支持OpenStack內部存儲應用編程介面（API），並且讓用戶可以針對該數據來執行Hadoop查詢。還有一個辦法就是在Swift裡面使用HDFS。但是這些方法似乎沒有一個是理想的。
OpenStack社區方面也在開展研究開發方面的一些工作，認真研究其他替代性的MapRece框架（Riak和CouchDB等）。
最後，現在有別的一些存儲項目，目前「隸屬於」OpenStack社區（SheepDog和HC2）。充分利用數據局部性，並且讓對象存儲變得「更智能」，這是預計會取得進步的一個領域。

『柒』 hadoop和spark的區別

1、解決問題的層面不一樣

首先，Hadoop和Apache Spark兩者都是大數據框架，但是各自存在的目的不盡相同。Hadoop實質上更多是一個分布式數據基礎設施:它將巨大的數據集分派到一個由普通計算機組成的集群中的多個節點進行存儲，意味著您不需要購買和維護昂貴的伺服器硬體。
同時，Hadoop還會索引和跟蹤這些數據，讓大數據處理和分析效率達到前所未有的高度。Spark，則是那麼一個專門用來對那些分布式存儲的大數據進行處理的工具，它並不會進行分布式數據的存儲。

2、兩者可合可分

Hadoop除了提供為大家所共識的HDFS分布式數據存儲功能之外，還提供了叫做MapRece的數據處理功能。所以這里我們完全可以拋開Spark，使用Hadoop自身的MapRece來完成數據的處理。

相反，Spark也不是非要依附在Hadoop身上才能生存。但如上所述，畢竟它沒有提供文件管理系統，所以，它必須和其他的分布式文件系統進行集成才能運作。這里我們可以選擇Hadoop的HDFS,也可以選擇其他的基於雲的數據系統平台。但Spark默認來說還是被用在Hadoop上面的，畢竟，大家都認為它們的結合是最好的。

以下是從網上摘錄的對MapRece的最簡潔明了的解析：

• 我們要數圖書館中的所有書。你數1號書架，我數2號書架。這就是「Map」。我們人越多，數書就更快。

• 現在我們到一起，把所有人的統計數加在一起。這就是「Rece」。

3、Spark數據處理速度秒殺MapRece

Spark因為其處理數據的方式不一樣，會比MapRece快上很多。MapRece是分步對數據進行處理的: 」從集群中讀取數據，進行一次處理，將結果寫到集群，從集群中讀取更新後的數據，進行下一次的處理，將結果寫到集群，等等…「 Booz Allen Hamilton的數據科學家Kirk Borne如此解析。
反觀Spark，它會在內存中以接近「實時」的時間完成所有的數據分析：「從集群中讀取數據，完成所有必須的分析處理，將結果寫回集群，完成，」 Born說道。Spark的批處理速度比MapRece快近10倍，內存中的數據分析速度則快近100倍。
如果需要處理的數據和結果需求大部分情況下是靜態的，且你也有耐心等待批處理的完成的話，MapRece的處理方式也是完全可以接受的。
但如果你需要對流數據進行分析，比如那些來自於工廠的感測器收集回來的數據，又或者說你的應用是需要多重數據處理的，那麼你也許更應該使用Spark進行處理。
大部分機器學習演算法都是需要多重數據處理的。此外，通常會用到Spark的應用場景有以下方面：實時的市場活動，在線產品推薦，網路安全分析，機器日記監控等。

4、災難恢復

兩者的災難恢復方式迥異，但是都很不錯。因為Hadoop將每次處理後的數據都寫入到磁碟上，所以其天生就能很有彈性的對系統錯誤進行處理。
Spark的數據對象存儲在分布於數據集群中的叫做彈性分布式數據集(RDD: Resilient Distributed Dataset)中。這些數據對象既可以放在內存，也可以放在磁碟，所以RDD同樣也可以提供完成的災難恢復功能。

『捌』 從分布式存儲系統遷移至對象存儲系統有哪些難點

雖然HDFS與Openstack對象存儲（Swift）之間有著一些相似之處，但是這兩種系統的總體設計卻大不一樣。 1這家基於OpenStack的公司的創始人。 Chuck剛才詳細介紹了兩者的技術差異，但是沒有討論兩者可想而知的融合，OpenStack設計峰會上拋出了融合這個話題。簡而言之，HDFS被設計成可以使用Hadoop，跨存儲環境裡面的對象實現MapRece處理。對於許多OpenStack公司（包括我自己的公司）來說，支持Swift裡面的處理是路線圖上面的一個目標，不過不是每個人都認為MapRece是解決之道。 我們已討論過為HDFS編寫包裝器，這將支持OpenStack內部存儲應用編程介面（API），並且讓用戶可以針對該數據來執行Hadoop查詢。還有一個辦法就是在Swift裡面使用HDFS。但是這些方法似乎沒有一個是理想的。 OpenStack社區方面也在開展研究開發方面的一些工作，認真研究其他替代性的MapRece框架（Riak和CouchDB等）。 最後，現在有別的一些存儲項目，目前「隸屬於」OpenStack社區（SheepDog和HC2）。充分利用數據局部性，並且讓對象存儲變得「更智能」，這是預計會取得進步的一個領域。

『玖』 OpenStack 和 Hadoop 的區別是什麼

openstack是一個iaas雲平台（雲計算saas，paas，iaas中的iaas），是亞馬遜aws的開源實現。因涉及面忒廣，系統的解釋可能一時半會說不完，也說不全。從硬體到OS到虛擬化、中間件、消MQ、Web都有涉及。
hadoop是一個分布式的軟體架構，有分布式計算和分布式存儲。
或許這個問題延伸為「大數據與雲計算的區別」或者「openstack中的對象存儲swift與hadoop中的hdfs之間的區別會更有意義啊～～」

『拾』 對象存儲系統底層基於什麼系統來存取數據

記得在一篇介紹對象存儲的文章開頭這樣寫道「那些沒有為資料庫或文件系統寫過代碼的上了年紀的程序員應該不太可能會讀這篇文章。畢竟，一般商業應用程序訪問其他數據類型的模式已經存在超過 40年了。」 言下之意，對象存儲代表了新時代下的新型數據結構類型，但是對象存儲的出現也與存儲發展的歷史密不可分。在Web2.0、雲和數字內容爆發的時代，類似數字視頻和移動網路之類事物的增長，產生了極大量的非結構化數據。存儲廠商也推出了新的基於對象的存儲系統，從而來提供更加簡單的管理和具有更佳擴展性的元數據格式。相比傳統存儲，對象存儲的關鍵優勢在於其簡單性。由於對象存儲不依賴於LUNs和卷，因此新的存儲容量可以通過簡單配置加入到運行系統中，實現橫向擴展( scale-out)。 對象存儲與Hadoop 雲存儲 目前，對象存儲的規模部署則由雲服務所引領，如亞馬遜 S3、Facebook。現在，無論成熟廠商還是新興廠商的對象存儲解決方案都已達到相當的成熟度，因而IT部門開始考慮如何在自己企業中實現對象存儲。除了面向對象的存儲，還有基於Hadoop的雲存儲。中國惠普雲計算事業部高級產品經理呂洪在近期的視頻訪談中提到：「對於那些要求訪問控制的應用，對象存儲系統是個不錯的選擇，而用雲進行大數據分析的則要考慮Hadoop。」 對象存儲系統可以在一個持久穩固且高度可用的系統中存儲任意的對象，且獨立於虛擬機實例之外。應用和用戶可以在對象存儲中使用簡單的API訪問數據;這些通常都基於REST架構，但是也有面向編程語言的界面。 同時，需要在雲端進行大數據分析的用戶則可以考慮Hadoop雲存儲，比如AWS提供了彈性Map Rece (EMR)。雲存儲選擇適用於廣泛的需求，但是要針對你的需求找到正確的存儲類型，也意味著要找到延遲、易用性、數據完整性和成本之間的合適的平衡點。 對象存儲數據遷移和訪問 企業對存儲的訴求有一定的延續性，但其訪問的介質不外乎是主機、PC、移動端以及應用，針對不同的訪問介質來看，面向對象存儲的解決方案也有所不同。比如微信，我們可以在微信中上傳和訪問照片、視頻等內容，這是一種面向對象數據的訪問和存儲方式;然而如果應用軟體不支持HTTP下REST API的方式，需要以傳統文件伺服器協議的方式訪問，則需要在面向存儲對象前面加一個網關進行協議的轉換。 沒有了文件存儲系統中的NFS或CIFS來給應用提供數據，面向對象的存儲系統需要替換掉位於磁碟上的原始數據塊和應用可以理解的文件之間的這個抽象層。現在的面向對象的系統使用類似REST標準的API或者私有的API來告訴應用如何存儲和讀取對象標識。 總體而言，對於面向對象的存儲的操作的本質並不會改變。呂洪介紹：「比如我們熟悉的開源對象存儲系統OpenStack Swift。基本上就是POST，GET ，PUT和 DELETE操作，如果你需要上傳大量的數據，則需要編寫一個腳本就可以實現。」 惠普的對象存儲創新 OpenStack Swift是一種開源的對象存儲系統，以一種既滿足了存儲數據服務等級要求且經濟的方式實現。從高可用性以及安全穩定的角度上看，目前開源Swift並不如傳統廠商做的好，但是卻可以通過標準的伺服器，集合Swift搭建出一個能用且經濟的方案。 但是傳統廠商有自己的優勢，從對象存儲的設計結構來看分為三層，底層硬體基礎架構用來承載數據，在此之上則是面向對象的管理軟體，也就是系統層，最頂層為介面層，也就是用戶通過何種方式來存取數據。呂洪表示：「在這三個層次上面惠普的解決方案都有涉及。」 眾所周知，惠普一直以來都在基於OpenStack進行持續研發，推出更加符合企業級用戶要求的解決方案。此外，惠普實驗室中也在基於ProLiant x86伺服器，力求為swift尋找到一種更經濟的承載方式。惠普基於OpenStack Swift構建的Helion Content Depot則是第一款集成化的完整對象存儲解決方案，針對橫向擴展的對象存儲，提供當今企業存儲系統所需的高度可擴展性、易管理性、恢復能力和安全性。 呂洪提到：「預期不久的將來，惠普則會正式推出專門針對大數據的面相對象存儲的伺服器阿波羅4510。」據了解，阿波羅4510的一個機櫃中可以提供5.4PB的容量，這是在目前整個行業中，單機櫃容量最大的存儲解決方案。 除此之外，惠普還提供了面相對象存儲的數據加密工作，一部分確保用戶的數據在傳輸過程中是加密的，另一方面也首創硬體的加密，確保對象存儲數據的安全性。