杨凌美畅用 TDengine 时序数据库，支撑 500 条产线 2 年历史数据追溯

杨凌美畅工业研发团队凡银生、邵强

2025-10-14 / 时序数据库 - 用户案例, 时序数据库

小T导读：在制造业智能化产线监控实践中，杨凌美畅早期基于 TDengine TSDB 3.0.7.1 Windows 开源版，支撑了 108 条产线、23 万测点的基础监控。随着业务规模迅速扩大，原有架构的性能与稳定性逐渐成为瓶颈。针对这一挑战，杨凌美畅组织专项攻关，引入 TDengine TSDB 企业版 3.3.6.10 Linux，并重构时序数据处理架构与数据模型。目前系统已稳定接入 500 条产线、150 万测点，实现查询耗时稳定 ≤1 秒，告警全链路（从故障发生、数据写入、流计算处理到应用推送）时延 ≤10 秒。同时为扩展至 800 条产线预留了充足性能冗余，数据处理能力与业务适配性实现了质的飞跃。本文对此实践展开深入分享。

业务目标与痛点

在智能化产线的建设过程中，杨凌美畅始终围绕“产线全周期数据管理”这一核心目标推进数字化升级。企业对数据系统的业务诉求主要集中在以下三个方面：

首先是产线实时监控。目前公司已部署 500 条产线，每条产线配备 4 个 PLC 设备，总计约 150 万测点，需要实时采集电压、电流、温度等关键数据，并在监控室同步展示设备运行状态。一旦出现异常，系统必须能快速触发告警。
其次是生产效能分析。企业需要保留 2 年历史数据，用于开展产线优化分析，包括设备故障的根因追溯、产能波动的对比研究，从而为生产效率的提升提供数据支撑。
最后是业务高可用。产线必须 7×24 小时不间断运转，这就要求数据处理系统全年保持 99.99% 的可用性。同时，实时数据备份和灾难恢复机制也至关重要，以确保数据安全和连续生产。

然而，在实际运行中，现有系统暴露出多方面的痛点和挑战：

高可用缺失，业务连续性无保障。 作为制造业企业，我们的产线需 7×24 小时不间断运转，对业务连续性要求极高。早期基于 TDengine TSDB 开源版搭建的系统，在初期阶段完全能够满足生产需求。但随着产线规模和数据体量快速增长，单机单副本的部署模式逐渐难以支撑更高层级的连续性要求——例如在硬件或数据库发生异常时，系统可能需要较长时间才能恢复。与此同时，开源版主要提供了基础的备份工具，适合一般场景，但在我们这种大规模连续生产环境下，就需要更完善的自动化备份与恢复机制。曾经在一次备份失败的情况下，企业内部排查和修复过程较为耗时，影响了部分历史数据的完整性，也让我们更加意识到高可用和容灾机制的重要性。

性能与功能不足，支撑规模受限。随着业务需求增加，接入的产线数量不断扩充，从最开始的 108 条，逐步增加到现在的 500 条，未来还计划扩展到 800 条，对应的测点数量也从 23 万增长到 150 万，并且还会持续增加。在这一过程中，基于开源版的单机架构在起步阶段表现良好，但随着数据体量和实时性要求不断提升，逐渐显现出局限。在大规模产线数据处理时，查询耗时会出现一定波动：快的时候可在 1 秒内返回，但在高负载场景下可能延长至几十秒。这种不稳定性在日常监控中尚可接受，但对于异常检测和快速响应等关键业务，就需要更高层级的性能保障。

高保障不足，升级迁移风险大。因业务连接性要求，数据迁移、系统升级以及数据恢复都面临诸多难题，不能因这些操作导致生产停机或中断，否则会造成巨大经济损失。开源版缺乏原厂保障，迁移需人工导出导入，耗用资源较高且耗时较长，可能影响生产环境正常运行，若操作过程中出现异常，会进一步延长业务中断时间。

综上，随着业务规模的不断扩张和智能化水平的提升需求，现有架构的局限性愈发明显。如何在保障业务连续性的前提下，提升系统的高可用性、性能和可扩展性，成为我们当下必须解决的关键问题。

2025 年 5 月，我司决定引入 TDengine TSDB 企业版，从根本上解决时序数据处理系统历史问题，并为后续产线扩充，打下坚实基础。

基于企业版的高可用架构设计

从业务目标出发，依托 TDengine TSDB 3.3.6.10 企业版专属功能，我们构建了 “Linux 操作系统 + 数据双副本 + 自动化数据备份” 的高可用系统架构，彻底解决开源版单机单点风险，系统可用性相较于开源版架构有了极大的提升，满足 99.99% 业务连续性需求。

