NoSQL-HDFS-基本概念

Hadoop

成都創(chuàng)新互聯(lián)公司自2013年創(chuàng)立以來，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢想脫穎而出為使命，1280元府谷做網(wǎng)站,已為上家服務(wù),為府谷各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18980820575

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

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

文件存儲在哪里？硬盤

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

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

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

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

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

潛在問題

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

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

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

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

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

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

接下來我們來看一下完整的文件寫入的流程：

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

讀取文件的流程：

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

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

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

文件寫入的流程：

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

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

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

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

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

SecondNameNode是一個(gè)NameNode內(nèi)的定時(shí)任務(wù)線程，它會(huì)定期地將editlog寫入fsimage，然后情況原來的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è)問題了，但是配置多個(gè)NameNode，需要注意的地方就更多了，系統(tǒng)就更加復(fù)雜了。

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

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

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

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

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

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

缺點(diǎn)：

互聯(lián)網(wǎng)的核心要義是什么？

現(xiàn)在的互聯(lián)網(wǎng)+，不過是練了個(gè)吸星大法，但吸進(jìn)來的內(nèi)力，如果不消化好，就很快會(huì)反噬，您說呢，令狐少俠

據(jù)株洲日報(bào)報(bào)道，近年來，株洲水電氣、公交等公用事業(yè)單位紛紛推出自己的App應(yīng)用。盡管在報(bào)道中亦提到，部分此類App仍不支持移動(dòng)支付功能，或僅支持銀行卡額，不支持微信或支付寶之類的第三方支付，距離老百姓還有“最后一公里”的問題。

但即使解決移動(dòng)支付這個(gè)便捷性問題，就算是解決了最后一公里嗎？愚以為不然，這恰恰是包括公用事業(yè)在內(nèi)的許多消費(fèi)類App們的認(rèn)知上的瓶頸所在，即在他們看來，互聯(lián)網(wǎng)+的核心要義，就是解決一個(gè)排隊(duì)難的問題。

當(dāng)然，不得不承認(rèn)，這樣的互聯(lián)網(wǎng)思維，已經(jīng)比只是簡單地讓自己的產(chǎn)品、服務(wù)展示在網(wǎng)絡(luò)上，把互聯(lián)網(wǎng)+看做是聯(lián)網(wǎng)要強(qiáng)上許多。而且低段位的互聯(lián)網(wǎng)+確實(shí)也是用這種方式來撈取第一波用戶的。

畢竟排隊(duì)在中國一直都是個(gè)難題，這里面涉及到一個(gè)時(shí)間成本的問題，通過互聯(lián)網(wǎng)，讓用戶不用到線下的窗口，直接可以網(wǎng)上支付了“門票”，然后按照約定的時(shí)間來吃飯、看電影、逛景點(diǎn)，或者如水電煤氣之類的服務(wù)，足不出戶就把事情給辦了，自然是皆大歡喜。

但這其實(shí)只是互聯(lián)網(wǎng)+的起手式，只是通過互聯(lián)網(wǎng)，拉近了和用戶之間的交易距離，說白了，就是繳費(fèi)方便了，但心與心的距離，還是很遙遠(yuǎn)。

接下來的事情更重要，通過網(wǎng)絡(luò)能夠減少雙方的時(shí)間成本和各種空耗沒了，但互聯(lián)網(wǎng)+最后的落實(shí)之處還是在線下，而不是僅僅一個(gè)網(wǎng)上快捷繳費(fèi)。線下比拼的是什么？服務(wù)二字而已。

對于那些做獨(dú)家生意的App來說，或許這樣的感覺還不明顯。但對于其他競爭壓力頗大的互聯(lián)網(wǎng)+項(xiàng)目來說，比如外賣、電影、美容美發(fā)之類，則頗為鮮明，客人最終決定是否長期光顧，還是要在線下體驗(yàn)了你的服務(wù)確實(shí)不錯(cuò)之后，才會(huì)形成黏性。線上付費(fèi)也好、各種折扣也罷，不過是一個(gè)最初用來招攬客人入口罷了，何況同樣的入口還有很多。為何選擇你，用戶體驗(yàn)好、服務(wù)有特色，依然是不二法門。

