NoSQL-HDFS-基本概念

Hadoop

創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括東莞網(wǎng)站建設(shè)、東莞網(wǎng)站制作、東莞網(wǎng)頁(yè)制作以及東莞網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃等。多年來(lái)，我們專(zhuān)注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，東莞網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到東莞省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

文件系統(tǒng)：文件系統(tǒng)是用來(lái)存儲(chǔ)和管理文件，并且提供文件的查詢、增加、刪除等操作。

直觀上的體驗(yàn)：在shell窗口輸入 ls 命令，就可以看到當(dāng)前目錄下的文件夾、文件。

文件存儲(chǔ)在哪里？硬盤(pán)

一臺(tái)只有250G硬盤(pán)的電腦，如果需要存儲(chǔ)500G的文件可以怎么辦？先將電腦硬盤(pán)擴(kuò)容至少250G，再將文件分割成多塊，放到多塊硬盤(pán)上儲(chǔ)存。

通過(guò) hdfs dfs -ls 命令可以查看分布式文件系統(tǒng)中的文件，就像本地的ls命令一樣。

HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實(shí)現(xiàn)將分布在多臺(tái)機(jī)器上的文件系統(tǒng)進(jìn)行統(tǒng)一的管理。

在分布式文件系統(tǒng)中，一個(gè)大文件會(huì)被切分成塊，分別存儲(chǔ)到幾臺(tái)機(jī)器上。結(jié)合上文中提到的那個(gè)存儲(chǔ)500G大文件的那個(gè)例子，這500G的文件會(huì)按照一定的大小被切分成若干塊，然后分別存儲(chǔ)在若干臺(tái)機(jī)器上，然后提供統(tǒng)一的操作接口。

看到這里，不少人可能會(huì)覺(jué)得，分布式文件系統(tǒng)不過(guò)如此，很簡(jiǎn)單嘛。事實(shí)真的是這樣的么？

潛在問(wèn)題

假如我有一個(gè)1000臺(tái)機(jī)器組成的分布式系統(tǒng)，一臺(tái)機(jī)器每天出現(xiàn)故障的概率是0.1%，那么整個(gè)系統(tǒng)每天出現(xiàn)故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一個(gè)容錯(cuò)機(jī)制來(lái)保證發(fā)生差錯(cuò)時(shí)文件依然可以讀出，這里暫時(shí)先不展開(kāi)介紹。

如果要存儲(chǔ)PB級(jí)或者EB級(jí)的數(shù)據(jù)，成千上萬(wàn)臺(tái)機(jī)器組成的集群是很常見(jiàn)的，所以說(shuō)分布式系統(tǒng)比單機(jī)系統(tǒng)要復(fù)雜得多呀。

這是一張HDFS的架構(gòu)簡(jiǎn)圖：

client通過(guò)nameNode了解數(shù)據(jù)在哪些DataNode上，從而發(fā)起查詢。此外，不僅是查詢文件，寫(xiě)入文件的時(shí)候也是先去請(qǐng)教N(yùn)ameNode，看看應(yīng)該往哪個(gè)DateNode中去寫(xiě)。

為了某一份數(shù)據(jù)只寫(xiě)入到一個(gè)Datanode中，而這個(gè)Datanode因?yàn)槟承┰虺鲥e(cuò)無(wú)法讀取的問(wèn)題，需要通過(guò)冗余備份的方式來(lái)進(jìn)行容錯(cuò)處理。因此，HDFS在寫(xiě)入一個(gè)數(shù)據(jù)塊的時(shí)候，不會(huì)僅僅寫(xiě)入一個(gè)DataNode，而是會(huì)寫(xiě)入到多個(gè)DataNode中，這樣，如果其中一個(gè)DataNode壞了，還可以從其余的DataNode中拿到數(shù)據(jù)，保證了數(shù)據(jù)不丟失。

實(shí)際上，每個(gè)數(shù)據(jù)塊在HDFS上都會(huì)保存多份，保存在不同的DataNode上。這種是犧牲一定存儲(chǔ)空間換取可靠性的做法。

接下來(lái)我們來(lái)看一下完整的文件寫(xiě)入的流程：

大文件要寫(xiě)入HDFS，client端根據(jù)配置將大文件分成固定大小的塊，然后再上傳到HDFS。

