集算器(SPL Server)

高性能数据仓库

(一)集算器是什么?

高性能数据仓库 (SPL Server)

  • 离线跑批
  • 在线查询
  • 多维分析
  • 内存计算

集算器解决什么?

跑不完

半夜跑批跑不完,出错了来不及再来
月末年头更是担惊受怕…

查询慢

看个报表等10分钟,业务人员拍桌子…
人多了、时间跨度大了,就查不了了

反应钝

关联统计运算慢,界面拖拽迟钝;
预汇总方案占用空间太大且功能盲区多

代价高

花了很多钱上了内存数据库,
结果性能还是不理想…

无问单机与集群、无问国际大牌与国产新秀、无问MPP与HADOOP,同等硬件条件下集算器平均提速10倍起!
了解集算器适用场景

离线跑批

【场景特征】无并发,不必实时,数据量巨大,对时间窗口要求高

点击查看详细内容

在线查询

【场景特征】多并发,业务可能复杂,秒级响应,大数据需集群支持

点击查看详细内容

多维分析

【场景特征】多并发,实时响应,计算相对规整,支持通用BI工具

点击查看详细内容

内存计算

【场景特征】对性能要求非常高,关联运算复杂

点击查看详细内容

(二)性能优化案例

案例1 保险行业历史保单关联业务跑批性能优化

面临现状

规则复杂

什么才算是同一辆车?车架号相同、车辆vin码相同、车牌号和种类形同。是否贷款车、商业险和交强险等等

数据量大

一个省的数据几亿条

跑批时间长

30天新增保单2个小时,90天新增保单长时间跑不出结果

优化效果

案例2海量账户大并发实时查询解决方案

面临现状

数据量大,超过3亿条

2015年09月到2018年09月

并发高访问人数多

几十万、上百万人访问

查询时间不能超过1秒

使用6台ES服务器基本达到响应要求

但无法再实现代码表关联

代码表改变时要花数小时重新生成数据

优化效果

案例3银行业多用户大数据量自助分析提速方案

面临现状

自助分析系统-性能要求高

几百个用户访问,期望秒级响应

期望查询全量数据

数据仓库-性能不可控

承担过多应用负载,只能为自助分析系统开放5个连接,性能受其他应用影响很大

优化效果

查询时间不超过5秒

比肩专业列存数据仓库

每台服务器支持50并发

实际支持几百用户访问无压力

数据量超过3千万条

按照条件过滤查找结果

自助分析工具全兼容

JDBC配置改为集算器即可

(三) 集算器强在哪里?

高性能计算理念

高性能来自于创新计算体系

【类比】计算1+2+3+…+100=?

思考题:1亿行数据取前10名在SQL下会怎么做?

SQL理论上就是大排序后取前10个,效率很低,程序员都知道有不必大排序的办法实现这个运算,却无法用SQL表达,只能用指望数据库引擎自动优化,但复杂情况时数据库并不会优化!

关系数据库的SQL就像只有加法的算术体系,而集算器的SPL则发明了乘法!

集算器还有更多乘法(高性能计算和存储库),人人都能成为高斯(快速实现高性能算法)。

集算器提供的部分高性能计算机制

这里许多算法都是集算器的独创发明!

高性能算法举例

集算器性能表现

测试结果(时间单位:秒)测试结果(时间单位:秒)

【注】SPL是润乾集算器采用的程序设计语言;SQL是关系数据库采用的程序设计语言

国产飞腾芯片上运行的润乾集算器可以超越Intel芯片上分布式数据库的性能

(四) 常见问题

集算器要自行存储数据吗?

必须!数据密集型计算的存储是性能保障,传统RDB和HADOOP的低效存储无法实现高性能

集算器针对内存、外存、集群都设计有专用高效数据组织方案,适应于多种运算场景

集算器基于开源或数据库技术?

集算器基于全新的计算模型,无开源技术可以引用,从理论到代码全部自主创新

基于创新理论的集算器不能再使用SQL实现高性能,SQL无法描述大部分低复杂度算法

仅对于运算形式规整的多维分析可提供高性能SQL接口,以适应各种前端BI工具

集算器的学习难度如何?

集算器专门用于性能优化,提供了专用的SPL语法

学习SPL不难,数小时即可掌握,数周就能熟练

难的是设计优化算法

所以我们设计了下面的优化流程

性能优化流程

最初的1-2个场景,由润乾高级工程师介入配合用户实现

大多数程序员习惯了SQL思维方式,不熟悉高性能算法,需要用一两个场景训练和理解

几十种性能优化套路经历过也就学会了,算法设计和实现并不是那么难

授人以鱼不如授人以渔!