# 数据集平台系统架构与数据流全景说明

## 一、系统整体定位

这是一个**企业级AI数据集治理平台**，核心使命是将分散在各业务系统（Token运营平台、AI工作台）中的原始数据，经过**采集→清洗→脱敏→分类→标注→质量评估→审核→版本管理**的全链条处理，最终形成高质量、合规、可追溯的标准化数据集，供下游AI模型训练、数据分析等场景使用。

---

## 二、系统分层架构总览

系统采用**七层架构**设计，自上而下分别为：

| 层级 | 职责 | 核心组件 |
|------|------|----------|
| **数据源层** | 产生原始数据的外部系统 | Token运营平台、AI工作台 |
| **采集接入层** | 将数据从源端接入平台 | 采集网关、消息队列、调度器 |
| **数据处理层** | 对原始数据进行加工治理 | 清洗、脱敏、分类、标注、质量评估引擎 |
| **审核管理层** | 对处理后的数据进行合规审批 | 工作流引擎、审核后台 |
| **数据集管理层** | 对通过审核的数据进行版本化管理 | 数据集服务、版本控制、存储管理 |
| **数据服务层** | 对外提供数据展示和输出能力 | 看板后端、WebSocket推送、开放API |
| **治理与审计层** | 保障系统安全合规可追溯 | 元数据中心、权限控制、审计日志、链路追踪 |

各层之间通过**Kafka消息队列**和**RESTful/gRPC接口**进行异步解耦和同步调用，基础设施层（Kubernetes + Prometheus + Grafana）为全系统提供容器编排、监控告警和弹性伸缩能力。

---

## 三、端到端数据流转全流程

### 3.1 完整数据链路（10个关键步骤）

```
步骤1：数据产生
  └─ Token运营平台记录用户调用日志（每次API调用的输入输出）
  └─ AI工作台记录问答对话、文件解析结果、知识引用记录
  └─ 这些数据通过Kafka Producer实时写入消息队列

步骤2：数据采集
  └─ Go采集网关作为Kafka Consumer，持续消费数据流
  └─ 网关进行初步校验（字段完整性、格式合法性）
  └─ 校验通过的数据写入Kafka的"待处理"分区，失败的进入死信队列

步骤3：数据清洗
  └─ Python清洗引擎拉取"待处理"数据
  └─ 执行去重（基于TraceID）、空值填充、格式标准化、字段映射
  └─ 清洗后的数据回写Kafka的"已清洗"主题

步骤4：数据脱敏
  └─ Python脱敏引擎消费"已清洗"数据
  └─ 自动识别敏感字段（手机号、身份证、邮箱等）
  └─ 根据策略中心配置执行掩码/AES加密/SM4加密
  └─ 脱敏后数据进入"已脱敏"主题

步骤5：智能分类
  └─ Python分类引擎读取"已脱敏"数据
  └─ 结合规则匹配和机器学习模型自动打标
  └─ 按行业（金融/医疗/政务）、场景（对话/问答/材料生成）、来源自动归类
  └─ 分类结果写入"已分类"主题

步骤6：数据标注
  └─ Python标注引擎处理"已分类"数据
  └─ 先通过预训练NLP模型进行半自动预标注
  └─ 低置信度样本推送至人工标注台（Vue前端）
  └─ 标注完成后数据进入"已标注"主题

步骤7：质量评估
  └─ Python质量评估引擎对每条/每批数据打分
  └─ 从完整性、准确性、一致性、时效性、合规性五个维度综合评分
  └─ 低于阈值（如0.75分）的数据打回重新处理或标记为低质量
  └─ 评分结果作为元数据附加到数据集上

步骤8：合规审核
  └─ 质量达标的数据触发Go工作流引擎（Temporal）
  └─ 启动多级审批流程：提交→初审→复审→归档
  └─ 审核人员通过审核台（Go + Gin后台）查看数据详情和敏感级别
  └─ 审核通过的数据进入"待入库"状态

步骤9：数据集版本化管理
  └─ Go数据集管理服务接收审核通过的数据
  └─ 创建新数据集或已有数据集的新版本
  └─ 采用Delta差异算法存储（每10个版本做一次全量快照）
  └─ 元数据存入MySQL，实际数据文件存入MinIO/OSS对象存储

步骤10：数据服务与消费
  └─ 看板API（Go）聚合各类统计信息，通过WebSocket实时推送给前端
  └─ 看板前端（Vue3 + ECharts）展示数据量、质量趋势、行业分布、审核状态
  └─ 第三方系统通过标准化gRPC/REST接口订阅或拉取数据集
  └─ 全链路审计日志写入ELK，权限控制贯穿所有操作
```

### 3.2 数据流转过程中的关键决策点

