比 Spark 快 100 倍的 GPU 加速 SQL 引擎:BlazingSQL 开源了

阅读数:6036 2019 年 8 月 6 日

BlazingSQL 是基于英伟达 RAPIDS 生态系统构建的 GPU 加速 SQL 引擎,可以为各种 ETL 大数据集提供 SQL 接口,并且完全运行在 GPU 之上。近日,其研发团队宣布,BlazingSQL 基于 Apache 2.0 许可完全开源!

开源项目地址: https://github.com/blazingdb/pyBlazing/

关于 BlazingSQL

image

BlazingSQL 是一个基于英伟达 RAPIDS 生态系统构建的 GPU 加速 SQL 引擎。RAPIDS 包含一组软件库(BlazingSQL、cuDF、cuML、cuGraph),用来在 GPU 上执行端到端的数据科学计算和分析管道。RAPIDS 基于 Apache Arrow 列式存储格式,其中 cuDF 是一个 GPU DataFrame 库,用于加载、连接、聚合、过滤和操作数据。BlazingSQL 是面向 cuDF 的 SQL 接口,具备支持大规模数据科学工作流和企业数据集的各种功能。

官方称,BlazingSQL(几乎)可以处理任何你想要的数据。它的前身是 BlazingDB,但因为它并不是一个数据库,所以研发团队将 BlazingDB 改名为 BlazingSQL。

BlazingSQL 主要特性:

  • 查询外部存储数据 :仅需一行代码就可以注册远程存储解决方案,例如 Amazon S3。

  • 简单的 SQL:非常容易使用,运行 SQL 查询就能得到 GPU DataFrames(GDF)的查询结果。

  • 互操作性:任意一个 RAPIDS 库都可以访问查询到的 GDF,并用于任意的数据科学工作负载。

BlazingSQL 解决的痛点

  • 价格昂贵:进行大规模数据科学研究通常需要包含数千台服务器的集群,而 BlazingSQL + RAPIDS 运行相同规模的工作负载只需要其中一小部分基础设施。

  • 速度慢:在大型数据集上运行工作负载和查询可能需要数小时或数天,而 BlazingSQL + RAPIDS 借助 GPU 加速可以在几秒内得到结果,帮助数据科学家快速迭代新模型。

  • 复杂型:数据科学工作负载通常基于小数据集开发出原型,然后针对分布式系统进行重建。BlazingSQL + RAPIDS 让用户能够只编写一次代码,并且只需要一行代码就能动态地改变分布式集群规模。

在开发团队看来,迄今为止,SQL 是每一个主流分析生态系统的支柱之一,RAPIDS 是下一代分析生态系统,而 BlazingSQL 是 RAPIDS 的 SQL 标准。

BlazingSQL 完全基于 cuDF cuIO 构建,这些项目的新功能会直接影响 BlazingSQL 的功能和性能。同时,由于 BlazingSQL 运行在 GDF 上,它与 RAPIDS 的所有库都是 100%可互操作的。

如果你正在使用 RAPIDS,或者正在考虑使用 RAPIDS,BlazingSQL 将为你提供更多便利,包括但不限于:

  • 降低代码复杂性:SQL 语句非常简单,你可以用单个语句替换数十到数百个 cuDF 函数调用。

  • 连接到数据湖:你不再需要同步其他数据库,BlazingSQL 可以查询云端或网络文件系统中的任意原始文件。

  • 让 RAPIDS 变得更快:更先进的 SQL 优化器让 RAPIDS 技术栈更智能地运行。

BlazingSQL 性能表现

目前,BlazingSQL+RAPIDS 已经上线 Google Colab,研发团队在 GCP 上搭建了两个价格相当的集群,一个用于 Spark,另一个用于 BlazingSQL。他们在集群上运行端到端的数据分析工作负载:从数据湖到 ETL/ 特征工程,再到 XGBoost 训练,并对 Spark 和 BlazingSQL 的性能进行了对比测试。

研发人员在超过两千万行 Netflow 数据上运行两次相同的特定工作负载(具体实验参见 Colab 链接)。首先运行 BlazingSQL + RAPIDS,然后使用 PySpark(Spark 2.4.1)再次运行,得到如下结果:

