最有效的压缩非常大的数据集

目前,我正在远程HPC(高性能计算机)上生成一个非常大的数据集。 目前我们正在谈论3TB,一旦完成就可能达到10TB

450 000个文件中的每一个文件的范围从几KB到大约100 MB,并且包含没有重复/可预测模式的整数行。 而且它们被分成150个文件夹(我使用path根据input参数对它们进行分类)。 现在可以很好了,但是我的研究小组在技术上只限于远程服务器上的1TB磁盘空间,尽pipepipe理员愿意闭上眼睛,直到情况得到解决。

你会推荐什么来压缩这样的数据集? 限制是任务在这台计算机上一次不能运行超过48小时。 只要48小时就够了,那么长久而有效的压缩方法是可能的……我真的没有别的select,既不是我,也不是我的团队在其他机器上拥有足够的磁盘空间。

编辑 :只是为了澄清,这是一个远程计算机上运行的一些变种的Linux。 所有标准压缩协议都可用。 我没有超级用户权限。

编辑2:根据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等相关。我相信没有任何额外的信息。

有几点可能有所帮助:

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

在这个LINK上做了一些研究,打破了使用gzipbzip2lzma优缺点。 希望这可以让你做出明智的决定,你最好的办法。

你所有的数字似乎都在增加(每一行)。 数据库技术中一个相当普遍的做法是只存储大小差异 ,形成一条线

 24 30 86 312 726 875 1023 1683 1799 

类似的东西

 6 56 226 414 149 148 660 116 

你的例子的其他行甚至会显示更多的好处,因为差异较小。 当数字在两者之间减少时也是有效的,但是你必须能够处理负面的差异。

第二件事就是改变编码 。 虽然压缩将减少这种开销,你目前正在使用8位每位数,而你只需要4位(0-9,空间作为除数)。 实现您自己的“4位字符集”已经将您的存储需求减少到当前大小的一半! 最后,这将是某种任意长度的数字的二进制编码。