尤其是在同行們都互聯(lián)網(wǎng)+之后，其實(shí)比拼又回到了服務(wù)這個(gè)原始起點(diǎn)之上。再多問一句然后呢？其實(shí)互聯(lián)網(wǎng)+的另一層深意也就在此體現(xiàn)，比如早前在網(wǎng)約車和出租車的比拼中，出租車為何頻頻落于下風(fēng)？除了網(wǎng)約車多了個(gè)更精準(zhǔn)的網(wǎng)上攬客手段，在服務(wù)上也頗為個(gè)性化之外。網(wǎng)約車平臺也在憋大招，比如通過大數(shù)據(jù)，根據(jù)地圖和約車熱度對用戶群體進(jìn)行畫像，然后給網(wǎng)約車們更多的攬客建議；又如百度外賣，甚至整出了個(gè)智能物流調(diào)度系統(tǒng)，用人工智能為平臺里的商戶們送餐，合理規(guī)劃最佳路線，而且還是根據(jù)路況來實(shí)時(shí)制定的……

網(wǎng)上繳費(fèi)沒變、基礎(chǔ)服務(wù)也未必立刻得到了升級，比如菜的口味總不是一朝一夕改變的，但互聯(lián)網(wǎng)+里面其實(shí)還可以納入更多技術(shù)元素，來讓服務(wù)變得“不一樣”起來。

或許，對于苦于找不到風(fēng)口的眾創(chuàng)企業(yè)們來說，為App們提供支付之外的技術(shù)服務(wù)，也是個(gè)商機(jī)。

mySQL的替代方案

隨著 MySQL 被 Oracle 收購，MySQL 的用戶和開發(fā)者開始質(zhì)疑開源數(shù)據(jù)庫的命運(yùn)，與此同時(shí)他們開始尋找替代品。

有文章寫到了放棄 MySQL 的五大理由： MySQL 不如其它關(guān)系型數(shù)據(jù)庫管理系統(tǒng)那樣成熟； MySQL 是開源的...但只有近似而已； MySQL 的性能無法與競爭對手相提并論； MySQL 是 Oracle 所有的，而不是社區(qū)驅(qū)動(dòng)的； 越來越多的強(qiáng)勁對手。 從 MySQL 轉(zhuǎn)向 MariaDB的代表廠家：谷歌（2013年9月）、RedHat（2013年6月）、維基百科（2013年4月）

MySQL 在 2008 年被Sun以10億美金所收購，MySQL 創(chuàng)始人 Michael Widenius 則不滿 Sun 開發(fā)團(tuán)隊(duì)腳步過慢，憤而離職成立開源數(shù)據(jù)庫聯(lián)盟，另外從現(xiàn)有 MySQL 程序代碼中，開發(fā)出另一個(gè)延伸分支版本，也就是名為瑪莉亞數(shù)據(jù)庫的企業(yè)級開源數(shù)據(jù)庫 。

瑪莉亞數(shù)據(jù)庫如同 MySQL 的影子版本，瑪莉亞數(shù)據(jù)庫是 MySQL 的一個(gè)分支版本（branch），而不是衍生版本（folk），提供的功能可和 MySQL 完全兼容。 從 MySQL 轉(zhuǎn)向 PostgreSQL的代表廠家：蘋果（2011年）

PostgreSQL是一個(gè)自由的對象-關(guān)系數(shù)據(jù)庫服務(wù)器(數(shù)據(jù)庫管理系統(tǒng))。PostgreSQL支持大部分 SQL標(biāo)準(zhǔn)并且提供了許多其他現(xiàn)代特性：復(fù)雜查詢、外鍵、觸發(fā)器、視圖、事務(wù)完整性、MVCC。同樣，PostgreSQL 可以用許多方法擴(kuò)展，比如， 通過增加新的數(shù)據(jù)類型、函數(shù)、操作符、聚集函數(shù)、索引方法、過程語言。并且，因?yàn)樵S可證的靈活，任何人都可以以任何目的免費(fèi)使用、修改、和分發(fā) PostgreSQL，不管是私用、商用、還是學(xué)術(shù)研究使用。

