现代大数据应用的结构大概是这样的：

作为数据中心（中间部分）处于各种应用与数据源之间，对下对接多种数据源处理分析所有数据，对上要为各个应用提供数据服务，其重要性不言而喻。数据中心由于要处理的数据规模庞大、要响应的任务繁多，几乎都会采用大数据集群技术实现，这样才能满足庞大的业务需求，同时还可以横向扩容提升算力以满足不断增长的业务需要。

这是一个重型解决方案。

与其他技术一样，这种架构在实际应用时也会存在一些缺点：

首先是运维复杂。集群运行使用离不开运维，通常规模越大运维复杂度越高。而当前大数据技术对硬件的资源利用率并不高，这就需要投入更多硬件来弥补，导致集群规模越来越大，推高运维复杂度和运维成本。

其次是体系封闭。目前无论采用何种大数据技术，都会面临封闭性的问题。所谓封闭性是指数据只有“进来”才能算，数据在内在外有严格的区别。外部数据要先搬进来意味着先要有个 ETL 过程，这不仅会增加工作量，还会丧失数据的实时性。而现代企业的数据来源种类繁多，每次都要先搬再用显然会降低数据的使用效率，还会增加成本。

还有耦合性问题。数据中心为所有应用提供服务，某些数据处理任务可能被多个应用所共用，从资源节约的角度来看这当然是合理的，但表（存储）和计算逻辑（代码）共用会造成应用与应用间紧耦合，这既不利于应用扩展（修改可能会影响其他应用），也会增加运维难度（某些功能下线也不敢删除），导致整个数据中心过于臃肿，运维更复杂，经常面临扩容压力。

数据中心建设的初衷是为整个企业提供数据服务，但似乎又不能把所有任务都压给数据中心来做，这涉及到程度问题。如果数据中心压力过大，就要想办法分担其计算任务。

常见的做法是将一部分计算分散到应用端完成，尤其是一些临时性、个性化的需求在应用端就消化了没必要全都压给数据中心来做。但采用何种方式来实现应用端数据处理任务呢？

可以想到的是在原有架构基础上再增加一个前置计算层来分担部分计算。其表现形式可以是多个数据集市，每个集市为某一类应用专属，这样不仅分担了计算还能解决应用间的耦合性问题。

那么具备采用什么技术来建设呢？

采用建设数据中心的大数据技术显然不行，这些技术过于依赖集群，对于体量相对较小的前置计算来说过于沉重，一套下来极可能不如扩容数据中心来得直接。而且数据集市会建设多个，架构变复杂运维难度增大，成本会远远大于数据中心扩容，得不偿失。

采用传统数据库行不行？数据库没有集群技术那么重，同时计算能力也挺强，似乎挺适合。但是数据库仍然很重。绝大部分数据库还是需要单独部署，这在物理架构上就要增加一层，需要独立的硬件资源同时架构和运维也更复杂，成本仍然较高。此外，还有两个关键因素导致数据库不太适合用来实施前置计算。

一是数据范围的问题。我们搭建前置计算（数据集市）的目的是为了分担数据中心的计算压力，但计算不能脱离数据完成，那么问题来了，哪些数据需要搬到数据集市中呢？范围太小恐怕不行，太小了应用动不动就查不到就失去了前置计算的意义；范围太大也不行，把全部数据都搬过去是什么都能查到了，但容量又是个问题，且不论能不能容纳得下，这么干又相当于建设了个数据中心，重复建设也没意义。其实，即使使用大数据技术也会存在这个问题，数据集市只存储部分数据就会面临查不到的情况。

二是SQL 本身的问题。SQL 运行需要元数据，元数据加载和使用的效率很低，加之数据库的封闭性所有数据都要入库才能使用，这就造成了使用上的沉重。另一方面，SQL 的语言能力并不完善，在实际业务中有一些复杂计算用 SQL 很难实现（比如涉及有序步骤的电商漏斗计算），需要借助 Python 或 Java 等其他语言来做，导致技术栈复杂、沉重。而 SQL 本身写起来也不简单，业务中上千行嵌套多层的 SQL 很常见，这种 SQL 不仅难写还难维护，导致开发上也很重。SQL 的问题不仅作用在数据库上，很多支持 SQL 的大数据技术也同样存在这些问题。

综合来看，应用端计算需要的是一种不依赖于数据库的、可被集成嵌入的、具备较强开放性能直接处理多源数据、能够解决数据范围问题、简单方便的轻量级大数据处理技术，但现在这些技术都存在这样那样的问题。

开源的 esProc SPL 可以很好解决这些问题。

轻量级大数据计算引擎 esProc SPL

