LabVIEW中测试测量大数据地存储.docx
《LabVIEW中测试测量大数据地存储.docx》由会员分享，可在线阅读，更多相关《LabVIEW中测试测量大数据地存储.docx（17页珍藏版）》请在冰点文库上搜索。
LabVIEW中测试测量大数据地存储
试测量数据。
对其他的测试测量应用场景我还不熟悉。
NI的硬件，如PXI卡采集所得的测
NI原先是缺乏一个比较优秀的测试测量数据存储方案的，NI后来也意识到了这个问题，于是在德国收购了一家公司，这家公司专做数据存储（也包括显示、报表等），于是NI在数据的采集、存储、显示这方面的产品线已经比较齐全了。
NI现在主推的一个数据存储逻辑模型叫做TDM（TechnicalDataManagement），具体的方案可见：
NITDMDataModel这个模型的特点可以简单概括为：
清晰的层次结构以及支持各层次的描述性信息。
具体来讲，一个TDM模型的数据文件可以分为三层，分别为文件（File）、组（Group）和通道（Channel），在每个层次上，都有NI定义好的一些属性，同时，用户也可以自定义属性。
这样的一种数据模型很容易被理解和接受。
比较符合实际的应用需求。
比如用NI的采集卡采集电压数据。
一块卡上一共8个通道。
每个通道每次采集的数据都可以保存为一个“通道（channel）”，8个通道一次采集的数据可以组成一个组（group），每天采集一次，n天就形成n个组，每个组都有8个通道，所有的数据都写在同一个文件（file）里。
其他卡采集的数据放在不同的文件中。
除了直接采集到的数据（可称之为RawData）之外，总要写点其他信息的，比如采集卡到底是什么型号，每次采集都是谁来完成，采集的是电压还是电流，单位是伏特还是千伏等等。
这些信息就称为描述性信息（MeatData）。
这些信息写在别的文件里面总不太容易管理，最好写在一个文件中。
因此TDM模型也支持将这些描述性信息写在同一个文件中。
注意一下，我在这里说的是TDM的“逻辑”模型，并不是指他的物理存储结构。
在NI，有数种文件格式都支持TDM的模型，但是他们的物理存储方式大相径庭，这个以后再写。
这种TDM模型的测试测量数据文件，是NI软件平台中通用的文件，除了LabVIEW外，很多其他的NI软件产品都支持这种模型，比如DIAdem、CVI、SingalExpress等等。
在LabVIEW中，分别有三套API支持TDM模型的数据文件，他们分别是：
这三套API分别对应着三种应用的难易级别，由易而难。
具体以后
再介绍。
下次写一下我对TDM数据模型的看法（优缺点），以及简单介绍相关的文件格式。
在分析TDM模型的优劣势之前，我想最好先罗列一下一些数据文件格式的技术要求。
NI软件平台上针对于测试测量的数据，有很多不同的文件格式，其
中有几种是支持TDM模型的。
并不是说这些文件都能满足以下技术要求，我只是
先罗列出来：
1）写文件速度必须要快。
很多情况下需要一边采集数据一边就把数据写到文件中，采集卡的速度已经相当快了，这时候瓶颈常常是在写文件这个步骤上。
相反，读文件可能并没有如此高的要求。
2）向文件追加（append）数据的时候，速度要快，这个时候不能读取文件中的信息。
这其实也是常用的一个usecase，采集数据写入文件的动作可能经常要进行（比如在一个循环中），往往又是往同样的文件中写入信息。
3）写文件的速度不能与文件大小成正比。
我们希望不管文件有多大，写文件的速度总是保持相对恒定，不能文件越大就写得越慢。
4）支持随机的读取。
比如我想读文件中某个位置的某些内容，不能要求把这个位置之前的所有数据都先读出来（即读到内存中）。
5）支持分别读写描述性信息和原始数据。
这是上一条的延伸，读描述性信息（metadata）的时候不要求把原始数据（rawdata）读进来，同样，读原始数据的时候也不要求把描述性信息读进来，否则，势必影响读文件的速度。
6）对读文件的速度也有一定的要求。
这个要求主要来自于搜索数据。
无数浩瀚的数据，怎样才能快速的找到用户需要的数据，这一直是一个难题。
7）文件不能太大。
存储同样的数据量，文件自然越小越好。
技术要求暂时就写这么多，其实总结起来，无非两点：
1）快；2）方便。
我们对照TDM的数据模型，对于“快速”，暂时看得不明显（以后可以谈谈为什么TDMS文件可以达到“快速的要求”），但是说它“方便”，还是可以理解的。
这个模型的设计完全是依照用户的应用实例。
首先，它是分层次的。
比如说我们需要测试汽车发动机的各个指标。
我们用8个通道的采集卡采集发动机振动的数据，8个通道分别采集8个部位的振动，存到文件中，作为一个组（group），组的名字就叫做“发动机振动”。
我们还需要采集发动机的进气管、排气管压力，又作为一个组。
还要采集发动机的温度，可能也用8个通道的采集卡采集8个部位的温度，每个部位的温度数据作为一个通道（channel）存到文件中，8个通道作为一个组，叫做“发动机温度”等等。
我们可能会采集多次，其他参数都不变，只是数据每次都附加在文件的后面。
我们有很多的测试工程师，每个工程师做的测试分别存成一个TDM模型的数据文件。
可以发现，这样的三层结构还是很清晰的。
这就好比用LabVIEW些程序，VI大了，就不知道怎么管理了，那就多用几层SubVI嘛。
其次，它具有描述性信息。
比如可能需要把测试的日期、测试者的名字、测试的环境配置等信息写下来。
有些描述性信息是针对“文件”这个层次的，比如测试者的姓名。
有些信息可能针对“组”这个层次，比如采集的是“温度”，单位是“摄氏度”。
有些信息则可能针对“通道”，比如采集的是发动机哪个部位的温度等等。
描述性信息比较利于他人阅读文件，并且，在搜索文件数据的时候，可以派上大用场，可以先利用这些描述性信息进行定位。
当然，这些信息最好能和“原始数据”（rawdata）放在一起，要是放在两个文件中，一是难以对应起来，而是不利于维护。
这也好比是写LabVIEW程序，你写的程序，别人也要能看到，没太多的好办法，就多写点注释吧。
这样的TDM模型也有其缺点。
至少看起来有点复杂，同时有原始数据和描述性数据，还要实现那么多的技术要求，着实有点困难啊。
其次，这个模型写下来就固定了，一共就3个层次，说到底在某个文件中也就2个层次，不能扩展，不像XML那样方便。
我有时候就想要把数据写到一个“通道”中，我还非得先造一个“组”出来（其实可以不写，默认会造一个出来，但是逻辑结构上不能缺少）。
还有其他限制条件，比如原始数据必须写在“通道”这个层次，不能写在“组”这个层次等等。
总体来讲，TDM数据模型利大于弊，比较适合测试测量领域的数据的存储，是一套不错的解决方案。
今天谈谈如何选择合适的文件格式。
在LabVIEW中可以使用的文件格式有好几种，争对于测试测量数据的文件格式也不少。
每种文件格式都有自己的优缺点，很难说孰优孰劣。
关键的问题在于要选择合适自己的文件格式。
那么，在选择具体的文件格式时，有哪些指标可以参考？
1）性能。
测试测量数据的一个比较重要的usecase就是要一边采集数据一边
存储数据，NI现在采集数据的速度已经非常快了，性能的瓶颈往往是在存储数据到文件中去这个步骤上。
当然，有些usecase对于读取数据的性能也有要求，比如要做实时的数据分析等。
因此，在选择合适的文件格式时，需要考虑性能的问题。
2）兼容性。
采集数据、存储数据、分析数据，用的可能不是同一套软件，很有可能在不同的平台、不同的软件中完成这些不同的功能。
那么就需要采用一种比较通用的文件格式。
打个比方，XML就是一种比较通用的文件格式。
3）支持的数据类型。
并不是每种文件格式都支持所有的数据类型。
有些可能不支持存储二维数组、不支持存储时间、日期等等，在选择文件格式时需要注意到这一点，以免将来带来不必要的麻烦。
4
对于高手来讲也
）是否方便使用。
有些人可能喜欢定义一套自己的文件格式，
未尝不可，但是对于一般的用户就需要考虑是否有这个必要。
有些文件格式，在LabVIEW
中已经有现成的、丰富的API，那就直接拿来用吧。
5
还可能会拿去给
）可维护性、可移植性。
写完的文件很有可能将来还会修改，
别人去修改。
别人是否看得懂这样的文件？
别人是否方便修改这样的文件？
6）文件大小。
存储相同的信息量，当然文件越小越好，信息存储紧凑一点好。
当然还有其他很多方面的指标可以参考。
暂时先说这些，以后还会有更深入的内容介绍。
针对于测试测量行业的数据存储，LabVIEW提供了数种不同的文件格式，先来介绍一下LVM格式。
LVM（LabVIEWMeasurementFile）总体来说是一种比较轻量级的文件格式。
它基于ASCII编码，用一般的文本编辑器打开都能看懂。
当然，这个特点优劣参半，非二进制代码的文件，总体来说性能较低，并且不够紧凑（即存储相同信息量，文件稍大）。
所以，LVM文件格式适用于对性能、文件大小并不具有太高要求的情形。
左图显示的就是用普通的文本编辑器打开一个LVM文件的情形。
可以看到第11行文字为"***End_of_Header***"，可见lvm文件具有header信息，header中的每一行都是一个键值对，表示该文件的一个属性，属性名与属性值之间目前以Tab分开。
第13行开始就是文件的主体部分，LVM文件中也有类似于"segment"的概念。
每次往相同的文件中写入信息都会往这个文件的末尾增加一个segmentsegment也可以含有自己的header，header中自然也是存着针对于这个segment的属性信息。
在segment的header之后就是真正的原始数据。
比如一个波形图的数据。
在上图中，我们存储了一个一维数组的数据。
LVM文件最多可以支持二维数组的数据，如果打开存储二维数组的LVM文件，其原始数据部分看起来会与上图稍有不同，很像一个excel中存储的数据。
在LabVIEW中操作LVM文件格式的API主要是Read/WriteMeasurementFile，如下图所示：
LVM文件还有一个缺点，就是header中的属性是固定的，仅通过LabVIEW的API并不能增加用户自定义的属性，这是一个限制。
当然，不排除这样的情况：
用户自己用文本编辑器打开LVM文件，向其中写入或者修改一些属性。
世上没有完美的文件格式。
LVM文件格式也有其自己的优缺点，有其独特的应用条件。
并不能根据某个单一的指标判断它是好是坏，使用时应先判断自己的应用要求，作出合适的选择。
今天先来谈谈Datalog文件，这种文件格式也有点年代了。
基本上可以认为这种文件格式是二进制的。
准确的讲，如果仔细研究，可以发现这种文件的内部结构比较奇怪。
举个例子：
如果往这个文件中存储3个int32的数字，用二进制的文本编辑器打开，可以看到内容类似于：
这个还比较还理解，前面是一些头文件，后面是1、2、3三个数字但是如果写入a、b、c三个字符，情况就比较复杂了：
中间再省略若干行0。
。
。
到文件的最后是：
由此可见，该文件格式对于不同的数据类型、不同的存储方法有不同的内部结构。
我个人看来，对于后一种结构，还是有不少的冗余信息的。
这种文件使用起来也不是太复杂，有一整套的API可以调用，具体的使用方法可以参考帮助文档。
总体来讲，这种文件格式，性能、使用的建议度、可读性均在中等水平，仅适用于LabVIEW软件。
对于性能有一点要求，但要求不是很高的用户来说，可以采用该文件格式。
再介绍一种文件格式，在LabVIEW中就叫做“二进制文件（binaryfile）”，其实很多文件格式都是二进制的，包括刚才介绍的Datalog，以及以后要介绍的TDMS。
为了区别于其他二进制文件，我们有时候叫这种二进制文件为“bytestream”。
具体操作这种文件格式的API非常简单。
这种文件格式的性能非常高，使用起来也非常方便（就两个VI，一个负责写，一个负责读），但是数据的组织，也就是内部数据的结构（在这里无法透露具体的内部结构），可以说是比较差的。
如果用户对于写入文件的性能要求比较高，但是并没有太多后续维护、管理数据的需求，可以考虑采用这种文件格式。
接着介绍LabVIEW中的另外两种文件格式。
首先是Bytestream。
这个文件格式说穿了就是二进制文件。
就两个VI，分别是读和写。
基本支持LabVIEW中的任何类型的数据。
只要你在LabVIEW中能造出的数据，都可以用这种文件格式存储。
可以猜测，其实这两个VI做的事情也比较简单，直接把LabVIEW在内存中的这部分数据写到文件中就行了，当然这样做的话，效率也比较高，因为没什么运算的步骤。
但是也有部分缺点，比如直接把数据写到文件中也不见得好，真正的问题是如何管理这些数据。
例如，读文件的时候也需要知道究竟这些文件存储了什么类型的数据，究竟存储在文件的什么位置等等。
总的来说，如果用户追求纯粹的写文件的速度，并且不在乎将来读文件是否遇到困难（其实如果一个文件只写不读那就没什么意义了），那么用这样的文件格式还是可以的。
接下来介绍TDM文件格式。
TDM文件是指后缀名为.TDM的文件。
文件的逻辑存储模型遵循NI的TDMDataModel，三层结构。
TDM文件主要分为两个物理文件，一个是主文件，后缀名为TDM，存储原始数据以及属性等信息；另一个是头文件，后缀名为TDX，主要存储属性信息，方便查找，作为一个索引文件。
主文件是类似于XML结构的，而头文件是一个二进制文件，理由也很简单：
头文件主要用来索引搜索数据，所以对读的速度有较高要求，因此作为二进制文件更合适。
对于TDM文件的操作，LabVIEW中主要通过StorageVIs来完成。
TDM的文件格式，我个人感觉，最大的优点在于对于数据的管理。
以前介绍的文件格式，没有对数据的管理做太多的考虑。
TDM文件格式分为三次结构并且可以
加入用户定制的属性，使用更为方便。
举个通俗易懂的例子：
很多人中午要带饭，放在饭盒里。
普通的文件就是一个大杂烩，饭、菜混合放在一起，吃起来不方便并且看上去就杂乱；而TDM文件就像是有分隔的饭盒，饭菜可以分开放置，方便整洁。
随着NI在测试测量文件方面的进步，TDM的文件格式已经逐步被TDMS文件格式取代，下次专门介绍TDM。
S终于写到TDMS了，千呼万唤始出来啊，其实所有前面的相关文章都是为了TDMS作铺垫。
正是由于用户提出的种种需求以及其他种种文件格式的缺点，才有了TDMS的出现。
1.TDMS文件的逻辑格式
TDMS文件的逻辑格式遵循TDM三层结构，仍然是文件、通道组、通道三层。
用户在使用时只需要关心这三层就行了。
2.TDMS文件API
TDMS文件格式基本上可以称为NI用在测试测量领域的通用数据文件格式，LabVIEW,CVI/LabWindows,SignalExpress,DIAdem中都可以使用，也常看到在Excel,MatLab被中调用。
TDMS最核心的内容都在一个dll中，用户如果安装了LabVIEW，就会发现在ProgramFiles\NationalInstruments\Shared\TDMS文件夹中有个tdms.dll的文件。
其他软件正是通过调用这个dll的API来操作TDMS文件的。
在LabVIEW中操作TDMS文件其实相当方便，有专门的TDMS面板，提供了TDMS绝大多数的功能。
虽然我们一直说Write/ReadMeasurementFiles,StorageVIs,TDMS分别面向初级、中级、高级的用户，但是我个人觉得LabVIEW中的TDMS用起来十分方便，即便是初级用户，也能很容易的上手。
在面板上一共就10个SubVI，无论是什么样的数据类型，都可以用这样同一套SubVI，无需大量额外的编程工作。
这里可以简单介绍一下TDMS面板上的两个SubVI，我个人觉得十分有用。
一个是“TDMSFileViewer”，当用户写完某个TDMS文件之后，就可以用这个SubVI来方便的查看文件的内容，只要输入TDMS文件的路径即可，运行VI就会跳出一个Viewer的界面，可以查看数据、属性，并且可以根据数据简单的绘制出一些波形图。
另外一个是“TDMSDefragment”，通常用户写完TDMS文件之后，可能会发现这个文件非常大，那么这时就可以使用这个SubVI，可以
大幅度的减小文件的size。
3.TDMS二进制文件
TDMS从设计之初就确定它必须是二进制的。
二进制文件带来两个优点：
第一，与一般的文本式文件相比，二进制文件通常比较小；第二，二进制文件读写通常比较快。
这两个都是其他二进制文件都具备的优点，就不再多说了。
4.TDMS头文件
用户写完TDMS文件之后，会发现硬盘上其实有两个TDMS文件，一个是.tdms，另一个是.tdms_index文件，我们通常把前者称为主文件或者数据文件，而把后者称为头文件或者索引文件。
头文件与主文件相比，最大的区别就是把主文件中的rawdata都去掉了，只留下属性等信息。
这样做，有两个目的，第一，可以使得读文件加快速度，并且支持随机读取文件数据，这个稍后再解释，用户看完后面的内容就可以理解。
第二，可以使得某些软件的搜索TDMS文件功
能加快。
比如在DIAdem中搜索TDMS文件，可以根据文件名、通道组名、通道名（其实这些也是属性），或者其他某些属性进行搜索，这个时候，仅将TDMS的
头文件载入进行搜索，其速度远远比将TDMS主文件载入搜索快得多。
5.TDMS的内部结构
TDMS文件的内部结构，也就是物理结构，可以在这里找到原文。
一般的用户并不需要了解这方面的知识就可以方便的使用TDMS文件。
在这里介绍
这个内部结构，是为了更好的解释TDMS文件格式的优点。
TDMS内部结构的核心概念是segment，如下图。
为了避免混淆，在这里必须澄清的是，这个segment的概念与TDM的三层结构（即逻辑结构）没有任何对应的关系，也就是说，一个通道可能对应着多个segment，一个segment
中也可能有多个通道。
segment是什么意思？
我们在写TDMS文件的时候，数据本来可能存放在内存中，那么总要往硬盘上写这些数据的，每次往硬盘上写（flushtodisk）就会产生这样一个segment。
同样，我们在读TDMS文件的时候，也是一个segment一个segment的把内容读出来。
再稍微深入介绍一下这个segment中的内容。
一开始有一些头信息，比如这个segment中是否含有metadata，是否含有rawdata，version是多少。
下面的东西就很重要了，有个“nextsegmentoffset”的信息，指向下一个segment的起始位置，这个有什么用呢？
比如我要读某个通道的数据，发现这个
segment中并不包含这个通道的内容，就可以使用这样的信息直接跳到下个segment中看下个segment是否有要找的信息。
同样，还有一个“rawdataoffset”的信息，比如用户只想读rawdata，并不关心属性之类的信息，那么这个“rawdataoffset”的信息就派上用场了。
说到这里，就可以明白，TDMS是怎样支持Randomaccess，怎样支持独立的读属性信息和rawdata的信息。
此外，这个segment还有一个极为重要的特点。
我们每次写数据，每次往TDMS文件中flushtodisk的时候就在文件的后面添加这样一个segment，而不去关心之前的segment中包含了什么样的信息。
这个特点非常关键，这就可以使得我们写文件的速度非常快，我们并不关心之前文件中包含了什么信息，也就使得我们写TDMS文件的速度并不和TDMS文件的大小成正比或者有任何关系。
6.TDMS文件格式的优点
我在以前的文章中提到几个数据文件格式的技术要求，我们现在再来回顾一下，看看TDMS文件是如何实现这些技术要求的，这样也就能看出TDMS文件的优点来。
1）写文件速度必须要快——通过segment实现以及二进制。
2）向文件追加（append）数据的时候，速度要快——segment。
3）写文件的速度不能与文件大小成正比——segment。
4）支持随机的读取——segment以及头文件。
5）支持分别读写描述性信息和原始数据
segment以及头文件。
6）对读文件的速度也有一定的要求——segment以及头文件。
7）文件不能太大——二进制。
7.其他
TDMS文件格式目前（LabVIEW8.5）只支持Windows和PharLap（一种实时操作系统）平台上。
不过我还看到一个基于VI的TDMSAPI，这个完全基于LabVIEW，既然LabVIEW能在其他平台上工作，那么这个小工具也能在其他平台上工作。
当然，效率、性能的会差很多了。
通常总有人拿TDMS文件格式和一般的基于WindowsAPI文件流操作比较，然后会说TDMS比那样的Win32streamingAPI慢嘛，是不是TDMS不行？
比如在某些磁盘阵列的配置下，Win32streamingAPI可以达到650MB/S，而TDMS只能600MB/S左右。
我在这里需要澄清的是，TDMS在保持着数据良好逻辑结构（TDM的三层结构）、良好的数据管理的前提下，还能保持着这样高速的性能，这才是TDMS最大的优点。
Win32streamingAPI只是纯粹的追求速度（也仅比TDMS快5-10%左右），并不能将测试测量的数据良好的组织好、管理好，用户如果片面的追求速度而不管写入文件的数据如何保存如何管理，那就有点得不偿失了。
当然，TDMS文件也并不完美，同样存在着种种缺点。
比如不能支持方便的删除某个通道的功能，目前还不支持其他操作系统等等。
相信将来都会有改善的。
最后，用一个不是很恰当的例子来结束这篇文章。
测试测量数据的文件格式，有很多种，文件格式就像我们中午带饭的饭盒一样。
其他的数据文件格式就是把饭菜都放在一起，吃起来不方便（速度慢），而且味道都混杂在一起（组织不好）；而TDMS文件格式就像是内部有分隔的饭盒，不同的饭菜分开存放，吃起来又方便（速度快）味道又好（组织良好）。
升级会员 