PostgreSQL 也受 NoSQL 思想的啟發(fā)，希望能夠在今后可以給使用者更多可定制可調(diào)節(jié)的功能（不是說這個(gè)成熟的關(guān)系性數(shù)據(jù)庫系統(tǒng)要向 NoSQL 轉(zhuǎn)變）。 NoSQL(NoSQL = Not Only SQL)，意即“不僅僅是 SQL”，是一項(xiàng)全新的數(shù)據(jù)庫革命性運(yùn)動(dòng)。NoSQL指的是非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng) web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付 web2.0 網(wǎng)站，特別是超大規(guī)模和高并發(fā)的 SNS 類型的 web2.0 純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。

其代表的開源軟件如：Membase、MongoDB、Hypertable、Apache Cassandra、CouchDB等。 Oracle自 Oracle 10g 后推出對應(yīng)的免費(fèi)版。

如何擺脫現(xiàn)有關(guān)系數(shù)據(jù)庫的思想來設(shè)計(jì) NoSQL 數(shù)據(jù)庫？

關(guān)系是客觀存在的自然規(guī)律，擺脫就是在修改事實(shí)模型。

用NOSQL，我覺得可以理解成關(guān)系模型的變化，而不是另起爐灶。

技術(shù)選型 - OLAP大數(shù)據(jù)技術(shù)哪家強(qiáng)？

Lambda架構(gòu)的核心理念是“流批一體化”，因?yàn)殡S著機(jī)器性能和數(shù)據(jù)框架的不斷完善，用戶其實(shí)不關(guān)心底層是如何運(yùn)行的，批處理也好，流式處理也罷，能按照統(tǒng)一的模型返回結(jié)果就可以了，這就是Lambda架構(gòu)誕生的原因。現(xiàn)在很多應(yīng)用，例如Spark和Flink，都支持這種結(jié)構(gòu)，也就是數(shù)據(jù)進(jìn)入平臺后，可以選擇批處理運(yùn)行，也可以選擇流式處理運(yùn)行，但不管怎樣，一致性都是相同的。

Kylin

Kylin的主要特點(diǎn)是預(yù)計(jì)算，提前計(jì)算好各個(gè)cube，這樣的優(yōu)點(diǎn)是查詢快速，秒級延遲；缺點(diǎn)也非常明顯，靈活性不足，無法做一些 探索 式的，關(guān)聯(lián)性的數(shù)據(jù)分析。

適合的場景也是比較固定的，場景清晰的地方。

ClickHouse

Clickhouse由俄羅斯yandex公司開發(fā)。專為在線數(shù)據(jù)分析而設(shè)計(jì)。

Clickhouse最大的特點(diǎn)首先是快 ，為了快采用了列式儲存，列式儲存更好的支持壓縮，壓縮后的數(shù)據(jù)傳輸量變小，所以更快；同時(shí)支持分片，支持分布式執(zhí)行，支持SQL。

ClickHouse很輕量級，支持?jǐn)?shù)據(jù)壓縮和最終數(shù)據(jù)一致性，其數(shù)據(jù)量級在PB級別。

另外Clickhouse不是為關(guān)聯(lián)分析而生，所以多表關(guān)聯(lián)支持的不太好。

同樣Clickhouse不能修改或者刪除數(shù)據(jù)，僅能用于批量刪除或修改。沒有完整的事務(wù)支持，不支持二級索引等等，缺點(diǎn)也非常明顯。

與Kylin相比ClickHouse更加的靈活，sql支持的更好，但是相比Kylin，ClickHouse不支持大并發(fā)，也就是不能很多訪問同時(shí)在線。

總之ClickHouse用于在線數(shù)據(jù)分析，支持功能簡單。CPU 利用率高，速度極快。最好的場景用于行為統(tǒng)計(jì)分析。

Hive

Hive這個(gè)工具，大家一定很熟悉，大數(shù)據(jù)倉庫的首選工具。可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，并提供完整的sql查詢功能。

主要功能是可以將sql語句轉(zhuǎn)換為相對應(yīng)的MapReduce任務(wù)進(jìn)行運(yùn)行，這樣可能處理海量的數(shù)據(jù)批量，

Hive與HDFS結(jié)合緊密，在大數(shù)據(jù)開始初期，提供一種直接使用sql就能訪問HDFS的方案，擺脫了寫MapReduce任務(wù)的方式，極大的降低了大數(shù)據(jù)的門檻。