esProc 是一个专门面向大数据的结构化数据计算引擎，不仅可以独立部署，还可以与应用集成作为应用内嵌入引擎使用，整体表现更轻。esProc 具备良好的开放性，支持多种数据源混合计算，同时提供的高性能计算机制可以充分利用硬件资源将单机计算性能发挥到极致，实现单机顶级群的效果，应用成本更低。同时，esProc 支持数据路由，可以将计算路由到本地或数据中心。此外，esProc 提供的 SPL（Structured Process Language）语法具备良好的敏捷性，更擅长完成复杂计算，从而让 esProc 从部署到使用都很轻。

esProc 技术架构

集成性

esProc 支持独立和集成部署，既可以独立对外提供服务，也可以与应用集成在一起作为应用的一部分使用。集成时 jar 包嵌入即可，整体才几十 M 非常轻量。集成后，esProc 作为应用逻辑上的计算层，对下访问数据源，对上提供数据服务（封装了通用的 JDBC/ODBC/RESTful 接口）。

良好的集成性使得计算不再沉重，引擎嵌入应用内部，随应用使用十分灵活，架构上不用做多余的调整，运维复杂度几乎没有增加，同时硬件也无需额外投入。

当算力不够时还可以部署独立计算服务，esProc 支持分布式部署，提供负载均衡与容错等全部集群计算能力。

这是引入 esProc 以后的应用架构，可以看到 esProc 可以嵌入应用内工作，这样物理上的前置计算层就可以不用，当需要增强计算能力时再部署独立的计算服务，在使用时更灵活。

开放性

esProc 没有主题（元数据）的概念，没有库内库外之分，随便什么数据，只要能访问到就能一起参与运算，无非只是不同数据源的访问性能不同。良好的开放性可以解决原来数据库封闭造成的容量、数据实时性差以及无法利用各类数据源自身优势等问题。

在 esProc 的开放性支持下还很容易实施空间换时间的手段，冗余数据直接存储在文件系统中，不会造成任何容量压力，无论单独使用还是与其他数据源混合计算都很方便。

高性能

和数据库类似，esProc 也提供了存储能力，可以将数据存储在本地来使用。但与数据库不同的是，esProc 直接采用文件存储，目前提供了高性能二进制文件格式，提供了压缩、列存、有序、并行分段等诸多保证计算性能的存储机制。

同时，在数据类型和计算类库方面也更加丰富。借助这些高性能算法可以实现更低复杂度的运算从而提高性能。在实际应用中，esProc 经常比其他技术快几倍到几十倍，有的甚至达到上千倍。比如在计算用户流失率的电商漏斗分析场景中，用户使用 Snowflake 的 Medium 服务器（相当于 4*8=32 核）3 分钟没有跑出来；而 esProc 在一个 12 核 1.7G 的低端服务器上仅用不到10 秒就跑出来了。还有国家天文台的天体聚类任务中 esProc 的性能相较其他实现（Python 和某分布式数据库）快了 2000 倍。

有了这些高性能保障机制，esProc 的单机表现就很突出了，有些场景使用单机就可以达到甚至超过原来集群的效果（单机顶集群）。这样在使用时可以优先考虑集成嵌入，如果性能还达不到要求，再独立部署一台 esProc 节点基本就能满足要求。

数据路由

esProc 提供了可编程的数据路由功能。当前置计算层（物理上可以单独也可以与应用集成在一起）存储部分数据（同上是经常使用的热数据）时，如果应用数据需求超出了前置层存储的范围，esProc 会自动将请求路由到后端数据中心上执行，继而为应用返回查询结果。路由规则可以在计算脚本中自由设定。

更多内容请参考： 可路由计算引擎实现前置数据库

敏捷性

前面我们提到，当前技术的重不仅体现在技术架构上，还包括 SQL 语法体系的重。esProc 没有继续使用 SQL，而是基于新的理论模型设计了 SPL 语法。在以往的实际案例中，esProc 不仅能提升性能，还会大幅缩短代码。相对 SQL，SPL 更擅长实现复杂计算，这是因为 SPL 不仅支持过程计算可以分步编码，还提供了循环、分支、过程、子程序等完整的编程能力；提供了非常丰富的结构化数据计算类库。

在电商漏斗计算的例子中，SPL 实现就 SQL 短得多，而且更具有通用性（漏斗多一步 SQL 就要增加一个子查询），这都是 SPL 语法的优势。有了这样的敏捷性语法，完备的计算能力，再叠加使用灵活和高性能已经能完全做到轻量大数据计算了。

总结一下，esProc 之所以能够实现轻量级大数据计算，在应用端为应用提供前置计算服务，是由其集成性、开放性、高性能、数据路由能力和敏捷性综合作用的结果。有了这些特性，就可以很容易满足无处不在的应用计算需求，保证高性能的同时应用成本也更低，总体表现更轻。