怎么看gpu,怎么看gpu显存

2022-06-24 09:28:22

怎么看gpu,怎么看gpu显存

本文是12月8日大数据杂谈群分享的内容。

关注“大数据杂谈”公众号,点击“加群学习”,更多大牛一手技术分享等着你。

讲师介绍

杨旸:上海雅捷信息技术股份有限公司 产品总监。美国宾州州立大学电子工程硕士, 曾就职于易鲸捷、Cisco Systems,East n Kodak等;

2000年开始从事分布式多媒体通信系统研发,历经电信运营商级的互联网电话、安全监控/电子病历/慢病管理大数据、OLTP-On-HBase的分布式数据库等项目。现负责基于NVidia GPU的高速查询加工引擎的售前、方案架构、技术市场等工作,兴趣在于多GPU集群在关联、聚合和模型计算的技术,以及在 、电信及商业的应用。

推荐阅读:

用图形处理器GPU做数据处理近几年发展很快。比较 的故事之一是MapD的创始人,2011年在MIT做中东研究时,需要分析几亿条Twitter数据。他用了几个常见数据库,响应时间要几小时,晚上跑,第二天早上一看,方法不对,还得重来,非常火大,就想到用并行计算能力很强的显卡来做,效果不错,然后就开了公司。

前几天和一个医疗器械公司的朋友聊,也是类似情况,业务部门手头有数据,想自己做点分析,不麻烦IT部门,看看有没有新发现,结果几个简单的汇总就得几十分钟。

所以,如果想自由地查,在一秒以内出结果的话,有没有很简单的办法,不需要一大堆的准备工作,比如事先确定用哪些字段查,频率,如何建索引、如何分区之类的?

这就是GPU数据查询和处理的典型应用:普通Hadoop配置的服务器,加上几块显卡,就能很方便、自由地处理上千个维度的组合查询、排序、分组、筛选、上卷、下钻、切片、模糊匹配等,毫秒或秒级拿到结果。

为什么GPU能达到这效果呢?GPU有两多: 同样大小的硅片上,核更多, 并发的线程数也多。

Telsa K40 GPU包括15个多处理器(Multi Processor),共2880个核, 每个多处理器MP可支持2048个线程。 大家可以想象一下, 一台装8张K40显卡的服务器,计算能力顶的上多少台同样CPU+内存配置的系统?

当然CPU每个核的能力更强,能处理复杂逻辑,比如Switch…Case等。而对于图像和数据处理来讲,更多的是单向计算和加工,逻辑分叉较少,GPU更加适合。

如果一个GPU处理一张表,1亿条记录, 2万个线程同时处理,每个线程只需处理5千条。

再加上NVidia线程切换、Pipeline、SIMT等技术非常全面,可以实现类似超线程,开发者可以起更多线程,获得更大吞吐量。

CUDA开发平台,提供了三种手段: 线程组、显存和同步(Barrier Synchronization),供开发者很方便地利用这些并行计算机制,用C开发,并将数据在Device(GPU)和Host(内存)之间交换。

用户可以把数据从内存调入显存里,编写自己的C函数“Kernel”,然后通过CUDA并发N个线程来执行Kernel,再将结果搬回内存即可。比如要把A和B两个数组相加得到C数组:

如果N=1000,相当于启动1000个线程,各自执行一个加操作,一次完成1千个元素叠加。

计算完成后,再将数据从共享显存移到内存。 需要同步的时候,比如等所有线程计算完再移数据到内存,可以在Kernel里调__syncthreads(),来等待所有线程完成计算,再移到内存。

大家会想, GPU的存储小啊。 对,不过,GPU的容量越来越大,也越来越便宜。 现在常用的K80显卡有24G显存,一旦不够,还可以多加显卡--一台服务器可以插2-8张卡。

据说目前也有256GB的GPU。我们估计,2年左右,游戏和Deep Learning会让显存大小成倍提升。

而且,不一定要把所有数据放在显存里。 可以把热数据放在显存,其他数据放内存和磁盘上。即使是计算必须的数据,也可以从内存里一块一块地搬。 比如小表和大表的JOIN, 小表放在显存里,大表分块在内存和显存之间交换。

I/O也是影响性能的重要问题,GPU的内存带宽比CPU大得多,K40内存I/O 384位,288GB/秒,问题不大。内存和磁盘间的数据交换可以异步进行,磁盘IO的频率也不高,因此对GPU吞吐量影响不大。

实际上,因为CPU比较空闲,还可以通过CPU--内存--磁盘并行很多处理。

同时,现阶段GPU主要应用不是在海量数据上,更不是数据库,而是高速、高性能的数据集市。 数据集市是个老概念:从业务系统或数仓里取出相关数据,关联、聚合存成几张表,专门服务于某个应用。 这样,不会影响到核心数据系统,更安全,而且可以优化这几张表,提升性能—比如通过加载到GPU集群。