杨凌美畅用 TDengine 时序数据库，支撑 500 条产线 2 年历史数据追溯 - TDengine Database 时序数据库

Linux 操作系统适配：替换原 Windows 系统为 Ubuntu Linux 操作系统，提升系统稳定性与资源利用率，为高可用架构奠定底层基础；
双副本数据冗余功能：通过 TDengine TSDB 企业版 “双副本” 功能，在成本可控基础上，实现数据副本冗余，任一节点异常时，另一节点可无缝接管服务，避免数据丢失或停服；
自动化数据备份保障：依托 TDengine TSDB 企业版 “备份管理” 专属功能，制定 “每日增量备份”策略，通过备份工具，每天 0 点进行备份，且可以指定备份服务节点和使用磁盘空间目录，备份过程可通过企业版管理页面可视化配置，支持备份任务监控与日志查询，彻底解决开源版 “手工备份” 问题。

基于企业版的高性能优化

数据库及模型设计优化

数据库建模优化

CREATE DATABASE `iot` BUFFER 256 CACHESIZE 1 CACHEMODEL 'none' COMP 2 DURATION 1440m WAL_FSYNC_PERIOD 3000 MAXROWS 4096 MINROWS 100 STT_TRIGGER 1 KEEP 5256000m,5256000m,5256000m PAGES 256 PAGESIZE 4 PRECISION 'ms' REPLICA 3 WAL_LEVEL 1 VGROUPS 10 SINGLE_STABLE 0 TABLE_PREFIX 0 TABLE_SUFFIX 0 TSDB_PAGESIZE 4 WAL_RETENTION_PERIOD 3600 WAL_RETENTION_SIZE 0 KEEP_TIME_OFFSET 0 ENCRYPT_ALGORITHM 'none' S3_CHUNKSIZE 262144 S3_KEEPLOCAL 5256000m S3_COMPACT 0

分片优化：建库参数 VGROUPS 调整为 20，目前有 108 个工作台的 PLC 数据接入，最终可能接入 800 个工作台的 PLC 数据，跟进最大数据接入情况，预估创建 20 个 vnode，每个 vnode 使用单独读写线程，充分利用计算资源，使得性能最大化。
分区优化：建库参数 DURATION 调整为 10d，将分区长度调整为 10 天，10 天一个数据文件组，便于快速检索、定位到具体的文件，无需遍历搜索。
写入缓存：建库参数 BUFFER 调整为 256，一个 vnode 写入内存池的大小，批次落盘，优化数据写入速度。

超级表建模优化

模型重构核心思路

我们的原有设计未使用超级表，108 条产线对应 1420 张普通表，查询需遍历多张表，效率极低。升级后基于 “设备类型 + 业务场景” 划分超级表，共 13 张超级表，大幅提升查询效率。

核心超级表示例：

超级表名称	对应业务场景	核心字段（时序数据）	标签（Tag，用于筛选产线）
metron_dmp.alarm	全产线通用告警数据	ts（TIMESTAMP）、m6033（设备故障码）、m6120（告警等级）	line（产线编号）、workshop（车间）、factory（工厂）
metron_dmp.easy_plc	PLC 设备关键参数（电流 / 温度）	ts、yudu_dianliu（主轴电流）、dianjie_wendu（电解温度）	line、workshop、factory
metron_dmp.back_ac802	收线 AC802 设备运行参数	ts、sx_px_fuzailv（负载率）、sx_px_zhuansu（转速）、sxzlb_weizhi（位置）	line、workshop、factory

模型优化效果
- 查询效率：筛选某车间 10 条产线的 1 天告警数据，由于此前应用的开源版未使用超级表，只能遍历 140 张普通表，耗时 12 秒；企业版通过超级表标签筛选，耗时 0.5 秒，效率提升 23 倍；
- 扩展能力：新增产线时，仅需在对应超级表下创建子表（继承标签与结构），500 条产线场景下，新增产线更加便捷，无需修改表结构。

查询优化

优化调整查询 SQL，利用超级表和标签索引快速定位数据，减少查询耗时，例如：

单产线查询：查询某条产线 1 天内的 PLC 电流数据（约 8.6 万条），优化前耗时 1.5 秒，优化后耗时 0.3 秒；
多产线聚合查询：查询某车间 100 条产线 1 个月的平均产能，优化前耗时 12 秒，优化后耗时耗时 0.8 秒；
历史数据查询：查询某产线 6 个月前的故障告警记录，优化前该场景因历史数据保存周期无法实现，优化后耗时仅 0.9 秒。

