随着大数据时代的出现，数据量继续增长。在这种情况下，很难扩大在传统的小型计算机上运行数据库的能力，从而难以支持业务开发。为了解决此问题，许多用户开始转向分布式计算路由，即使用多个廉价的PC服务器形成群集来执行大数据计算任务。 Hadoop/Spark是这条路线中重要的软件技术之一，因为它是开源且免费的，这很受欢迎。经过多年的应用和开发，Hadoop已被广泛接受，不仅可以直接应用于数据计算，而且基于IT开发了许多新数据库，例如Hive和Impala。
。Hadoop/Spark的重度
Hadoop的目标是设计一个由数百个节点组成的群集。为此，开发人员实施了许多复杂而重型的功能模块。但是，除了一些互联网巨头，国家通信运营商和大型银行外，在大多数情况下的数据量并不那么巨大。结果，通常看到只有几个或十二个节点的hadoop群集。由于目标与现实之间的错位，Hadoop成为许多用户，无论是技术，使用还是成本。现在，我们将解释Hadoop在上述三个方面很重的原因。
技术的重度
如果确实存在由数千台计算机组成的集群，则不可能依靠手动操作来执行个性化管理。我们可以想象，如果列出了这些计算机，计算机的数量将超出操作和维护人员可以接受的眼睛，更不用说管理和分配任务了。此外，当如此多的机器运行时，不可避免地会发生各种故障。在这种情况下，如何确保计算任务的平稳执行？为了解决这些问题，Hadoop/Spark开发人员编写了许多代码来实施功能，包括自动节点管理，任务分布和强大的容错。
但是，这些功能本身将占用大量计算资源（CPU，内存，硬盘等）。如果在几至十几个节点的集群上使用此类功能，则将太重。几个节点的簇原本不是很大，但Hadoop占据了很大的资源，这是非常不经济的。
除此之外，Hadoop的产品线很长。要将这些功能模块放在一个平台上运行，它需要整理各种产品之间的相互依赖性，因此，它必须实现一个无所不包的复杂体系结构。尽管大多数方案仅使用产品线的一两个产品，但他们必须接受这个复杂而繁重的平台。
后来出现的Spark弥补了Hadoop缺乏记忆利用率。遗体宣传：它可以使技术更轻松吗？遗憾的是，火花陷入了另一个极端。从理论模型的角度来看，Spark仅考虑内存计算。特别是，Spark中的RDD采用了不变的机制，每个计算步骤后将复制新的RDD，从而导致大量职业和浪费记忆空间和CPU。它甚至不能没有大记忆，因此在技术上仍然很重。
使用的重量
Hadoop在技术上太复杂了，这意味着安装，操作和维护将非常麻烦。即使群集只有几台计算机，它也必须使用节点管理，任务分布和可容忍功能，该功能为群集设计了数千个节点，因此您可以想象安装，配置和调试的难度由于日常操作的维护和管理。
即使解决了这些困难，并且Hadoop正常运行，在编写大数据计算代码时，您也会遇到更大的麻烦。 Hadoop中编程的核心框架是MapReduce，程序员只需要在编写并行程序时就编写地图并减少操作。确实，解决简单的问题（例如总和和计数）是有效的，但是，在遇到复杂的业务逻辑时，MapReduce中的编程将非常困难。例如，在MAPREDUCE中很难实现JOIN计算，这在业务计算中非常普遍。此外，也很难实施许多与订单相关的操作。
Spark的Scala具有一定的计算结构化数据的能力，在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如此沉重，为什么许多用户仍然选择它？原因很简单：用户暂时找不到替代方案，只能使用hadoop，至少它的声誉更高。
因此，用户只能安装和配置Hadoop的重型应用程序，并忍受Hadoop本身计算资源的巨大消费。小型集群中的服务器数量最初并不大，而Hadoop占用了许多，这将导致一种现象，即一个具有较少服务器的群集运行的计算任务超出了其容量，因此您可以想象跑步效果的速度将有多慢。简而言之，Hadoop既昂贵又费力，但是实际的计算性能并不理想。
没有其他选择吗？
轻巧的选择
开源ESPROC SPL是一种轻巧的大数据计算引擎，采用了新的实施技术，并具有技术在技术方面的优势，使用简单，成本较低。
技术光
正如本文开头所述的那样，不断增长的数据使传统数据库无法持有如此大量的数据，因此用户必须转向分布式计算技术。原因是很难在SQL中实施高速算法，而大数据的计算性能只能依赖于数据库的优化引擎，但是对于复杂的计算，这些优化引擎通常无能为力。
>因此，我们应该找到设计更有效算法的方法，而不是盲目地追求分布式计算。根据这个想法，SPL提供了许多高性能算法（其中许多是在行业中启用的）和有效的存储方案，因此我们可以获得在相同硬件环境下远远超过数据库的计算性能。安装在单台计算机上的SPL可以完成许多大数据计算任务，并且其架构比集群要简单得多，因此它在技术上自然要轻得多。
SPL的高性能算法包括：
对于大量数据，SPL可以实现轻质群集的计算功能。此功能是为少数到十几个节点的群集而设计的，该节点采用了Hadoop的完全不同的实现方法。
SPL群集不提供复杂且重型的自动化管理功能。相反，它允许您个性化每个节点的配置。程序员可以决定每个节点存储的哪种数据，以及每个节点根据数据的特征和计算目标执行的计算。这样，体系结构的复杂性不仅大大降低，而且也是提高性能的重要手段。
让我们以订单分析为例。当订单表较大时，我们希望将产品编号字段与较小产品表的主要键关联，然后将产品供应商分组并汇总订单数量。 SPL群集可以在每个节点的硬盘上轻松将订单表存储在段中，然后将较小的产品表读取到每个节点的存储器中。计算时，每个节点只需要将局部顺序段与产品数据相关联，然后将组和聚集物关联，这可以缩短总计算时间，此后，将聚合结果传输到下一个辅助聚合。由于传输的是第一个汇总结果，因此数据量很小，网络传输时间很短。总体而言，该方案实现了最佳性能。尽管程序员需要做一些更详细的工作，但对于小规模集群而言，增加的工作量并不大。
另外，SPL不提供强大的容错性。与Hadoop不同，SPL无需确保在节点故障的情况下成功执行任何任务。实际上，大多数计算任务的执行时间都在几个小时之内，而使用几个或十二台机器的聚类通常可以正常运行，而不会经常失败。即使由于偶尔的节点故障而导致任务执行失败，也可以接受。毕竟，这并不经常发生。因此，SPL的容错能力仅确保整个群集可以继续工作并接受新任务（包括重新计算）时，当一些节点失败时，这大大降低了SPL群集的复杂性。
。在内存计算方面，SPL不使用Spark RDD的不变机制，而是使用指针式的重复使用机制。该机制使用地址（指针）来访问内存，并直接使用原始数据的地址来形成一个结果，即数据结构未更改。由于无需在每个计算步骤中复制数据，唯一需要做的就是保存一个地址（指针），因此可以同时减少CPU和内存空间的消耗，因此比在操作中的火花轻得多。此外，SPL改善了当前的外部存储计算算法系统，降低了复杂性并扩大了适应性范围。此外，SPL可以结合内存和外部存储计算，以完全改善计算性能，而无需像Spark一样依赖大型内存。
简单使用
SPL采用轻型技术，自然更容易安装，配置，运行和维护。 SPL不仅可以用作独立服务器，而且还可以轻松地集成到需要高性能计算的应用程序中。例如，您只需要为即时查询系统导入一些罐子即可。相比之下，很难将Hadoop集成到此类应用程序中，因此，Hadoop必须在应用程序外作为数据源运行。需要随时处理一些临时数据，您可以使用SPL的桌面IDE来视觉计算以快速获得结果。但是，如果您想通过安装和部署Hadoop来处理此类临时数据任务，则在建立Hadoop环境后可能会过时。
上图中显示的高性能算法也使大数据计算的编程变得简单。程序员可以在较短的时间内掌握此类算法的功能，因此学习成本相对较低。此外，通过使用这些现成的功能，实现各种复杂的计算要求非常容易。因此，SPL比MapReduce/Scala更简单，并且比SQL更简单。
让我们以电子商务平台的常见渠道分析为例。用于实施三步漏斗的SQL代码大致如下：
with e1 as (
select gid,1 as step1,min(etime) as t1
from T
where etime>= to_date('2021-01-10', 'yyyy-MM-dd') and etime<to_date('2021-01-25', 'yyyy-MM-dd')
and eventtype='eventtype1' and …
group by 1
),
with e2 as (
select gid,1 as step2,min(e1.t1) as t1,min(e2.etime) as t2
from T as e2
inner join e1 on e2.gid = e1.gid
where e2.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e2.etime<to_date('2021-01-25', 'yyyy-MM-dd') and e2.etime > t1
and e2.etime < t1 + 7
and eventtype='eventtype2' and …
group by 1
),
with e3 as (
select gid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3
from T as e3
inner join e2 on e3.gid = e2.gid
where e3.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e3.etime<to_date('2021-01-25', 'yyyy-MM-dd') and e3.etime > t2
and e3.etime < t1 + 7
and eventtype='eventtype3' and …
group by 1
)
Select
sum(step1) as step1,
sum(step2) as step2,
sum(step3) as step3
from
e1
left join e2 on e1.gid = e2.gid
left join e3 on e2.gid = e3.gid
我们可以看到它需要在SQL中编码30多行，并且很难理解此代码。如果任务是在MapReduce/Scala中执行的，则将更加困难。即使在SQL中，该代码也与漏斗的步骤数有关，每个额外的步骤也需要一个子问题。
相反，SPL更简单，以下SPL代码可以处理任何数量的步骤：
A B
1 =["etype1","etype2","etype3"] =file("event.ctx").open()
2 =B1.cursor(id,etime,etype;etime>=date("2021-01-10") && etime<date("2021-01-25") && A1.contain(etype) && …)
3 =A2.group(id).(~.sort(etime)) =A3.new(~.select@1(etype==A1(1)):first,~:all).select(first)
4 =B3.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime<t1+7).etime, null))))
5 =A4.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3)
SPL的群集计算代码也非常简单。让我们以上面提到的订单分析计算为例。现在，我们想将大订单表存储在四个节点上，将小产品表加载到每个节点的存储器中，然后将两个表供应商组合在一起，然后将两个表供应商汇总到两个表供应商，请在两个表供应商相关联，SPL代码：
A B
1 ["192.168.0.101:8281","192.168.0.102:8281",…, "192.168.0.104:8281"]
2 fork to(4);A1 =file("product.ctx").open().import()
3
>env(PRODUCT,B2)
4 =memory(A1,PRODUCT)
5 =file("orders.ctx":to(4),A1).open().cursor(p_id,quantity)
6 =A5.switch(p_id,A4)
7 =A7.groups(p_id.vendor;sum(p_id.price*quantity))
执行此代码时，任务管理所需的计算资源（内存加载，任务分配，合并等）远远少于关联，分组和聚合所消耗的计算资源。任务管理功能非常轻，可以在任何节点甚至IDE上执行。
成本低
像Hadoop一样，SPL也是开源的，并且是免费的。但是，与Hadoop不同，由于以下两个原因，SPL的综合成本非常低：
一个人是人力资源的成本降低了。一方面，由于SPL的安装，配置，操作和维护非常简单，因此人力资源的相关成本大大降低了；对于另一个人来说，由于SPL降低了大数据计算的编程难度，因此程序员可以很容易地实施各种复杂的计算，并且开发效率大大提高，因此节省了程序员的成本。
。另一个是降低了硬件成本。由于SPL技术系统非常轻，并且该系统本身几乎没有CPU，内存和硬盘资源，因此它使更多资源用于业务计算，因此，硬件利用率大大改善了。此外，SPL不像Spark那样依赖大型内存。总体而言，硬件采购的成本大大降低了。
轻快的SPL
因为SPL的技术很轻，本身消耗较少，并且提供了许多高性能算法，因此SPL的性能要比Hadoop/Spark更好，对于几个或几十个机器，甚至只有数十个机器。
案例1：电子商务业务的渠道分析和计算。
Spark：6个带有四个CPU内核的节点，平均计算时间：25秒。
SPL：8个线程中的一台机器，平均计算时间：10秒。代码的量仅是Spark Scala的一半。
案例2：分析大型银行的用户配置文件。
Hadoop上的OLAP服务器：具有100个CPU内核的虚拟机，计算时间：120秒。
SPL：具有12个CPU内核的虚拟机，计算时间：仅4秒。性能提高了250次。
案例3：通过商业银行的移动银行应用程序查询经常帐户的详细信息。数据量很大，并发数很高。
基于Hadoop的商业数据仓库：由于当并发率高时无法实现第二个响应速度，因此必须用6 ESS的集群替换仓库。
SPL中的一台机器：它在相同的并发编号下具有相同的响应速度。
总而言之，来自顶级互联网企业的重型解决方案的Hadoop/Spark来源，适用于需要部署非常大集群的非常大型企业。尽管在许多情况下的数据量并不小，但小型集群甚至一台机器都可以完全处理它们，因为数据量的比例远远少于大型企业的规模，并且没有太多的硬件设备和维护人员。在这种情况下，SPL是轻量级的大数据计算引擎，是首选，因为它可以实现轻型技术，简单使用，更高的开发效率和更高的性能，成本非常低。
起源：https://blog.scudata.com/hadoop-spark-is-too-heavy-esproc-spl-is-light/
SPL源代码：https://github.com/SPLWare/esProc