开源分析数据库ClickHouse和开源esProc SPL的性能对比_clickhouse 计算 q1,q2, q3

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

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

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

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

这个测试的结果是下图这样：


![..](http://img.raqsoft.com.cn/docx/1657614855135100.png)
SPL使用列式游标机制之后，简单遍历分组计算的性能也和CH一样了。如果在TPC-H的Q1测试中也使用列式游标，SPL也会达到和CH同样的性能。


测试过程中发现，8亿条数据存成文本格式占用磁盘15G，在CH中占用5.4G，SPL占用8G。说明CH和SPL都采用了压缩存储，CH的压缩比更高些，也进一步证明CH的存储引擎做得确实不错。不过，SPL也可以达到和CH同样的性能，这说明SPL存储引擎和算法优化做得都比较好，高性能计算能力更加均衡。


当前版本的SPL是用Java写的，Java读数后生成用于计算的对象的速度很慢，而用C++开发的CH则没有这个问题。对于复杂的运算，读数时间占比不高，Java生成对象慢造成的拖累还不明显；而对于简单的遍历运算，读数时间占比很高，所以前面测试中SPL就会比CH更慢。列式游标优化了读数方案，不再生成一个个小对象，使对象生成次数大幅降低，这时候就能把差距拉回来了。单纯从存储本身看，SPL和CH相比并没有明显的优劣之分。


接下来再看常规TopN的对比测试，CH的SQL是：


SQL2：

SELECT * FROM test.t ORDER BY amount DESC LIMIT 100

对比测试结果是这样的：


![..](http://img.raqsoft.com.cn/docx/1657614854638100.png)
单看CH的SQL2，常规TopN的计算方法是全排序后取出前N条数据。数据量很大时，如果真地做全排序，性能会非常差。SQL2的测试结果说明，CH应该和SPL一样做了优化，没有全排序，所以两者性能都很快，SPL稍快一些。


也就是说，无论简单运算还是复杂运算，esProc SPL都能更胜一筹。


## 进一步的差距


差距还不止于此。


正如前面所说，CH和ORA使用SQL语言，都是基于关系模型的，所以都面临SQL优化的问题。TPC-H测试证明，ORA能优化的一些场景CH却优化不了，甚至跑不出结果。那么，如果面对一些ORA也不会优化的计算，CH就更不会优化了。比如说我们将SQL1的简单分组汇总，改为两种分组汇总结果再连接，CH的SQL写出来大致是这样：


SQL3：

SELECT *
FROM (
SELECT mod(id, 100) AS Aid, max(amount) AS Amax
FROM test.t
GROUP BY mod(id, 100)
) A
JOIN (
SELECT floor(id / 200000) AS Bid, min(amount) AS Bmin
FROM test.t
GROUP BY floor(id / 200000)
) B
ON A.Aid = B.Bid

这种情况下，对比测试的结果是CH的计算时间翻倍，SPL则不变：


![..](http://img.raqsoft.com.cn/docx/1657614854774100.png)
这是因为SPL不仅使用了列式游标，还使用了**遍历复用**机制，能在一次遍历过程中计算出多种分组结果，可以减少很多硬盘访问量。CH使用的SQL无法写出这样的运算，只能靠CH自身的优化能力了。而CH算法优化能力又很差，其优化引擎在这个测试中没有起作用，只能遍历两次，所以性能下降了一倍。


SPL实现遍历复用的代码很简单，大致是这样：




|  |  |  |
| --- | --- | --- |
|  | A  | B  |
| 1  | =file("topn.ctx").open().cursor@mv(id,amount)  |
| 2  | cursor A1  | =A2.groups(id%100:Aid;max(amount):Amax)  |
| 3  | cursor  | =A3.groups(id\200000:Bid;min(amount):Bmin)  |
| 4  | =A2.join@i(Aid,A3:Bid,Bid,Bmin)  |


再将SQL2常规TopN计算，调整为分组后求组内TopN。对应SQL是：


SQL4：

SELECT
gid,
groupArray(100)(amount) AS amount
FROM
(
SELECT
mod(id, 10) AS gid,
amount
FROM test.topn
ORDER BY
gid ASC,
amount DESC
) AS a
GROUP BY gid

这个分组TopN测试的对比结果是下面这样的：


![..](http://img.raqsoft.com.cn/docx/1657614854827100.png)
CH做分组TopN计算比常规TopN慢了42倍，说明CH在这种情况下很可能做了排序动作。也就是说，情况复杂化之后，CH的优化引擎又不起作用了。与SQL不同，SPL把TopN看成是一种聚合运算，和sum、count这类运算的计算逻辑是一样的，都只需要对原数据遍历一次。这样，分组求组内TopN就和分组求和、计数一样了，可以避免排序计算。因此，SPL计算分组TopN比CH快了22倍。


而且，SPL计算分组TopN的代码也不复杂：




|  |  |
| --- | --- |
|  | A  |
| 1  | =file("topn.ctx").open().cursor@mv(id,amount)  |
| 2  | =A1.groups(id%10:gid;top(10;-amount)).news(#2;gid,~.amount)  |


## 不只是跑得快


再来看看电商系统中常见的漏斗运算。SPL的代码依然很简洁：




|  |  |  |
| --- | --- | --- |
|  | A  | B  |
| 1  | =["etype1","etype2","etype3"]  | =file("event.ctx").open()  |
| 2  | =B1.cursor(id,etime,etype;etime>=date("2021-01-10") && etime<date("2021-01-25") && A1.contain(etype) && …)  |
| 3  | =A2.group(id).(~.sort(etime))  | =A3.new(~.select@1(etype==A1(1)):first,~:all).select(first)  |
| 4  | =B3.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime<t1+7).etime, null))))  |
| 5  | =A4.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3)  |


CH的SQL无法实现这样的计算，我们以ORA为例看看三步漏斗的SQL写法：

with e1 as (
select gid,1 as step1,min(etime) as t1
from T
where etime>= to_date(‘2021-01-10’, ‘yyyy-MM-dd’) and etime

ORA 的SQL写出来要三十多行，理解起来有相当的难度。而且这段代码和漏斗的步骤数量相关，每增加一步数就要再增加一段子查询。相比之下，SPL就简单得多，处理任意步骤数都是这段代码。


这种复杂的SQL，写出来都很费劲，性能优化更无从谈起。


而CH的SQL还远不如ORA，基本上写不出这么复杂的逻辑，只能在外部写C++代码实现。也就是说，这种情况下只能利用CH的存储引擎。虽然用C++在外部计算有可能获得很好的性能，但开发成本非常高。类似的例子还有很多，CH都无法直接实现。


总结一下：CH计算某些简单场景（比如单表遍历）确实很快，和SPL的性能差不多。但是，高性能计算不能只看简单情况快不快，还要权衡各种场景。对于复杂运算而言，SPL不仅性能远超CH，代码编写也简单很多。SPL能覆盖高性能数据计算的全场景，可以说是完胜CH。


## SPL资料


* [SPL下载]( )


**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）**
![img](https://img-blog.csdnimg.cn/img_convert/7947afe9399d13ac6ab1ae43c5c07a22.png)

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**

术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）**
[外链图片转存中...(img-SXXWygeD-1713401532730)]

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**