共计 3142 个字符，预计需要花费 8 分钟才能阅读完成。
小 T 导读：禹为科技在古代灌区信息化平台的建设过程中，经验了数据库 & 定时工作的架构、以流式计算为外围的架构和以 TDengine 为外围的架构三个阶段，最终选用 TDengine 帮忙其对水位、流量、水量等实时指标数据分析。本文分享了他们技术选型的过程，建库建表的思路以及应用 TDengine 后的收益。
公司简介
成都禹为科技有限责任公司是一家基于多年水利行业教训胜利孵化而出的高科技企业，专一于物联网、大数据和数字孪生技术在水利行业中的利用，致力于通过本身行业教训和研发能力为水利行业管理者与建设者提供全方位的数字化解决方案和价值服务。
灌区信息化平台是以灌区内建设物理网零碎、无人机零碎联合卫星遥感等感知零碎为根底，对灌区内的水雨情、土壤墒情、工程信息、气象信息及作物散布等信息进行监督，通过大数据分析，联合 GIS、数字孪生等技术为灌区提供量测水服务、供需水预报、水资源综合调度、水旱灾害进攻、供用水治理、重点区域视频监督、近程设施管制等性能。
相较于以往的水利信息化零碎，古代灌区信息化平台出现以下特点：
- 设施厂家多，数据没有对立标准，数据品质无奈保障
- 数据多且存储周期长，一个中型灌区一年数据量约为 300~500 亿条，数据要求至多保留 10 年及以上，要害数据甚至要求保留 20 年及以上
- 数据类型较为集中，次要集中在水位、流量、闸门开度、环境温湿度、土壤温湿度、雨量等
- 须要实时展现的指标较多，个别有各要害节点上的实时水位、小时均匀水位、5 分钟水量、日水量等
- 个性化的数据 OLAP 需要较多，且对数据准确性要求较高
产品架构图
为理解耦零碎中的数据接入和数据分析，咱们将数据的接入和计算剖析拆分为独立的通用物联网平台及大数据平台，在整个零碎的技术选型计划中，咱们经验了数据库 & 定时工作的架构、以流式计算为外围的架构和以 TDengine 为外围的架构三个阶段。
一、技术计划
1. 数据库 & 定时工作的架构
在零碎设计之初，咱们思考间接应用 MySQL+MongoDB+ 定时工作的形式来撑持咱们的零碎：MySQL 存储所有的业务数据及维度信息；MongoDB 存储设备实时数据以及水量等业务数据；为了解决分钟水量、日水量等数据的计算，咱们应用定时工作在计算时从 MongoDB 中获取实时数据，从 MySQL 中获取维度数据，将解决好的数据再写回 MongoDB 中，通过提前预计算的形式为前端提供数据。
但这种形式有以下几个问题：
- 无奈对设施数据进行灵便的治理剖析，设施数据乱序后须要通过人工干预或程序预处理的形式纠偏；
- 须要提前思考多种维度的数据处理，以便满足实时数据展现和 OLAP 查问的需要；
- 5 分钟水量、日水量等数据应用定时工作计算会导致数据库负载过重；
- 在数据较多的状况下，MongoDB 必须应用更多的硬件资源搭建数据库集群，能力满足存储和数据查问的要求。
2. 以流式计算为外围的架构
鉴于在数据库 & 定时工作的架构计划中呈现的数据处理较慢的问题，联合笔者在过往工作中所积攒的教训，咱们设计了流式计算数据架构计划。
数据通过物联网零碎进入零碎，通过解决后会依据设施类型被标准化为对立格局的数据，而后数据被写入 OpenTSDB 和 Kafka 中，供 Flink 生产。Flink 依照 Job 定义生产 Kafka 数据，并依照 MySQL 中的维表信息进行加工解决，而后写入 MongoDB 中；同时还将数据处理为分钟水量、日数量等业务实时所需的数据。
相较于上一版计划，数据乱序问题以及数据实时计算的问题失去了良好的解决，同时也能很好地满足 OLAP 等业务对数据的查问要求。但该计划减少了 Flink、Kafka 以及 OpenTSDB 三个较为大型的工具，无形中减少了我的项目的建设老本及运维老本。是否有一种平台能够集数据存储、音讯队列、大数据计算及剖析于一身，且不会过多的减少硬件老本？TDengine 最终走进了咱们的眼帘。
3. 以 TDengine 为外围的架构
因为以上两个计划都各自有本人的缺点，咱们试着调研寻求一个更适宜咱们的平台计划，偶然间笔者从一位从事工业物联网多年的敌人那里理解到 TDengine 这个产品，于是咱们迅速从查问效率、写入效率、稳定性、容错率以及性能完整性等方面对多个数据库进行了调研，最终咱们认为 TDengine 是当下最适宜咱们的。起因如下：
- 查问和写入速度极快，亿级数据霎时查问
- 丰盛的查问计划，可能很好地满足业务需要
- 应用和部署简略，官网文档齐全，类 SQL 语法能够升高学习老本
- 反对音讯队列、音讯订阅、缓存、流式计算等性能，劣势显著
- 集群等高级性能均开源收费，集群扩容容易
- 数据库资源需要较少，可能显著地缩小零碎的建设老本
零碎架构如下图所示。
相较于上两版计划，整个架构在数据存储和数据查问剖析环节更加简洁，应用 TDengine 代替了 Flink、Kafka、OpenTSDB 三个重量级工具。
4. 设施数据
本来咱们的零碎中就有设施模型的概念，用以隔离设施厂商之间设施数据规范不对立所带来的问题，而 TDengine 提供的超级表概念与咱们的设施模型概念不约而同！
create stable model_${设施类型编号}
(ts timestamp,${设施规范数据属性})
tags
(devicesn binary(50));
设施子表建表语句
create device_${devicesn} using model_${设施类型编号} tags (${devicesn});
实时数据的查问语句如下
select last_value(*) from device_${devicesn};
聚合数据查问也是十分不便，比方查问某设施一天内每小时的平均值
select avg(val) from device_${devicesn} where ts>now-1d interval(1h);
5. 实时指标
在灌区信息化平台中，简直所有的实时指标数据分析源数据都集中在水位、流量、水量上，为了解决业务中的需要，咱们将水位、刹时流量、累计流量从设施数据中独自抽取到一个独立的水量专题表中。
create stable st_water
(ts timestamp,waterleve float,instantflow float,accumflow double)
tags
(devicesn binary(50));
改用 TDengine 后，查问各类指标数据，咱们不再应用任何预处理，而是在前端须要展现数据时，通过 SQL 间接查问所须要的数据。比方 5 分钟水量查问语句如下：
select last(accumflow)-first(accumflow) from st_water where ts>now-1d and devicesn=xxxx interval(5m)
一条 SQL 解决了以往须要一番周折能力解决的问题，太棒了！！
6. 应用 TDengine 后的收益
- * 简化了零碎架构
- TDengine 的音讯订阅、缓存、流式计算等诸多个性，能够代替 Kafka、OpenTSDB 和 Flink，缩小业务代码中定时计算（如用水量）等性能，简化了整体架构
- * 升高运维老本和开发成本
- 架构简化当前，排查和定位问题能疾速响应，节约开发和运维老本
- * 升高数据存储老本
- TDengine 表结构设计正当，能够节俭存储空间，进而节俭存储费用
- * 进步数据实时性和一致性
- TDengine 代替了 OpenTSDB+Redis+MySQL，进步了数据实时性和一致性
二、将来瞻望
在古代灌区信息化平台建设过程中，因为某些历史起因，咱们还有许多如闸门管制、状态实时预警、水旱灾害进攻等业务性能仍旧在应用定时工作来进行告警触发。咱们筹备在不久的未来，将以上业务与 TDengine 的告警性能联合起来，逐渐将零碎对立起来。也心愿 TDengine 越来越好！
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。
