技术建设方案

芯片检测数据平台

面向海量检测数据的写入、查询、备份、封存与运维体系

客户单位 武汉沪光引擎科技有限公司
方案提供 西安探知图灵科技有限公司
文件版本 V1.0
编制日期 2026 年 10 月

01 / 执行摘要

让检测数据“写得进、查得快、丢不了、可恢复”

现有生产环境使用 Windows 与单机 MySQL，数据持续增长后，查询经常超过 300 秒，写入和查询都难以满足芯片检测业务对时效的要求。新平台把 Redis 作为写入缓冲层，MySQL 只保存业务数据和汇总结果，ClickHouse 保存检测明细；Longhorn 分布式存储为 Kubernetes 持久卷提供跨节点副本，降低单台机器或单块磁盘损坏造成的数据风险。

约 5000 万条 每月新增检测数据
超过 300 秒 当前典型查询耗时基线
3 秒内 数据可靠接收后的写入确认目标
性能目标说明

“3 秒内”指业务请求在 Redis 缓冲层完成持久化接收并获得“已接收”结果，需要在双方约定的并发量和数据包大小下进行压测验证。明细数据由后台消费者批量写入 ClickHouse，状态随后更新为“已入库”或“写入失败”。查询优化效果以当前超过 300 秒的查询作为基线，对典型查询逐一测量并形成前后对比报告。

02 / 现状与痛点

数据已经超过单机 MySQL 的舒适区

客户上传的数据规模估算显示，系统数据库为 mars_db_wafer_fd，核心明细表 t_test_value_fd 已有 103,173,331 条记录，占用约 23 GB。客户业务每月约 5000 万条检测记录；结合现有明细表结构和客户给出的数据增长预估，一年明细数据量可能达到约 30 亿条。

当前主要数据表规模
数据表 记录数 占用空间 主要用途
t_session 8,179 - 记录检测环境信息
t_test 792,838 472 MB 记录芯片级测试信息，按 test_id 判断写入结果
t_test_bin_definition 751 - 定义测试 Bin 分类
t_test_bin_result 2,857,523 321 MB 保存测试分类结果
t_test_condition 801,590 211 MB 记录芯片测试条件
t_test_value_fd 103,173,331 约 23 GB 保存详细测试数据明细

查询等待时间过长

按设备、产品版本、批次、晶圆和时间等维度统计时，查询经常超过 300 秒，影响生产查看和问题追溯。

写入链路缺少稳定设计

业务需要根据 test_id 判断数据是否写入成功。当前系统无法在高并发写入下持续提供稳定、明确的反馈。

一台服务器承担全部风险

现有 512 GB 内存、64 核服务器配置较高，但仍是单点。硬件、系统或磁盘损坏都可能导致业务中断甚至数据损失。

Windows 不适合长期生产运行

数据库、容器、监控和自动化运维生态在 Linux 上更成熟，也更适合持续运行和故障处理。

03 / 建设目标

建立可承载一年在线数据的生产平台

01

写入可确认

接入服务完成格式和字段校验，把数据写入 Redis 缓冲层并返回明确结果，目标为单次业务请求 3 秒内完成。

02

查询可加速

把海量明细分析交给 ClickHouse，针对常用维度设计分区、排序键和预聚合，缩短查询等待时间。

03

数据可恢复

建立每日增量、每周全量、月度归档和年度封存机制，并把备份放在独立设备上。

04

故障可发现

持续监控服务器、数据库、写入链路和备份任务，异常时及时告警。

05

服务可恢复

服务进程异常时自动重启，节点异常时调度到健康节点，数据损坏时按副本或备份流程恢复。

06

容量可规划

记录数据增长和资源趋势，为下一阶段扩容、数据归档和硬件采购提供依据。

04 / 总体架构

Redis 缓冲写入，Longhorn 保护持久数据

Redis 作为写入缓冲层，先把设备上报的数据稳定接住，再由消费者按批次写入 ClickHouse，避免瞬时并发直接冲击数据库。MySQL 只保存业务数据和汇总结果，ClickHouse 保存检测明细，Longhorn 分布式存储为 Kubernetes 持久卷提供至少 3 副本，任一节点或单块磁盘损坏时，持久卷可以在健康节点继续提供服务或重建副本。