| 决策点 | 触发条件 | 处理逻辑 | 去向 |
|--------|----------|----------|------|
| **采集校验失败** | 字段缺失/格式错误 | 记录失败原因，写入死信队列 | 人工排查或重试 |
| **质量评分过低** | 综合评分 < 0.75 | 标记为"待优化"，触发人工复核 | 退回处理层重新加工 |
| **敏感级别过高** | 合规性评分 < 0.6 | 拒绝入库，强制人工审核 | 进入特殊审批流程 |
| **版本回滚需求** | 用户发起回滚操作 | 从Delta日志重建指定版本 | 生成新版本号并标记为回滚版 |
| **存储策略切换** | 数据集达到阈值（如100万条） | 增量存储切换为快照模式 | 创建全量快照释放Delta累积 |

---

## 四、各模块功能配合关系

### 4.1 采集网关与数据处理引擎的配合

采集网关（Go）和数据处理引擎（Python）通过**Kafka主题分区**实现解耦：

- 采集网关负责"生产速度"，确保高吞吐数据不丢失
- 数据处理引擎负责"消费能力"，按自身处理速度拉取数据
- 当处理引擎消费能力不足时，Kafka自动积压起到**削峰填谷**作用
- 两者通过**消费者组**机制实现水平扩展，互不阻塞

### 4.2 数据处理引擎内部各子模块配合

六个子模块形成**流水线（Pipeline）**架构：

```
原始数据 → [清洗] → [脱敏] → [分类] → [标注] → [质量评估] → 待审核
   ↑         ↑         ↑         ↑         ↑          ↑
   |    规则库    策略中心   模型库   标注平台   评分模型
   └─────── 各模块通过Kafka主题串联，异步并行 ───────┘
```

每个模块独立部署，**通过Kafka主题传递数据**，实现了：
- **弹性伸缩**：瓶颈模块可单独扩容
- **故障隔离**：单个模块宕机不影响上下游
- **灰度发布**：可单独升级某个处理环节

### 4.3 工作流引擎与数据集管理的联动

审核通过后，工作流引擎（Temporal）通过**异步回调**通知数据集管理服务：

```
Temporal工作流状态机：
  [提交] → (初审中) → [初审通过/驳回] 
         → (复审中) → [复审通过/驳回] 
         → (归档中) → [归档完成] → 回调通知数据集服务
```

数据集管理服务收到回调后，执行**原子化操作**：
1. 开启数据库事务
2. 创建数据集版本记录（含元数据）
3. 将数据文件写入对象存储
4. 更新数据集当前版本指针
5. 提交事务
6. 触发后续事件（如通知看板刷新、发送消息通知）

### 4.4 看板服务与全链路信息的聚合

看板服务（Go）作为**信息聚合层**，从多个数据源实时拉取信息：

| 数据来源 | 获取方式 | 看板展示内容 |
|----------|----------|--------------|
| MySQL（数据集表） | 定时查询 | 数据集总数、版本数、各状态数量 |
| Elasticsearch（审计日志） | 聚合查询 | 操作行为统计、用户活跃度 |
| Prometheus（监控指标） | 实时查询 | 系统吞吐量、处理延迟、错误率 |
| Kafka（实时流） | WebSocket推送 | 今日入库量、实时质量评分趋势 |
| 处理引擎（Python） | Redis缓存 | 各处理环节的积压情况、处理速度 |

---

## 五、关键技术选型与设计考量

### 5.1 为什么Go和Python分工协作？

| 语言 | 负责模块 | 核心优势 | 典型场景 |
|------|----------|----------|----------|
| **Go** | 采集网关、调度器、数据集管理、审核后台、看板API、权限控制 | 高并发、低内存占用、快速启动、自带并发原语 | 处理大量连接、高频API调用、I/O密集型任务 |
| **Python** | 清洗、脱敏、分类、标注、质量评估 | 丰富的科学计算库、AI生态完善、算法迭代灵活 | 数据处理、模型推理、复杂业务规则实现 |

**边界清晰**：Go负责"搬运"和"管理"，Python负责"加工"和"判断"，两者通过Kafka和API接口通信，互不侵入对方代码。

### 5.2 消息队列的核心作用

Kafka在整个系统中承担**数据总线**的角色：
- **削峰填谷**：采集高峰时数据先在Kafka积压，处理层按能力消费
- **解耦模块**：各处理环节通过Kafka主题连接，可独立部署和升级
- **重放能力**：处理失败时可重置消费偏移量，重新处理历史数据
- **多路分发**：同一份数据可被多个消费者组同时消费（如数据分析和审计）

### 5.3 存储架构的分层设计

```
热数据（近期高频访问）→  MySQL（元数据） + MinIO（文件）
温数据（定期访问）    →  HDFS冷存储 + 元数据保留在MySQL
冷数据（归档备份）    →  云存储归档层（OSS IA/Glacier）
审计日志              →  Elasticsearch（近实时检索）
处理中间态            →  Kafka（最多保留7天）
```

