SPL
- 一、前言
- 二、集算器应用场景
- 三、下载
- 四、集算器的基本使用
一、前言
一种面向结构化数据的程序计算语言
集算器又称：SPL（Structured Process Language）
敏捷计算是集算器的主要特征
二、集算器应用场景
- 数据准备（跑批）几小时，时间不够用，后面全耽误，月末年终尤其紧张
SQL/ 存储过程太慢，数据要先导入，慢；计算时重复遍历表、反复中间结果落地，慢。跑批有时间窗口（通常是晚上几个小时），如果太慢在规定时间跑不完就会影响业务，在月末年终的时候尤其突出。
用 Java/Python 也跑不快，由于大数据能力差、难以并行、缺乏专门存储导致往往还不如 SQL 快。
用集算器 SPL 跑批，数据不需要入库直接就能算，节省入库时间；SPL 支持过程计算，同一份数据集只读取一次重复使用，中间结果无需落地就能给下一步使用，节省磁盘 IO 时间。
SPL 大数据计算能力强，支持小数据量的内存和大数据量的外存计算，提供支持列存、压缩、索引等优化后的高性能存储，同时支持并行计算，进一步提升计算性能。同等硬件跑批性能经常能提升 10 倍以上。
- 查询报表呈现太慢，按下回车要去喝茶抽烟等，业务人员拍桌子
报表慢，90% 的原因是数据库计算慢，SQL 复杂一点数据库就很难优化，而 SQL 由于本身的限制也无法写出高性能算法，最后只能容忍低性能。
集算器 SPL 作为报表计算引擎（层），将原来只能压在数据库中的计算（尤其是性能低的部分）剥离出来在计算层使用 SPL 完成， 在高性能存储和算法的保障下，剥离出来的计算比 SQL 更快，从而优化报表查询效率。实际操作时可以逐步完成，先替换性能低的 SQL，再逐步把剩余 SQL 迁移到 SPL，实现完全替代 SQL 为报表准备数据。
- 实时大屏仪表盘很久刷不出来，演示现场极度尴尬
大屏经常同时呈现多个指标，数据库计算时会把大数据刷 N 遍，重复读取和计算导致很慢。
集算器 SPL 过程计算很适合多指标计算，一次遍历就可以完成多个指标计算，避免重复读取数据。同时 SPL 还专门设计了不同的预汇总机制、布尔维序列、标签位维度等技术，可以进一步加速指标类计算，实现秒级大屏呈现。
- 为了速度搞宽表，占了空间又耗时，数据变化还得重新来
宽表是常见的多维分析后台数据存储以避免关联运算的慢速。但宽表冗余很多，生成耗时，占用空间也大，当需求或数据变化时宽表还要重新准备，耗时耗力。
容忍宽表的缺点（冗余不灵活）主要是为了避免关联从而加速查询。集算器 SPL 的实时关联速度比宽表还快，而且还灵活，宽表也就没必要了。实测中，SPL 的实时关联速度要比 Clickhouse 的宽表快 2 倍以上。
- 来不及实时算，只能调研需求先算好再查，探索式分析成空谈
性能跟不上，就只能预计算，先调研业务分析人员需求，再预先计算准备数据。但业务人员需要探索式的分析，下一步动作是由上一步结果决定的，预计算模式限死查询统计的范围，灵活分析成为空谈。
集算器 SPL 的实时计算能力很强，在高性能存储、算法以及其他诸多机制的保障下可以快速得到计算结果供业务人员进行下一步分析。特别地，SPL 十分擅长复杂关联计算，原来需要预先准备主要为了避免关联，而 SPL 的实时关联性能要比基于预计算结果更快。有了性能上的保障，就可以满足任意灵活度的探索分析需要。
- 专业数仓 / 内存数据库太贵太重，集群大到机房都放不下，还老要扩容
当前 SQL 体系的数据（仓）库的硬件利用率很低，并没有把硬件跑满，数据量稍大或并发稍多就要靠集群来撑。应用成本高，运维也很复杂。
集算器 SPL 运算体系的硬件资源利用率很高，可以让单机发挥出集群的算力，绝大多数原本用小集群（ < 10 ）的数据库场景，SPL 用单机就可以搞定。即使一定需要集群，SPL 的集群规模也会远远小于 SQL 集群，成本更低，运维也更方便。
- 新型数据库确实快了，但可应用面太窄，情况稍复杂点就指望不上
现在有很多新型专用数据库，在某个场景下的速度很快，但应用场景过于狭窄。比如 Clickhouse 号称最快的分析库，但实际发现仅针对单表计算有效，SQL 复杂时会很慢。有些数据库还不支持存储过程，很多复杂计算连实现都是问题，还需要外部编写 UDF，难度很高。如果上这些数据库只为解决单一某个场景的问题非常划不来。
集算器 SPL 速度快，且擅长复杂计算，应用范围更广。SPL 的过程计算天然可以实现存储过程类的多步骤计算，而且性能更高。
SPL 的可编程能力也很强，可以充分利用任务特征写出优化代码从而获得更高计算性能。相比这些新型数据库，SPL 无论在性能还是应用范围上都更有优势。
- 历史大数据使用频率低，进数据库划不来，不进库又没法算
历史数据量大不再改变且使用低频，但仍然要用到。如果入库会占用昂贵的数据库空间，不入库又没法使用（计算），临时入库常常会发生入库三小时计算两分钟的尴尬局面。
集算器可以使用文件存储历史数据，并使用 SPL 直接计算文件（各种文件系统，甚至云上都行），无须入库直接算，完美解决入库与计算的矛盾。
- TP 库太撑业务受限，想上 AP 库疑虑重重，选型难，迁移风险大
专业 AP 库通常是 MPP，软硬件成本很高。从 TP 库向 AP 库迁移面临两难，一次性迁移风险大不现实；逐步迁移，量小看不出选型是否正确，迁移多了发现不合适工作白做，而且还可能出现后迁移的部分影响前面的情况。
集算器 SPL 相对 AP 库更轻量，文件存储使用灵活，独立或嵌入使用简单轻量，同时硬件资源利用率高，总体成本更低。集算器采用文件存储，非常适合逐步迁移，不会出现迁移前后相互影响的情况，可以充分降低迁移风险。
SPL 具备天然跨源计算能力，不同库之间、文件与数据库都可以进行实时混合查询，能够满足 TP 和 AP 分库后的全量数据查询需求。
- 10库里成千上万中间表，早就没用还消耗资源，却没人敢动
计算复杂、查询性能低、数据源多样都会产生数据库中间表，中间表存在库内主要是为了利用数据库的再计算能力。但数据表一旦创建就有可能被多个应用共用，导致紧耦合，即使应用下线了，中间表仍然不敢删，还要消耗资源维护，数据库又累又繁。
用集算器，中间表可以移植到成本更低 I/O 性能更高的文件系统中，降低数据库冗余，为数据库减负。SPL 直接基于文件计算，性能更高。
中间表在库外采用文件系统的树状结构进行分类管理，跟随应用走，应用下线可以放心删除对应目录的中间表，不存在任何耦合不敢删的问题。
- 中央数仓压力大指望不上，应用端加个单体数据库不够，搞集群又重复建设
中央数据仓库承担所有查询任务不太现实，但如果再为应用分别建设不同的分析库（集市）会面临矛盾，仅同步部分数据无法满足应用需要，同步全量数据又要集群才能撑起来，导致重复建设。
使用集算器充当前置数据库提供贴近应用的计算服务（提供 JDBC 和 RESTful 接口），集算器可以仅存储高频热数据，单机就能搞定，可以完全避免重复建设。再借助 SPL 提供的数据网关功能，将超出热数据范围的查询路由到中央数据仓库中实施，就能满足应用所有数据查询需求。
- T+0 还真地很难搞，数据同步来不及，跨库运算又不会，HTAP 也不好使还风险大
数据分库会面临 T+0 查询问题，分时同步数据机制不仅复杂，也难以满足实时查询需求，不同库之间又很难进行跨库查询。HTAP 库大都在 AP 方面能力并不强，而且与原有 TP 库类型不同，把业务都迁移过去会面临较大风险。HTAP 库也无法继承 NoSQL 等多样数据源的优势，性能往往也不达标。
集算器天然支持多数据源混合计算，使用 SPL 可以在保留 TP 库的同时将冷数据外置实现 T+0 查询，这样不仅几乎没有迁移风险，原有库还可以继续利用，保留各种数据源的优势。
更进一步，将冷数据使用 SPL 高性能文件存储，还可以获得极致的计算性能。
- 国产芯片有点慢，国产数据库也挺慢，慢上加慢怎么办
国产芯片慢，再加上国产数据库性能也不高，国产化后整体性能与原来有很大差距，需要花费更高的成本才能弥补。而且有些新型高性能数据库对国产芯片的兼容性还不好，总体应用效果并不理想。
集算器 SPL 在软件层面做了革新，性能在同等硬件下会比传统数据库技术快数倍，可以弥补硬件性能的下降，达到使用国产芯片性能也不会降低的效果。集算器使用纯 Java 编程，天然兼容所有国产芯片和操作系统。在实测中，SPL 在国产芯片上的计算性能，很多复杂计算还可以超越其他数据库在国外芯片上的运算性能。
三、下载
下载地址：https://www.raqsoft.com.cn/download/download-jsq
拿到安装包后执行安装程序，按提示逐步进行：
-
运行安装程序
-
按照提示，依次点击下一步，接受许可证协议
-
选择安装路径，点击安装
-
完成安装。
如果对Java的运行环境配置比较了解，而且本地已经安装了JDK1.8及以上版本，也可以选择不自动安装JDK的集算器安装包来安装，在安装中需要填写本机JDK所在目录。
四、集算器的基本使用
运行集算器主程序可以打开集算器，点击
按钮可以创建网格文件。
左侧的代码网格区是当前活动的代码网格。右边，上部分区域是格值显示区，下部分区域是相关信息区，其中的输出信息区可以显示系统输出的消息。格值显示区和相关信息区可以收起和展开。
在集算器中，如果一个单元格有值，那么在计算格或者执行格中，就可以直接使用单元格名称引用单元格值。有值的单元格可以是常数格、计算格，也可以是被执行格赋值的其它单元格。单元格名称由列号字母和行号整数组成。上面网格中A2中表达式中就调用了A1的值，又如：
后记
👉👉💕💕美好的一天，到此结束，下次继续努力！欲知后续，请看下回分解，写作不易，感谢大家的支持！！ 🌹🌹🌹