1. 数据准备（跑批）几小时，时间不够用，后面全耽误，月末年终尤其紧张

SQL/ 存储过程太慢，数据要先导入，慢；计算时重复遍历表、反复中间结果落地，慢。跑批有时间窗口（通常是晚上几个小时），如果太慢在规定时间跑不完就会影响业务，在月末年终的时候尤其突出。

用 Java/Python 也跑不快，由于大数据能力差、难以并行、缺乏专门存储导致往往还不如 SQL 快。

用集算器 SPL 跑批，数据不需要入库直接就能算，节省入库时间；SPL 支持过程计算，同一份数据集只读取一次重复使用，中间结果无需落地就能给下一步使用，节省磁盘 IO 时间。

SPL 大数据计算能力强，支持小数据量的内存和大数据量的外存计算，提供支持列存、压缩、索引等优化后的高性能存储，同时支持并行计算，进一步提升计算性能。同等硬件跑批性能经常能提升 10 倍以上。

2. 查询报表呈现太慢，按下回车要去喝茶抽烟等，业务人员拍桌子

报表慢，90% 的原因是数据库计算慢，SQL 复杂一点数据库就很难优化，而 SQL 由于本身的限制也无法写出高性能算法，最后只能容忍低性能。

集算器 SPL 作为报表计算引擎（层），将原来只能压在数据库中的计算（尤其是性能低的部分）剥离出来在计算层使用 SPL 完成， 在高性能存储和算法的保障下，剥离出来的计算比 SQL 更快，从而优化报表查询效率。实际操作时可以逐步完成，先替换性能低的 SQL，再逐步把剩余 SQL 迁移到 SPL，实现完全替代 SQL 为报表准备数据。

3. 实时大屏仪表盘很久刷不出来，演示现场极度尴尬

大屏经常同时呈现多个指标，数据库计算时会把大数据刷 N 遍，重复读取和计算导致很慢。

集算器 SPL 过程计算很适合多指标计算，一次遍历就可以完成多个指标计算，避免重复读取数据。同时 SPL 还专门设计了不同的预汇总机制、布尔维序列、标签位维度等技术，可以进一步加速指标类计算，实现秒级大屏呈现。

4. 为了速度搞宽表，占了空间又耗时，数据变化还得重新来

宽表是常见的多维分析后台数据存储以避免关联运算的慢速。但宽表冗余很多，生成耗时，占用空间也大，当需求或数据变化时宽表还要重新准备，耗时耗力。

容忍宽表的缺点（冗余不灵活）主要是为了避免关联从而加速查询。集算器 SPL 的实时关联速度比宽表还快，而且还灵活，宽表也就没必要了。实测中，SPL 的实时关联速度要比 Clickhouse 的宽表快 2 倍以上。

5. 来不及实时算，只能调研需求先算好再查，探索式分析成空谈

性能跟不上，就只能预计算，先调研业务分析人员需求，再预先计算准备数据。但业务人员需要探索式的分析，下一步动作是由上一步结果决定的，预计算模式限死查询统计的范围，灵活分析成为空谈。

集算器 SPL 的实时计算能力很强，在高性能存储、算法以及其他诸多机制的保障下可以快速得到计算结果供业务人员进行下一步分析。特别地，SPL 十分擅长复杂关联计算，原来需要预先准备主要为了避免关联，而 SPL 的实时关联性能要比基于预计算结果更快。有了性能上的保障，就可以满足任意灵活度的探索分析需要。

6. 专业数仓 / 内存数据库太贵太重，集群大到机房都放不下，还老要扩容

当前 SQL 体系的数据（仓）库的硬件利用率很低，并没有把硬件跑满，数据量稍大或并发稍多就要靠集群来撑。应用成本高，运维也很复杂。

集算器 SPL 运算体系的硬件资源利用率很高，可以让单机发挥出集群的算力，绝大多数原本用小集群（<10）的数据库场景，SPL 用单机就可以搞定。即使一定需要集群，SPL 的集群规模也会远远小于 SQL 集群，成本更低，运维也更方便。