讀取文件的流程：

1、client詢問(wèn)NameNode，我要讀取某個(gè)路徑下的文件，麻煩告訴我這個(gè)文件都在哪些DataNode上？

2、NameNode回復(fù)client，這個(gè)路徑下的文件被切成了3塊，分別在DataNode1、DataNode3和DataNode4上

3、client去找DataNode1、DataNode3和DataNode4，拿到3個(gè)文件塊，通過(guò)stream讀取并且整合起來(lái)

文件寫(xiě)入的流程：

1、client先將文件分塊，然后詢問(wèn)NameNode，我要寫(xiě)入一個(gè)文件到某個(gè)路徑下，文件有3塊，應(yīng)該怎么寫(xiě)？

2、NameNode回復(fù)client，可以分別寫(xiě)到DataNode1、DataNode2、DataNode3、DataNode4上，記住，每個(gè)塊重復(fù)寫(xiě)3份，總共是9份

3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數(shù)據(jù)寫(xiě)到他們上面

出于容錯(cuò)的考慮，每個(gè)數(shù)據(jù)塊有3個(gè)備份，但是3個(gè)備份快都直接由client端直接寫(xiě)入勢(shì)必會(huì)帶來(lái)client端過(guò)重的寫(xiě)入壓力，這個(gè)點(diǎn)是否有更好的解決方案呢？回憶一下mysql主備之間是通過(guò)binlog文件進(jìn)行同步的，HDFS當(dāng)然也可以借鑒這個(gè)思想，數(shù)據(jù)其實(shí)只需要寫(xiě)入到一個(gè)datanode上，然后由datanode之間相互進(jìn)行備份同步，減少了client端的寫(xiě)入壓力，那么至于是一個(gè)datanode寫(xiě)入成功即成功，還是需要所有的參與備份的datanode返回寫(xiě)入成功才算成功，是可靠性配置的策略，當(dāng)然這個(gè)設(shè)置會(huì)影響到數(shù)據(jù)寫(xiě)入的吞吐率，我們可以看到可靠性和效率永遠(yuǎn)是“魚(yú)和熊掌不可兼得”的。

潛在問(wèn)題

NameNode確實(shí)會(huì)回放editlog，但是不是每次都從頭回放，它會(huì)先加載一個(gè)fsimage，這個(gè)文件是之前某一個(gè)時(shí)刻整個(gè)NameNode的文件元數(shù)據(jù)的內(nèi)存快照，然后再在這個(gè)基礎(chǔ)上回放editlog，完成后，會(huì)清空editlog，再把當(dāng)前文件元數(shù)據(jù)的內(nèi)存狀態(tài)寫(xiě)入fsimage，方便下一次加載。

這樣，全量回放就變成了增量回放，但是如果NameNode長(zhǎng)時(shí)間未重啟過(guò)，editlog依然會(huì)比較大，恢復(fù)的時(shí)間依然比較長(zhǎng)，這個(gè)問(wèn)題怎么解呢？

SecondNameNode是一個(gè)NameNode內(nèi)的定時(shí)任務(wù)線程，它會(huì)定期地將editlog寫(xiě)入fsimage，然后情況原來(lái)的editlog，從而保證editlog的文件大小維持在一定大小。

NameNode掛了， SecondNameNode并不能替代NameNode，所以如果集群中只有一個(gè)NameNode，它掛了，整個(gè)系統(tǒng)就掛了。hadoop2.x之前，整個(gè)集群只能有一個(gè)NameNode，是有可能發(fā)生單點(diǎn)故障的，所以hadoop1.x有本身的不穩(wěn)定性。但是hadoop2.x之后，我們可以在集群中配置多個(gè)NameNode，就不會(huì)有這個(gè)問(wèn)題了，但是配置多個(gè)NameNode，需要注意的地方就更多了，系統(tǒng)就更加復(fù)雜了。

俗話說(shuō)“一山不容二虎”，兩個(gè)NameNode只能有一個(gè)是活躍狀態(tài)active，另一個(gè)是備份狀態(tài)standby，我們看一下兩個(gè)NameNode的架構(gòu)圖。

兩個(gè)NameNode通過(guò)JournalNode實(shí)現(xiàn)同步editlog，保持狀態(tài)一致可以相互替換。

