关系数据库提供了 SQL，因而有较强的计算能力，但很遗憾的是，这个计算能力是封闭的。所谓计算封闭性，是指要被数据库计算和处理的数据，必须事先装入数据库之内，数据在数据库内部还是外部是很明确的。与之相对，计算开放性是指数据无需进入内部就可以直接处理多种来源的数据。

数据库有元数据，使用前要先定义表，数据要经过整理满足约束才能入库使用，封闭也就成了自然而然的事情了。反过来，什么样的计算能力是开放的呢？数据在使用之前无需整理就可以直接计算，没有任何约束限制，使用起来很灵活。

现在有很多这样的开放数据计算引擎，Spark 就是比较著名的一个。但 esProc SPL 更好一些，相对 Spark 不仅更轻，代码实现也更简单，计算性能也更高。

SPL 除了具备简洁的语法和高计算性能以外，具有很强的开放计算能力，不仅能直接对接多种数据源计算，还可以进行混合计算。

那么计算能力开放与封闭到底哪种更具优势呢？由于 SPL 和 SQL 经常被一起比较，这里我们不妨从开放性的角度来看看二者的不同，以及开放性对数据应用系统建设成本的意义。

解决多样性数据源直接计算

多样性数据源在现代企业信息化建设中十分常见，除了最常用的 RDB，还有 NoSQL、CSV/Excel、WebService 等等。作为综合性质的数据分析，数据来源可能分布在多种数据源中，要使用就涉及跨数据源计算。

SQL（数据库）在实现跨源计算方面表现较差，比如以 DBLink 为代表的跨库查询方案，不仅稳定性和效率很差，还只能基于数据库。因此在实际使用中经常会将多源数据先统一再计算，即将其他数据源数据通过 ETL 导入同一个数据库再使用，这样就避免了跨源计算的问题。但这种方式也会带来一些问题，主要表现在三方面。

首先是数据实时性问题。如果数据需要经过 ETL 入库才能使用，数据整理和入库都需要时间，而且数据库写入是一个很慢的动作，这个过程的时间损耗势必会导致数据的实时性差。除了时间成本，增加的这些过程就会增加开发成本，毕竟这些工作也需要人来完成。

其次是存储成本。多源数据存储到一个数据库中要占用宝贵的数据库存储空间，增加存储成本，增大扩容压力。事实上，很多数据并不需要持久化到数据库，尤其是一些临时查询。而数据库的“封闭性”要求只有进来才能算，不存不行。

再次，无法利用多样性数据源自身的优势。我们知道，之所以会出现多样数据源的情况就是因为各类数据源都有自己独特的优势，能在不同的应用场景下发挥作用。如 RDB 的计算能力较强，但 IO 效率较低，因此会承担更多的计算任务；NoSQL 恰好反过来，IO 性能高，并且可以采用多种 / 多层的动态结构十分灵活，但计算能力往往较弱；文本 /JSON 等文件则完全没有计算能力，但使用和管理更加灵活，也更容易实施并行计算提升性能。如果数据都统一到 RDB 中将无法再利用这些数据源自身的优势，导致应用成本增加，同时也需要花费更多的硬件成本来弥补同库带来的损失。

再来看 SPL。

SPL 具备更强的开放性，提供了多种数据源支持，这些数据源可以直接拿来使用计算。更重要的是，SPL 还可以针对数据源进行连接混合计算。

支持多样数据源（混算）以后，就可以节约“入库”带来的开发与时间成本，多源实时计算可以充分保证数据的实时性，实现数据分库后的 T+0 查询也不再是问题。同时，数据不再无脑入库，数据库的存储成本也将大大降低，扩容压力减轻。

SPL 还可以充分保留各类数据源的优点，RDB 的计算能力较强，在很多场景下就可以让 RDB 先完成一部分计算后再由 SPL 接管；NoSQL 和文件的 IO 传输效率高 SPL 就可以直接读取计算；MongoDB 支持多层数据存储，SPL 直接使用会很方便…… 这些都将大幅节约人力与软硬件成本。

延伸阅读： 多数据源混合计算用什么技术？

规避存储过程的弊端

使用 SQL 解决复杂计算问题时，存储过程是常见的技术。使用存储过程将 SQL 过程化，将复杂计算通过分步的方式实现，这样可以应对足够复杂的计算场景。但存储过程的缺点也很明显：没有移植性，不同数据库对存储过程的支持程度不同，几乎无法进行移植，更难以进行扩展。而且存储过程难以开发调试，开发成本也高。同时，多个应用共用存储过程还会造成应用间紧耦合，导致应用成本增加。此外，存储过程还存在管理和安全性方面的问题，数据库的扁平结构无法像文件系统的树形结构管理存储过程，多了以后就会陷入管理混乱带来管理问题；存储过程的创建和修改需要较高的数据库权限，这就带来安全隐患，整体使得运营成本增加。现在很多企业已经明确禁止使用存储过程了，由此可见存储过程的缺点的确很难容忍。

