【摘要】
我们经常说是要解决开发难和运算慢两个问题，其实从根本上只解决开发难就行了，原来之所以会有性能问题是因为算法很难优化，换句话说高性能算法很难写！因此，让高性能算法变得好写，既解决了开发效率问题，同时又解决了性能问题！但这需要从理论层面进行改变，现在恰好我们做了这样一件事。一起来看一下吧…
《37 个场景你要用集算器》

【慢】

1、清单式大报表难以及时呈现，采用数据库分页方式翻页效率很差

• 集算器将计算和呈现做成两个异步线程，取数线程发出 SQL 将数据缓存到本地，然后交给呈现线程快速展现报表
• 取数线程只涉及一个事务不会出现数据不一致，保证数据准确性

2、查询报表从数据库中取数量大，JDBC 传输性能低

• 集算器通过（多线程）并行计算与数据库建立多个连接并行取数提升取数性能
• 可将量大的冷数据事先存储在库外文件系统中，集算器基于文件直接查询计算，避免通过 JDBC 取数

3、T+0 实时全量查询涉及数据量大，影响生产系统运行，而分库后又难以实施跨库混合运算

• 将冷热数据分离，仅将当期热数据存放在数据库中，冷数据存储在文件系统或数据库中，通过集算器完成跨源（库）计算，完成多源数据汇总、复杂计算，实现 T+0 全量数据实时查询
• 集算器提供不同数据库的 SQL 翻译功能，数据分库（同构异构均可）后，仍然可以使用通用 SQL 进行跨库查询

4、SQL 复杂，嵌套层次多，数据库优化路径不可控，运算性能低

• 集算器采用过程计算，分步实施计算简化实现代码，无需嵌套
• 过程中可以复用中间结果，性能更高

5、存储过程步骤多，代码长，使用临时表落地中间数据，性能低下

• 相对存储过程需要反复读写磁盘使用中间结果，集算器提供丰富的运算方案，大量减少中间结果落地，性能更高
• 集算器采用过程计算，提供丰富函数类库，实现算法短小精悍易于维护
• 集算器脚本可以脱离数据库编写和运行，减少数据库安全隐患

6、数据关联运算太多，十几甚至几十个表 JOIN，性能恶劣

• 集算器重新定义关联运算，可以根据计算特征选用不同且高效的关联算法提升多表关联性能
• 一对多的主外键表可采用指针式连接提高性能
• 一对一的同维表和多对一的主子表可采用有序归并提升性能

7、巨大数据量中按条件查询或用批量键值取数，无法建索引或简单索引效果很差

• 集算器提供高性能压缩存储及遍历技术，再配合以并行手段，可以从巨量数据中快速获得查询结果
• 对于批量键值取数，集算器提供多级索引缓存，可以复用多次取数的索引信息，从而提高性能

8、SQL 难以实现的运算只能在外部应用程序或用 UDF 开发，高性能算法实现难度大

导致效率低下
* 集算器采用全新的离散数据集理论，基于该理论实现的 SPL 具备语法简洁、计算完备的特点，通过 SPL 更容易实现低复杂度、简单灵活的高效算法，从而获得更高性能

9、使用了内存数据库或内存计算技术仍然不能满足性能要求，占用内存过大，硬件成本太高

• 集算器采用非关系数据库理论，计算过程中有效减少数据复制，不仅占用内存更少，而且运算性能更好
• 通过指针引用机制可以进一步提升内存利用率和定位效率

10、中央数据仓库支撑了过多应用，并发过多导致性能不可控，前端用户体验差

• 集算器易于应用集成，可将数据仓库中的部分计算和数据移植到应用层借助集算器计算能力实施数据存储和计算，分担数据仓库压力

【繁】

11、生产库和分析库在一起，大数据运算可能影响生产系统运行；分库又难以做到实时全量查询

• 集算器可基于生产库和分析库进行混合计算，量小的实时热数据从生产库查，将对生产系统的影响降到最低，量大的历史冷数据从分析库查，两部分数据混合计算实现全量数据实时计算

12、很多业务应用中都要部署单独的前置数据库作为数据集市，成本高昂

• 集算器的强计算能力 + 数据缓存 + 数据网关 + 多源混算可以基于文件系统实现数据集市或前置数据库，成本低廉，甚至可以直接嵌入到应用程序中

