大数据最新大数据计算，如何优化SQL _聚合函数 sum 耗时，大数据开发推送技术解析

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

假如SQL的分组TopN能这样写：

 select y,top(x,5) from T group by y

把top看成和sum一样的聚合函数，这不仅更易读，而且也很容易高速运算。

可惜，不行。

还是干瞪眼！

关联计算也是很常见的情况。以订单和多个表关联后做过滤计算为例，SQL大体是这个样子：

select o.oid,o.orderdate,o.amount 
from orders o 
    left join city ci on o.cityid = ci.cityid 
    left join shipper sh on o.shid=sh.shid 
    left join employee e on o.eid=e.eid 
    left join supplier su on o.suid=su.suid 
where ci.state='New York' 
    and e.title='manager' 
    and ... 

订单表有几千万数据，城市、运货商、雇员、供应商等表数据量都不大。过滤条件字段可能会来自于这些表，而且是前端传参数到后台的，会动态变化。

SQL一般采用HASH JOIN算法实现这些关联，要计算 HASH 值并做比较。每次只能解析一个JOIN，有N个JOIN要执行N遍动作，每次关联后都需要保持中间结果供下一轮使用，计算过程复杂，数据也会被遍历多次，计算性能不好。

通常，这些关联的代码表都很小，可以先读入内存。如果将订单表中的各个关联字段预先做序号化处理，比如将雇员编号字段值转换为对应雇员表记录的序号。那么计算时，就可以用雇员编号字段值（也就是雇员表序号），直接取内存中雇员表对应位置的记录，性能比HASH JOIN快很多，而且只需将订单表遍历一次即可，速度提升会非常明显！

也就是能把SQL写成下面的样子：

select o.oid,o.orderdate,o.amount 
from orders o 
    left join city c on o.cid = c.# --订单表的城市编号通过序号#关联城市表 
    left join shipper sh on o.shid=sh.# --订单表运货商号通过序号#关联运货商表 
    left join employee e on o.eid=e.# --订单表的雇员编号通过序号#关联雇员表 
    left join supplier su on o.suid=su.#--订单表供应商号通过序号#关联供应商表 
where ci.state='New York' 
    and e.title='manager' 
    and ... 

可惜的是，SQL 使用了无序集合概念，即使这些编号已经序号化了，数据库也无法利用这个特点，不能在对应的关联表这些无序集合上使用序号快速定位的机制，只能使用索引查找，而且数据库并不知道编号被序号化了，仍然会去计算 HASH 值和比对，性能还是很差！

有好办法也实施不了，只能再次干瞪眼！

还有高并发帐户查询，这个运算倒是很简单：

select id,amt,tdate,… from T 
where id='10100' 
    and tdate>= to\_date('2021-01-10','yyyy-MM-dd') 
    and tdate<to_date('2021-01-25','yyyy-mm-dd') 
    and="" …="" <p="">

在T表的几亿条历史数据中，快速找到某个帐户的几条到几千条明细，SQL写出来并不复杂，难点是大并发时响应速度要达到秒级甚至更快。为了提高查询响应速度，一般都会对 T 表的 id 字段建索引：

create index index_T_1 on T(id)

在数据库中，用索引查找单个帐户的速度很快，但并发很多时就会明显变慢。原因还是上面提到的SQL无序理论基础，总数据量很大，无法全读入内存，而数据库不能保证同一帐户的数据在物理上是连续存放的。硬盘有最小读取单位，在读不连续数据时，会取出很多无关内容，查询就会变慢。高并发访问的每个查询都慢一点，总体性能就会很差了。在非常重视体验的当下，谁敢让用户等待十秒以上？！

容易想到的办法是，把几亿数据预先按照帐户排序，保证同一帐户的数据连续存储，查询时从硬盘上读出的数据块几乎都是目标值，性能就会得到大幅提升。

但是，采用SQL体系的关系数据库并没有这个意识，不会强制保证数据存储的物理次序！这个问题不是SQL语法造成的，但也和SQL的理论基础相关，在关系数据库中还是没法实现这些算法。

那咋办？只能干瞪眼吗？

不能再用SQL和关系数据库了，要使用别的计算引擎。

开源的集算器SPL基于创新的理论基础，支持更多的数据类型和运算，能够描述上述场景中的新算法。用简单便捷的SPL写代码，在短时间内能大幅提高计算性能！

上面这些问题用SPL写出来的代码样例如下：

• 一次遍历计算多种分组

	A	B
1	=file(“T.ctx”).open().cursor(a,b,c,d,x,y,z
2	cursor A1	=A2.select(…).groups(a,b;sum(x))
3		//定义遍历中的第一种过滤、分组
4	cursor	=A4.select(…).groups(c,d;max(y))
5		//定义遍历中的第二种过滤、分组
6	cursor	=A6.select(…).groupx(a,c;avg(y),min(z))
7		//定义遍历中的第三种过滤、分组
8	…	//定义结束，开始计算三种方式的过滤、分组

• 用聚合的方式计算Top5

全集Top5（多线程并行计算）

	A
1	=file(“T.ctx”).open()
2	=A1.cursor@m(x).total(top(-5,x),top(5,x))
3	//top(-5,x) 计算出 x 最大的前 5 名，top(5,x) 是 x 最小的前 5 名。

分组Top5（多线程并行计算）

	A
1	=file(“T.ctx”).open()
2	=A1.cursor@m(x,y).groups(y;top(-5,x),top(5,x))

• 用序号做关联的SPL代码：

系统初始化

	A
1	>env(city,file(“city.btx”).import@b()),env(employee,file(“employee.btx”).import@b()),…
2	//系统初始化时，几个小表读入内存

查询

	A
1	=file(“orders.ctx”).open().cursor(cid,eid,…).switch(cid,city:#;eid,employee:#;…)
2	=A1.select(cid.state==“New York” && eid.title==“manager”…)
3	//先序号关联，再引用关联表字段写过滤条件

• 高并发帐户查询的SPL代码：

数据预处理，有序存储

	A	B
1	=file(“T-original.ctx”).open().cursor(id,tdate,amt,…)
2	=A1.sortx(id)	=file(“T.ctx”)
3	=B2.create@r(#id,tdate,amt,…).append@i(A2)
4	=B2.open().index(index_id;id)
5	//将原数据排序后，另存为新表，并为帐号建立索引

帐户查询

	A
1	=T.icursor(;id==10100 && tdate>=date(“2021-01-10”) && tdate<date(“2021-01-25”) && …,index_id).fetch()
2	//查询代码非常简单

除了这些简单例子，SPL还能实现更多高性能算法，比如有序归并实现订单和明细之间的关联、预关联技术实现多维分析中的多层维表关联、位存储技术实现上千个标签统计、布尔集合技术实现多个枚举值过滤条件的查询提速、时序分组技术实现复杂的漏斗分析等等。

正在为SQL性能优化头疼的小伙伴们，可以和我们一起探讨：

http://www.raqsoft.com.cn/wx/Query-run-batch-ad.html

SPL资料

• SPL官网

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

(img-SG2v1TR3-1715058290888)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取