存储成本降低80%,Zendure用TDengine支撑117万台设备的能源数据分析

小T导读

Zendure(征拓)是全球领先的即插即用家庭能源管理系统供应商,其太阳能储能设备遍布欧洲、北美等60多个国家和地区,接入设备超过117万台。随着产品线从单一储能扩展到太阳能流控、智能互感器、智能插座等9大品类,数据规模从千万级暴增至数千亿条。面对写入压力剧增、存储成本失控等挑战,Zendure从TDengine开源版升级至企业版集群,实现了存储成本降低约80%、单设备查询毫秒级响应、7×24小时高可用运行,为全球用户提供了可靠的能源数据服务。

业务背景

关于Zendure

Zendure(征拓)是广州疆海科技有限公司(深圳分公司)旗下的全球能源管理品牌,定位为"即插即用家庭能源管理系统的全球先驱"。公司的核心产品是SolarFlow系列智能储能逆变器,覆盖从轻量级阳台光伏(SolarFlow 800)到专业级屋顶储能(SolarFlow 2400 Pro、4000 Mix AC+)的完整场景。配套设备包括可扩展电池模块(AB系列)、智能电表(Smart Meter CT)、智能插座(Smart Plug Pro)和电力枢纽(Power Hub),共同构成完整的家庭能源管理生态。目前Zendure用户遍布欧洲、北美、亚太等主要市场,尤其在欧洲阳台光伏市场处于领先地位。公司拥有7年以上技术积累和150余项全球专利。仅2024年,Zendure用户就通过太阳能累计发电13,172 MWh------相当于让80万辆电动汽车行驶100公里。

业务场景

我们的核心业务围绕家庭能源管理展开,主要覆盖两大场景:

阳台光伏储能(Balcony Power Plant):欧洲大量公寓住户无法安装屋顶光伏系统。我们的方案是在阳台栏杆上挂2~4块光伏板,连上SolarFlow逆变器和电池,插上家中插座即插即用。白天光伏发电存入电池,晚上释放使用,用户通过App实时查看能源流向和节省的电费。

屋顶光伏加装储能(AC-Coupled Storage):对于已有屋顶光伏系统的独栋住宅业主,Mix AC+系列可在不改动原有系统的情况下加装储能,大幅提升光伏自用率。

在这些场景中,每台设备持续产生功率(Power)、电流(Electric)、输入输出电能(InOut)等典型时序数据。我们的App还基于AI算法实现智能充放电调度------根据天气预报预测发电量、根据动态电价(如法国EDF Tempo)在低价时段充电、根据用户用电习惯智能调度。

技术痛点

使用TDengine企业版之后,从开始的仅3张超级表、数千台设备。时隔一年多,业务规模暴增百倍,我们在数据层面遇到了越来越大的压力。

痛点一:写入压力------百万设备并发上报

随着太阳能流控、智能CT、智能插座等多条产品线同时上量,接入设备从数千台攀升到117万台。每一台设备都在高频产生功率、电流、电能等时序数据。以太阳能流控功率表为例,单表累计数据行数已接近千亿级,高峰期每秒写入量达到数十万数据点。原有的单机部署已无法承受如此大的写入压力。

痛点二:存储成本------年存储需求逼近TB级

我们部署在亚马逊AWS上,EBS存储按月计费。117万台设备×高频采集×长期保留(约10年),数据总量达到数千亿条。如果按传统方式存储,总存储需求将达到7~8 TB,年存储成本超过20万美元。对于一家全球化运营的创业公司来说,这是一笔不可忽视的开支。

痛点三:查询性能------用户感知到App变慢

随着数据量增长,用户在App中查看功率曲线的加载时间从最初的几百毫秒变成了好几秒,部分大跨度查询甚至超时。"App变卡了"的用户反馈开始增多。我们必须在数据规模持续增长的同时,保证毫秒级的实时查询响应。

痛点四:高可用------全球化服务不能断

Zendure的用户遍布全球多个时区,系统必须7×24小时不间断运行。我们曾因一次单机故障导致欧洲用户2小时无法查看App数据,收到大量投诉。从那以后,高可用成为我们的硬指标。

选型论证

在开源版遇到瓶颈后,我们成立了技术选型小组,从写入吞吐、查询效率、压缩能力、集群高可用等维度评估了多种方案。

对比维度 MySQL InfluxDB TDengine
写入性能 分表后勉强支撑,运维复杂 开源版不支持集群 原生分布式集群,线性扩展
压缩率 无原生压缩 约3:1~5:1 约6:1~60:1
查询性能 大表查询分钟级 聚合查询秒级 单设备毫秒级,跨设备秒级
集群高可用 需搭建主从+读写分离 集群版闭源收费 原生3副本集群
SQL兼容性 完整SQL 类SQL(非标准) 标准SQL
运维成本 高(分表+索引维护) 低(自动化运维)

InfluxDB在IoT场景下是不错的选择,但其开源版不支持集群部署,集群版为商业闭源产品,且压缩率不及TDengine。MySQL在数据量增长后,分表和索引维护的成本急剧上升。

最终,TDengine在写入性能、压缩率、集群能力和SQL兼容性等方面综合表现最优,且我们已有开源版的使用经验,因此决定升级至TDengine企业版。

架构设计与数据建模

系统架构

我们的系统架构采用分层设计:

数据模型设计

