大数据开发，Hadoop Spark太重？你试试esProc SPL
2023-02-26 07:26:15
esProc SPL是一个轻量级大数据计算引擎，相比Hadoop/Spark，具有技术轻、使用简单、成本低等优势，适合数据量并非特别巨大的场景。具体介绍如下：
技术轻- 高性能算法与存储方案
SPL提供了众多高性能算法（有许多是业界首创）以及高效的存储方案，同等硬件环境下可以获得远超过数据库的运算性能。安装在单机上的SPL就可以完成很多大数据计算任务，架构比集群简单很多。
高性能算法示例：
- 轻量级集群计算功能
个性化节点配置：对于数据量更大的情况，SPL实现了轻量级集群计算功能，其设计目标是几台到十几台节点的集群，采用与Hadoop完全不同的实现方法。SPL集群不提供复杂沉重的自动化管理功能，而是允许对每个节点进行个性化配置。程序员可以根据数据特征和计算目标来决定各节点存储什么样的数据，完成哪些计算，大大降低了架构复杂度，也是提升性能的重要手段。
订单分析示例：以订单分析为例，订单表很大，要通过产品号字段与较小的产品表主键做关联，再按照产品供应商分组汇总订单金额。SPL集群可以很容易的将订单表分段存放在各个节点的硬盘上，再将较小的产品表读入每个节点的内存中。计算时，每个节点仅对本机上的订单分段和产品数据做关联、分组汇总，可以缩短总计算时间；再将结果传输到一个节点上做二次汇总。由于传输的是第一次汇总的结果，数据量小、网络传输时间较短。总体来说，这个方案可以获得最佳性能，虽然程序员需要做一些更细致的工作，但对于小规模集群来说，增加的工作量并不大。
适度容错能力：SPL不提供超强的容错能力，不会像Hadoop那样，在有节点故障的情况下，还要保证任何一个任务都会执行成功。实际上，大多数计算任务的执行时间都在几个小时以内，而几台、十几台机器的集群一般都能做到较长时间正常运行，不会频繁出故障。即使偶尔出现节点故障导致任务执行失败，再重新计算一遍也可以接受。所以，SPL的容错能力只是保证有少数节点故障的时候，整个集群还能继续工作并接受新任务（包括重算的任务），这就大大降低了SPL集群的复杂度。
内存计算优化：在内存计算方面，SPL没有使用Spark RDD的immutable机制，而是采用了指针式复用机制，利用地址（指针）访问内存，在数据结构没有改变的情况下，直接用原数据的地址形成结果集，不必每个计算都将数据复制一遍，仅仅多保存一个地址（指针），可以同时减少CPU和内存的消耗，运行起来要比Spark轻很多。并且，SPL改进了当前的外存计算算法体系，降低了复杂度并扩大了适应范围，可以做到内外存计算结合，充分提升计算性能的同时，还不像Spark那样依赖大内存。
- 易于安装、配置和运行维护：SPL采用轻量级技术，自然更容易安装、配置和运行维护。SPL不仅可以作为独立服务器使用，还很容易集成到需要高性能计算的应用中，比如即时查询系统，只要引入几个jar包即可。Hadoop则很难集成，只能在边上作为一个数据源运行。有些临时性数据需要随时进行处理，则可使用SPL的桌面集成开发环境可视化地计算，快速得到结果。如果要安装部署Hadoop，那么等环境搭建好时临时数据任务已经过期了。
- 编程简单：前面展示的众多SPL高性能算法，也能让大数据计算编程变得简单。程序员可以在较短时间内掌握这些算法函数，学习成本相对较低。而且，使用这些现成的函数很容易实现各种复杂的计算需求，不仅比MapReduce/Scala简单，比SQL也简单很多。
漏斗分析代码对比：
SQL实现三步漏斗：
SQL写出来要三十多行，理解起来有相当的难度。如果用MapReduce/Scala来写，会更加困难。即使是用SQL实现，写出来的这段代码和漏斗的步骤数量相关，每增加一步就要再增加一段子查询。- SPL实现：相比之下，SPL就简单得多，处理任意步骤数都是下面这样简洁的代码：
- 订单分析集群计算代码：SPL集群计算的代码也非常简单，比如前面提到的订单分析计算，具体要求是：大订单表分段存储在4个节点上，小产品表则加载到每个节点的内存中，两表关联之后要按照产品供应商分组汇总订单金额。用SPL写出来大致是下面这样：这段代码执行时，任务管理（内存加载、任务拆分、合并等）所需要的计算资源，远远小于关联和分组汇总计算的消耗。如此轻便的任务管理功能，可以在任意节点、甚至是集成开发环境IDE上执行。成本低- 人力资源成本低：与Hadoop相同，SPL也是开源软件，不同的是SPL不仅软件免费，综合成本也非常低。SPL安装、配置、运维很容易，可以大大降低支持人员的人力资源成本。同时，由于SPL降低了大数据计算编程的难度，程序员很容易实现各种复杂的计算，开发效率显著提高，也就节省了程序员的人力资源成本。
- 硬件采购成本低：由于SPL技术体系非常轻，平台自身占用的CPU、内存和硬盘很少，可以让更多的资源用于业务计算，能大幅提高硬件利用率。SPL也不像Spark那样依赖大内存，总体来说，大大减少了硬件采购成本。
SPL技术轻、自身消耗小，而且还提供了众多高性能算法，所以，在几个到几十个节点的集群，甚至单机的情况下，比Hadoop/Spark有更好的性能表现。
- 案例1：某电商漏斗分析计算
Spark：6节点，每节点4CPU核，平均计算时间：25秒。
SPL：单机，8线程计算，平均计算时间可达10秒。代码量仅有Spark Scala的一半。
- 案例2：某大型银行用户画像分析
Hadoop上某OLAP服务器：虚拟机100CPU核，计算时间：120秒。
SPL：虚拟机12CPU核，计算时间：仅4秒。性能提高250倍。
- 案例3：某商业银行的手机银行APP，活期明细查询，数据量大且高并发
基于Hadoop的某商用数据仓库：高并发时无法达到秒级的响应速度，只好换用6台ES集群。
SPL单机：达到6台ES集群同样的并发和响应能力。
热门标签
