# 数据集平台系统架构设计文档

## 文档说明

- **文档版本**：v2.0
- **编制日期**：2026年7月
- **文档类型**：系统架构设计说明书（Architecture Design Document）
- **阅读对象**：技术决策者、架构师、技术负责人、核心开发人员
- **文档目的**：阐述系统的架构设计理念、技术选型依据、模块划分、数据流转及非功能性保障策略

---

## 一、项目背景与目标

### 1.1 业务背景

随着AI能力在Token运营平台和AI工作台中的深度应用，各业务系统产生了海量的调用日志、问答记录、文件解析结果和知识引用数据。这些数据天然具有以下特征：

- **来源分散**：横跨多个业务系统，数据格式各异
- **价值密度不均**：部分数据可直接用于模型训练，部分需加工治理
- **合规要求高**：涉及用户隐私和业务敏感信息，需严格脱敏和审计
- **需要版本化管理**：数据集需可追溯、可回滚、可对比

因此，需要一个**企业级数据集治理平台**，将分散的原始数据转化为高质量、合规、可追溯的标准化数据集，服务于AI模型训练、业务分析等下游场景。

### 1.2 核心建设目标

| 目标维度 | 具体描述 |
|----------|----------|
| **统一采集** | 支持多数据源（Token平台、AI工作台）的统一接入，标准化数据格式 |
| **智能加工** | 自动化完成清洗、脱敏、分类、标注、质量评估，减少人工干预 |
| **合规可控** | 全过程脱敏、多级审批、完整审计，满足企业数据治理要求 |
| **版本管理** | 支持数据集的版本化存储、差异对比和任意版本回滚 |
| **高效服务** | 提供实时看板、标准化API，支撑数据消费和运营决策 |
| **可扩展** | 支持水平扩展，可平滑接入新数据源和新的处理环节 |

### 1.3 关键非功能性指标

| 指标 | 目标值 |
|------|--------|
| 采集吞吐量 | ≥ 50,000 条/秒 |
| 端到端处理延迟 | P95 < 5秒（从产生到入库） |
| 系统可用性 | 99.95%（年停机时间 < 4.5小时） |
| 数据准确性 | ≥ 99.99%（端到端校验） |
| 单日处理能力 | ≥ 1亿条记录 |
| 数据集查询响应 | 百万级数据 < 500ms |
| 合规审计覆盖率 | 100%（所有操作可追溯） |

---

## 二、系统架构设计

### 2.1 架构设计原则

| 原则 | 说明 | 体现 |
|------|------|------|
| **职责单一** | 每个模块只做一件事，边界清晰 | 采集只负责接入，清洗只负责清洗，互不耦合 |
| **异步解耦** | 模块间通过消息队列通信，降低依赖 | 全链路基于Kafka流转数据 |
| **语言择优** | 不同场景用最合适的语言 | Go负责高并发I/O，Python负责数据处理和AI |
| **可观测性优先** | 所有操作可追踪、可度量 | 日志+指标+链路追踪三位一体 |
| **安全内置** | 安全不是附加层，而是贯穿全流程 | 脱敏、权限、审计从设计阶段即纳入 |
| **弹性扩展** | 瓶颈模块可独立扩容 | Kubernetes HPA + Kafka消费者组 |

### 2.2 系统分层架构

系统采用**七层架构**，从下至上分别为基础设施层、治理审计层、数据服务层、数据集管理层、审核管理层、数据处理层、采集接入层、数据源层。

