如果你管着一个千万行级别的Power BI模型，"半年后这玩意会撑爆吗"这个问题值多少钱？答案是：可能够买一辆Model 3的Premium容量费用，或者一次凌晨三点的故障抢修。
一位做过Qlik引擎逆向的老兵最近对VertiPaq动了手。他的目标很简单——不是估算，是公式。输入今天的元数据，输出六个月后的字节级体积预测。Qlik那边他搞过AppSizePredictor，这次他想复制到Power BI。
结论先放这儿：基本能成，但有个诚实的坑。
VertiPaq的存储账本：每列就记三笔账
拆解结果比想象中干净。每一列的存储体积 = 数据本体 + 字典 + 层级结构。没有暗箱，没有魔法，就是这三项相加。
数据区存的是编码后的值，字典存的是唯一值映射表，层级结构（Hierarchy Size）服务于钻取和聚合路径。这三块的计算逻辑各自独立，意味着你可以分别建模、分别预测。
这位工程师的做法很产品经理：跑对照实验、比对生产环境的快照版本、逐字节验证公式。不是看文档猜，是让数据自己说话。
可预测的部分：字典和层级是老实人
字典体积跟唯一值数量基本线性挂钩。你加一行新数据，如果值已经存在于字典，字典不增重。这个特性让字典成为最容易预测的部分——看业务字段的基数增长曲线就行。
层级结构更乖。它的体积取决于列的数据类型和唯一值分布，公式稳定到可以写进Excel。对于日期列这种结构固定的字段，预测误差能压到5%以内。
真正麻烦的是数据区。
那个"诚实的坑"：数据区的压缩率会叛变
VertiPaq的列式压缩不是固定比率，它跟值的分布模式强相关。同一列，今天可能是10:1，下个月业务数据一变，可能变成6:1。这不是bug，是设计特性——引擎会动态选择编码方案。
这意味着你的预测公式必须留一个压缩率变量。不能假设历史压缩率代表未来，得给业务方一个区间：最好情况、最坏情况、以及最可能情况。产品经理管这叫"管理预期"，工程师管这叫"承认不确定性"。
这位老兵的原话是：「我想要的不是水晶球，是带误差范围的望远镜。」
这对你手里的容量规划意味着什么
如果你现在用"行数×平均字节"来估算模型增长，建议停下来。VertiPaq的存储逻辑跟行数不是线性关系，跟列的基数、分布、数据类型才是。
一个 practical 的折中方案：先按三公式拆分测算字典和层级，数据区则取过去三个压缩率的移动平均，再给一个±30%的浮动带。够不上数学级精确，但比拍脑袋准一个数量级。
那位工程师把验证过程发在了社区。最有趣的反馈来自一个评论区用户：「按这个公式回测了我们过去两年的增长，误差在12%以内。但去年Q4那次业务改版，压缩率直接崩了，模型差点撑爆P1容量。」
你的模型最近一次压缩率波动，发生在什么时候？
热门跟贴