从Hadoop到TDengine,我们走过的路和展望

原创
2022/02/11 11:45
阅读数 3.5K

作者:黄斯郡


小 T 导读大家好,我是一名来自广州某企业的架构师,主攻大数据和云原生方向。今天在这篇文章里,我想结合近些年的工作经验,讲讲为何以及如何在物联网大数据项目中落地TDengine ,希望能给大家一些启示和有意义的参考。


一次调侃



在认识TDengine之前,我一直都在做工业互联网项目,其中的一些工作,包含数据从应用层到大数据库的汇总、分析计算,以及反馈应用层需要的业务报表数据。


例如计算平均每分钟的功率曲线、统计每分钟的用电量、对比不同设备乃至厂区的耗能情况,这里面既有实时流计算也有批处理。


如果把大数据系统作为一个中台型服务,它对应用层暴露的仅仅是HTTP形式的查询接口,背后需要涵盖很多技术组件,例如将Hadoop的HDFS/Hive做原始数据保留、使用Hbase保存计算后的数据、利用消息中间件Kafka同步各类数据,计算框架是使用Flink还是Spark、分布式协调上选择Zookeeper。


因此,整个框架技术组件看起来非常的"重",一方面体现在你需要对Hadoop的技术组件非常熟悉:例如数据均衡备份冗余策略、Hive分区策略、Hbase的key设计规则;另一方面则体现在业务规则的不好把控和适应:以每分钟的功率计算为例,开始是取该分钟间隔内的最后一个数值,后来改成取该分钟内的平均数值,凡此种种需要大数据系统从ods层面重新进行计算,会带来非常大的开发工作量。


项目经理经常调侃,"就是展示几条曲线,几个数据而已,为什么要那么复杂?"



一篇文章



在调侃之余,我们开发人员也在思考,其实工业互联网以设备为主线,统计的都是一段时间内单个设备的数据,难道就没有一个能够很好地强调物联网时序场景的大数据软件吗?


一次偶然机会,我在朋友圈看到了这篇文章——《比Hadoop快至少10倍的物联网大数据平台,我把它开源了》,再结合搜索引擎的这几个关键字——"秒杀Hadoop""分布式集群""开源",马上就吸引了我的注意,点进去一看,真的大有相见恨晚的感觉。


因为TDengine的优势完全可以解决我们的痛点——以设备数据模型创建超级表,以设备为单个子表,按时间先后顺序连续存储数据。在查询的时候,可以提供预计算的统计数据,可以基于设备单个子表的tag做聚合的功能,结合流计算中的滑动窗口、滚动窗口概念,还可以快速地基于原始数据得到聚合统计结果。


此外,TDengine还支持分布式集群部署,避免单点故障,提升存储计算能力。更重要的是,这个集群功能也是开源的!开源核心功能意味着不用担心以后给人卡脖子,也意味着会有一个优秀的开源社区伴你同行。



启航扬帆



心动不如行动,接下来我们团队立马着手在新的物联网项目上,按照"安装->应用集成(读写)->应用部署"的三部曲,正式使用上了TDengine。

它的安装包十分小巧,只有10M左右,借助于官方文档,Linux系统下的集群部署也很简单。接下来,配置好主机名、域名解析、暴露的端口、运行程序,过程非常顺滑,立马就能使用了。对比之前的Hadoop技术栈,这对运维团队来说简直就是福音!

在和应用集成方面,TDengine支持JDBC-JNI和HTTP RESTful两种方式读写数据,我们采取JDBC-JNI结合Mybatis的方式,本地开发的时候,需要安装对应版本的TDengine-client。另外,设计好超级表后,子表在首次写入的时候同时创建。

对应于我们三节点(24核,62G)的集群,程序轻轻松松就达到qps每秒1万记录的写入性能。至于查询性能,以当天的功率曲线为例,按照1分钟1个记录,总共1440个计算数据计算,可以轻松地在1秒钟内通过1句SQL聚合当天1万条记录而得到;还有每月的日温度曲线,总共30个计算数据,当月的30万条记录,也可以通过avg函数结合Interval在秒级查询的时间间隔内返回!