我们在某省级银行做了个CRM项目, 其中用到GPU数据处理。

该行4个业务系统:存款、信贷等,5700多万客户,9000多万账户,3029个机构网点。

之前,数据工作是由专职人员进行,现在希望扩大到2万客户经理和管理人员。这就要求能实时查询,按多个维度自由统计汇总,自由查询符合多个条件的客户列表等等。同时,可实时查询的字段需要扩展到近1000个,并逐渐将延伸到5千。

所有表无索引,所有字段皆可自由组合查询。 可以按多个字段Group By,包括字符串,比如统计“存款余额高”+“贷款风险较低”的客户数。计算上,需要统计滚动平均(日均、日均比上日/上月、/上季/年初/同期)等等。

我们晚上从Hadoop和R中,将所需查询的字段和指标预处理,比如用R计算某个客户的贷款风险。 形成17张表,几百G。 大表可上千字段,典型的大宽表。

第二天早上Load到GPU集群里,300个并发响应时间为毫秒级。

资金转移定价(FTP)也是银行比较新的IT应用,大家知道,商业银行靠存款和贷款的收益差获利。直白地讲,FTP是银行内部资金价格“保底价“,具体金额每天不同。

比如,某客户存款到上海静安支行100万,利率3%,存款利息=3万。如果FTP是5%,这笔存款的“保底价”就是5万,光凭“进货价”低,该支行就赚了2万。

贷款另算: 如果该支行贷出100万,按8%的贷款利率,利息收入8万,而FTP保底价5万,光凭卖价好,该支行又赚了3万。

FTP能帮助回答一系列重要问题,比如:

1.不同维度各自创造了多少利润?比如存款/贷款、对公/对私、不同行业;

2.不同的产品(如活期存款和2年定期)的保底价FTP不一样,如果先设定一个小目标,比如1个亿,各种产品分别需要完成多少指标?

3.存款和贷款部门利率各自调整时,对银行产生潜在风险有多少?

FTP价格的基础价是从收益曲线计算来的。横轴是贷款长度,如一个月、1-9个月、1-2年、2年以上, 分别对应不同值(回购利率、SHIBOR、央票利率和国债利率等)。每天需要对每笔贷款,按照当天的收益率曲线和贷款长短,计算成本、利息收入、余额等指标。

某省级行,下属80多个支行,贷款明细包括1.8亿条记录。每天需要对应3张表,逐条查找所有周期的收益率,然后按照产品类型、时长等,逐条计算上述指标。

我们在银行的3台Hadoop服务器上,加5张K40,200秒完成,速度是内存数据库的20多倍。

有的朋友担心并发不够。 GPU确实不适合直接服务于银行所有用户,更适合服务于某个范围,比如客户经理。

每个GPU的MP多处理器在处理Query的时候,确实是独占。 不过,一般几十毫秒完成,相比网络IO等开销,并不是主要因素。 我们测试显示,在满负荷之前,并发数的影响不大。 以一个两字段的Group By在32个GPU的集群和DB2上测试为例,横轴是每秒请求数量:

随着请求增加, DB2越来越慢,而GPU没有明显变化。主要延迟是千兆网造成的聚合延迟。如果请求数量继续上升,解决方法也可以借鉴传统数据库,比如多加节点,保持足够的空闲,或者通过Query缓存、好的调度算法分散负载、等等。

回头来看,最初那两个例子也很有潜力: 买一张显卡,插在现成的电脑里,几百毫秒就能出结果。不建索引、不限定字段,就是一张大表和几张小表,自由地玩。大数据不就是要自由实验,才能发现未知规律吗?

我们曾用一张普通的Geforce GTX 780,插在现成的服务器里测试2500万行。

再举个最近的一个 机构日志分析的例子,

1300万条记录,2G左右数据。1台E5-2530@2.4GHz, G内存,1T SAS,1张K40显卡

SELECT col1 from t where colID=”abcd1234efgh”

查询时间68ms, 13条记录;

SELECT count(*) from t

查询时间51ms, 1条记录;

SELECT colID, count (*) from t group by colID;

查询时间420ms, 33条记录;

我们现在正在做数据加工,比如2-3个表的JOIN + Where条件筛选。

对等值JOIN而言,常用Hash JOIN。Hash通过GPU做非常快,小一点的Hash表放在显存里。 另外一张大表分块从内存调入显存,高速Hash, 逐行Probe。 如果Hash表太大,也可以按Oracle Hash JOIN的Bucket做法,部分放在显存,部分放在内存。

同时,JOIN键是字符串的情况也很常见,对字符串Hash由GPU并行算,非常快。

对非等值JOIN,可以考虑Sort Merge JOIN。 GPU做排序也很快。 的排序算法虽无定论,不过多段并行处理,也能加快不少。因此,通过在显存里做好排序,之后计算的时间复杂度就是线性的了。