7. 新型数据库确实快了，但可应用面太窄，情况稍复杂点就指望不上

现在有很多新型专用数据库，在某个场景下的速度很快，但应用场景过于狭窄。比如 Clickhouse 号称最快的分析库，但实际发现仅针对单表计算有效，SQL 复杂时会很慢。有些数据库还不支持存储过程，很多复杂计算连实现都是问题，还需要外部编写 UDF，难度很高。如果上这些数据库只为解决单一某个场景的问题非常划不来。

集算器 SPL 速度快，且擅长复杂计算，应用范围更广。SPL 的过程计算天然可以实现存储过程类的多步骤计算，而且性能更高。

SPL 的可编程能力也很强，可以充分利用任务特征写出优化代码从而获得更高计算性能。相比这些新型数据库，SPL 无论在性能还是应用范围上都更有优势。

8. 历史大数据使用频率低，进数据库划不来，不进库又没法算

历史数据量大不再改变且使用低频，但仍然要用到。如果入库会占用昂贵的数据库空间，不入库又没法使用（计算），临时入库常常会发生入库三小时计算两分钟的尴尬局面。

集算器可以使用文件存储历史数据，并使用 SPL 直接计算文件（各种文件系统，甚至云上都行），无须入库直接算，完美解决入库与计算的矛盾。

9. TP 库太撑业务受限，想上 AP 库疑虑重重，选型难，迁移风险大

专业 AP 库通常是 MPP，软硬件成本很高。从 TP 库向 AP 库迁移面临两难，一次性迁移风险大不现实；逐步迁移，量小看不出选型是否正确，迁移多了发现不合适工作白做，而且还可能出现后迁移的部分影响前面的情况。

集算器 SPL 相对 AP 库更轻量，文件存储使用灵活，独立或嵌入使用简单轻量，同时硬件资源利用率高，总体成本更低。集算器采用文件存储，非常适合逐步迁移，不会出现迁移前后相互影响的情况，可以充分降低迁移风险。

SPL 具备天然跨源计算能力，不同库之间、文件与数据库都可以进行实时混合查询，能够满足 TP 和 AP 分库后的全量数据查询需求。

10. 库里成千上万中间表，早就没用还消耗资源，却没人敢动

计算复杂、查询性能低、数据源多样都会产生数据库中间表，中间表存在库内主要是为了利用数据库的再计算能力。但数据表一旦创建就有可能被多个应用共用，导致紧耦合，即使应用下线了，中间表仍然不敢删，还要消耗资源维护，数据库又累又繁。

用集算器，中间表可以移植到成本更低 I/O 性能更高的文件系统中，降低数据库冗余，为数据库减负。SPL 直接基于文件计算，性能更高。

中间表在库外采用文件系统的树状结构进行分类管理，跟随应用走，应用下线可以放心删除对应目录的中间表，不存在任何耦合不敢删的问题。

11. 中央数仓压力大指望不上，应用端加个单体数据库不够，搞集群又重复建设

中央数据仓库承担所有查询任务不太现实，但如果再为应用分别建设不同的分析库（集市）会面临矛盾，仅同步部分数据无法满足应用需要，同步全量数据又要集群才能撑起来，导致重复建设。

使用集算器充当前置数据库提供贴近应用的计算服务（提供 JDBC 和 RESTful 接口），集算器可以仅存储高频热数据，单机就能搞定，可以完全避免重复建设。再借助 SPL 提供的数据网关功能，将超出热数据范围的查询路由到中央数据仓库中实施，就能满足应用所有数据查询需求。

12. T+0 还真地很难搞，数据同步来不及，跨库运算又不会，HTAP 也不好使还风险大

