Hadoop Spark太重，esProc SPL很轻

---

LogiKM(改名KnowStreaming) 是滴滴开源的Kafka运维管控平台, 有兴趣一起参与参与开发的同学,但是怕自己能力不够的同学,可以联系我,当你导师带你参与开源！ 。

文章目录

• • Hadoop/Spark之重
  • 轻量级的选择
  • SPL既轻且快
  • SPL资料

随着大数据时代的来临，数据量不断增长，传统小机上跑数据库的模式扩容困难且成本高昂，难以支撑业务发展。很多用户开始转向分布式计算路线，用多台廉价的PC服务器组成集群来完成大数据计算任务。Hadoop/Spark就是其中重要的软件技术，由于开源免费而广受欢迎。经过多年的应用和发展，Hadoop已经被广泛接受，不仅直接应用于数据计算，还发展出很多基于它的新数据库，比如Hive、Impala等。

Hadoop/Spark之重

Hadoop的设计目标是成百上千台节点的集群，为此，开发者实现了很多复杂、沉重的功能模块。但是，除了一些互联 巨头企业、国家级通信运营商和大型银行外，大多数场景的数据量并没有那么巨大。结果，经常能看到只有几个到十几个节点的Hadoop集群。由于目标和现实的错位，对很多用户来讲，Hadoop成了一个在技术、应用和成本上都很沉重的产品。

技术之重

如果真的有几千台计算机组成的集群，是不可能依靠手工个性化管理的。试想，将这些计算机罗列出来，运维人员看都看不过来，更别说管理和分配任务了。再说，这么多机器，难免会不断出现各种故障，怎么保证计算任务顺利执行doop/Spark的开发者为了解决这些问题，编写了大量代码，用于实现自动化节点管理、任务分配和强容错功能。

但是，这些功能本身就要占用很多计算资源（CPU、内存和硬盘等），如果用到几台到十几台节点的集群上，就太过沉重了。集群本来就不大，Hadoop还要占用相当一部分的资源，非常不划算。

不仅如此，Hadoop产品线很长，要把这些模块都放在一个平台上运行，还要梳理好各个产品之间的相互依赖性，就不得不实现一个包罗万象的复杂架构。虽然大多数场景只用其中一两个产品，也必须接受这个复杂、沉重的平台。

后来出现的Spark弥补了Hadoop对内存利用的不足，技术上是不是可以变轻呢憾，Spark走向了另一个极端，从理论模型上就只考虑内存计算了。特别是Spark 中的 RDD 采用了 immutable 机制，在每个计算步骤后都会复制出新的 RDD，造成内存和 CPU 的大量占用和浪费，离开大内存甚至无法运行，所以技术上还是很重。

使用之重

Hadoop技术上太过复杂，也就意味着安装和运维会很麻烦。集群只有几台计算机时，却不得不使用为几千台节点集群设计的节点管理、任务分配和容错功能。可想而知，安装、配置、调试都很困难，日常运行的维护、管理工作也不容易。

即使克服这些困难让Hadoop运行起来了，编写大数据计算代码时还会面临更大的麻烦。Hadoop编程的核心框架是MapReduce，程序员要编写并行程序，只要写 Map 和 Reduce 动作即可，用来解决求和、计数等简单问题也确实有效。但是，遇到复杂一些的业务逻辑，用MapReduce编程就会变得非常困难。例如，业务计算中很常见的JOIN计算，就很难用MapReduce实现。再比如，很多和次序有关的运算实现起来也很困难。

Spark的Scala语言具备一定的结构化数据计算能力，是不是能简单一些呢惜，Scala使用难度很大，难学更难精。遇到复杂一些的运算逻辑，Scala也很难写出来。

MapReduce、Scala都这么难，所以Hadoop/Spark计算语法开始回归SQL语言。Hive可以将SQL转化为MapReduce所以很受欢迎，Spark SQL的应用也比Scala广泛的多。但是，用SQL做一些常规查询还算简单，用于处理多步骤过程计算或次序相关运算还是非常麻烦，要写很复杂的UDF。而且，许多计算场景虽然勉强能用SQL实现，但是计算速度却很不理想，也很难进行性能调优。

成本之重

虽然 Hadoop 软件本身开源免费，但它技术复杂、使用困难，会带来高昂的综合成本。

前面说过，Hadoop自身会占用过多的CPU、内存和硬盘，而Spark需要大内存支撑才能正常运行。所以不得不为Hadoop/Spark采购更高配置的服务器，要增加硬件支出。

Hadoop/Spark使用困难，就需要投入更多的人力去完成安装、运维，保证Hadoop/Spark的正常运转；还要投入更多的开发人员，编程实现各种复杂的业务计算，要增加人力资源成本。

由于使用过于困难，很多用户不得不采购商业公司的收费版本Hadoop/Spark，价格相当可观，会大幅增加软件采购成本。

既然Hadoop如此沉重，为什么还有很多用户会选择它呢很简单：暂时找不到别的选择，也只有Hadoop勉强可用，好歹知名度高一些。

如此一来，用户就只能安装、配置Hadoop的重型应用，并忍受Hadoop本身对计算资源的大量消耗。小规模集群的服务器数量本来就不多，Hadoop又浪费了不少，小马拉大车，最后运行的效果可想而知。花了大价钱采购、费事费力的使用Hadoop，实际计算的性能却不理想。

就没有别的选择了p>

轻量级的选择

开源的esProc SPL是轻量级大数据计算引擎，采用了全新的实现技术，可以做到技术轻、使用简单、成本低。

技术轻

所以，我们应该想办法设计更高效的算法，而不是一味地追求分布式计算。按照这个思路，SPL提供了众多高性能算法（有许多是业界首创）以及高效的存储方案，同等硬件环境下可以获得远超过数据库的运算性能。安装在单机上的SPL就可以完成很多大数据计算任务，架构比集群简单很多，从技术上自然就轻的多了。

SPL的高性能算法有下面这些：