當(dāng)然Hive的缺點(diǎn)非常明顯，定義的是分鐘級別的查詢延遲，估計(jì)都是在比較理想的情況。 但是作為數(shù)據(jù)倉庫的每日批量工具，的確是一個(gè)穩(wěn)定合格的產(chǎn)品。

Presto

Presto極大的改進(jìn)了Hive的查詢速度，而且Presto 本身并不存儲數(shù)據(jù)，但是可以接入多種數(shù)據(jù)源，并且支持跨數(shù)據(jù)源的級聯(lián)查詢，支持包括復(fù)雜查詢、聚合、連接等等。

Presto沒有使用MapReduce，它是通過一個(gè)定制的查詢和執(zhí)行引擎來完成的。它的所有的查詢處理是在內(nèi)存中，這也是它的性能很高的一個(gè)主要原因。

Presto由于是基于內(nèi)存的，缺點(diǎn)可能是多張大表關(guān)聯(lián)操作時(shí)易引起內(nèi)存溢出錯(cuò)誤。

另外Presto不支持OLTP的場景，所以不要把Presto當(dāng)做數(shù)據(jù)庫來使用。

Presto相比ClickHouse優(yōu)點(diǎn)主要是多表join效果好。相比ClickHouse的支持功能簡單，場景支持單一，Presto支持復(fù)雜的查詢，應(yīng)用范圍更廣。

Impala

Impala是Cloudera 公司推出，提供對 HDFS、Hbase 數(shù)據(jù)的高性能、低延遲的交互式 SQL 查詢功能。

Impala 使用 Hive的元數(shù)據(jù), 完全在內(nèi)存中計(jì)算。是CDH 平臺首選的 PB 級大數(shù)據(jù)實(shí)時(shí)查詢分析引擎。

Impala 的缺點(diǎn)也很明顯，首先嚴(yán)重依賴Hive，而且穩(wěn)定性也稍差，元數(shù)據(jù)需要單獨(dú)的mysql/pgsql來存儲，對數(shù)據(jù)源的支持比較少，很多nosql是不支持的。但是，估計(jì)是cloudera的國內(nèi)市場推廣做的不錯(cuò)，Impala在國內(nèi)的市場不錯(cuò)。

SparkSQL

SparkSQL的前身是Shark，它將 SQL 查詢與 Spark 程序無縫集成，可以將結(jié)構(gòu)化數(shù)據(jù)作為 Spark 的 RDD 進(jìn)行查詢。

SparkSQL后續(xù)不再受限于Hive，只是兼容Hive。

SparkSQL提供了sql訪問和API訪問的接口。

支持訪問各式各樣的數(shù)據(jù)源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。

Drill

Drill好像國內(nèi)使用的很少，根據(jù)定義，Drill是一個(gè)低延遲的分布式海量數(shù)據(jù)交互式查詢引擎，支持多種數(shù)據(jù)源，包括hadoop，NoSQL存儲等等。

除了支持多種的數(shù)據(jù)源，Drill跟BI工具集成比較好。

Druid

Druid是專為海量數(shù)據(jù)集上的做高性能 OLAP而設(shè)計(jì)的數(shù)據(jù)存儲和分析系統(tǒng)。

Druid 的架構(gòu)是 Lambda 架構(gòu)，分成實(shí)時(shí)層和批處理層。

Druid的核心設(shè)計(jì)結(jié)合了數(shù)據(jù)倉庫，時(shí)間序列數(shù)據(jù)庫和搜索系統(tǒng)的思想，以創(chuàng)建一個(gè)統(tǒng)一的系統(tǒng)，用于針對各種用例的實(shí)時(shí)分析。Druid將這三個(gè)系統(tǒng)中每個(gè)系統(tǒng)的關(guān)鍵特征合并到其接收層，存儲格式，查詢層和核心體系結(jié)構(gòu)中。

目前 Druid 的去重都是非精確的，Druid 適合處理星型模型的數(shù)據(jù)，不支持關(guān)聯(lián)操作。也不支持?jǐn)?shù)據(jù)的更新。

Druid最大的優(yōu)點(diǎn)還是支持實(shí)時(shí)與查詢功能，解約了很多開發(fā)工作。

Kudu

