TDengine 在雷达台站运维管理系统中的落地实践

作者：雷达台站运维项目研发团队

小 T 导读：该雷达和平安城市研发单位是国家技术创新示范企业、国家高新技术企业、全国电子信息行业标杆企业、“平安城市”建设优秀安防工程建设企业，是首批安徽省创新型企业、安徽省产学研联合示范企业、安徽省重点软件企业，股票代码 600990。

随着大数据时代的到来，民航行业对数据的重视程度提高，对空管设施设备可靠性、安全性、智能化水平也提出了更高的要求。在这一背景下，智慧化雷达台站的建设提上日程，为便于对台站进行全局的管理，提高台站运行效率，民航开始推动以集中化的管理模式对雷达台站进行智慧运行管控——以台站智能化设备为基础，利用先进的信息化技术构建台站管理信息化应用体系。这一举动旨在为业务统一、高效管理提供信息服务支撑，解决台站运行维护痛点，推进空管台站向管控自动化、智慧化发展。

我们在雷达台站运维管理系统中搭建了数个传感器设备，这些传感设备种类杂数量多，大致可以分为以下几类：声音传感器、XYZ 三向轴振动传感器、倾斜角度传感器、电力模拟量传感器、风速传感器等等。

由于传感器设备采集数据频度高，数据传输量大，要求存储数据库具有极高的数据吞吐率和存储低延时，特别是声音传感器，每秒钟要采集 22050 条数据，常规的事务型数据库(MySQL、Oracle 等)对这类数量级的结构化数据存储早已力不从心，而使用基于事务型数据库的分表分库中间件（ShardingSphere、MyCat 等）又会把技术架构变得更加复杂，也会大大提高后期系统运维成本。

基于此，我们决定进行数据库选型，以匹配雷达台站运维管理系统的搭建。

为什么会选择 TDengine

综合考虑软硬件成本和后期系统的技术维护成本，我们先后调研了时间序列数据库中的 InfluxDB、TDengine、OLAP 工具 ClickHouse 以及曾使用过的 Hadoop 技术栈中的 HBase（Hive、Kylin）。由于服务器数量所限，我们首先放弃了基于 HBase（Hive、Kylin）的技术方案，随后对 InfluxDB、TDengine 和 ClickHouse 做了写入和查询性能对比，发现在相同配置的服务器硬件资源中，TDengine 都发挥出了最好的性能表现。部分性能对比如下图：

同时我们也查询了两款数据库软件在 GitHub 和 Gitee 等国内外开源托管平台上的社区活跃程度，并了解到 TDengine 不仅集群版已经进行开源且还是一款国产化的数据库产品，在当下国产化的大趋势背景下，我们就此选定了 TDengine 作为存储海量传感器数据的时序数据库，配合传统的关系型数据库 MySQL（用于存储组织机构、用户名、密码、巡检记录等强事务型数据）一起作为系统的后端底层存储数据库。

选定数据库之后，搭建便开始进行。下面我会介绍一下我们在搭建时遇到的一些避坑经验，给到大家参考。

TDengine 具体实践

具体到我们的场景中，使用 TDengine 建库建表思路如下图所示。

TDengine 在使用数据库的时间精度上默认的是毫秒，但是系统的声音振动传感器采集频率是 22050HZ，即每秒钟采集 22050 条数据，因此我们对数据存储的时间精度要求到纳秒级别，需要修改数据库默认的时间精度。相关指令如下：

#振动声音表(微妙时间精度)(22050/s)#创建纳秒时间精度数据库CREATE DATABASE radar_us_sc precision "us" KEEP 365 DAYS 10 BLOCKS 4 UPDATE 1;#使用刚刚创建的数据库USE radar_us_sc;#创建超级表CREATE TABLE st_sc_shock (ts timestamp, ch1 float,ch2 float,ch3 float) TAGS (location binary(32), groupdId int);#创建普通表（继承上面的超级表）CREATE TABLE t_sc_shock_hf20101 USING st_sc_shock TAGS ("test", 1);#手动插入微秒级时间戳数值（测试数据）INSERT INTO t_sc_shock_hf20101 VALUES (1613799712123412, 10,10,10);

这里需要注意的是由于是纳秒级别的时间精度，在插入测试数据时，时间戳字段对应的数值比普通时间戳多 3 位数字，且不需要有小数点。

其它传感器例如风速传感器，使用默认的时间精度建表语句即可：

#风速表-建库(时间精度是默认的毫秒)CREATE DATABASE radar_sc KEEP 365 DAYS 10 BLOCKS 4 UPDATE 1;#使用风速表USE radar_sc; #建超级表，Tag里面只定义，不设置具体值CREATE TABLE st_sc_wind (ts timestamp, speed float) TAGS (location binary(32), groupdId int);#建普通表，在定义普通表的时候给出Tag的具体值CREATE TABLE t_sc_wind_hf40101 USING st_sc_wind TAGS ("test", 1);

在上层的业务应用中，用户需要试听一段时间的雷达转机的声音去判断雷达运行状态是否正常，页面请求数据库给出开始时间和结束时间这两个时间段的数据，再通过声音还原算法将这些结构化文本数据还原成可以播放的 WAV 或者 MP3 文件，用户在页面上即可实时听到部署在雷达转机运转的声音，再配合我们在前端网页上渲染出来的频谱图、时域图、频域图，来一起判断雷达转机工作是否正常。

由于我们需要基于时域图和频域图去判断雷达转机工作是否正常，因此在生成频域图之前，我们需要预先在数据库中把原始数据按照频率分段生成数千张子频率段表，再基于这些子频率段表进行 FFT 转换从而得到频域图。

