3. 制造质量数据模型总体架构设计

制造质量数据模型的总体架构，本质上要回答三个层次的问题：业务上“质量是什么”、系统上“数据怎么组织”、存储上“数据放在哪里”。这三个问题分别对应概念模型、逻辑模型和物理模型，它们不是三份可以互相替代的文档，而是一条自上而下、逐层收敛的设计链。概念模型决定口径，逻辑模型决定结构，物理模型决定性能与成本。任何一层缺失或错位，都会在后续的质量分析中表现为“指标对不上”“查询跑不动”或“口径反复改”的典型问题。

三层模型的分工与收敛关系

概念模型面向业务人员和质量管理者，用最少的实体和关系描述质量领域的核心对象。它不关心字段类型、不关心主键，只回答“有哪些质量对象、它们之间是什么关系”。在制造质量场景中，典型的概念实体包括：产品与物料、工序与工位、检验任务、缺陷现象、质量特性、批次与序列号、供应商、设备与工装。概念模型的关键产出是统一术语和口径，例如“一次合格率”到底以检验任务为分母还是以产出数量为分母，必须在概念层就锁定，否则逻辑层无论怎么设计都会产生歧义。

逻辑模型把概念实体转化为可实现的表结构或数据结构，明确主键、外键、粒度、维度与事实的划分。它是数据仓库建模的核心战场，需要决定采用星型模型、雪花模型还是宽表，需要决定质量事实表的粒度是“一次检验一行”还是“一个批次一行”。逻辑模型还要处理缓慢变化维，例如产品工艺路线变更、供应商更名、检验标准版本升级，这些都会影响历史数据的可追溯性。

物理模型则落到具体的存储引擎、分区策略、索引、压缩、分布键和文件格式。同一个逻辑模型，在关系型数据库中可能表现为分区表加复合索引，在数据湖中可能表现为按日期分区的 Parquet 文件，在湖仓一体中可能表现为带事务日志的 Delta 或 Iceberg 表。物理模型的选择直接决定查询延迟、存储成本和并发能力。

从概念到逻辑：质量事实表的粒度选择

逻辑模型设计中最关键的决策是事实表粒度。以检验数据为例，可选粒度包括“一次检验一行”“一个检验项一行”“一个批次一行”。粒度越细，分析灵活性越高，但数据量和查询复杂度也越大。实际工程中常见的做法是采用“一次检验项一行”作为主事实表粒度，因为质量分析经常需要下钻到具体检验项，例如某工位某尺寸的 CPK 趋势。此时事实表字段包括：检验项ID、检验任务ID、产品ID、工序ID、设备ID、检验时间、实测值、规格上限、规格下限、判定结果、缺陷代码。维表则围绕产品、工序、设备、供应商、时间展开。

对于缺陷数据，由于一次检验可能发现多个缺陷，且缺陷与工序之间是多对多关系，需要引入桥接表。桥接表记录检验项ID与缺陷代码的对应关系，并附带缺陷数量、严重等级等度量。这样既能支持“某缺陷在哪些工序高发”的分析，也能支持“某工序的主要缺陷构成”的追溯。

数据仓库、数据湖与湖仓一体的选型逻辑

三种架构并非互相替代，而是面向不同数据阶段和不同分析负载。数据仓库适合承载已经清洗、建模、口径稳定的质量指标数据，支撑固定报表和强一致查询。它的优势是 SQL 兼容性好、事务能力强、查询性能可预期；劣势是存储成本较高、对半结构化和原始数据支持弱、扩展性受限于专有引擎。

数据湖适合承载原始检验数据、设备日志、图像元数据、MES 事件流等尚未建模的数据。它以对象存储为底座，采用 Parquet、ORC 等开放列式格式，按日期或产线分区，成本低、扩展性好。但数据湖缺乏事务保证，容易出现小文件问题、并发写入冲突和“读脏数据”的风险，需要额外的治理手段。

湖仓一体在数据湖之上引入表格式层，典型代表是 Delta Lake、Apache Iceberg 和 Apache Hudi。它们提供 ACID 事务、模式演进、时间旅行和增量读取能力，使数据湖具备数据仓库级别的可靠性，同时保留开放格式和低成本存储。对于制造质量场景，湖仓一体尤其适合处理“检验数据持续追加、缺陷数据频繁更新、质量指标需要按小时刷新”的混合负载。

选型决策的实操判断

实际选型时，可以先回答四个问题：第一，数据是否已经建模且口径稳定？如果是，优先数据仓库。第二，是否需要保留原始明细和半结构化数据？如果是，数据湖不可跳过。第三，是否存在频繁的增量更新和近实时质量看板需求？如果是，湖仓一体更合适。第四，团队是否具备维护表格式和小文件合并的运维能力？如果否，湖仓一体的收益可能被运维成本抵消。

无论选择哪种存储架构，三层模型的设计顺序不能颠倒。概念模型先锁定“一次合格率”“缺陷率”“CPK”等指标的业务定义和计算口径；逻辑模型再确定事实表粒度、维表结构和桥接关系；物理模型最后根据查询模式、数据量和成本约束选择存储引擎、分区策略和文件格式。只有这条链路完整且一致，质量数据模型才能真正支撑从日报到实时看板、从单点追溯到全流程质量分析的各种需求。