WEKA公司AI解决方案深度解析（PPT）
Source: Colin Gallagher, David Gilinsky, Efraim Grynberg, Joel Kaufman, Shimon Ben-David; WEKA Presents at AIFD3; May 19, 2022
《WEKA：迎接人工智能和下一代工作负载的挑战》 演讲者：David Gilinsky 《WEKA人工智能数据平台解决方案》 演讲者：Colin Gallagher 《构建WEKA解决方案的框架：为何统一的数据平台对于优化AI工作负载至关重要》 演讲者：Shimon Ben-David 《WEKA客户案例：将科幻变为科学事实》 演讲者：Efraim Grynberg
WEKA：迎接AI和下一代工作负载的挑战
介绍：
一系列力量的汇聚促使AI市场迅速成熟：随着全球新冠疫情加速了几乎每个企业在全球的数字化进程，AI现已成为现代企业和研究机构的必备战略。企业正在迅速导入一系列新型加速计算产品，其性能比传统CPU提高了10-100倍，深度神经网络模型数量大幅增加，引发了AI的寒武纪大爆发。然而，大规模运行AI项目需要大量数据，许多企业正在努力为这些数字化转型引擎提供充足的数据，以实现AI/ML的全部潜力，并推动其业务计划和研究项目取得进展。正是在这样的背景下，WEKA应运而生。
在这次讨论中，David将深入探讨WEKA客户在实施AI/ML项目时所面临的挑战，以及为什么WEKA开发其专为人AI设计的数据平台解决方案具有重要意义。
演讲内容：
大家好，我是David Gilinsky，负责WEKA的客户成功。
WEKA构建了一个面向AI数据平台。WEKA成立于2013年。昨晚我与许多长期从事存储工作的代表们进行了非常愉快的交流。我希望大家思考一下在过去的30多年里，有多少次你们曾经想过：“哎呀，有人能不能重新编写一下I/O堆栈呢？”我们得花多少时间去调试SCSI命令，查看CDB等等。我们得花多长时间去观察I/O堆栈，找出延迟究竟是从哪里积累起来的。WEKA就是为了应对这个挑战而成立的。m
WEKA由三位深耕存储领域的专业人士创立，你们可能会认识到其中一位，他们还涉及其他存储产品，比如XIV。这正是他们所做的，他们接受了我们其他人认为“哇，要做这个太难了，即使我们能做到，谁会相信我们呢？”这个挑战。这三位创立了WEKA，就是为了做到这一点。在这个幻灯片上，我显然没有在读的是一份清单，你们可以查看和了解这些内容，但也许最重要的一点是，我们每天做很多事情只是因为它一直以来都是这样做的，而I/O就是其中之一。有时候，只需要有人愿意用不同的方式看待这个问题，接受挑战，并重新编写这个东西。这就是WEKA为我所做的，对我个人而言，在一个纯软件存储平台、纯软件数据平台的公司工作真是令人激动，因为作为纯软件，它给予我们巨大的灵活性，而且我们不必处理令人费解的硬件问题。
我们今天谈论AI，并将以一种在一个漫长的、缓慢的革命结束时常见的方式来谈论它。我们认为是从一天到另一天发生的范式转变，导致每个人都在做事情的方式发生变化，就像我们今天在AI中看到的一样。实际上，这些被认为是范式转变的东西，实际上是多年多年努力、小小的实验和变化的结果，但当你达到一个拐点时——我们稍后会谈到推动这一拐点的因素——它看起来很像我们在化石记录中看到的寒武纪爆发，突然间你从一个稀疏的领域转变为许多不同的事物，它们以许多不同的方式做事，这是一件非常健康的事情，你会得到竞争，得到变化，得到对各种事情的适应能力，这是你无法预测的。
所以，我们今天将这一时期称为AI版本的寒武纪爆发。我不能继续下去而没有向那些认识到我们不再处于寒武纪时期的人们喊话，所以不能称之为寒武纪爆发，这将是全新的爆发，是的，我们知道，但是每个人都认识寒武纪，所以我们就坚持这个。
有了这些背景，随着这个解决方案的爆发，解决企业问题的解决方案大家可以有更多的选择。由我们所称之为AI/ML推动的解决方案的爆发，我们面临一些重大问题。这些问题包括那些为特定I/O配置定制环境的企业现在必须处理许多不同的I/O配置。当你将这一点与我们所说的许多AI管道在高性能计算环境中完成相结合，而这些环境设置与企业环境极为不同，我们就面临着挑战。作为商业企业客户，我们试图优化我们的环境的效率，以解决这些问题，使得我们不会浪费大量的时间和金钱。
这里有一些内容，我不打算读出来，但我认为你们大家都会理解。各个垂直领域、各个解决方案空间以及它们是如何传统地设置它们的环境以完成所需任务的，以及如何现在需要调整这些环境以执行看起来非常不同的任务。这些任务之间的差异非常大，因为在解决这个问题的整个过程中，从一开始到最后，你将会在后续的会话中听到更多关于这一点的内容。在I/O方面，我们存在着巨大的差距，包括I/O的模式、性能需求等等，无论是在数据摄入、预处理、处理还是摄取的相反过程中。
我们一直在处理复杂指令集架构，曾经认为只能不断地复制和复制和复制，使用越来越多的这些CISC（复杂指令集）核心叠加在一起，以获得所需的性能和吞吐量，就像气态巨星一样。现在，这些气态巨星已经被凝缩，将小核心的密度增加到了GPU中，GPU突破了摩尔定律，允许我们进行从未想过能够完成的计算，以采用我们所称之为AI和神经网络的方法来解决问题，这无疑是一场革命性的变革。这是一次巨大的推进，从技术和业务的角度来看，没有人能够承受不去做这个的代价。无论在哪个领域，所有竞争对手都在尝试通过采用这些算法、采用这些方法来获取关于他们核心竞争力的额外智能信息，所以你必须去做，你别无选择，因此你被迫进入这个困境，试图使你的环境适应一些它原本不是为之构建的事物。
WEKAAI数据平台解决方案
介绍：
在企业范围内运行AI/ML项目需要大量的数据——许多组织在为这些数字转型引擎提供足够的数据以实现AI的全部潜力并推动其项目前进时面临困难。一个关键原因是它们的传统数据基础设施根本无法满足现代工作负载（如AI/ML和云）的性能和可扩展性需求，这使得它们受到了制约。WEKA应运而生。
在这个环节，Colin将讨论WEKA的面向AI数据平台是如何通过一个基于软件的数据平台来解决几十年来数据基础设施的问题，该平台专门设计用于简化和加速为AI/ML引擎和其他下一代工作负载提供数据的数据管道。
演讲内容：
我们是AI数据平台，我在这里要和大家谈谈他们所设定的这个背景实际上为那些在过去十年左右实施生产中的AI的人们带来了一系列挑战。在过去的十年左右，我们真正看到了AI的一个转变，它已经从某些部门的手工项目逐渐转变为在企业中大规模部署。然而，作为你们在构建和管理这些部署时所面临的一系列挑战。
但首先，我想退后一步谈谈我们自称为AI数据平台是什么意思。我们有一些不同的关键标准，我们认为这些标准定义了数据平台，是的，我知道现在每个人都在称其产品为数据平台。这是时尚潮流，但是，你知道，将一些传统的巨大盒子称为数据平台，并试图将其塞进云中，与我们从头开始重新思考，专为这些现代工作负载而设计的情况完全不同。正如戴夫所提到的，我们是从头开始重新思考的，因此我们真的相信我们是一个真正的数据平台。
我们为您提供对所有数据的无处不在的访问，随时随地，通过任何协议，而所有这些协议上的数据都是相同的拷贝，无论是在本地运行、在云中运行、在边缘运行还是在混合环境中运行，都是相同的代码库。我们为您在所有这些部署上提供无限的线性扩展。我们还支持对所有不同类型的工作负载的零调优。传统的存储阵列通常为其中一种工作负载或另一种工作负载进行了优化，而为了正确服务不同的工作负载，您必须使用多个不同的存储阵列，但数据平台不同，它全面处理您的工作负载，最后，它必须是负担得起且易于部署的。
我是一个市场营销的人，我们喜欢把数据管道想象成一件非常简单易懂的事情。我大约五年来一直在制作这些幻灯片，是的，这些数据管道服务于各种各样的应用，包括电子商务、自动驾驶、制造业、人力资源、生命科学等等。
每个数据管道内部都有一系列的步骤，包括摄入数据、转换数据、规范化数据、对数据进行训练、验证数据、对其进行推理，然后归档以备将来使用。这是一张很好的营销幻灯片，但这并不代表现实。
首先，这些步骤是迭代的。在验证过程中，你可能会意识到需要回到重新训练数据；在推理阶段，也可能需要同样的操作；在归档阶段，你实际上可能需要使用去年开发的训练模型和数据。你可能需要检索那些数据出于法律或合规的目的。因此，实际上，这些数据管道看起来更像是这样的。
在这些步骤之间，对于数据有不同的要求。每个步骤可能有不同的输入类型、不同的协议用于写入或写出数据，可能还有不同的性能配置文件。你可能需要快速访问低延迟的小文件，你可能有需要从中提取图像的高带宽。每一个这些步骤传统上都是以不同的方式处理的，无论是不同的文件系统，甚至是不同的存储类型来管理。对于每一个环节，你都需要复制数据。而这个“数据复制”引入了复杂性、人为错误和浪费时间。
Colin，这些数据集可能是数百TB，甚至可能是PB级别的数据，他们实际上在这个过程中复制了五次？
是的，我们确实是对的。
谁会复制五次PB级别的数据？
我们在最后会给你一些过去的客户的例子。用户实际上会这样做，而且这浪费时间，因为随着你从一个阶段移动到另一个阶段，你在进行这些复制时，你最终会有一个非常低效的数据管道。
他们不得不这样做，因为每个步骤的性能配置都不同，对吧？
是的，他们把它复制到特殊的性能存储中，他们可能复制它从某个地方到HPC集群，他们可能复制到GPU Farm内的本地存储，以便更快地访问它，然后他们需要复制下一个数据集并替换它。所以这变成了一个不断移动这些数据副本的持续挑战。现在这是我们称之为数据停滞的原因，因为在你移动所有这些数据的同时，你拖慢了整个管道。而且你制造了浪费，因为你创建了这些数据的多个副本，你不得不为此付出代价，而且每一个步骤也是如此。
我们在WEKA所做的是为所有这些步骤提供一个单一的数据平台，涵盖服务所有这些步骤。我们需要进行数据摄取、ETL（抽取、转换、加载）、训练、验证、推理或归档，这是一个数据管道，它只有一个数据副本。例如，在摄取阶段，你从S3中带入的数据，我们可以立即提供给POSIX客户端，用于进行必要的训练，或者你可以将其传送回S3，以在对象存储上进行归档存储，并以这种方式进行清理。我们将在之后的演讲中更详细地介绍这是如何运作的。我们解决了所有这些问题，解决了所有这些数据移动的问题。
Ray，你提到的实际上是我们一位非常大的客户的实际环境，他们正在进行这样的数据移动。他们从传感器中提取数据，将其存储在NAS存储中，然后将其复制到HPC集群，从中使用数据来供应他们的HPC GPU。然后，他们不得不将这些数据移动并提取到一个长期的数据湖中进行临时存储，最终将其移动到磁带服务以进行备份和归档，因为他们需要在法律问题出现时使用这些数据。此外，他们还在环境中的其他地方保留了一个灾难恢复（DR）副本。
当我向客户展示这张幻灯片时，这是一种恍然大悟的感觉，他们会说是的，那是我的环境，我今天确实在做所有这些工作，以完成我的AI工作负载。我们所做的是提供一个可以服务于所有这些工作负载的单一数据平台，消除所有复制，消除所有调优，因为每个存储配置都需要分别调优，以能够服务于不同工作负载的性能配置文件。我们消除了所有这些基础架构集群和基础架构集群，极大地加速了数据管道。研究表明，在将数据传送到GPU之前，平均有70%的工作在一个epoch内完成。
现在我们称自己为AI数据平台，我们相信这个数据平台对其他工作负载也非常有用。
我们始于数据中心核心，正如我之前提到的，我们还在云中提供服务。我们在AWS中以完全容器化的微服务工作负载运行，已经运行了多年。我们还在考虑进入近端部署，所以未来请期待这一点。我们在科学计算和HPC工作负载方面表现得非常好。今天我们是一个专注于AI和数据管道的公司，最终，一个成熟的数据平台也可以为其他用途提供服务，所以请在未来关注我们，看我们是否还会进入容器、微服务和DevOps环境，并进入数据湖和其他形式的数据存储，我们相信这也将带来传统价值。最后，显然，一个数据平台可以在需要时为传统企业工作负载提供全套强大的能力。
通用数据系统。这是不可能的，特定工作负载需要太多的调优。你们怎么能做到这一切？
我们还没有看到这是如何做到的。老实说，这取决于你们所有的文件，我们以非常随机的顺序执行，听起来像是Dr. Seuss的小文件。但确实，有趣的是，当我在这里尝试时，我也有同样的想法，我说这是不可能的，一切都必须进行调优。答案是，如果你正确地开发了架构，如果你正确地进行了优化，并且你拥有今天的技术，我是说当存储阵列被开发时，它们是为在阵列内进行写而进行优化的。你会尽一切努力避免跨越阵列到其他地方，因为你会尽一切努力在缓存中完成，因为去磁盘太慢了。而今天我们拥有的技术，包括闪存盘、NVMe高性能网络，使我们能够重新思考这一范式，并真正专注于开发正确的架构，正如Joel将在接下来讨论的。
你实际上可以服务小文件、大文件、任何文件、无文件，以一种高效的方式。但再次强调，这是一个乌托邦的愿景，但如果你能够努力实现它，就必须制定一个乌托邦的愿景。我们已经看到，我们确实有一些客户正在使用WEKA平台运行数据库工作负载，并且运行得非常好。尽管这不是我们最初为他们销售的目的，我们最初为解决这些问题而销售。但他们决定在平台上运行它，并且运行得很好。是的，它奏效了。可能还有其他一些功能我们需要完善，以充分发展这个生态系统，我们也意识到这一点，但我们相信这项技术具有巨大的、深刻的力量，可以在企业中实现一种全新的数据管理方式。
构建WEKA解决方案的框架：为何统一的数据平台对于优化AI工作负载至关重要
介绍：
对于像AI/ML这样的下一代工作负载，要推动业务转型或进行研究创新的下一个飞跃，它们需要能够实现更多。AI可以支持企业规模的需求 - 如果有数据的话。但是，如果没有一个高度可扩展的现代数据平台，无法快速处理海量数据并满足AI苛刻的性能要求，那么它将无法充分发挥其全部承诺和潜力。
在这个环节中，Shimon Ben-David将讨论为什么WEKA决定构建一个现代化的数据平台框架，以及它如何为希望在其AI和ML部署中实现市场首创成果的组织提供关键支持。
演讲内容：
我是Shimon Ben-David，WEKA的首席技术官。
首先，我想从AI开始，让我们先讨论一下AI的工作负载，然后深入探讨它们与存储环境的关系，以及它们与存储I/O如何关联。正如我们从David和Colin那里听到的，实际上我们在AI客户方面有很长时间的经验，可以追溯到公司早期，当时硬件甚至还没有准备好应对这些庞大的AI项目。如今，我们看到一些全球最大的AI项目实际上正在运行在WEKA上。让我们稍微谈一下AI环境，然后我们将转向存储方面，讨论WEKA如何促进这一过程以及我们的不公平优势。
当我们审视人工智能所面临的挑战时，显而易见的是，现在有了这些加速器。NVIDIA在市场上占据了很大的份额，它们已经超越了摩尔定律的限制，实现了成千上万的核心并行运算。此外，还有许多新的加速器问世，比如Graphcore的Ripper。实际上，我们与很多这样的公司在一些联合项目上都展开了合作。在计算领域，我们取得了巨大的进步，计算能力也得到了显著提升。
此外，我认为在过去几年中，我们看到了ML应用环境方面的很多进展，协调环境运行着分布式AI工作负载，底层运行的是Kubernetes集群，因为在现代AI中，一切都是容器化的，所以在这方面有很多进展。
那么，我们正在问自己：存储和数据平台对AI是否相关，它们是否需要适应AI？我们当前拥有的和以往拥有的可能已经足够了，对吗？
我想简要介绍一下Colin提到的流程，并在AI流程的一些步骤中讨论挑战，显然这与数据平台和存储环境有关。首先，让我们看看数据摄取。所有的数据流程都始于摄取，因为AI需要大量的数据，从小型AI环境开始，甚至是双位数的TB也算不上很大。但是随着其成熟，从运营的第二天、第三天、第四天开始，您需要增加所需的计算资源和数据量。
显然有这样一个概念，即数据就是代码，如果我可以提供大量的数据给模型，显然它会比数据量较小的模型更好。因此，我需要将大量数据引入我的环境。这些数据通常来自于全球范围的成熟环境，所以现在您需要从许多传感器、边缘位置的自动驾驶汽车、录音等地积累数据，然后将数据移动到一个环境中。也许有一些边缘训练，但主要的推理是在边缘完成的，而训练则在某个核心位置完成。因此，您需要将数据从多个地理位置移动到一个集中的环境，这本身就是一项复杂的任务，因为如果我每小时收集数TB的数据，现在我需要将这些数据集中起来，我如何将这些数据移动到集中的位置，涉及到规则、法规，以及在移动数据时的实际可行性。当我将数据移动到摄取时，我还希望对其进行丰富处理，有时候需要标记。因此，摄取部分需要处理的已经是一个挑战。
接下来，我们转向我们所谓的预处理阶段。在这个环节，预处理实际上是AI中最为人熟知的秘密。让我们花一点时间来谈谈这个阶段，可能占据了训练epoch时间的50%，甚至更多，这个时间可能还算宽松。预处理实际上是一个阶段，在这个阶段中，我们处理数据，数据科学家需要处理数据，以便他们的AI模型能够适应。例如，如果我不是处理图像，我需要调整图像的大小，每个模型或每个数据科学家都期望他们的图像具有特定的大小，不同的颜色校正，对比度等等。
因此，每位数据科学家现在都以不同的方式对其数据进行预处理。这是一项巨大的挑战，因为在这段时间内，数据甚至还没有到达GPU。我们将不断讨论GPU工作负载和加速工作负载，这令人困惑，因为很多AI工作负载、很多训练工作的时间实际上都在到达GPU之前。
此处，我们看到在一个组织内存在巨大的变化，因此您会看到多个组织以不同的方式对数据进行预处理。更复杂的是，即使在一个组织内，数据也以不同的方式被处理。可能我有多个原始图像，您可能会问关于复制数据和增加数据的问题，可能我有多个原始图像或原始数据，现在我有10名数据科学家，每个人都会以他们自己的有效方式对数据进行预处理，这会与他们期望看到的方式相关。
实际上，我们已经讨论了I/O的影响，因为我们确实希望将其与存储最终连接起来，或者说与数据平台连接起来。其影响实际上是非常巨大的。有大量的读取和写入数据，对数据平台进行大量的读取和写入，根据定义，这是一个写缓存未命中，因为您需要将数据写入稳定存储，需要大量读取数据，然后将其预处理后再写回稳定存储，再次进行大量的读取和写入。
大部分的AI活动实际上是在组织内发生，或者发生在像组或孤立的团队中。因此，一个团队可能正在为特定应用程序的特定模型进行工作，另一个团队可能使用相同的数据为另一个模型进行工作，针对不同的方面。
确实，我们看到不同组织的工作方式不同，通常存在合作，通常您会看到不同的团队为相同的数据以不同的结果进行工作。这些都与一个组织有多少AI项目有关。
确切地说，每个项目的预处理都必然不同。
这是巨大的挑战，这甚至在您到达GPU之前，您的高工作负载、读写变化就已经发生了。
这种情况是否有像特征存储这样的东西适应到这个框架中？
特征存储最终与训练部分有关，因为在训练数据时，您希望连接到特征存储并理解您试图查看的内容。但它还没有达到这个状态
它在预处理之后的某个步骤？
是的。更多地是在训练部分。
我们已经讨论了预处理，现在我想展示一些例子，虽然是非常简化的例子，但我认为它们能传达出I/O模式或训练模型步骤的信息。
我们将从一个小数据集开始，然后转向一个更大的数据集，以及它的形式，因为我认为有这样一种观念，即有时我们现有的存储足够，甚至以往的存储也足够了，为什么我们需要对其进行改进呢？所以让我们看一个小数据集，就像你知道的，GPU服务器上有多个GPU，每个GPU都有一定的高带宽内存（HBM）。
那么，一个小数据集的训练模型是什么样子的，然后让我们专注于单个GPU服务器。显然，我们将从预处理开始，我现在将我的数据读入服务器内存，进入服务器的RAM，甚至不是GPU的内存，我会读取数据，执行预处理，裁剪图像，调整对比度，按需要更改像素，例如计算机视觉，然后我将其写回稳定存储，这已经花费了一些时间。然后我再次读取预处理后的数据，因为我已经遍历了我的数据集，我会再次重新读取，现在我也将其读取到GPU内存中，现在我将数据加载到GPU内存中，由于这是一个小数据集的例子，数据可以适配GPU内存。
现在我可以在数据上进行训练，我在数据上运行我的模型，数据在GPU内存中，一切正常，也许我有一些输出正在保存，然后我重复这个过程，因为我的一些超参数也会说出我需要从我的数据中提取多少个epoch以及准确性等等。所以我只是重复这个过程，而数据在内存中，也许我还会在内存中对数据进行打乱，这样我不总是在同一时间读取它，这是一个确保性措施。但是它在我的内存中。
那么好处在哪里，缺点在哪里呢？小数据集可以适应GPU内存，因此它们实际上几乎消除了存储延迟，因为现在我已经将一切都加载到内存中了，存储就不太相关了。但正如我们所看到的，小数据集的预处理仍然需要读写数据，因此我无法避免需要进行的预处理，这是一个存储工作负载。即使我的数据在内存中，在许多情况下，我仍然需要进行元数据操作，通过文件进行打乱，获取属性，它们并非全部都被缓存。
Ray，在您之前提到的关于不断复制大量数据的问题，复制并不总是主动的。有时复制是在中心的NAS环境上进行的，而我现在正在处理这些数据，复制实际上是在GPU服务器的本地NVMe上缓存数据。有时它实际上只是直接复制，但有时它是作为结果进行缓存的。
在小数据集中，我会说仍然存在存储的重要性，但在较大的数据集上，某些情况下可以消除一些。嘿，现在我的AI实践工作增加了一点，我需要处理更多的数据，也许我仍然只有一个GPU服务器，但现在基本上一切都是一样的，和以前一样，我需要读取我的数据，需要对其进行预处理，我需要将其读入RAM，加载到GPU中，但现在我的GPU内存不够了，因为这是一个较大的数据集，我需要对数据进行训练。
因此，我们看到客户实际上正在使用双缓冲机制。你看一下GPU内存，显然包含你的模型和参数，然后你拿出其中剩下的一部分，就像你把它分成两半，然后你加载数据到其中的一半，同时你在训练，加载更多的数据，训练进行时。所以你实际上正在尝试创建一个缓冲区，通过在小数据子集上进行训练来消除存储，因此有这个双缓冲的机制。
最终，你又想运行几个epoch，所以你对数据进行打乱，重新训练，优缺点是什么呢？较大的数据集无法适应GPU内存，因为它们太大了，双缓冲会试图跟上读取，因为它会尝试这样做，这有点尽力而为力，它依赖于加速不够快，而快速读取到GPU内存需要多长时间，有时是真的，有时不是。
但我们面临与之前相同的问题，较大的数据集预处理仍然需要读取这些较大的数据集进行预处理，进行大规模的元数据操作，浏览数十亿或数十亿的文件。
在我过去进行训练时，它主要是在Python循环中，有效地处理从直接存储或类似的实时读取的数据批次，所以当你谈到将数据移入GPU时，我是在批量处理的情况下完成的，所以我只是在努力理解所有这些是如何发挥作用的，你提到了双缓冲，我试图想象它在这个领域中的实际应用。
最终GPU将对其自身内存中的数据进行计算，甚至不在服务器内存中而是在其自身内存中，因此你需要将数据加载到GPU内存中，也许你有多个GPU并进行分布，因此我们可以将其看作是一个大内存在一个大的GPU中。双缓冲的作用是在这里发挥作用，想象一下你正在将数据从存储中读入GPU内存，现在你正在运行训练作业，你完成了一个批次，因为显然你不会在所有数据上进行训练，你的模型能够接受的是有限的，所以你完成了这个批次，现在你需要带更多的数据。
基本上在你从存储中提取数据的那个时刻，你正在依赖于存储，因此存储越快，你等待的时间就越短，那里你的GPU是空闲的。双缓冲率只是回答你的问题？双缓冲是计算机科学中的一种方法，说嘿，我不会在一个大批次上进行训练，而是在一个较小的批次上进行训练，而在我训练的同时，我正在从我的存储中复制。因此从本质上讲，我正在限制我的训练。
我理解这个逻辑。对于更多的了解，我只是试图理解这在实际应用中是如何运作的。
我将展示WEKA并不需要这样做。
那么，让我们进一步复杂化问题，看看真实环境下的情况。在真实环境中，你在服务器上运行，运行在一个容器化的环境中，你运行多个训练管道，它们并不一定完全在同一地方。也许这个人在进行训练，那个人在进行推理，这个人在进行预处理。因此，你甚至不能依赖于任何东西真的匹配在GPU内存或CPU内存上完全专用于那个作业。因此，多个作业在并发运行，处于不同的阶段，拥有较重或较轻的负担。
关于问题的最后一张幻灯片，让我们进一步复杂化。现在你有，让我们看看SuperPOD的配置，其中我们有数百或数千个GPU服务器，正如我们与一些客户看到的那样，它们每一个都在复杂化这个问题，所以这是一个真正的问题，我们如何解决它，如何帮助你，这是一个大问题。
因此，让我们看一下I/O模式，我认为这是你们关心的。这是来自TensorFlow在ImageNet上的一个真实例子。你可以看到，与数据加载相比，元数据加载是巨大的。在这种情况下，它只是展示了打开数，但是如果我们看整个管道，我们也看到了很多统计数据，显然有很多查找，因为你要处理数百万个文件，所以元数据加载非常重要。同时，如果你看I/O模式，会发现有很多小文件。
有这样一种观念，即在AI中只处理大文件，这在某种情况下是正确的，如果你使用TFRecord并将大量数据聚合到较大的文件中，你会得到较大的文件工作负载。但是如果你处理一些AI工作负载，例如原始图像或文本，你将使用大量小文件。因此，你绝对需要一个环境，我正在为WEKA的解决方案做铺垫，这个环境必须能够处理大规模的元数据、大规模的IOPS和大规模的小文件。WEKA就是这样的环境，这是我们解决这个问题的方式。那么，看一下WEKA环境，我们是如何做到这一点的。
你说大部分数据都是在100字节以下，是这么看的吗？
在这种情况下，在ImageNet上是的。
底部的图显示是I/O活动，按块大小划分的？
是的。
因此，当你进行训练时，即使在ImageNet上，你也会有很多与之相关的标签。因此，想象一下，不完全正确，我认为元数据可能是与标签分开的，但是想象一下你有一个目标检测器，你知道我们将查看这个场景，我们得到了一个注释，这是一个人，那是一个人，那是一个人，这是一张桌子……
David，有80,000个100字节的I/O，只有40,000个100K字节的I/O？
不，但是如果你看一个目标检测数据集，你每个图像会有很多标签，如果你看其他类型的视觉，比如分割，你会为每个像素分配一个对象，你知道一个像素会是32字节。
我认为它代表了一个使用案例。我们如何解决这个问题，我试图说服每个人，真正的AI工作负载有一些不同的要求，WEKA是如何解决它的，现在我们可以讨论“秘诀”，我们如何做到这一点。首先，正如David提到的，WEKA完全是软件定义的，或者正如我们的首席执行官所说的，如果你把工作倒过来检查一下，没有服务器会倒下，这确实意味着我们可以在本地和云中轻松运行，事实上，我们在云中看到了AI的应用，实际上，Efraim会谈论这个话题。我们支持多协议环境，正如Colin提到的，所有数据都可以通过所有协议访问，所以现在如果我通过多个传感器或范围通过S3或SMB或NFS进行数据摄取，我们看到一些客户在做这样的事情，你不需要为了协议兼容性而移动数据到另一个存储环境，你将其摄取到WEKA中，然后在高性能方式下处理这些数据，所以这本身就消除了训练工作通常需要花费的很多时间。
我们还具备扩展我们命名空间的能力，能够在快闪存和对象存储之间进行扩展，甚至在发送数据方面也能实现。因此，如果我们回到摄取阶段时讨论的是从边缘到核心的问题，我们也能够灵活地发送数据。
我们看到客户建立了边缘存储环境，实际上是从他们的本地位置收集数据，并能够将数据发送到一个集中的WEKA集群进行训练。WEKA负责数据移动，因此我们可以有效地管理EB级别的数据移动。我们解决了这个问题，现在转向下一个问题。
很多客户收集了PB级别的数据，但他们并没有同时处理PB级别的数据。那么WEKA是如何在处理中既经济高效又性能高效的呢？
太好了，正如之前提到的，WEKA具备这个能力。去年我们做了一些工作，我们将讨论我们是如何实现这一点的。
它还具有在WEKA快闪存层和对象存储之间虚拟化容量的能力，可以在同一数据中心或多个数据中心中具有一个或多个。实际上，我们看到了巨大的兴趣。我将用一个实际客户的例子来说明。这个客户有3PB的快闪存层和100PB的对象存储。所以现在我们正在虚拟化这个容量，并展现那100PB。因此，显然，如果你看这个解决方案的经济性，100PB对象存储的经济性非常便宜，以及3PB的WEKA快闪存层的经济性。
顺便说一下，当我们不断比较价格时，我不是销售人员，但是在这个团队上，我们非常具有成本效益。WEKA为你提供了这种聚合所有数据的能力，WEKA是实现这种虚拟化容量的关键，你只需使用WEKA进行工作，不需要尝试在WEKA和对象存储之间移动数据，只需通过WEKA进行工作。
是的，如果我理解正确，你之前提到了一个问题，关于如何从磁带转移到热存储。我认为你的观点包括，在磁带系统上，可以有一个WEKA内核模块驻留，同时有一个客户端。这样的设置可以抽象出性能和容量上的权衡，无论是在磁带、阵列、快闪存还是云中的某个存储设备。
WEKA以一种虚拟化这些不同存储层的方式运作，用户只需与WEKA通信。接下来，我们将讨论当数据在这里时，经过WEKA加速的方式。但总体上，用户只需通过WEKA工作，WEKA会负责发送数据，无论是到本地对象存储、云对象存储，还是一个支持S3的磁带库。顺便提一下，我们还有一些正在研究的用例。
整个问题的关键在于，我认为Frederic提到的经济和性能问题，都要经过WEKA进行，数据在虚拟化容量之间流动。
但元数据又在哪里呢？
这是一个很好的问题。让我先说点内容，然后问题就会显而易见。
我们所做的是，在这张幻灯片上，我想展示的是你看不到的东西。你看不到的有JBOD、JBOF、RAID控制器、UPS、SCM，不同的协议网关，以及不同的NVMe Fabric，因为这些并不在用户视野内，它们是不需要被关心的。我们实际上是在分发这些任务，也许我可以展示一下这张幻灯片，展示我们正在如何按比例扩展数据和元数据。这其中有很多我们的秘密，其中之一是我们实际上是在所有存储节点上进行元数据的扩展。可以想象一下，在这个环境中，可能有10台服务器，20台服务器，或者甚至可能有1000台服务器。我们所做的是在每个服务器上运行服务，运行多个CPU核心，实际上运行着多个虚拟元数据服务器。所以即使在小规模环境中，WEKA可以从6个节点开始，适用于你的AI环境的起始阶段，然后可以扩展到数千个节点。实际上，我们正在运行数千个虚拟元数据服务器，它们分布在所有存储节点上。
从统计数据上看，我们将命名空间分成了数千个小块。每个虚拟元数据服务器处理其命名空间的相应部分。例如，假设有1000个虚拟元数据服务器运行在10台服务器上，每台服务器有100个CPU核心。在WEKA环境中，如果你写入1000个文件，从统计数据上看，每个文件都会由其中一个虚拟元数据服务器处理。因此，没有单一的元数据服务器，没有限制元数据服务器的数量。整个环境以真正的扩展形式提供元数据，而且整个环境是完全均衡的。没有一个I/O模式会影响一个元数据服务器而不影响其他服务器。因为当你访问不同的文件时，你会访问不同的虚拟元数据服务器。更妙的是，即使你访问单个文件并且以不同的块范围进行访问，每8MB也由不同的虚拟元数据服务器处理。
这在HPC领域非常重要，例如在进行检查点时，可能有数千个核心同时检查点到一个单一文件。我们解决了这个问题，因为我们所做的是，这些数千个核心不会集中攻击一个元数据服务器或一小部分元数据服务器。相反，它们将与所有的CPU一起工作，以提供元数据。这是一个真正的元数据扩展。底层有很多东西，但通常很难扩展元数据，因为有东西向流量。如果我有数千个虚拟元数据服务器，其中一个失败了，我们需要是有韧性的，这样其他人才能继续他们停下的地方。我们所做的是运行这些数千个虚拟元数据服务器，它们之间没有东西向流量。因此，你可以基本上不断扩展，添加更多，而不会出现递减的结果。
我们实际上将它们用作块层的日志位置。因此，假设我有一台服务器，它运行了100个虚拟元数据服务器，其中一个失败了。那么我的其他10台或100台服务器现在需要决定谁来接手。它们会简单地分配新的虚拟元数据服务器，每个服务器都会去替代它们已知的日志位置，并继续向前推进。所以这是一个真正的元数据扩展。
我们是如何将元数据切片的呢？你是说每个这样的元数据服务器，比如虚拟元数据服务器，只控制文件命名空间的一部分，对吧？
是的。
所以我们是如何实现这一点的呢？我们使用了一个哈希环，它是根据名称进行计算的，然后通过名称和文件中的LBA进行计算。所以涉及到iNode和范围，这都是通过计算完成的，没有表，因为内存中的表会导致无法扩展。它只是基于计算，因此一个需要与文件通信的客户端会说：“嘿，我需要那个iNode，我正在计算，我知道谁拥有它，有很高的概率是那个虚拟元数据拥有它。然后它会去协调I/O。如果不是，那个虚拟元数据服务器会说：“嘿，那是下一个”。所以内存中没有表，没有查找。这是一种非常简单的计算，以了解我需要去哪里。这就是我们分片元数据的方式，再次强调这是在文件，甚至是文件内的块范围。所以这是庞大的。如果你看我们所有的基准测试，如果你与我们的客户交流，你会发现元数据的性能非常惊人，速度快。
让我们回到之前的话题。我也提到了扩展数据不仅仅是元数据。所以即使我只是在处理一个文件，我们从不具有数据的局部性，这是非常重要的。因为我认为对你的问题的答案是，我们如何做到这一切的，是因为网络现在不再是瓶颈了。过去，网络是1G、10G、25G，而现在是100G、200G、400G，或者是同等速度的InfiniBand。我们所做的是即使是一个单一的文件，当我写一个单一的文件，让我们以1MB为例，我们将该文件分成多个4K的片段，并在所有故障域、所有NVMe之间进行条带化和保护这些4K片段。所以如果我有10台服务器，每台服务器有10个NVMe，那么现在我将1MB分解成多个条带。因此我们不进行镜像，我们不进行复制，实际上我们使用我们自己的纠删码进行纠删。因为纠删码有点像，你想要加速它，所以我们有很多事情可以做来加速我们自己的纠删码。
因此，数据最终被条带化到环境中的4K片段。所以如果客户说：“嘿，我写了一个1000MB的文件，这相当于256,000个4K片段”，我们将检索它。如果需要读取那个1000MB的文件，我们将并行读取所有的片段，跨足环境中的所有节点。如果现在客户或客户端说：“我只需要文件中的4K、8K或60K，因为我们的块大小只有4K”，我们将只检索这些4K。现在，与传统架构相比，传统架构中的块大小大多适应于机械硬盘，所以你必须使用大块大小。所以现在如果你现在需要读取4K，你实际上需要读取1MB或128MB。这就是为什么传统环境在IOPS和吞吐量方面正在努力，而与WEKA一起，我们并不会，因为一切都是4K。因此，我们扩展了元数据，扩展了数据。在这里我们正在进行许多更智能的操作，绕过内核，进行我们自己的线程调度，工作在用户空间，实际上是容器化的。这实际上允许我们在需要时与应用程序一起在相同的GPU服务器上运行，或者充当远程专用环境。我们甚至编写了我们自己的网络协议，它看起来像普通的IP，但实际上它是你自己的协议的顶层。
最终，我们可以讨论技术和我们如何做事情，这很好，我很乐意更详细地阐述。但最终问题是，价值在哪里？价值实际上是让客户运行更多的训练epoch，缩短他们的训练作业的实际时间。我们从实际客户案例中获得的一张著名的幻灯片是，一个庞大的AI项目转移到了WEKA环境，他们的训练作业从两周缩短到四小时。这就是我们所做的，从两周到四小时，这就是价值。显然，这表明他们有一些I/O问题，否则它就不会加速，加速了84倍。例如，我们展示了SPEC AI基准测试等等，这同样适用于其他市场，我们加速了整体数据。
WEKA客户案例：将科幻变为科学事实
介绍：
WEKA公司协助组织克服下一代工作负载的性能、规模和数据管理挑战，推动其关键业务计划和研究项目取得进展。
在这个对话中，Efraim Grynberg将分享真实的WEKA客户案例，这些客户正在利用WEKA数据平台实现其AI（AI）和ML（ML）方面的市场领先成果。
演讲内容：
我是WEKA公司全球销售工程高级总监，Efraim Grynberg。
我将讨论我们的客户，再次强调我们所探讨的是WEKA为AI提供的数据平台。今天我想分享一些我们的客户以及使用案例。
在我详细介绍之前，我想先分享一些最近在我职责范围内发生的事情，即人们经常问我为什么喜欢在WEKA工作。原因很简单，人们对我们非常感兴趣。我的回答有三个方面，前两个方面很容易理解。首先，当我考虑加入一家公司时，我寻找卓越的技术、卓越的产品和卓越的愿景，还有一个领导团队，他们有这个愿景，并愿意尝试新的事物。第三个方面我在加入WEKA时并没有预料到，实际上是我更为喜欢的部分，那就是我们的客户。我们使我们的客户能够实现一些他们以前认为无法实现的事情，他们想做但不知如何着手，因为存在所有这些数据迁移问题、可扩展性问题等等。现在，我们的客户正在推动他们所从事领域的极限。我在工作中有幸收到这些最高级工程师、数据科学家和一般科学家的小论文，了解他们如何看待解决新问题，这正是我想要分享的。
我选择了三个使用案例或三个客户，选择这些客户的原因是因为它们都是与AI相关的使用案例，而且这些使用案例今天正在生产中，它们正在为客户带来商业价值和业务影响结果，而不仅仅是研究模式，也许将在五年后才能看到成果。
第一个案例是关于智能制造，制造在一般情况下可能听起来很普通，但实际上当你涉及到复杂的流程时，它可能会变得非常有趣。我想要介绍的是液晶显示屏的制造过程，这实际上是我们今天正在生产中的一个真实项目。在我们深入讨论如何解决所有这些问题之前，让我先简要解释一下液晶显示屏的工作原理。如果你还没见过液晶显示屏，它有几个层次，包括一个像素层、一个背光层以及其他一些我不记得的层次，但其中一个是玻璃层，通常被认为是底部，但实际上当我们有液晶显示屏时我们触摸的就是这个玻璃层。
这个制造过程与晶圆的概念非常相似，与便宜的制造相似。首先，有一个最新一代的概念，即母玻璃，尺寸为九英尺乘九英尺。LCD屏幕是从这个母玻璃上切割出来的。这个母玻璃必须非常干净，需要在非常洁净的环境下进行，因此实际上使用的环境非常类似于芯片制造时的环境。这些机器非常昂贵，因此建造这些LCD屏幕的制造工厂需要数十亿美元的投资。为了最大化这些投资的可预测性，确保供应链畅通，同时确保履行合同并及时为客户提供服务，这对公司至关重要。此外，用于生产这些不同层次的材料非常昂贵，因此希望产生的浪费要尽量减少。
今天公司正在使用WEKA等GPU服务器对玻璃进行视觉检查，检查切割前后的任何缺陷。在这种情况下，我们谈论每小时需要对这家客户的庞大制造计划进行170万张图片的可视化检查，同时对每个像素进行质量分析和质量保证。在切割玻璃之前，他们需要检查是否有缺陷；切割后，他们还需要检查是否有引起的缺陷。因此，需要不断进行视觉检查和处理数据，但这与AI无关，即使他们正在使用GPU工作负载来执行这些操作。
顺便说一下，他们想要做的其中一件事，对我来说至少是有趣的，就是如果他们看到任何缺陷，他们将重新调整玻璃或切割机的角度，以确保充分利用剩余的玻璃。问题在于，如果在处理或玻璃上引入缺陷，他们会在事后发现这一点，要么在终止产品上，要么在其中一次检查中，可能需要数小时或数天才能真正了解有问题。有很多浪费和时间浪费。
那么我们应该如何做，我们应该如何帮助或者这家公司是如何尝试说，让我们预测是否存在缺陷。我们所讨论的每一台机器都有很多传感器，每个传感器都与其他传感器不同，例如电源传感器、振动传感器、温度传感器、运动传感器、机械传感器等。这些都是用于发出警报的数据，例如电源问题、运动问题的机械故障，但这只有在问题发生时才会被发现。其中一个传感器每毫秒采样一次，这是一大量的数据。
如果我们能提前获取所有数据，或者收集所有数据，创建一个AI模型来分析是否存在异常或趋势变化，然后我们实际上可以预测是否会有机器在发生之前引入缺陷，甚至是两周前，我可以更换零件而不会发生任何事情。因此，我们开始了解机器或机器的一部分在真正发生故障或引入缺陷之前将会失败，这节省了大量的资金。这家公司实际上正在做的就是这个。
但是，困难之处在于如何分析，谁会移动1PB或PB以上的数据，它们在图像和不同传感器之间有大约1PB的数据需要处理，它们需要将所有数据引入某种中央库，实际上是WEKA数据平台，他们需要实时引入数据、传输数据、分析数据，然后将该数据暴露给一个仪表板，以了解是否存在故障。
如果我理解正确，你说的是每小时约1TB的数据？
是的，包括图像、传感器数据等，总质量约为300GB/s。
但这不仅是有趣的事情，这些传感器产生不同类型的数据，每个传感器都有不同类型的文件，它们通过S3摄取数据，直接进入WEKA进行在线转换。然后实时处理和分析，然后传送到仪表板，每一个这样的循环每15分钟发生一次。每15分钟我们都在刷新仪表板，同时在分析数据的同时，我们也在转换新数据和摄取数据。所有这些过程都在持续进行。
现在你可能会说，我们需要大量的闪存，我们需要大量的CPU核心，但事实是，对于这家公司来说，能够在问题真正发生之前处理数据并了解这一点，可以节省大量的资金。业务结果是清晰的，对于这家公司来说是切实可行的。
有一个关于这个循环中的一个问题，因为我们之前讨论过管道有很多阶段，有很多数据复制等等。在这个例子中，他们似乎更倾向于批处理还是实时流处理？
他们正在使用实时流处理。从I/O的角度来看，这种在线的流处理是发生在同一种数据存储库和数据平台中的，你在转换、分析和暴露数据，这并不是从一个地方移到另一个地方。如果想象一下，在使用WEKA之前，每次他们需要将数据移到不同的地方。
之前训练已经完成，这更像是在制造线上实时进行推理，以确定一块板是否有缺陷或不。
但实际上可能不是推理，因为你可能无法立即消费一些数据。希望最终能够达到实时推理，但其中一些数据可能只是你在希望稍后进行分析的数据。
我假设所有这些数据都是用来训练QA代理，以确定是否存在缺陷。
最终是这样，已经有一个模型在使用，但实际上，他们正在不断地使用新数据重新训练，从过去的20天中持续获取新数据。所以不断地对模型进行再训练，使用新数据，因为在现场环境中事物会发生变化，这实际上是当前在生产中进行的事情，对我来说仍然非常令人印象深刻。
顺便说一下，再次强调管道的整体思想，你可以想象这个管道不是一个叠在另一个后面的，而是在同一个数据平台上有多个这样的管道。
让我们转到另一个用例，这是一个我可以谈论的用例，实际上所有的赞誉都应该归这些他们：Atomwise，如果你还不了解他们，你应该去读一下，因为他们非常有趣。
Atomwise目前可能不再是一个小公司，但他们是一家初创公司，他们认为他们现在很认真，他们募集了1.3亿美元，但这些数据可能有些不准确，但他们确实做得很好。他们的做法是应用AI模型来加速药物发现，你在屏幕上看到的是冠状病毒的蛋白质的3D建模。
他们的方法实际上是使用训练模型，一个深度神经网络，实际上非常类似于计算机视觉。所以，与其说“好吧，让我们试着识别像素，然后将边缘转化为脸部特征”，他们在蛋白质的3D建模中应用深度学习。他们创造了一个蛋白质，然后试图理解原子之间的关系，这些关系将告诉他们一些关于结合亲和力的事情，因为当你创造一种药物时，你想要创造一种能够与蛋白质结合并对该蛋白质产生作用的分子，以摧毁它，从而避免治愈你。
所以，当你尝试开始时，这个结合亲和力的过程是一个非常迭代的过程，有点类似于科学家在实验室里做的，可能需要数年、数月、数天的每一次迭代。所以他们实际上是在进行蛋白质的3D建模，并试图理解对他们想要作为药物生产的分子来说，什么样的结合会更好。而且，他们再次使用与图像识别相似的模型。
关于数据点有一个值得关注的点，他们有大约四千个蛋白质目标，每一个病毒可能有不同的蛋白质目标。对于每一个模型，他们实际上收集了1,500万个实验测量值，或者说这不是实验测量，因为这是建模，但这相当于实验测量。这一切都由非常非常小的文件表示，这不是图像，这是非常非常小的文件、向量等等。
有趣的一点是，当我们开始与他们交流时，实际上有关AI流程的讨论是成熟的。Atomwise作为一个非常小的初创公司开始，他们的训练数据集适应一个服务器，然后逐渐增长，增加了数据集，有了更多的项目，他们决定需要分布式计算、集群和文件系统，事情在一个GPU服务器或GPU上无法胜任。所以他们开始尝试不同的方法，尽管体积可能不是很大，但从一个地方移动到另一个地方的文件数量对他们来说非常困难，引起了巨大的麻烦。顺便说一下，他们在AWS中有很多DevOps，所有这些都在AWS上运行。
现在他们正试图在AWS中创建有限时间的超级计算，实际上他们正在旋转成千上万的GPU Spot实例，连接到一个相对较小的WEKA集群，你可以在联合演示的网络研讨会上了解更多信息，通过这样做，他们减少了从一个地方移动数据、创建这些实例等等所有那些事情所需的时间，对于每个项目来说，当他们开始使用WEKA创建这个模型时，这一切缩短到了一个星期。当然，这涉及到你能够多快地训练你的模型，但也涉及到你如何有效地管理你的数据循环，以便实际上缩短项目的时间。
现在你可以在YouTube上观看Atomwise的视频，他们在视频中表示，他们需要突然重新思考他们的业务方式，因为三个月的时间突然缩短到一周，他们可以完成的工作量显著增加。此外，前一个用例是在本地进行的，而这个用例是在云端进行的。使用WEKA，你可以在云端运行项目，实现你想做的任何事情。
尽管你在提到在玻璃中发现缺陷的例子和基因或细胞处理的例子时，给了我们一个总体的提升情况，但在管道的各个步骤中，你并没有详细介绍具体的改进措施，也没有解释WEKA如何帮助这个过程，除了提供一个总体的情况，说它变得更好了。
没有问题，实际上他们在这里所做的有点不同于典型的管道。首先，他们需要创建所有这些3D模型，因此需要大量计算来生成这些数据。虽然没有涉及到数据摄入的概念，但涉及到了数据的创建。这是一个非常密集的计算过程。现在他们可能希望基于这些模型进行多次训练。实际上，他们对文件系统进行了快照，然后将该快照上传到他们所说的对象存储或层。现在，他们将其保存为一个不同的项目。他们表示，他们希望为不同的项目和不同的实验多次复制这个蛋白质或模型的快照，并希望尝试不同的算法。实际上，可以启动该快照的不同副本，连接到许多GPU，因此现在他们可以并行处理工作，因为从你对该数据集的一个快照中，可以并行化正在进行的工作量。这有点不同，不是按行，而是数据平台允许你做的另一个特性。你不必复制所有数据，只需创建的快照。
好的，你刚刚的解释确实很有道理。直到你刚刚这样解释，这一点并不明显。
是的，而且还有一点，实际上所有这些都是容器化的，他们的工作方式是用这些东西。我们与AWS EKS直接集成，他们使用AWS的托管服务。这是另一个实际上为他们节省时间和管理工作的部分，因为他们更注重科学而不是IT或运维。
自动驾驶汽车是当今AI的终极目标，对吧？我们有几个客户正在进行AI/ML或自动驾驶方面的工作，实际上，我们不仅有进行自动驾驶汽车开发的客户，还有涉足卡车和甚至飞机自动驾驶的公司，包含各种功能。在训练方面，有两种方法用于自动驾驶车辆的训练或模型创建，一种是激光雷达，另一种是图像。
我想谈谈图像方面的问题，尤其是图像的规模问题。其中一个我们可以提到的参考客户是Tu Simple公司，他们主要进行卡车的自动驾驶研发，实际上他们主要使用相机而不是激光雷达传感器。举个例子，一辆汽车配备了8个相机，每个相机每秒产生20帧。虽然这些帧的质量并不是非常高，你不需要很高的清晰度来理解这是一棵树，但如果你考虑一辆车8个相机每小时产生的帧数，那将超过50万帧。这是一个巨大的规模，尤其对于那些自动驾驶是主营业务的公司来说，他们希望收集尽可能多的数据。他们从小规模开始，逐渐扩大，希望能够添加更多的计算资源。
这涉及到规模化，所以不仅要在计算上进行扩展，还要在容量上进行扩展，但随之而来的问题是性能的线性扩展。在训练中，你会进行大量的查找操作，即使在ImageNet中，我们也有非常小的文件。现在，元数据操作变得极其重要，如果你的集群无法在吞吐量、元数据和IOPS等所有性能维度上进行线性扩展，当你的数据不断增长时，你将会消耗元数据服务器。你需要一个可以持续扩展的系统。四年前我们与一家公司开始合作时，他们的数据集只有几PB，而今天我们有了数十PB，全部采用了闪存，用于训练和对所有数据集进行训练。这意味着它们产生了越来越多的元数据操作。在这个集群中，我们看到吞吐量约为1PB/s，同时进行数百万、甚至数千万的元数据操作。
因此，我在这里提到的是一个非常紧凑的时间框架，因为时间有限，但其中的思想是，如果作为一个公司成长和成熟，你的数据集变得更大，你的训练模型需要更准确。
关于你们服务的目标客户、市场推广的对象。我假设你不是在市场推广给那些每个月运行一次AI工作负载，只是一个核心系统的一部分的人，或者像我总是听说的那些零售商，他们每周或每月只进行一次情感分析，而且工作负载并不是那么大，所以他们可能只是使用他们已经拥有的系统。你能不能描述一下，你认为谁会对你的解决方案进行成本效益和风险分析，并且他们愿意把你的解决方案当作一种伟大的东西，他们想要应用你的解决方案，您认为这是解决方案的核心用户或人员？
首先，我们倾向于与在AI方面已经相对成熟的公司合作。那些刚开始涉足AI的人，他们已经全身心投入到他们的计算机中，但实际上在我与Atomwise的工作开始时，当时他们只有500万美元的创始资金，他们规模很小，但他们的业务基于AI建模，他们意识到他们很快就会遇到挫折的问题。因此，我们实际上是在一个非常早期的阶段与他们合作，但由于他们是一家业务完全基于AI建模的公司，对他们来说很容易理解我们需要解决的问题。
对于其他公司，当失败成为问题时，它进入到一个成熟的阶段。如果你只是在探索和起步，你可以在AWS上使用WEKA进行非常小的尝试，可能不会想要完整的本地安装，尽管我们看到那些开始探索AI的公司通常有大量的数据。无论如何，通常我们可以与他们不仅仅谈论AI，所以AI会随之而来，但如果你有大量的数据，而且你在高性能数据分析（HPDA）方面，那么分析工作也是一个很好的目标。
上周我正在与一家公司交谈，实际上我们正在帮助他们处理EDA工作负载，没有AI，但他们现在开始探索如何将AI应用于EDA，因为他们的容量和数据量正在激增，他们如何能够使其更加高效。因此，我们认为那些已经拥有大量数据的公司仍然是WEKA的一个很好的目标。因为我看到您所经历的问题陈述，您经历了一切从数据复制到任何类型的分析的管道，就像任何进行任何类型分析的人一样，已经对此进行了压缩，并停止了从摄取开始的所有数据移动等操作。
是的，我认为您对那些使用这种有问题、成本高昂的方式的人有一个很好的故事，很多时候他们可能有一个分析流程，现在刚刚开始添加ML，比如用于转换或其他数据丰富，我可以看到它既是AI解决方案，也是一般分析的解决方案。
是的，这是我们一个伟大的起点目标，特别是HPC。Colin谈到了这个管道，实际上在我们关注的4到6个大场景中，我们反复看到这样的情况，至少在这个方面非常相似。但我们今天讨论的是AI，所以我们专注在这一点上。
这很好，因为我发现那些进行这种迁移的公司，不是因为他们有意设计成这样，而是因为他们的工具在不同的系统中、甚至在不同的服务器机架中，他们正在移动数据，而不是解决管道问题。我认为今天听到的很多内容都是关于解决管道挑战的，几乎所有糟糕的设计都是因为没有人投资使其高效，直到它变得太昂贵，没有人关心性能，他们关心的是投资，然后他们会说我需要同时优化性能和成本。是的，谢谢，你描述得很好。
你早些时候谈到了近边缘解决方案，以及即将推出的一些东西，那么在近边缘环境中如何部署WEKA呢？
好的，很好的问题。这取决于边缘是如何的，如果你需要摄入数据或只是读取数据，但你可以使用混合模型。你可以在集中模型上部署一个巨大的WEKA，可以是在本地或云端，然后你可以在边缘有较小的WEKA部署。
这就是所谓的边缘计算，从主节点到边缘节点的部署？
通过我们的快照，你实际上可以将数据逐增地从一个地方移动到另一个地方，并重复这个过程。
实际上，你在边缘可以拥有一个小型的WEKA集群，而在中央存储库上拥有更大的集群。
这样的数据移动可以是从边缘到中央，也可以是从中央到边缘，具体取决于你的需求。
你还提到了SAP、SAS、Oracle等各种东西，它们如何与WEKA的解决方案整合呢？
是的，我们正在进行很多探索性的用例研究，实际上Shimon目前正在致力于为SAS提供解决方案，我将让他更好地回答这个问题。
即使SAS已经存在，它不仅仅是未来，它已经完成了，我们已经做了这项工作，我们验证了这些指标，我们实际上在这方面进行了工作，虽然今天谈的是AI，但你提到了SAS，所以SAS已经在我们已经涉足的多个市场中存在，包括金融、生命科学等等。
我们实际上运行了SAS的工作负载，运行了I/O加载程序，这是他们认为是SAS复杂工作负载的一部分。我们展示了惊人的价值，因为当你看我们正在做的性能特性时，首先在性能方面，SAS有一个关于每个运行SAS分析的CPU核需要多少兆字节的概念，他们要求每个核心150MB，而我们展示了500MB，这是惊人的，因为最终你运行SAS分析的速度提高了4倍。此外，我们还展示了可扩展性，因为当我们谈论WEKA时，不仅关注性能，还关注可扩展性，我们如何扩展集群，以便在相同性能下获得大容量，我们如何将SAS数据发送到云端并在云上运行SAS。
这已经实现了，我们实际上与HP的合作伙伴一起制作了这些内容，我们可以与您分享。这已经是完成了。
您在屏幕上有一个关于两个简单错误的7倍性能改进，与NFS相比，然后您突出了NVMe。我能问一下，也许有点深奥，这种类型的NVMe是传统的NAND，还是您发现使用QLC之类的技术带来了价值，或者只是测试而已？
就是普通的TLC和NVMe，你可以找到许多厂商在使用TLC，没有什么特别的。
---【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）