86亿条/天这个数字第一次写进容量规划表那天团队差点吵架。有人觉得是数学题算错了有人觉得就算真有这么大量无非多买几台服务器。结果都错了——单时序数据库在高写入压力下的瓶颈根本不是加节点就能线性解决的。这个结论是我们给慧知开源重卡充电平台搭数据底盘时用几个月压测和线上事故换来的。这篇文章不写通稿我会把86亿是怎么算出来的、为什么单库会憋死、双时序库怎么分工、中间哪些坑用真金白银踩过全部摊开讲。如果你也在做车联网、充电网络、工业物联网这类高吞吐时序项目这篇可以直接当参考系。1. 86亿条/天的“数据洪水”到底是哪股水1.1 重卡充电平台的数据维度比乘用车复杂在哪乘用车充电平台通常只关心三件事哪把枪在用、充了多少度、谁付了多少钱。哪怕全国几千个站点把订单、告警、交易流水全加起来一天也就是几百万到几千万条事件级记录。重卡充电完全不是一个物种。重卡跑干线物流充电场景大多集中在高速服务区、城市外环物流园、大型货运枢纽。一个场站动辄部署三四十把大功率直流充电枪旁边往往还配套储能柜、光伏棚、变压器监测、枪头温度检测、消防传感这些外围设备。慧知这个平台一上线要接入的就不只是“充电订单”而是现场所有会跳变、会爬升、会抖动的信号。车是移动的桩是固定的场站里的储能系统是第三套体系。三套系统的时间基准不同、采集频率不同、数据特征也不同。车端电池管理系统报文按秒级甚至百毫秒级在跑充电模块每秒钟都有母线电压、模块温度、输出功率百分比的变化场站逆变器、空调、烟感也在持续产生环境信号。这些信号过去很少被充电平台重视但它们恰恰是重卡充电策略优化、设备健康预测、峰谷套利调度最依赖的底层数据。1.2 一条数据从产生到落库中间有几道关卡一条典型时序数据在慧知平台里的路径是这样的感知单元充电模块、电池管理系统、场站网关→ 边缘采集器打本地时间戳 → 前端网关聚合成报文 → 4G/5G或有线链路 → 接入网关集群 → 消息缓存 → 实时清洗补全 → 时序数据库落盘。每一步都要做时间对齐、设备ID补全、业务线标签注入。等数据真正进入时序库时它已经不是最原始的裸报文而是一条干净、带设备维度、带站点维度、带时间戳的高密度记录。举个典型报文例子实际结构会比这个复杂但骨架差不多{ device_id: hc-gun-000123, channel: output_current, value: 376.82, unit: A, ts: 1720000000123, station_id: st-045, charge_session: cs-889912, status: 1 }很多人以为一条这样的JSON才有几十字节不算什么。但问题在于它的量级——单把充电枪如果按2秒周期上报5个通道一天就能产生4.3万条左右。接入十万把枪呢那就是几百万个传感器通道同时产生时间序列数据库要面对的已经不只是“存不存得下”而是“写不写得进、查不查得出”。1.3 86亿不是拍脑袋这个数是这样推算的我把我们按实际接入规模做的测算口径贴出来。这里有一个关键约定我们把“一条时序记录”定义为“单通道单采样值”而不是“一条合并报文”。为什么要用这个口径因为时序数据库在物理存储上就是按序列、按通道展开的事件报文合并得再深落到存储引擎还是要拆成一个个通道值。按这个口径算数字会更贴近存储系统的真实压力。数据源分类接入数量单端日均记录数日数据量充电侧终端枪头/模块/柜内传感15万套约3.5万条52.5亿重卡车辆侧终端BMS数据透传10万台约3万条30亿场站侧能源网关储能/光伏/热管理3万套约9000条2.7亿业务侧订单/运维/告警/结算——约0.8亿合计——≈86亿车辆侧单端日均3万条听着挺夸张但折算下来就是每4秒左右一条车辆状态摘要包含主电压、主电流、电芯温度、整车功率、卫星定位、充电开关状态等字段按照单字段单通道拆开数量就上来了。站点侧包含储能柜的充放电功率、电池簇温度、光伏发电功率等一个综合能源场站每天产生近万条记录非常正常。所以“86亿条/天”不是营销词里的数据洪水而是真实设备联网规模下的客观流量。最要命的是这份流量全年无休每天都在累加。2. 为什么一台时序库扛不住三层瓶颈拆给你看2.1 写入瓶颈均值10万条/秒只是起点峰值从来没客气过把86亿除以86400秒得到的平均写入速度约10万条/秒。但工程上没有人按平均值做容量规划。重卡充电有明显的时间聚集效应——夜间电价低谷期、车队批量到达、换班交接时段都会造成写入突发。我们在实际运营里看到的峰值通常是平均值的5到8倍也就是说架构必须能承受每秒50万到100万条的瞬时写入。单套时序数据库能不能扛住这个峰值如果只是纯写入很多引擎在压测里都能跑出好看的数据。但生产环境不是压测实验室写入的同时还叠加着数据压缩、后台合并、TTL清理、用户查询。这几个任务抢的是同一批CPU、同一批磁盘IO、同一片内存缓存。单库高吞吐下最常见的一幕实时写入把WAL打得很长后台压缩任务跟不上系统的合并积压越来越多随之查询开始变慢慢查询又继续拖累写入。最后整个库像高峰期堵在环路上的车流谁也别想快。我们当时的实测结论是单节点在32核128GB配置下可以守住秒级写入但一旦同时做跨天聚合查询整体吞吐直接回落。2.2 查询瓶颈原始明细和聚合视图放在一个池子里谁也游不好重卡充电平台的查询模式分两类性质完全相反。一类是运维查询最近一分钟某把枪的电流曲线、某个站的实时功率分布、某辆车最近一次充电的电压变化。这类查询要求毫秒级响应命中尽量少的数据。另一类是业务分析查询按站点跑最近30天充电量趋势、按司机维度分析补电行为、按时间段对比峰谷用电结构。这类查询要跨很大的时间窗口扫过的数据量以TB计。这两类查询放同一个库里后果就是互相踩踏。大跨度聚合查询会把内存缓存冲掉缓存命中率一下降实时查询也跟着变慢实时查询占着CPU大查询的执行时间又不断往后拖。单库场景里我们压测时见过聚合查询把P95从2秒直接拉到60秒以上而罪魁祸手往往是另一拨人在同一时间打开了大屏监控页面。2.3 加节点也不是银弹分布式不等于按比例分摊所有问题有人会问拿一个分布式时序库堆几十个节点不也能解决问题吗思路没错但有几个隐藏代价。第一时序数据按时间分区热点数据永远集中在最近的时间窗口新增节点不一定能分摊热分片的负载。第二跨节点聚合查询要在协调节点汇总大量中间结果节点越多通信开销越大查询未必越来越快。第三数据重分布和节点扩容期间系统要处理数据迁移迁移本身就吃带宽和IO。我们当时判断与其让一套库同时承担“高频写入”“临时查询”“深度聚合”“长期保留”四份工作不如做职责拆分。这也是双时序数据库架构的出发点。3. 双时序数据库架构热库与分析库各管一段3.1 架构总览一条数据进来后按生命周期走四段我们最终落地的架构分四层接入层桩端、车端、站端数据统一进边缘代理再汇入消息队列。消息队列在这里最重要的价值是削峰填谷把突发流量先缓冲成可控的消费节奏。热库层第一套时序数据库部署在业务侧直接承接清洗后的原始数据保留最近7到30天的明细。数据搬运层负责把热库里的增量数据读出来做降采样、补维度、算聚合然后写入分析库。分析库层第二套时序数据库不碰原始高频数据只存储聚合结果和降采样数据保留周期按年计专门服务业务分析和运营报表。查询网关业务侧不直接连接任何一个库。统一API背后先走路由逻辑区分实时查询与分析查询分头访问热库或分析库。这个设计的第一原则是每条数据在自己的生命周期里只占一层。热的时候待热库凉下来搬到分析库绝不混装。3.2 热库选型逻辑我们要的是窄而深的写入尖刀热库承担整个系统最脏最累的活选型标准非常明确。我们把权重按这个顺序排能力项权重原因写入吞吐最高峰值每秒几十万条这是最硬的指标数据压缩比高86亿条/天的明细压缩比直接决定磁盘成本TTL与分区清理高热库必须能低成本丢老数据乱序数据容忍度中高车端网络不稳定时间戳乱序是常态多副本容灾中生产环境至少要一主一从复杂SQL/跨表JOIN低热库不做深度分析不需要重SQL能力热库的查询场景其实很窄最近一分钟曲线、最近一小时对比、最近一次充电过程回放、按设备ID取最近N条。这些查询的特征是小范围、时间近、维度单一。所以选型时我们宁可选一个写入与压缩极致优化、查询能力朴素的开源时序引擎也不要一个功能全面但写入毛刺明显的重量级库。3.3 分析库选型逻辑把聚合查询下推到存储层分析库的定位完全不同。它要承接的是天级、月级跨度的聚合计算比如“按站点聚类统计充电量”“按车型对比平均补电时长”“按周维度看场站负载率”。这类查询的特点是大范围扫描、分组聚合、结果集小。我们的选型标准是分析库必须有充分的聚合下推能力能在存储层完成分组、窗口、极值、均值、计数等计算而不是把几百GB原始扫描结果拖到应用层来做。同时它得支持多级存储分层热分区放SSD、冷分区放机械盘或对象存储这样三年期的历史数据才不用一直占用高速存储资源。简单说热库选“写得好”的分析库选“算得好”的。两个库各自独立伸缩高峰期热库顶不住就单独扩热库分析任务重了就单独扩分析库互不干扰。3.4 连接两个库的桥流式降采样加批式回填双库之间不是手工导出导入而是两条自动流水线。第一层是流式降采样。数据写入热库后搬运任务订阅热库的增量时间窗口在外部计算环节做第一遍简化聚合——比如把2秒粒度聚成1分钟粒度同时算出均值、峰值、谷值、计数。聚合结果实时写入分析库端到端延迟控制在10秒级。第二层是批式回填。流式计算天生存在窗口边界问题10秒整点的窗口可能缺最后几毫秒的数据。所以每隔5分钟或每小时我们会对刚落过去的窗口重新做一次完整聚合修正流式结果里的边界误差。这里有一个必须强调的顺序先写分析库再在热库里标记“该窗口可回收”。反过来操作一旦执行到一半进程崩溃就可能出现热库老数据已删、分析库数据缺失的空窗。4. 数据底盘的关键细节压缩、存储成本与一致性4.1 存储成本账86亿条到底要多少硬盘很多团队栽在存储估算上。拿原始JSON报文来估算86亿条乘150到200字节一天就是15到30TB一个月几百TB一看就吓人。但实际上时序数据库落盘时会做很重的编码压缩单条记录的物理占用比大部分人想象的少得多。我们按实际压缩后的预算重算了一版存储层数据形态单条压缩后估算日增量30天增量热库原始明细2~5秒全字段10~15字节100~150GB3~4.5TB热库聚合降采样30秒~1分钟6~8字节10~20GB300~600GB分析库长期数据5分钟以上4~5字节2~5GB60~150GB这个表是按单副本算的加上标签索引和副本因子之后实际占用要再乘1.5到2倍。结论是热库留30天明细大约需要6到8TB在线存储分析库留三年聚合数据大约需要2到4TB。这个成本对生产系统完全可接受前提是你别把原始报文以JSON形态长期堆在在线库里。4.2 降采样策略粒度怎么分每档存多久降采样不是简单地把数据变稀而是要跟着业务价值走。我们最后定下来的分档是这样最近7天保留原始明细2~5秒粒度用于充电过程回溯、故障定位、设备瞬态分析。7到30天只在热库里保留30秒到1分钟的聚合值拆分出均值、峰值、谷值和累计量丢弃瞬态细节。30天到1年进入分析库存储1到5分钟粒度聚合主要用于运营报表和场站效率分析。1年以上可以再做一层月包聚合或者把原始归档到对象存储只在需审计时才回拉。为什么原始明细只留7天而聚合能留三年因为在这套系统里原始明细最大的价值是“出问题时回去看”而问题通常在一周内就会暴露。跨月度、年度的趋势分析基本用不到原始2秒数据聚合之后的精度已经足够。4.3 双库对账机制没有计数校验就别删老数据双库之间如果出现数据不一致后果比单库更严重——因为热库老数据一旦删除想靠原始数据重算就没有机会了。所以我们设计了一套轻量的对账机制原理不复杂搬运任务每处理完一个时间窗口会在同步水位表里记录高层级水位watermark。系统每天定时做一次全量校验对比热库和分析库在同一个窗口内的累计记录数、累计值之和是否一致。校验通过后热库对应窗口的分区才被标记为可回收进入TTL清理队列。这个机制本质上是把“双库同步的正确性”从概率事件变成可审计事件。出现不一致时我们宁可让热库多存几天数据也要先找出原因再删而不是先删后补。4.4 清理策略Drop分区别反复Delete行时序数据的清理有个非常重要的运维细节能按分区删除就绝不按行删除。时序库普遍按时间分片存储直接删除一个废弃时间分区在存储引擎内部只是元数据操作瞬间完成而按条件删除单行会触发重写、索引更新、压缩链生效代价高一个量级。我们在生产环境严格按“日分区站/设备分桶”的规则建表每天的清理任务就是检查哪些分区过了保留期限然后整分区回收。这样TTL清理对写入路径的干扰被压到最小磁盘回收也稳定。5. 回放压测与真实踩坑漂亮话不多说5.1 回放压测结果先把一天的流量完整重演一遍上线之前我们自己搭了一套模拟环境做回放压测把真实业务一天的流量按时间轴重新打一遍同时跑业务查询和报表任务连跑七天。项目热库分析库节点规模8节点32核/128GB4节点32核/128GB存储NVMe盘混合存储分层峰值写入平均43万条/秒聚合写入约3~4万条/秒写入P95延迟8毫秒以内30毫秒以内典型查询P95近一分钟曲线小于200毫秒90天聚合小于20秒这个结果不算惊艳但够真实。我们没盲信任何厂商的压测报告自己的环境和自己的数据跑法才是最可信的验收标准。5.2 第一批坑乱序写入、写热点、磁盘打满乱序写入是第一个撞上的坑。车端网络在弱网环境里会出现数据重传时间戳比接收时间早几分钟甚至几小时都很正常。时序引擎对乱序数据的处理成本远高于顺序写入乱序比例一旦超过某个阈值写入吞吐直接掉一截。我们的解决办法是双时间对齐按设备本地时间戳为主排序按接收时间为辅兜底超过两分钟乱序的记录重定向到专用缓冲表避免拖慢主写入链路。第二个坑是写热点。充电桩天然按站点聚集同一站点几十把枪的数据会形成单站热点。如果不做散列这些热点会全部压向同一批分片。我们把设备ID加盐散列到不同的分桶同时保留站点维度的二级索引热点被打散之后集群负载明显均匀。第三个坑最俗但最致命——磁盘满。搬运任务的临时导出目录和数据盘放在同一块物理盘上某天大聚合任务把临时文件写爆直接顶满磁盘热库写入开始告警。从那以后临时目录一律放独立空间磁盘水位监控提前到85%预警。5.3 第二批坑主数据漂移与跨库查询设备主数据漂移是双库架构特有的坑。某天一批充电桩被重新划分到另一个站点平台修改了它的站点归属。旧数据在热库里的标签却还是旧的导致按新站点统计时历史数据对不上账。我们最终的处理是建立独立的主数据字典站点归属、车型型号、运营商合同这些动态属性全部抽离到关系表时序库里只存设备ID和静态标签查询时实时关联字典。这样设备改属、改名、改合同都不需要回刷历史时序数据。跨库查询则是一个设计取舍。我们最初做过统一查询服务让一个API同时查热库和分析库再做内存合并。结果发现时间跨度大的查询响应不稳定于是改成了调用侧显式声明“我要查实时层”还是“我要查分析层”。损失了一点点便利但换来了行为可预期。5.4 运维护栏容量快速公式和监控看板容量规划我用一条公式快速估算单层容量 日增量条数 × 压缩后单条字节 × 保留天数 × 副本数 × 1.2冗余率拿86亿条热库30天场景代入8.6亿乘10字节乘30天乘单副本乘1.2约3TB再按索引和段落开销放宽一些4TB预算足够。数据量翻倍时直接把条数项改掉就能重新估算。监控看板我们固定盯五个指标写入吞吐、节点磁盘水位、压缩任务积压数、乱序比例、同步水位延迟。前三个保写入稳定后两个保双库一致。任何一个指标长期偏离基线都是架构调整的前置信号。6. 什么时候不该用这套架构以及再翻十倍怎么走6.1 低于一定数据量单库更划算双时序库不是万金油它带来的运维成本是实打实的两套集群、双份监控、同步任务、对账机制每一样都需要有人维护。如果每日增量低于5亿条、峰值写入低于2万条/秒单套时序库配合合理的分区和降采样策略完全可以撑住。如果业务团队少于两人、没有专职的数据库运维角色我更建议先把单库的写入批量调优、查询超时控制做扎实而不是急着拆成两套。架构是服务业务的不是用来发论文的。6.2 如果数据量再翻十倍这套架构怎么演进真到那个规模我们大概率会往三个方向走第一热库扩大分片规模同时把部分计算往前推让边缘网关先做第一层轻量降采样再往中心热库送中心收到的数据压力会明显变小。第二分析库按业务域拆成多个独立集群比如充电运营分析集群、车辆行为分析集群、设备健康分析集群避免不同业务的大查询互相干扰。第三超过三年的明细数据从分析库搬入对象存储用归档文件格式保存。在线时序库只保留可检索的聚合层把“存”和“查”的成本彻底分开。做完这套双时序数据底座我最大的一个体会是数据量大不可怕可怕的是在数据还没大到需要用架构解决时你提前用了复杂的架构而真到了需要解决的时候你又发现方案里缺了水位、对账、清理这些“不性感却保命”的设计。如果让我重新做一遍我会把设备主数据字典和同步水位表的设计排到最前面这些看不见的部分才是整个底盘真正承重的地方。
