计算机视觉资源站扩容难？三步清除存储冗余

　　群里又在吵存储扩容的事，产品在那儿拍桌子说“用户上传的模型和测试集都卡着，再不扩容要掉量了”——我盯着监控面板上的磁盘使用率，八成是去年三月那波“数据大迁徙”埋的雷。当时设计非要搞什么“全量历史版本保留”，说用户可能回滚到三年前的模型，结果现在存储池里躺着二十万份重复数据，光是YOLOv3的预训练权重就存了四百多版，每版都带不同前缀的压缩包名，我原以为用哈希校验能筛掉，结果发现有人直接改了文件名又传了一遍，这他妈谁筛得动？

　　上周三下午，编译进度条卡在98%的时候，我盯着日志里“No space left on device”的报错，突然反应过来——这破站扩容难根本不是硬件问题，是存储里的冗余数据比代码里的if-else还多。我原以为用rsync同步就能去重，结果发现用户上传的模型文件里，有三分之一是不同版本的“同名不同内容”，比如有人把训练到50轮的权重存成“model_v1.pth”，过两天又存了个“model_final.pth”，内容差了二十个epoch，但文件名里没版本号，哈希值也不一样，系统根本不敢删。

　　旁边工位的小张正在啃辣条，听到我骂街，抬头说了句：“要不试试按文件修改时间排序，只留最近三个月的？” 我差点把键盘砸他脸上——计算机视觉的数据哪能这么干？用户可能半年前传了个基础模型，最近才用它微调出最终版，你把基础模型删了，他微调的时候不得重新下？但话说回来，现在存储池里确实有大量“僵尸数据”：比如某个用户去年传的CIFAR-10数据集，压缩包名带“20220315”的日期戳，结果今年他又传了个同名但不带日期戳的，系统就把两个都留着，现在光CIFAR-10就占了三个T，其中两个是重复的。

　　外卖到了，我边拆筷子边想，这事儿得从“优胜劣汰”的逻辑下手。第一步先把“绝对冗余”干掉——比如完全相同的文件，不管用户怎么改名，只要哈希值一样就只留一份，其他全删。这一步能筛掉四成左右的数据，我上周试了下，删了二十万份文件，存储占用直接降了1.2T，结果产品又在群里发了个“裂开”的表情包，说“用户反馈找不到历史版本了”——我他妈明明在删除前做了软链接备份，是他自己用绝对路径访问的旧文件，这能怪谁？

　　第二步更狠，针对“相对冗余”的数据。比如同一个模型的不同训练轮次，用户可能只关心最终版和中间某几个关键轮次，其他的可以删。但怎么定义“关键轮次”？我原以为按损失函数值排序就行，结果发现不同任务的损失函数量纲不一样，有的用MSE，有的用交叉熵，根本没法直接比。最后跟算法组的老王商量，改成“按用户访问频率排序”——最近三个月被下载超过三次的文件保留，其他的打上“冷数据”标签，迁移到低成本存储里。这一步又筛掉三成数据，但老王提醒我：“有些用户可能半年后才用冷数据，迁移了他们访问会变慢。” 我回他：“慢总比存不下强，大不了后面再搞个预热机制。”

文章配图，仅供参考

　　窗外在下雨，我盯着监控面板上的存储使用率，从92%降到了78%，心里却没那么踏实。这三步确实清了不少冗余，但“优胜劣汰”的逻辑有个大坑——如果用户上传的数据本身就不“优”，比如他传了个错误训练的模型，或者测试集标签错了，系统按访问频率或修改时间筛，反而会把这些错误数据留着，把正确的冷数据删了。我上周就遇到个案例：有个用户传了个标签全错的测试集，结果因为他在群里喊“急需这个数据测试”，被其他用户频繁下载，系统把它当“热数据”保留了，真正的正确测试集却被迁到了冷存储，用户访问时等了十秒才加载出来，又在群里骂街。

　　现在的问题是，这三步只能解决“显性冗余”，比如完全相同的文件或明显过期的版本，但“隐性冗余”——比如错误数据、低质量模型、重复但文件名不同的数据——还是筛不掉。我跟产品提过，要不要加个“用户反馈机制”，让用户标记“这个数据没用”，系统根据反馈删，结果他说：“用户哪会主动反馈？他们只会骂存储不够。” 我认了，可能这就是计算机视觉资源站的宿命——数据量永远比代码复杂，扩容难不是技术问题，是人性问题。下一步我打算在删除前加个“确认弹窗”，让用户自己选要不要删，虽然麻烦，但至少能少背点锅。

（编辑：我爱资讯网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!