[[177569]]

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

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

MapReduce

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

Storm

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

Pig

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

Java

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

Tez

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

Oozie

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

Flume

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

也許到2018年……

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

Hive

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

HDFS

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

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