[[177569]]

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

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

MapReduce

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

Storm

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

Pig

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

Java

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

Tez

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

Oozie

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

Flume

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

也許到2018年……

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

Hive

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

HDFS

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

著眼于未來，是時候剔除一批看起來大有希望，但是已變得落后或過氣的技術了。這是我的全文，還有什么技術是我要補充上去的嗎?