数据分库会面临 T+0 查询问题，分时同步数据机制不仅复杂，也难以满足实时查询需求，不同库之间又很难进行跨库查询。HTAP 库大都在 AP 方面能力并不强，而且与原有 TP 库类型不同，把业务都迁移过去会面临较大风险。HTAP 库也无法继承 NoSQL 等多样数据源的优势，性能往往也不达标。

集算器天然支持多数据源混合计算，使用 SPL 可以在保留 TP 库的同时将冷数据外置实现 T+0 查询，这样不仅几乎没有迁移风险，原有库还可以继续利用，保留各种数据源的优势。

更进一步，将冷数据使用 SPL 高性能文件存储，还可以获得极致的计算性能。

13. 国产芯片有点慢，国产数据库也挺慢，慢上加慢怎么办

国产芯片慢，再加上国产数据库性能也不高，国产化后整体性能与原来有很大差距，需要花费更高的成本才能弥补。而且有些新型高性能数据库对国产芯片的兼容性还不好，总体应用效果并不理想。

集算器 SPL 在软件层面做了革新，性能在同等硬件下会比传统数据库技术快数倍，可以弥补硬件性能的下降，达到使用国产芯片性能也不会降低的效果。集算器使用纯 Java 编程，天然兼容所有国产芯片和操作系统。在实测中，SPL 在国产芯片上的计算性能，很多复杂计算还可以超越其他数据库在国外芯片上的运算性能。

14. 数据来源 Oracle+MySQL+Mongo+JSON+RESTful+……，想要混合算，数据库搞不定，Java 写太难

应用系统多，数据源种类多，多源混算是难题。用数据库只能先同库，效率低，数据实时性差；用 Java，编码太难。

集算器 SPL 作为开放的计算引擎，可以同时对接几十种数据源并进行混合计算，保障数据实时性的同时还能充分利用数据源的原有优势。特别地，SPL 混算代码十分简洁。

4 行代码实现 Restful 取来的 json 和本地数据库的混合计算。

15. 微服务架构好，但 Java 实现太烦、服务耦合高、没法热切换

中台 / 微服务等存算分离架构大都还是用 Java 做计算，架构改善了，但数据计算实现难度比 SQL 高很多，而且 Java 作为编译语言，不能热切换，总改总重启，为了服务之间解耦合还要动用容器，微服务搞得很重，一点都不“微”。

集算器 SPL 提供了丰富的结构化计算类库及数据类型，加上独特的函数选项、层次参数和增强 Lambda 语法，使得 SPL 实现计算的代码比 SQL 还要简单，更远胜于 Java。而作为解释型语言，SPL 支持热切换，天然解耦服务（无需容器），特别适应微服务针对的业务多变的目标场景，微服务真正变 “微”且适应“热”。

16. 复杂 SQL 难写难懂难调又不可缺省，有 SQL 方言还没法移植

成百上千行嵌套 N 层的 SQL 难写难调，写出来过半个月自己都看不懂，碰到数据库 SQL 方言，想移植也困难。ORM 技术也只能处理非常简单的情况。

集算器 SPL 代码更简洁，可以分步编码，还有编辑调试功能齐全的 IDE，复杂计算代码简短易懂。集算器 SPL 还支持标准的 SQL 语法，可以翻译成不同数据库的 SQL，SPL 代码天然不依赖于数据库，轻松实现数据库间的无缝移植。

17. 对存储过程又爱又恨，用了，难扩展耦合高，不用，复杂计算不好做

借助存储过程的分步机制可以完成相对复杂的计算，但存储过程移植性差、调试困难、安全隐患高，多个应用共用存储过程还会导致应用间高耦合，应用难扩展，更无法移植。

集算器 SPL 天然支持过程计算，在计算类库和敏捷语法的加持下，计算实现比存储过程更简单，可视化 IDE 编写调试脚本也更方便。计算逻辑在库外的 SPL 脚本内实现（库外存储过程），无需过多数据库权限，移植性超强。SPL 脚本借助文件系统的树状目录管理，不同应用对应不同目录，不会出现应用间的耦合性问题。