Oracle與Hadoop對比：強一致性和高效能不可兼得！

提起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驅動的解決方案。