因?yàn)閍ctive的NameNode掛了之后，standby的NameNode要馬上接替它，所以它們的數(shù)據(jù)要時(shí)刻保持一致，在寫(xiě)入數(shù)據(jù)的時(shí)候，兩個(gè)NameNode內(nèi)存中都要記錄數(shù)據(jù)的元信息，并保持一致。這個(gè)JournalNode就是用來(lái)在兩個(gè)NameNode中同步數(shù)據(jù)的，并且standby NameNode實(shí)現(xiàn)了SecondNameNode的功能。

進(jìn)行數(shù)據(jù)同步操作的過(guò)程如下：

active NameNode有操作之后，它的editlog會(huì)被記錄到JournalNode中，standby NameNode會(huì)從JournalNode中讀取到變化并進(jìn)行同步，同時(shí)standby NameNode會(huì)監(jiān)聽(tīng)記錄的變化。這樣做的話就是實(shí)時(shí)同步了，并且standby NameNode就實(shí)現(xiàn)了SecondNameNode的功能。

優(yōu)點(diǎn)：

缺點(diǎn)：

如何安裝和配置Cassandra

Cassandra屬于最近比較流行的一款NoSQL數(shù)據(jù)庫(kù) 中給NoSQL的定義如下：

下一代的數(shù)據(jù)庫(kù)產(chǎn)品應(yīng)該具備這幾點(diǎn)：非關(guān)系型的，分布式的，開(kāi)源的，可以線性擴(kuò)展的。這類(lèi)數(shù)據(jù)庫(kù)最初的目的在于提供現(xiàn)代網(wǎng)站可擴(kuò)展的數(shù)據(jù)庫(kù)解決方案。這個(gè)運(yùn)動(dòng)開(kāi)始于2009年初，目前正在迅速的發(fā)展。這種類(lèi)型的數(shù)據(jù)庫(kù)具有：自由的schema，數(shù)據(jù)多處備份，簡(jiǎn)單的編程API，數(shù)據(jù)的最終一致性保證等等。所以我們將這種類(lèi)型的數(shù)據(jù)庫(kù)稱(chēng)為NoSQL（不僅僅是SQL，全稱(chēng)為“not only sql”）。

下面我們一起來(lái)看看如果分別在Windows和Linux環(huán)境下安裝和部署Cassandra。

在WINDOWS上單機(jī)運(yùn)行CASSANDRA

大多數(shù)人使用的OS都是Windows，所以如果只是想簡(jiǎn)單地測(cè)試一下Cassandra，我們可以直接在安裝好JDK1.6的Windows系統(tǒng)上安裝Cassandra，并進(jìn)行簡(jiǎn)單的測(cè)試。

1 下載Cassandra

下載即可。目前最新的beta版本是0.6.0 b3，但是我們安裝使用的最新的Release版本0.5.1。

2 安裝Cassandra

將下載的壓縮包解壓，假設(shè)解壓的位置是D:\apache-cassandra-0.5.1。

1 修改conf目錄下的log4j.properties文件：

log4j.appender.R.File=D:\apache-cassandra-0.5.1\logs

2 修改conf目錄下的storage-conf.xml文件：

CommitLogDirectoryD:\apache-cassandra-0.5.1\commitlog/CommitLogDirectory

DataFileDirectories

DataFileDirectoryD:\apache-cassandra-0.5.1\data/DataFileDirectory

/DataFileDirectories

CalloutLocationD:\apache-cassandra-0.5.1\callouts/CalloutLocation

StagingFileDirectoryD:\apache-cassandra-0.5.1\staging/StagingFileDirectory

3 設(shè)置系統(tǒng)的環(huán)境變量：

CASSANDRA_HOME=D:\apache-cassandra-0.5.1

3 啟動(dòng)Cassandra

運(yùn)行bin目錄下的cassandra.bat。如果看到：INFO - Starting up server gossip，那么恭喜你，Cassandra已經(jīng)在你的本機(jī)啟動(dòng)起來(lái)了。

4 使用命令行進(jìn)行簡(jiǎn)單的測(cè)試

運(yùn)行bin目錄下的cassandra-cli.bat。輸入：connect localhost 9160，連接成功后可以看到下面的提示。

