提起Hadoop，我們就可以想到大數(shù)據(jù);提起Oracle，我們就可以想到數(shù)據(jù)庫(kù)。國(guó)內(nèi)確實(shí)有不少企業(yè)習(xí)慣于將Hadoop作為數(shù)據(jù)庫(kù)使用，因此將其與數(shù)據(jù)庫(kù)領(lǐng)域同樣占據(jù)重要位置的Oracle進(jìn)行對(duì)比是有意義的。

Hadoop不是數(shù)據(jù)庫(kù)，而是一個(gè)開(kāi)源軟件集合，通過(guò)底層的分布式存儲(chǔ)框架(HDFS)來(lái)管理龐大的數(shù)據(jù)集，其主要目的是分析、存儲(chǔ)、管理和交付數(shù)據(jù)。因?yàn)镠adoop的核心是HDFS(分布式文件系統(tǒng))，所以從這一點(diǎn)就可以看出它的本質(zhì)是一個(gè)非常強(qiáng)大的文件系統(tǒng)。

Hadoop底層架構(gòu)中的HDFS和MppReduce給它帶來(lái)了兩大優(yōu)勢(shì)——可擴(kuò)展性和大規(guī)模并行處理(MPP)能力。下圖是一個(gè)典型的數(shù)據(jù)庫(kù)體系架構(gòu)，用戶(hù)對(duì)單個(gè)大型數(shù)據(jù)庫(kù)服務(wù)器執(zhí)行SQL查詢(xún)。盡管已經(jīng)有了各種復(fù)雜的緩存技術(shù)，但大多數(shù)商業(yè)智能應(yīng)用程序的瓶頸依然出現(xiàn)在數(shù)據(jù)從磁盤(pán)提取到內(nèi)存的過(guò)程，這限制了系統(tǒng)的處理和擴(kuò)展能力，使其難以應(yīng)對(duì)快速增長(zhǎng)的龐大數(shù)據(jù)集。由于只有一臺(tái)服務(wù)器，因此還需要昂貴的冗余硬件來(lái)保證系統(tǒng)的高可用性，整體擁有成本進(jìn)一步提升。

下圖是Hadoop分布式架構(gòu)圖，在此解決方案中，用戶(hù)對(duì)服務(wù)器集群執(zhí)行SQL查詢(xún)，并且整個(gè)過(guò)程并行運(yùn)行。由于任務(wù)分布在多臺(tái)計(jì)算機(jī)上，因此磁盤(pán)瓶頸不再是問(wèn)題。隨著數(shù)據(jù)量的增長(zhǎng)，解決方案可通過(guò)額外的服務(wù)器擴(kuò)展到數(shù)百甚至數(shù)千個(gè)節(jié)點(diǎn)。

Hadoop內(nèi)置故障恢復(fù)能力，如果一臺(tái)服務(wù)器不可用，任務(wù)將自動(dòng)在幸存節(jié)點(diǎn)之間重新分配，從而避免了購(gòu)買(mǎi)備用系統(tǒng)的巨大成本開(kāi)銷(xiāo)，在可用性層面的優(yōu)勢(shì)也十分明顯，單個(gè)機(jī)器的維護(hù)或操作系統(tǒng)升級(jí)不會(huì)造成整個(gè)系統(tǒng)停擺，整個(gè)系統(tǒng)的停機(jī)時(shí)間為零。

傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)和Hadoop在云計(jì)算層面的優(yōu)勢(shì)比較!

與傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)相比，Hadoop具有幾個(gè)潛在的優(yōu)勢(shì)，這些優(yōu)勢(shì)通常被總結(jié)為“3V”：

• Volume (規(guī)模)- Hadoop的分布式MPP架構(gòu)使其成為處理大量數(shù)據(jù)的理想選擇，多TB數(shù)據(jù)集可以跨多個(gè)服務(wù)器自動(dòng)分區(qū)(擴(kuò)展)并行處理。
• Variety (種類(lèi))- 與需要在加載數(shù)據(jù)之前定義數(shù)據(jù)結(jié)構(gòu)的傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)不同，在HDFS中，加載數(shù)據(jù)可以像復(fù)制文件一樣簡(jiǎn)單——可以是任何格式。 這意味著Hadoop可以輕松地管理、存儲(chǔ)和集成數(shù)據(jù)，文本文檔、JSON或XML格式、照片，甚至是電子郵件中的數(shù)據(jù)都可以。
• Velocity(速度)- MPP架構(gòu)和功能強(qiáng)大的內(nèi)存工具(包括Spark、Storm和Kafka)構(gòu)成了Hadoop框架的一部分，使其成為處理實(shí)時(shí)或近實(shí)時(shí)流式傳輸?shù)睦硐虢鉀Q方案。

云計(jì)算的出現(xiàn)讓Hadoop的優(yōu)勢(shì)更加明顯，這體現(xiàn)在Elasticity(彈性)層面。

基于云的服務(wù)器提供按需、可擴(kuò)展處理工作負(fù)載的能力，這意味著整個(gè)機(jī)器網(wǎng)絡(luò)可以根據(jù)需要進(jìn)行調(diào)整，以應(yīng)對(duì)海量數(shù)據(jù)處理挑戰(zhàn)，同時(shí)硬件成本受到按需付費(fèi)模式的限制而不會(huì)太高。當(dāng)然，在具有高度敏感數(shù)據(jù)的監(jiān)管行業(yè)(例如金融服務(wù))中，云計(jì)算可能會(huì)受到懷疑，在這種情況下，我們也可以考慮基于內(nèi)部部署基于云的解決方案來(lái)保護(hù)數(shù)據(jù)。

