4. 归档数据模型设计

卫星测控数据归档的核心矛盾在于：数据体量巨大、类型异构、生命周期长，而追溯查询又要求快速定位到某颗星、某台设备、某个参数、某个时间点的原始记录。因此，归档数据模型不是单一数据库选型问题，而是“元数据标准 + 数据字典 + 存储模型”三层协同设计问题。元数据标准解决“怎么描述”，数据字典解决“怎么统一口径”，存储模型解决“怎么放、怎么查”。

一、元数据标准：让归档对象可被发现、可被解释

卫星测控归档对象通常包括原始遥测帧、遥控指令记录、轨道根数、测距测速数据、设备状态日志、处理中间产品等。若没有统一元数据，同一份数据在不同系统中可能被命名为“TM_RAW”“telemetry_raw”“遥测原始帧”，追溯时无法自动关联。建议采用“核心元数据 + 领域扩展”的结构：核心元数据描述标识、来源、时间、格式、版本、密级、校验值；领域扩展描述卫星标识、测站标识、测控弧段、通道号、参数代号、处理级别。

一个可落地的元数据记录示例（JSON 形式，字段为示例设计）如下：

{
  "object_id": "SAT-07_TM_20240512T031500Z_RAW",
  "satellite_id": "SAT-07",
  "ground_station": "Kashi",
  "pass_id": "P20240512_0315",
  "data_type": "telemetry_raw",
  "start_time": "2024-05-12T03:15:00Z",
  "end_time": "2024-05-12T03:22:30Z",
  "format": "CCSDS-TM-Frame",
  "version": "v1.2",
  "checksum": "sha256:9f2c...",
  "security_level": "internal",
  "storage_uri": "s3://sat-archive/SAT-07/2024/05/12/raw/"
}

其中 object_id 是全局唯一标识，pass_id 关联一次测控弧段，storage_uri 指向实际存储位置。元数据本身应存入关系库或元数据服务，保证可按卫星、时间、类型、测站等条件快速检索。

二、数据字典：统一参数口径与编码含义

数据字典是元数据的“语义底座”。测控数据中大量使用参数代号，如 P001、V_BUS、TEMP_A，若不记录其含义、单位、量程、采样率、所属分系统，追溯时只能看到数字而无法解释。数据字典至少应包含：参数代号、中文名称、英文名称、单位、数据类型、量程下限、量程上限、采样周期、所属分系统、有效起始日期、失效日期。

例如，参数 V_BUS 可定义为：母线电压，单位 V，量程 24.0～32.0，采样周期 1 s，所属分系统为电源分系统，有效起始日期为 2024-01-01。这样，当追溯查询到某时刻 V_BUS=28.6 时，系统能自动判断其是否在正常范围内，并关联到电源分系统。

三、时序数据模型：面向高频遥测的参数—时间—值结构

遥测参数具有典型时序特征：按时间连续到达，写多读少，查询常按“卫星 + 参数 + 时间范围”进行。时序数据模型通常采用“标签 + 时间戳 + 值”的结构。标签用于标识卫星、分系统、参数代号、测站等维度；时间戳精确到毫秒或微秒；值可为浮点、整型、布尔或字符串。

以 InfluxDB 风格为例，写入点可表示为：

telemetry,satellite=SAT-07,param=V_BUS,station=Kashi value=28.6 1715483700000000000
telemetry,satellite=SAT-07,param=TEMP_A,station=Kashi value=21.3 1715483700000000000

时序模型的优势是写入吞吐高、时间范围聚合快、压缩比好；劣势是关系表达能力弱，不适合存储复杂的指令—响应关系、审批流程和跨表关联。因此，它适合作为遥测参数值的“主存储”，但不适合单独承担全部归档追溯职责。

四、关系模型与对象存储：结构化关联与大文件承载

关系模型适合存储元数据、数据字典、弧段信息、设备台账、指令记录、处理任务、用户查询日志等结构化数据。其优势是事务一致性、外键关联、复杂条件查询和成熟生态。例如，可用一张 pass 表记录弧段，一张 telemetry_file 表记录原始帧文件，一张 parameter_dict 表记录参数定义，通过 pass_id、satellite_id 等字段关联。

对象存储适合存放原始遥测帧文件、遥控指令日志、轨道产品、图像、压缩包等大对象。它按对象键寻址，容量近乎无限，成本低，适合长期归档。对象存储不擅长复杂查询，因此通常与关系库配合：关系库存元数据和索引，对象库存实际文件，查询时先查元数据拿到 storage_uri，再回源读取对象。

五、选型对比与组合建议

四种模型并非互斥，而是按数据特征分工。下表给出示例性对比：

推荐组合为：关系库 + 时序库 + 对象存储 + 元数据服务。关系库保存数据字典、弧段、指令、任务和索引；时序库保存遥测参数值；对象存储保存原始帧和产品文件；元数据服务统一编目并对外提供检索入口。追溯时，用户先按卫星、时间、参数检索元数据，定位到弧段和对象 URI，再从时序库取参数值、从对象存储取原始帧，形成完整证据链。

实际落地时，建议先冻结元数据标准与数据字典版本，再确定时序库和对象存储的键设计。例如对象键可采用 satellite_id/year/month/day/pass_id/data_type/object_id 的层级，既便于生命周期策略，也便于按弧段批量回取。关系库中的 pass 表与 telemetry_file 表通过 pass_id 关联，telemetry_file 表再记录 object_id 与 storage_uri，即可实现从“某次弧段”到“原始帧文件”的精确追溯。