2. 工程分析平台概述：平台定位、核心功能模块、数据流转架构
工程分析平台是承载指标管理与质量治理的统一技术底座。它不再是一个单纯的 BI 报表工具，而是面向数据工程师、分析工程师与业务产品经理的协同工作台，核心价值在于将“指标定义—数据开发—质量校验—线上发布”全链路纳入同一套配置体系。
2.1 平台定位
平台定位可概括为三个关键角色：
| 角色维度 | 定位描述 |
|---|---|
| 指标管理中心 | 统一管理所有业务指标的元数据、口径、血缘与版本，消除跨团队口径不一致问题。 |
| 质量治理引擎 | 将数据质量规则（完整性、准确性、及时性等）与指标口径绑定，实现配置即监控。 |
| 协同配置门户 | 提供可视化配置界面与 API 接口，支持数据开发、质量巡检、业务验收三方协作。 |
实践要点：平台定位决定了后续所有功能模块的边界。建议在平台建设初期就明确“不做什么”——例如不替代实时计算引擎、不存储明细数据，只做元数据与规则的协同编排。
2.2 核心功能模块
平台按职责划分为六大核心模块，各模块之间通过统一的元数据服务进行通信：
- 指标注册中心：支持原子指标、派生指标、复合指标的分层注册，自动生成指标编码与版本号。
- 口径配置引擎：提供 SQL 模板、UDF 函数注册、业务逻辑表达式编辑器，支持口径的在线调试与比对。
- 质量规则工厂：预置空值检测、唯一性校验、波动阈值、跨表一致性等规则模板，支持自定义规则脚本。
- 调度与执行器：对接离线数仓（Hive/Spark）与实时链路（Flink），统一管理指标计算与质量校验的调度周期。
- 血缘与影响分析：自动解析口径 SQL 与质量规则中的表级、字段级血缘，支持变更影响面评估。
- 监控告警看板：集中展示指标产出状态、质量规则执行结果、异常事件与告警通知。
模块间关键约束：质量规则工厂必须依赖指标注册中心中的指标 ID 进行绑定，不允许独立创建规则。这一约束保证了“无指标、不质检”的治理原则。
2.3 数据流转架构
平台的数据流转分为配置流与数据流两条主线。配置流负责将用户在前端配置的口令、规则、调度参数写入元数据库；数据流则驱动实际的计算与校验任务在底层引擎上执行。
下图展示了平台的整体数据流转架构：
配置流与数据流在元数据服务层完成汇合：用户在前端配置的指标口径与质量规则，经过元数据服务解析为可执行的作业描述，再下发给离线或实时执行引擎。执行引擎将计算结果与质量校验结果写回数据输出层，最终由监控告警看板消费。
常见误区：很多团队在初期将配置流与数据流混在同一管道中处理，导致配置变更后无法追溯历史数据。建议严格分离两条流的存储——配置变更写入元数据库（MySQL/PostgreSQL），数据结果写入分析型数仓（ClickHouse/Doris），互不干扰。
2.4 架构设计要点总结
下表从三个维度总结了平台架构设计的关键考量：
| 维度 | 设计要点 | 常见反模式 |
|---|---|---|
| 扩展性 | 元数据服务采用插件化设计，支持新增引擎类型（如 Flink、Spark）时无需修改核心逻辑 | 将引擎适配代码硬编码在配置层，每接入一个新引擎就要改前端逻辑 |
| 一致性 | 指标口径与质量规则共用同一份元数据，避免规则与口径版本不同步 | 质量规则独立维护一套口径副本，导致口径更新后规则仍按旧口径校验 |
| 可观测性 | 每条配置变更、每次任务执行都生成可追溯的事件日志 | 仅记录最终结果，无法排查“某次口径修改后质量规则为何失效” |