数据来源 检测设备 / 现有业务系统 检测明细、环境信息、芯片测试信息
数据入口 数据接入服务 格式校验、状态查询、接收确认、异常数据隔离
写入缓冲 Redis 写入缓冲层 AOF 持久化、副本保护、按批次交付消费者
数据与计算 MySQL + ClickHouse 业务与汇总结果 + 海量检测明细分工存储
业务出口 查询与统计系统 设备、产品版本、批次、晶圆、时间分析
Linux 稳定、可自动化的生产底座
Kubernetes 统一部署、健康检查、故障重启和节点调度
Longhorn 分布式持久卷，推荐至少 3 副本并支持节点故障重建
Prometheus + Grafana 指标采集、看板展示和告警触发
独立备份存储 保存全量、增量和封存数据

05 / 写入与查询

先保证写入可靠，再保证查询高效

数据写入流程

  1. 1
    接收与校验

    接入服务检查数据格式、字段完整性和 test_id 是否已经存在，不额外增加一套复杂的重复校验流程。

  2. 2
    写入 Redis 缓冲层

    数据写入 Redis 并完成持久化后返回“已接收”。Redis 配置 AOF 持久化和副本，作为短期缓冲，不作为唯一长期数据源。

  3. 3
    消费者批量入库

    后台消费者按批次把明细写入 ClickHouse，把需要事务一致性的业务数据和汇总结果写入 MySQL。

  4. 4
    状态更新与查询确认

    写入成功后按 test_id 更新为“已入库”，失败则记录原因并进入告警。接口返回“已接收”的目标为 3 秒内完成。

缓冲层与状态边界

Redis 负责接住瞬时写入，不承担长期归档；MySQL 和 ClickHouse 才是在线数据存储。系统沿用现有 test_id 查询写入状态，不在第一阶段增加额外的去重框架。若上游存在重复上报，应由现有业务规则处理，或后续单独评估。

查询优化方式

时间分区

ClickHouse 按时间分区，具体按日或按月根据数据量、查询范围和维护成本在压测后确定。

排序键设计

围绕设备、产品版本、批次、晶圆、时间及高频组合查询设计排序键，减少无关数据扫描。

预聚合

对固定口径的高频统计使用物化视图或预聚合结果，避免每次查询都重新扫描全部明细。

慢查询治理

记录典型查询耗时和分位数，持续发现需要补充索引、调整排序键或改写查询的场景。

职责分流

MySQL 只保存业务数据和汇总结果，明细统一进入 ClickHouse，降低核心业务库的资源竞争。

历史分层

近期数据在线提供高频查询，满一年数据转为封存数据，控制在线数据规模。

06 / 组件说明

每个组件都对应一个明确问题

下面不使用“技术名词堆叠”的方式说明架构。每个组件都先说明它在业务中的作用，再说明实现方式。

基础环境

Linux

解决什么问题：替掉不适合长期生产运行的 Windows 环境，减少数据库、容器、监控和自动化部署之间的兼容问题。

实现方式：生产服务器统一使用稳定的 Linux 发行版，规范系统账户、磁盘挂载、时间同步、日志和安全策略。

运行编排

Kubernetes

解决什么问题：让数据接入、查询、监控等服务的部署和恢复保持一致，不依赖人工登录服务器逐个重启。

实现方式：使用健康检查、副本、滚动发布和调度策略管理无状态服务；对于需要持久磁盘的数据库，使用稳定的持久卷和部署策略，避免把数据库当成随时可丢弃的临时容器。

写入缓冲

Redis

解决什么问题：Redis 作为写入缓冲层，接住设备高峰时段的瞬时写入，避免数据直接冲击 MySQL 和 ClickHouse。

实现方式：启用 AOF 持久化和副本机制，配合消费者按批次投递数据。Redis 只保存短期缓冲和必要的热点数据，不替代长期存储和备份。

分布式存储

Longhorn

解决什么问题：服务器或磁盘可能损坏，单个 Kubernetes 节点上的持久卷不能成为单点。

实现方式：Longhorn 为 Kubernetes 持久卷提供分布式块存储，生产环境至少配置 3 副本并分布在 3 个节点。单节点或单盘故障时，副本可在健康节点继续提供服务并自动重建。Longhorn 快照和副本保护不能替代独立备份。