13、前置数据库中只能存放部分频繁数据，难以与中央数据仓库混合运算，前端应用只能分别针对不同库查询分析

• 集算器提供了多源异构数据混合计算能力，可以基于前置数据库热数据和数据仓库冷数据进行混合计算
• 集算器提供标准应用访问接口，前端应用可以通过集算器实现全量数据统一查询

14、数据库中有大量非原始数据的中间表，冗余严重，而且年代久远非常难管理

• 集算器支持将数据库的中间表移植到 I/O 性能更高的文件系统，降低数据库冗余，集算器直接基于文件计算，性能更高，还方便实施并行计算，进一步提升效率
• 中间表在库外采用文件系统的树状结构进行分类管理，优于数据库的线性结构，管理方便

15、报表或 ETL 涉及多数据库和非数据库的整合，SQL 无法直接运算，需要事先汇总到单库，ETL 做成 ELT 和 LET，数据库臃肿且性能差

• 集算器作为完备计算引擎可以实现真正的 ETL，基于多源混合计算能力先将多源数据进行清洗（E）传输（T），将整理好数据加载（L）到目标数据库，避免汇总到单库带来的时间、空间和管理上的过多开销

16、查询报表涉及 Web 或 IOT 等实时数据，事先导入数据库不仅效率低又影响实时性

• 集算器提供了不依赖数据库的计算能力，可以直接基于 Web 或 IOT 数据实时计算，不仅编码简单，而且性能高实时性好，避免入库带来的昂贵成本

17、Java 和 SQL 编写的运算逻辑与界面模板分开存储，程序耦合性太强，还难以做到热切换

• 集算器可作为报表独立的计算层，数据准备算法和报表模板一起存储，共同管理，可与应用分开部署，降低应用的耦合度
• 解释执行的集算器脚本可实现热切换

18、BI 系统（多维分析）的后台，采用普通数据库性能跟不上，用专业的列存数据库又太沉重 / 造价太高

• 集算器是一个轻量级数据处理引擎，通过高效的存储机制和开放计算体系可以为 BI 系统提供远高于普通数据库的性能，同时成本远低于列存数据库，还可以直接嵌入到 BI 系统中，结构非常轻巧

19、数据中心对外提供数据访问服务时要解决权限、脱敏等问题，后台还涉及多个异构数据仓库及多样性数据源整合困难

• 集算器提供 JDBC 网关功能，可以在网关层实按成数据权限和脱敏工作
• 集算器具备多源混算能力，可以直接整合多个异构数据源，对外提供统一数据服务

【累】

20、报表没完没了，业务人员取数需求多，自助报表敏捷 BI 也不管用，技术部门应对吃力，找不到低成本高效率的应对手段

• 集算器帮助报表开发彻底工具化，不仅报表呈现层工具化，报表数据计算层也工具化，从而降低报表开发难度，报表实现更快更简单
• 对人员要求更低，适合一般程序员使用
• 报表业务不稳定导致报表没完没了不可能消灭，集算器提供了最低成本的应对方案

21、数据源 SQL 或存储过程过于复杂，嵌套或步骤多，SQL 缺乏调试机制，开发效率低下

• 集算器通过过程计算，分步编程简化算法开发难度，算法短小、分步同时降低了维护难度，极大改善上千行 SQL 编写调试和维护困难的情况

22、涉及有序及过程性复杂运算，要用库外的 Java 开发或编写 UDF 才能完成，人工成本高

• 集算器支持有序和过程性计算，其集合化、离散性、有序性等特性解决了 SQL 有序运算困难、JAVA 集合运算能力差的问题
• 集算器采用过程计算机制，提供了丰富的计算类库，复杂计算编码简单，对人员要求低

23、涉及 MySQL 等开源数据库，窗口函数等许多高级语法不支持，开发困难

• 集算器作为完备计算引擎，提供了丰富的结构化数据运算函数，改善 MySQL 等数据库缺乏复杂函数导致的编码困难

24、涉及 NoSQL、文本、Excel、json/xml 等库外数据，无法使用 SQL，只能硬编码，开发效率太低且难以维护

