完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户

小T导读:在内蒙古某新能源集控项目中,三区需接入并分析大量风电、光伏逆变器及储能设备的监测数据。随着数据规模不断扩大,原有的 Hadoop 系统逐渐难以支撑,查询缓慢、存储低效、数据丢失等问题频频出现。

为突破瓶颈,积成电子果断引入TDengine。经过一年多的验证和实际运行,TDengine 展现出显著优势:查询效率大幅提升,存储空间显著压缩,彻底解决了 Hadoop 的数据丢失难题。目前,TDengine 已全面替代 Hadoop,成为积成电子的核心数据支撑平台。在良好合作基础上,双方已签订战略合作协议,未来将共同为电力行业客户提供更高效、更可靠的数据服务。

项目背景

电力系统分区简介

电力系统根据功能和安全等级划分为一区、二区、三区,主要用于电力监控和数据管理。其中

  1. 一区:直接控制电力生产设备,如发电机组、变电站等,负责实时监控和控制,确保系统安全运行。
  2. 二区:位于一区和三区之间,负责数据采集和预处理,但不直接控制设备,主要进行数据分析和监控。
  3. 三区:用于高级数据分析和决策支持,如负荷预测、故障分析等,不直接参与实时控制,数据经过严格隔离以确保安全。

简单来说,一区直接控制设备,二区处理数据,三区进行高级分析和决策。

设备数量

在内蒙某新能源集控项目中,三区需要接入大量风机、光伏逆变器、储能设备以及其他系统设备的监测数据,并对这些数据进行应用分析。

设备主要包括:

  • 风力发电机约 5000 台
  • 光伏逆变器约 2000 台
  • 各类储能设备,共计超过 100 万台
  • 少量水电、火电系统的监测数据

业务支撑能力要求

由于每台设备都有几个到几百个测点不等,所有设备共计约近 700 万测点,数据采集频率涵盖秒级、分钟级、小时级。这就要求三区的数据平台能够承担巨大的数据写入压力,并且存储众多设备产生的海量历史数据。

对数据的查询应用主要有:

  • 定时统计服务,每个小时统计一次,并将指标上报
  • 设备数据每日统计,每个设备每天( 24 小时)都要进行一次统计
  • 用户随机查询,根据业务需要,用户对设备实时或历史数据进行不定期的查询应用

由于设备数量超过百万,且定时统计需覆盖全部设备,这就要求三区数据平台必须具备强大的并发查询能力,同时确保查询时效性满足业务需求。

技术痛点

我们最初采用 CDH ( Cloudera Distribution including Hadoop)搭建底层数据平台对海量时序数据进行管理,这是一个基于 Hadoop 的集成式大数据平台。随着使用时间越来越长,接入的设备与数据越来越多,它的写入效率遇到瓶颈,出现丢数现象,稳定性也难以保障,而且每次掉线后恢复速度很慢,导致我们的运维难度非常大。

当时我们迫切地需要一个新的大数据平台,它不仅要替代 Hadoop,还要能突破性能瓶颈,保障整个系统的稳定运行。

在了解到 TDengine 后,我们主动邀请其技术专家来访交流。令人欣喜的是,双方迅速达成共识——TDengine 是一款专为物联网、工业互联网等场景设计与优化的大数据平台,正好契合我们在海量设备监测数据存储、管理与应用方面的核心需求。基于此,我们决定在三区率先部署 TDengine 集群,探索新技术的落地实践。

初期,我们采取双系统并行方案,数据同步写入 Hadoop 和 TDengine,以确保系统平稳过渡。经过约半年的测试运行,TDengine 在业务正确性、系统稳定性方面表现出色,不仅彻底解决了长期困扰的丢数问题,在查询性能和存储效率上更是带来了令人惊艳的优化效果。

自 2024 年 10 月起,我们已将全部业务切换至 TDengine 集群,并持续稳定运行至今。

TDengine 建模方案

建表方案

TDengine 的基本数据结构是 “一个采集点一张表”,并采用 “超级表” 来管理相同类型设备的所有子表。最初我们计划仿照官网文档中智能电表的案例,为每类设备创建一个超级表,所有该类设备的数据都由这个超级表下的子表来管理,但是 TDengine 技术专家在调研现场数据采集情况后,给出了另一种方案。

由于我们的设备采集频率从秒级到分钟级、小时级不等,同一设备的不同测点之间差异明显,无法适配统一的采样周期。如果将这些测点强行放入同一张子表,不仅无法整行写入,必须逐列指定,影响写入性能;还会因为大量空值(null)影响压缩效率,造成存储空间浪费,并需依赖后续的 compact 操作进行空间回收。

因此,TDengine 专家建议,采用 “单列模型” 的设计,即为同一数据类型的测点(通道)创建一张超级表,为每个测点(通道)创建一张子表,每张子表只有一个数据列,依赖子表的 tag 列的信息来区分不同的测点(通道)。

