关于大数据:双汇大数据方案选型从棘手的InfluxDBRedis到毫秒级查询的TDengine

双汇发展多个分厂的能源管控大数据系统次要采纳两种技术栈：InfluxDB/Redis和Kafka/Redis/HBase/Flink，对于中小型研发团队来讲，无论是零碎搭建，还是施行运维都十分辣手。通过对InfluxDB/Redis和TDengine大数据平台的性能和性能比照测试，最终将TDengine作为实施方案。

我的项目背景

基于双汇发展对能源管控的需要，利用云平台技术以及电气自动化解决伎俩，对双汇发展的一级、二级、三级能源仪表进行整体革新，实现仪表组网，进一步通过边缘网关进行能源在线监测数据的采集，并上报至云平台，建设对立能源管理信息化零碎，实现能源的实时监控、报表统计、能源流向剖析与预测，升高企业单位产品能源消耗，进步经济效益，最终实现企业能源精细化治理。

总体架构

能源管控平台基于公有云构建，包含残缺的IaaS层、PaaS层和SaaS层，而能源采集零碎作为管控平台中最为重要的一环，采纳TDengine作为外围数据引擎，通过Restful接口进行仪表在线数据插入，并实现大规模时序数据的高效稳固存储，同时，也为能源管控应用层提供实时数据查问、历史聚合统计、流计算和订阅服务等性能，实现能源地图监控、能耗预警、能源流向预测和能源互联综合决策，具体架构如下图所示。

TDengine要害利用

Connector抉择

本我的项目数据采集最要害的环节，就是将订阅到的MQTT数据插入到TDengine中，于是也就波及到了TDengine连接器的抉择，咱们平时我的项目中java应用居多，而且JDBC的性能也绝对较强，实践上，应该抉择JDBC API，但最终抉择了RESTful Connector，次要思考以下几点：

1）简洁性

毫无疑问，RESTful通用性最强，TDengine间接通过HTTP POST 申请BODY中蕴含的SQL语句来操作数据库，而且TDengine自身作为时序数据库并不提供存储过程或者事务机制，基本上都是每次执行单条SQL语句，所以RESTful在应用上很简便。

2）可移植性

本我的项目的Java利用都是部署在Kubernetes中，所以向TDengine插入数据的Java利用须要容器化部署，而之前理解到，JDBC须要依赖的本地函数库libtaos.so文件，所以容器化部署可能较为麻烦，而RESTful仅需采纳OKHttp库即可实现，移植性较强。

3）数据规模

本项目数采规模不大，大概每分钟7000条数据，甚至后续数采性能扩大到其余分厂，RESTful也齐全满足性能要求。

但总体来讲，JDBC是在插入与查问性能上具备肯定劣势的，而且反对从firstEp和secondEp抉择无效节点进行连贯（相似于Nginx的keepalive高可用），目前TDengine版本公布状况上看，JDBC的保护与晋升也是重中之重，后续我的项目也可能会向JDBC迁徙。

RESTful代码实现

1）ThreadPoolExecutor线程池

订阅EMQX和RESTful插入TDengine的代码写在了同一个java服务中，每接管到一条MQTT订阅音讯，便开启一个线程向TDengine插入数据，线程均来自于线程池，初始化如下：

ExecutorService pool = new ThreadPoolExecutor(150, 300, 1000, TimeUnit.MILLISECONDS,        new ArrayBlockingQueue<Runnable>(100), Executors.defaultThreadFactory(),new ThreadPoolExecutor.DiscardOldestPolicy());

线程池采纳基于数组的先进先出队列，采纳抛弃晚期工作的回绝策略，因为本次场景中单次RESTful插入数据量大概在100~200条，执行速度快，迟迟未执行完极可能是SQL语句异样或连贯taosd服务异样等起因，应该抛弃工作。外围线程数设为150，绝对较高，次要为了保障顶峰抗压能力。

2）OKHttp线程池