核心数据

MySQL

解决什么问题：MySQL 只保存业务数据和汇总结果，包括设备、批次、任务、test_id、写入状态以及后续统计完成的结果数据。

实现方式：保留必要业务表和汇总表，规范主键、唯一约束和索引，不再把海量检测明细继续堆进 MySQL。

明细分析

ClickHouse

解决什么问题：ClickHouse 保存检测明细，承担按设备、产品版本、批次、晶圆和时间等维度的海量统计查询。

实现方式：采用批量写入、时间分区、排序键和预聚合设计；根据数据保留和查询范围管理分区，避免全表扫描。

指标采集

Prometheus

解决什么问题：把服务器、容器、数据库和业务接口的运行状态持续记录下来，让故障从“用户发现”变成“系统先发现”。

实现方式：采集 CPU、内存、磁盘、网络、连接数、写入延迟、查询耗时、失败重试、备份结果和数据增长趋势。

可视化与告警

Grafana

解决什么问题：把分散的指标整理成一眼能看懂的看板，帮助业务和技术人员判断系统是否正常、容量是否接近上限。

实现方式：按总览、写入、查询、数据库、备份和服务器分组展示，并通过告警规则触发通知。

保护数据

独立备份存储

解决什么问题：生产服务器损坏时，备份不能和业务数据一起消失。

实现方式：备份写入独立存储设备或独立备份节点，分别保留每日增量、每周全量和月度归档；满一年数据按封存策略处理，并定期演练恢复。

07 / 可用性与硬件

高可用需要多个故障域，不能靠一台高配服务器

现有服务器配置为 512 GB 内存、64 核 CPU。单台服务器无法在硬件损坏、系统故障或维护期间保证业务连续，也不能把“配置高”等同于“高可用”。建议至少配置三台 Linux 服务器，现有服务器在完成数据迁移后重装为 Linux，并加入 Kubernetes 集群，作为其中一个数据或计算节点。

节点 A 业务 / 接入 / Redis 运行接入服务、缓冲层和可调度组件
节点 B MySQL / ClickHouse 业务数据、汇总结果与检测明细
节点 C 数据库副本 / Longhorn 故障切换、副本重建与持久卷保护
Longhorn 至少 3 副本 每个持久卷分布在不同节点，单节点掉线不影响卷可用性。
磁盘故障自动重建 健康节点上的副本继续服务，Longhorn 在可用磁盘上重建缺失副本。
快照不是备份 Longhorn 快照用于快速恢复，独立备份用于防误删、防勒索和机房级故障。
数据库自身副本 MySQL 和 ClickHouse 仍按各自副本机制部署，减少存储层单点。

最终硬件型号、CPU、内存、磁盘数量和容量，需要在确认单条数据实际大小、每日峰值写入、查询并发、在线保存周期和备份周期后形成正式配置清单。当前数据量估算不足以支持虚假的精确容量承诺。

必须明确的边界

Kubernetes 的自动重启只能恢复服务进程，Longhorn 只能降低存储卷的单节点单盘风险，两者都不能替代数据库副本和独立备份。MySQL、ClickHouse、Longhorn 和备份存储必须分别设计副本、切换或恢复路径。

08 / 数据迁移

先把旧数据安全搬过去，再让新系统接管业务

  1. 阶段一

    盘点与清洗

    确认表结构、数据量、主键、唯一约束、缺失值、重复数据和历史归档范围，建立迁移前的数据基线。

  2. 阶段二

    建设新环境

    完成 Linux、数据库、接入服务、Kubernetes、监控和备份链路建设，并进行基础功能验证。

  3. 阶段三

    全量迁移

    把现有核心表和明细数据迁移到新平台，保留原始数据，迁移过程记录数据量、异常记录和处理结果。

  4. 阶段四

    增量同步

    全量完成后持续同步新增和变更数据，验证增量是否完整，为业务切换准备。

  5. 阶段五

    数据核验

    核对核心表记录数、关键字段、抽样明细和业务统计结果，确认新旧系统的数据口径一致。

  6. 阶段六

    灰度切换

    先让部分查询或部分数据源切到新平台，观察稳定性、性能和告警，再逐步扩大范围。

  7. 阶段七

    业务切换与回退预案

    确认核验通过后把写入和查询切到新平台，同时保留旧系统和回退路径。旧系统只读冻结，确认新平台稳定后再进入服务器改造。

  8. 阶段八

    原服务器重装并加入集群

    确认旧数据已经完整迁移和备份后，将原 Windows 服务器重装为 Linux，配置容器运行环境、磁盘和网络，再加入 Kubernetes 集群，并加入 Longhorn 存储节点。

  9. 阶段九

    集群扩展与最终验收

    等待 Longhorn 副本重建完成，执行节点故障、磁盘故障、恢复和性能测试，确认三节点集群达到最终高可用状态。

