生活网讯:

  

选自The Next Platform

  

机器之心编译

  

参与:微胖、黄小天、吴攀

  

对于工作,有一个合适的工具当然好;但是把一个工具应用于多个工作且效用更佳,这更好。这就是为什么通用的基于 X86 的计算接管数据中心的原因之一。通过受限范围或者只是把原来有的应用程序单独放在替换平台上,规模经济获得了出乎意料的效率。

  

十多年前,把计算任务从 CPU 卸载到 GPU 加速器的想法从学术界脱颖而出,并且相对更快的高性能计算社区和 GPU 制造商英伟达扩展了现有的 Fortran 和通常用于 CPU 并行超级计算机的 C++ 框架,这样可以大大拓展计算容量,所得到的系统也会有更好效果。不久之后,有可能使用相同的机械来进行模拟和模型所需的计算,也可以进行渲染来可视化这些模拟和模型的结果。正如我们所知,超级计算机进化的下一步是在机器学习中编排(weave)以分析模拟和模型的结果,并据此做预测。因此一个应用程序将有三个不同、相互交织的层,且全部运行在相同的加速单元上。

  

数据库和分析领域也进行着一场类似的革命,它由 GPU 驱动,某些情况下也会用到 FPGA 加速器。在 GPU 采用传统的高性能计算方法的几年之后,谷歌、Facebook、百度等巨头公司的主导研究者发现了一个运行神经网络软件的方法,该方法在上世纪 80 年代已被提出,用于解决 GPU 加速系统中大量并行样式的图像识别问题,;该方法最终创造出了可在图像分任务中优于人类的软件。在过去的五年中,机器学习框架中的最先进技术获得了极速发展,图像识别技术也被用于文本、语音、视频识别及翻译服务,而翻译不仅仅限于语言之间,还包括从语音到文本的转换,或者图像、视频到文本的转换,且这些转换的精确度相当惊人。

  

结果就是,在 HPC 驱动以及机器学习的爆发之下,英伟达 2008 年成立的 Tesla GPU 早期计算业务如今规模扩大了 4 倍,并在今年 2 月英伟达 2017 财年第 4 季度的最后达到了 12 亿美元的年销售额(annual run rate)。英伟达的业务是如此之好以至于其竞争对手 AMD 最终一起推出了 Radeon Instinct GPU 计算平台和 ROCm 软件平台,它们不仅支持 OpenCL 卸载到 Radeon GPU,还具备在 AMD 自身的 Radeon motor 上为其 GPU 仿真英伟达 CUDA 并行编程环境的能力。

  

业界 英伟达GTC大会谈GPU未来:实现机器学习和数据库的融合

而现在,另一个应用正在成为 GPU 上的加速工作负载,它是关系型数据库(relational database),且处在大多数业务系统的核心,具有像 HPC 模拟、建模与机器学习这样的规模问题,这种问题可通过 GPU 的并行特性及其非常高的内存带宽而解决。我们已经记录了 GPU 加速数据库两大主要供应商——Kinetica(以前被称为 GPUdb)和其新兴挑战者 MapD——的兴起,但这一领域还有其他供应商,比如 Sqream、BlazingDB、Blazegraph 和 PG-Strom。并不清楚数据库加速是否会一直像传统 HPC 模拟、建模或者机器学习那样驱动同样的 GPU 单元。后两者几乎带动了英伟达 Tesla GPU 计算收入的一半。但这也有机会成为该业务的另一个重要部分,尤其是在这样的系统上:既可以使用标准 SQL 查询方法咀嚼大型数据集,也可以在同一个单元上可视化这些查询的结果。

业界 英伟达GTC大会谈GPU未来:实现机器学习和数据库的融合

  

本周,英伟达在圣荷西举行的 GTC 大会之前,我们与 MapD 和 Kinetica 谈到了把新兴 GPU 数据库与企业环境中的机器学习框架进行混合的可能性,这两个工作负载不仅共享同样的 GPU 单元,而且还像 HPC 空间中的模拟、可视化和机器学习所做的那样相互反哺。

  

MapD 创始人 Todd Mostak 告诉 The Next Platform 说,「这将是一个大趋势。如果我们有数据库、可视化和 GPU 机器学习,为什么不使它们一起工作?人们一直希望在 MapD 之上运行 TensorFlow,或者甚至在数据上运行回归以连接点,而无须离开 GPU 生态系统。现在,人们正在使用 Spark,它是好的,因为它连接到了 Hadoop;但是要使用这些公司使用的数据集来获得任何一种性能,他们必须大规模地进行扩展,然后将结果从集群中的 CPU 移到 GPU。但是如果你把一切保留在 GPU 之中,并从 GPU 生态系统的不同部分传递结果,这将是一个巨大的胜利。」

  

在 GPU 加速的数据库与依赖 GPU 来显著提升性能的机器学习框架之间的搭配中,还有一个问题仍待解决,即数据如何存储在机器的集群中。你是否在一个 CPU-GPU 集群中有一个用于运行数据库的分区,还有另一个分区用来运行 TensorFlow、Torch、Caffe、Theano 和 CNTK 这样的机器学习框架?还是说你实际上想将机器学习算法所用的数据就存在 GPU 数据库中?

  

