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