资金费率套利中的 “数据工程”
内容提要
作者总结资金费率套利数据看板的工程经验：项目从简单榜单扩展为跨平台多币种看板，遇到的问题多因AI处理过于死板，包括接口兼容、采集任务堆积、身份验证过严、数据覆盖口径不当、JSON反复序列化等，通过合并请求、调整优先级、拆分共享数据优化。最终迁移至Hetzner服务器，页面加载从60秒降至1~5秒。作者认为AI能解决具体技术问题，但缺乏整体布局能力，软件开发仍需工程师。
延伸解读
AI 写代码的边界：能解具体问题，难做整体布局
作者反复遇到接口兼容、任务堆积、身份验证过严等“低级问题”，根源在于 AI 标准生硬、缺乏对业务场景的整体判断。AI 能逐个解决具体技术问题，但无法主动发现“按小时覆盖”这类口径不合理的设计。这提示读者：用 AI 辅助开发时，工程师仍需负责架构决策和验收标准，不能把整体设计交给 AI。
采集任务膨胀：合并请求比堆硬件更有效
文章提到采集任务一度堆积到 15 万个，原因是按“单币种、单时间点、单数据维度”拆成独立请求。通过将多数平台请求合并，任务数降到一两万。这说明在数据采集系统中，请求粒度设计直接影响资源消耗；先优化请求合并与优先级，再考虑升级服务器，往往是更经济的路径。
数据口径与序列化：隐藏的性能杀手
作者发现两个容易被忽视的问题：一是要求每个小时都有 K 线才算完整覆盖，导致反复采集、进度阻塞，改为请求成功率口径后采集大幅推进；二是榜单快照以超大 JSONB 存储，反复反序列化耗时超过 5 秒。将关键字段拆表、复用增量快照后，JSON 体积降低至少三分之一。这提醒读者，数据覆盖口径和序列化方式会显著影响系统吞吐。
硬件差异被低估：迁移 Hetzner 后加载降至 1~5 秒
在软件优化遇到瓶颈后，作者将服务从 Vultr 迁移到 Hetzner CPX32，同价位下 CPU 性能高出约三倍，页面加载从 60 秒降至 1~5 秒。作者坦言此前不重视服务器环境，这次体会到当软件层面难有显著提升时，升级硬件也是有效手段。对读者而言，选型时值得对比不同供应商的同价位机型，而非默认沿用原有环境。
Q&A
资金费率套利数据看板最初是怎么做的，后来为什么改成了手动触发计算？
最初是纯前端页面，打开后实时请求多个平台的全部代币数据并计算排行榜，但加载需要几分钟，体验很差。后来改为手动触发计算任务：用户设定平台和代币参数后，后端持续请求数据、汇总结果并返回，任务会记录到操作记录中，用户可以离开页面并随时查看任务状态和结果。
采集任务堆积到15万个，作者是如何优化到一两万的？
大多数平台的请求可以合并，比如一次性请求300个代币在一天内的资金费率数据，一个请求就能合并上万个采集任务。对五六个平台进行这种合并优化后，任务数量从15万降低到了一两万。
为什么作者去掉了代币身份验证？
身份验证要求两个平台接口返回的代币合约地址能对上，才认为可以配对套利。但很多平台不返回合约信息，尤其是代币化股票需要传递不同参数，导致能通过验证的代币很少，榜单大量缺失正常数据。因此后来尽可能去掉了这层验证。
数据覆盖口径从按小时完整覆盖改为请求成功率，带来了什么效果？
原程序要求数据库里每个小时都有K线数据才算完整覆盖，没数据的地方会反复采集，导致进度阻塞。改为只要请求成功且不是异常请求，就认为该时间段数据已覆盖。这个简单改动极大推进了整个系统的采集进度。
JSON反复序列化问题是如何优化的，优化后效果如何？
以前整个榜单快照放在一个JSONB里，每次读取超过100M数据并反序列化，仅反序列化就耗时5秒以上。优化包括：减少反复读取和序列化、共享内存、精简JSON中重复和完整历史K线数据、将关键字段拆开放到数据表上。优化后JSON体积降低至少1/3，减少到20M左右，读取速度进一步加快。
迁移到Hetzner服务器后，页面加载速度提升了多少？
迁移到Hetzner CPX32（4 CPU 8G Memory，42u/m）后，同样页面路径加载数据时长从之前的5s~20s降低到了1s~5s，最长5秒，比原本快了3倍，达到了正常使用可接受的速度。
作者认为AI在软件开发中的能力边界是什么？
AI有能力把每一个具体的技术问题解决好，但还不具备整体布局的能力。软件的演进依然需要遵守软件工程的客观规律，这也是以后软件开发仍然需要工程师的原因。