在每个ThreadPoolExecutor线程中，基于OKHttp库进行RESTful插入操作，也是采纳ConnectionPool治理 HTTP 和 HTTP/2 连贯的重用，以缩小网络提早，OKHttp重点配置如下：

public ConnectionPool pool() {    return new ConnectionPool(20, 5, TimeUnit.MINUTES);}

即最大闲暇连接数为20，每个连贯最大闲暇工夫为5分钟，每个OKHttp插入操作采纳异步调用形式，次要代码如下：

public void excuteTdengineWithSqlAsync(String sql,Callback callback)  {    try{        okhttp3.MediaType mediaType = okhttp3.MediaType.parse("application/octet-stream");        RequestBody body = RequestBody.create(mediaType, sql);        Request request = new Request.Builder()                .url(tdengineHost)                .post(body)                .addHeader("Authorization", "Basic cm9vdDp0YW9zZGF0YQ==")                .addHeader("cache-control", "no-cache")                .build();        mOkHttpClient.newCall(request).enqueue(callback);    } catch (Exception e) {        logger.error("执行tdengine操作报错:"+ e.getMessage());    }}

3）Java打包镜像

长期压力测试显示，每秒执行200次RESTful插入申请，单次申请蕴含100条数据，每条数据蕴含5组标签，Java服务内存稳固在300M~600M。而且上述模仿规模仅针对单个Java利用而言，在Kubernetes能够跑多个这样pod来生产不同的MQTT主题，所以并发能力齐全够用。打包镜像时，堆内存最大值设为1024MB，次要语句为：

ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-XX:MaxRAM=2000m","-Xms1024m","-jar","/app.jar"]

性能测试

1）RESTful插入性能

依照3.2大节中的RESTful代码进行数据插入，Java程序和TDengine集群均运行在公有云中，虚拟机之间装备万兆光纤交换机，Java程序具体如3.2大节所示，TDengine集群部署在3个虚拟机中，配置均为1TB硬盘、12核、12GB（公有云中CPU比拟富余，但内存比拟缓和），通过大概三周的生产环境运行，性能总结如下：

表1 生产环境下RESTful插入性能测试

生产环境下，单条插入性能极高，齐全满足需要，当然后期也进行过稍大规模的插入场景模仿，次要是基于2.0.4.0当前的版本，留神到2.0.4.0之前的TDengine版本RESTful的SQL语句下限为64KB。模仿环境下，RESTful插入性能十分优良，具体如下表所示。

表2 模仿环境下RESTful插入性能测试

2）RESTful查问性能

应用RESTful进行SQL查问时，性能也是十分好，目前实在生产环境中，数据总量为800万，绝对薄弱，所以查问性能测试在模仿环境下进行，在8亿数据量下，LAST_ROW函数能够达到10ms响应速度，count、interval、group by等相干函数执行速度均在百毫秒量级上。

实施方案

本我的项目针对双汇发展上司的6个分厂（后续会持续裁减）进行能源数据采集，大概1200多块仪表（后续会持续裁减），每块仪表包含3至5个采集标签，采集频率均为1分钟，数据接入规模不大。六个厂各自有独立的租户空间，为了不便各自的时序数据库治理，同时也不便各厂间的聚合查问（目前六个分厂均隶属双汇发展总部），所以各分厂别离建设超级表，每个超级表包含4个tag，别离为厂编号、仪表级别、所属工序和仪表编号，具体超级表建表状况如下图所示。

次要用到的集群包含TDengine集群、EMQX集群和Redis集群，其中Redis集群在数据采集方面，仅仅用于缓存仪表连贯状态，其重点在于缓存业务零碎数据；EMQX集群用于撑持MQTT数据的公布与订阅，部署在Kubernetes中，能够实现资源灵便扩大；TDengine集群部署在IaaS虚拟机中，反对大规模时序数据的存储与查问。

表3 集群配置信息

依照TDengine官网的倡议，“一个数据采集点一张表，同一类型数据采集点一张超级表”，我针对不同分厂的水表、电表、蒸汽表和燃气表别离建设的超级表，每个仪表独自建表，保障每张表的工夫戳严格递增。在实际TDengine的过程中，重点领会如下：