kudu是一套完全獨(dú)立的分布式存儲引擎，很多設(shè)計(jì)概念上借鑒了HBase，但是又跟HBase不同，不需要HDFS，通過raft做數(shù)據(jù)復(fù)制；分片策略支持keyrange和hash等多種。

數(shù)據(jù)格式在parquet基礎(chǔ)上做了些修改，支持二級索引，更像一個(gè)列式存儲，而不是HBase schema-free的kv方式。

kudu也是cloudera主導(dǎo)的項(xiàng)目，跟Impala結(jié)合比較好，通過impala可以支持update操作。

kudu相對于原有parquet和ORC格式主要還是做增量更新的。

Hbase

Hbase使用的很廣,更多的是作為一個(gè)KV數(shù)據(jù)庫來使用，查詢的速度很快。

Hawq

Hawq是一個(gè)Hadoop原生大規(guī)模并行SQL分析引擎，Hawq采用 MPP 架構(gòu)，改進(jìn)了針對 Hadoop 的基于成本的查詢優(yōu)化器。

除了能高效處理本身的內(nèi)部數(shù)據(jù)，還可通過 PXF 訪問 HDFS、Hive、HBase、JSON 等外部數(shù)據(jù)源。HAWQ全面兼容 SQL 標(biāo)準(zhǔn)，還可用 SQL 完成簡單的數(shù)據(jù)挖掘和機(jī)器學(xué)習(xí)。無論是功能特性，還是性能表現(xiàn)，HAWQ 都比較適用于構(gòu)建 Hadoop 分析型數(shù)據(jù)倉庫應(yīng)用。

數(shù)據(jù)庫一體機(jī)與大數(shù)據(jù)技術(shù)區(qū)別何在

數(shù)據(jù)庫一體機(jī)與大數(shù)據(jù)技術(shù)區(qū)別何在

作為近期信息管理領(lǐng)域最為熱門的兩項(xiàng)技術(shù)，數(shù)據(jù)庫一體機(jī)與大數(shù)據(jù)技術(shù)的硬件架構(gòu)基本相同，但軟件體系有著本質(zhì)的區(qū)別，這也導(dǎo)致了兩者擁有不同的特征表現(xiàn)。

隨著企業(yè)數(shù)據(jù)量的快速增長，以及用戶對服務(wù)水平要求的不斷提高，相當(dāng)長的一段時(shí)間以來，傳統(tǒng)關(guān)系數(shù)據(jù)庫技術(shù)在生產(chǎn)實(shí)踐中表現(xiàn)出明顯的能力不足。如何以合理的成本獲得海量數(shù)據(jù)的高可用性已經(jīng)成為現(xiàn)代IT領(lǐng)域的重大挑戰(zhàn)。為了應(yīng)對這一挑戰(zhàn)，近年來，IT市場中相繼出現(xiàn)了許多新的技術(shù)手段，其中最為引人注目的便是由主流數(shù)據(jù)庫廠商主導(dǎo)的數(shù)據(jù)庫一體機(jī)（例如Oracle ExaData以及IBM Netezza等），以及以開源力量為主的大數(shù)據(jù)技術(shù)。

不過，雖然數(shù)據(jù)庫一體機(jī)與大數(shù)據(jù)技術(shù)都是當(dāng)今的熱門話題，并都已經(jīng)被廣泛應(yīng)用，但卻有相當(dāng)一部分用戶仍然無法深入了解兩者之間的本質(zhì)區(qū)別與關(guān)系。同時(shí)，很多用戶也在為如何在企業(yè)內(nèi)部對這兩者進(jìn)行正確定位而感到困惑。為此，本文特別對數(shù)據(jù)庫一體機(jī)（也可稱新一代主流關(guān)系型數(shù)據(jù)庫）和大數(shù)據(jù)技術(shù)（例如Hadoop，主要指MapReduce與NoSQL）的相關(guān)技術(shù)特點(diǎn)進(jìn)行對比。

硬件與軟件