```
┌─────────────────────────────────────────────────────────────────────────────────┐
│                              数据源层（外部系统）                              │
│                    Token运营平台    │    AI工作台    │    其他数据源            │
└────────────────────────────────────────┬────────────────────────────────────────┘
                                         │
                                         ▼
┌─────────────────────────────────────────────────────────────────────────────────┐
│                     采集接入层（Go）—— 数据入口                               │
│    统一采集网关     │     消息队列（Kafka）     │     同步调度器              │
│  实时消费/批量拉取   │     缓冲削峰/解耦       │   定时/增量同步管理          │
└────────────────────────────────────────┬────────────────────────────────────────┘
                                         │
                                         ▼
┌─────────────────────────────────────────────────────────────────────────────────┐
│                   数据处理层（Python）—— 数据加工                             │
│  清洗引擎 → 脱敏引擎 → 分类引擎 → 标注引擎 → 质量评估引擎                    │
│  去重/格式化   加密/掩码   自动打标   半自动标注   五维评分                    │
└────────────────────────────────────────┬────────────────────────────────────────┘
                                         │
                                         ▼
┌─────────────────────────────────────────────────────────────────────────────────┐
│                  审核管理层（Go）—— 合规管控                                  │
│           工作流引擎（Temporal）    │    审核管理后台                         │
│         多级审批/状态机管理          │   授权/敏感级别/审核状态管理            │
└────────────────────────────────────────┬────────────────────────────────────────┘
                                         │
                                         ▼
┌─────────────────────────────────────────────────────────────────────────────────┐
│               数据集管理层（Go）—— 核心资产                                   │
│       数据集管理服务      │      版本控制模块      │      存储管理             │
│   创建/状态/台账管理       │   Delta差异/快照/回滚  │  元数据+文件存储          │
└────────────────────────────────────────┬────────────────────────────────────────┘
                                         │
                                         ▼
┌─────────────────────────────────────────────────────────────────────────────────┐
│                 数据服务层（Go + Vue）—— 能力输出                             │
│   看板后端（WebSocket）   │   看板前端（ECharts）  │   第三方API（gRPC/REST）   │
│   实时聚合推送            │   可视化运营           │   标准化数据输出           │
└────────────────────────────────────────┬────────────────────────────────────────┘
                                         │
                                         ▼
┌─────────────────────────────────────────────────────────────────────────────────┐
│             治理与审计层（Go）—— 贯穿全局                                     │
│  元数据中心  │  审计日志（ELK）  │  权限控制（Casbin）  │  链路追踪（Jaeger）    │
└─────────────────────────────────────────────────────────────────────────────────┘
                                         │
                                         ▼
┌─────────────────────────────────────────────────────────────────────────────────┐
│                    基础设施层（全栈支撑）                                       │
│      Kubernetes  │  Docker  │  Prometheus/Grafana  │  Nacos/Consul            │
│      容器编排     │  容器化   │   监控告警           │   服务发现/配置           │
└─────────────────────────────────────────────────────────────────────────────────┘
```

### 2.3 部署架构与高可用设计

系统采用**多可用区部署**方案，确保高可用性：

| 组件 | 部署策略 | 容灾机制 |
|------|----------|----------|
| 采集网关 | 多副本部署（≥3），Kubernetes管理 | 滚动更新，自动恢复 |
| 数据处理引擎 | 多Worker部署，任务队列分发 | 失败自动重试，死信队列 |
| 数据集服务 | 多副本部署（≥3），无状态设计 | 自动扩缩容，故障漂移 |
| MySQL | 主从架构 + 定期全量备份 | 主备切换，数据备份恢复 |
| Kafka | 多Broker集群（≥3） | 分区副本，ISR机制 |
| MinIO | 分布式部署（≥4节点） | 纠删码，多节点容错 |
| Elasticsearch | 多节点集群（≥3） | 主分片+副本分片 |

---

## 三、技术选型与决策依据

### 3.1 双语言架构设计

系统采用**Go + Python**双语言架构，核心设计思想是"用对的语言做对的事"。

| 语言 | 负责领域 | 选型理由 | 典型模块 |
|------|----------|----------|----------|
| **Go** | 接入、传输、管理、服务 | 高并发性能优异，内存占用低，部署简单，适合构建长期运行的基础设施服务 | 采集网关、数据集管理、审核后台、看板API、权限控制 |
| **Python** | 处理、分析、AI | 数据科学生态最成熟（Pandas/Scikit-learn），算法迭代灵活，AI模型集成方便 | 清洗、脱敏、分类、标注、质量评估 |

**模块间通信机制**：
- 异步数据流：通过Kafka主题连接
- 同步管理调用：通过gRPC/RESTful接口
- 配置共享：通过Nacos统一配置中心

### 3.2 关键技术组件选型