我们采用TDengine"超级表+子表"建模方式,核心设计思路为:超级表按业务品类划分,子表按设备拆分,标签按查询维度设置

共创建16张超级表(11张有数据,5张为新业务预留),按产品线归类:

业务线 超级表 设备数 说明
太阳能流控 power / electric / inout 各~19万台 核心业务,数据量最大
智能互感器 power / inout 各~9万台 精准电流计量
智能插座 power / inout 各~6万台 家庭用电管理
预测功率 predic_power 4万台 AI功率预测
收益分析 hems_profit 7.6万台 投资回报展示
用户能耗 consumer_energy 10.2万台 用户能耗画像
Tesla集成 tesla_inout 1268台 第三方储能对接

以太阳能流控功率表为例,超级表设计如下:

SQL 复制代码
-- 太阳能流控功率超级表
CREATE STABLE st_device_solar_flow_power (
    ts       TIMESTAMP,    -- 采集时间戳
    power    INT,          -- 实时功率值(W)
    type     INT,          -- 功率类型(充电/放电/光伏等)
    hems_id  BIGINT        -- 所属家庭能源管理系统ID
) TAGS (
    device_id  BIGINT      -- 设备唯一标识
);

同一台SolarFlow逆变器在功率表、电流表、输入输出电能表下各有一张子表。TAG字段device_id标识设备,业务层通过hems_id关联到家庭维度。

典型查询场景:

SQL 复制代码
-- 1. 单台设备最新功率(App实时展示)
SELECT last_row(*) FROM st_device_solar_flow_power 
WHERE device_id = 100048;
-- 响应时间:< 10ms

-- 2. 某设备过去24小时功率趋势(App功率曲线)
SELECT _irowts, AVG(power), MAX(power), MIN(power) 
FROM st_device_solar_flow_power
WHERE ts >= NOW() - 1d AND device_id = 100048
INTERVAL(5m);
-- 响应时间:< 100ms

-- 3. 统计所有设备本月每日总发电量(运营分析)
SELECT _irowts, SUM(energy) 
FROM st_device_solar_flow_inout
WHERE ts >= '2026-07-01'
INTERVAL(1d);
-- 响应时间:~2秒(覆盖18万+设备)

-- 4. 按家庭维度聚合平均功率(HEMS分析)
SELECT hems_id, AVG(power) 
FROM st_device_solar_flow_power
WHERE ts >= NOW() - 1d
PARTITION BY hems_id;
-- 响应时间:~3秒

应用成效

核心效果指标

指标类型 优化前(开源版/MySQL) 优化后(TDengine企业版) 提升幅度
写入性能 单机瓶颈,高峰期写入延迟 3节点集群,稳定高吞吐写入 质的飞跃
查询性能 大跨度查询分钟级 单设备<10ms,跨设备~2秒 百倍以上
存储压缩 MySQL无压缩/开源版5-9% 压缩率15%~31% 约1:6~1:60
存储成本 约$200,000+/年(估算) 约$35,000/年 降低约80%
高可用 单机无冗余 3节点+3副本,零故障运行9个月+ 从0到1
数据保留 无法长期保留 约10年(KEEP 3650d) 满足合规需求

数据增长一览

太阳能流控是绝对的数据大户,仅功率数据就有近千亿条记录,占总数据量的60%以上------这反映出全球家庭对太阳能储能系统的强劲需求。

写在最后

通过引入TDengine企业版,我们不仅解决了百万级设备并发写入和千亿级数据存储的难题,更重要的是将存储成本控制在可接受范围内(降低约80%),同时保证了全球用户7×24小时的数据服务可用性。

回顾从开源版到企业版的升级之路,taosX数据迁移工具帮助我们实现了零停机平滑迁移,超级表+子表的数据模型让我们在新增产品线时只需定义新表而不影响已有业务,这些设计极大地降低了我们的开发和运维成本。

未来,随着Zendure在全球市场的持续扩张,我们将探索冷热数据分层存储以进一步优化成本,并深化智能分析能力,让积累的海量历史数据反哺业务。感谢涛思数据团队在迁移和运维过程中提供的技术支持。


作者信息:广州疆海科技有限公司深圳分公司(Zendure 征拓) 运维部门 马伟雄

相关推荐
必须会一定会1 小时前
Spring Boot 3 + PostgreSQL 场景工程持久化:revision、contentHash 与历史回滚
人工智能·spring boot·后端·postgresql·ai编程
shirsl1 小时前
数据开发每日面试题 Day 1
大数据·数据库·sql·big data
崖边看雾1 小时前
Hadoop —— MapReduce完整工作流程
大数据·mapreduce
崖边看雾1 小时前
Hadoop —— HDFS 读流程
大数据·hadoop·hdfs
ms365copilot1 小时前
OneDrive Copilot 从图像获取见解,读懂图表、示意图
人工智能·copilot·onedrive
IT·陈寒1 小时前
Vue的响应式比我想象的更“敏感“
人工智能·大模型·api·创业·变现·简历优化
我有满天星辰1 小时前
【从 0 打造我的本地 AI 知识库】在 M1 Mac 上搭建 Ollama:我的本地 AI 模型到底应该怎么选?
人工智能·macos
Java后端的Ai之路1 小时前
Git pull弹出vim编辑器完整排查指南
开发语言·人工智能·git·编辑器·vim
2601_960356382 小时前
消费者洞察岗项目准备清单:SQL、问卷、用户分层与可视化
大数据·数据库·sql