半夜跑批跑不完，出错了来不及再来
月末年头更是担惊受怕…
集算器 -九游会登陆
集算器是什么
- 一款专用的高性能计算数据库，简称：spl base
- spl（structured process language）是集算器内置的程序语言
- 高性能是集算器的主要特征
高性能计算数据库
集算器解决什么？
跑不完
查询慢
看个报表等10分钟，业务人员拍桌子…
人多了、时间跨度大了，就查不了了
反应钝
关联统计运算慢，界面拖拽迟钝；
预汇总方案占用空间太大且功能盲区多
代价高
花了很多钱上了内存数据库，
结果性能还是不理想…
无问单机与集群、无问国际大牌与国产新秀、无问mpp与hadoop，集算器平均有数倍到数十倍的性能提升！
为什么现有技术跑不快
计算性能的决定性因素
- 计算效率取决于硬件和软件两方面
- 软件性能就是算法效率
- 算法效率由算法设计和算法实现共同决定
- 好算法只想得出，实现不了也是徒劳
- 缺乏高性能机制的编程语言会限制好算法的实现
没有火药，无论如何也造不出枪炮
根本原因
结构化数据是重点
- 当前数据计算仍以业务系统产生的结构化数据为主
- 业界在提升结构化数据计算性能时主要依靠大内存、大集群
- 大内存、大集群的实质是纵向或横向提升硬件能力
- 而软件核心仍然使用sql为主的关系代数体系
- sql无法实现高性能算法
sql无法实现高性能结构化数据计算
重点问题
sql的问题
- sql难以实现高效算法的原因在于其理论体系（关系代数）
- 理论上的缺陷很难通过工程实现来弥补
【举例】1亿行数据取前10名在sql下会怎么做？
- sql理论上会将所有数据排序，然后取前10名，效率很低
- 大家都知道有不必大排序的办法实现这个运算，却无法用sql表达
- 只能用指望数据库引擎自动优化，但复杂情况时数据库并不会优化
这就是为什么说，好算法不光要想出来，还要能实现
关于java
相对sql，java可以实现高效算法，但java实施计算的复杂度过高，可行性较低
高性能的本质
高性能算法想得出，写不出（sql），能写出又太难（java）
高性能的本质是开发效率问题，要能想得到、方便写得出
集算器为什么跑得快
集算器高性能来自于创新计算体系
【类比】计算1 2 3 … 100=?
普通人这么算
1 2=3
3 3=6
6 4=10
10 5=15
15 6=21
…
高斯这么算
1 100=101
2 99=101
…
一共有50个101
50*101=5050
高斯很聪明，想到了高效的算法，但更关键的是：那时人们已经发明了乘法！
前面的题：1亿行数据取前10名在sql下会怎么做？
关系数据库的sql就象只有加法的算术体系，而集算器的spl则发明了乘法！
集算器还有更多乘法（高性能计算和存储库），人人都能成为高斯（快速实现高性能算法）
离散数据集模型
集算器的高性能来源于创新的代数体系
离散数据集模型
也就是集算器发明的"乘法"
- 集合化
- 离散性
- 深度集合化
- 有序性
解决难写的问题，从而实现高性能算法
敏捷语法更简单
计算目标：某支股票最长连续涨了多少交易日
select max(continuousdays)-1 from (select count(*) continuousdays from (select sum(changesign) over(order by tradedate) unrisedays from (select tradedate, case when closeprice>lag(closeprice) over(order by tradedate) then 0 else 1 end changesign from stock) ) group by unrisedays)
sql解法
sql在使用窗口函数的情况下嵌套三层完成；
读懂了吗？
| a | |
|---|---|
| 1 | =stock.sort(tradedate) |
| 2 | =0 |
| 3 | =a1.max(a2=if(closeprice>closeprice[-1],a2 1,0)) |
spl解法
其实这个计算很简单，按照自然思维：先按交易日排序（行1）,然后比较当天收盘价比前一天高就 1，否则就清零，最后求个最大值（行3）
高性能算法与存储方案
内存查找
- 二分法
- 序号定位
- 位置索引
- 哈希索引
- 多层序号定位
外存数据集
- 文本文件的分段
- 集文件及倍增分段
- 数据类型
- 组表与列存
- 有序与补文件
- 数据更新及复组表
外存查找
- 二分法
- 哈希索引
- 排序索引
- 行存和带值索引
- 索引预加载
- 批量查找
- 返回集合的查找
- 多索引归并
- 全文检索
遍历技术
- 延迟游标
- 遍历复用
- 并行遍历
- 数据库并行加载
- 多路游标
- 分组汇总
- 聚合理解
- 冗余分组键
有序遍历
- 有序分组汇总
- 有序分组子集
- 程序游标
- 前半序分组
- 后半序分组
- 序号分组与可控分段
- 索引排序
外键关联
- 外键地址化
- 临时地址化
- 外键序号化
- 内连接语法
- 索引复用
- 对位序列
- 大维表查找
- 单边分堆
归并与连接
- 有序归并
- 分段归并
- 关联定位
- 附表
多维分析
- 部分预汇总
- 时间段预汇总
- 冗余排序
- 对位序列
- 标签位维度
- 内存标签异动
集群
- 计算与数据分布
- 集群复组表
- 复写维表
- 分段维表
- 冗余式容错
- 备胎式容错
- 多作业负载均衡
这里许多算法都是集算器的发明！
高性能算法举例
聚合理解
| a | ||
|---|---|---|
| 1 | =file("data.ctx").create().cursor() | |
| 2 | =a1.groups(;top(10,amount)) | 金额在前10名的订单 |
| 3 | =a1.groups(area;top(10,amount)) | 每个地区金额在前10名的订单 |
高复杂度的排序转换为低复杂度的聚合
遍历复用
| a | ||
|---|---|---|
| 1 | =file("order.ctx").create().cursor() | 准备遍历 |
| 2 | =channel(a1).groups(product;count(1):n) | 配置复用计算 |
| 3 | =a1.groups(area;sum(amount):amount) | 遍历，并获得分组结果 |
| 4 | =a2.result() | 取出复用运算的结果 |
一次遍历可返回多个结果集
高性能存储
高性能数据存储
私有数据存储格式，集文件、组表
文件系统存储形式
支持以树状目录方式按业务分类存储数据
集文件
- 倍增分段方式支持任意数量并行
- 自有高效压缩编码（减少空间；cpu占用少；安全）
- 泛型存储，允许集合数据
组表
- 行列混合存储
- 有序存储提高压缩率和定位性能
- 高效智能索引
- 倍增分段方式支持任意数量并行
- 主子表合一减少存储与关联
- 排号键值实现高效定位关联
分布式计算
数据容错和计算容错
提供内外存两种数据容错机制，外存冗余式容错，内存备胎式容错
支持计算容错，节点故障时自动将该节点计算任务迁移掉其他节点继续完成
可控数据分布
用户可根据数据和计算任务的特点灵活定制数据分布及冗余方案，有效减少节点间数据传输量，以获得更高性能
无中心架构，避免单点失效
集群没有永久的中心主控节点，程序员用代码控制参与计算的节点
负载均衡能力
根据每个节点空闲程度（线程数量）决定是否分配任务，实现负担和资源的有效平衡
集算器性能表现
* intel3014 1.7g/12核/64g内存 - 飞腾ft1500/16核/32g内存 - 龙芯/8核/64g内存 - intel2670 2.6g/16核/128g内存 - 飞腾ft2000/64核/256g内存
应用构架与场景
应用架构
应用场景
集算器（spl base）典型应用场景
- 在线查询统计
- 交互分析取数
- 离线定时跑批
在线统计查询
【场景特征】多并发，业务可能复杂，秒级响应，大数据需集群支持
交互分析取数
【场景特征】无并发，实时性要求高，会根据上一步的计算结果决定下一步计算
离线定时跑批
【场景特征】无并发，不必实时，数据量巨大，对时间窗口要求高
高性能常见问题
集算器要自行存储数据吗?
必须！数据密集型计算的存储是性能保障，传统rdb和hadoop的低效存储无法实现高性能
集算器针对内存、外存、集群都设计有专用高效数据组织方案，适应于多种运算场景
集算器基于开源或数据库技术?
集算器基于全新的计算模型，无开源技术可以引用，从理论到代码全部自主创新
基于创新理论的集算器不能再使用sql实现高性能，sql无法描述大部分低复杂度算法
仅对于运算形式规整的多维分析可提供高性能sql接口，以适应各种前端bi工具
集算器的学习难度如何?
集算器专门用于性能优化，提供了专用的spl语法
学习spl不难，数小时即可掌握，数周就能熟练
难的是设计优化算法！
所以我们设计了下面的优化流程
性能优化流程
最初的1-2个场景，由润乾高级工程师介入配合用户实现
大多数程序员习惯了sql思维方式，不熟悉高性能算法，需要用一两个场景训练和理解
几十种性能优化套路经历过也就学会了，算法设计和实现并不是那么难
初步提出问题场景
优化专家了解计算与数据特征
讨论确定结构方案
测试验证并调优完成
编制报告
培训用户方人员
授人以鱼不如授人以渔！
