📚 课程目录第3章工程分析平台数据架构

3. 工程分析平台数据架构：平台典型数据流、数据仓库与数据湖的融合、元数据管理的重要性

工程分析平台的数据架构是支撑主数据集成与访问控制联动配置的骨架。一个设计良好的数据架构，需要清晰定义数据从采集到消费的流动路径，合理融合数据仓库与数据湖的存储优势，并通过元数据管理实现数据的可发现、可理解与可管控。本章将围绕这三个核心维度展开。

工程分析平台的数据流通常遵循“采集 → 集成 → 存储 → 计算 → 服务”的五阶段模型。每个阶段都涉及不同的数据形态与处理逻辑。

    关键洞察： 在“集成”阶段，主数据（如设备编码、物料号、组织架构）必须与业务数据完成关联，并打上访问控制标签（如部门、密级），后续所有阶段才能基于标签执行权限过滤。

下图展示了工程分析平台中一条典型的“设备振动数据”从采集到仪表盘展示的完整流动路径，并标注了主数据标签注入点。

工程分析平台需要同时处理大规模原始文件（如仿真结果、3D 模型）和高性能结构化查询（如报表、KPI 看板）。单一架构难以兼顾，因此采用“湖仓一体”架构，即数据湖与数据仓库的融合。

架构原则： 数据湖（Data Lake）负责“存”，以原始格式存储所有数据，成本低、灵活性高；数据仓库（Data Warehouse）负责“管”，对结构化数据进行建模、聚合与权限管控，查询性能高。两者通过统一的元数据层和存储层（如 Iceberg / Delta Lake）实现无缝互通。

下表对比了两种模式在工程分析场景下的典型分工：

下图展示了湖仓一体架构中，数据如何从湖流入仓，以及主数据如何作为“粘合剂”贯穿两层。

常见误区： 不要试图将所有数据都加载到数据仓库中。工程分析中的大型二进制文件（如仿真结果 .h5、点云 .las）应保留在数据湖中，仓库只存储其元数据索引（如文件路径、仿真参数、关联设备ID）。这样既能保持仓库查询性能，又不浪费湖的存储成本。

元数据是“关于数据的数据”。在工程分析平台中，元数据管理直接决定了主数据集成与访问控制能否落地。没有良好的元数据，数据湖会退化为“数据沼泽”，数据仓库的权限模型也无法追溯。

元数据管理在平台中承担三大核心职责：

    最佳实践： 建议在平台建设初期就引入企业级元数据管理工具（如 Apache Atlas、DataHub 或 Alation），并将主数据模型作为“黄金实体”注册到元数据中心的实体注册表中。后续所有数据集成任务都必须引用该注册表，确保主数据 ID 和标签的一致性。

下图展示了元数据如何作为“中枢神经”连接数据源、主数据、访问控制策略和数据消费端。

实施建议： 在工程分析平台中，元数据管理不应是事后补充，而应与数据管道同步建设。建议在每条数据管道上线前，先在元数据中心注册其输入输出实体、主数据关联字段以及预期的访问控制标签。这能大幅减少后期数据治理的返工成本。