比較SQL資料庫和Hadoop

　　鑑於Hadoop是一個資料處理框架，而在當前大多數應用中資料處理的主力是標準的關聯式資料庫，那又是什麼使得Hadoop更具優勢呢？其中一個原因是，SQL（結構化查詢語言）是針對結構化資料設計的，而Hadoop最初的許多應用針對的是文字這種非結構化資料。從這個角度來看，Hadoop比SQL提供了一種更為通用的模式。

　　若只針對結構化資料處理，則需要做更細緻的比較。原則上，SQL和Hadoop可以互補，因為SQL是一種查詢語言，它可將Hadoop作為其執行引擎 。但實際上，SQL資料庫往往指代一整套傳統技術，有幾個主要的廠商，並面向一組歷史悠久的應用進行優化。許多這些現有的商業資料庫無法滿足Hadoop設計所面向的需求。

　　考慮到這一點，讓我們從特定視角將Hadoop與典型的SQL資料庫做更詳細的比較。

　　1. 用向外擴充套件代替向上擴充套件

　　擴充套件商用關係型資料庫的代價是非常昂貴的。它們的設計更容易向上擴充套件。要執行一個更大的資料庫，就需要買一個更大的機器。事實上，往往會看到伺服器廠商在市場上將其昂貴的高階機標稱為“資料庫級的伺服器”。不過有時可能需要處理更大的資料集，卻找不到一個足夠大的機器。更重要的是，高階的機器對於許多應用並不經濟。例如，效能4倍於標準PC的機器，其成本將大大超過將同樣的4臺PC放在一個叢集中。Hadoop的設計就是為了能夠在商用PC叢集上實現向外擴充套件的架構。新增更多的資源，在Hadoop叢集上意味著增加更多的機器。一個Hadoop叢集的標配是十至數百臺計算機。事實上，如果不是為了開發目的，沒有理由在單個伺服器上執行Hadoop。

　　2. 用鍵/值對代替關係表

　　關聯式資料庫的一個基本原則是讓資料按某種模式存放在具有關係型資料結構的表中。雖然關係模型具有大量形式化的屬性，許多當前的應用所處理的資料型別並不能很好地適合這個模型。文字、圖片和XML檔案是最典型的例子。此外，大型資料集往往是非結構化或半結構化的。Hadoop使用鍵/值對作為基本資料單元，可足夠靈活地處理較少結構化的資料型別。在Hadoop中，資料的來源可以有任何形式，但最終會轉化為鍵/值對以供處理。

　　3. 用函數語言程式設計（MapReduce）代替宣告式查詢（SQL）

　　SQL從根本上說是一個高階宣告性語言。查詢資料的手段是，宣告想要的查詢結果並讓資料庫引擎判定如何獲取資料。在MapReduce中，實際的資料處理步驟是你指定的，這更類似於SQL引擎的一個執行計劃。SQL使用查詢語句，而MapReduce則使用指令碼和程式碼。MapReduce允許你採用比SQL查詢更為一般化的資料處理方式。例如，你可以建立複雜的資料統計模型，或者改變影像資料的格式。而SQL就不能很好地適應這些任務。

　　另一方面，當資料處理非常適合於關係型資料結構時，有些人可能會發現使用MapReduce並不自然。那些習慣於SQL正規化的人可能會發現用MapReduce來思考是一個挑戰。我希望本書中的練習和示例能幫你更輕鬆地掌握MapReduce程式設計。不過值得注意的是，這裡還有很多擴充套件可用，它們允許人們採用更熟悉的正規化來程式設計，同時擁有Hadoop的可擴充套件性優勢。事實上，一些擴充套件會允許你使用一種類似SQL的查詢語言，並自動將查詢編譯為可執行的MapReduce程式碼。我們將在第10章和第11章介紹其中的一些工具。

　　4. 用離線批量處理代替線上處理

　　Hadoop是專為離線處理和大規模資料分析而設計的，它並不適合那種對幾個記錄隨機讀寫的線上事務處理模式。事實上，在本書寫作時（以及在可預見的未來），Hadoop最適合一次寫入、多次讀取的資料儲存需求。在這方面它就像SQL世界中的資料倉儲。

　　你已經從巨集觀上看到Hadoop與分散式系統和SQL資料庫之間的關係。那麼，讓我們開始學習如何用它來程式設計。為此，我們首先需要了解Hadoop中MapReduce的正規化。

摘自《Hadoop實戰》