| 技术领域 | 选型方案 | 备选方案 | 选型理由 |
|----------|----------|----------|----------|
| **消息队列** | Apache Kafka | RocketMQ/Pulsar | 高吞吐、持久化、消费者组机制成熟，与大数据生态集成好 |
| **数据存储（文件）** | MinIO + 云OSS | HDFS/Ceph | S3兼容，与公有云无缝对接，部署简单，支持生命周期管理 |
| **元数据存储** | MySQL | PostgreSQL | 团队熟悉度高，运维生态成熟，事务支持完善 |
| **日志存储** | Elasticsearch | ClickHouse | 全文检索能力强，ELK生态成熟，支持复杂聚合分析 |
| **工作流引擎** | Temporal | Activiti/Flowable | 支持Go原生，状态持久化，宕机恢复能力强 |
| **权限管理** | Casbin | Spring Security | 轻量级，支持RBAC+ABAC混合模型，多语言支持 |
| **链路追踪** | Jaeger + OpenTelemetry | Zipkin | 开源生态活跃，Go SDK支持完善，与Kubernetes集成好 |
| **容器编排** | Kubernetes | Docker Swarm | 事实标准，生态最丰富，支持自动扩缩容 |
| **配置管理** | Nacos | Consul/Etcd | 支持配置热更新，服务发现，与Go/Python集成方便 |
| **监控告警** | Prometheus + Grafana | Zabbix | 云原生标准，与Kubernetes深度集成 |

### 3.3 技术风险与应对

| 风险点 | 影响 | 应对措施 |
|--------|------|----------|
| Go与Python跨语言调试困难 | 问题定位耗时 | 引入OpenTelemetry全链路追踪，统一日志格式 |
| Kafka消费积压 | 端到端延迟增大 | 配置消费者组自动扩容，设置积压告警阈值 |
| Python处理性能瓶颈 | 处理速度不足 | 多Worker并行，Dask处理大数据集，优化算法 |
| 存储成本快速增长 | 成本失控 | 建立数据生命周期策略，冷热分层存储 |
| 版本Delta链过长 | 版本恢复变慢 | 每N个版本自动合并为快照，定期清理过期Delta |

---

## 四、模块功能定义与交互关系

### 4.1 各层模块职责详解

#### （1）采集接入层（Go）

| 模块 | 核心职责 | 输入 | 输出 |
|------|----------|------|------|
| 统一采集网关 | 消费Kafka数据流，初步校验，路由分发 | Kafka消息/REST请求 | 清洗后写入Kafka或死信队列 |
| 消息队列（Kafka） | 数据总线，削峰填谷，模块解耦 | 各上游Producer写入 | 各下游Consumer读取 |
| 同步调度器 | 管理定时/增量同步任务，控制同步节奏 | Cron触发/API触发 | 调度任务执行状态 |

**关键能力**：
- 支持批量拉取和流式消费双模式
- 数据校验失败时自动写入死信队列，不阻塞主流程
- 消费位移管理，支持数据重放

#### （2）数据处理层（Python）

| 模块 | 核心职责 | 依赖 | 输出标准 |
|------|----------|------|----------|
| 清洗引擎 | 去重、格式标准化、空值处理、字段映射 | 规则库（可配置） | 数据完整性≥99% |
| 脱敏引擎 | 敏感字段识别、动态脱敏（掩码/加密/替换） | 策略中心 | 合规性100%（无明文敏感数据） |
| 分类引擎 | 规则匹配+机器学习自动打标 | 分类模型、规则库 | 分类准确率≥90% |
| 标注引擎 | 预标注（NLP模型）+ 人工标注台辅助 | 标注模型、前端标注平台 | 标注准确率≥95% |
| 质量评估引擎 | 五维评分（完整性/准确性/一致性/时效性/合规性） | 评分模型 | 输出0-1量化评分 |

**模块协作模式**：
- 各引擎通过Kafka主题串联，形成处理流水线
- 每个引擎可独立扩容，互不影响
- 质量评估低于阈值的数据被回退，形成反馈闭环

#### （3）审核管理层（Go）

| 模块 | 核心职责 | 关键机制 |
|------|----------|----------|
| 工作流引擎 | 管理多级审批流程，状态机驱动 | 提交→初审→复审→归档，超时自动提醒 |
| 审核管理后台 | 审核台操作界面后端 | 权限控制，审核任务分配，审核记录留痕 |

