最高效的压缩超大数据集答案

【问题标题】：Most efficient compression extremely large data set最高效的压缩超大数据集
【发布时间】：2013-12-31 13:18:02
【问题描述】：

我目前正在远程 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.. 等相关联。我相信没有任何额外的信息。

【问题讨论】：

在 WinXP 中：Right Click -> Send to zip ... ;)
是的，我希望它可以这么简单......
那是什么，来自 NSA 的通信跟踪数据？
检查一下，希望对您有所帮助。 maximumcompression.com 但是，我认为最好的压缩策略取决于您的应用程序
检查 lzma thegeekstuff.com/2010/06/…

标签： linux storage

【解决方案1】：

在 LINK 上进行了一些研究，分析了使用 gzip、bzip2 和 lzma 的优缺点。希望这可以让您就最佳方法做出明智的决定。

【讨论】：

【解决方案2】：

可能有帮助的几点：

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

【讨论】：

相邻数位的差异很有趣！当然，在分析数据时会涉及额外的计算，但它会极大地减少文件的大小。谢谢。

【解决方案3】：

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

的行

24 30 86 312 726 875 1023 1683 1799

类似

6 56 226 414 149 148 660 116

您的示例中的其他行甚至会显示出更多的好处，因为差异更小。这也适用于中间数字减少的情况，但你必须能够处理负面差异。

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

【讨论】：