流计算告警优化

在最初的设备告警流程中，系统需要通过时序数据库轮询查询数据，再由应用层进行比对，最后将告警结果写入 SQL Server 触发告警。整个链路涉及多个处理环节，技术复杂度高，告警延迟也较大。

在优化后，告警逻辑直接依托 TDengine TSDB 的流计算功能实现，数据比对与告警触发均在数据库内部完成，大幅简化了处理流程，不仅降低了系统复杂度，也显著提升了告警响应的实时性和稳定性。

create stream front_ac802_alarm_stream trigger at_once into metron_dmp_stream.alarm tags(line varchar(20), workshop varchar(20), factory varchar(20)) subtable(tname) as select _wstart as ts,last_row( m6033  ) as m6033,last_row( m6120  ) as m6120,last_row( m6121  ) as m6121,…… from  metron_dmp.alarm partition by tbname tname, line, workshop, factory  STATE_WINDOW(cast(case when m6033 is null then 0 else m6033  end + case when m6120 is null then 0 else m6120  end + case when m6121 is null then 0 else m6121  end + …… as int));

流计算配置：基于metron_dmp.alarm超级表创建流计算，触发模式设为 “实时触发”，聚合故障码与告警等级，结果写入metron_dmp_stream.alarm结果表；
告警流程：应用通过数据订阅功能监听结果表，获取实时告警数据后直接推送至监控大屏，无需中间数据库中转；
效果：告警从 “故障发生→数据写入→流计算处理→应用推送” 全程 ≤10 秒，原方式需 21-44 秒，效率提升 3 倍左右。

基于企业版的高保障专业服务

历史数据迁移（从开源版到企业版）

迁移挑战

需同步开源版 108 条产线的恢复的历史数据，且不能影响现有产线的实时数据采集。

迁移方案（无停机）

我们依托 TDengine TSDB 企业版原生工具 taosX 的实时数据同步功能，实现了无感知升级：在新集群（企业版）完成部署后，taosx 会自动且持续地同步历史数据与实时数据；待历史数据同步完毕，仅需通过配置调整数据接入指向，即可无缝切换至新集群。整个过程无需停机，业务查询也能保持正常，保障了生产业务连续性。

跨版本、跨系统同步： 借助 taosX，实现了从 Windows → Linux 的数据迁移，并支持不同版本间的平滑升级。
表结构同步：先同步超级表与子表结构，确保数据模型一致。示例：

taosx run -f "taos+ws://windows_ip:6041/dmp?schema=only&./tables=@table_list.txt" -t "taos+ws://linux_ip:6041/metron_dmp"

增量数据同步： 历史数据按时间分片迁移，每次同步 1 天的数据，避免对源端造成过大压力，同时保持实时写入不断流。示例：

taosx run -f "taos+ws://windows_ip:6030/dmp?schema=none&tables=@./table_list.txt&start=2025-05-01T00:00:00+0800&end=2025-05-02T00:00:00+0800&workers=48" -t "taos://linux_ip:6030/metron_dmp"

数据校验： 同步完成后，随机抽取 10 条产线 × 100 条数据，逐一比对源端与目标端，确认数据完整性 100%。
迁移结果：耗时 48 小时完成 108 条产线历史数据同步，迁移期间实时数据写入无丢包，业务查询正常。

高效快捷的实施服务

在涛思与杨凌美畅的紧密协作下，整个实施过程仅用 11 天就完成了从数据同步、集群部署到副本切换的全流程，高效推动了 TDengine TSDB 企业版在生产环境的平稳落地。

同时，涛思数据还提供企业级专属维保服务：每月一次例行巡检，借助企业版巡检工具对 CPU、内存、磁盘 IO 及集群运行状态进行全面检查，提前发现并预警潜在风险；并提供 7×24 小时技术支持，第一时间响应业务咨询与问题处置。通过这一系列措施，切实保障了我司生产系统的稳定可靠运行。

未来规划

随着产线规模的持续扩充，我们将充分发挥 TDengine TSDB 企业版的横向扩展能力，通过在线增加节点，进一步提升系统的数据处理与支撑能力。

同时，我们也计划引入涛思数据推出的 TDengine IDMP（AI 原生的工业数据管理平台）。该平台采用经典的树状层次结构对传感器与设备数据进行组织，建立统一的数据目录，并对数据进行语境化与标准化处理，并提供实时分析、可视化、事件管理与报警等功能。借助 IDMP，我们能够进一步强化设备管理与生产分析水平，为未来的智能化运营奠定坚实基础。