关于GPU数据库的未来

最新推荐文章于 2025-03-27 14:26:52 发布

Rateup

最新推荐文章于 2025-03-27 14:26:52 发布

阅读量1.1w

点赞数 8

分类专栏： GPU 数据仓库文章标签：数据库深度学习性能优化

本文链接：https://blog.youkuaiyun.com/weixin_51779762/article/details/121436396

版权

作者：李如豹博士，Rateup CTO

1. 介绍：什么是GPU数据库？

在过去十年里，GPU数据库已经成为数据库产品中的一个分支，并且解决了很多大规模数据密集型应用客户的关键问题。然而，虽然GPU数据库频繁出现在各种报道新闻中，但是业界对于GPU数据库的定义、GPU数据库的发展历史以及GPU数据库所能解决的本质应用需求仍然不了解。有鉴于此，本文尝试回答这些问题，并对GPU数据库的发展现状和将来预期进行讨论。

1.1 GPU数据库的定义

GPU数据库是个经常用的术语，但其本质指的是 “利用GPU设备处理某些数据处理功能的数据库管理系统” ，这些功能所涉及的范围可能很广，例如从某些特殊函数的处理到完整的查询引擎（或者其它数据库组件）。因为数据库管理系统的一个特性是允许用户添加自定义的函数来扩展数据库的功能，因此存在不同的场景关于GPU是如何被接入到数据库系统中的，这包括：场景（1）数据库管理系统本身不提供对GPU设备的任何管理和使用，但数据库管理系统提供扩展函数功能允许用户在其自定义函数内使用GPU设备的处理能力来完成某些操作；（2）数据库管理系统的某些内置功能被直接实现在GPU设备上，并且数据库管理系统直接管理底层的GPU设备，但是否其允许上层应用或者其它扩展函数使用或者访问GPU设备均可。

我们所定义的GPU数据库概念包含上述两种情况——只要数据库系统的某个功能使用了GPU设备，那么该数据库系统都可以称之为GPU数据库。最常见的GPU数据库形态（当前主流形态）是利用GPU设备来执行SQL查询，但对于不同产品而言，一个完整SQL查询所涉及的多个算子中，哪些被放置在GPU上执行并不确定；并且这种任务调度的方式完全可以在查询运行动态中完成。需要指出的是，理论上而言GPU并不仅限于执行查询处理，很多学术研究工作也指出在GPU上执行key/value查询和事务处理的可能性，因此当必要时，我们应该区分广义上的GPU数据库可能性和主流产品中的具体形态。根据目前工业界进展，我们所探讨的GPU数据库都是指的是利用GPU来加速查询处理的数据库系统。

1.2 GPU数据库的发展历史

从2003年到现在，GPU数据库这一产品形态或者数据库形态已经走过了18年！已知最早的学术研究工作是2003年的一篇SIGMOD论文： “Hardware Acceleration for Spatial Selections and Joins” 。该工作在通用GPU出现之前首次探讨了如何利用GPU硬件的rendering和searching能力来解决复杂计算几何算法的性能问题。该论文中所述技术方案出现在Nvidia CUDA生态系统之前，属于早期探索复杂数据库运算同底层硬件匹配的核心问题所在。在2010年之后，随着各种新应用的兴起，GPU数据库慢慢发展起来。对GPU数据库的学术研究开发了很多原型系统，例如GDB、GPUDB、Ocelot等，其目的是研究各种数据库并行算法，系统架构以及各种优化技术。工业界的GPU数据库包括了两类，一类是从PostgreSQL等传统开源CPU数据库上扩展而来的系统，例如日本的HeteroDB和英国的Brytlyt数据库；另一类是从头为GPU开发的全新数据库，例如美国的Kinetica和OmniSci，中国的RateupDB，以及以色列的SQream等。

1.3 GPU数据库所解决的工业需求

随着人类社会进入所谓的数据驱动时代，各种新应用需求层出不穷，其背后根本驱动原因是由于遍地普及的终端（例如手机）所带来的各种新经济模式，例如典型的移动计算带来的各种应用需求。这些需求往往超越了传统关系型数据库所提供和优化的数据处理能力，而需要新型数据库。我们总结有如下三种需求：

对实时业务价值的需求：这是最重要的业务需求，其目标是在各种及时更新的数据集上利用各种计算分析来获取瞬时的业务价值。一个典型的场景是实时车辆位置管理所带来的一系列业务应用，其典型代表是Uber内部使用的AresDB方案和USPS里面使用的Kinetica方案。对于一个运营几百万载客车辆的出行服务公司来说，实时的路线规划和偏航率分析不仅能够降低运营成本，改进客户体验，并且是实时恶意行为检测和犯罪提前预警的重要手段。

对极端计算能力的需求：当前存在对非结构化数据爆炸性的分析需求，而这些分析必须依赖于极端强大的计算能力，特别是这些数据的大规模增长和CPU有限算力之间的矛盾使得很多分析不能有效开展。典型的例子包括图数据分析、DNA序列分析，空间数据分析、3D结构分析等。尽管传统数据库在处理这些数据时存在性能问题，例如“Oracle Spatial and Graph”，各种行业的用户仍然首选一个数据库平台来执行这些分析，这是因为用户最需要数据库的简单接口以分离上层应用和底层系统。

对全面数据平台的需求：随着实时分析、智能分析、扩展分析的重要性日渐突出，传统企业内部多套数据库集成的方案越来越不能满足核心需求，特别是多套库之间所带来的业务延迟、协调管理以及维护开销等随着业务规模的增长越来越严重。例如，把大量数据从数据库提取出来送到一个智能分析平台里进行智能分析严重违背了用户对实时智能分析的需求。传统数据库系统通过加入各种扩展来尝试解决这些问题，例如Teradata Vantage，然而由于CPU的算力有限，很多复杂分析只能借助于其它非数据库内置的模块，例如TensorFlow。由于这些模块本身并不被数据库系统管理，因此存在各种数据格式转换以及资源调度冲突等问题。