T+0 问题

T+0 查询是指实时数据查询，数据查询统计时将涉及到最新产生的数据。在数据量不大时，T+0 很容易完成，直接基于生产数据库查询就可以了。但是，当数据量积累到一定程度时，在生产库中进行大数据量的查询会消耗过多的数据库资源，严重时会影响交易业务，这就不能接受了，毕竟生产交易是更关键的任务。所以，我们常常会把大量用于查询分析的历史数据从生产库中分离出去，使用单独的数据库存储和查询，以保证查询统计不会影响生产业务，这就是常说的冷热数据分离。

数据分离后就会产生 T+0 问题。数据拆分到两个数据库中，要查询全量数据就涉及跨库查询。而且，我们知道，用于交易的生产库大多使用能够保证事务一致性的 RDB，而分离出来的冷数据（量大且不再修改）则会更多使用专门的分析型数据库或数据平台存储，即使是关系数据库也很可能与原来的生产库类型不同，这就不仅涉及跨库，还需要跨异构库（源）查询。遗憾的是，当前实现跨库查询的技术都存在这样那样的问题。

数据库自身的跨库查询功能（如 Oracle 的 DBLink、MySQL 的 FEDERATED、MSSQL 的 Linked Server 等）通常是将远程数据库的数据拉到本地，再在本地完成包括过滤在内的大部分计算，整个过程十分低效。不仅如此，这种方式还存在数据传输不稳定、不支持大对象操作、可扩展性低等很多不足。

除了数据库自身的跨库查询能力，使用高级语言硬编码也可以完成跨库查询，毕竟没有什么问题不是硬编码解决不了的。这种方式虽然灵活，但使用难度却很大，尤其对于当前大部分应用的开发语言Java来说，缺少足够的结构化数据计算类库使得完成跨库查询后的计算很难完成，通常只能做简单的列表式查询，而涉及到统计汇总类的运算就会异常麻烦。

事实上，要解决分库后的T+0查询问题也并非难事，只要有具备这样一些能力的计算引擎就可以实现：能够对接多种数据源；拥有不依赖数据库的完善计算能力以完成多库数据归集后的数据计算工作；还可以利用数据库（源）的能力充分发挥数据库的效能；提供简单的数据计算接口；性能相对理想等。

引入 SPL

可以借助开源SPL可以实现这些目标。SPL 是一款开源数据计算引擎，提供了大量结构化数据计算函数并拥有完备计算能力，支持多数据源混合计算，可以同时连接存储热数据的业务库和存储冷数据的历史库完成全量数据 T+0 查询。

由于具备独立且完善的计算能力，SPL 可以分别从不同的数据库取数计算，因此可以很好适应异构数据库的情况，还可以根据数据库的资源状况决定计算是在数据库还是 SPL 中实施，非常灵活。在计算实现上，SPL 的敏捷语法与过程计算可以大大简化 T+0 查询中的复杂计算，提升开发效率，SPL 解释执行支持热部署。更进一步，依托 SPL 的强计算能力还可以完成冷热数据分离时的 ETL 任务。

SPL 还提供了自有的高性能二进制文件存储，对性能要求较高时可以将历史冷数据使用文件存储，再借助 SPL 的高性能算法与并行计算来提升查询效率。此外，SPL 封装了标准应用接口（JDBC/ODBC/RESTful）供应用集成调用，也可以将 SPL 嵌入应用中使用，这样应用就轻松具备了 T+0 查询与复杂数据处理能力，将计算和存储分离也更符合当代应用架构的需要。

冷热混合计算

对于常见的冷热分库 T+0 查询场景，SPL 实现很简单，这里看一个例子。

本例中，Oracle 作为生产库存储当期热数据，MySQL 存储历史冷数据。前端传入一句标准 SQL（A2），再借助 SPL 的转换功能将标准 SQL 转换成对应数据库的语法（B3）并发给数据库查询（B4），最后归并结果进行最后的汇总运算（A5）。这里使用了多线程并行方式（A3）同时执行两个 SQL，效率更高。