现在我们支持常见的SQL,包括Select,Select Distinct, Update, Order By, Group By, JOIN,各种聚合函数,字符串模糊匹配等等常见查询。 大宽表也是特色,比如几千列。

下个阶段会开发一些常见函数,会根据客户的需求,比如日期和时间计算等,在 类应用里比较多,会先开发。

答疑环节

Q1:GPU,在具体应用过程中,是侧重从硬件方面来实现,还是从软件方面来实现?

答:通俗来讲,是一张或多张显卡加上一套软件。 多GPU集群一般由管理进程、协调进程、计算节点和聚合节点组成。 计算节点就是GPU, 其他进程既可以在GPU的机器上,也可以在单独机器上。

像数据库一样,用户通过SQL查询,软件解析后,发到各个GPU上进行计算,查询结果再以文本文件或JDBC/ODBC等形式,返回用户。

Q2:请问你们这套系统是自己基于CUDA开发实现的吗,将来有没有计划会开源?

答:是我们自己基于CUDA开发的,是个不错的框架。管理层还没考虑开源,目前是逐步完善GPU查询和处理所需的各种功能,以 、电信等行业需求为开发导向。

Q3:GPU计算如何与传统数据库结合,有通用的基础应用框架么?

答:和传统数据库的结合主要是以SQL+数据集市的形式。 传统数据库将希望加速的内容提取成大宽表和维度表,存成文本文件。我们Load到内存和GPU集群里,继续加工、计算,并提供给用户查询。产生的结果、报表、视图等可以通过JDBC、ODBC或文本文件返回;

实时查询类型的应用, 由数据库提供大宽表给GPU集群。

有考虑和其他SQL引擎做更深度的集成,不过Optimizer或执行计划的具体结合点还在研究中。

Q4:GPU计算应该很快,毕竟计算单元多,但是对于大多数分析应用可能都是偏数据密集型。既然目前测试这么快为啥没有多少成熟的产品出现?

答:GPU计算的基础框架近两年逐渐成熟,尤其是CUDA。这几年软硬件结合的发展非常快,比如在GPU硬件上提供足够强大的抽象,来充分发挥GPU的处理带宽,比如利用超多线程、显存和线程块的映射、多层次的线程块、以及多GPU之间的数据交换等等

比如刚才说的,起一堆线程,并行处理。现在可以做到不太考虑多处理器,起上万线程,让 CUDA去管理协调,尽可能大地发挥硬件吞吐量。 调度、Pipleline, SIMT做的都比较好了。

Q5:请问老师,你们现在的sql支持update吗?

答:支持。

Q6:老师你们考虑未来将gpu整合进 hadoop spark 里面吗?

答:正在考虑和HDFS的结合,还没有计划整合进spark。

Q7:实时查询场景,数据库的大宽表数据是不是都加载到显存中?

答:要看情况。如果大宽表的数据是为了该应用特别抽取的,所有字段都有可能查询,那就全部加载到显存。

银行的例子里,可以加载上千字段的大宽表,实际上,今后需求可能是三五千字段。

Q8:目前使用gpu做查询的瓶颈在哪,换句话说数据的读取会是瓶颈吗、

答:从响应时间来讲,只要是多节点分布式,老生常谈的网络IO算一个瓶颈。

不过,现在有能装8张卡的服务器,PCI-Express总线的传输速度很快。 如果八张K80,装24Gx8=192G, 能干不少事了,如果热数据在192G之内,无需走网络。

数据读取方面,GPU的带宽很大。 K80显卡, I/O是480GB/S,两张可以达到将近1TB/S。所以和内存数据库相比,I/O、计算等都没遇到过明显瓶颈。

实际使用中, 次从磁盘加载入内存,然后进入显存,速度还好。 如果遇到两张大表JOIN, 需要从内存里一块一块地读,做计算,会有影响,但也不明显。

Q9:大表(聚簇)里面包含很多小表,hbase这种设计理念老师有了解吗?

答:现在用GPU,还没接触HBase。

Q10:请问老师,现在主流显卡的显存都不太大(与线程数相对应),在开发基于 GPU 的工具时,一般以怎样的思路解决这个矛盾?

答:一方面,显存的成本在下降,听MapD讲,现在有256GB的芯片了,而且游戏、Deep Learning的大模型会让显存继续快速加大。

另一方面,CUDA在调度、SIMT等有不少机制,让开发者无需太关心线程具体在多处理器上的执行,而实现超线程。所以,问题是要尽量喂饱GPU,而不是大量等待数据Ready。

显存虽然不大,但是I/O快,在内存和显存之间交换数据的开销不大,而关键在于如何平衡GPU计算、显存里的共享块和Global memory的使用、内存和显存交换、CPU+内存的处理、总线传输、网络传输等等, 通过异步函数调用、stream等,让他们尽量并行,比较花心思,而且在排序、JOIN等算法上,也要找比较适合GPU的。

