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