cassandra connect localhost 9160

line 1:18 missing SLASH at '9160'

Connected to localhost/9160

然后，我們可以參考README.txt文件中提供的范例進(jìn)行測(cè)試：

cassandra set Keyspace1.Standard1['jsmith']['first'] = 'John'

Value inserted.

cassandra set Keyspace1.Standard1['jsmith']['last'] = 'Smith'

Value inserted.

cassandra set Keyspace1.Standard1['jsmith']['age'] = '42'

Value inserted.

cassandra get Keyspace1.Standard1['jsmith']

(column=age, value=42; timestamp=1249930062801)

(column=first, value=John; timestamp=1249930053103)

(column=last, value=Smith; timestamp=1249930058345)

Returned 3 rows.

cassandra

你也可以根據(jù)這篇文章《談?wù)凜assandra的客戶端》中的內(nèi)容測(cè)試一下如何使用Java編寫(xiě)簡(jiǎn)單的程序和Cassandra交互。

在LINUX上運(yùn)行CASSANDRA集群

如果需要真正在生產(chǎn)環(huán)境中使用Cassandra，我們需要搭建一個(gè)Cassandra集群，這樣才能真正發(fā)揮出它作為NoSQL數(shù)據(jù)所應(yīng)該具備的特性。

在Linux部署Cassandra的步驟基本與Windows上部署的類(lèi)似，我們需要在每一臺(tái)機(jī)器上安裝JDK1.6，然后下載Cassandra，并修改log4j.properties和storage-conf.xml的配置文件和設(shè)置環(huán)境變量。不同的是，我們需要在storage-conf.xml文件中配置集群的信息：

1 配置集群

1 配置集群節(jié)點(diǎn)信息

Seeds

Seedhadoop2/Seed

Seedhadoop3/Seed

Seedhadoop4/Seed

Seedhadoop5/Seed

Seedhadoop6/Seed

Seedhadoop7/Seed

Seedhadoop8/Seed

Seedhadoop9/Seed

Seedhadoop10/Seed

/Seeds

2 配置集群節(jié)點(diǎn)之間交互的監(jiān)聽(tīng)地址

直接留空即可：

ListenAddress/ListenAddress

3 配置Thrift Server監(jiān)聽(tīng)的地址

直接留空即可：

ThriftAddress/ThriftAddress

4 配置集群的名稱(chēng)

每一個(gè)集群的名稱(chēng)都應(yīng)該是不用的

ClusterNamegpcuster.cnblogs.com/ClusterName

5 開(kāi)啟節(jié)點(diǎn)自動(dòng)加入集群的功能

AutoBootstraptrue/AutoBootstrap

6 配置數(shù)據(jù)的備份數(shù)

ReplicationFactor3/ReplicationFactor

7 調(diào)節(jié)Memory和Disk的性能

需要根據(jù)實(shí)際的情況來(lái)配置，可以參考Wiki。

2 運(yùn)行Cassandra

在每一臺(tái)節(jié)點(diǎn)上，運(yùn)行bin/cassandra。如果看到：INFO - Starting up server gossip，說(shuō)明啟動(dòng)成功。

如何根據(jù)性能選擇內(nèi)存NoSQL數(shù)據(jù)庫(kù)

本文主要內(nèi)容是測(cè)試了不同NoSQL數(shù)據(jù)庫(kù)在測(cè)試工具YCSB中的表現(xiàn)。我們選取了3款流行的內(nèi)存(in-memory)數(shù)據(jù)庫(kù)管理系統(tǒng)：Redis，Tarantool 以及 CouchBase，還有緩存系統(tǒng)Memchached。Memchached雖然不屬于數(shù)據(jù)庫(kù)管理系統(tǒng)但常作為快速存儲(chǔ)系統(tǒng)使用。

測(cè)試環(huán)境由4臺(tái)在Microsoft Azure Cloud中的虛擬機(jī)組成的計(jì)算機(jī)組組成。這些虛擬機(jī)同屬于一個(gè)數(shù)據(jù)中心。nosql-1和nosql-2用作測(cè)試Tarantool和CouchBase，nosql-3和nosql-4用作測(cè)試Redis，Azure Redis Cache 以及 Memcached。這些機(jī)器都安裝和配置了相應(yīng)數(shù)據(jù)庫(kù)和測(cè)試項(xiàng)目。虛擬機(jī)的配置為4核A3 CPU，7GB RAM，120GB硬盤(pán)。

