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 管道，且开发者将我们用作数据库平台，而无须把数据从一项技术移动到另一个。」