那么如何解决这个问题呢？我们稍加思考就会发现，之所以使用存储过程是因为要借助数据库的计算能力，SQL 纵有千般不好，但总比 Java 这些高级语言简单甚至高效得多，因此依赖数据库成了自然而然的事情。如果在库外计算也能达到相同的效果，当然可以替代存储过程。将存储过程移到库外，使用 SPL 实现“库外存储过程”就可以解决这些问题。

SPL 提供不依赖数据库的开放计算能力，数据库更换不需要更改 SPL 计算脚本，解决存储过程的移植性问题；简洁易用的 IDE 环境编辑调试功能齐全，算法实现更加简单； “外置存储过程”不依赖数据库，可随应用存放解决耦合性问题；借助文件系统的树状结构进一步解决管理问题；SPL 独立数据库运行，更不会带来安全问题。

因此，即使我们撇开存储过程的难写和性能低下（参考： SPL 比 SQL 更难了还是更容易？ ）的问题不谈，单从开放性的角度来看，SPL 就可以带来非常多好处。

延伸阅读：爱恨交加的存储过程该往何处去

消灭中间表减少不必要的数据库

数据库中间表通常是为了方便后续计算生成的中间结果，在数据库中以表的方式存储，即形成中间表。有的复杂计算没法一步算完会先存储中间表再算，有时为了提升查询性能会事先将查询结果加工成中间表再用，前面提到的多样数据入库同样会形成中间表。中间表一旦创建往往很难删除，因为不确定这个表是否还有其他应用在用，因此会越积越多，有时竟高达数万张。中间表过多会带来容量和性能两方面的问题。

中间表存储需要空间，占用过多的数据库空间就会提升存储成本，带来扩容压力；中间表过多也会带来管理困难，增加管理成本；中间表的生成和维护都需要定时计算才能完成，即使中间表不再使用也常常由于不知道耦合关系而不敢删除，这些无用的中间表仍然会消耗数据库计算资源导致数据库资源告急，带来性能问题，提升硬件成本。

其实，中间表之所以存储在数据库中是因为仍然要利用数据库（SQL）的计算能力，因为中间表后续还要使用（计算），如果存成文件就只能（用 Java）硬编码相比 SQL 要复杂得多，因此会极度依赖数据库和 SQL。

SPL 具备足够的开放计算能力，可以基于文件直接计算，这样中间表就可以搬到库外存储，再借助 SPL 实施后续计算解决中间表的问题。

有了 SPL 的库外计算支持，原本数据库中间表带来的各种问题就能得到有效解决。文件存储不再占用数据库存储空间，数据库扩容压力降低，数据库更方便管理；库外计算不再占用数据库计算资源，数据库减负可以更好服务其他业务。库外使用文件存储和 SPL 计算成本更低。更进一步，使用 SPL 提供的高性能私有文件存储还可以大幅提升计算性能，降低硬件成本。

延伸阅读：开源 SPL 消灭数以万计的数据库中间表

数据路由实现冷热分层

有时为了及时满足前端应用的数据请求，会在贴近应用端搭建前置数据库，将常用数据移到前置库中，由前置库负责计算，这样不仅可以很好为应用服务，还能降低中央数据仓库的压力，可谓一举两得。

但使用传统数据库作为前置库时会遇到一些问题。因为前置库中存储的是少量较热数据，就无法满足应用查询全量数据的要求。如果把数据都从数据仓库搬出来放到前置库中，不仅工程量巨大，还涉及重复建设，成本高昂；但如果仅有部分数据，由于缺乏路由功能（无法识别数据位置）和跨库查询能力，就需要在应用端针对数据查询范围进行限制，十分繁琐。

SPL 不仅提供了跨源（库）的计算能力，还支持数据路由，可以用来充当前置数据库解决这些问题。

具体实现时，我们将数据分为三层。极高频使用的热数据通过 SPL 加载到内存中，用于高速访问和计算；高频使用的温数据采用 SPL 提供的高性能文件格式进行存储，使用时直接读取文件进行计算；而极少使用的大量冷数据仍然存储在中央数据仓库中。SPL 可以根据前端查询请求将数据处理任务分别路由到数据所在地进行计算（SPL 提供了相应 SQL 解析和转换功能），即热数据和温数据由 SPL 计算，冷数据由中央数据仓库计算，最后由 SPL 进行归并返回给应用端。这样大部分（高频数据）计算都由 SPL 来完成，只有少量查询会转发给中央数据仓库处理，不仅解决了原来面临的数据查询范围问题，还能有效降低中央数据仓库的压力，前端查询体验更佳。

延伸阅读： 实现数据冷热分离用什么技术合适？

解决 HTAP 需求