**审核流程设计**：
- 支持三级审批（初审、复审、终审），可根据数据敏感级别动态调整
- 审核超时自动升级，确保流程不被阻塞
- 驳回数据需附带驳回原因，数据退回处理层重新加工

#### （4）数据集管理层（Go）

| 模块 | 核心职责 | 关键设计 |
|------|----------|----------|
| 数据集管理服务 | 数据集CRUD、状态管理、台账维护 | 元数据存MySQL，文件存MinIO |
| 版本控制模块 | 版本创建、差异存储、回滚、追溯 | Delta算法+定期快照 |
| 存储管理 | 文件读写、生命周期管理、压缩优化 | Parquet格式+Snappy压缩 |

**版本管理策略**：
- 增量存储：每次变更仅保存Delta差异，节省70%存储空间
- 快照策略：每10个版本自动创建全量快照
- 回滚能力：从任意历史版本快速重建

#### （5）数据服务层（Go + Vue）

| 模块 | 核心职责 | 技术实现 |
|------|----------|----------|
| 看板后端 | 聚合多源数据，实时推送统计信息 | WebSocket长连接 + 定期拉取 |
| 看板前端 | 可视化展示数据集运营状态 | Vue3 + TypeScript + ECharts |
| 第三方API | 标准化数据输出，支持下游消费 | gRPC（高性能）+ RESTful（兼容性） |

**看板数据聚合来源**：
- MySQL：数据集元数据统计
- ES：审计日志聚合分析
- Prometheus：系统运行指标
- Redis：实时计数器

#### （6）治理与审计层（Go）

| 模块 | 核心职责 | 关键设计 |
|------|----------|----------|
| 元数据中心 | 统一管理数据字典、血缘关系 | 基于ES实现快速检索 |
| 审计日志 | 全操作记录，合规追溯 | 异步写入ES，按天滚动索引 |
| 权限控制 | 细粒度访问控制 | Casbin实现RBAC+ABAC混合模型 |
| 全链路追踪 | 分布式调用链分析 | OpenTelemetry标准 + Jaeger可视化 |

**审计日志覆盖范围**：
- 所有API调用（谁、何时、做了什么操作、结果如何）
- 数据处理行为（每条数据经过哪些环节、结果状态）
- 审核行为（谁审核的、审核结果、审核意见）
- 数据消费行为（谁导出了什么数据、导出量级）

### 4.2 模块间关键交互流程

#### 流程一：数据采集与预处理

```
数据源产生数据 → 采集网关消费Kafka → 网关校验（通过/失败）→ 
通过数据写入"待处理"主题 → 失败数据写入死信队列 → 告警通知
```

#### 流程二：数据处理流水线

```
待处理数据 → 清洗引擎（去重/格式化）→ 脱敏引擎（加密/掩码）→ 
分类引擎（自动打标）→ 标注引擎（半自动标注）→ 质量评估引擎（五维打分）→ 
高质量数据→触发审核流程 / 低质量数据→退回清洗引擎重新加工
```

#### 流程三：审核与入库

```
质量达标数据 → 工作流引擎发起审核 → 初审 → 复审 → 审核通过 → 
回调数据集管理服务 → 创建数据集版本 → 存储快照+Delta → 更新元数据
```

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

```
外部请求 → 权限校验（Casbin）→ 查询数据集元数据 → 
从MinIO读取数据文件 → 按权限级别脱敏输出 → 记录消费审计日志
```

### 4.3 关键交互时序（逻辑描述）

**场景：一条新数据从产生到看板可见的完整旅程**

1. 用户在Token平台执行一次API调用，系统自动生成调用日志
2. 日志通过Kafka Producer实时写入`raw-data`主题
3. 采集网关作为Consumer拉取数据，完成字段完整性校验
4. 校验通过后写入`to-clean`主题，失败则写入`dlq`死信队列
5. 清洗引擎消费`to-clean`，执行去重和格式标准化，输出到`to-desensitize`
6. 脱敏引擎消费并执行动态脱敏，输出到`to-classify`
7. 分类引擎打标后输出到`to-annotate`
8. 标注引擎预标注，低置信度样本送人工标注台，完成后输出到`to-evaluate`
9. 质量评估引擎打分，≥0.75分的数据进入`to-audit`，<0.75分退回`to-clean`
10. 工作流引擎检测到`to-audit`有新数据，启动审核流程
11. 审核人员在审核台操作，通过后回调数据集服务
12. 数据集服务创建版本，存储数据到MinIO，记录元数据到MySQL
13. 看板服务通过WebSocket推送最新统计数据
14. 整个过程的每一步都记录审计日志到ES