數(shù)據(jù)庫(kù)及設(shè)置

內(nèi)存數(shù)據(jù)庫(kù)管理系統(tǒng)會(huì)存儲(chǔ)所有在主內(nèi)存中的數(shù)據(jù)并在磁碟上進(jìn)行持續(xù)更新操作；透過(guò)日志記錄每個(gè)數(shù)據(jù)的修改以確保連貫性。由于是以append-only方式進(jìn)行日志寫(xiě)入，因此它很少遇到瓶頸問(wèn)題；讀取/寫(xiě)入都不會(huì)造成頻繁的磁碟頭移動(dòng)。

Redis在2009推出，目前的最新版本是3.0.5。我們這里使用的版本是3.0.4，以append-only(只附加)方式進(jìn)行數(shù)據(jù)管理，與其配合使用的是Microsoft Azure Redis Cache工具。

Tarantool是一款開(kāi)源NoSQL數(shù)據(jù)庫(kù)管理系統(tǒng)。我們使用的是Tarantool 1.6.7-126-gb35aff9，日志采用write-ahead(先寫(xiě))模式。Memcached是一款分布式內(nèi)存緩存系統(tǒng)，這里使用是Memcached 1.4.14-0ubuntu9。

Couchbase Server是開(kāi)源分布式NoSQL面向文檔數(shù)據(jù)庫(kù)，這里使用的版本是Couchbase 4.0.0-4047-1。

YCSB測(cè)試工具

Yahoo! Cloud Serving Benchmark(YCSB)是功能強(qiáng)大的NoSQL數(shù)據(jù)庫(kù)性能測(cè)試工具，它提供了6種主要的負(fù)載工作類(lèi)型，以字母A到F來(lái)區(qū)分。

負(fù)載A負(fù)責(zé)更新操作，極值是50/50的讀寫(xiě)操作，如用于進(jìn)行新近操作記錄。負(fù)載B負(fù)責(zé)讀取操作，極值是95/5的讀寫(xiě)操作，如用于進(jìn)行圖片標(biāo)簽管理，多進(jìn)行標(biāo)簽讀取操作。負(fù)載C負(fù)載100%的讀取操作，如用于進(jìn)行用戶屬性獲取。負(fù)載D以先進(jìn)先出方式進(jìn)行插入操作，如用戶進(jìn)行最新數(shù)據(jù)讀取。負(fù)載E負(fù)責(zé)小范圍記錄讀取而不是單個(gè)記錄讀取，如線程會(huì)話。負(fù)載F負(fù)責(zé)記錄的讀取，修改和寫(xiě)入，如用戶信息管理。

我們對(duì)配置文件作了兩處參數(shù)修改：數(shù)據(jù)條目recordcount設(shè)為200000，操作條目operationcount設(shè)為5000000。YCSB是多線程工具，我們將以8, 16, 32, 64, 128 及256 線程來(lái)進(jìn)行測(cè)試。詳細(xì)的測(cè)試腳本請(qǐng)點(diǎn)擊這里進(jìn)行下載。

下列測(cè)試結(jié)果圖以顏色進(jìn)行測(cè)試對(duì)象區(qū)分，

Tarantool (HASH) （藍(lán)）

Tarantool (TREE)（淺藍(lán)）

Redis （紅）

Azure Redis Cache （橙）

Memcached （綠）

CouchBase（黑）

更多圖片請(qǐng)點(diǎn)擊［這里］查看。

結(jié)論

Tarantool在所有負(fù)載類(lèi)型測(cè)試中皆取得了最優(yōu)成績(jī)。它創(chuàng)建了一個(gè)無(wú)鎖內(nèi)存引擎，以協(xié)同多任務(wù)方式進(jìn)行操作而不是互斥或并行處理方式。根據(jù)以下性能圖表現(xiàn)，我們的結(jié)論是Tarantool的高吞吐量處理是其最大優(yōu)勢(shì)之一。因此在多數(shù)場(chǎng)合下，Tarantool是用戶的最佳選擇。