在这里，SPL 不仅完成了两个数据库的跨库查询，还提供了 SQL 转换方法，更利于前端应用使用，同时拥有合并两个数据库计算结果后的继续计算能力，本例是分组汇总。SPL 还有更丰富的结构化数据对象及其上的丰富运算，除了分组汇总、循环分支、排序过滤、集合运算等基础计算外，位置计算、排序排名、不规则分组也不在话下。

除了 RDB，对于有些场景涉及的 NoSQL、Hadoop 等数据源也能支持，SPL 具备多源混算能力，无论基于何种数据源都可以进行混合查询实现 T+0。比如 MongoDB 与 MySQL 混合查询：

SPL 的计算能力还能用于 ETL，将生产数据转移到历史库中，还经常伴随一些转换计算，这些都可以使用 SPL 来完成。比如出于某些原因，要将生产数据某些编码字段通过某个对照表转换成另一种编码（遵守一致性的编码规则、整理数据类型获得更好性能等），而对照表通常并不会存在生产库中，而不能直接在生产库中计算好，这就涉及多数据源计算了。

高性能

历史冷数据量可能很大，使用 RDB 存储容易受到资源容量等因素限制，而且数据读取效率很差。相比之下，文件存储具备很多优势，不仅读取效率更高，还可以有效利用文件压缩、并行等机制提速，同时也不会像数据库容易受到容量的限制。不过，开放的文本格式使用效率不高（无压缩、解析数据类型慢等），一般会使用二进制格式文件。另外，文件存储的最大问题是没有计算能力，不像数据库使用 SQL 可以很方便完成数据处理，通过硬编码处理的难度很大。

这些问题都可以通过 SPL 来解决，SPL 提供了两种高性能二进制数据存储格式集文件和组表，再借助 SPL 的独立计算能力可以直接基于文件和数据库混合计算实现高效 T+0 查询。比如前面的例子，可以使用 SPL 文件存储历史冷数据与生产库热数据混合查询。

将历史数据存储在文件后与生产库混合查询，历史数据使用游标可以支持大数据场景，A4 针对文件游标进行分组汇总，A5 归并数据并汇总分组结果。这里使用了 SPL 提供的二进制集文件（btx），相对文本更加高效。集文件采用了压缩技术（占用空间更小读取更快），存储了数据类型（无需解析数据类型读取更快），支持可追加数据的倍增分段机制，利用分段策略很容易实现并行计算，保证计算性能。

SPL 还有另外一种支持列存的高效存储形式组表，在参与计算的列数（字段）较少时会有巨大优势。组表上还实现了 minmax 索引，也支持倍增分段，这样不仅能享受到列存的优势，也更容易并行提升计算性能。

SPL 还支持各种高性能算法。比如常见的 TopN 运算，在 SPL 中 TopN 被理解为聚合运算，这样可以将高复杂度的排序转换成低复杂度的聚合运算，而且很还能扩展应用范围。

这里的语句中没有排序字样，也不会产生大排序的动作，在全集还是分组中计算TopN 的语法基本一致，而且都会有较高的性能，类似的算法在 SPL 中还有很多。

SPL 也很容易实施并行计算，发挥多 CPU 的优势。SPL 有很多计算函数都提供并行机制，如文件读取、过滤、排序只要增加一个 @m 选项就可以自动实施并行计算，简单方便。

易集成

SPL 封装了标准 JDBC 和 ODBC 接口供应用调用，特别对于 Java 应用可以将 SPL 嵌入应用内使用，T+0 查询能力在应用端实现，不再依赖数据源，这样可以充分解耦应用与数据源，获得很好的移植性和可扩展性。

JDBC 调用 SPL 代码示例：

Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
Statement st = connection.();
CallableStatement st = conn.prepareCall("{call splscript(?, ?)}");
st.setObject(1, 3000);
st.setObject(2, 5000);
ResultSet result=st.execute();

SPL 是解释执行的，天然支持热切换。基于 SPL 的数据计算逻辑编写、修改后不需要重启，实时生效，使开发运维更加便捷。

相对其它 T+0 实现技术，SPL 借助自身独立的强计算与跨数据源计算能力可以更方便完成 T+0 查询，同时提供的高性能存储和高性能算法可以充分保障查询效率，良好的集成性使得应用端可以轻松具备这些能力，是名副其实的 T+0 查询利器。