### 5.4 为什么选择Temporal作为工作流引擎？

相比传统的工作流引擎（如Activiti、Flowable），Temporal提供：
- **强一致性**：工作流状态持久化，宕机后可从中断点恢复
- **超时控制**：每个步骤可设置超时，超时后自动触发补偿
- **可观测性**：内置Web UI查看所有工作流执行状态
- **Go原生**：与平台主语言一致，代码嵌入性强

---

## 六、系统关键能力

### 6.1 数据质量保障机制

贯穿全链路的**四重质量保障**：

1. **采集校验**：字段完整性、数据格式检查
2. **处理质量**：清洗引擎剔除脏数据、脱敏引擎确保合规
3. **主动评估**：质量评分引擎量化数据可用性
4. **人工审核**：关键数据经过多级审批

### 6.2 数据版本管理能力

- **增量存储**：每次变更只存储差异（Delta），节省存储空间约70%
- **快照机制**：每10个版本自动创建全量快照，保证重建效率
- **一键回滚**：可从任意历史版本快速重建数据集
- **差异对比**：可视化展示两个版本之间的字段变化和记录差异

### 6.3 全链路可观测性

- **分布式追踪**：Jaeger追踪单个数据从采集到入库的全链路耗时
- **指标监控**：Prometheus采集每个服务的QPS、延迟、错误率
- **结构化日志**：ELK集中存储，支持复杂查询和告警
- **业务看板**：实时展示数据处理进度、积压量、质量趋势

---

## 七、系统核心流程时序图

以下用文字描述关键流程的时序配合：

### 流程一：一条数据从产生到入库的完整旅程

```
用户操作 → Token平台产生日志 → Kafka → 采集网关拉取 
→ 网关校验后写入"待处理"主题 → 清洗引擎消费并清洗 → 写入"已清洗"主题
→ 脱敏引擎消费并脱敏 → 写入"已脱敏"主题 → 分类引擎打标 → 写入"已分类"主题
→ 标注引擎预标注 → 低置信度送人工标注台 → 写入"已标注"主题
→ 质量评估引擎打分 → 低质量打回重处理 → 高质量触发工作流
→ 工作流发起审核 → 审核员审批通过 → 回调数据集服务
→ 数据集服务创建版本 → 存储元数据+文件 → 看板实时更新
→ 审计日志记录全过程
```

### 流程二：数据异常时的处理路径

```
情况A：采集校验失败
  采集网关拒绝接收 → 写入死信队列 → 告警通知运维 → 人工排查后重推

情况B：质量评分过低
  质量引擎标记低质量 → 不进入审核流程 → 退回数据处理层 → 人工介入优化规则

情况C：审核驳回
  工作流状态变更为"已驳回" → 不创建数据集版本 → 记录驳回原因 → 数据进入待优化池
```

### 流程三：数据消费与输出流程

```
外部系统申请数据集 → 权限校验(Casbin) → 校验通过
→ 查询数据集管理服务 → 获取最新版本元数据
→ 从MinIO读取实际文件 → 按权限级别脱敏输出
→ 记录消费审计日志 → 通过gRPC/REST返回数据
```

---

## 八、系统扩展性设计

### 8.1 水平扩展能力

- **采集网关**：通过Kafka消费者组实现，增加节点自动分担分区
- **处理引擎**：Celery Worker可动态增减，任务队列自动负载均衡
- **数据集服务**：无状态设计，Kubernetes HPA根据CPU/内存自动扩缩容

### 8.2 新数据源接入

- 新增数据源只需实现Kafka Producer接口，将数据写入标准Topic
- 采集网关支持多源配置，无需修改代码
- 数据分类引擎通过新增规则/模型即可支持新类型数据

### 8.3 新处理环节添加

- 在数据处理流水线中新增模块，只需订阅上游Topic，写入下游Topic
- 不影响现有模块运行，实现"热插拔"

---

## 九、总结

整个系统的核心设计理念是**"职责分离、异步解耦、分层治理"**：

1. **职责分离**：Go负责高性能I/O和业务逻辑，Python负责数据智能处理，各取所长
2. **异步解耦**：Kafka作为数据总线连接所有模块，实现松耦合、高可用
3. **分层治理**：从采集到服务的七层架构，每层有明确的输入输出和质量标准
4. **可观测性**：日志、指标、追踪三位一体，确保系统运行状态透明可见
5. **合规安全**：脱敏、权限、审计贯穿全流程，满足企业级数据治理要求

这套架构已在类似的大规模数据平台中得到验证，能够支撑**日均亿级数据量**的处理，并具有良好的扩展性和维护性。