量化巨头 Jump Trading 如何围绕共享访问重构数据基础设施

在 2026 年 VAST  FWD 2026 全球技术大会上，当 Jump Trading 高性能计算系统工程师 Lucas Wojcik 登台演讲时，全场听众都全神贯注。外界很少有机会亲身了解，要搭建一套能够紧跟研究与市场节奏、支撑核心业务的超高速基础设施，需要具备怎样的条件。

Wojcik 向现场观众介绍，Jump Trading 的业务环境围绕持续、大规模的研究工作搭建，其基础设施需要支撑数千颗 CPU 与 GPU 运行，同时不能产生额外运行阻碍。“我们大量业务均为大规模部署。想要支撑大规模研究，需要诸多能力，包括自动化、架构灵活性、自助服务系统，以及持续优化的理念。其原因非常简单：如果架构不够灵活，就极易出现故障，而倘若没有实现自动化，仅凭人工操作难免会出现疏漏。”

他表示，这一需求标准也决定了 Jump Trading 对所有新系统的评估准则。

Wojcik 谈到，VAST Data 最初进入他们的视野，是因为其技术路线颠覆了传统高性能存储的设计模式。“我们当时听说，这家新兴厂商能够让 NFS 协议达到高性能计算级别性能，在当时这听起来天方夜谭。同时他们还提供低成本全闪存存储方案，这一点在当时业内很少有厂商能做到。” 在此之前，NFS 从未实现过如此高的性能，因此唯一可行的方式就是亲自实测验证。

Wojcik 和他的团队首先从标准基准测试开始，验证系统性能是否达标。“引入一项新技术时该做的测试我们都做了，包括各种合成性能测试，DD 测试、ior 测试、IO500 测试、FiO 文件性能测试等，以此验证产品宣传是否属实，技术实力是否名副其实。” 正如他在整场演讲中详细讲解的，该平台性能完全达标，足以承接真实业务负载 —— 而真实业务场景恰恰最容易暴露系统瓶颈。

Jump Trading 的思路发生了转变，不再将存储视作固定硬件，而是看作具备高灵活性的软件平台。他提到，团队此前遇到的瓶颈仅限于集群规模，并非平台本身。因此他们没有单纯等待采购新硬件，而是复用旧服务器作为计算节点（C-nodes），由此打开了极大的扩展空间。

VAST Data 的产品快速完成适配并上线部署，以保障业务持续运行。存储容量不再受厂商固定配置限制， Jump Trading 得以持续发展。正如 Wojcik 所说，团队可以利用现有设备直接扩容，不受供应链供货延迟的制约。

这种灵活性也恰恰在需要的时候显现出来。当硬件采购周期变得漫长，但业务扩容需求十分迫切时，集群原地扩展的能力意味着生产业务零中断。而在传统架构中，此类扩容都会受硬件限制与审批流程制约，进度十分缓慢。

Wojcik 还提到，技术支持服务同样具备这种高效特性。Jump Trading 可直接对接厂商工程师，这些工程师会针对其业务负载进行专项优化，这意味着问题无需等待后续版本更新才能解决。漏洞修复通常可以实现当晚完成，次日便可上线部署。Wojcik 表示，双方合作近乎联合研发，真实业务使用场景直接驱动系统迭代优化。

Wojcik 明确表示，Jump Trading 从不局限于基准测试，更会通过极限业务负载测试压榨文件系统性能边界，包括修改已打开、已删除的文件，测试非常规 NFS 协议运行逻辑，支撑数千客户端超高并发访问。他强调，这些都是量化交易真实业务场景的业务模式，并非极端特例，能够精准暴露各类系统的缺陷。

在 Jump Trading 高速运转的业务场景中，元数据处理会形成瓶颈，数据交互协调会增加延迟，且随着并行任务增多，原有集群容量规划也会崩溃。高负载下的数据协调、锁定、数据一致性问题会不断加剧，而这正是对 VAST Data 平台能否全面展现实力的真正考验。

同样的限制迫使 Jump Trading 公司从 NFSv3 协议升级至 NFSv4 协议。公司的最初目标很简单，仅计划使用常规标准 NFS 协议，但 NFSv3 无法支撑大规模业务访问。而 NFSv4 可以更好地处理复杂文件交互与元数据协同管理，Jump Trading 率先完成升级。尽管初期遇到适配问题，但最终获得了匹配自身业务负载的能力。Wojcik表示，该协议也为文件委托等功能奠定了基础，以此降低了元数据开销，并提升了扩展性能。

而更核心的架构变革体现在系统层面。正如 Wojcik 所说，存储从原先孤立的 Pod 级部署，升级为贯穿整个数据中心的统一共享存储层。