1）集群搭建门槛低

TDengine集群装置部署十分便捷，尤其相比于其余集群，仅须要简略的配置就能够实现生产环境级的搭建，官网文档也比拟丰盛，社区沉闷，也大为升高了后续运维老本。

2）插入与查问效率极高

TDengine的插入与查问性能极高，这点在理论运行时也深有感触，用last_row函数查问仪表最新数据，基本上能够达到毫秒级，在几十亿级的数据上进行聚合查问操作，也可达到百毫秒级，极大提供了零碎的响应速度。

3）全栈式时序解决引擎

在未应用TDengine之前，咱们次要采纳InfluxDB/Redis和Kafka/Redis/HBase/Flink两种技术栈，对于咱们中小型研发团队来讲，无论是零碎搭建，还是施行运维都十分辣手。然而应用TDengine后，所有都简化了，TDengine将数据库、音讯队列、缓存、流式计算等性能交融一起，以一种全栈的形式，为咱们的大数据系统带来了便捷。技术计划的对比方表4所示。

注：计划一为InfluxDB/Redis，计划二为Kafka/Redis/HBase/Flink，计划三为TDengine

表4 数据采集计划比照

从表4的比照计划中能够看出，TDengine（计划三）是有着很大的劣势，尤其在开源EMQX Broker的反对上也十分好（次要依赖于Restful接口），其余的例如Kafka和InfluxDB只能和企业版EMQX集成；在数据插入和查问效率方面，上述三种计划关键在于TDengine、HBase和InfluxDB的比照，官网有十分具体的测试报告，TDengine也是有绝对优势，这里就不过多叙述。所以抉择TDengine是势在必行的。

技术冀望

在时序数据库性能方面，TDengine有着很大的劣势，并且也集成了音讯订阅和流计算性能，能够说在中小型物联场景下，是无需部署Kafka和Flink的。当然集体了解TDengine不是为了齐全取代Kafka和Flink而生的，尤其是在大型云服务项目中，更多是共存。

然而在边缘端，TDengine凭借着极低的资源占用率和优良的时序解决性能，将会产生更大的能量，冀望能彻底集成边缘流计算和MQTT broker等性能，裁减Modbus、OPC-UA等常见工业协定反对，向下连贯工业设施或者物联设施，向上和边缘Kubernetes生态（如KubeEdge、K3S等）协同，或者间接和云核心协同。

零碎运行界面

我的项目重点是能耗统计，而在线采集到TDengine里的数据都是累计量，所以在计算能耗时，须要在不同的超级表执行按表分组、按工夫周期采样的查问，相似上面语法：

select last(累计列) as max_val,first(累计列) as min_val from [超级表名] where [标签栏相干过滤] and ts>=now-10h INTERVAL(1h) group by [仪表编号] ;

得益于TDengine的极佳性能，根本能保障不超过百毫秒的拜访延时，上面是一些相干的PC端、挪动端界面（咱们挪动端是用H5做的，为了间接能跑在Android和iOS上）。

写在最初

其实从2019年开始就始终在关注TDengine，也看了很多陶总的演讲，受益匪浅，尤其在往年8月份，TDengine进行了集群版开源，也正好筹备启动能源数据采集我的项目，所以果决采纳TDengine作为外围时序引擎，目前也是播种了十分的成果。本次我的项目施行过程中，尤其感激涛思数据的苏晓慰工程师，屡次帮助解决TDengine相干的施行问题。打算在后续其余我的项目也也会持续推广TDengine，同时也违心为一些商业版性能付费，反对国产，反对涛思。

作者介绍

于淼，学历硕士，副研究员，次要从事MES零碎研发以及智能制作相干实践和规范钻研，次要钻研方向：数字工厂使能技术、制造执行系统关键技术和智能制作规范体系等，参加国家级我的项目及企业我的项目十余项，包含国家重点研发打算以及国家智能制作专项等。