“NoHadoop”？——新一代海量數(shù)據(jù)架構(gòu)分析

申請免費試用、咨詢電話：400-8352-114

      [CSDN編譯]在經(jīng)歷了長達25年的統(tǒng)治地位后，關(guān)系型數(shù)據(jù)庫正面臨越來越火的“NoSQL”挑戰(zhàn)，而挑戰(zhàn)者是以Hadoop為代表的分布式計算開源架構(gòu)。可以看到，越來越多的消息表明，不管NoSQL是被解釋為“No SQL”還是“Not Only SQL”，如果你面臨海量數(shù)據(jù)的挑戰(zhàn)，那么你最應(yīng)該選的海量數(shù)據(jù)架構(gòu)是Hadoop。
      但是Hadoop就能代表一切嗎？答案顯然是否定的，Hadoop的MapReduce在性能上的確是有局限性的：比如MapReduce沒有索引，只有靠強大的運算能力來處理；此外，MapReduce本身存在一些lower-level實現(xiàn)的問題, 特別是skew和數(shù)據(jù)交換等等。
      因此有些人開始回到關(guān)系型數(shù)據(jù)庫上，因為相比較Hadoop的處理能力，一些SQL架構(gòu)依然呈現(xiàn)數(shù)量級的優(yōu)勢。
      也許，我們現(xiàn)在正處于一個新的“NoHadoop”時代，因為越來越多的企業(yè)開始認(rèn)識到，海量數(shù)據(jù)處理僅有Hadoop是不夠的。在他們看來，簡單的批處理工具比如MapReduce和Hadoop恐怕并不足以應(yīng)付將來更大的數(shù)據(jù)結(jié)構(gòu)。誠然，大多數(shù)的比較復(fù)雜的海量數(shù)據(jù)處理我們也許能夠用Hadoop就足以對付——也許更多的是一個無奈選擇。它們可能涉及更復(fù)雜的連接，比如ACID需求、實時要求、超級計算的算法、圖形計算、互動分析或者連續(xù)增量的需求等等。
      事實上，Hadoop之所以受到越來越多的人歡迎，原因在于它對于海量數(shù)據(jù)的處理方式，而且，最重要的是，它是免費的。
      但是隨著對海量數(shù)據(jù)處理的應(yīng)用程序性能需求不斷增加，我們會發(fā)現(xiàn)，在很多領(lǐng)域，我們需要除了Hadoop以外的更多的海量數(shù)據(jù)處理方式。
      那么，我們應(yīng)該怎樣看待下一代分布式計算架構(gòu)呢？或者說，“NoHadoop”的架構(gòu)應(yīng)該是怎樣的呢？從性能上而言，下一代的架構(gòu)需要在MapReduce/Hadoop的基礎(chǔ)上有10——10000倍的性能提高。
      在每一種應(yīng)用下，都有新一代的數(shù)據(jù)架構(gòu)，可以提供所需的規(guī)模和效能。在未來的幾年內(nèi)，這些架構(gòu)中的某些也許會成為主流。
      1、SQL：數(shù)據(jù)庫已經(jīng)有了25年的發(fā)展歷史。大量的創(chuàng)新正在圍繞數(shù)據(jù)庫技術(shù)，比如VoltDB、Clustrix等等（也許下一代產(chǎn)品不應(yīng)該再稱為數(shù)據(jù)庫），但當(dāng)你需要處理復(fù)雜的連接，或需要ACID需求時，數(shù)據(jù)庫依然是你最好的選擇。
      應(yīng)用場景：復(fù)雜的業(yè)務(wù)查詢、在線交易處理。
      2、Cloudscale：在海量數(shù)據(jù)上的實時分析，它打破了自由批量處理的限制。比如，當(dāng)你打算分析一臺百萬次的服務(wù)器中發(fā)生的事件流，你需要一個真正的實時數(shù)據(jù)流體系結(jié)構(gòu)。而Cloudscale架構(gòu)提供的這種實時數(shù)據(jù)分析能力，比Hadoop的批處理系統(tǒng)快了近10000倍。
      應(yīng)用場景：商業(yè)算法，欺詐檢測，手機廣告、位置服務(wù)、市場情報。
      3、MPI和BSP：相當(dāng)多的超級計算機應(yīng)用中，需要在海量數(shù)據(jù)上建立復(fù)雜的算法，為了實現(xiàn)規(guī)模效應(yīng)，需要對處理器的直接訪問調(diào)用以提高計算的速度。在并行計算中，MPI和BSP這些工具是進行高性能計算的必要。
      應(yīng)用場景：建模與仿真系統(tǒng)，流體動力學(xué)。
      4、Pregel：當(dāng)你需要分析一個復(fù)雜的社交網(wǎng)，或者是要分析網(wǎng)絡(luò)的時候，面對的不是數(shù)據(jù)的問題，而是一個很大的圖形。我們面臨的現(xiàn)狀是，大規(guī)模的動態(tài)圖形正成為一些應(yīng)用的關(guān)鍵。Google的Pregel結(jié)構(gòu)采用了BSP模型，以便能夠進行規(guī)?；⒏咝У膱D形計算。
      應(yīng)用場景：算法，算法的結(jié)構(gòu)圖，地理位置圖，網(wǎng)絡(luò)優(yōu)化等
      5、Dremel：這是一個需要與網(wǎng)絡(luò)進行大規(guī)模交互的數(shù)據(jù)集。Google的Dremel的設(shè)計原理在于支持幾秒內(nèi)萬億行命令的執(zhí)行，并提供即時查詢。而它的查詢執(zhí)行并沒有采用MapReduce 的功能。自從2006年以來Dremel誕生以來，已經(jīng)有了成千上萬的用戶。
      應(yīng)用場景：數(shù)據(jù)搜索、客戶支持、數(shù)據(jù)中心監(jiān)控。
      6、Percolator (Caffeine) ：如果需要對龐大的數(shù)據(jù)增量進行不斷更新，你會發(fā)現(xiàn)，Percolator是一種很好的實現(xiàn)方式，這也是Google在新的索引系統(tǒng)上采用的架構(gòu)，Google的即時搜索引擎Instant不能沒有它。“由于索引內(nèi)容可以逐步增加，采用以Percolator的Google Caffeine系統(tǒng)檢索速度將百倍于之前采用Hadoop的分布式數(shù)據(jù)處理方式。”