我們踏上這個大數據征程已有一段時日了。一切不再依然鮮豁亮麗。實際上，一些技能大概會阻礙你的步驟。切記，大數據是企業技能行業成長最快的一個規模，快得一些軟件還沒有站穩腳跟，更好的技能就已撲面而來。
那些技能進級或改換至關重要，這干系到大數據項目得到樂成，照舊你在此后幾年通過動作讓各人原諒你的紕謬。下面是你應該開始思量改換掉的大數據架構中的一些要素。
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
它不是什么了不得的事情流引擎，也不是什么了不得的調治器，不外它想搞好這兩者，卻都搞欠好!然而，它有一大堆的軟件缺陷，這款軟件編寫起來不應很難。面臨StreamSets、DAG實現以及其他一切，你應該有的是步伐來處理懲罰Oozie處理懲罰的大部門任務。
Flume
在StreamSets、Kafka 及其他辦理方案之間，你大概有Flume的替代方案。2015年5月20日宣布的這個版本看起來有點過氣了。你可以跟蹤闡明較上年同期的勾當強度。很多人離它遠去，也許是該翻篇的時候了。
也許到2018年……
還剩下什么?一些技能日漸老朽，可是完全切實可行的替代方案還沒有問世。不妨事先想想改換掉這些技能：
Hive
有點過于吹毛求疵了，可是Hive比如是市面上機能最低下的漫衍式數據庫。要是我們整個行業沒有認定干系數據庫打點系統(RDBMS)是自切單方面包以來這40年來最精彩的技能，那么我們果然會開拓出這種怪獸?
HDFS
用Java編寫一種系統級處事不是最好的想法。Java的內存打點也使得傳送大量字節有點慢。HDFS NameNode的事情方法對任何任務來說不是很抱負，造成了瓶頸。各家廠商拿出了變通要領，改進這種環境，可是坦率地說，市面上有更好的技能。尚有其他漫衍式文件系統。MaprFS就是一種設計相當精彩的漫衍式文件系統。尚有Gluster及別的一批文件系統。