• 集算器提供直接针对文件使用 SQL 查询的功能
• 提供了对 JSON/XML 这类分层数据的支持
• 可以编写脚本读取 NoSQL、文本、Excel 数据，提供实施计算，实现复杂度与 SQL 相当或更低

25、某些数据仓库（或大数据平台）对存储过程支持不好，难以完成复杂运算

• 集算器作为完备结构化数据计算引擎，可以充当通用库外存储过程，具备不依赖于数据库的强计算能力和易移植特性

26、SQL（存储过程）语法涉及数据库方言，难以移植

• 集算器作为库外通用计算引擎，可以编写不依赖数据库的通用算法，数据库发生变化时无需更改核心算法，易于移植

27、ETL 工具不能直接解决复杂业务逻辑，还要大量编写脚本，而 ETL 工具的脚本功能常常弱于 SQL，开发困难

• 集算器通过计算完备的 SPL 语言，提供不低于 SQL 的数据处理能力，面向过程的算法实现方式非常适合复杂的 ETL 场景
• 实际应用中，集算器替代已有 SQL/ 存储过程 / 脚本可以大幅缩短实现代码，同时获得数倍到数十倍的性能提升

【Hadoop?】

28、采用了 Hadoop/Spark 集群仍然难以获得期望的性能

• 集算器提供了简单、灵活的算法机制，可以根据计算特征编写适合的高性能算法，结合集算器的高性能存储和分布式计算机制，可以获得远高于 Hadoop/Spark 的性能

29、Spark 内存耗用太大，硬件成本太高，很多运算超过内存范围还无法实施

• 集算器提供内存和外存两种计算方式，由于采用高效计算模型，内存计算时效率更高、内存利用率更低，从而降低成本
• 当内存容量不够或无需全内存计算时，集算器采用外存计算从而减轻对内存容量的依赖，硬件成本更低

30、Hadoop 集群规模不大，只有几个或十几个节点，管理的数据并不多，无法发挥其优势，但维护却很复杂

• 集算器作为轻量级大数据解决方案非常适合几个到几十个节点的集群规模，相对 hadoop 集算器资源利用率更高，节约资源，同样的计算指标需要硬件更少，同样的硬件计算效率更高

31、Hadoop/Spark 难以完成需要的计算，结果又在旁边部署传统数据库来实施计算，结构累赘且效率低

• 集算器可将 hadoop 作为数据源，实现 hadoop 难以完成的计算
• 同时支持实时查询，避免部署 RDB 带来的 ETL 时间成本高，数据实时性差，商用 RDB 价格成本高等问题

32、Hadoop/Spark 提供的计算接口不够用，复杂运算经营还要编写 UDF，开发效率低

• 集算器计算引擎具备复杂计算实现简单、效率高的特点，适合使用 hadoop 或 spark 却还经常需要编写 UDF 的场景，极大提升开发效率

【Python?】

33、Python 并非专门为结构化数据计算设计，开源包贡献者不同，风格不统一，复杂过程编写并不简单

• 集算器专为结构化数据计算设计，支持过程化计算，提供了丰富的结构化数据集算函数，提供即装即用的可视化编辑调试环境，非常适合进行桌面数据分析，随装随用，随用随走

34、涉及 Excel/json 等非库数据，Python 等开源技术虽然接口丰富，但版本混乱，难以驾驭

• 集算器具备完备的数据计算能力，作为商业软件，提供了丰富的接口处理 Excel/JSON 等非库数据，即装即用，避免了 Python 等开源技术版本混乱、使用困难

35、Python 缺乏自有大数据方案，几乎不能写并行程序，无法充分利用多 CPU 能力

• 集算器提供了多线程并行计算和分布式计算能力，通过简单的脚本即可实现并行计算，可充分利用多 CPU 核能力实施高性能计算

36、Python 代码难以和 Java 集成，算法需要嵌入到生产系统时常常还要重写

• 集算器可作为计算中间件无缝嵌入应用系统，桌面数据分析编写的脚本可直接移植到生产系统中，无需重写

37、Python 等桌面开发环境调试功能不够友好，开发与测试效率低

• 集算器提供了易于开发调试的 IDE，采用网格式编程方式，提供设置断点、单步执行、执行到光标等功能
• 提供可视化结果面板，每步运行结果均可实时显示，利于开发和排错

作者微信

欢迎勾搭交流