從本質(zhì)上來講，數(shù)據(jù)庫一體機(jī)與大數(shù)據(jù)技術(shù)的硬件架構(gòu)基本相同，同樣是采用x86服務(wù)器集群的分布式并行模式，以應(yīng)對大規(guī)模的數(shù)據(jù)與計(jì)算。但是，數(shù)據(jù)庫一體機(jī)的賣家們通常會(huì)對其產(chǎn)品的硬件體系進(jìn)行面向產(chǎn)品化的、系統(tǒng)性的整體調(diào)優(yōu)，同時(shí)也會(huì)有各自的特色手段。比方說Oracle ExaData的Infiniband、Flash Cache，IBM Nettezza的FPGA（現(xiàn)場可編程邏輯門陣）等。[page] 數(shù)據(jù)庫一體機(jī)與大數(shù)據(jù)技術(shù)最為核心的區(qū)別是在軟件體系上。數(shù)據(jù)庫一體機(jī)的核心是SQL體系，這不只是指SQL解析，更重要的是指包括SQL優(yōu)化引擎、索引、鎖、事務(wù)、日志、安全以及管理等在內(nèi)的完整而龐大的技術(shù)體系。這一體系是成熟的、面向產(chǎn)品的。

大數(shù)據(jù)技術(shù)軟件體系中的MapReduce則提供了一個(gè)面向海量數(shù)據(jù)處理的分布式編程框架，使用者需要自行編制所需要的計(jì)算邏輯。MapReduce對數(shù)據(jù)的讀寫是批量連續(xù)的，而不是隨機(jī)的。而大數(shù)據(jù)技術(shù)的另一體系NoSQL則大都只是提供了海量數(shù)據(jù)的分布式存儲，以及基于索引的快速讀取機(jī)制，為使用者提供的大多是編程API（雖然也有類SQL的語言，但其本質(zhì)并不是完整的SQL體系）。

由于SQL體系的復(fù)雜性與處理邏輯的整體關(guān)聯(lián)性，導(dǎo)致數(shù)據(jù)庫一體機(jī)在擴(kuò)展性上遠(yuǎn)不及大數(shù)據(jù)技術(shù)體系，雖然前者已經(jīng)在很大程度上改善了傳統(tǒng)關(guān)系數(shù)據(jù)庫垂直擴(kuò)展的瓶頸。MapReduce與NoSQL的單個(gè)集群往往可以擴(kuò)展到數(shù)千個(gè)節(jié)點(diǎn)，而數(shù)據(jù)庫一體機(jī)如果在硬件上擴(kuò)展到這個(gè)規(guī)模，從軟件上來講，已經(jīng)是沒有意義的了。

特征與本質(zhì)

基于軟件體系的不同，導(dǎo)致了數(shù)據(jù)庫一體機(jī)和大數(shù)據(jù)技術(shù)有著不同的特征表現(xiàn)。數(shù)據(jù)庫一體機(jī)往往適合于存儲關(guān)系復(fù)雜的數(shù)據(jù)模型（例如企業(yè)核心業(yè)務(wù)數(shù)據(jù)），并且需要限制為基于二維表的關(guān)系模型。同時(shí)，數(shù)據(jù)庫一體機(jī)適合進(jìn)行一致性與事務(wù)性要求高的計(jì)算，以及復(fù)雜的BI計(jì)算。

大數(shù)據(jù)技術(shù)則更適合于存儲較簡單的數(shù)據(jù)模型，并且可以不受模式的約束。因而其可存儲管理的數(shù)據(jù)類型更加豐富。大數(shù)據(jù)技術(shù)還適合進(jìn)行一致性與事務(wù)性要求不高的計(jì)算（主要是指NoSQL的查詢操作），以及對超大規(guī)模海量數(shù)據(jù)的、批量的分布式并行計(jì)算（基于MapReduce）。

需要注意的是，NoSQL數(shù)據(jù)庫由于擺脫了繁瑣的SQL體系約束，其查詢與插入的效率比數(shù)據(jù)庫一體機(jī)更高。大數(shù)據(jù)技術(shù)比數(shù)據(jù)庫一體機(jī)所能處理的數(shù)據(jù)量也相對大些，這主要是因?yàn)槠浼嚎梢詳U(kuò)展得更大。

