Power BI / Fabric 的容量事件（Capacity Operation Events）默认只保留很短时间，做容量治理的人几乎都踩过这个坑。FourMoo 的 Gilbert Quevauvilliers 给了一个很实用的思路：把容量运维事件直接落进 Lakehouse，长期留存、随时可查。
为什么要自己存一份
Fabric 自带的容量指标页面适合「看当下」，不适合「查历史」。
- 默认保留窗口有限，出问题后再去找往往已经过期
- 无法和业务数据、刷新记录、用户行为做关联分析
- 容量治理需要趋势，而趋势必须靠长期数据积累
把事件写进 Lakehouse 之后，你就拥有了一个可查询、可建模、可做时间序列分析的容量运维数据集。
整体思路
核心链路并不复杂：
- Fabric 容量会持续产生运维事件（如容量状态变化、节流、扩展等）
- 通过事件流 / API 方式把这些事件捕获出来
- 写入 Lakehouse 的 Delta 表，形成持久化历史
- 在 Power BI 里对这张表建模，做容量健康度看板
关键点在于事件捕获要稳定、写入要幂等，否则历史表会出现重复或断档。
落地时的几个细节
- 表结构设计：建议保留事件时间、事件类型、容量 ID、区域、消息体原文等字段，原文 JSON 别丢，后面解析口径变了还能回溯
- 分区策略：按日期分区，容量事件量级不大但时间跨度长，按天分区查询最舒服
- 去重逻辑：用事件唯一 ID 做 merge，避免重复投递导致数据翻倍
- 刷新节奏：容量事件不需要秒级，分钟级或小时级足够，成本更可控
存下来之后能做什么
一旦历史数据攒起来，很多以前做不了的分析就成立了：
- 容量节流的时间分布规律，判断是偶发还是周期性
- 关联刷新失败记录，定位是不是容量压力导致的
- 容量扩容前后的对比，验证扩容是否真的解决问题
- 给管理层做容量成本与使用效率的趋势报告
这其实就是把「救火式运维」变成「数据驱动运维」的一步。
国内用户怎么看
国内很多团队用 Fabric 还在早期，容量治理往往靠人工盯监控。但一旦业务量上来、并发刷新集中，容量事件的历史留存就会变成刚需。
这个方案的价值不在于技术多复杂，而在于它把一件容易被忽略的基础设施工作提前做了。等到真出问题那天，你会庆幸自己有历史数据可查。
如果你正在做 Fabric 容量治理，建议尽早把事件落湖这件事排进计划，数据这种东西，永远是攒得越早越值钱。