最后是应用部署,因为我们的程序采用容器化的方式运行和管理,所以需要简单基于Linux镜像安装对应版本的TDengine-client生成基础镜像,再提供给应用程序使用。期间,我们遇到问题都是在GitHub(https://github.com/taosdata/TDengine)上提交issue,很快就有TDengine的官方伙伴回复,在社区群也有技术支持人员以及其他热心开发者帮忙解答。


两篇文章



项目运行一段时间后,我们团队在客户端连接高可用方面也尝试着进行了思考和改进。实际场景下,我们会依据数据需求动态增加节点,但是不希望应用程序也跟着改动连接地址,所以我们希望应用程序的连接域名不变。那么,怎么实现呢?


比如,连接域名'td-prod-service:6030',通过负载均衡服务进行udp转发(TDengine的连接是走udp协议),随机分发连接请求到实际的三节点之一(prod-td-1:6030, prod-td-2:6030, prod-td-3:6030),之后,应用程序根据接收到的节点信息,和实际的节点发生连接。为了解决这个问题,我们曾和TDengine社区的官方小伙伴们进行很多互动交流,后来他们把这个做成了经典案例文章——《「GitHub问题精选」TDengine 如何做到客户端高可用?


再接着,我们又接到了应用适应客户时区进行统计的需求,这个需求的背景是因为我们的设备遍布全球,每个客户审阅自己设备的统计数据时,当然期望是以客户自己所在时区为维度进行统计。很幸运,TDegnine不仅提供了时间窗口函数interval,还支持偏移 offset(偏移必须小于间隔)。


首先,我们配置taos的系统时区为"timezone UTC-12"(即地球最早的时区)。然后,当中国时区客户(Asia/Shanghai (CST, +0800))查询以天为间隔时,我们会偏移4个小时,例如, interval(1d, 4h);当美国时区客户(America/Los_Angeles(PST, -0800)查询以天为间隔时,我们会偏移20个小时,例如, interval(1d, 20h);


后来,TDengine的社区技术支持人员也基于此做成了经典案例文章——《一文帮你掌握TDengine的降采样查询+跨时区统计》,当时我还没留意,是我的同事和我说“你看这个文章里的示范表叫daluo(我的微信ID名字)”我才发现。当时,我的心情是十分惊喜的。


这两篇文章在解决我们问题的同时,进一步完善了TDengine自身与用户交互的技术资料,我们真正做到了在开源社区中合作共赢。



几点希望



未来,我们希望TDengine可以继续保持开源的态势,及时友好地解答用户的疑问,为社区繁荣以及中国的开源软件建设充当开路者。


同时,我们也希望TDengine的软件部署可以向容器化的方式靠拢。毕竟在当下云原生的时代,容器化已经是团队提升效率必不可少的利器。想象一下未来的场景,基于云计算的强大共享存储计算能力,以及可靠稳定的容器化编排环境Kubernetes,开发者只需要简单的运行k8s operator就能运行TDengine,然后实现版本的升级以及计算资源的随意调度,将给运维带来极大的便利。


此外,结合传统的数据仓库星形模型,我们也希望TDengine可以实现多表的联合查询统计。因为在设备的背后是业务,设备总是会关联具体的车间、客户、厂区,而我们可能无法把所有的业务属性一次性预先作为tag写入到子表中(虽然我们现在是这样做的),当有新的业务属性需要关联的时候,我们又需要去增加超级表的tag,然后更新到对应的设备子表数据。而实际上,tag和设备数据更像是索引关系。所以,如果子表作为事实表可以随意和维度表进行关联统计查询,这又是一个多么美妙的场景!


最后,我们希望结合机器学习等框架,TDengine可以衍生出自己的 "MapReduce" 作业框架,支持开发者在上面进行人工智能作业分析。


总结一下,就是希望TDengine可以在物联网大数据平台方向提供全栈的技术方案,为企业的提效降本提供扎实便利的技术基础,成为整个行业的事实标准。



👇 点击 阅读原文 ,了解体验TDengine!

本文分享自微信公众号 - TDengine(taosdata_news)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
1 收藏
1
分享
返回顶部
顶部