下面是单列模型示意图:

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

具体建表时,超级表命名规则为 “s+aaaa+bbbb”,s 意为超级表,“aaaa” 是设备类型,例如风机、逆变器等,“bbbb” 是参数类型,例如有功功率等。

例如,创建超级表 s001f002f ,设备类型为 001f ,参数类型为 002f,示例如下:

CREATE STABLE s001f002f (ts TIMESTAMP ENCODE 'delta-i' COMPRESS 'lz4' LEVEL 'medium', data DOUBLE ENCODE 'delta-d' COMPRESS 'lz4' LEVEL 'medium', quality BIGINT UNSIGNED ENCODE 'simple8b' COMPRESS 'lz4' LEVEL 'medium') TAGS (tab_desc VARCHAR(64), changzhanid INT, dianyadengjiid INT)  

建库方案

根据 TDengine 的最佳实践,建议将更新频率相近的子表归入同一个 database。这样可以确保子表在落盘时生成的数据块大小相近,便于合理配置如 STT_TRIGGERMINROWS 等落盘相关参数,使更多数据聚合写入同一 data 文件,减少文件碎片,提高查询响应效率。

在 TDengine 专家的指导下,我们最终按数据更新频率划分,创建了四个业务数据库:secondiesdb_officialminuteiesdb_officialhouriesdb_officialdayiesdb_official,分别对应秒级、分钟级、小时级和日级采集数据,有效支撑了上层业务的多频率分析需求。

主要建库参数和超级表、子表数统计如下:

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

以上四个业务 database ,共计创建了 6983262 张子表,管理三区所有接入设备的时序数据。

TDengine 应用效果

数据一致性测试

我们对存储在 HBase(构建在 Hadoop 之上的分布式 NoSQL 数据库)和 TDengine 中相同时间段的数据进行了查询,并对查询结果进行了一致性比对。结果显示,两者在各项指标上的查询结果保持一致,验证了 TDengine 在数据存储过程中的正确性和准确性。如下图所示:

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

查询效率提升

在对 TDengine 与原有 Hadoop 系统的查询性能进行对比后发现,TDengine 在查询效率上有显著提升。例如,在对单个设备进行定时统计时,查询耗时由原来的数秒缩短至百毫秒级,整体速度提升约 10 倍,极大提高了系统的响应能力和使用体验。

存储空间减少

TDengine 通过支持二级压缩、每个子表的数据按块存储、数据块内按列存储等机制,对不同类型的数据列采用差异化压缩算法,极大提升了存储效率。实际对比结果显示,使用 TDengine 后,磁盘空间占用仅为原来的约十分之一,大大超出了我们的预期。

掉点(写入数据缺失)问题解决

在采用 TDengine 之前,受限于 HBase 的写入性能以及多列模型的结构设计,我们在高并发写入场景中长期面临数据掉点(写入缺失)的问题,始终难以彻底解决。TDengine 凭借其高并发写入能力,有效承载了大规模数据同时写入的压力,彻底消除了这一问题。从下图对比可以明显看出,在相同时间段内,HBase 的数据曲线存在缺口,而 TDengine 的数据曲线则连续完整,验证了其稳定可靠的写入能力。

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

曲线和图表支持

在历史数据查询业务中,我们主要通过 TDengine 获取所需数据,并以图表形式进行可视化展示,便于用户直观理解设备运行状态与趋势。如下图所示:

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

其它使用问题

时间窗口前开后闭问题

TDengine 提供了时间窗口功能,用户可以通过 interval 子句轻松划分指定时间长度的窗口,并在每个窗口内执行聚合操作。

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

但在使用过程中我们发现,系统默认的窗口区间为前闭后开,即 interval 按时间段取值为 [0,10)[10,20)[20,30)。但在我们的业务场景中,更希望将时间窗口设为前开后闭,即 (0,10](10,20](20,30]

起初我们认为这需要增加额外的配置参数才能实现,后来发现 interval 子句实际上支持窗口偏移设置。通过 offset 参数,我们可以灵活地调整时间窗口的位置。只需配置一个合适的偏移值,就能实现前开后闭的效果。 例如,下面的 SQL 语句通过 offset 1a(表示偏移 1 毫秒),即实现了我们期望的窗口划分方式:

 select _wstart-1a, _wend-1a, count(*) from ftb interval(10s, 1a);

新增节点与 vnode 迁移

由于设备规划调整,原有的 5 节点 TDengine 集群扩容为 6 节点。然而,TDengine 在新增节点后,历史数据并不会自动迁移,新写入的数据也仍然分布在原有的 5 个节点上。这是因为数据库和数据表已提前创建完毕,所有 vnode 的分配仍集中在原集群中,新增节点无法自动分担读写和存储压力。