09 / 备份与封存

备份不是把文件复制一份，而是能恢复才算数

每日增量 每天保存变化数据，MySQL 同时持续保留事务日志
每周全量 每周形成完整恢复基线，避免长期依赖多份增量拼接
每月归档 形成月度独立副本，便于追溯、审计和跨设备保存
年度封存 满一年数据压缩、校验后封存，在线库保留一年高频查询数据
3-2-1 备份原则

至少保留 3 份数据副本，使用生产存储、Longhorn 副本和独立备份三类位置；至少使用 2 种存储或介质；至少 1 份放在独立设备或异地位置。Longhorn 副本解决机器和磁盘故障，独立备份解决误删除、勒索、逻辑损坏和数据追溯，两者不是同一个能力。

备份范围、频率与恢复目标
数据范围 备份方式与频率 建议保留 建议 RPO 建议 RTO
MySQL 业务数据与汇总结果 每日全量 + 持续事务日志；每日复制到独立备份设备 30 天每日、12 周每周、12 个月每月 不超过 5 分钟 不超过 2 小时
ClickHouse 检测明细 每日增量、每周全量、每月归档；年度数据压缩封存 30 天每日、12 周每周、12 个月每月及年度封存 不超过 24 小时 根据数据量在恢复演练中确定
Redis 写入缓冲 AOF 持久化 + 副本；只保存短期待处理数据 不作为长期备份，保留待处理窗口 节点故障尽量接近 0 副本切换后继续消费
Longhorn 持久卷 至少 3 副本；定时快照并备份到独立目标 快照 7 天，独立备份不少于 30 天 单节点单盘故障为 0 5 至 30 分钟
Kubernetes 与监控配置 每日导出配置、密钥清单、部署文件和看板定义 不少于 30 天 不超过 24 小时 不超过 4 小时

备份放在哪里

生产数据先写入节点磁盘和 Longhorn 持久卷；Longhorn 通过至少 3 副本抵御单节点和单盘故障。独立备份再写入一台独立备份服务器、NAS 或对象存储，不能只放在 Kubernetes 集群内部。条件允许时，至少一份备份放在不同机房或异地位置，并对备份文件进行加密、校验和权限隔离。

恢复怎么执行

机器或磁盘故障时先由 Longhorn 副本和数据库副本恢复；逻辑损坏时按全量备份加增量备份恢复；误删除或勒索场景从隔离备份恢复；严重故障时使用异地备份重建。每季度恢复演练至少覆盖一次全量恢复和一次增量恢复，记录实际 RPO、RTO、数据校验结果和问题整改项。未实际恢复过的备份，不能视为可靠备份。

容量与目标边界

上述 RPO、RTO 是建议目标，最终值需要结合数据量、网络带宽、备份窗口和恢复演练结果确认。如果业务要求所有明细数据零丢失，需要采用同步写入和更高规格的存储、网络及副本配置，不能沿用普通每日备份或异步写入方案。

10 / 监控与恢复

让异常先被系统发现，再让服务自动恢复

监控范围

服务器

CPU、内存、磁盘容量、磁盘延迟、网络流量和文件系统状态。

容器与服务

Pod 状态、重启次数、服务健康检查、接口错误率和请求耗时。

Redis 缓冲

内存占用、待处理消息量、消费速度、AOF 状态、主从延迟和异常堆积。

数据链路

写入延迟、批量失败、test_id 状态、查询耗时、消费者积压和数据增长。

Longhorn 存储

