随着大数据时代的到来，民航行业对数据的重视程度提高，对空管设施设备可靠性、安全性、智能化水平也提出了更高的要求。在这一背景下，智慧化雷达台站的建设提上日程，为便于对台站进行全局的管理，提高台站运行效率，民航开始推动以集中化的管理模式对雷达台站进行智慧运行管控——以台站智能化设备为基础，利用先进的信息化技术构建台站管理信息化应用体系。这一举动旨在为业务统一、高效管理提供信息服务支撑，解决台站运行维护痛点，推进空管台站向管控自动化、智慧化发展。我们在雷达台站运维管理系统中搭建了数个传感器设备，这些传感设备种类杂数量多，大致可以分为以下几类：声音传感器、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 taosd
journalctl -u taosd.service
在涛思数据技术支持人员的帮助下，我们决定升级TDengine，升级数据库需要先卸载旧版本，操作如下：然后下载新版本的TDengine，在Server的目录里执行命令如下：TDengine的整个升级过程比较简单，新版本的数据库启动之后即可使用，同时也建议涛思数据的研发人员在taos启动时监测下上次未完成读取的WAL文件，再启动进度条中显示读取执行WAL文件进度，这样可以让数据库使用者知道现在数据库的真实状态和进度。搭载TDengine的系统架构详解
整体来看，雷达台站智能运维系统分为单台站系统和中心站系统两种类型。单台站系统组成内容包括台站现场的主设备监控、网络设备监控、动力设备监控、环境设备监控、专项数据分析、机器人巡检、雷达台站智能运维系统管理平台、雷达台站智能运维系统APP等。中心站是远端多个单台站信息集成的中心，可以对多个单台站的数据进行融合处理，功能包括总体运行态势分析、数据融合、数据挖掘、专家知识库、自主学习、辅助决策等功能，日常管理人员可以通过该中心站平台远程管理所有接入雷达台站智能运维系统系统的单台站。雷达台站智能运维系统移动终端软件可在手机或平板电脑上运行，功能由台站态势监测、实时数据监测、报警预警、工单流转、技术会诊、专项分析、知识库、机器人控制、视频监控等应用功能。其业务架构主要包括数据来源层、数据存储层、数据模型层，数据接口层、业务应用层、业务展示层和用户终端几个部分，如下图所示。整体架构由底层到上层组成主要分为以下几个层面：数据来源层、数据存储层、数据模型层、数据接口层、业务模块层、业务展示层。数据来源层可以利用物联网传感器和智能采集技术对台站运行情况进行多维度信息采集。物联数据采集包括台站的环境监测、设备检测、动力监测、数据监测、服务监测、网络链路监测、资源监测等几个方面。数据存储层的作用是对所有监测的数据进行统一的数据清洗，剔除异常数据后融合成标准化的格式并进行存储。数据存储层对不同的数据类型采用不同的底层存储方式，具有明显时间序列属性的传感器数据将会被存放在TDengine中，并且按照不同的业务数据形成不同的业务主题库。而且数据存储层具有数据缓冲的功能，并能按数据的访问频率自动建立数据缓存，合理规划系统内冷热数据的存储方式，提高数据访问的速度。此外，存储层还会定时对数据进行备份存储、冷热数据替换以及数据诊断，及时发现数据存储的故障隐患、保证数据的存储安全性。数据模型层能够根据业务需求利用存储的数据建立多个数据分析模型，提供模型算法统一的运行环境，包括实时分析和批处理分析，并能对运行的模型算法进行统一管理，包括算法任务启停、服务编排、算法运行监控、算法资源管理、算法运行告警、算法模型库等多个功能。通过分析算法历史对海量监测数据进行综合分析，利用多维数据相关性分析技术，可以将以往一些不被注意但会产生实际影响的传感器数据囊括进特征提取建模和神经网络建模的过程中，结合历史数据对实时全量数据进行深度挖掘，再结合过往的设备运维实际经验便可预测出故障发生的概率，实现智能故障预测。数据接口层利用多种行业内通用的数据共享接口实现系统数据和其它第三方平台以及APP端的数据共享，支持的数据接口方式包括RESTful、消息队列、中间库等多种方式，且能控制数据的共享权限和共享目录。业务模块层通过平台底层提供的数据和基础服务，可在上层开发构建多个业务智能应用，同时提供了上层应用统一运行的环境。业务模块功能主要包括工单系统、实时监测、智能预警、态势分析、远程控制、专项分析、健康评价、告警联动、自动巡检、专家知识库、智能安防等。在业务展示层，可根据系统使用人员和使用场景的区别来构建多个业务展示平台。其中本地管理平台和远程管理平台分别作用于单台站和中心站的管理，同时配备了移动端软件方便台站管理人员远程对台站进行管理和监控。展示平台可按用户使用权限的不同来展示不同的数据和视图，管理人员视图更倾向于宏观全局的数据展示维度，维保人员视图展示的是细节和本人工作相关的展示维度。写在后
在实现快速查询检索提升用户体验的同时，TDengine还可以达到节省硬件服务器资源和降低系统后期运维成本的目的。考虑到TDengine在本项目中各项性能指标和数据库稳定性的优异表现，在未来的平安城市、智慧社区等业务场景中，我们也会考虑使用TDengine用于存储过车记录、人脸识别记录和WiFi探针记录等数据，展开更深层次的合作。来源 https://www.modb.pro/db/181480