提起Hadoop，我們就可以想到大數據;提起Oracle，我們就可以想到數據庫。國內確實有不少企業習慣于將Hadoop作為數據庫使用，因此將其與數據庫領域同樣占據重要位置的Oracle進行對比是有意義的。

Hadoop不是數據庫，而是一個開源軟件集合，通過底層的分布式存儲框架(HDFS)來管理龐大的數據集，其主要目的是分析、存儲、管理和交付數據。因為Hadoop的核心是HDFS(分布式文件系統)，所以從這一點就可以看出它的本質是一個非常強大的文件系統。

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

下圖是Hadoop分布式架構圖，在此解決方案中，用戶對服務器集群執行SQL查詢，并且整個過程并行運行。由于任務分布在多臺計算機上，因此磁盤瓶頸不再是問題。隨著數據量的增長，解決方案可通過額外的服務器擴展到數百甚至數千個節點。

Hadoop內置故障恢復能力，如果一臺服務器不可用，任務將自動在幸存節點之間重新分配，從而避免了購買備用系統的巨大成本開銷，在可用性層面的優勢也十分明顯，單個機器的維護或操作系統升級不會造成整個系統停擺，整個系統的停機時間為零。

傳統關系型數據庫和Hadoop在云計算層面的優勢比較!

與傳統關系型數據庫相比，Hadoop具有幾個潛在的優勢，這些優勢通常被總結為“3V”：

• Volume (規模)- Hadoop的分布式MPP架構使其成為處理大量數據的理想選擇，多TB數據集可以跨多個服務器自動分區(擴展)并行處理。
• Variety (種類)- 與需要在加載數據之前定義數據結構的傳統關系型數據庫不同，在HDFS中，加載數據可以像復制文件一樣簡單——可以是任何格式。 這意味著Hadoop可以輕松地管理、存儲和集成數據，文本文檔、JSON或XML格式、照片，甚至是電子郵件中的數據都可以。
• Velocity(速度)- MPP架構和功能強大的內存工具(包括Spark、Storm和Kafka)構成了Hadoop框架的一部分，使其成為處理實時或近實時流式傳輸的理想解決方案。

云計算的出現讓Hadoop的優勢更加明顯，這體現在Elasticity(彈性)層面。

基于云的服務器提供按需、可擴展處理工作負載的能力，這意味著整個機器網絡可以根據需要進行調整，以應對海量數據處理挑戰，同時硬件成本受到按需付費模式的限制而不會太高。當然，在具有高度敏感數據的監管行業(例如金融服務)中，云計算可能會受到懷疑，在這種情況下，我們也可以考慮基于內部部署基于云的解決方案來保護數據。

基于列的存儲VS基于行的存儲方式

硬件優勢似乎并不足夠引人注目，畢竟現在的硬件成本已經不是非常高了。但是，基于列的存儲方式與傳統的基于行的存儲方式存在明顯差異，Hadoop本身支持基于列的存儲，這為分析查詢提供了巨大的性能和壓縮優勢，這一點恐怕是傳統關系型數據庫不可及的。

上圖說明了這兩種方法之間的區別。使用傳統的基于行的存儲可以快速識別和獲取單行，這對于需要獲取或更新單行值的事務處理系統非常有用。但是，分析查詢傾向于獲取、匯總和處理數百萬甚至數十億行數據。

例如：

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

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

在對十億行文本進行的簡單測試中，基于列的存儲方式節省了50%的成本，使用Parquet數據格式可以將56Gb文本文件減少到26Gb。

Hadoop比Oracle便宜!

當然，這里的便宜并不是單純得指Hadoop開源版本不需要購買，而Oracle只有商用成本必須購買，這里計算的是二者的整體擁有成本。雖然部署Hadoop的成本越來越高，但開源軟件和廉價硬件的好處意味著托管大型Hadoop系統比Oracle數據庫要便宜得多。

在一個存儲168 TB數據并考慮到硬件、許可證成本、IT人員支持和維護的系統上，研究發現Oracle的成本比相應的Hadoop解決方案高出約200%。當然，這并沒有考慮將數據從數據倉庫遷移到Hadoop的成本。

雖然，Hadoop看起來似乎更加優秀，但是它并不適合處理ACID事務。在很多情況下，Hadoop沒有辦法保證所有數據的強一致性。事實上，Hadoop犧牲了部分ACID合規性而提高系統吞吐量。

Hadoop可以處理大量數據，最小的典型工作單元大約為128Mb，如果將其與大約8千字節的典型Oracle數據塊進行比較，Oracle可以管理一系列OLTP和OLAP，使用單行查找處理大量短期運行事務，而Hadoop更適合單進程批處理操作。大多數數據倉庫都面向批處理、獲取并存儲海量數據集，Hadoop就是專門為此用例而構建的。

在Hadoop生態系統中，Cloudera Impala、Apache Hive和Spark SQL等產品在大規模數據集上添加了低延遲的SQL查詢和分析工具，同樣，在商業智能系統中，ACID合規性往往不那么重要，99.9%的準確性通常只是口號，而不是業務最關鍵的要求。

結論

當然，Oracle在企業數據庫領域耗時30多年建立起來的核心地位并不會很快消失。實際上，Oracle已經采用Oracle Big Data Appliance，Exadata Appliance和Oracle 12c In-Memory等適應新的需求和挑戰。但是，整個數據倉庫架構變化讓Hadoop及其附帶的眾多技術產品成為最適合整個堆棧的工具。與此同時，我們需要注意是需求驅動開發而不是CV驅動的解決方案。