一组CFD计算结果里光网格就有几十万个节点和面每个时间步还要叠加三五组标量场、矢量场再加上湍流模型的一堆参数。前几天还有朋友问我要不要把数据全导成CSV方便后续处理。我当时就回了一句真要这么干一个2000万单元的机翼网格配上100个时间步的流场数据先准备一个能塞下2TB文本文件的硬盘再说。实际上这个问题远不止容量这么简单——文本格式的读取速度、精度损失、文件管理方式在工程规模数据面前全是硬伤。HDF5和CGNS这两个格式就是业内为了解决这些问题沉淀出来的标准答案。我在工业仿真和航空航天数据管理这块折腾了十几年从早期Fortran直接写二进制到后来转HDF5再到接触CGNS感触最深的一点是文件格式从来不是锦上添花的工具而是项目能不能跑下去的地基。这篇文章不打算写成一本文档翻译而是想从一个实际工程项目使用者的角度把HDF5和CGNS的底层逻辑、两者的关系、以及实际读写时踩过的那些坑一次性讲清楚。严格说来这两者不是对位竞争的关系。CGNS经常被人误解成跟HDF5二选一实际上CGNS在数据存储这一层依赖的正是HDF5。理解这一点后面很多选择就顺了。无论你是做CFD、有限元分析、气象模拟还是单细胞测序数据分析只要你的数据集维度高、规模大、结构复杂这篇文章都值得花十分钟读完。1. 数据维度一膨胀文本格式先崩盘很多人对HDF5、CGNS的认知是从读不懂的二进制文件开始的。早年我还在用文本格式存网格和计算结果的时候确实没觉得有什么问题直到数据规模上来问题集中爆发。1.1 一个简单算例背后的数据量级先算一笔账。假设你有一个2000万单元的CFD网格这是今天一个中等规模算例的常态。我们要存的元数据包括单元到节点的连接关系、节点坐标、边界条件标签每个时间步还要存密度、速度分量、压力、温度等多个物理场。用ASCII文本存的话光是节点坐标三列单精度float假设每个数字带符号和小数点约9到10个字符一行就是约30字节2000万行就是600MB。再看单元连接关系每个六面体单元8个节点编号平均每个节点编号约7到8个字符一行约60字节2000万行又是1.2GB。这还没算上每个时间步的物理场数据。100个时间步跑完文本文件轻松突破200GB。更要命的是每次从文本读取解析ASCII的开销极大读这200GB做后处理一个晚上耗进去很正常。二进制格式能大幅压缩体积这大家都能理解。但二进制的格式管理是另一个大坑Fortran的unformatted write在不同编译器、不同平台下字节序和记录标记都不同。我以前接过一个上游合作单位发过来的二进制数据文件对方用Intel Fortran写的我用gfortran程序去读直接乱码。双方整整花了两天去对齐老程序的记录分隔符。这种经历几乎每个做数值仿真的工程师都遇过也是整个行业后来转向自描述、跨平台二进制格式的根源动力。1.2 自描述与层级结构解决的是可读性问题HDF5、CGNS这类格式最核心的思想是把数据本身和描述数据的元数据打包在一起。也就是说打开文件你不需要额外的说明文档就能看出来这个文件里有哪些变量、维度是多少、单位是什么。类比一下文本格式就像你在书架上堆了一排没有标签的纸箱里面装的东西只有你自己知道HDF5则像一套管理井然的档案柜每个抽屉Group上有标签每份档案Dataset附带说明卡Attribute。不知道里面有什么也没关系打开抽屉列表翻一遍就知道。这种结构对于大型项目尤其重要。当你一个项目做了三年文件数量上千个每个文件内部几十个变量没有一套标准的自描述体系后期找数据基本靠考古。而在团队协作场景里一个结构良好的HDF5文件新接手的人十分钟就能熟悉数据组织方式不用追着前人问东问西。2. HDF5不是文件是一个装在文件里的文件系统HDF5全称Hierarchical Data Format version 5它的设计目标从一开始就很明确为科学计算领域提供一种灵活、高效、可扩展的数据存储方案。理解它的结构有几个关键概念必须吃透。2.1 Group、Dataset、Attribute三件套HDF5的底层模型其实非常朴素就三种东西Group分组、Dataset数据集和Attribute属性。Group相当于文件系统里的目录。Group可以嵌套形成一棵树。你可以创建/mesh/volume、/flow/solution_001这样的路径来组织数据。Dataset真正存放数据的地方跟NumPy里的ndarray概念几乎一一对应。每个Dataset包含数据本身还包括元数据比如维度信息、数据类型整数、浮点、字符串等。Dataset不需要是规整的矩形数组HDF5支持分块存储、压缩、无限维度扩展这后面会细说。Attribute挂在Group或Dataset上的小字段适合存放标量式的描述信息。比如time_step、Reynolds_number、mesh_units或者用来指明这个数据集是用CFL3D还是OpenFOAM生成的。举个例子一个典型的气动仿真文件结构可能长这样/mesh /coordinates [N_nodes, 3] float64 /connectivity [N_cells, 8] int32 /boundary_conditions /wall [N_wall_faces, 2] int32 /farfield [N_far_faces, 2] int32 /flow /solution_001 /density [N_nodes] float64 /momentum_x [N_nodes] float64 /energy [N_nodes] float64 /solution_002 ... /attributes /reynolds_number 6.5e6 /mach_number 0.85这种组织的直观性用过的人都懂。写代码的时候不再是你自己设计一套二进制布局然后头疼兼容性而是直接反射这个树状结构想加数据随时加想读哪个变量就定位到对应路径。2.2 分块存储和压缩HDF5的加速引擎我见过不少人对HDF5的印象是读起来挺方便的但性能不行这多半是因为没有用上分块Chunking和压缩Compression。这也是最容易被误解、但收益最大的部分。先说分块。默认情况下HDF5按行存储整个Dataset的连续切片想象一下一个大的二维数组在磁盘上按行排开。如果程序频繁访问的是一个数组的某一列不连续的内存或磁盘区间按连续存储就会触发大量小I/O性能非常差。分块存储把一个Dataset逻辑上切成一个个小砖块每个砖块在文件里独立存放。数据的读写以块为单位进行只有被访问的块才会真正落到磁盘上。举个例子一个形状为[10000, 10000]的浮点矩阵如果设成chunks (1000, 1000)整个数据被划分为10x10共100个块。当程序只读取行范围[2000:3000, 2000:3000]的数据时连续存储可能要扫描几乎整行数据而分块存储只需要读取命中的4个块速度可能差一到两个数量级。压缩则是把块内数据做压缩HDF5默认支持gzip在HDF5里叫deflate、szip、zstd、blosc-lz4等。无损压缩对科学数据的压缩率通常相当可观。我自己实测的CFD流场数据用deflate level 4压缩后体积普遍能缩小50%到70%。对于CFD这类浮点场数据相邻网格点的值变化连续相关性极高压缩效果尤其显著。代价是读取时需要解压会产生额外CPU开销但I/O减少带来的收益往往完全覆盖这个开销尤其在大规模数据集群上。2.3 一个具体的Python读写示例在日常工程中我用的最多的工具是Python的h5py库。它的API跟字典非常接近学习成本很低。下面给一段实际可跑的示例代码演示创建文件、写入一组数据、追加一个时间步、再读出来import h5py import numpy as np # 创建一个HDF5文件 with h5py.File(simulation.h5, w) as f: # 创建两个Group组织目录 mesh_grp f.create_group(mesh) flow_grp f.create_group(flow) # 写入网格坐标假设100万个节点三维 coords np.random.rand(1_000_000, 3).astype(np.float64) mesh_grp.create_dataset(coordinates, datacoords, chunks(100_000, 3), compressiongzip, compression_opts4) # 写入一个标量属性 mesh_grp.attrs[mesh_units] meter # 写入初始流场 density np.random.rand(1_000_000).astype(np.float64) flow_grp.create_dataset(density, datadensity, chunks(100_000,), compressiongzip) # 初始步设为0 flow_grp.attrs[time_step] 0 # 之后追加新的时间步 with h5py.File(simulation.h5, a) as f: flow_grp f[flow] # 检查当前已有多少步 n_steps len([key for key in flow_grp.keys() if key.startswith(solution_)]) new_step_name fsolution_{n_steps 1:03d} # 创建新的Group并写入这一时间步的物理场 new_step flow_grp.create_group(new_step_name) new_density np.random.rand(1_000_000).astype(np.float64) new_step.create_dataset(density, datanew_density, chunks(100_000,), compressiongzip) flow_grp.attrs[time_step] n_steps 1这段代码的运行逻辑很简单第一段创建文件建目录写入带压缩的网格数据和初始流场并挂上属性第二段以追加模式打开同一个文件自动探测已有步数添加新时间步。你会看到h5py的对象创建方式跟操作Python字典几乎一样可读性和上手速度显而易见。2.4 读单个数据集时的可视化从热词里能看到很多人关心HDF5 Python显示的问题也就是怎么把HDF5里的数据可视化。这一步本质上分两件事读出哪个Dataset然后把它喂给Matplotlib或PyVista。以下是一个常见流程import h5py import numpy as np import matplotlib.pyplot as plt with h5py.File(simulation.h5, r) as f: # 查看整体结构 def print_structure(name, obj): if isinstance(obj, h5py.Dataset): print(fDataset: {name}, shape{obj.shape}, dtype{obj.dtype}) else: print(fGroup: {name}) f.visititems(print_structure) # 读取第一个时间步的密度场 density f[flow/solution_001/density][:] # 密度场是1D的节点数据需要根据网格拓扑转为2D或3D数组才能画云图。 # 这里仅演示一维数据的直方图 plt.hist(density, bins100) plt.xlabel(Density (kg/m^3)) plt.ylabel(Node count) plt.title(Density Distribution at t1) plt.show()实际工程中网格数据往往是三维体网格直接可视化要借助PyVista或ParaView读取HDF5后构建UnstructuredGrid。对于单细胞测序数据则是把稀疏矩阵读成scipy.sparse.csr_matrix再做降维聚类。这些后处理步骤五花八门但第一步永远是同一个动作定位到目标Dataset用切片把它读进内存。掌握HDF5的树状结构导航能力就是所有可视化和分析的起点。3. CGNS把约定直接写进了标准HDF5解决了怎么存的问题但它本身不规定存什么。换句话说HDF5是一个万能柜子容量巨大、抽拉灵活但每个格子该放什么完全由使用者自己决定。这在一家公司内部还能靠规范约束一旦需要跨团队、跨软件、跨行业交换数据问题就来了你的density是节点的还是单元的单位是帕斯卡还是大气压网格连接关系的节点索引从0还是1开始CGNS的出现就是冲着这些问题来的。3.1 从CFD出发的标准化之路CGNS全称CFD General Notation System。名字里的CFD直接表明了它的出身上世纪90年代中期NASA联合波音、麦道、NASA Langley等机构想为CFD数据交换制定一个统一标准。早期CFD领域的数据交换非常混乱不同软件各有各的格式用户想把网格从网格生成器挪到求解器再挪到后处理软件往往要经过一长串格式转换中间每一个环节都可能丢掉信息或产生错误。CGNS的核心理念有两个。第一定义一套标准的数据模型给CFD领域里几乎所有数据都规定了统一的命名、路径和存储方式。这套模型称为SIDSStandard Interface Data Structure。第二提供一套与具体存储介质无关的接口方式早期CGNS使用ADFAdvanced Data Format作为底层存储后来为了性能和互操作性的考虑实现了基于HDF5的CGNS版本如今已经是主流。换句话说CGNS回答的是格子里应该放什么、标签怎么写的问题。它把HDF5这个通用柜子做成了按CFD行业习惯布局好的专业档案系统。3.2 CGNS的标准树结构CGNS定义了一套固定的树形结构粗略长这个样子/CGNSTree /Base /Zone /GridCoordinates /CoordinateX /CoordinateY /CoordinateZ /ZoneType /ZoneBC /BC /BCType /FlowSolution /Solution001 /Density /MomentumX /MomentumY /MomentumZ /EnergyStagnationDensity /ReferenceState /SimulationType这些节点路径、允许的子节点、值的单位在CGNS的SIDS文档里都有严格定义。比如Density就是标准节点名单位默认是kg/m^3ZoneType的取值必须从Structured、Unstructured、UserDefined等预定义枚举中选择。你不需要跟对方解释Density到底存的是密度还是比容因为整个行业都认这套字典。3.3 CGNS为何把地基选在HDF5上关于CGNS和HDF5的关系很多人一直没绕清楚。一个常见的误解是CGNS是HDF5的替代品甚至认为CGNS是一种独立文件格式。实际上当前主流的CGNS实现cgnslib 3.x在默认配置下就是把数据存储层构建在HDF5之上的文件的后缀名也统一是.cgns但打开后底层的物理存储结构完全遵循HDF5规则。为什么会选择HDF5而不是继续维护ADF几个原因很实际并行I/O成熟MPI-IO加持下HDF5早就具备了高效的并行读写能力。CGNS要做大规模CFD并行计算跨进程写入同一个文件是刚需直接站在HDF5的肩膀上比自研并行I/O机制划算得多。生态完善HDF5的Python绑定h5py、系统工具h5dump、h5ls、可视化支持ParaView内置HDF5读插件都是一套现成的生态CGNS可以直接复用。数据压缩与分块这部分能力HDF5本身已经非常成熟CGNS无需重复造轮子。所以你现在打开一个.cgns文件完全可以用h5py或者h5dump去查看它的内部结构看到的就是一套由HDF5 Group和Dataset组成的数据树只是这棵树遵循了CGNS的命名约定。3.4 CGNS完整示例新建一个结构化网格并写入为了让你体会CGNS的实际用法我用Python的cgns库基于cgnslib的Python绑定演示一次创建一个简单的三维结构化网格Zone并写入坐标和一步流场import cgns import numpy as np # 新建一个CGNS文件数据层基于HDF5 cgns.open(wing.cgns, w) cgns.goto(/) cgns.create(CGNSTree, CGNSTree) cgns.goto(/CGNSTree) cgns.create(Base, StructuredBase) cgns.goto(/CGNSTree/StructuredBase) # 创建一个Zone维度是50x20x10的结构化网格 nx, ny, nz 50, 20, 10 cgns.create(Zone, wing_zone) cgns.goto(/CGNSTree/StructuredBase/wing_zone) cgns.create(ZoneType, UserDefined) cgns.write(ZoneType, Structured) # 写网格坐标 x np.random.rand(nx, ny, nz).astype(np.float64) y np.random.rand(nx, ny, nz).astype(np.float64) z np.random.rand(nx, ny, nz).astype(np.float64) cgns.create(GridCoordinates, GridCoordinates) cgns.goto(/CGNSTree/StructuredBase/wing_zone/GridCoordinates) cgns.create(DataArray, CoordinateX) cgns.write(CoordinateX, x) cgns.create(DataArray, CoordinateY) cgns.write(CoordinateY, y) cgns.create(DataArray, CoordinateZ) cgns.write(CoordinateZ, z) # 写一步流动解 cgns.create(FlowSolution, Solution001) cgns.goto(/CGNSTree/StructuredBase/wing_zone/FlowSolution/Solution001) cgns.create(DataArray, Density) rho np.random.rand(nx, ny, nz).astype(np.float64) cgns.write(Density, rho) cgns.close()这个例子里有几个关键点说一下。第一ZoneType用Structured才表示这是结构化网格坐标数组要按[Nx, Ny, Nz]存储。第二所有坐标和物理场标准节点名都是大写驼峰比如CoordinateX、Density这个不是随便写的是SIDS定义好的命名规范写错了别的CGNS读取器可能就识别不了。第三create(DataArray, ...)在前write(...)在后跟HDF5的先建Dataset再写数据逻辑一致。实际工程中很少有人直接手写CGNS树大多用cgnslib封装好的高层API或者用Python的pyCGNS。但理解这层树结构对你排查数据问题、调试跨软件交换时的信息丢失非常有帮助。4. HDF5还是CGNS一张表直接对照差距把HDF5和CGNS的定位差异说清楚之后最关键的问题就来了实际项目里到底选哪个我的答案是看你的数据是否需要行业标准的语义约定。HDF5是通用工具箱CGNS是CFD定制的专用方案。两者之间的对比用下面的表格看得更清楚对比维度HDF5CGNS基于HDF5标准定位通用科学数据格式CFD专用数据标准含数据模型约定数据组织自行设计Group/Dataset结构遵循SIDS的固定树结构内置语义无全靠使用者定义节点命名、单位、边界条件类型等均有标准定义单元类型支持需自行定义内建多种网格单元类型六面体、四面体、棱柱等边界条件描述需自行约定标准BCType枚举跨软件通用并行写入原生支持并行通过HDF5并行底层实现支持好压缩原生支持多种压缩插件依赖HDF5底层能力适用场景任意科学数据气象、生物、材料、深度学习训练数据等CFD网格生成、数值模拟、后处理、跨软件交换Python生态h5py非常成熟pyCGNS、cgns.py对比h5py文档较少跨软件交换仅通用性高无行业语义航空、CFD领域事实标准各大软件直接支持从这个表不难看出CGNS的优势不在存储技术层面HDF5能做的它底层都能做CGNS的溢价全部来自那套行业语义约定。如果你的场景是CFD数据跨软件交换比如Gridgen/Pointwise生成网格导出给Fluent或CFL3D再交给Tecplot或ParaView做后处理选CGNS几乎不需要犹豫它把密度单位是谁家的这种破事直接消灭了。反过来如果你的数据是单细胞测序矩阵、气象格点、材料微观结构、深度学习特征向量这些跟CFD传统无关的数据用CGNS反而是自找麻烦因为你得把语义强行塞进CFD那套词汇表里HDF5才是更自然的通用载体。4.1 为什么很多CFD软件内部用HDF5对外用CGNS有一个现象可以加深理解很多CFD软件内部求解器存储中间结果时用的其实是纯HDF5速度最快、结构完全由开发者自己掌控只有到了需要对外交换、出版、归档或跨团队交接时才会导出为CGNS。这背后的逻辑很朴素内部格式追求的是写读速度和存储效率不需要照顾别人的理解成本对外格式追求的是语义一致性和长期可读性让人一看就懂。碰到这种场景HDF5和CGNS根本不是二选一的关系而是构成了内部存储层和外部交换层的分工。这种双层结构在真实的工程项目里非常常见。4.2 从实际项目角度给一个选型建议如果是新手我给的建议非常直接数据只在自己的程序里用或全团队都用同一套代码读写选HDF5自己定义一套清晰的规范省心高效。数据要跟外部软件交换或者项目生命周期超过五年需要归档并保证未来仍可读优先CGNS尤其是CFD领域。数据涉及CFD网格和流场但需要同时兼容机器学习训练管线建议以CGNS为主存储转换出一份HDF5子集给训练框架。两种格式的转换成本并不高关键是要在上游保证语义不丢。5. 实操中最容易栽的几个坑我全部替你踩过格式的选型和原理弄清楚以后实操层面的坑更致命。下面这几条全部是这些年我在真实项目中踩过、或者亲眼见队友踩过的每一条都是硬邦邦的教训。5.1 字符串和编码问题HDF5对字符串的默认处理方式在不同版本之间变化很大。早期h5py默认把Python字符串存储为变长UTF-8但某些老版本C库读出来的是定长ASCII如果写入的数据包含中文或特殊字符轻则读出来乱码重则读取器直接报错。我的建议是跨语言交换的HDF5文件属性字符串不要用中文不要用特殊字符统一ASCII安全字符集。如果必须用长文本用numpy的定长字符串类型显式声明并做好编码约定。5.2 文件锁和跨平台共享HDF5文件的并发写是单写者多读者的模型同一时刻只允许一个进程打开文件写入但多个进程可以同时读。这在单机环境不痛不痒一旦放到共享文件系统比如NFS、GPFS上坑就来了。HDF5的锁机制在不同版本、不同文件系统上的行为并不一致早期版本在NFS上可能引发文件损坏。我们在集群上踩过一次两个节点的后处理进程同时尝试对同一个HDF5文件做追加写入结果文件元数据冲突整个文件报废只能从备份恢复。教训就是任何涉及写入的操作必须通过任务调度机制比如SLURM作业、Python的multiprocessing加文件互斥锁保证单写者模型。读操作再频繁都没关系写操作一定不能并发。5.3 追加数据集时维度不匹配HDF5支持对Dataset做无限扩展但前提是创建数据集时设置了maxshape(None, ...)。很多人创建数据集时只传data...没有预留最大维度之后想追加新时间步时发现维度写不进去只能重新拷贝文件。h5py的解决办法是创建数据集时显式指定maxshapedset f.create_dataset(flow, shape(0, N_nodes), maxshape(None, N_nodes), dtypef8) # 追加新时间步 dset.resize((current_steps 1, N_nodes)) dset[current_steps, :] new_field这是一个非常经典的最佳实践从一开始就把时间维设计成可扩展的后面每个时间步做完就往里塞一行不需要反复创建新数据集。我在CFD瞬态数据的存储里一直用这个模式配合chunking和deflate压缩存储效率和读写速度都很理想。5.4 误把CGNS当成HDF5的附加包前面说过CGNS底层用HDF5但这不代表HDF5的API可以直接读CGNS文件并且语义正确。CGNS的树结构里除了普通Dataset还有大量特殊节点比如CGNSLibraryVersion、DataClass、DimensionalUnits这些节点的数据格式跟HDF5默认读写方式不完全一致。如果用h5py直接去读CGNS文件里的字符串节点读出来的是字节串需要手动解码。命令行工具倒是很方便直接执行h5dump wing.cgns就能一览CGNS在HDF5层级的完整结构。但生产环境读取CGNS数据我还是建议用pyCGNS或者cgnslib的API走正规路径让库帮你处理那些特殊节点的语义转换省得手动适配。5.5 压缩等级不是越高越好HDF5的deflate压缩等级从0到9很多人在想压缩得狠一点直接拉到9。观测下来等级4到6往往是最优区间。等级更高压缩率提升非常有限但压缩和解压的CPU时间会几倍地增长。对于单次写入、多次读取的归档类数据牺牲写入时间换压缩率是可以接受的但对于仿真过程中随时在读写的数据等级4已经足够更关键的是压缩与分块要搭配使用压缩只对整块进行块大小设置不好压缩率会大打折扣。chunk大小建议按一次实际读取的子区域来设计比如你经常读某一片空间区域chunk就跟那片区域对齐。6. 单细胞等非CFD场景下的HDF5读取从热词里能看到单细胞hdf5数据如何读取是很多人搜的方向。单细胞数据跟CFD数据虽然领域完全不搭边HDF5的读取逻辑却惊人地一致。单细胞数据里最常见的HDF5格式是10x Genomics的h5文件核心内容是一个稀疏矩阵基因表达量按[genes, cells]组织但绝大多数位置是0所以文件里存放的是非零数据的索引和数值。用Python读取的基本流程是import h5py import numpy as np import scipy.sparse as sp with h5py.File(filtered_feature_bc_matrix.h5, r) as f: # 数据结构一般为 /matrix 目录 print(list(f.keys())) data f[matrix/data][:] indices f[matrix/indices][:] indptr f[matrix/indptr][:] shape f[matrix/shape][:] # 特征基因信息 feature_names f[matrix/features/name][:] gene_ids f[matrix/features/id][:] # 恢复成稀疏矩阵 counts sp.csc_matrix((data, indices, indptr), shapetuple(shape))关键点在于single-cell矩阵的存储方式是CSCCompressed Sparse Column格式indptr标记每一列非零元素的起点和终点indices是行索引data是对应的表达量。看懂这个三元组把稀疏矩阵恢复出来就轻而易举。这套思路跟CFD读网格坐标没什么本质区别都是先看结构再定位数据最后按自己的数据结构重组。HDF5的通用性在这里体现得淋漓尽致。7. 追加压缩、并行写入与格式转换的最后建议我知道很多人读到这里真正关心的问题可能是我已经确定了用HDF5或者CGNS接下来该怎么落地。前面讲原理和踩坑已经覆盖了主要路径但还有几个容易忽略的设计细节值得最后单独说一下。第一如果确定要长期使用HDF5作为主存储格式建议尽早把压缩选项和chunk形状纳入项目编码规范。同一套数据不同的人第一次创建文件时随手写的chunk和压缩选项可能完全不同后期合并比对会很痛苦。我们团队的做法是所有新文件创建统一走一个封装函数内部固定chunk策略、压缩算法和压缩等级。项目成员不用纠结这些参数同时保证文件层面的统一性长期归档可维护性大幅提升。第二并行I/O是规模化计算的必经之路。当你的计算进程数上百甚至上千每个进程都往同一个HDF5文件里写数据的时候需要走HDF5的并行接口。核心要点是所有进程同时打开同一个文件采用MPI_Info设置文件访问属性并使用PCollection或h5py.File(..., drivermpio, commMPI.COMM_WORLD)的方式确保集体I/O正确执行。以下是一个最简单的MPI并行写示例骨架from mpi4py import MPI import h5py import numpy as np comm MPI.COMM_WORLD rank comm.Get_rank() size comm.Get_size() # 每个进程写入一个区间段 N_per_rank 100 data np.full(N_per_rank, rank, dtypenp.float64) with h5py.File(parallel.h5, w, drivermpio, commcomm) as f: dset f.create_dataset(field, shape(N_per_rank * size,), dtypef8) start rank * N_per_rank dset[start:start N_per_rank] data注意drivermpio一定要在文件创建时就指定并且所有进程调用这段代码时的文件打开模式必须一致。写完之后用任意一个进程读取全量数据进行验证确认每个rank写入的正是自己的区间。这套方法在千核级别的CFD计算里配合HDF5的chunked布局和deflate压缩读写性能和数据体积都能得到很好的平衡。第三关于HDF5和CGNS的转换真到了需要转的时候别自己造轮子。CGNS本身提供的cgns_to_hdf5和hdf5_to_cgns工具已经足够可靠Python环境下pyCGNS也提供了高层转换接口。转换之前的关键动作是盘点语义映射特别是单位、坐标系约定、边界条件类型这些容易在转换中丢失的元数据先确认目标格式的树结构怎么组织再执行转换避免转换完才发现某个关键信息丢了。说实话格式本身并不性感HDF5和CGNS的光环往往被高性能计算、人工智能这些热词盖过但它们才是数据工程真正承重墙的一部分。踩过这么多坑之后我最大的体会是一份数据格式选型方案、一套稳定的存储实现比多写几千行业务代码更有长远价值。尤其是项目做到后期数据规模上来团队换人如果存储层是乱的整个项目会陷入持续救火。反过来格式用对了后面维护、交接、扩展都会顺很多。希望这篇梳理能帮你少走这段弯路。