從本質(zhì)上講，MapReduce是對海量數(shù)據(jù)分布式計(jì)算領(lǐng)域的一個(gè)重要?jiǎng)?chuàng)新，但也只是在適合于并行處理的大規(guī)模批量處理問題上更占優(yōu)勢，而對一些復(fù)雜操作，則不一定具有優(yōu)勢。NoSQL則可以看作是對傳統(tǒng)關(guān)系數(shù)據(jù)庫進(jìn)行簡化的結(jié)果。由于NoSQL數(shù)據(jù)庫的設(shè)計(jì)思想只是提取出關(guān)系型數(shù)據(jù)庫的索引機(jī)制，并加了上分布式存儲，把SQL體系中那些對“某些特殊問題”而言并不需要的東西統(tǒng)統(tǒng)刪去，由此實(shí)現(xiàn)了更優(yōu)秀的效率、擴(kuò)展性與靈活性。[page] 因此，我們可以明顯地看到，在實(shí)踐中，有很多問題（特別是流行的大數(shù)據(jù)問題），關(guān)系數(shù)據(jù)庫中的許多設(shè)計(jì)并不需要，這才是NoSQL發(fā)展壯大的根本立足點(diǎn)。

關(guān)系與協(xié)作

通過前面的分析，我們不難得出這樣的結(jié)論：大數(shù)據(jù)技術(shù)與數(shù)據(jù)庫一體機(jī)應(yīng)該是相輔相成，并非互相替代的。它們針對不同的應(yīng)用場景設(shè)計(jì)，并相互補(bǔ)充與合作。具體來說，大數(shù)據(jù)技術(shù)可以實(shí)現(xiàn)：

■處理企業(yè)內(nèi)海量的、模型簡單、類型多樣的非結(jié)構(gòu)化與半結(jié)構(gòu)化數(shù)據(jù)（例如社會(huì)化數(shù)據(jù)、各種日志甚至圖片、視頻等），其處理結(jié)果可以被直接使用；

■以上處理結(jié)果也同時(shí)可以被當(dāng)成是新的輸入存儲到企業(yè)級數(shù)據(jù)倉庫中，這時(shí)大數(shù)據(jù)機(jī)相當(dāng)于是面向大數(shù)據(jù)源的、新的ETL（提取-轉(zhuǎn)換-加載）手段；

■面向海量數(shù)據(jù)的、不太適合SQL的存儲或計(jì)算。

而數(shù)據(jù)庫一體機(jī)則應(yīng)該還是作為企業(yè)數(shù)據(jù)倉庫的主流技術(shù)，至少在很長一段時(shí)間內(nèi)應(yīng)該是這樣。它負(fù)責(zé)存儲與計(jì)算最主要的、有重大價(jià)值的企業(yè)關(guān)鍵業(yè)務(wù)數(shù)據(jù)。

現(xiàn)存的誤區(qū)

有些人認(rèn)為，雖然大數(shù)據(jù)技術(shù)的原始開源狀態(tài)還不適合充當(dāng)企業(yè)級數(shù)據(jù)倉庫主平臺的要求，但經(jīng)過開發(fā)、補(bǔ)充，應(yīng)該是可以的。其實(shí)這個(gè)觀點(diǎn)沒有錯(cuò)。但實(shí)際上，對開源的大數(shù)據(jù)技術(shù)進(jìn)行補(bǔ)充開發(fā)，所要補(bǔ)充的正是大數(shù)據(jù)技術(shù)在原始設(shè)計(jì)上就去除了的、那些本屬于關(guān)系型數(shù)據(jù)庫體系的東西。

如果進(jìn)行這樣的補(bǔ)充開發(fā)，企業(yè)不僅會(huì)面臨龐大的、難于估計(jì)的開發(fā)工作量，同時(shí)也難以像專業(yè)數(shù)據(jù)庫廠商那樣實(shí)現(xiàn)這些工作的理論化、產(chǎn)品化與體系化。雖然從純技術(shù)的角度上講，開發(fā)什么都有可能。但是如果企業(yè)真的準(zhǔn)備這樣做，是要開發(fā)另一個(gè)商業(yè)化的關(guān)系數(shù)據(jù)庫嗎？很明顯，這違背了大數(shù)據(jù)技術(shù)的設(shè)計(jì)初衷。

名稱欄目：nosql思想,什么是NoSQL數(shù)據(jù)庫
當(dāng)前路徑：http://chinadenli.net/article45/dsiopei.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、電子商務(wù)、網(wǎng)站排名、App設(shè)計(jì)、小程序開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)