我們踏上這個(gè)大數(shù)據(jù)征程已有一段時(shí)日了。一切不再依然光鮮亮麗。實(shí)際上，一些技術(shù)可能會(huì)阻礙你的步伐。切記，大數(shù)據(jù)是企業(yè)技術(shù)行業(yè)發(fā)展最快的一個(gè)領(lǐng)域，快得一些軟件還沒(méi)有站穩(wěn)腳跟，更好的技術(shù)就已撲面而來(lái)。
那些技術(shù)升級(jí)或更換至關(guān)重要，這關(guān)系到大數(shù)據(jù)項(xiàng)目獲得成功，還是你在今后幾年通過(guò)行動(dòng)讓大家原諒你的過(guò)失。下面是你應(yīng)該開(kāi)始考慮更換掉的大數(shù)據(jù)架構(gòu)中的一些要素。
MapReduce
MapReduce速度很慢。它也很少是著手處理問(wèn)題的最好方法。還有其他算法可供選擇，最常見(jiàn)的算法是DAG，MapReduce被認(rèn)為是DAG的一個(gè)子集。如果你處理過(guò)一批自定義的MapReduce任務(wù)，就會(huì)發(fā)覺(jué)與Spark相比性能差多了，值得投入成本和精力來(lái)更換MapReduce。
Storm
我倒不是說(shuō)，Spark 會(huì)稱霸數(shù)據(jù)流領(lǐng)域，不過(guò)它可能會(huì)，但是由于Apex和Flink之類的技術(shù)，外頭有些Spark的替代方案比Storm更出色，而且延遲更低。除此之外，你應(yīng)該評(píng)估對(duì)延遲的容忍程度，你編寫(xiě)的那些較低級(jí)較復(fù)雜的代碼中的缺陷是不是值得延遲多幾毫秒。Storm并沒(méi)有得到應(yīng)有的支持，Hortonworks是唯一真正的支持者，由于Hortonworks面臨越來(lái)越大的市場(chǎng)壓力，Storm不太可能得到更多人的關(guān)注。
Pig
Pig形勢(shì)有點(diǎn)不妙。你可以用Spark或其他技術(shù)做Pig所做的任何事情。起初，Pig似乎是一種很好的“面向大數(shù)據(jù)的PL/SQL”，但你很快發(fā)現(xiàn)它有點(diǎn)怪異。
Java
不，這里說(shuō)的不是Java虛擬機(jī)(JVM)，而是Java這種語(yǔ)言。語(yǔ)法對(duì)大數(shù)據(jù)任務(wù)來(lái)說(shuō)很笨重。另外，像Lambda這些更新穎的構(gòu)件以一種有點(diǎn)笨拙的方式事后擴(kuò)充上去。大數(shù)據(jù)世界已經(jīng)很大程度上遷移到了Scala和Python(如果你承受得了性能影響，又需要Python庫(kù)，或者擁有大量的Python開(kāi)發(fā)人員，就使用Python)。當(dāng)然，你可以使用R用于統(tǒng)計(jì)數(shù)據(jù)，直到你用Python來(lái)改寫(xiě)，因?yàn)镽沒(méi)有所有好玩的規(guī)模特征。
Tez
這是Hortonworks的另一個(gè)寵物項(xiàng)目。它是一種DAG實(shí)現(xiàn)，但是與Spark不同，Tez被其中一個(gè)開(kāi)發(fā)人員描述為像是用“匯編語(yǔ)言”編寫(xiě)。目前，借助Hortonworks發(fā)行版，你最后得在Hive及其他工具后面使用Tez，但是你可能已經(jīng)使用Spark作為其他發(fā)行版中的引擎。不管怎么說(shuō)，Tez始終有不少缺陷。同樣，這是一家廠商的項(xiàng)目，不像其他技術(shù)那樣得到行業(yè)或社區(qū)的廣泛支持。相比其他解決方案，它也沒(méi)有任何壓倒性的優(yōu)勢(shì)。這是我期望合并掉的一種引擎。
Oozie
它不是什么了不起的工作流引擎，也不是什么了不起的調(diào)度器，不過(guò)它想搞好這兩者，卻都搞不好!然而，它有一大堆的軟件缺陷，這款軟件編寫(xiě)起來(lái)不該很難。面對(duì)StreamSets、DAG實(shí)現(xiàn)以及其他一切，你應(yīng)該有的是辦法來(lái)處理Oozie處理的大部分任務(wù)。
Flume
在StreamSets、Kafka 及其他解決方案之間，你可能有Flume的替代方案。2015年5月20日發(fā)布的這個(gè)版本看起來(lái)有點(diǎn)過(guò)氣了。你可以跟蹤分析較上年同期的活動(dòng)強(qiáng)度。許多人離它遠(yuǎn)去，也許是該翻篇的時(shí)候了。
也許到2018年……
還剩下什么?一些技術(shù)日漸老朽，但是完全切實(shí)可行的替代方案還沒(méi)有問(wèn)世。不妨事先想想更換掉這些技術(shù)：
Hive
有點(diǎn)過(guò)于吹毛求疵了，但是Hive好比是市面上性能最低下的分布式數(shù)據(jù)庫(kù)。要是我們整個(gè)行業(yè)沒(méi)有認(rèn)定關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)(RDBMS)是自切片面包以來(lái)這40年來(lái)最出色的技術(shù)，那么我們果真會(huì)開(kāi)發(fā)出這種怪獸?
HDFS
用Java編寫(xiě)一種系統(tǒng)級(jí)服務(wù)不是最好的想法。Java的內(nèi)存管理也使得傳送大量字節(jié)有點(diǎn)慢。HDFS NameNode的工作方式對(duì)任何任務(wù)來(lái)說(shuō)不是很理想，造成了瓶頸。各家廠商拿出了變通方法，改善這種情況，但是坦率地說(shuō)，市面上有更好的技術(shù)。還有其他分布式文件系統(tǒng)。MaprFS就是一種設(shè)計(jì)相當(dāng)出色的分布式文件系統(tǒng)。還有Gluster及另外一批文件系統(tǒng)。
重慶分公司
重慶分公司
