|
在以前的文章中稍微介绍了一下工业软件中超大文件的处理方法，本文再系统的介绍的一些通用的处理方法。阅读对象主要定位于软件研发人员。 常用术语： 文本格式：基于字节编码，即可以使用类似记事本打开，可以明文编辑的文件格式 二进制格式：基于值的编码，使用记事本打开是乱码，无法编辑，按数值定义字节保存长度 工程文件：工业软件自定义的文件格式 几何文件：常用的CAD数据文件，比如*.step, *.igs, *.x_t, *.jt，*.dxf等 渲染文件：用于显示的数据文件，比如VTK数据 网格文件：常用作求解器计算的输入文件，比如*.bdf, *.inp,*.cas,*.cdb等 结果文件：仿真之后用于保存结果的文件 中间文件：在软件使用过程中保存的临时文件，通常不对用户开放 序列化和反序列化：通俗讲就是将内存中的数据以二进制保存(序列化)和加载(反序列化) 在软件研发中，最容易生成超大文件的几个数据
处理超大模型文件的一些策略： 策略一：避免使用B-Rep几何数据 空间中任意一个长方形，使用参数描述，只需要两个顶点+旋转平移矩阵数据即可表达，而使用B-Rep至少需要200行的拓扑+几何数据文件存储。对于几何造型要求不高的几何数据，尽量使用参数描述，而不要使用B-Rep。比如建筑里的实体框架结构，给出框架每个结点坐标和柱的截面长宽，即可表达。做框架整体结构分析主要以杆梁索单元为主，不太需要实体结构。类似，IC设计中的走线，通过线的转弯节点和走线宽度高度或截面(梯形)即可定义，不需要复杂的实体结构。实际测试表明，使用参数存储三维结构数据文件，其大小通常只有B-Rep结构的5%-10%，甚至更少。 策略二：使用二进制格式代替文本格式 二进制格式的读写性能要好于文本格式，这种性能提升在超大模型读写时非常明显。现在固态硬盘的读写速率已经达到了500M/秒，所以在硬件读写上基本没有太大瓶颈，性能瓶颈主要在数据读取之后的处理上。 文本格式的好处是，如果使用压缩算法存储，压缩比可以非常高，在一些有传输瓶颈的场景有优势，比如网络传输(百度如何传输400T)。随着存储硬件越来越便宜，在实际应用中，大文件存储并不是太大的问题，而文件的读写性能是比较关注的。 策略三：内存映射文件 内存映射文件，是由一个文件到一块内存的映射。内存映射文件与虚拟内存有些类似，通过内存映射文件可以保留一个地址空间的区域，同时将物理存储器提交给此区域，内存文件映射的物理存储器来自一个已经存在于磁盘上的文件，不需要再对文件执行I/O操作，从而解决内存开销，读写瓶颈等问题。但正如所讲，硬盘读写本身性能问题不大。因此内存映射主要解决了大模型读过程中内存开销，CPU占用过高等问题。Boost库提供了Interprocess来进行内存映射，内存共享等操作。 策略四：分治并行 在一篇文章入门仿真软件性能优化一文中提到了分治是提升性能最常用的方式，在文件处理中体现在两方面：1.尽可能把大数据按照不同属性放在分散的几个大小接近的文件中，最常见的比如把网格文件中的节点数据和单元放在两个文件里；2.读同一个文件时，统一读取之后使用多线程分块解析，正如前所说，文件读入性能并不在硬盘读取而是在数据解析上。为了最大化分治并行，在文件结构设计上，相同或类似的属性尽可能放在一起，文件内容上，尽可能减少数据冗余度。 策略五：保存几何和渲染映射数据 在三维几何超大模型的加载和显示中，性能瓶颈主要体现在三个方面：1.三维数据的创建；2.三维数据的三角化；3.三角化数据的渲染。如果能够保存几何和渲染映射数据到文件，下次打开文件直接加载该数据。可以避免上述三部操作，大大加快模型数据加载。 策略六：数据轻量化 数据轻量化本质上是把大模型数据中不需要或不重要的部分去掉，或者把原始数据转成另外一种轻量级的格式。对于软件来说，任何从外部导入的数据都需要变成软件内部的数据格式，在这个过程中，可以根据业务做轻量化。在对结果数据处理时也可以有类似操作。 以结构仿真结果为例，比如有限元模型有1亿的节点，应力一般需要计算最大最小和一般应力，XYZ方向也要单独显示，业务需求还要MISES，等效应力等，应变，位移也类似。单个节点上的结果数据以double值计算大概要20-30亿。这种规模数据量使用常规的计算显示方式是无法实现的，所以需要从业务上进行数据轻量化。比如对结果平滑部分进行合并处理；实体单元只显示表面数据；单个结果拆分成多个文件；在不影响性能情况下适当采用压缩算法等。 策略七：避免文件操作过程中的计算 超大模型的读写过程中加入计算逻辑，会进一步影响性能。最常见的是这种网格结构定义： 网格类型 网格节点1 网格节点2 网格节点3 ... 这种设计根据类型来读写后面的数据，表面看起来具有统一的设计，方便实现，但在实际应用中大模型会产生严重性能瓶颈。理想的做法是将某一类型的数据作为一个属性单独操作。上述设计改成： 策略八：规范研发流程 这个属于非技术。以往经验表明，研发中对于文件读写的都是各自为战，且写法各异，有用流，有用c风格，也有使用第三方库的，而每种写法也都有各自的使用方法。在文件小的时候都能实现各自功能，问题不大，但文件大一些之后，有些就容易出现bug和瓶颈。所以规范研发流程，讨论清楚每种方法的利弊和使用场景，将文件读写统一规范使用。 笔者处理过的最大的单个文件在40G左右，如果您有更好的超大模型文件处理经验，也欢迎留言。 |
|
|
