一、储能数据仓库概述
1.1 储能行业数据特点
做储能数据仓库，首先得搞清楚我们面对的数据长什么样。我做了这么多年储能项目，总结下来就四个字——多、快、杂、大。
先说“多”。一个储能电站，少说几百个电池簇，每个簇又有几十个电芯。每个电芯都在上报电压、温度、内阻。你算算，光一个站就是几万个测点。我见过最大的项目，单日数据量超过 5TB。
再说“快”。储能系统的采样频率通常是秒级，有些关键参数甚至到毫秒级。BMS（电池管理系统）每秒钟都在往外吐数据。你想想看，这种实时性要求，传统数据库根本扛不住。
“杂”体现在哪里？ 储能数据不只是时序数据。还有设备台账、运维工单、交易电价、气象信息……结构化、半结构化、非结构化数据混在一起。嗯，这里要注意，数据治理的坑往往就埋在这里。
最后是“大”。一个百兆瓦时的储能电站，一年产生的数据量轻松上百 TB。我有个客户，三年没做数据清理，光历史数据就占了 1.2PB。后来做数据仓库迁移，光导出就花了整整两周。
核心总结： 储能数据 = 高频时序 + 多维异构 + 海量存储。这三个特点决定了我们选型和技术方案的方向。
1.2 数据仓库核心概念
数据仓库这个概念，说白了就是把散落在各个系统的数据，统一清洗、整合、存储，然后给分析用。跟业务数据库不一样，它不是为了支撑实时交易，而是为了做决策支持。
我习惯把数据仓库比作一个中央厨房。各个业务系统（比如 BMS、PCS、EMS）就是菜市场买回来的原材料。ODS 层是粗加工，DWD 层是精细切配，DWS 层是半成品拼盘，ADS 层就是端上桌的成品菜。这个比喻你记住，后面讲分层架构时还会用到。
数据仓库有几个关键特性：
- 面向主题：按业务主题组织数据，比如“电池健康度”、“充放电效率”、“故障告警”
- 集成性：把不同来源的数据统一编码、统一单位、统一口径
- 非易失性：数据写入后基本不修改，只做追加
- 随时间变化：保留历史快照，支持时间维度的分析
个人经验： 我在做第一个储能数仓项目时，犯过一个低级错误——没有统一电压单位。BMS 上报的是 mV，PCS 用的是 V，结果报表里电压值差了 1000 倍。从那以后，我要求所有接入数据必须在 ODS 层完成单位归一化。
1.3 OLTP 与 OLAP 对比
这两个概念，很多初学者容易搞混。我直接给你画个对比表，一目了然。
| 对比维度 | OLTP（在线事务处理） | OLAP（在线分析处理） |
|---|---|---|
| 典型场景 | BMS 实时写入电芯数据 | 分析师查询月度充放电效率 |
| 数据特点 | 当前数据，频繁更新 | 历史数据，批量加载 |
| 操作类型 | 增删改查（CRUD） | 聚合查询、多维分析 |
| 响应时间 | 毫秒级 | 秒级到分钟级 |
| 数据模型 | 实体关系模型（ER） | 星型/雪花型模型 |
| 存储设计 | 行式存储 | 列式存储 |
| 典型技术 | MySQL、PostgreSQL | ClickHouse、Doris、Hive |
为什么会这样？因为两者的目标完全不同。OLTP 要的是快写快读，保证数据一致性；OLAP 要的是大查询高性能，能快速做聚合分析。
我曾经遇到一个客户，非要用 MySQL 做储能数据分析。结果一个月的充放电数据，跑个聚合查询要 40 分钟。后来换成 ClickHouse，同样的查询 3 秒出结果。这就是选错工具的代价。
避坑指南： 千万不要在 OLTP 库上直接跑分析查询。我曾经见过有人把生产库查挂了，导致 BMS 无法写入，整个储能站停机了 2 小时。记住：OLTP 负责生产，OLAP 负责分析，两者必须分离。
1.4 数据仓库分层架构
储能数据仓库的分层，我一般分为四层：ODS → DWD → DWS → ADS。下面这张图是我自己画的，你可以直观感受一下数据流转过程。
下面我逐层给你拆解一下。
ODS 层：操作数据存储
这一层是数据进入数仓的第一站。说白了就是原样接入，简单清洗。我一般只做三件事：格式统一（比如时间戳全部转成 UTC）、单位归一化（电压统一用 V，温度统一用 ℃）、去重（去掉重复上报的数据）。
注意，ODS 层的数据跟源系统基本保持一致。它不负责复杂业务逻辑，只做接入和暂存。我习惯保留 7 天的 ODS 数据，方便回溯排查问题。
DWD 层：明细数据层
这是整个数仓的核心层。DWD 层要做的事情很多：数据脱敏（比如去掉运维人员的手机号）、维度退化（把冗余的维度属性直接拉平到事实表）、缓慢变化维处理（比如电池型号升级了，历史数据怎么处理）。
我曾经在 DWD 层踩过一个坑——电池的序列号是 SCD Type 2 变化的，但我没做历史追踪。结果后来查某批次电池的故障率，数据全对不上。从那以后，所有关键维度我都强制做 SCD 处理。
DWS 层：汇总数据层
这一层是性能优化的关键。DWS 层把 DWD 层的明细数据，按业务维度做轻度聚合。比如按天、按电站、按电池簇，预计算好充放电量、平均温度、循环次数等指标。
为什么要做这层？你想想看，如果每次报表都要扫描几十亿条明细数据，再快的引擎也扛不住。DWS 层把数据粒度从秒级提升到小时级或天级，查询速度能提升 100 倍以上。
我的习惯： DWS 层的聚合粒度，我一般按业务场景来定。实时监控看分钟级，运营报表看小时级，战略分析看天级。不要一刀切，要灵活设计。
ADS 层：应用数据层
这一层是面向最终用户的。报表、大屏、API 接口，都从 ADS 层取数据。ADS 层的数据高度定制化，比如某个领导要看“TOP10 故障率最高的电站”，我就专门建一张 ADS 表来支撑。
ADS 层的数据量通常不大，但查询频率很高。我一般用 ClickHouse 的物化视图或者 MySQL 的索引表来承载。注意，ADS 层不要做复杂 JOIN，所有关联关系应该在 DWS 层就处理完。
分层核心原则： 上层依赖下层，数据逐层收敛，复杂度逐层降低。ODS 管接入，DWD 管质量，DWS 管性能，ADS 管交付。各层职责清晰，出了问题也好定位。
好了，第一章的内容就到这里。记住这四个分层，后面讲建模和优化时，我会反复用到这些概念。