为充分利用新加入的 dnode 节点,需手动执行 vnode 的迁移操作。TDengine 提供了 vnode redistribute 功能,用于灵活调整 vnode 的分布。例如,编号为 679 的 vgroup,其所在数据库设置了副本数为 3,对应的 3 个 vnode 分别位于 1、4、6 号 dnode 上。若希望将其中 1 号节点上的 vnode 迁移至 7 号节点,只需执行以下命令:

redistribute vgroup 679 dnode 4 dnode 6 dnode 7;

实际上就是将原来的 [1 ,4, 6 ] 分布修改为 [4,6,7] 。

从 ID 为 1 的 dnode 上迁移了 5 个 vnode 到 ID 为 7 的新节点上,语句如下:

redistribute vgroup 679 dnode 4 dnode 6 dnode 7;
redistribute vgroup 684 dnode 4 dnode 6 dnode 7;
redistribute vgroup 686 dnode 4 dnode 6 dnode 7;
redistribute vgroup 689 dnode 4 dnode 6 dnode 7;
redistribute vgroup 690 dnode 2 dnode 3 dnode 7;

整个集群共包含 392 个 vnode。我们在迁移过程中制定了周密的规划方案,并尽量避免迁移 vgroup leader 所在的 vnode(leader 节点负责处理读写请求,迁移会影响性能)。最终从原有的前五个 dnode 中各迁移了 5 至 7 个 vnode,总计 62 个 vnode 被平滑迁移至新加入的节点(dnode ID 为 7),如下图所示:

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

如此一来不仅充分利用了集群中所有节点的资源,同时也达到了我们增加节点的目的。

leader 再平衡

新增节点后,由于多数迁移过来的 vnode 并非 Leader,导致新节点上的 vnode 多为 Follower,无法直接处理读写请求,资源利用率偏低。为了实现各个 dnode 之间的负载均衡,有必要进行 Leader 再平衡操作。

说明:TDengine 通过多副本机制实现高可用,即每个 vnode 有若干个副本,vnode 的全部副本共同构成了一个虚拟节点组(vgroup),vgroup 里 vnode 个数就是数据的副本数。vgroup 采用 RAFT 一致性协议,保证系统的高可用与高可靠,vnode 可以是 Leader、Follower、Candidate 或 Offline 状态。写操作只能在 Leader 上进行,系统采用异步复制的方式将数据同步到 Follower 上,这样确保了一份数据在多个物理节点上有拷贝。

leader 再平衡命令如下:

BALANCE VGROUP LEADER;

由于 RAFT 一致性协议选主过程是随机的,因此有时需要单独对一个 database 或 一个 vgroup 进行专门 balance。

balance vgroup leader; # 再平衡所有 vgroup 的 leader
balance vgroup leader on <vgroup_id>; # 再平衡一个 vgroup 的 leader
balance vgroup leader database <database_name>; # 再平衡一个 database 内所有 vgroup 的 leader

平衡后使用如下语句查看 leader 分布情况:

select dnode_id,count(*) as leader_num  from information_schema.ins_vnodes where status = 'leader' and db_name = 'test'  group by dnode_id;

leader 分布情况如下:

完全替换 Hadoop,彻底解决写入丢数问题 !TDengine 助力积成电子更好服务电力客户 - TDengine Database 时序数据库

经过以上操作,可以看到 6 个节点的 leader 个数大致平衡。

结语

近年来,随着新能源项目的规模化推进和电网智能化进程加快,底层数据处理能力的重要性日益突出。特别是在新能源发电集控平台建设及南方电网边缘集群等场景中,对高效、稳定的时序数据库产品提出了更高要求。

在大唐蒙西新能源集控项目中,TDengine 展现出的卓越产品力给我们留下了深刻印象。基于良好的合作基础,以及对行业趋势和自身发展规划的深入判断,积成电子已与 TDengine 签署战略合作协议。未来,双方将携手深化合作,共同为电力行业客户提供更高效、更优质的服务。

本文作者:积成电子,张涛

关于积成电子:

积成电子股份有限公司是国内领先的智能电网与公用事业自动化整体解决方案供应商,核心业务涵盖电力系统全链条的自动化与信息化,产品覆盖电力系统“发、输、变、配、用、调度”各环节,此外,公司在新能源领域为风电场和光伏电站提供自动化控制方案,并布局智慧水务、智慧燃气等公用事业自动化业务,形成了“电、水、气、热”多领域协同发展的格局。作为国家高新技术企业和行业标准制定者,积成电子主持或参与了 50 余项国家标准及行业标准,拥有千余项技术专利与软件著作权,电网调度自动化系统在国内地调市场占有率高达 30%,技术实力位居行业前列。