大數(shù)據(jù)應用到數(shù)據(jù)集,其大小超出了常用軟件工具所能捕捉、管理和在可承受的時間內處理數(shù)據(jù)的能力。Big Data的規(guī)模在不斷變化,單一數(shù)據(jù)集的規(guī)模從幾十個TB漲到多個PB。
IDC估計到2011年數(shù)據(jù)約達到1.8ZB。
ZB有多大?答案是10億個TB。目前世界人口有7億也就是說,如果給每個人250G硬盤存儲空間仍然是不夠用的。
這次的數(shù)據(jù)洪流有諸多來源:
1. 紐約證券交易所每天產(chǎn)生1TB的新交易數(shù)據(jù);
2. Facebook主機存儲100億張照片會占用1PB空間;
3. Ancestry.com,家譜網(wǎng),存儲約2.5PB數(shù)據(jù);
4. 互聯(lián)網(wǎng)檔案館存儲約2PB數(shù)據(jù),并以每月約20TB的速度增長;
5. Geneva附近的Large Harden Colider每年將產(chǎn)生15PB的數(shù)據(jù);
6. 人們每天從傳感器、移動設備、網(wǎng)上交易和社交網(wǎng)絡創(chuàng)造相當于2.5萬億字節(jié)的數(shù)據(jù)。
Facebook、Yahoo和Google發(fā)現(xiàn)他們以空前的規(guī)模匯集數(shù)據(jù)。他們是第一批從上百萬用戶中匯集數(shù)據(jù)的大公司。
這些數(shù)據(jù)迅速淹沒了傳統(tǒng)的例如Oracle和MySQL等的數(shù)據(jù)系統(tǒng)。即便是最好的、最昂貴的供應商使用最大規(guī)模的硬件也只能勉強跟上,無法給他們有力的工具來分析數(shù)據(jù)的涌入。
在2000年初,開發(fā)諸如MapReduce、BigTable、Google File System的新技術來處理大數(shù)據(jù)。最初,這些技術是專有的。但隨后人們注意到公開的概念會更有利-因為越來越多的人會有助于此,并且他們雇傭的畢業(yè)生在加入他們之前對此也會有一個良好的理解。
在2004-2005年度,F(xiàn)acebook、Yahoo和Google開始共享描述他們大數(shù)據(jù)技術的研究論文。
2004年,Google發(fā)表題為“MapReduce:在大型集群上簡化數(shù)據(jù)處理(MapReduce: Simplified Data Processing on Large Clusters)”的論文。
MapReduce
是一個編程模型,同時也是一個處理和生成大型數(shù)據(jù)的工具。用戶指定映射函數(shù)來處理一對key-value以生成一個中間key-value的集合,指定reduce函數(shù)合并相同的中間鍵關聯(lián)的所有的中間值。正如這篇文章所寫,現(xiàn)實世界的許多工作都可以在這個模型中得以表達。
以此功能所編寫的程序自動并行,而且能在商品機大型集群上執(zhí)行。系統(tǒng)處理分割輸入數(shù)據(jù)的細節(jié),跨機器調度程序執(zhí)行,處理機器故障,管理所需的機器間的通訊。這樣使得沒有任何操作并行和分布式系統(tǒng)經(jīng)驗的程序員同樣可以輕松地利用大型分布式系統(tǒng)的資源。Google基于MapReduce實現(xiàn)在大型集群的商品機上運行并且這是高度可伸縮的。
一個典型的MapReduce在成百上千臺機器上處理大量的數(shù)據(jù)。設計器和系統(tǒng)是很容易使用的。數(shù)以百計的MapReduce程序已經(jīng)實施并且每天有超過一千的MapReduce工作在Google集群執(zhí)行。
Nutch
是一個開源的搜索技術,現(xiàn)在由Apache Software Foundation管理,而為其工作的Doug Cutting閱讀了由Google發(fā)表的此文和由Google分布式文件系統(tǒng)[GFS]發(fā)表的另一篇文章,指出GFS可以解決他們的存儲要求,MapReduce也會解決Nuth和實施MapReduce及GFS的縮放問題。他們把為Nutch實施的GFS命名為Nutch Distributed Filesystem[NDFS]。
NDFS和Nutch的MapReduce的實現(xiàn)超出了搜索領域,并于2006年2月遷移出Nutch構建成一個名為Hadoop和NDFS的獨立的Lucene子項目,成為HDFS[Hadoop分布式文件系統(tǒng)],這是一個GFS的實現(xiàn)。與此同時,Yahoo延長了他們對Hadoop的支持并雇傭了Doug Cutting。
在HDFS的工作層面,有一個300MB的文件[Hadoop的PB級和TB級文件非常好]。HDFS所需做的第一件事就是將它分割為若干塊。HDFS上的默認塊的大小為128MB。一旦把他們分割成塊,我們將得到分別為128MB和44MB的兩個部分。現(xiàn)在,HDFS將"n"["n"即是配置]作為每個塊的拷貝/副本的一部分。HDFS將這些副本存儲在集群的不同數(shù)據(jù)節(jié)點上。我們也有單一的保持著副本和數(shù)據(jù)節(jié)點路徑的數(shù)據(jù)NameNode。NameNode清楚副本在什么位置-每當它檢測到有副本損壞[DataNode一直在副本上進行校驗]或者相應的HDFS變?yōu)閐own,它將會尋找集群中該副本的其他副本,并告訴其他節(jié)點復制該副本的"n"。NameNode是一個單點故障-兩個點就會避免出現(xiàn)這種情況,我們會有與主要NameNode同步的次要NameNode-當主的變?yōu)閐own-從的將會起控制作用。Hadoop項目目前工作在分布式的NameNodes上。
Google在2006年又發(fā)表了一篇名為“Bigtable:一個結構化數(shù)據(jù)的分布式存儲系統(tǒng)(Bigtable: A Distributed Storage System for Structured Data)”的文章。
Bigtable
是一個管理結構化數(shù)據(jù)的分布式存儲系統(tǒng),它的設計擴展到一個非常大的規(guī)模,跨越了成千上萬服務器的PB級數(shù)據(jù)。Google許多項目的數(shù)據(jù)都存儲在Bigtable中,其中包括網(wǎng)頁索引、Google Earth和Google Finance。這些在Bigtable中的應用有不同的需求,不僅是在數(shù)據(jù)大小方面(從網(wǎng)頁地址到衛(wèi)星圖像)還有在延遲要求方面(從后臺數(shù)據(jù)處理到實時數(shù)據(jù)服務)。盡管這些需求不同,Bigtable為Google的產(chǎn)品提供了一個柔性的、高性能的解決方案。本文介紹了Bigtable中提供的簡單的數(shù)據(jù)模型,Bigtable使得客戶可以對數(shù)據(jù)的布局和格式進行動態(tài)控制,并且描述了Bigtable的設計和實施。
Bigtable映射任意兩個字符串值(行值和列值)和時間戳(三維映射)關聯(lián)的任意字節(jié)數(shù)組。這并不是個關系型數(shù)據(jù)庫,更應該定義為sparse,分布式多維分類映射。
Bigtable基本上討論了怎樣在GFS上建立分布式數(shù)據(jù)存儲。
由Hadoop所生成的HBase是一個BigTable的實現(xiàn)。HBase
是一個分布式、列導向的、利用HDFS為其底層存儲同時支持使用MapReduce和點查詢的批量計算的數(shù)據(jù)庫。
Amazon,在2007年出版了“Dynamo:亞馬遜高度可用Key-value存儲(Dynamo: Amazon"s Highly Available Key-value Store)”的文章。
Dynamo
是一個高度可用的Key-value存儲系統(tǒng),Amazon的核心服務提供一個“always-on”的技巧。Apache Cassandra匯集了Dynamo的完全分布式設計和BigTable的數(shù)據(jù)模型,用Java進行編寫,由Facebook發(fā)布的開源系統(tǒng)。這是個NoSQL的解決方案,最初由Facebook開發(fā),直到2010年底,增強他們的收件箱搜索功能。事實上,Cassandra最初的開發(fā)工作是由兩個由Facebook從Amazon招募的Dynamo工程師進行的。但是在2010年底當Facebook建立了基于HBase的信息平臺后便放棄了Cassandra。
此外,除了使用BigTable的建模方法,它具有類似于最終一致性的屬性,Gossip協(xié)議,master-master方式的讀服務和Amazon Dynamo產(chǎn)生的寫請求。最終一致性是其中一個重要的屬性,意味著在一段足夠長的時間內沒有發(fā)送更改信息,所有的更新都可以預期,最終系統(tǒng)和所有副本也將保持一致。
再說到Cassandra
時,使用了“NoSQL”一詞。NoSQL(有時候解釋為not only SQL)是數(shù)據(jù)庫管理系統(tǒng)的一個寬泛類,在一些重大方面,它不同于典型的關系型數(shù)據(jù)庫管理系統(tǒng)(RDBMS)。這些數(shù)據(jù)存儲不需要固定的表模式,通常能夠避免連接操作,可以進行橫向擴展。
“NoSQL”這個名字最初是由Carlo Strozzi在1998年提出的,作為由他開發(fā)的基于文件的數(shù)據(jù)庫的名稱。具有諷刺意味的是,它僅僅是個沒有SQL接口的關系型數(shù)據(jù)庫而已。當Eric Evans在2009年用它來命名非關系型數(shù)據(jù)庫的流沖擊(current surge)的時候,這個名字重新復出水面。
NoSQL數(shù)據(jù)庫有四個類別:
1. Key-value stores:基于Amazon的Dynamo文件;
2. ColumnFamily / BigTable clones:例如HBase、Cassandra;
3. Document Databases:例如CouchDB、MongoDB;
4. Graph Database:例如AllegroGrapgh、Neo4j。
正如Marin Dimitrov所言,以下是NoSQL數(shù)據(jù)庫的使用場合,換句話說,是關系型數(shù)據(jù)庫不適合執(zhí)行的情況。
1. 龐大的數(shù)據(jù)量;
2. 極端的查詢量;
3. 模式演化。
我們從NoSQL上可以得到高可擴展性、高可用性、低成本(與同等規(guī)模的解決方案相比)、可預見的彈性和架構靈活性的優(yōu)勢。
對于應用程序來說關系型數(shù)據(jù)庫和Cassandra的主要區(qū)別在于基于BigTable的數(shù)據(jù)模型。Cassandra數(shù)據(jù)模型是專為大規(guī)模的分布式數(shù)據(jù)所設計的。在性能、可用性和運算管理遵從慣有的優(yōu)勢。