如果把从 Google Drive 中加载 CSV 到各自 DataFrame 所需的时间考虑在内,BlazingSQL 比 Spark 快 71 倍。

image

如果只看 ETL 时间,则BlazingSQL 和 RAPIDS 的速度比 Spark 快 100 倍!

image

运行以下 Colab 演示,用户可以使用免费英伟达 T4 GPU 资源进行同样的测试,对 BlazingSQL 的实际效果进行验证。

https://colab.research.google.com/drive/1EbPE9FwFur7fE2054BH9s23Kd0FiUgGo

介绍,BlazingSQL 大部分性能提升来自团队的内部引擎项目,BlazingSQL 团队的工程师们希望开发一种专为 GPU DataFrames(GDF)构建的 GPU 执行内核,称之为“SIMD 表达式解释器”(SIMD Expression Interpreter)。研发团队分享了一些关于 SIMD 表达式解释器的细节,SIMD 表达式解释器通过几个关键步骤带来提升性能:

  1. 接收多个输入,包括 GDF 列、字面量,在不久的将来也会支持函数。

  2. 在加载这些输入时,SIMD 表达式解释器将对 GPU 寄存器的分配进行优化,这可以优化 GPU 线程占用率,并提高性能。

  3. 然后,虚拟机处理这些输入,并生成多个输出。假设有以下 SQL 查询:

    复制代码
    SELECT colA + colB * 10sin(colA) - cos(colD)FROM tableA

    在以前,BlazingSQL 会将这条查询语句转换为 5 个操作(+,*,sin,cos, - ),每个操作都需要单独执行。在使用 SIMD 表达式解释器后,它会同时接收(colA、colB、colD)作为输入,并在单次内核执行中执行所有 5 个操作,最终生成两个输出。这意味着 colA 只需要加载一次,而不是两次。

    目前,SIMD 表达式解释器支持 BlazingSQL 的过滤和投影,因此它对许多主流的 SQL 查询都有影响。

如何使用 BlazingSQL

使用 BlazingSQL 在 Amazon S3 中查询 CSV 文件的示例代码:

复制代码
from blazingsql import BlazingContext
bc = BlazingContext()
bc.s3('dir_name', bucket_name='bucket_name', access_key_id='access_key', secrect_key='secret_key')
# Create Table from CSV
bc.create_table('taxi', '/dir_name/taxi.csv')
# Query
result = bc.sql('SELECT count(*) FROM taxi GROUP BY year(key)').get()
result_gdf = result.columns
#Print GDF
print(result_gdf)

更多 BlazingSQL 的操作方法参见 GitHub 项目官方网站

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论

最新评论

2019 年 08 月 07 日 08:56 0 回复
看到GPU就呵呵了
价格相当的两个集群,BlazingSQL比Spark快100倍,所以GPU有啥问题呢? 0 回复
蔡芳芳 2019 年 08 月 06 日 19:20 0 回复
现在对于此类SQL引擎,是否有一个统一的Benchmark可用于对比测试呢?
fasdfka 2019 年 08 月 06 日 15:45 5 回复
首先结果没有问题,但是通过实验结果得到的结论有些问题。 第一,对于通常应用大数据系统的用例,测试数据集大小非常小(我从链接里看到nf-chunk2.csv的只有2.5GB,咋说也得用100GB的数据集来测试吧?),是否有必要把分布式mapreduce框架的所有复杂性和开销引入ETL数据集?将一个运行在单节点上的框架,使用较小的数据集,和一个多节点的框架直接对比是否公平? 第二,spark运行在jvm上,而这里选择的不是scala,更不是java,而是python的spark应用程序进行对比,要知道scala和python编写的spark应用程序之间的运行速度差距可不是只有2、3倍而已。 第三,spark本身具有很多参数,比如:excutor的内存,使用的核数,这里对比的报告中缺少配置细节。如何管理分区大小、操作顺序和选择以及优化参数可以使性能产生数量级差异。 最后,这样的框架运行在GPU上,我不知道对于PB级别的数据,机器的内存和GPU相比,运行在GPU上的成本到底有多高。
展开全部
没有更多了