Sirius是一个GPU原生的SQL引擎,旨在为DuckDB提供即插即用的加速功能,未来也将支持其他数据系统。
Sirius作为DuckDB的一个扩展实现,无需对DuckDB的代码库进行任何修改,仅对用户接口进行了极小的调整。在执行层面,Sirius使用通用的Substrait格式来消费查询计划,确保了与其他数据系统的兼容性。为了最大限度地减少工程投入并提高可靠性,Sirius构建在成熟的某机构库之上:
Sirius在这些高性能库之上构建了其GPU原生执行引擎和缓冲区管理,同时复用了DuckDB的高级子系统,包括其查询解析器、优化器和扫描运算符。这种成熟生态系统的结合为Sirius提供了先发优势,使其能够以最少的工程投入打破ClickBench记录。
图1. Sirius 架构
当Sirius从DuckDB的内部格式接收到已优化的查询计划时,处理流程即开始。对于表扫描,Sirius调用DuckDB的扫描功能,该功能提供了如最小-最大过滤、区域跳过和即时解压等特性——这些操作高效地将相关数据加载到主机内存中。
接着,表扫描的结果从DuckDB的原生格式转换为Sirius数据格式(与Apache Arrow紧密对齐),然后传输到GPU内存。在像ClickBench这样的基准测试中,Sirius可以在GPU上缓存频繁访问的表,从而加速重复查询的执行。
Sirius格式可以直接映射到 cudf::table,实现零拷贝互操作性,使得所有剩余的SQL运算符(聚合、投影和连接)能够通过cuDF原语以GPU速度执行。计算完成后,结果被传回CPU,转换为DuckDB预期的输出格式,并返回给用户。
运行在某机构GH200 Grace Hopper超级芯片实例上的Sirius,与ClickBench上排名前五的系统进行了评估对比。对比系统运行在仅使用CPU的实例上。报告了热运行执行时间和相对运行时间,数值越低表示性能越好,1.0代表最佳可能得分。图3显示了所有基准查询的相对运行时间的几何平均值。在ClickBench运行中,Sirius在更便宜的硬件上实现了最低的相对运行时间,在此设置下成本效益提高了至少7.2倍。
图3. ClickBench 成本和相对运行时间
图4展示了Sirius与ClickBench中排名前二的系统(Umbra和DuckDB)的热运行查询性能。得益于通过cuDF实现的GPU高效计算,Sirius在大多数查询中实现了最低的相对运行时间。例如,在q4、q5和q18中,Sirius在过滤、投影和聚合等常用操作上显示出显著的性能提升。
然而,少数查询也揭示了进一步改进的机会。例如,q23的瓶颈在于字符串列上的“包含”操作,q24和q26受限于Top-N操作符,而q27则受限于对海量输入的聚合。Sirius的未来版本将包括对这些操作符的持续改进。
图4. ClickBench 单条查询的相对运行时间
图5深入研究了最复杂的ClickBench查询之一,即正则表达式查询(q28)。在GPU上以朴素方式实现正则表达式匹配可能会产生大规模的核函数,导致高寄存器压力和复杂的控制流,从而严重降低性能。
为了解决这个问题,Sirius利用cuDF的即时编译字符串转换框架来处理用户定义函数。图5比较了JIT方法与cuDF预编译API的性能,结果显示速度提升了13倍。JIT转换后的核函数达到了85%的线程束占用率,而预编译版本仅为32%,展示了更好的GPU利用率。通过将正则表达式分解为标准的字符串操作,cuDF JIT框架可以将这些操作融合到单个核函数中,从而改善数据局部性并降低寄存器压力。
图5. 使用JIT编译转换与预编译正则表达式的Sirius在Q28上的性能对比
展望未来,Sirius计划集成某机构正在开发的用于GPU数据处理的新基础性、可共享构建模块。优先领域包括:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。