那些技术升级或更换至关重要，这关系到大数据项目获得成功，还是你在今后几年通过行动让大家原谅你的过失。下面是你应该开始考虑更换掉的大数据架构中的一些要素。

我们踏上这个大数据征程已有一段时日了。一切不再依然光鲜亮丽。实际上，一些技术可能会阻碍你的步伐。切记，大数据是企业技术行业发展最快的一个领域，快得一些软件还没有站稳脚跟，更好的技术就已扑面而来。

那些技术升级或更换至关重要，这关系到大数据项目获得成功，还是你在今后几年通过行动让大家原谅你的过失。下面是你应该开始考虑更换掉的大数据架构中的一些要素。

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及另外一批文件系统。

着眼于未来，是时候剔除一批看起来大有希望，但是已变得落后或过气的技术了。这是我的全文，还有什么技术是我要补充上去的吗?

本文转自d1net（转载）