我們已經(jīng)在大數(shù)據(jù)領(lǐng)域進(jìn)行了很長(zhǎng)時(shí)間的探險(xiǎn)了，雖然大數(shù)據(jù)已經(jīng)不再讓人眼前一亮和感到新鮮，但技術(shù)的不斷更新足以讓你時(shí)刻關(guān)注這個(gè)領(lǐng)域。同時(shí)，這也是很多企業(yè)技術(shù)更新最快的領(lǐng)域，但還是有一些技術(shù)會(huì)長(zhǎng)期占據(jù)靠前的位置，直到有更好的替代品出現(xiàn)為止。

許多技術(shù)在未來(lái)面臨著很大變化，或者重大升級(jí)。以下的這些技術(shù)，你或許可以考慮替換掉了：

1、MapReduce。 MapReduce速度很慢，它很少成為解決問(wèn)題的最佳方式。還有其他算法可供選擇 - 最常見(jiàn)的是DAG，其中MapReduce可以被認(rèn)為是一個(gè)子集。如果你做了一堆自定義的MapReduce作業(yè)，Spark在性能上的優(yōu)勢(shì)絕對(duì)值得你為了切換在Spark上運(yùn)行付出的成本。

2、Storm，雖說(shuō)不敢確定Spark是否占據(jù)了整個(gè)流媒體市場(chǎng)。但是相比于Spark而言，Apex或者Flink似乎在性能上更加優(yōu)秀，有著更低的延遲，更適合作為Storm的替代品。選用工具之前，你應(yīng)該先評(píng)估你能允許的延遲范圍是多少以及代碼的最低出錯(cuò)率是多少。Hortonworks作為Storm的唯一支持者，也在面臨著越來(lái)越大的市場(chǎng)壓力，未來(lái)的Storm可能不會(huì)得到太多關(guān)注。

3、Pig。Pig是一種編程語(yǔ)言，它簡(jiǎn)化了Hadoop常見(jiàn)的工作任務(wù)。Pig最大的作用就是對(duì)mapreduce算法(框架)實(shí)現(xiàn)了一套shell腳本 ，類(lèi)似我們通常熟悉的SQL語(yǔ)句。但Pig現(xiàn)在也備受打擊，似乎用它可以完成的事情，很多其他技術(shù)也可以完成。

4、Java。不僅僅是JVM，而是一門(mén)編程語(yǔ)言。大數(shù)據(jù)很多任務(wù)所用的語(yǔ)法都很笨重。而且，即便是Lambda這樣較新的結(jié)構(gòu)也以一種尷尬的方式被放在一邊。大數(shù)據(jù)的世界中很多工作已經(jīng)轉(zhuǎn)移到Scala和Python上了(如果你能承受性能損失，可以使用Python庫(kù)或雇傭Python開(kāi)發(fā)人員)。 當(dāng)然，你可以使用R語(yǔ)言的stats包，但最后你可能還是會(huì)用Python重寫(xiě)它，因?yàn)镽語(yǔ)言缺少很多特征。

5、Tez。這是Hortonworks的另一個(gè)項(xiàng)目，支持DAG作業(yè)的計(jì)算框架，而其開(kāi)發(fā)人員認(rèn)為T(mén)ez更像是“匯編語(yǔ)言”。與此同時(shí)，隨著Hortonworks將其發(fā)布，你就完全不需要在Hive或者其他工具之后使用它了，你可以在其發(fā)行版中使用Spark作為引擎。 雖說(shuō)發(fā)行了，但Tez總是有各種bug。 同樣地，這也是一個(gè)供應(yīng)商項(xiàng)目，沒(méi)有其他技術(shù)廠商或社區(qū)支持。相比其他解決方案，它似乎并沒(méi)有什么優(yōu)勢(shì)。

6、Oozie。它不是一個(gè)單純的工作流引擎或調(diào)度程序，它二者都是。它并不難用，與Tez相比，Tez偏底層，Oozie偏頂層，但你應(yīng)該可以在StreamSets，DAG實(shí)現(xiàn)和其他工具之間，找到可以替代Oozie的。

7、Flume。 在StreamSets、Kafka以及其他解決方案之間，你總能找到一個(gè)足以替代Flume的。 Apache Flume是一個(gè)分布式、高可靠和高可用的收集、集合和將大量來(lái)自不同來(lái)源的日志數(shù)據(jù)移動(dòng)到一個(gè)中央數(shù)據(jù)倉(cāng)庫(kù)。目前有兩個(gè)可用的發(fā)布版本，0.9.x和1.x。但Flume是時(shí)候快速發(fā)展了，再不往前一步，就只能后退了。

可能2018年會(huì)這樣......

接下來(lái)會(huì)發(fā)生什么?一些技術(shù)可能已經(jīng)到年齡了，但完全合適的替代品可能還沒(méi)出現(xiàn)。

1、Hive。Hive好像是地球上性能最差的分布式數(shù)據(jù)庫(kù)。如果沒(méi)有數(shù)據(jù)倉(cāng)庫(kù)這個(gè)概念，誰(shuí)會(huì)開(kāi)發(fā)這樣一個(gè)東西呢?只在數(shù)據(jù)倉(cāng)庫(kù)的統(tǒng)計(jì)分析上有些用處，不適用于所有要求低延遲的任務(wù)。

2、HDFS。在Java中編寫(xiě)系統(tǒng)級(jí)服務(wù)不是最好的想法。Java的內(nèi)存管理也使得推送大量的字節(jié)有點(diǎn)慢。HDFS NameNode的工作方式不是很理想，并構(gòu)成瓶頸。各種供應(yīng)商都有解決方法，但老實(shí)說(shuō)，更好的工具是存在的，還有其他分布式文件系統(tǒng)，比如MaprFS就是一個(gè)不錯(cuò)的選擇，還有Gluster.......

結(jié)語(yǔ)

總結(jié)下來(lái)，未來(lái)的Spark、Apex、Flink還有著廣闊的發(fā)展前景，而Storm、Hive、HDFS等等看起來(lái)已經(jīng)過(guò)時(shí)或者用處不大的技術(shù)應(yīng)該從你的名單上剔除了。或者也可以看看，還有哪些值得添加到名單里的，評(píng)論告訴我。