13个场景你要用集算器

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 的实时关联性能要比基于预计算结果更快。有了性能上的保障，就可以满足任意灵活度的探索分析需要。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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