自此不再需要频繁数据同步、数据重复存储与传输延迟，一切都从统一全局命名空间进行操作。 Wojcik 表示，“如今所有业务集群都可以访问全部数据，量化研究员无需再处理繁琐的数据管理工作。” 此外，他也强调，用户无需再进行数据预处理、数据复制迁移等操作。

Jump Trading 最初仅使用 NFS 协议，后续该平台逐步演进为多协议统一架构，同一套数据可适配各类不同业务负载。

NFS 依旧作为 POSIX 标准文件访问的核心协议，S3 协议则适配对象存储业务，且不存在云端访问延迟与数据拷贝问题。Wojcik 表示，“用户需要 POSIX 访问，可使用 NFS 来读取数据；而如果想要通过 S3 来访问，只需简单切换选项即可。”

NVMe over TCP 是较新的协议，它可为 Kubernetes 与生产系统提供块存储服务，延续了单数据集具备多访问路径的架构，全程无需复制数据。

有趣的是，性能大幅提升的原因，来自于 Jump Trading 起初并不打算启用的一项功能。Wojcik 介绍，团队原本一直规避使用内核模块，直到 Linux 的原生 NFS 出现一个 Bug ，他们才不得已接入 VAST 客户端驱动，系统性能立刻发生巨变。读取速度从原本 8-9 GB/s 提升至原先 6 倍以上，写入速度接近 20GB/s，集群整体吞吐量达到 1.25TB/s，访问延迟仅 0.6 毫秒。

Wojcik 表示，这并非参数调优带来的提升，而是路径优化得以实现。多路径技术让客户端能够调用全部网络接口，结合计算节点间更优的流量负载均衡，打破单链路带宽限制，释放了此前闲置的全部带宽。

可观测能力也实现了同等幅度的升级。系统审计日志会记录所有文件操作，并结合用户、文件路径生成完整操作时间线，这使得故障排查不再依靠经验猜测，而变得有据可依。

运维团队可以精准定位事件内容与发生时间。Wojcik 表示，“当用户反馈数据丢失时，我们可以通过日志清晰查证，确认是否为用户自身操作删除了数据。” 对于 Wojcik 的团队而言，这最初仅用于数据可视的能力，逐渐演变为复杂业务场景下，面向用户与运维人员的可靠故障排查体系。

一旦吞吐量与可观测能力得到完善，更深层的附加价值便开始凸显。平台中大约 2:1 的数据缩减比例降低了硬件需求，而更大的价值体现在配套环节：电力消耗、机柜空间、网络资源以及运维成本均大幅缩减。在数据集高度重叠的业务环境中，这意味着数据可以实现高效复用，同时降低了大规模部署的整体成本。

该平台的应用范围也持续拓展至生产系统。CSI 驱动将该平台接入Kubernetes ，为容器化业务提供持久化存储。合作模式始终稳定：业务提出需求，厂商工程师直接对接，数日内完成测试，随后快速落地生产。架构模式保持不变 —— 一套数据平台、多种访问路径，以及与此同时不断拓展的应用场景。

这套架构能够平稳运维，得益于 Jump Trading 独特的运维模式。Wojcik 提到，他们仅拥有一支小型团队，就可依托 API 与自研工具实现全流程自动化运维，从而可以摒弃人工操作。从资源分配、集群运维到版本升级，全部可通过自动化完成，确保整个系统完全适配程序化管控的基础设施需求。

平台版本升级的成果最能体现技术进步。早期升级需要多方严密协调、大量人工排障；如今，即便在从不空闲的系统上，升级也能够在白天直接进行，且用户完全无感知。底层运维复杂度依旧存在，但它全部被封装在平台内部，因此，升级不会中断正在运行的业务，系统可持续迭代更新。

最引人注目的是，当这套系统真正落地后，团队的期望值所发生的改变。多协议访问成为刚需， NFS 驱动成为了追求极致性能的必选项，全链路可观测成为核心能力，数据缩减的价值也不再局限于节省存储空间。工程师团队的极速响应重塑了服务预期，平台新功能可在系统在线运行的状态下，直接无缝更新上线。

谈及 Jump Trading 团队的未来规划，Wojcik 表示，他们将优化 NFSv4 的委托功能，以降低高并发场景下的元数据开销；借助 VAST DataSpace实现跨地域全局命名空间，数据无需异地搬运就可以实现计算灵活迁移；依托 VAST Event Broker ，搭建与数据活动紧密绑定的事件驱动工作流；块存储业务也将结合容器技术，持续拓展生产应用场景。

对 Jump Trading 来说，该平台实现了可编程、可观测，并实现了跨计算域的共享。业务瓶颈不再是原始数据吞吐量，转而聚焦数据协同、访问模式，以及大规模场景下的数据高效复用能力。

本文作者：Nicole Hemsoth Prickett ， Vast Data 行业关系总监