最有效的压缩极大数据集

Question

我目前正在远程HPC（高性能计算机）上生成一个非常大的数据集。我们现在谈的是3 TB，一旦完成，它可以达到 10 TB 。

450 000个文件中的每一个都从几KB到大约100 MB不等，并且包含没有重复/可预测模式的整数行。此外，它们分为150个文件夹（我使用路径根据输入参数对它们进行分类）。既然可以没问题，但是我的研究小组在技术上限制在远程服务器上的 1TB 磁盘空间，尽管管理员愿意闭上眼睛直到情况得到整理出来。

您建议压缩此类数据集？ 限制是此计算机上的任务一次不能超过48小时。如果48小时就足够了，那么长时间但有效的压缩方法是可行的...我真的没有其他选择，因为我和我的组都没有其他机器上足够的磁盘空间。

编辑：只是为了澄清一下，这是一台运行在某些Linux版本上的远程计算机。所有标准压缩协议都可用。我没有超级用户权限。

EDIT2：根据Sergio的要求，这是一个示例输出（文件的前10行）

27 42 46 63 95 110 205 227 230 288 330 345 364 367 373 390 448 471 472 482 509 514 531 533 553 617 636 648 667 682 703 704 735 740 762 775 803 813 882 915 920 936 939 942 943 979 1018 1048 1065 1198 1219 1228 1513 1725 1888 1944 2085 2190 2480 5371 5510 5899 6788 7728 9514 10382 11946 13063 13808 16070 23301 23511 24538 
93 94 106 143 157 164 168 181 196 293 299 334 369 372 439 457 508 527 547 557 568 570 573 592 601 668 701 704 799 838 848 870 875 882 890 913 953 959 1022 1024 1037 1046 1169 1201 1288 1615 1684 1771 2043 2204 2348 2387 2735 3149 4319 4890 4989 5321 5588 6453 7475 9277 9649 9654 11433 16966 
1463 
183 469 514 597 792 
25 50 143 152 205 244 253 424 433 446 461 476 486 545 552 570 632 642 647 665 681 682 718 735 746 772 792 811 830 851 891 903 925 1037 1115 1147 1171 1612 1979 2749 3074 3158 6042 12709 20571 20859 
24 30 86 312 726 875 1023 1683 1799 
33 36 42 65 110 112 122 227 241 262 274 284 305 328 353 366 393 414 419 449 462 488 489      514 635 690 732 744 767 772 812 820 843 844 855 889 893 925 936 939 981 1015 1020 1060 1064 1130 1174 1304 1393 1477 1939 2004 2200 2205 2208 2216 2234 3284 4456 5209 6810 6834 8067 10811 10895 12771 15291 
157 761 834 875 1001 2492 
21 141 146 169 181 256 266 337 343 367 397 402 405 433 454 466 513 527 656 684 708 709 732 743 811 883 913 938 947 986 987 1013 1053 1190 1215 1288 1289 1333 1513 1524 1683 1758 2033 2684 3714 4129 6015 7395 8273 8348 9483 23630 
1253 

所有整数由一个空格分隔，每行对应一个给定的元素。我使用隐式行号来存储这些信息，因为我的数据是相关的，即第0个元素与元素27 42 46 63 110 ...等相关。我相信没有任何额外的信息。

Answer 1

可能有所帮助的几点：

• 看起来您的号码已排序。如果情况总是如此，那么压缩相邻数字之间的差异会更有效，而不是数字本身（因为差异平均会略微偏小）。
• 有很好的方法可以用二进制格式编码小整数值，这可能比以文本格式编码它们更好。请参阅Google在其协议缓冲区中使用的技术：（https://developers.google.com/protocol-buffers/docs/encoding）
• 一旦你应用了上述技术，那么压缩/某种标准形式的压缩应该可以进一步改善一切。

Answer 2

在此LINK进行了一些研究，打破了使用gzip，bzip2和lzma的利弊。希望这可以让您在最佳方法上做出明智的决定。

Answer 3

所有数字似乎都在增加（每行）。数据库技术中一种相当常见的方法是仅存储大小差异，形成类似

的行

24 30 86 312 726 875 1023 1683 1799 

类似

6 56 226 414 149 148 660 116

您的示例的其他行甚至会显示更多的好处，因为差异较小。当数字减少时，这也有效，但你必须能够处理负差异。

要做的第二件事是更改编码。虽然压缩会减少这种开销，但您目前使用的是每位8位，而您只需要4位（0-9，空格除数）。实现自己的“4位字符集”已经将存储要求降低到当前大小的一半！最后，这将是某种任意长度数字的二进制编码。