HTAP（混合事务和分析处理）希望通过一个数据库满足 AP 和 TP 两种需求，从根本上希望在满足 TP 的基础上还可以应对全量大数据查询，即 T+0 查询。不过，AP 和 TP 两个场景有显著不同，这注定 HTAP 需要采用不同的技术实现。

当前基于数据库体系实现 HTAP 有两种方式，一种采用多副本的方式，多份数据采用行列不同形式来应对 TP 和 AP 的不同需求。另一种底层仍然将两个场景分离，分别采用 TP 和 AP 领域成熟的技术进行封装，同时设计统一的对外访问接口。

无论采用何种实现方式，当前 HTAP 都会面临以下几个问题。

迁移风险大成本高。 如果原来的业务数据库不是（大概率）采用 HTAP 数据库就要涉及数据库迁移，这将面临巨大的风险和成本。

无法获得多样源的优势。 现代业务系统涉及的数据源种类很多，都要迁移到新数据库十分不易，而且没法利用多样数据源自身的优势，这与我们前面讨论的多样数据源问题一致。

性能不达标。 实现高性能只有列存是远远不够的，有些复杂计算需要针对计算特点专门设计数据存储形式（比如有序存储、数据类型转换、预计算等）。简单“自动化”地行存转列存性能往往无法达标。

其实，我们可以在原有独立 TP 和 AP 体系的基础上引入 SPL，借助其开放的跨源计算能力、高性能存储和计算能力、敏捷开发能力来实现 HTAP。

SPL 通过与现有系统融合的方式实现 HTAP，这样原有系统的改动很小，TP 部分几乎不动，甚至原有的 AP 数据源也可以继续工作，逐步使用 SPL 接管 AP 业务。SPL 部分或全部接管 AP 业务后，历史冷数据使用 SPL 高性能文件存储，原来针对业务库到数据仓库的 ETL 过程可以直接移植到 SPL 上。冷数据量大且不再变化使用 SPL 高性能文件存储可以获得更高地计算性能；热数据量小仍然存放在原有 TP 数据源中，SPL 直接读取计算，由于热数据量并不大，直接基于 TP 数据源查询也不会对其造成太大影响，访问时间也不会太长。再利用 SPL 的冷热数据混合计算能力，就可以获得针对全量数据的 T+0 实时查询。我们只要定期将变冷的数据固化到 SPL 的高性能存储中，原数据源只需要保持少量近期新产生的热数据即可。这样不仅实现了 HTAP，而且还是高性能的 HTAP，且对应用架构冲击很小。

延伸阅读： HTAP 数据库搞不定 HTAP 需求

循序渐进的湖仓一体

数据湖和数据仓库的联系很密切但着眼点不同，前者更注重原始数据的保留和存储，而后者更侧重于计算。因此将二者融合在一起实现“湖仓一体”是个很自然的想法。

目前通常的做法是在数据湖上开放数据访问权限供数据仓库访问，具体实现时需要在数据仓库中首先创建外部表 /schema 映射 RDB 的表或 schema，或者 hive 的 metastore，这个过程与传统的 DBLink 等数据库访问外部数据的实现方式并无太大差别，缺点十分明显。这还是由于数据库的封闭性造成的，数据只有经过整理、满足约束后才能入库计算，这个整理的过程就会导致大量原始信息丢失，数据湖的价值丧失。约束限制，体系封闭，不够灵活是当前数据湖技术面临的主要问题。

如果数据库具备足够的开放性，可以直接计算数据湖上未经整理的数据，甚至可以基于多种不同类型的数据源混合计算，同时提供高性能机制保证计算效率那湖仓一体就可以很好实现了。

借助 SPL 就可以实现这样的目标。

SPL 可以针对数据湖的原始数据直接计算，没有约束，无需入库。同时 SPL 还提供了多样性数据源混合计算的能力，无论数据湖使用统一文件系统构建，还是基于多样性数据源（RDB、NoSQL、LocalFile、Webservice）使用 SPL 都可以直接混合计算，快速输出数据湖价值。此外，还可以使用 SPL 提供的高性能文件存储（数仓的存储功能），在 SPL 实施计算的同时，整理数据可以从容不迫地进行，将原始数据整理到 SPL 存储中可以获得更高性能。使用 SPL 存储整理后数据仍然存放在文件系统中，理论上可以与数据湖存放一处，这样就实现了真正意义的湖仓一体。

在 SPL 的支持下数据整理与数据使用可以同时进行，循序渐进地建设数据湖，逐步整理，有序建设。还在建设数据湖的过程中就完善了数据仓库，让数据湖也拥有强计算能力，实现真正意义的湖仓一体。

延伸阅读： 现在的湖仓一体像是个伪命题

综合来看，开放计算体系的 SPL 可以带来更加灵活、高效、低应用成本的效果，相对封闭的 SQL（数据库）更有优势。