NeuroBlade的SQL处理单元（SPU）
彻底改变了大数据分析
Elad Sity领导深度探讨NeuroBlade的SQL处理单元（SPU）对未来大数据分析的革命性影响。本次演讲突出了SPU作为数据分析加速的核心技术，提供快速和可伸缩的处理能力，将大数据转化为可操作的洞察。探索NeuroBlade在推动大数据分析方面的作用，通过增强市场导入来使其更易获得。
演讲者：NeuroBlade 首席执行官兼创始人Elad Sity
NeuroBlade的首席执行官Elad Sity介绍了他的公司，该公司成立于2018年，旨在革新数据处理。NeuroBlade已经发展到120多名员工，并筹集了超过1亿美元。该公司在以色列的特拉维夫和加利福尼亚州的Palo Alto都有业务。他们专注于加速大数据分析，特别是针对加速SQL查询和数据查找。NeuroBlade的SQL处理单元（SPU）旨在更高效地运行数据分析，以三分之一的成本获得高达30倍的性能提升。
NeuroBlade的SPU是专为数据分析而建的加速器，不是CPU或GPU。它通过软件层和API与客户已经使用的现有分析引擎（如Spark、Presto和ClickHouse）集成。SPU专为现代云环境设计，并支持容器化工作负载，但目前不支持虚拟化工作负载。它还针对结构化数据分析进行了优化。
该公司已与戴尔合作，为企业客户提供搭载SPU的PowerEdge服务器，而超大规模客户则可以将SPU卡集成到自己的服务器设计中。NeuroBlade进行了显示显著性能提升的基准测试，例如将查询时间从几分钟减少到几秒钟。
问答环节，Eliad回答了关于SPU与查询优化器的集成、其对容器化的支持、其对结构化数据的关注以及其与客户现有基础设施和分析引擎的集成易用性等问题。他澄清说，虽然他们目前没有针对传统的RDBMS平台（如Oracle或SQL Server）进行定位，但将来愿意与此类供应商合作。
-----
我是NeuroBlade公司的首席执行官Elad Sity。今天，我将与大家分享关于NeuroBlade以及我们如何加速大数据分析的相关内容。稍后，我们的市场副总裁Mordechai和首席产品官Krishna也会分别上台发言，深入探讨市场和产品方面的细节。
我们于2018年创立了NeuroBlade，致力于革新数据处理方式。如今，公司规模已扩大至120余名员工，并成功筹集了超过1亿美元的资金。我们的主要业务集中在以色列的特拉维夫，同时在美国Palo Alto设有分部，我的联合创始人兼NeuroBlade首席执行官Eliad也常驻那里。实际上，我们感到非常惊喜的是，我们已经开始向客户发布这些产品，并看到客户从我们的产品中获得了实实在在的价值。
关于数据分析领域的一些情况，我可以简单地举个例子来说明。当我们在2018年创立NeuroBlade时，我们怀揣着一个宏伟的创业理念，那就是成为数据领域的英伟达（Nvidia）。随着时间的推移，我们逐渐明确了我们的目标，那就是加速数据分析。在与众多大型超大规模公司、大型银行以及大型制药公司的交流中，我们了解到他们都面临着加速SQL查询或快速查找的难题。
在过去的几年里，大数据分析或分析型数据库备受瞩目，这让我们稍感惊讶。因为SQL自上世纪70年代以来便一直存在，起初主要用于研究和商业决策支持。随着数据量的不断增长，数据挖掘逐渐成为热门话题。进入2000年后，互联网的迅猛发展以及物联网的兴起，使我们能够收集到更多数据。这些数据被用于分析客户行为和人们的行为模式，以便更精准地投放广告、提高收入。同时，我们也试图通过理解这些行为来改善世界。这推动了人工智能和机器学习时代的到来。我们开始构建各种模型，并输入更多数据进行管理。最终，生成式AI的兴起引发了新一轮的数据爆炸。
我们可以发现，在这一系列的发展过程中，我们从数据中获取了更多的价值。但要进一步挖掘数据的价值，我们需要保存并分析这些数据，这就导致随着时间的推移，我们需要处理的查询量越来越大。
值得关注的是，在语言模型的发展过程中，由于数据的不断增加，查询量也随之增长。而现在，查询量的增长不仅仅是因为数据量的增加，更多的人也开始提出更多的查询需求。许多数据库供应商，包括我们的一些客户，已经开始将语言模型作为数据库的前端。这意味着，以前只有企业中的一小部分人（如程序员、数据分析师或SQL专家）能够提出关于数据的问题，或者需要求助于商业智能团队或分析团队。但现在，随着这些界面逐渐转向自然语言导向，企业中的每个人都可以轻松地提出自己的问题。
另一件值得注意的事情是，当你与这些语言模型交互时，你通常需要问多个问题才能找到你想要的答案。因此，我们不断地积累着越来越多的数据。而最重要的是，现在的查询量也越来越大。
过去几年里，我们的基础设施已经难以跟上查询量或数据量的增长。实际上，每花费一美元所获得的查询量已经开始下降。这意味着，数据量翻倍并不意味着只需要翻倍的CPU或GPU就能处理。有时，你可能需要10倍甚至更多的资源。你将不断在硬件上投入更多资金，仅仅为了维持从数据中获取所需的速度和价值。
回顾一下，这其实是我们开始的地方。我们正在尝试新的形态，专注于数据密集型应用程序，特别是高频股票交易。Eliad和我最初都是年轻的实时工程师，我们开始思考为什么这些应用程序不能运行得更快。我们意识到，CPU只是为通用工作负载而设计的。它们旨在尽快运行你要执行的任何任务，但并没有为任何特定的工作负载进行优化。
然后在2017年，我们开始尝试使用GPU。GPU被称为强大的工具，在图形处理方面，NVIDIA最初是从图形游戏起家的，然后是深度学习，这需要大量的乘法累加单元。但我们真正研究的是关于数据的数据流和数据结构管理、内存管理以及网络和存储的管理。
当我们开始与之前提到的所有公司交谈时，我们发现超大规模企业的问题已经从几年前的局部软件问题转变为真正的大型基础设施问题、规模问题。它变成了一个涉及计算、网络、存储以及能源和空间的问题。最终，对于任何加速公司来说，这都是一个真正的软件问题。即使你拥有加速器，它仍然是一个巨大的软件问题。如何扩展是一个关键挑战。
我们看到许多超大规模公司开始构建自己的内部解决方案来加速SQL查询或数据分析等任务。这是因为，当我们与这些公司交谈时，以及在最近的研究中，我们发现这些公司每家都在这项工作上花费了超过10亿美元，这还不包括存储和网络等其它方面的投入。因此，如果我们能改变这种状况，我们就能真正改变现有范式，节省大量资金，同时节省能源，并从所有客户的数据中获得更多洞见。
这一切都得益于我们的SPU，即我们所称的SQL处理单元。如你所见，我们试图给它起一个描述性强的名字。在尝试了多个不同的名称后，我们最终选择了这个直接明了的名字。这款产品的独特之处在于，它是一款专为数据分析而设计的加速器。它并非仅仅拥有多个乘法器或能运行任何任务，而是专注于协助CPU更高效地执行数据分析工作。
当我说“更高效”时，我将向你展示我们与客户合作所取得的一些成果。在某些情况下，我们实现了性能提升30倍，而成本仅为原来的三分之一。当然，并非所有结果都如此惊人，但在其它场景中，我们也实现了10倍的性能提升。然而，正如我之前提到的，这些大公司在该领域的支出如此庞大，即使能节省30%到40%的10亿美元支出，对他们来说也是一笔巨大的数目。
再来说说我们的SPU。我们花费了近六年的时间来设计它，以确保它完全适应现代的云环境架构。SPU是专为分布式存储和计算而设计的，这一点从我们目前所支持和加速的引擎中便可见一斑。
不过，还有一点至关重要，那就是软件堆栈。您可以打造出世界上最出色的处理器或加速器，但如果没有配套的软件堆栈，让用户能够轻松集成，无需学习新架构或新语言，同时还能让用户快速启用或关闭功能，那么这款产品恐怕也难以发挥其应有的价值。因此，我们选择不另起炉灶，开发全新的分析引擎，而是专注于连接并加速客户当前实际使用的分析引擎。
我们与不同客户合作的三个例子，都是关于连接并加速这些分析引擎的。有些客户还拥有自己的引擎，我们同样也在帮助他们进行连接和加速。我们的目标是尽可能地满足客户的需求，让客户能够更方便地使用我们的产品，硬件集成方面也是如此。
我们的产品是一个标准的PCIe卡，适用于任何服务器。无论是您从OEM处购买的服务器，还是我稍后会详细介绍的ODM服务器，SPU都可以轻松安装在其中。对于不同的企业，我们也与OEM进行合作。去年，我们宣布了与戴尔的合作伙伴关系，并且已经在戴尔的PowerEdge服务器中验证了SPU的性能。对于希望使用这项技术的企业来说，他们可以直接从我们这里购买SPU卡，并将其集成到他们自己的服务器设计中。
最后，我想分享一些我们之前公开的结果。我们一直在做这个工作。
你好，你可能会对这一点有所了解，所以我不想打断你的发言，但是关于这个集成，你们是否与这些引擎中的查询优化器协同工作，或者你们只是通常接受加速这些查询，而这些查询通常会分配给CPU来处理呢？
Krishna接下来的内容会更详细地涉及到这个问题，但我可以先简单告诉你。我们的做法是，有一个名为DAXL的软件层，它是我们卡的一个API，这个软件层会集成到这些常见平台的查询计划器中。我们并不试图改变查询计划器，它的工作方式是，将我们擅长加速的部分推送到硬件中进行处理，如果我们不能处理或者不能加速，CPU会继续处理。我回答你的问题了吗？
是的。
我的理解是，这个API是在操作系统级别上运行的软件组件，对吗？
没错，确实是这样。不过，它的功能远不止于此。它不仅仅是一个简单的守护进程，它在不同的平台上有不同的集成方式。但从本质上来说，它可以被看作是一个驱动程序层级的组件，同时也是一个中间件的层级。最终，这个API就像是一个软件基础，但更深入地与驱动程序层面进行集成。它既在驱动程序级别工作，也在其它级别发挥作用。
关键点在于——我稍后会详细介绍这部分内容——我们的目标是支持众多突出显示的功能。就像我之前提到的，我们想让客户能够更轻松地适应我们的产品。这意味着我们需要沿着这样的道路前进：使用客户正在使用的文件格式、内存布局等等。
我来分享一下我们去年公开的一些合作成果。我们与MAA的Velo团队合作，针对Velux进行了加速优化，主要通过加速Presto和Spark，我们取得了超过30倍的加速效果。稍后Krishna会进一步深入探讨生态系统、各种数据格式以及我们如何集成到现有标准环境中的更多细节。
这里我想特别提到一个有意思的结果。在医疗保健领域，我们有一个客户拥有大量记录，他们建立了一个系统，允许用户连接系统并对数据进行查询。在他们使用现有的一代技术时，你可以看到真实查询客户数据的运行时间在一分钟到三分钟之间。这意味着用户发出查询后，需要离开一会儿，比如去喝杯咖啡，再回来查看结果，而结果可能还没出来。但是，通过引入NeuroBlade的技术，即使是在最耗时的查询中，用户也能即刻得到结果，完全不需要离开座位，查询过程仅需几秒钟。这极大地改变了用户的工作方式，提高了工作效率。甚至可以说，我们除了为用户节省时间外，还在某种程度上优化了他们的咖啡消费量，因为他们不再需要频繁地离开座位去喝咖啡了。
我有一个问题。如果将那块硬件集成到企业系统中，服务器中，那么企业是否能像幻灯片所展示的那样实现30倍的性能提升？如果是这样，企业是否有能力购买更便宜的服务器，因为他们通过集成您的硬件获得了性能提升，从而从数据分析速度中节省了成本？与不使用您的产品相比，他们是否应该选择购买更便宜的服务器，还是像现在这样购买尽可能高性能的服务器，然后再集成您的硬件？
我只能告诉您我们在实践中观察到的情况。实际上，很多这些客户都是规模非常大的客户，他们正在自行设计服务器。这也涉及到与这些客户建立信任关系的问题。目前，他们会继续购买高性能的服务器，因为这样需要的服务器数量更少。但如果出现最坏的情况，他们可以关闭SPU，并像以前一样运行。几年后，当这种技术被广泛部署时，他们可能会开始尝试购买更便宜的服务器。但最终，关键在于拥有更少的服务器，而不一定是更小的服务器。对于只有一两个实例的小型中心来说，这并不是规模问题。所以实际上，客户想要的是更少的服务器，而不一定是更便宜的服务器。
关于虚拟化架构，我有一个疑问。您的卡是否支持虚拟化工作负载？因为我知道，或者您是否假设所有这些大数据部署都是在没有虚拟化层的裸机上进行的？
实际上，我们目前主要的想法是与那些正在构建自有基础设施的公司合作，这是在裸金属层面上的，但我们也可以通过Kubernetes等方式支持容器化。至于虚拟化，我们目前还没有着手解决，因为尚未收到来自客户的相关需求。
对，我们确实支持容器化，因为容器提供了不同的硬件访问方式。我注意到很多企业都在将容器与AI结合使用，因为库和其它组件大多都内置在容器中，并由Nvidia和其它供应商分发。
我想补充一点，根据我们的观察，大多数客户都是为特定的工作负载而设置服务器的。他们并不是在进行其它类型的测试，比如AI，或者它是AI堆栈的一部分，但他们仍然在运行数据分析。这些服务器可能是Spark服务器、Presto服务器或ClickHouse服务器，它们不承担其它任务。
您主要是支持对结构化数据进行查询，还是也支持非结构化数据？
从软件层面来看，我们主要侧重于结构化数据。当然，我们也有客户使用相同的API对非结构化数据进行了一些分析，但我们的核心还是在于结构化数据。你会发现，无论是结构化还是非结构化数据，很多运算符都是通用的。
好的，谢谢。那么我现在有两个问题，您展示了一些查询的基准测试结果，那么这些测试是在标准的TPC-DS或TPC上运行的吗？
我们目前还没有在标准的TPC-DS或TPC上公布官方的基准测试结果，但可能会在几个月内发布。
关于您的SPU，您采用了哪款GPU芯片组？也许您之前已经提到过，它看起来像是Nvidia的产品。
实际上，我们并没有使用CPU或GPU。
明白了，我可能有些混淆。看起来您主要面向的是现代数据堆栈引擎，如Presto、Spark，还有ClickHouse等。这些引擎很多时候是在云环境中运行的，当然也有一些公司会在本地运行它们。不过，我认为这些引擎的主要市场还是在云端。既然您主要面向的是在本地工作的人群，那么为什么不考虑也支持主要的关系数据库平台或它们的数据仓库变体，比如微软的分析平台或Oracle数据仓库等呢？
这可以说是一个市场问题或市场策略问题。我们当前的主要目标客户是那些超大规模的企业，他们同时也是云服务商。这些企业拥有自己的内部基础设施，并服务于自己的用户。他们并不一定在本地运营，因为他们是云服务商。
我们试图满足他们的需求，他们的前提可能是一个数据中心设施，但他们仍然对硬件有控制权。他们掌控着硬件，同时也是他们自己的，可以说他们是独立的软件平台。像微软这样的公司通常不会从SAP或Oracle购买软件，他们更倾向于自主研发，基于微软SQL，或者Spark、Presto、ClickHouse等引擎。你会发现这三个引擎在现代数据处理中非常常见。当你研究像AANA这样的公司，或者研究Starburst，你会发现即使有这些独立的本地软件供应商，他们的产品也是基于这些平台的。
我们也正在与一些公司合作，加速他们自己的引擎。所以，你可能会看到我们与Starburst和Databricks等公司的OEM合作。你提到的这两家公司，Starburst使用的是Trino，他们是将引擎名称从Presto改为Trino的团队。我承认我总是混淆这些名称和分支，但我们会努力与这些公司合作，提供更好的解决方案。
我有一个问题。作为一名长期从事Oracle数据库管理员工作的人，我深知Oracle优化器的工作机制。我真的不太明白你们的产品如何能为那些在云上运行Oracle数据库的企业带来价值，比如那些在专门设计用于处理可能需要进行大量全表扫描的查询的Exadata上运行的自治数据库。对我来说，你们似乎更关注一些小众的、更偏向开源的数据库，比如Apache Spark。这固然很好，但还有很多大型企业在使用SQL Server、PostgreSQL等其它Oracle的竞品。我想知道你们如何能为那些需要处理PB级SQL数据的更大型数据库带来价值。
如果我们看一下我们的目标客户，你会发现他们对Oracle的使用并不多，反而对Spark、Presto和ClickHouse等工具有大量的使用需求。这并不是说Oracle不好，我们很愿意与Oracle合作，帮助他们加速Oracle Exadata数据。我们过去已经对Oracle Exadata数据进行了测试和基准测试，当这些基准测试结果可用时，我们会与Exadata数据进行比较。不过，我认为更公平的比较应该是与Spark、Presto等我们主要关注的市场进行比较。这才是我们的目标市场。
好的，确实很酷。我只是想确保自己理解了我们正在讨论的市场——我认为这再次指向了那些超大规模的公司，他们拥有自己的解决方案，并希望加速他们自己的基础设施。
这说得通，谢谢。
我对你提到的集成有些疑问。你所说的“容易集成”具体指的是什么？
我的意思是，我可以理解它在硬件部件中的集成可能是很容易的，只需将其插入相应的插槽即可。
但你是在谈论与数据库的集成吗？如果是的话，你是如何简化这个过程的？
是的，这与我们的讨论是相关的。我会让Krishna在他的会议中进一步讨论这个问题。但在此之前，我可以告诉你，最近我们有一个客户进行了Presto的集成，他们花费的时间相比之前有了显著的减少。几个月前，一个客户需要三个月的时间来完成集成，而在上个月，另一个客户只花了一周的时间就完成了集成。
你所说的“集成到他们的软件中”具体是指什么？是他们的软件堆栈吗？当他们谈论自己的软件堆栈时，他们是指数据库、应用程序还是其它什么？
不，他们指的是他们的基础设施，比如他们的Presto或Spark等。他们各自有自己的Spark实现、Presto实现或ClickHouse实现等。我们不仅仅提供如何连接到Presto的参考文档，而是需要面对他们高度定制化的Presto设计进行集成。他们的Presto可能与开源的Presto有很大的不同，因此我们需要与他们自己的Presto设计进行集成。
利用加速技术为未来的大数据分析赋能：NeuroBlade的角色
Mordechai Blaunstein讨论了在大数据分析领域中数据分析加速的关键需求。通过展示NeuroBlade的SQL处理单元（SPU），展示了其提高大数据处理速度和规模的效果。与会者可以深入了解定义大数据分析格局的最新趋势，包括数据湖架构和开放标准，并了解NeuroBlade如何满足数据中心对快速数据分析加速的需求。
演讲者：NeuroBlade市场副总裁Mordechai Blaunstein
Blaunstein强调了数据呈指数增长以及与之相关的挑战，如计算、网络、存储、能源、空间和软件。他概述了影响他们解决方案的市场趋势，包括向数据湖和数据湖仓库架构的转变、云中快速数据分析的需求以及开放标准的采用。
Blaunstein解释说，传统CPU无法有效扩展以满足大数据分析的需求，而虽然GPU提供了更好的性能，但价格高昂且供应有限。NeuroBlade的SPU被呈现为专为数据分析而构建的加速器，旨在提高性能而不需要高昂的成本。
SPU可以集成到现有的软件生态系统中，并支持像Spark、Presto和Clickhouse等常见工作负载。它作为一个PCIe卡提供，便于集成到服务器中。Blaunstein提到，SPU特别适用于拥有大量数据且由于监管或其它限制无法将数据转移到云端的大型企业。
观众提出的问题涉及SPU的目标市场、与其它加速器的竞争、与分析层的集成、许可证问题以及软件SDK和API的开源可用性。Blaunstein澄清说，SPU被优化为每台服务器一张卡，因为它已充分利用了服务器的I/O能力，并且数据分析工具的分片是由NeuroBlade层上方处理的。
-----
我会先概述一下我们的解决方案，然后再深入探讨上次会议中提及的市场情况。大家提到了市场的现状以及我们在其中的定位。因此，我们会重点讨论那些对我们解决方案定义产生重大影响的趋势。
在谈论整体局势时，我们注意到数据呈现出持续增长的趋势。随着数据量的不断攀升，我们需要进行大规模的扩展，可能是原有规模的10倍甚至更多。尽管这里没有具体的数字，但可以肯定的是，只有进行大幅度的规模扩展，我们才能有效地处理如此庞大的数据量，并使其更易于使用。否则，大量的数据存储投资将被浪费，同时也会给客户带来诸多挑战。当客户试图在不增加过多存储成本的前提下快速扩展并利用数据时，就会面临各种困难和挑战。
我们观察到了这样的市场趋势，并尝试提出一个解决方案，以帮助客户实现扩展，同时避免成本激增。因此，我们设计了一种加速器，我们将其称为SPU。这个名称与市场上的xPU命名趋势保持一致。SPU是专门为数据分析而设计的，我们并没有采用为其它任务构建的硬件或计算芯片，然后再尝试通过软件解决方案来最大化其性能。相反，SPU是从头开始，针对数据分析和客户面临的挑战进行设计的。
它是为云原生架构设计的，可以轻松地集成到客户的软件生态系统中。无论是云端、混合云还是云原生架构中的客户，都可以使用SPU。虽然它可以在本地使用，但其云原生的特性使其更适合大规模的应用。我们的目标是构建一个能够轻松集成到客户软件生态系统中的解决方案。
因此，我们开始与一些最常见的大规模或不断增长的工作负载进行集成，如Spark、Presto和ClickHouse等。一些客户直接使用我们的API将SPU连接到他们的数据分析工具，这也是可行的，因为我们提供了相关的API。
在我们的产品演示中，大家将会更深入地了解这一优势。它以PCIe卡的形式呈现，可以轻松集成并直接连接到服务器上，无需进行任何繁琐的硬件改动。
现在谈谈市场趋势。这些市场趋势帮助我们明确了需求，以及如何定义和构建我们的解决方案。众所周知，数据正在不断增长。我们看到组织正在收集更多的数据，并发现新的业务机会，无论是寻找更多客户、发掘更多商机、提升服务质量，还是优化操作和降低成本。数据的使用和利用方式多种多样，包括结构化和非结构化数据。但我们看到大量需要更多计算能力的数据涌入生态系统。
你不这么认为吗？
是的，如果这不是你们的目标受众，我深表歉意。但出于好奇，如果我们暂时抛开AI和ML的炒作，假设你是一个组织，你选择了LLM路线或AI路线，并使用ML工作负载和引擎进行训练。比如说，如果你是那家公司，你是否希望利用NeuroBlade的SPU来降低成本？或者这并不是你真正关注的目标受众？
它虽然不是主要的目标受众，但可以作为ETL过程的一部分来发挥作用，例如在你希望安排数据处理时。我们发现ETL过程的速度可以提高几十倍，这将有助于你更好地利用基础设施。因为GPU不会等待数据准备就绪，它会迅速完成任务，甚至模型的训练速度也会更快。因此，你将能够更高效、更快速地过滤数据。
明白了，非常感谢你的解答。好的，谢谢。
接下来，关于数据趋势，这已是一个持续多年的发展态势。在我们考虑和定义解决方案以及客户目标时，我们确实将其纳入了考量范围。我们注意到，客户正逐渐转向更多的垂直仓储解决方案。这里所说的“垂直”，指的是在特定平台上，你清楚知道运行的是什么样的硬件。
与过去多年来客户所采用的解决方案相比，他们现在更倾向于选择数据湖或数据湖仓库的解决方案。数据湖能够帮助你充分利用低成本的对象存储，并在不同的数据分析工作负载之间共享数据，从而实现数据资源的共享。然而，数据湖在性能方面存在问题，尽管它可以高效扩展，但性能并不出众。因此，客户提出了一种混合解决方案，即数据湖仓库。在这种方案中，工作负载和对象存储之间有一个元数据层，用于存储元数据缓存或其它有助于应用程序更快找到并利用数据的信息。这样，你就可以兼顾两方面的优势。
对于缩小规模的问题，关键在于两个市场领导者Databricks和Snowflake都是公有云解决方案，对吗？
是的。
那么你们的市场定位呢？
我们会进一步讨论的，但可以肯定的是，公有云服务商是我们必须迎合的客户群体之一。我们需要考虑如何在他们的基础设施上提供加速服务，以满足这一关键客户群体的需求。
这绝对是一个关键问题。在我看来，你的客户Databricks也完全可以成为我们的潜在客户。我这样表述是否准确？还是我遗漏了什么重要信息？
你说得没错，我会在接下来的两张幻灯片中详细阐述这一点。实际上，这个领域确实潜力巨大。虽然我不想在这里提及任何具体的公司名称，但我们可以明确的是，满足公有云中客户群体的需求是一个重要的增长方向。我们正在密切关注这一趋势，并据此构建我们的解决方案。
另外，你是否还针对特定的受监管行业提供服务？
是的。
你有没有具体的行业案例想要分享？
当然，我也理解他们可能不太愿意公开分享。
以卫生保健提供商为例，他们可以在自己的环境中采用我们的解决方案，并从合作伙伴那里获取相应的支持。卫生保健是一个受到严格监管的行业，但我们的服务并不仅限于这个领域，还包括其它同样受到严格监管的客户。
确实如此，我认为这个设计更倾向于数据仓库，而不是数据湖仓库。我理解数据湖仓库的概念，它允许你存储结构化和非结构化数据，并以结构化的方式导出数据以进行查询。但我们的设计更注重于数据仓库的功能性和效率。
确实，当你在操作Databricks和Snowflake环境时，会遇到类似的情况。但听起来，你的真正目标客户是那些拥有大型结构化数据库并使用SQL查询的公司。这个观点很有见地，问题也问得很到位。我认为，最好的回答方式是：想象一下我们有一个可以更快执行数据分析工作和SQL查询的CPU。就像CPU有特定的指令集可以更快执行SQL操作一样，这是我们的核心理念。无论数据生态系统中的数据以何种格式存在，我们都能提供相应的加速服务。
确实，我们可以加速结构化数据的处理，但这并不是我们产品的唯一功能，也不是我们的主要限制。这只是我们当前专注的一个方面。我们的市场足够广阔，面临的挑战也足够多，这是我们当前选择专注的领域。
我认为，你通过SPU解决的是服务器内存方面的问题。进行查询操作确实需要大量的内存资源，因为并非所有数据都存储在内存中。我们直接从存储中以原始格式提取数据，并将其推送回加速器中进行处理。这样，你就能以接近内存的速度执行查询操作，并输出所需的数据。
非常感谢你的解释。
接下来有一个相关问题：如果不涉及客户的具体行业领域，我们是否可以这样理解，那些拥有大量数据的大型企业，由于数据引力、监管要求或其它原因，他们不会将数据迁移出他们的数据中心？那么，这些企业是否是你的主要目标客户群体？
他们并不是我们唯一的目标客户群体，但确实是首批能够采纳我们解决方案的客户之一。这是因为他们拥有完全的控制权，对自身需求非常明确，同时拥有大量数据和快速获取结果的需求。他们能够投入大量资金进行部署，并采用我们的API。在我们的协助下进行部署后，他们会积极地进行研究和探索，有时我们甚至不清楚他们具体在做什么，除了使用我们的API和提出错误修复请求之外。
那么，你是否有特定的目标客户群体，你希望他们的数据仓库或数据湖达到一定规模，从而能够验证你提供的解决方案的有效性？
当然有。不过我们会进一步深入讨论这个问题。所有公有云服务商、私有云供应商以及超大规模供应商都是我们的潜在客户群体的一部分。目前，我们正在与众多客户进行对话，覆盖率相当高。
另一个趋势也促使我们加大了投入，那就是数据分析和格式的开放标准。在软件基础设施层，软件正在逐渐实现解耦。因此，不同的查询引擎可以支持不同的表格格式或文件格式，并期望能在不同的存储解决方案上运行。这为客户提供了灵活性，使他们能够利用各个领域的最佳解决方案，并选择最适合其存储中表格格式的查询引擎，从而无需担心供应商锁定问题。这对于客户和所有提供解决方案的参与者来说都是非常理想的，无论是软件解决方案、硬件解决方案，还是二者的组合。我们需要支持所有这些格式，这也是我们讨论的焦点。我们首先会考虑哪些客户，然后再跟进哪些客户。通常是首批采用者客户，他们愿意接受新事物，并在此基础上进行开发、测试，并帮助我们确保产品最适合他们的业务领域。
这个趋势是云端数据分析的增长。云端数据分析正在迅速崛起，因此我们需要与客户建立联系，可能会作为他们数据分析服务的一部分出现在公有云中。为此，我们需要与他们的数据分析服务团队合作。当然，他们也在内部进行数据分析，所以我们还需要与这个内部团队保持合作。此外，他们还有服务提供商为其提供数据分析解决方案，我们也需要与这些服务提供商建立联系。因此，这是一个涉及多个方面的讨论，实际上不仅仅是三个方面，因为我们还需要与基础架构团队沟通，确保我们的卡可以集成到他们的基础架构中。同时，我们还需要确保最终用户，无论是数据分析服务的用户还是内部数据分析的用户，都能充分利用我们的软件。
我不想深究细节，但你可以清楚地看到我们在哪些环节能够与客户接触。我们不是一家能解决所有问题的大型企业，而是一家专注于服务早期采用者并具备足够规模以证明投资合理性的小公司。
我们定义了一个加速器。起初，我们对此持怀疑态度，因为大多数数据分析解决方案都是基于软件的。但随着云端和数据中心中加速器的日益普及，我们意识到CPU的使用量在不断增加，GPU的使用量当然也在攀升。突然间，我们认识到定制工作负载加速的需求同样在增长，这涉及到网络（如DPU和我们的SPU）、安全卸载和存储卸载等方面。
因此，我们观察到一个趋势，即所有客户都希望扩展他们的基础设施，并需要发明或利用一种不同的计算方式来满足能源和功耗的限制。
说到CPU，它确实是一个简单易行的选择。作为一种软件解决方案，CPU被广泛应用，所有工作都可以在CPU上完成，成本适中，可用性高，已经被广泛部署并证明是安全可靠的。问题在于，你无法高效地扩展它。虽然它的性能还算可以，运行也算稳定，但只是勉强满足需求。因此，你只需要更多的服务器，比如BF服务器，就可以完成任务。虽然速度不是最快的，但足够应对当前需求，客户今天就可以使用它。然而，这并不足以满足未来的扩展需求。
我们来说说GPU。GPU是目前顶级的加速器，就像Elad在他的演示里提到的那样，它自然是我们首先会考虑的选项。不过，GPU的计算能力与CPU大不相同。问题在于，GPU价格高昂、不易获取，而且可用性也较低。事实上，据我们了解，目前还没有大规模、实际应用于数据分析的GPU部署案例。虽然GPU能显著提升性能，甚至达到5倍的提升，但成本也极高。如果你只追求性能而不考虑成本，那么GPU确实是个不错的选择。然而，对于那些需要运行数百万个数据分析工作负载的云服务提供商来说，这并不是一个理想的解决方案。
考虑到这些问题，你如何看待像AWS Inferentia这样的服务呢？
它们在全球范围内提供定制芯片，以满足特定类型的工作负载需求。AWS在这方面表现出色，他们有为DPU设计的Nitro芯片、为存储优化的Nitro芯片，甚至还在自主研发驱动器以实现加速。他们在DPU上运行大量存储服务，例如最新收购的E8存储技术，这使得他们的EBS平台速度更快。AWS是首个提出“我们需要摆脱传统的硬件服务器架构，构建一个更高效的系统”的公司，因此在这方面处于领先地位。其它公司也在跟随他们的步伐，采用不同的模式，如使用FPGA或通过收购公司来获取技术。但你可以看到，加速技术的采用率正在不断提升。
你是否认为AWS的Inferentia、Google的TPU以及微软刚刚宣布的Maya等定制芯片是你们领域的竞争对手？
我个人并不这么认为。首先，它们的效率并不高，因为它们是为完全不同的工作负载而设计的。当你为特定工作负载设计产品时，你很难兼顾其它因素。因此，TPU或GPU并不是为直接读取存储格式中的数据、解码解压缩所有数据而构建的。它们可以在数据流的某些部分进行并行计算，但无法覆盖所有方面。因此，你只能利用数据流的一部分，这就是你使用非常特定的应用特定加速器的原因。
你认为NVIDIA的生产和分销效率有提升的空间吗？如果答案是肯定的，那么这就涉及到了可用性的问题。对于数据分析来说，如果有人购买了GPU，你认为应该将它部署在哪里才能获得更好的性能或更高的性价比？如果将它用于AI/ML领域，而不是数据分析工作负载，这就是我所说的针对数据分析工作负载的可用性。
当然，你提到的“数据分析工作负载”是一个非常宽泛的概念。我知道它涵盖了很多内容，但通过添加具体的描述，你正在使其更加具体，并与实际的数据分析工作负载相联系。我们现在先不深入讨论这个概念。
从你们的网站上可以看到，客户的数据与你们的SPU之间需要一个分析层，比如Spark、Presto等。没有这个分析层，公司就无法充分利用SPU的价值。但是，其中一些系统需要水平扩展到数百个节点才能获得高性能。你会推荐部署数百个SPU吗？
是的，我们会告诉客户使用我们的解决方案可以大大减少所需的服务器数量。很多客户都提供了实际案例，证明通过使用我们的解决方案，他们节省了大约70%的成本。有时候，成本的降低并不总是直接转化为性能的提升，有时候只需要一个更小的集群就可以满足需求。
为了避免反复将问题归咎于硬件性能不足，我们增强了现有服务器的性能。确实，我在此代表供应商发言。好的，既然产品概述已经给出，接下来我们将着手解决集成问题。我们的目标是满足客户的需求，而不是强迫他们采用比现在更加复杂的方案。
集成并非没有成本，因为需要引入新的硬件，同时基础架构团队和数据分析团队都需要参与并有所投入。但投入并不大，尤其是如果他们选择我之前提到的标准化解决方案。如果遇到特殊情况，问题变得复杂且对他们来说是个大问题时，我们将与他们紧密合作，共同解决。尽管我们是一家小公司，但我们愿意承担这样的成本。
我在会议开始时提到过，使用我们的产品，客户可以选择性能稍弱的服务器，并且可以减少服务器数量。如果我说得不对，请纠正我，因为我在数据分析领域不是专家。但我认为，即使使用我们的产品，客户也不需要强大的GPU支持。目前GPU价格昂贵，未来可能依然如此。但如果使用类似SPU这样的产品，客户就不需要花费数千美元购买GPU了。这是我们的产品带来的附加价值之一，或许可以说是第三级好处。虽然难以量化，但我们帮助客户理解价值的方式并不仅限于此。对于特定的工作负载，我们的优势是显而易见的。
我们进行了基准测试，并会展示部分测试结果，以便客户看到实际的收益。我们将深入探讨基准测试的细节以及在这些特定查询中的具体成本，帮助客户更深入地了解这个问题。
这张幻灯片是一个总结性的内容。我们的解决方案是基于行业趋势构建的，这些趋势引导我们设计出了既具有可伸缩性又具备灵活性的解决方案。它需要在云环境中顺畅运行，并实现硬件和软件的深度集成。对于容器和虚拟化技术来说，这一点尤为重要。目前，多租户虚拟化主要取决于公有云服务商的意愿，这超出了我们的预测范围。因此，我们更注重提供快速有效的查询处理能力。
我可以提个问题吗？在购买SPU卡时，无论是在OEM版本中还是作为独立设备运行，除了硬件之外，我们还需要购买额外的许可证或订阅服务吗？你之前提到了“供应商锁定”，虽然这个词带有一定的负面含义，但我还是想进一步了解：你提到了开源，那么请确认一下，虽然硬件不是开源的，但是软件SDK和API是否是开源的呢？
有些集成工作是与像Meta Velox团队这样的合作伙伴共同完成的。他们是我们首个合作的团队，为VCS提供了硬件加速支持。我们非常珍视这样的合作机会，并会积极寻求更多类似的合作。我们不担心分享API，只是要确保人们不能随意滥用它们，对吧？所以，虽然并不是完全开源的，但如果有意义的话，我们会考虑提供开源版本。
关于并行处理，你的中间件是否负责将负载均衡分配到多张加速卡上，特别是当客户配置了多张加速卡的时候？
目前，我们的优化策略是每台服务器配置一张卡，并与驱动程序完全对齐。当然，在云环境中，我们同样可以为每个虚拟机分配一张加速卡。对于运行在此云环境中的虚拟机实例，可以单独使用一张加速器卡。
从架构层面来看，如果有一个大型的查询任务需要运行，中间件并不会将其拆分到多张不同的卡上进行处理，因为这样做可能会引发磁盘或网络I/O的瓶颈。因此，在大多数情况下，使用一张加速卡就足够了。虽然增加更多的计算能力听起来很吸引人，但在某个时刻，你需要从某个数据源拉取数据，这可能会再次导致I/O成为瓶颈。当然，当I/O不再是瓶颈时，我们应该能够支持跨卡查询分发。这并不是说我们的技术有限制，只是目前尚未出现这样的需求和关注点。
接下来的问题是：你是否考虑过类似于MongoDB的解决方案？他们通过跨多台服务器进行数据分片来解决性能问题。你的意思是你的加速卡可以处理所有的性能需求，因此不需要超越单个服务器的限制吗？
我们并不直接处理数据分片，这是在我们上层完成的。数据分析工具或Presto会决定如何配置和处理数据。这就是我们的工作模式。我们不会做出决策，只是接收SQL命令或查询，并根据我们的能力来执行它们。
---【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）
