我們踏上這個大數(shù)據(jù)征程已有一段時日了。一切不再依然光鮮亮麗。實際上，一些技術可能會阻礙你的步伐。切記，大數(shù)據(jù)是企業(yè)技術行業(yè)發(fā)展最快的一個領域，快得一些軟件還沒有站穩(wěn)腳跟，更好的技術就已撲面而來。

那些技術升級或更換至關重要，這關系到大數(shù)據(jù)項目獲得成功，還是你在今后幾年通過行動讓大家原諒你的過失。下面是你應該開始考慮更換掉的大數(shù)據(jù)架構(gòu)中的一些要素。

MapReduce

MapReduce速度很慢。它也很少是著手處理問題的最好方法。還有其他算法可供選擇，最常見的算法是DAG，MapReduce被認為是DAG的一個子集。如果你處理過一批自定義的MapReduce任務，就會發(fā)覺與Spark相比性能差多了，值得投入成本和精力來更換MapReduce。

Storm

我倒不是說，Spark 會稱霸數(shù)據(jù)流領域，不過它可能會，但是由于Apex和Flink之類的技術，外頭有些Spark的替代方案比Storm更出色，而且延遲更低。除此之外，你應該評估對延遲的容忍程度，你編寫的那些較低級較復雜的代碼中的缺陷是不是值得延遲多幾毫秒。Storm并沒有得到應有的支持，Hortonworks是唯一真正的支持者，由于Hortonworks面臨越來越大的市場壓力，Storm不太可能得到更多人的關注。

Pig

Pig形勢有點不妙。你可以用Spark或其他技術做Pig所做的任何事情。起初，Pig似乎是一種很好的“面向大數(shù)據(jù)的PL/SQL”，但你很快發(fā)現(xiàn)它有點怪異。

Java

不，這里說的不是Java虛擬機(JVM)，而是Java這種語言。語法對大數(shù)據(jù)任務來說很笨重。另外，像Lambda這些更新穎的構(gòu)件以一種有點笨拙的方式事后擴充上去。大數(shù)據(jù)世界已經(jīng)很大程度上遷移到了Scala和Python(如果你承受得了性能影響，又需要Python庫，或者擁有大量的Python開發(fā)人員，就使用Python)。當然，你可以使用R用于統(tǒng)計數(shù)據(jù)，直到你用Python來改寫，因為R沒有所有好玩的規(guī)模特征。

Tez

這是Hortonworks的另一個寵物項目。它是一種DAG實現(xiàn)，但是與Spark不同，Tez被其中一個開發(fā)人員描述為像是用“匯編語言”編寫。目前，借助Hortonworks發(fā)行版，你最后得在Hive及其他工具后面使用Tez，但是你可能已經(jīng)使用Spark作為其他發(fā)行版中的引擎。不管怎么說，Tez始終有不少缺陷。同樣，這是一家廠商的項目，不像其他技術那樣得到行業(yè)或社區(qū)的廣泛支持。相比其他解決方案，它也沒有任何壓倒性的優(yōu)勢。這是我期望合并掉的一種引擎。

Oozie

它不是什么了不起的工作流引擎，也不是什么了不起的調(diào)度器，不過它想搞好這兩者，卻都搞不好!然而，它有一大堆的軟件缺陷，這款軟件編寫起來不該很難。面對StreamSets、DAG實現(xiàn)以及其他一切，你應該有的是辦法來處理Oozie處理的大部分任務。

Flume

在StreamSets、Kafka 及其他解決方案之間，你可能有Flume的替代方案。2015年5月20日發(fā)布的這個版本看起來有點過氣了。你可以跟蹤分析較上年同期的活動強度。許多人離它遠去，也許是該翻篇的時候了。

也許到2018年……

還剩下什么?一些技術日漸老朽，但是完全切實可行的替代方案還沒有問世。不妨事先想想更換掉這些技術：

Hive

有點過于吹毛求疵了，但是Hive好比是市面上性能最低下的分布式數(shù)據(jù)庫。要是我們整個行業(yè)沒有認定關系數(shù)據(jù)庫管理系統(tǒng)(RDBMS)是自切片面包以來這40年來最出色的技術，那么我們果真會開發(fā)出這種怪獸?

HDFS

用Java編寫一種系統(tǒng)級服務不是最好的想法。Java的內(nèi)存管理也使得傳送大量字節(jié)有點慢。HDFS NameNode的工作方式對任何任務來說不是很理想，造成了瓶頸。各家廠商拿出了變通方法，改善這種情況，但是坦率地說，市面上有更好的技術。還有其他分布式文件系統(tǒng)。MaprFS就是一種設計相當出色的分布式文件系統(tǒng)。還有Gluster及另外一批文件系統(tǒng)。