在一次删除数千张子频率段表操作中，删除语句执行之后，数据库访问和插入变得异常缓慢，我们的第一反应是数据库负载过高，于是尝试重启数据库，在数据库关闭并且重新启动之后，数据库服务状态显示启动正常，但客户端却仍然连接不上。此时我们找到 TDengine 的日志，通过翻看日志发现命令行程序 taos，正在恢复重启数据库之前的尚未完成的删除表操作，操作 WAL(Write Ahead Log)，而此时 taos 仅仅读取了数千个日志中的前几百个。大约等待了数小时后，数据库客户端才可以查询到数据，数据库得以正常使用。

systemctl status taosdjournalctl -u taosd.service

在涛思数据技术支持人员的帮助下，我们决定升级 TDengine，升级数据库需要先卸载旧版本，操作如下：

rmtaos或者rpm -e TDengine

然后下载新版本的 TDengine，在 Server 的目录里执行命令如下：

install.sh

TDengine 的整个升级过程比较简单，新版本的数据库启动之后即可使用，同时也建议涛思数据的研发人员在 taos 启动时监测下上次未完成读取的 WAL 文件，再启动进度条中显示读取执行 WAL 文件进度，这样可以让数据库使用者知道现在数据库的真实状态和进度。

搭载 TDengine 的系统架构详解

整体来看，雷达台站智能运维系统分为单台站系统和中心站系统两种类型。单台站系统组成内容包括台站现场的主设备监控、网络设备监控、动力设备监控、环境设备监控、专项数据分析、机器人巡检、雷达台站智能运维系统管理平台、雷达台站智能运维系统 APP 等。

中心站是远端多个单台站信息集成的中心，可以对多个单台站的数据进行融合处理，功能包括总体运行态势分析、数据融合、数据挖掘、专家知识库、自主学习、辅助决策等功能，日常管理人员可以通过该中心站平台远程管理所有接入雷达台站智能运维系统系统的单台站。

雷达台站智能运维系统移动终端软件可在手机或平板电脑上运行，功能由台站态势监测、实时数据监测、报警预警、工单流转、技术会诊、专项分析、知识库、机器人控制、视频监控等应用功能。

其业务架构主要包括数据来源层、数据存储层、数据模型层，数据接口层、业务应用层、业务展示层和用户终端几个部分，如下图所示。

整体架构由底层到上层组成主要分为以下几个层面：数据来源层、数据存储层、数据模型层、数据接口层、业务模块层、业务展示层。

数据来源层可以利用物联网传感器和智能采集技术对台站运行情况进行多维度信息采集。物联数据采集包括台站的环境监测、设备检测、动力监测、数据监测、服务监测、网络链路监测、资源监测等几个方面。

数据存储层的作用是对所有监测的数据进行统一的数据清洗，剔除异常数据后融合成标准化的格式并进行存储。数据存储层对不同的数据类型采用不同的底层存储方式，具有明显时间序列属性的传感器数据将会被存放在 TDengine 中，并且按照不同的业务数据形成不同的业务主题库。

而且数据存储层具有数据缓冲的功能，并能按数据的访问频率自动建立数据缓存，合理规划系统内冷热数据的存储方式，提高数据访问的速度。此外，存储层还会定时对数据进行备份存储、冷热数据替换以及数据诊断，及时发现数据存储的故障隐患、保证数据的存储安全性。

数据模型层能够根据业务需求利用存储的数据建立多个数据分析模型，提供模型算法统一的运行环境，包括实时分析和批处理分析，并能对运行的模型算法进行统一管理，包括算法任务启停、服务编排、算法运行监控、算法资源管理、算法运行告警、算法模型库等多个功能。

通过分析算法历史对海量监测数据进行综合分析，利用多维数据相关性分析技术，可以将以往一些不被注意但会产生实际影响的传感器数据囊括进特征提取建模和神经网络建模的过程中，结合历史数据对实时全量数据进行深度挖掘，再结合过往的设备运维实际经验便可预测出故障发生的概率，实现智能故障预测。

数据接口层利用多种行业内通用的数据共享接口实现系统数据和其它第三方平台以及 APP 端的数据共享，支持的数据接口方式包括 RESTful、消息队列、中间库等多种方式，且能控制数据的共享权限和共享目录。

业务模块层通过平台底层提供的数据和基础服务，可在上层开发构建多个业务智能应用，同时提供了上层应用统一运行的环境。业务模块功能主要包括工单系统、实时监测、智能预警、态势分析、远程控制、专项分析、健康评价、告警联动、自动巡检、专家知识库、智能安防等。

在业务展示层，可根据系统使用人员和使用场景的区别来构建多个业务展示平台。其中本地管理平台和远程管理平台分别作用于单台站和中心站的管理，同时配备了移动端软件方便台站管理人员远程对台站进行管理和监控。展示平台可按用户使用权限的不同来展示不同的数据和视图，管理人员视图更倾向于宏观全局的数据展示维度，维保人员视图展示的是细节和本人工作相关的展示维度。

写在最后

在实现快速查询检索提升用户体验的同时，TDengine 还可以达到节省硬件服务器资源和降低系统后期运维成本的目的。考虑到 TDengine 在本项目中各项性能指标和数据库稳定性的优异表现，在未来的平安城市、智慧社区等业务场景中，我们也会考虑使用 TDengine 用于存储过车记录、人脸识别记录和 WiFi 探针记录等数据，展开更深层次的合作。

🌟近期taosAdapter已正式发布，支持从 OpenTSDB 等时序数据库向 TDengine 无缝迁移，欢迎阅读 TDengine 此前发布的技术文章，了解体验 taosAdapter！