---

## 五、数据架构与存储设计

### 5.1 数据分类与存储映射

系统根据数据性质选择不同的存储方案，形成**混合存储架构**。

| 数据类型 | 存储位置 | 数据格式 | 保留周期 | 访问频率 |
|----------|----------|----------|----------|----------|
| **元数据**（数据集信息、版本信息、配置） | MySQL | 结构化关系表 | 永久（仅归档） | 高频读写 |
| **数据文件**（快照、Delta、原始归档） | MinIO/OSS | Parquet/JSON | 3年（原始归档）+永久（数据集） | 中频读写 |
| **审计日志**（操作记录、行为轨迹） | Elasticsearch | JSON文档 | 90天（热）+归档 | 高频查询 |
| **链路追踪**（调用链、耗时分析） | Elasticsearch | JSON文档 | 30天 | 中频查询 |
| **流转数据**（处理中的数据） | Kafka | 二进制/JSON | 7天 | 极高频读写 |
| **缓存数据**（热点统计、实时计数器） | Redis | 键值对 | TTL自动过期 | 极高频读写 |
| **系统指标**（CPU、内存、QPS） | Prometheus | 时序数据 | 15天 | 高频查询 |

### 5.2 核心数据模型

#### 数据集元数据模型（MySQL）

数据集的元数据是系统的核心资产索引，包含以下核心实体：

**数据集主表**记录数据集的全局信息，包括唯一标识、名称描述、行业分类、来源类型、当前版本指针、综合质量评分、记录总数、存储大小、生命周期状态以及创建和更新信息。

**版本表**记录数据集的每一次版本变更，包括版本标识、所属数据集、版本标签、父版本（形成版本链）、该版本的记录数和存储大小、快照文件地址、Delta操作日志、质量评分、审核状态和审核意见。

**数据源配置表**管理接入的数据源信息，包括数据源类型、连接配置（加密存储）、同步调度表达式、最后同步时间和同步状态。

**工作流实例表**追踪审核流程状态，包括工作流实例标识、关联的数据集和版本、工作流类型、当前步骤、状态、当前处理人和上下文变量。

#### 审计日志模型（Elasticsearch）

审计日志文档包含操作时间戳、操作用户标识和用户名、操作类型（增删改查）、资源类型和标识、操作路径、请求参数、响应码、客户端IP和User-Agent、操作耗时以及关联的数据集和版本标识。所有字段均支持全文检索和聚合分析。

### 5.3 存储容量规划与增长模型

基于业务量预估，对未来3年的存储需求进行规划。

#### MySQL容量预估

| 数据表 | 日增量 | 年增量 | 3年总量 | 备注 |
|--------|--------|--------|---------|------|
| datasets（数据集主表） | 50条 | 18,250条 | 约5.5万条 | 每条2KB，总量极小 |
| dataset_versions（版本表） | 5,000条 | 182万条 | 约550万条 | 每条5KB，总量约27GB |
| workflow_instances（工作流表） | 5,000条 | 182万条 | 约550万条 | 每条3KB，总量约16GB |
| process_logs（处理日志） | 10万条 | 3650万条 | 约1.1亿条 | 按天分区，只保留3个月 |
| 其他配置表 | 少量 | 少量 | <1GB | - |

**结论**：MySQL总数据量控制在100GB以内，单机可支撑，无需分库。

#### MinIO容量预估

| 数据类型 | 日增量 | 年增量 | 3年总量 | 压缩比 |
|----------|--------|--------|---------|--------|
| 数据集快照（Parquet） | 50GB | 18TB | 54TB | 3:1（相比JSON） |
| Delta增量文件 | 5GB | 1.8TB | 5.4TB | - |
| 原始归档 | 20GB | 7.3TB | 21.9TB | 压缩存储 |
| 临时处理文件 | 50GB | 18TB | - | 24小时自动删除 |

