医学数据实时数据压缩算法

Question

我正在寻找一个健壮，高效的数据压缩算法，我可以使用它来提供一个实时传输的医疗数据(主要是波形-心率等)。

如有任何与科学论文有关的建议/链接，我将不胜感激。

编辑：该系统将基于服务器(很可能安装在医疗基础设施内)和移动设备(iOS & Android智能手机和带有本地应用程序的平板电脑)，这些波形将被传输到其中。服务器将从医院收集所有数据(主要是波形数据)。在我的例子中，稳定性和速度比延迟更重要。

这是目前我能提供的最详细的规格说明。我将调查你的建议，然后测试几个算法。但我正在寻找在类似架构中成功实现的东西。我也愿意接受任何关于服务器计算能力或服务器软件的建议。

Answer 1

不要将其视为实时数据或医疗数据--将其视为需要压缩以便传输的数据包(在TCP数据包中最有可能)。内容的细节只在压缩算法的选择中起作用，即使在那里也不是医学问题，而是数据的格式化/存储方式以及实际数据的样子。重要的是数据本身和整个系统造成的限制(例如，是数据收集(如Holter监视器)，还是实时状态报告(如ICU中的心脏监视器)？(接收数据的系统是什么？)

查看数据，它是以原始二进制数据的形式显示出来的，还是从另一个组件或设备接收到的(例如)结构化XML或HL7，数值表示为文本？压缩原始数据是最有效的选择，还是应该转换成只覆盖实际数据范围的专有二进制格式( 2、3或4个字节是否足以覆盖值的范围？)通过转换可以实现什么样的节约?兼容性问题是什么(例如，HL7兼容性的丢失)。

选择绝对最好的压缩算法可能也不值得做太多的额外工作，除非您将在极低带宽的情况下；如果数据来自嵌入式设备，您应该平衡压缩效率与嵌入式处理器、工具集和周围系统与其工作的能力和限制。如果一个定制的压缩例程比已经内置的工具节省了5%，那么在嵌入式闪存中额外的编码和调试时间和存储空间值得吗？现有的验证的软件库产生“足够好”的输出可能是首选的，特别是对于医疗设备。

最后，根据环境的不同，您可能希望牺牲一大块压缩以支持某种程度的冗余，例如传输数据的滑动窗口，这样任何X数据包的丢失都不会导致数据丢失。这也可能让您改变协议，并可能改变设备的配置方式--流UDP (没有丢失数据包的重传)和TCP (发送方可能需要重新传输)之间的差别可能很大。

现在，我已经讨论了系统方面的问题，有很多关于分组和流模拟数据的信息，从RTP等流媒体协议的开发到GSM/CDMA和VOIP语音分组的细节。不过，您的决策最重要的驱动因素可能是设备和服务器端提供给您的工具集。使用现有的工具集--即使它们不是最有效的选项--可能会使您的开发时间(以及上市时间)大大减少，还可以简化医疗设备/产品的认证。在业务方面，额外花费3-6个月的软件开发时间、寻找真正合格的开发人员以及处理监管审批可能是最重要的因素。

更新2012/02/01：我只是花了几分钟的时间来查看一个12导联心脏应力EKG的XML，其总观察时间为12+分钟，文件大小为~6MB。我估计超过25%的文件是重复的，可压缩的XML在研究标题中，波形数据是在-200到200之间的逗号分隔的数字集中在范围的中心，并且变化缓慢，数字横过y轴并停留在这一边一段时间。假设您想要的大多数是波形值，在这个示例中，您将看到一个没有压缩4500 59 / 763秒或59 Kbps左右的数据速率。完全未压缩并使用文本格式，您可以轻松地在"2.5G“GPRS连接上运行。在任何现代无线基础设施上，所使用的带宽几乎都不会被注意到。

我仍然认为，库存压缩库午餐时会吃这种数据(可能还会遇到压缩头和数据包报头的问题)。如果您坚持进行自定义压缩，我会考虑发送差异值，而不是原始数字(除非原始数据已经被抵消)。如果您的数据与我正在查看的数据类似，您可能可以将每一项转换为-127至+127的1字节值，可能将极值保留为用于溢出的“特殊”值(根据您的需要处理这些值--特殊表示、错误等)。如果您希望传输效率稍低，处理速度也不高，那么只需将每个值作为一个有符号的2字节值发送，它仍将使用比文本表示更少的带宽，因为当前每个值都是2+字节(值是1-4个字符加上不再需要的分隔符)。

基本上，不要担心数据的大小，除非这将是24/7运行在一个高度计量的无线连接与低上限。

Answer 2

有一类压缩软件是如此之快，以至于我没有看到它不能被称为“实时”的场景:它们必须足够快。这样的算法称为LZ4、Snappy、LZO、QuickLZ，每个CPU达到数百MB/s。

在这里可以找到它们的比较：http://code.google.com/p/lz4/

“传输的实时压缩”也可以看作是速度和压缩比之间的权衡。更多的压缩，即使速度较慢，也能有效地节省传输时间。

关于压缩和速度之间的“最佳折衷”的研究已经在本页面上实现，例如：http://fastcompression.blogspot.com/p/compression-benchmark.html。

Answer 3

我测试了许多压缩库，这是我的结论。

LZO (http://www.oberhumer.com/opensource/lzo/)考虑压缩大量数据(超过1MB)的速度非常快。

Snappy (http://code.google.com/p/snappy/)很好，但在分解时需要更多的处理资源(对于小于1MB的数据更好)

http://objectegypt.com正在提供一个名为IHCA的库，它在大数据压缩方面比lzo更快，并且提供了良好的解压缩速度，并且不需要许可证。

最后，您最好创建自己的压缩函数，因为没有人比您更了解您的数据