题目：A Practical Approach to Device-Level Analytical Offloads
演讲者：Donpaul Stephens, Founder and CEO, AirMettle, Inc.
会议：SNIA Compute, Memory, and Storage Summit
日期：2024年5月21日
我将与大家分享我们在实现设备级分析卸载方面所付出的努力。这一工作的背后，源于许多大型科学和商业用户所面临的挑战，特别是美国洛斯阿拉莫斯国家实验室（Los Alamos National Laboratory，LANL）。LANL以其在探索计算型存储以提升运营能力的努力而闻名，这似乎为他们和其他大型用户的问题提供了一种自然的解决方案。正如他们所指出的，他们的数据集通常达到数百PB甚至更多，而科学研究中的特征数据通常比原始数据小四到六个数量级。若能找到一种有效的实现方法，其影响将是巨大的。
回顾一下计算型存储的概念，它作为一个理念已经存在很长时间了。早在90年代我读研时，我们就讨论过将应用程序和工作迁移到数据所在位置的可能性。这看似是一个明确的趋势，预示着下一次的重大突破，但同时又仿佛遥不可及。为什么我们迟迟无法实现这一目标？真正的障碍是什么？为什么它没有被广泛采用并取代传统的数据分析方式？
换句话说，为什么大数据处理如此缓慢？即使我们拥有堪比大型表演艺术场馆或体育赛事规模的计算资源，操作仍需要耗费大量的时间。
问题的核心在于，我们将数据存储在一个地方，而分析却在另一个地方进行，这必然涉及到数据的移动。为什么会这样呢？原因在于我们为了可靠地存储数据而采用的庞大且廉价的组件集合。这种方法使得在这些数据上进行高效分析变得困难，甚至不可能。RAID和纠删码已经使用了几十年，但问题在于，尽管它们看起来简单——比如通过一个漂亮的异或（XOR）函数或复杂的树结构来确保数据即使丢失部分元素也能恢复——但实质上却并非如此。
假设我们有一些可靠存储的数据——以四个驱动器为例。这些驱动器具有固定且统一的大小。我们已经证明了这些算法对硬盘驱动器和其他存储设备是有效的。
但问题是，这些算法通常针对的是简单的数据，如CSV格式的表格。然而，在实际操作中，大数据往往以Parquet、Iceberg、netCDF4和HDF5等多维数据格式存在。这些复杂的、基于数组的数据结构需要按照特定的指针序列来找到数据的组成部分。
有人可能会认为，我们已经有软件可以解决这个问题，甚至已经通过开源代码找到了解决方案。理论上，我们可以在SSD内部重建一台计算机来处理这些复杂的数据结构。但实际操作起来却变得复杂且成本高昂。这些设备需要高度验证的固件来确保高质量和可预测的操作。追踪指针、管理内存等都是复杂的任务，调试也极其困难。对于设备固件来说，其质量门槛非常高。对于一块小小的SSD来说，管理这些复杂性是极具挑战性的。此外，处理复杂数据结构时，性能损失的风险也会增加。
尽管问题复杂，但我们仍需找到解决之道。我们认为这个问题就像一个错综复杂的“戈尔迪之结”（Gordian Knot）。为了解开这个结，我们采用了“奥卡姆剃刀”（Occam's Razor）原则，决定采取一种全新的、简洁的方法。这个方法包括几个关键步骤。
首先，我们必须保留数据的语义结构。当数据进入时，我们不是简单地对其进行索引，而是根据CSV、JSON、Parquet或netCDF4等基本记录类型来查看数据。我们寻找具有语义意义的元素，这些元素可以让我们对数据进行合理的划分或切割。
为了实现这一点，我们并不在完美的字节边界上切割数据。相反，我们寻找对象的底层元数据，这些元数据使我们能够理解可能需要的部分或子部分。这些关键元数据通常只占总数据量的0.1%，非常小，但它们基本上告诉我们哪些边界可以在未来进行处理。这实际上是一种分而治之的策略。
一旦我们以这种方式划分了数据，这些子组件中的每一个都可以独立并行处理。同时，我们也会存储一些全局对象级元数据，这些元数据虽然不需要在每个组件中计算，但对于我们作为一个存储系统来可靠地存储数据至关重要。如果你只是读取字节范围，它的工作原理就像一个传统的对象存储系统；但对于分析来说，它们都可以并行运行，从而大大提高了处理效率。
一旦我们在设备集群中启用这一功能，以实现一个健壮、可靠的存储服务，我们便可以真正深入探索驱动器内部。
接下来，驱动器的创新之处主要体现在其数据路径上。值得注意的是，我们在驱动器中并没有控制路径。我们认为，这正是计算型存储在数据分析中难以实施的核心问题之一。控制路径通常包含分支和复杂路径，而这些在硬实时操作系统中往往难以高效执行。我们的目标是尽可能地简化这些功能的实现，并最小化成本或设计复杂性。
这种方法将如何实施呢？我们称之为“检查和获取”（Check and Fetch）。这些操作完全基于用户级API，无需控制系统的介入。如果用户能够简单地读取数据，他们就可以通过一种高效的修改读取操作，来检索数据并执行检查。例如，对于浮点数据，如果你有一个64位的IEEE浮点数，并希望进行范围检查，你可以将这个64位的浮点字段缩减到一位。这一位可以表示结果：是或否，包含或不包含。同样地，对于获取操作，你可以使用密集编码的位字段来指定你想要返回的元素。这种语义用于检索数据，并以缓存行的形式返回，使处理器在数据到达时能够轻松使用。
这看起来极具潜力。让我们深入探讨一下这种方法如何应用于复杂数据类型。
以一个简单的选择查询为例，它是星型模式事件基准测试的一部分。在这个查询中，你选择了某些列，但只想要满足特定条件的数据。比如，你只对数量在11到20之间，且订单日期在2021年1月16日之前的元素感兴趣。
在Parquet格式中，每列的数据可能达到数兆字节。传统上，Parquet允许你只获取所需的列，但整个列的数据仍然需要从SSD传输到处理器的内存中。一旦数据到达，处理器就可以开始处理这些元素。
然而，如果我们能够在NVMe设备内部执行这些检查和获取操作，并利用类似CMB（控制器内存缓冲区）的机制，这实际上是一个位于SSD内部的主机控制内存区域。这样，你就可以在SSD内部执行检查操作，比如评估数量是否在范围内、查看日期并确定相关性，并结合这些位字段进行操作。这使你能够执行一系列复杂的操作，比如在这种情况下的SQL查询，并通过范围检查生成位字段，保存这些非常小的向量作为中间结果。一旦你有了这些结果，就可以将它们组合起来，确定你想要从这个庞大表格中提取的具体元素。
一旦确定了这些元素，这个位字段可以随后用于从每个相关列中仅检索那些元素。SSD不需要了解任何关于数据结构的信息；它不需要知道Parquet、NetCDF或HDF5是什么。这些操作具有广泛的适用性，可以应用于各种不同的应用场景。令人兴奋的是，这些简单的操作可以在主机控制下将复杂的SQL操作减少两个数量级，从而大大减少返回主机的数据量。这是一个巨大的减少，使得主机处理数据变得更加容易，因为返回的数据非常紧凑且正是主机所需要的，数据量减少了99%。
最后，我想说：“不要问你应该为存储做什么，而是问你的存储应该为你做什么。”
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/单位/关注领域）