**结论**：3年总存储需求约80TB，采用冷热分层可有效控制成本。

#### Elasticsearch容量预估

| 索引类型 | 日增量 | 年增量 | 3年总量 | 保留策略 |
|----------|--------|--------|---------|----------|
| 审计日志 | 100GB | 36TB | 108TB | 保留90天，实际热数据约9TB |
| 链路追踪 | 50GB | 18TB | 54TB | 保留30天，实际热数据约4.5TB |
| 应用日志 | 30GB | 11TB | 33TB | 保留30天，实际约3TB |

**结论**：ES实际热数据总量约17TB，7节点集群可支撑。

### 5.4 数据生命周期管理策略

系统为不同类型的数据建立完整的生命周期管理机制：

**数据集快照**的生命周期：从创建开始，前30天存储在MinIO SSD高速存储区，31-180天自动迁移至HDD标准存储区，180天以上转为云OSS归档存储，永久保留直至手动删除。

**Delta增量文件**的生命周期：创建后保留30天用于版本回滚，31-90天保留但标记为可清理，在触发快照合并后自动删除，释放存储空间。

**原始归档数据**的生命周期：前180天存储在MinIO，181-1095天迁移到OSS冷存储，1095天（3年）后根据合规要求判断是否允许删除。

**审计日志**的生命周期：近7天存储在ES热节点（SSD），响应快速；8-30天自动迁移至ES温节点（HDD），查询速度略降；31-90天进入ES冷节点（冻结索引），查询需解冻；超过90天从ES删除，但先创建快照到OSS进行合规存档。

---

## 六、关键架构决策与权衡

### 6.1 为什么选择双语言而非单一语言

| 对比维度 | 全Go方案 | 全Python方案 | 双语言方案（选定） |
|----------|----------|--------------|-------------------|
| 采集吞吐量 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| AI/数据处理生态 | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 开发效率（业务逻辑） | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 部署运维复杂度 | ⭐⭐⭐⭐⭐（简单） | ⭐⭐⭐⭐ | ⭐⭐⭐（略有增加） |
| 人才招聘难度 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |

**决策结论**：虽然双语言增加了跨语言通信的复杂度，但在性能和数据智能处理两个维度上都获得了最优解，收益远大于成本。

### 6.2 为什么选择Kafka作为数据总线

| 评估维度 | Kafka | RabbitMQ | Pulsar |
|----------|-------|----------|--------|
| 吞吐量 | 极高（百万级/秒） | 中（万级/秒） | 高（十万级/秒） |
| 消息持久化 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 消费重放能力 | ⭐⭐⭐⭐⭐（支持） | ⭐⭐（有限） | ⭐⭐⭐⭐ |
| 生态成熟度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 运维复杂度 | 中 | 低 | 中高 |

**决策结论**：Kafka的持久化和消费重放能力对数据平台至关重要（支持数据回溯重新处理），高吞吐特性满足日亿级数据量需求。

### 6.3 为什么选择Delta增量存储而非全量快照

| 对比维度 | 全量快照 | Delta增量（选定） |
|----------|----------|-------------------|
| 存储效率 | 低（每次变更存全量） | 高（只存变化部分） |
| 版本恢复速度 | 快（直接读取） | 中（需合并Delta） |
| 版本对比能力 | 弱（需全量对比） | 强（天然支持差异） |
| 存储节省 | - | 约70% |
| 实现复杂度 | 低 | 中 |

**决策结论**：数据集平台核心价值之一是版本管理，Delta存储天然支持差异对比和增量追溯，配合定期快照机制解决了恢复速度问题，综合优势明显。

### 6.4 为什么用Temporal而非传统工作流引擎

| 评估维度 | Temporal | Activiti/Flowable |
|----------|----------|-------------------|
| 语言亲和性 | Go原生 | Java原生（需额外集成） |
| 状态持久化 | ✅ 内置，自动恢复 | 需手动持久化 |
| 超时控制 | ✅ 原生支持 | 需额外实现 |
| 可观测性 | ✅ 内置Web UI | 部分支持 |
| 轻量级 | 是 | 否（较重量） |