传输方面, NVidia的RDMA技术,可以大大加快跨节点GPU之间数据交换,大大减少CPU参与和网络开销,也能提高并行效率。

Q11:目前你们的应用框架支持集群吗?比如200台机器?在涉及到多表join时性能如何?比如6个表的join,大表在亿级,小表几万级

答:必须是集群。 我们有两层概念: 同一机箱2-8张卡,这是一个集群, 速度快。 跨机箱,也可以, 万兆网。

多表join这个需求本身来自于数据仓库。通过多次范式,把一张大表变成多张小表,减少冗余。问题是读取的时候,开销大,批量处理可以,但快不了。

如果join键是有索引的话,可以加快,但还是比一张大表慢,而且要自由查询,就不能把所有可能查询的字段都加索引。

所以如果是为了实时查询,用SQL-On-Hadoop JOIN成一张大宽表,放在磁盘上,我们加载到内存和显存里,客户查询起来很快。

如果是为了计算,追求的不是实时,而是相对更快,比如有Where…条件的情况,GPU处理起来也很好(Hash, Sort都有优势)。前面讲的FTP对应曲线算价格,就是这样的情况。

当然,必须用多表JOIN的时候,性能也不差,比如高速数据加工、高速数据集市、报表等,性能也不差。秒级响应,比实时查询慢了。

Q12:我想问下现在有没有留意过百亿甚至千亿的例子,现在查询效率如何?

答:架构上可以线性拓展,在同一个机箱里插更多卡,或增加服务器。 多张卡的处理结果在聚合节点汇总。 百亿的例子还没做过,现在大的集群40张K80卡。

我们倒是很希望做大集群。 现在集群的资源使用率并不高。 CPU和内存,Load完之后,比较闲。所以我们在现有集群上,帮客户想各种计算性应用,比如模型分析。或者同时装SQL-On-Hadoop等,做慢查询;

Q13:有没有比较过和Lucene的查询选择,我看老师讲的基本都是千万级别的,我看您有个柱状图来进行比较,有没有比较过Lucene和GPU在百亿甚至千亿级别的数据查询?因为如果用Lucene这种方式也可以实现千万数据的秒及查询

答:暂时没有机会做到文本搜索的百亿千亿,可能因为我们的客户 场景比较多。 但,我们很期望做字符串,文本比对,模糊匹配这种场景, GPU算起来非常快。

比较可行的是,在结构化数据上,做自由查询。 比如数据按字段分好了,有常住地、开卡地、户口所在地等, 对“大渡河路 27岁 白色凯越”这种带分隔符的单串字符, 可以用我们自己的分词技术,缩小每个词可能出现的字段,并在这些字段中高速扫描,得到所有类似结果,比如居住在大渡河路, 工作在大渡河路, 年纪26,27,28岁的,都可以查到。

同时,对文本比对,对字符串做Hash之类的速度都不错。

Q14:如果遇到两张大表JOIN, 需要从内存里一块一块地读,做计算 这样大表join的时候相对数据库走索引是否有优势,思路能否分享下

答:索引是个好办法,尤其是当查询的字段比较确定的时候。甚至自己也可以做个Hash table,临时索引一下。

但是,我们遇到一些场景,字段非常多,很难讲客户用哪些字段来组合查询。这就得把表看成一张扁平矩阵,在无索引的情况下,暴力扫。

而且,当Join的时候,如果JOIN键不是带索引的键,用传统数据库的JOIN算法也比较吃力。

Q15:我们怎么在现在有集群上快速搭建一个基于GPU环境

答:可以用从数据库里抽出一张大宽表,或者一个大事实表加几张维度表,存成文本文件,放在一个节点。再拿几台普通机器装GPU系统,我们会把数据Load进去, 做POC。查询结果的最简单办法是我们存成文本文件,放在某节点,并通知用户,由用户的请求线程去取。

也可以用JDBC/ODBC。

GPU占用的节点平时没准还可以 做以前做的事,比如晚上跑Map Reduce或SQL-On-Hadoop的慢查询或ETL工作。

Q16:因为现在我们是在2台IBM G内存的机器上做查询,200亿条数据大概1T是0.5秒查出来。是否用gpu能够加速的更快?

答:得看看查询内容,如果用带索引的字段查询,足够了的话,不需要考虑GPU了吧? 如果查询的字段比较多,那么不带索引的速度行不行?

往期部分精彩回顾

如何参与

长按识别左侧的

关注并点击菜单上的“加群学习”,参与活动

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

上一篇:生日蛋糕尺寸对照表,生日蛋糕标准尺寸表
下一篇:appstore显示无法连接是怎么回事(APPSTORE无法连接是什么原因)
相关文章