3. 工程分析数据平台架构
工程分析数据平台是支撑主数据迁移与血缘链路分析的核心基础设施。本章从分层架构视角，系统阐述平台的整体设计、各层职责及核心组件，帮助学员建立全局架构认知。
3.1 平台整体架构（五层模型）
平台采用经典的五层数据架构，自下而上依次为：数据源层、采集层、存储层、计算层、服务层。各层职责清晰、解耦独立，通过统一元数据与血缘引擎实现端到端数据治理。
3.2 各层职责与核心组件
3.2.1 数据源层
数据源层是平台的数据起点，涵盖工程分析领域所有结构化与非结构化数据源。主数据迁移的核心源端通常包括产品生命周期管理（PLM）、企业资源计划（ERP）、制造执行系统（MES）及工业物联网（SCADA）等。
| 数据源类型 | 典型系统 | 数据特征 | 主数据对象 |
|---|---|---|---|
| 产品数据 | PLM / PDM | 结构化、版本化、多属性 | 物料BOM、零部件编码 |
| 业务数据 | ERP / SAP | 事务性、高一致性要求 | 供应商、客户、物料主数据 |
| 生产数据 | MES / QMS | 实时、高频、多维度 | 工单、设备、工艺路线 |
| 时序数据 | SCADA / IoT | 高吞吐、时间戳密集 | 传感器、测点、设备参数 |
3.2.2 采集层
采集层负责将数据源层的数据实时或批量接入平台。针对主数据迁移场景，采集层需要支持全量快照与增量变更捕获两种模式，确保主数据的一致性与时效性。
- Canal：基于MySQL binlog的实时增量采集组件，用于捕获ERP/PLM中的主数据变更事件。
- Flume：日志级批量采集框架，适用于MES/SCADA的日志文件与流式数据接入。
- Kafka Connect：连接器生态丰富，支持JDBC、HDFS、S3等数据源的标准化采集。
- DataX / Sqoop：离线批量同步工具，用于主数据全量初始化迁移。
实践建议：主数据迁移初期建议采用“全量+增量”双轨策略——先通过DataX完成全量同步，再通过Canal实时捕获增量变更，确保数据迁移无缝衔接。
3.2.3 存储层
存储层是平台的数据底座，采用冷热分层与多模态存储策略。主数据仓库与血缘元数据存储是本章关注的重点。
| 存储组件 | 用途 | 数据模型 | 主数据场景 |
|---|---|---|---|
| HDFS | 原始数据湖、历史归档 | 文件/Parquet/ORC | 主数据全量快照存储 |
| HBase | 实时主数据明细查询 | 宽表、列族 | 主数据实时索引与关联 |
| ClickHouse | 聚合分析、报表加速 | 列式存储 | 主数据质量统计与血缘分析 |
| MySQL / TiDB | 元数据管理、配置存储 | 关系模型 | 主数据字典、映射关系 |
3.2.4 计算层
计算层承担数据清洗、主数据合并、血缘解析等核心处理逻辑。平台采用批流一体计算架构，兼顾离线全量处理与实时增量计算。
- Apache Spark：离线批处理引擎，用于主数据全量清洗、去重、标准化转换。
- Apache Flink：实时流处理引擎，用于主数据变更事件的实时合并与血缘链路构建。
- Atlas / 自研血缘解析器：嵌入计算任务中，自动解析数据输入输出关系，生成血缘链路。
- 规则引擎（Drools / 自研）：主数据质量校验与冲突检测，支持自定义校验规则。
关键设计：计算层通过“主数据合并算子”统一处理来自多源的主数据冲突，采用“时间戳+优先级”策略决定最终版本，确保主数据唯一性与权威性。
3.2.5 服务层
服务层面向数据消费者与治理人员，提供统一的数据访问、目录检索与血缘可视化能力。服务层是平台能力的对外窗口。
| 服务组件 | 功能描述 | 主数据迁移价值 |
|---|---|---|
| 数据API网关 | RESTful / GraphQL 接口统一暴露 | 主数据查询、变更推送 |
| 自助分析门户 | 拖拽式数据探索与报表 | 主数据质量看板、迁移进度监控 |
| 数据目录 | 元数据检索、数据资产地图 | 主数据资产盘点、字段级血缘 |
| 血缘可视化 | DAG图展示数据流转链路 | 主数据来源追溯、影响分析 |
3.3 核心组件协作关系
为帮助学员理解各组件在实际主数据迁移流程中的协作方式，下图以主数据变更事件为例，展示从数据源到服务层的完整链路。
3.4 架构设计要点总结
| 架构维度 | 设计要点 | 主数据迁移影响 |
|---|---|---|
| 分层解耦 | 各层通过消息队列/API 松耦合 | 支持主数据源灵活接入与替换 |
| 批流一体 | Spark 离线 + Flink 实时 | 全量初始化与增量变更无缝衔接 |
| 元数据驱动 | 统一元数据管理，自动血缘采集 | 主数据来源可追溯、影响可分析 |
| 多模态存储 | HDFS/HBase/ClickHouse 各司其职 | 主数据存储兼顾性能与成本 |
| 服务化封装 | API 网关统一暴露数据能力 | 主数据消费方与底层存储解耦 |
常见误区：部分项目在架构设计阶段过度追求组件“大而全”，引入过多中间件导致运维复杂度飙升。建议根据主数据规模与实时性需求，优先采用“最小可行架构”，后续按需演进。