基于列的存儲(chǔ)VS基于行的存儲(chǔ)方式

硬件優(yōu)勢(shì)似乎并不足夠引人注目，畢竟現(xiàn)在的硬件成本已經(jīng)不是非常高了。但是，基于列的存儲(chǔ)方式與傳統(tǒng)的基于行的存儲(chǔ)方式存在明顯差異，Hadoop本身支持基于列的存儲(chǔ)，這為分析查詢(xún)提供了巨大的性能和壓縮優(yōu)勢(shì)，這一點(diǎn)恐怕是傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)不可及的。

上圖說(shuō)明了這兩種方法之間的區(qū)別。使用傳統(tǒng)的基于行的存儲(chǔ)可以快速識(shí)別和獲取單行，這對(duì)于需要獲取或更新單行值的事務(wù)處理系統(tǒng)非常有用。但是，分析查詢(xún)傾向于獲取、匯總和處理數(shù)百萬(wàn)甚至數(shù)十億行數(shù)據(jù)。

例如：

SELECT team, sum(value) FROM sales GROUP by team;

在基于行的系統(tǒng)上，此查詢(xún)需要將每行的每一列提取到內(nèi)存中并按照team分組。在具有100列和數(shù)十億行的表中，這樣做的效率是極其低下的。但是，在基于列的解決方案中，相同的查詢(xún)僅需要處理約2%的數(shù)據(jù)，具有巨大的性能優(yōu)勢(shì)。在壓縮層面，TEAM列中的重復(fù)值可以用簡(jiǎn)單的字典編碼技術(shù)代替以壓縮數(shù)據(jù)。

在對(duì)十億行文本進(jìn)行的簡(jiǎn)單測(cè)試中，基于列的存儲(chǔ)方式節(jié)省了50%的成本，使用Parquet數(shù)據(jù)格式可以將56Gb文本文件減少到26Gb。

Hadoop比Oracle便宜!

當(dāng)然，這里的便宜并不是單純得指Hadoop開(kāi)源版本不需要購(gòu)買(mǎi)，而Oracle只有商用成本必須購(gòu)買(mǎi)，這里計(jì)算的是二者的整體擁有成本。雖然部署Hadoop的成本越來(lái)越高，但開(kāi)源軟件和廉價(jià)硬件的好處意味著托管大型Hadoop系統(tǒng)比Oracle數(shù)據(jù)庫(kù)要便宜得多。

在一個(gè)存儲(chǔ)168 TB數(shù)據(jù)并考慮到硬件、許可證成本、IT人員支持和維護(hù)的系統(tǒng)上，研究發(fā)現(xiàn)Oracle的成本比相應(yīng)的Hadoop解決方案高出約200%。當(dāng)然，這并沒(méi)有考慮將數(shù)據(jù)從數(shù)據(jù)倉(cāng)庫(kù)遷移到Hadoop的成本。

雖然，Hadoop看起來(lái)似乎更加優(yōu)秀，但是它并不適合處理ACID事務(wù)。在很多情況下，Hadoop沒(méi)有辦法保證所有數(shù)據(jù)的強(qiáng)一致性。事實(shí)上，Hadoop犧牲了部分ACID合規(guī)性而提高系統(tǒng)吞吐量。

Hadoop可以處理大量數(shù)據(jù)，最小的典型工作單元大約為128Mb，如果將其與大約8千字節(jié)的典型Oracle數(shù)據(jù)塊進(jìn)行比較，Oracle可以管理一系列OLTP和OLAP，使用單行查找處理大量短期運(yùn)行事務(wù)，而Hadoop更適合單進(jìn)程批處理操作。大多數(shù)數(shù)據(jù)倉(cāng)庫(kù)都面向批處理、獲取并存儲(chǔ)海量數(shù)據(jù)集，Hadoop就是專(zhuān)門(mén)為此用例而構(gòu)建的。

在Hadoop生態(tài)系統(tǒng)中，Cloudera Impala、Apache Hive和Spark SQL等產(chǎn)品在大規(guī)模數(shù)據(jù)集上添加了低延遲的SQL查詢(xún)和分析工具，同樣，在商業(yè)智能系統(tǒng)中，ACID合規(guī)性往往不那么重要，99.9%的準(zhǔn)確性通常只是口號(hào)，而不是業(yè)務(wù)最關(guān)鍵的要求。

結(jié)論

當(dāng)然，Oracle在企業(yè)數(shù)據(jù)庫(kù)領(lǐng)域耗時(shí)30多年建立起來(lái)的核心地位并不會(huì)很快消失。實(shí)際上，Oracle已經(jīng)采用Oracle Big Data Appliance，Exadata Appliance和Oracle 12c In-Memory等適應(yīng)新的需求和挑戰(zhàn)。但是，整個(gè)數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)變化讓Hadoop及其附帶的眾多技術(shù)產(chǎn)品成為最適合整個(gè)堆棧的工具。與此同時(shí)，我們需要注意是需求驅(qū)動(dòng)開(kāi)發(fā)而不是CV驅(qū)動(dòng)的解決方案。