卷健康、副本数量、降级状态、磁盘使用率、重建进度和快照备份结果。

数据保护

备份成功与失败、备份大小、备份保存位置、恢复演练状态和历史归档进度。

自动恢复的三个层次

第一层

服务进程异常

由 Kubernetes 健康检查和自动重启恢复无状态服务进程。

第二层

节点异常

Longhorn 使用健康副本继续提供持久卷，Kubernetes 把服务调度到健康节点，数据库按副本或恢复流程处理。

第三层

数据损坏或误操作

根据影响范围执行副本切换、单表恢复或全量恢复，并以备份校验和数据核验确认恢复结果。

自动恢复的边界

硬盘批量损坏、误删除、网络隔离和机房级故障不能依靠自动重启解决，需要告警、人工处置和恢复预案。自动恢复的能力取决于副本数量、数据分布和备份是否真实可用。

11 / 实施与交付

按阶段建设、验证、切换和交接

阶段 主要工作 交付结果
调研与设计 确认数据模型、查询场景、性能基线和硬件条件 详细设计、容量评估、迁移计划
环境建设 Linux、Kubernetes、Longhorn、Redis、数据库、接入服务、监控和备份链路搭建 可用测试环境、部署记录、配置说明
数据接入 实现 Redis 缓冲写入、消费者批量入库和状态更新 接入服务、接口说明、状态流转记录
数据迁移 全量迁移、增量同步、数据核验和切换演练 迁移报告、核验报告、回退方案
性能优化 分区、排序键、物化视图和典型查询优化 压测报告、优化前后对比
监控与备份 看板、告警规则、Longhorn 存储监控、备份任务和恢复演练 监控看板、告警说明、备份策略、恢复记录
原服务器改造 旧系统冻结后重装为 Linux，加入 Kubernetes 和 Longhorn 集群 节点加入记录、磁盘配置、集群验收记录
验收与交接 按验收清单逐项测试，完成文档和运维交接 验收报告、运维手册、交付清单

12 / 验收标准

每一项能力都要能被测试和复现

写入

业务请求写入 Redis 缓冲层并完成持久化后，目标在 3 秒内返回“已接收”；后台消费者继续把明细写入 ClickHouse，并更新“已入库”或“写入失败”状态。在双方约定的并发量和数据包大小下压测并记录耗时分布。

查询

以当前超过 300 秒的典型查询作为基线，建立查询清单，在真实数据量下对比优化前后耗时。不同查询分别约定目标时间，不对所有复杂查询使用同一个固定秒数。

稳定性

模拟服务进程退出，验证健康检查和自动重启；模拟一台节点或一块磁盘故障，验证 Longhorn 副本继续服务、自动重建和数据库访问不受影响。

存储

确认 Longhorn 持久卷至少 3 副本、副本分布在不同节点，节点恢复后能够自动补足副本数量，并记录副本重建耗时。

告警

模拟磁盘容量不足、服务离线和备份失败等场景，验证告警能够送达并留下记录。

备份

完成一次全量恢复和一次增量恢复演练，核对实际 RPO、RTO，输出恢复耗时、校验结果和操作记录；每季度恢复演练纳入运维计划。

一致性

迁移前后核对核心表记录数、关键字段、抽样明细和业务统计结果，异常数据必须可定位。

13 / 预期收益

从“能用”提升为“可持续运行”

生产查看更快

把海量明细查询从单机 MySQL 转移到 ClickHouse，减少等待时间，改善设备、批次和晶圆数据的查看体验。

写入结果更明确

通过 Redis 缓冲接收、消费者批量入库和状态更新，让业务知道数据是否已经接收、入库或失败。

数据保护更完整

通过 Longhorn 多副本、数据库副本、全量增量备份、年度封存和季度恢复演练，分别应对磁盘、节点、误删除和归档恢复场景。

运维响应更及时

通过 Prometheus、Grafana 和告警规则持续观察系统状态，在磁盘、服务和备份异常时提前发现。

容量增长更可控

持续记录数据量和资源趋势，为下一年度数据保留、硬件扩容和归档策略提供依据。

架构演进更清晰

Redis 负责缓冲，Longhorn 负责持久卷副本，MySQL 与 ClickHouse 各司其职，后续扩容不需要重新改变数据边界。