**决策结论**：Temporal与Go生态无缝集成，状态机自动持久化可大幅降低审核流程的开发复杂度，且保证了宕机后的流程恢复能力。

### 6.5 技术债务与演进规划

| 当前决策 | 潜在问题 | 未来演进方向 |
|----------|----------|--------------|
| MySQL存储元数据 | 版本表快速增长 | 1年后迁移历史版本到TiDB或ClickHouse |
| Python单机处理 | 超大数据量时性能不足 | 引入Dask分布式计算或迁移到Flink |
| Kafka单集群 | 单点风险 | 未来部署双集群跨机房容灾 |
| MinIO自建 | 运维成本 | 逐步迁移到公有云OSS服务 |
| 人工标注依赖 | 标注效率瓶颈 | 持续优化NLP预标注模型，降低人工比例 |

---

## 七、非功能性保障方案

### 7.1 高可用架构

| 组件 | 可用性保障 | RTO | RPO |
|------|------------|-----|-----|
| 采集网关 | 多副本+Kubernetes自动恢复 | < 1分钟 | 0（无状态） |
| 数据处理引擎 | 多Worker+任务队列 | < 1分钟 | 0（幂等设计） |
| 数据集服务 | 多副本+Kubernetes | < 1分钟 | 0（无状态） |
| MySQL | 主从+自动切换 | < 5分钟 | < 1分钟（异步复制） |
| Kafka | 多Broker+ISR | < 2分钟 | 0（持久化） |
| MinIO | 分布式纠删码 | < 5分钟 | 0（多副本） |
| Elasticsearch | 多节点+副本分片 | < 5分钟 | 0（副本） |

**整体可用性目标**：99.95%（年停机时间 < 4.5小时）

### 7.2 性能保障策略

| 策略 | 具体措施 | 适用范围 |
|------|----------|----------|
| **水平扩展** | Kubernetes HPA自动扩容，Kafka消费者组动态增减 | 采集、处理、API服务 |
| **缓存加速** | Redis缓存热点统计和常用数据集元数据 | 看板、数据集查询 |
| **异步处理** | 耗时操作（脱敏、标注）通过Kafka异步化 | 数据处理全链路 |
| **批量操作** | 采集批次1000条，处理批次5000条 | 采集、清洗、存储 |
| **读写分离** | MySQL主写从读，ES冷热分离 | 数据库、ES |
| **限流熔断** | 网关层限流，下游熔断保护 | 采集网关、API服务 |
| **预聚合** | 每日定时聚合统计数据，减少实时计算 | 看板、报表 |

### 7.3 安全防护体系

系统采用**纵深防御**的安全策略：

**网络安全层**：
- 服务间通信强制mTLS双向认证
- 对外接口仅开放HTTPS（TLS 1.3）
- 部署WAF防护常见攻击
- 内部网络隔离，数据库不暴露公网

**数据安全层**：
- 传输加密：全链路TLS加密
- 存储加密：MinIO服务端加密（SSE-S3），MySQL透明数据加密（TDE）
- 敏感字段：AES-256-GCM/SM4加密存储，动态脱敏查询
- 密钥管理：Hashicorp Vault统一管理，定期轮换

**身份与权限层**：
- 身份认证：JWT Token + 刷新Token机制
- 权限控制：Casbin实现RBAC+ABAC混合模型
- 细粒度控制：支持数据级权限（用户只能访问有权限的数据集）

**审计追溯层**：
- 100%操作审计覆盖，不可篡改
- 审计日志存储到ES，保留90天
- 敏感操作（删除、导出、权限变更）实时告警

### 7.4 可观测性体系

系统建立**Logging + Metrics + Tracing**三位一体的可观测体系：

**Logging（日志）**：
- 结构化日志（JSON格式），包含TraceID关联
- 日志分级（DEBUG/INFO/WARN/ERROR）
- 集中存储到ELK，支持全文检索和告警

**Metrics（指标）**：
- 业务指标：日处理量、质量评分分布、审核通过率
- 系统指标：QPS、延迟、错误率、资源利用率
- 采集方式：Prometheus Pull模型，Grafana可视化