Mostak 说,一种方法是使用 GPU 数据库作为记录(record)的存储位置,而且即使数据在该数据库中不是以张量格式存储的,该数据库也可以进行调整使其输出那种格式并将其传递给 TensorFlow 这样的框架。然后人们可以使用简单的老式 SQL 来查询该数据库以获得数据的一个子集,然后将其放入到机器学习框架中。

  

他补充说:「我们一直都会看到这种情况。公司需要将数据的子集放进它们的训练算法中,而且需要做得非常快。」另一种方法实际上是将本地的机器学习格式放进数据库本身,因为它们确实期望有结构化的数据,而不只是点击流和图像数据的 core dump 或任何对象存储(object store)中东西。Mostak 解释说,张量基本上就是一个向量,以类似于纵列数据库格式的方式表示,所以这里已经有非常好的适配了。

  

这些天来,GPU 数据库制造商 Kinetica 的 CEO 兼联合创始人 Amit Vij 也在思考人工智能(AI)和商业智能(BI)的交汇。他认同公司正部署以训练机器学习模型的严重依赖 GPU 的系统与 Kinetica 等公司开发的 GPU 加速的数据库具有完全一样的架构。超大规模用户(hyperscalers)已经在从消费者角度来对待这一问题了,它们正在努力分类我们的猫片和家庭视频;但 Kinetica(之前名为 GIS Federal)具有更加严肃的背景。

  

「因为有军方孵化的背景,所以我们已经将机器学习和图像识别技术用于无人机追踪的实体上,提取特征后返回基地以识别(车辆和其他内容)。」Vij 说,「我们已经有了一个 GPU 加速和分布式数据库,可以将人工智能和 BI 集成在一个平台上。」

  

你可以在同一个 GPU 集簇上运行 Kinetica 和框架,比如 TensorFlow、Caffe 或 Torch,不过为了方便工作量管理,最好分区运行数据库和机器学习工作负载(这和 MapD 上面所谈到的不一样,你要试着在 GPU 内存上保存所有的东西,从那里读取内容)。区分开人工智能和 BI 工作负载后,就能避免系统超负荷运行,两个不同的工作负载也不会相互负面影响。

  

Kinetica 也有一个容器环境,每种工作负载可分别向上向下扩展到集群上,以动态虚拟方式并肩运行。Kinetica 可以在内存中(或者 CPU 或者 GPU)存储几十亿行数据,还有用户定义功能,可以用存储在大型数据库的表格中的数据训练 TensorFlow 以及其他机器学习框架。比如,金融服务公司可以存储几个月甚至几年的股票行情数据,根据各种与股票价格相关的既定外部条件,预测分析股票价格(这也是 Kinetica 部署使用案例之一)。

  

总的说来,那些正在将数据库和机器学习工作负载混搭起来的早期用户,他们用于机器学习的机器比用于数据库处理的机器还要多。典型的 Kinetica 集群部署为 40 到 60 个节点,盒子里有很多 GPU,可以形成相当好的集群来运行机器学习算法。特别是用 MPI 协议延展的机器学习框架,就像俄亥俄州大学研究人员采用的方法那样,或者其他人使用的办法,比如 Facebook 处理已经开源的 Caffe2 框架的方法。虽然公司可以在云端部署 Kinetica,但是,我们更倾向于在这一前提下进行部署:金融服务、军方、制造管理方面的数据敏感性是给定的。而且鉴于这一既定事实:取决于 GPU 加速数据库的应用通常都是关键任务,不能降速,用户通常会部署双活高可用性集群。

  

为了让人工智能和 BI 集成更加容易,Vij 说 Kinetica「深度对齐」TensorFlow 框架,在 Kinetica 数据库框架中,张量被作为首先考虑的因素并以数据格式存储下来。这个任务并不困难。最初的 GPUdb 数据库就是当时所谓的 GIS 联盟创造的——现在,公司和产品都叫 Kinetica——一开始被作为地理时空引擎,然后它又用 JSON 来表征一个点、线或者多边形,对于一个 GPU 数据库来说,有一个朴素的目标最合适不过了,因为它正在矩阵上运行。

  

Vij 说,「我把这看作一个方案想法,其中所有的东西像一个苹果产品,通过单一技术进行封装,最终为终端用户轻松部署。并且不仅我们强化技术,用户也会。数据库管理者、机器学习专家和数据科学家不必熟练掌握 5 到 10 种不同的技术;他们也不必亲自使用开源框架,况且这些框架多是批量导向。我们由于所有这些堆栈而成为了分布式 GPU 管道,且开发者将我们用作数据库平台,而无须把数据从一项技术移动到另一个。」

  

没有人具备时间、金钱或者意向来完成所有的数据移动。因此,关于数据库和机器学习的融合平台将是一个很好的案例。大多数公司不满于为甲骨文数据库及其扩展或者等价的 IBM 和微软数据库服务支付高额费用;但现在,这已成为过去。

  

原文链接:

  ↓↓↓