Linux 之父出席、干货分享、圆桌讨论,精彩尽在 OpenCloudOS 社区开放日,报名戳 了解详情
写点什么

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

  • 2019 年 8 月 06 日
  • 本文字数:2196 字

    阅读完需:约 7 分钟

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

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


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


关于 BlazingSQL


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 完全基于cuDFcuIO构建,这些项目的新功能会直接影响 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 倍。


越小越好


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


越小越好


运行以下 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 查询:

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

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


如何使用 BlazingSQL

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


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


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


2019 年 8 月 06 日 14:2312198
用户头像
蔡芳芳 InfoQ高级编辑

发布了 695 篇内容, 共 363.9 次阅读, 收获喜欢 2413 次。

关注

评论 6 条评论

发布
用户头像
100TB对比过吗?
2019 年 12 月 16 日 09:47
回复
用户头像
看到GPU就呵呵了
2019 年 08 月 07 日 08:56
回复
价格相当的两个集群,BlazingSQL比Spark快100倍,所以GPU有啥问题呢?
2019 年 08 月 07 日 10:01
回复
用户头像
现在对于此类SQL引擎,是否有一个统一的Benchmark可用于对比测试呢?
2019 年 08 月 06 日 19:20
回复
tpc bb?
2019 年 12 月 16 日 09:48
回复
用户头像
首先结果没有问题,但是通过实验结果得到的结论有些问题。

第一,对于通常应用大数据系统的用例,测试数据集大小非常小(我从链接里看到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上的成本到底有多高。
展开
2019 年 08 月 06 日 15:45
回复
没有更多了
发现更多内容

如何认识更多的朋友扩展社交朋友圈的质量

吃素的左撇子

人生 人脉

Linux 容器化技术的前世今生(虚拟化、容器化、Docker)

Meandni

Docker 云计算 Linux 容器 虚拟机

【大咖说问大咖】关于开源的那些事 —— PingCAP CTO 黄东旭 Q&A 交流帖

InfoQ写作社区官方

开源 写作平台 大咖说 技术交流 热门活动

提升编程效率:重构

Page

高效工作 敏捷开发 重构 高效

Web3 极客日报#138

谢锐 | Frozen

区块链 独立开发者 技术社区 Rebase Web3 Daily

Java并发之AQS源码分析

指尖流逝

Java

Java 中的 Mysql 时区问题

张晓辉

一杯茶的时间,上手 Node.js

图雀社区

node.js

练习英语口语的误区

董一凡

学习

基于环信sdk在uni-app中快速开发多平台社交Demo

DT极客

严选合伙人(一)

Neco.W

创业 合伙人 初创公司

如何优雅的实现分布式锁

飘渺Jam

redis zookeeper 分布式锁

Kafka零数据丢失的配置方案

奈学教育

kafka kafka配置 kafka数据

《后浪》程序员版,献给新一代程序员的演讲,何冰《后浪》模仿秀

陆陆通通

Java 编程 程序员 后浪 何冰

现在的我和未来的我之间的差距原来是态度,而它拉开我们彼此命运的距离。

叶小鍵

Android | Tangram动态页面之路(一)需求背景

哈利迪

android

记一次线上事故

编号94530

Java MySQL 故障分析 事故

个人技术成长与发展

颇风

后端 技术人

为什么我喜欢的大V拉黑我?

lmymirror

经历 后真相时代 日常思考

从ClickHouse的名字由来讲起

nauu

数据库 大数据 分布式 OLAP Clickhouse

敏捷团队成员的工作量指标真的那么重要吗?

金生水起

敏捷开发 Scrum精髓 敏捷精髓 Agile

Web3极客日报 #139

谢锐 | Frozen

区块链 独立开发者 技术社区 Rebase Web3 Daily

游戏夜读 | 预测问题的硬核是?

game1night

ClickHouse为何如此之快?

nauu

数据库 大数据 OLAP Clickhouse

搜商:高效的使用搜索引擎

石云升

高效搜索 搜索技巧 搜商

Serverless: 2020年函数计算的冷启动怎么样了

刘宇

数据与广告系列一:初识在线计算广告

黄崇远@数据虫巢

互联网 数据 广告

JVM源码分析之深入分析Object类finalize()方法的实现原理

猿灯塔

JVM

MySQL索引知识介绍

Simon

MySQL 索引结构

低代码 .VS. 无代码

Jeff Kit

低代码 零代码

看完这篇操作系统,和面试官扯皮就没问题了

cxuan

操作系统 计算机基础

GPU容器虚拟化:用户态和内核态的技术和实践详解

GPU容器虚拟化:用户态和内核态的技术和实践详解

比Spark快100倍的GPU加速SQL引擎:BlazingSQL开源了_大数据_蔡芳芳_InfoQ精选文章