**Tracing（追踪）**：
- 基于OpenTelemetry标准
- 全链路追踪覆盖所有服务
- Jaeger提供可视化调用链分析
- 关键操作（数据处理、审核流程）自动埋点

---

## 八、部署与运维架构

### 8.1 容器化部署方案

所有服务采用容器化部署，基于Kubernetes进行编排管理。

| 服务类型 | 副本数 | CPU请求/限制 | 内存请求/限制 | 特殊配置 |
|----------|--------|--------------|---------------|----------|
| 采集网关（Go） | 3-10（HPA） | 500m / 2核 | 512Mi / 2Gi | 与Kafka消费Lag联动HPA |
| 数据集服务（Go） | 3-5 | 500m / 2核 | 512Mi / 2Gi | 无状态，水平扩展 |
| 审核后台（Go） | 2-3 | 500m / 1核 | 512Mi / 1Gi | 无状态 |
| 看板API（Go） | 2-3 | 500m / 1核 | 512Mi / 1Gi | WebSocket连接管理 |
| Python处理引擎 | 4-10（HPA） | 2核 / 4核 | 4Gi / 8Gi | Celery Worker，任务队列感知 |
| 看板前端（Vue） | 2 | 200m / 500m | 256Mi / 512Mi | Nginx静态服务 |

### 8.2 持续集成与交付

采用**GitOps**实践，实现自动化CI/CD流水线：

1. **代码提交**：开发人员提交代码到Git仓库
2. **CI阶段**：触发单元测试、代码扫描、镜像构建、镜像推送
3. **CD阶段**：ArgoCD监控Git仓库中的部署配置，自动同步到Kubernetes集群
4. **灰度发布**：金丝雀部署策略，新版本先替换10%流量，观察后再全量
5. **回滚能力**：一键回滚到任意历史版本

### 8.3 监控告警配置

建立多级告警机制，确保问题及时发现和响应：

| 告警级别 | 触发条件 | 响应方式 | 响应时效 |
|----------|----------|----------|----------|
| **P0（紧急）** | 服务不可用、数据丢失 | 电话+短信+钉钉 | 立即响应，15分钟内恢复 |
| **P1（严重）** | 处理延迟>10秒、错误率>5% | 钉钉+短信 | 30分钟内响应 |
| **P2（警告）** | 存储使用率>80%、Kafka积压>100万 | 钉钉通知 | 2小时内处理 |
| **P3（提示）** | 处理速度下降、质量评分波动 | 邮件通知 | 工作时间处理 |

---

## 九、开发路线图与里程碑

### 9.1 分阶段实施计划

| 阶段 | 周期 | 核心交付 | 里程碑 | 风险点 |
|------|------|----------|--------|--------|
| **Phase 1：基础接入** | 4周 | Go采集网关、Kafka对接、基础数据模型 | 完成数据从源端到Kafka的采集 | Kafka消费组管理、分区再平衡 |
| **Phase 2：核心处理** | 5周 | Python清洗+脱敏引擎、质量评估基础版、MySQL元数据 | 完成清洗→脱敏→评估的完整流水线 | 大文件内存溢出（Dask分批处理） |
| **Phase 3：版本管理** | 3周 | Go数据集管理服务、Delta版本控制、MinIO存储 | 完成数据集创建、版本存储和查询 | Delta算法性能需Benchmark优化 |
| **Phase 4：审核流程** | 3周 | Temporal工作流引擎、审核后台、审核台前端 | 完成从数据到审核通过入库的完整闭环 | 工作流状态机复杂度管理 |
| **Phase 5：服务输出** | 3周 | 看板API+WebSocket、前端看板、开放API | 完成数据服务化输出能力 | WebSocket连接数管理 |
| **Phase 6：治理安全** | 3周 | Casbin权限、ELK审计日志、Jaeger追踪 | 完成合规安全体系全覆盖 | 策略动态加载性能 |
| **Phase 7：上线运营** | 3周 | K8s部署、监控告警、压测调优、文档完善 | 系统正式上线，SLA达标 | 资源配额与自动扩缩容策略调优 |

### 9.2 关键里程碑验收标准

| 里程碑 | 验收标准 |
|--------|----------|
| M1：采集上线 | 采集网关