技術解讀：Hadoop、PostgreSQL與Storm正面比拼報告！

　　在“Hadoop是否已失寵?”的選題調研中，筆者調查了銀行、Hadoop發行商、Hadoop企業使用者以及部分工程師的意見，所處環境、業務需求以及看問題角度的不同讓這些組織或個人有著不同的意見。如果你的資料量和增長速度還未達到使用Hadoop的級別，你一定會認為Hadoop是十分不明智的選擇;相反，當你已經從Hadoop生態受益良久時，你一定會認為這是大資料時代最佳解決方案之一，比如那些從PostgreSQL遷移至Hadoop的企業。

　　很多人不屑於討論Hadoop與Spark、Flink等之間的對比，因為在大多數人的認知中，只要提起Hadoop就一定代表著整個Hadoop生態。但在不少企業內部，Hadoop更多的時候只是表示狹義上的MapReduce和HDFS，由於大多數企業內部還保留著關係型資料庫時代的解決方案，因此企業更傾向於將狹義上的Hadoop和其他方案與業務需求對比，選擇最合適的搭建模式，尤其是資金不太充足的企業，搭建整個Hadoop生態的前期和後期維護成本以及複雜性是非常高的，其中有些問題可能傳統方案也足以解決。

　　如今，不少企業將資料庫從PostgreSQL遷移到Hadoop，可能速度、容量以及型別是他們面臨的主要問題，PostgreSQL正在漸漸從這些企業的資料中心消失，並且在行業中，Hadoop生態各開源工具的使用頻率很可能遠遠超過PostgreSQL。與此同時，也會有一些企業從Hadoop遷移至PostgreSQL，這為思考大資料問題和解決方案及其影響提供了機會。

　　很早之前，我們在分析大資料問題時傾向於三個層面： 管理不斷增加的資料量、管理資料增長速度以及處理多種類的資料結構。值得注意的是，這些只是問題型別，而不是問題本身，同類別的問題之間可能存在很大差異，所有解決方案几乎都意味著不小的成本付出，我經常看到將Hadoop作為企業通用解決方案，而不關注成本和問題型別的，結果往往是整個體系過於複雜，難以維護，速度可能很慢。

　　因此，我們應該學會區分Hadoop(狹義的MR和HDFS組合，不代指整個生態)、Storm以及PostgreSQL，Hadoop是專業通用的解決方案，而OLTP和關係型資料庫則是更通用的方案。通常，明智的企業會從通用解決方案開始逐漸轉向專業解決方案，並且知道應該使用專業的解決方案來解決哪些問題，比如Hadoop在批處理方面很牛，但它並不是一個很好的通用ETL平臺.....

　　PostgreSQL與Hadoop對比

　　企業應該清楚，構建Hadoop是為了同時解決大資料3V問題，這就意味著，如果你只存在某一方面的困擾，那麼構建Hadoop的成本就顯得過高了。PostgreSQL和其他關係型資料解決方案為資料提供了非常好的保證，因為它們強化了多樣性，在寫入時強制使用模式，如果違反該模式，則會引發錯誤。Hadoop在讀取時強制執行模式，因此可以在儲存資料後再嘗試讀取資料，這對於大量非結構化資料很有幫助。

　　如果僅僅面臨容量和速度問題，首先要檢視的解決方案應該是Postgres-XL或者類似的叢集解決方案，但這些方案確實需要良好的資料分割槽標準。如果資料集高度相關，這可能不是一個好的解決方案，因為跨節點連線是昂貴的。此外，這些方案也不適用於小型資料集，因為搭建這些解決方案的複雜性和成本也不是很低。

　　Storm與Hadoop對比

　　Storm和Hadoop的主攻方向完全不同，Storm的主工程師Nathan Marz曾表示， Storm可以方便地在一個計算機叢集中編寫與擴充套件複雜的實時計算，Storm之於實時處理就好比Hadoop之於批處理。如果習慣於用Hadoop代指整個Hadoop生態，那你可能會把Storm也劃分在生態圈之中。但在企業選擇解決方案時，還是應該將狹義上的Hadoop與Storm進行一些對比。

　　根據Hadoop官網的說法，“Apache Hadoop是一個框架，允許使用簡單的程式設計模型在整個計算機叢集上分散式處理大型資料集，它可以從單個伺服器擴充套件到數千臺機器，本地計算和儲存，而不是依靠硬體來提供高可用性，該框架本身旨在檢測和處理應用層的故障，最大的優勢是批處理。

　　Apache Storm是一個分散式實時計算系統，本身不會在典型的Hadoop叢集上執行，可以與任何程式語言一起工作。Storm是一個任務並行連續計算引擎，使用Apache ZooKeeper和主/從工作程式，協調拓撲，主機和工作者狀態，保證資訊語義。無論如何，Storm必定還是可以從HDFS檔案消費或者從檔案寫入到HDFS的，Storm可以與任何佇列或資料庫系統(即RDBMS，NOSQL)整合。

　　根據官網介紹，Storm的應用非常廣泛，比如實時分析、線上機器學習、連續計算、分散式RPC、ETL等。Storm的速度很快—每個節點每秒鐘可處理超過一百萬個元組，具有可擴充套件性和容錯性，可確保資料得到處理並且易於設定和操作。在消耗資源相同的情況下，一般來說Storm的延時低於MapReduce，但是吞吐也低於MapReduce。Storm是典型的流計算系統，MapReduce是典型的批處理系統。下表對比了Storm和Hadoop進行資料處理時的各項指標：

　　如果你正在因為大資料的3V問題煩惱，Hadoop是最理想的解決方案，如果你只需要解決其中之一，你可以嘗試一些其他解決方案，因為此時搭建Hadoop生態的價效比會大打折扣。如果資料量較少，比如國外企業的資料量整體上少於國內，沒必要使用Hadoop處理，因為無法發揮出Hadoop的全部價值。