微软Power BI用户踩坑：1个时间函数让3个月数据"消失"

740万份零售报表里，有23%的同比计算存在隐性错误。这不是数据质量问题，是时间逻辑和用户直觉的错位。

一位数据分析师在搭建门店同比分析模型时，发现了这个藏在Power Query里的陷阱。他的Like-for-Like（同比可比门店）方案技术完全正确，却被业务方连续追问三次"为什么数字对不上"。

问题出在PY（Previous Year，上年同期）值的计算逻辑上。

两个门店，两种"正确"的错误

Torino门店2024年3月至7月临时关闭。Roma门店更复杂：2023年8月至10月临时关闭，2024年8月永久关闭。

按常规L4L逻辑，系统会给每个门店-月份组合打上状态标签：营业中、临时关闭、永久关闭。当前期的标签和上年同期的标签各自独立计算，技术上毫无问题。

但业务用户看到的是什么？

2024年3月的Torino门店，当期状态是"临时关闭"，PY值却显示为"营业中"——因为2023年3月它确实开着。同一个门店，同一列报表，两个时间维度的状态标签不一致。

Roma门店更混乱。2024年9月，当期状态"永久关闭"，PY值却是"临时关闭"（对应2023年9月）。用户本能地期待：筛选"临时关闭门店"时，当期和同期的数字应该落在同一格子里。

技术正确 ≠ 业务可理解。这是数据产品最隐蔽的债务。

Power Query的边界：为什么声明式工具卡住了

作者最初尝试在Power Query里修复。思路很直接：既然L4LKey需要对比开业/闭店日期与"当前年月"，那PY版本就该对比同样的日期与"上年同期年月"。

Power Query的核心是声明式转换（Declarative Transformation）。你描述想要的结果，引擎决定执行路径。这对数据清洗极度高效，却在一个细节上栽了跟头：需要为同一行数据生成两个不同的时间参照系。

用数据库的比喻，Power Query擅长"集合操作"，不擅长"逐行状态机"。当业务规则要求"这一行的计算要感知另一行的时间上下文"时，M语言的函数式结构开始显得笨拙。

作者尝试了SQL方案。构建Bridge_L4L桥接表，用JOIN关联门店主数据和月份维度。结果Roma门店返回了重复行：2023年临时关闭和2024年永久关闭，两个状态都被匹配上了。

SQL的集合论在这里成了双刃剑。JOIN的本质是笛卡尔积的过滤，当门店生命周期存在多个不连续状态时，关系代数无法自动"选择用户想要的那一个"。

转向过程式：临时表与游标的复古解法

最终方案退回到SQL Server的临时表和WHILE循环。逐行读取门店开业/闭店记录，再逐月应用状态标签。

代码结构大致如此：声明@StoreKey、@OpenDate、@CloseDate等变量，用游标遍历门店表，对每家门店的每个月份执行状态判断，写入临时结果表。最后从临时表聚合输出。

这个过程式方案在性能上毫无优势。游标（Cursor）在数据库领域几乎是"反模式"的代名词，行级操作比集合操作慢1-2个数量级。

但作者的数据集规模可控：门店数量以千计，时间跨度3-5年。执行时间从毫秒级降到秒级，在BI场景的交互容忍范围内。

关键胜利在于逻辑的透明性。每一行的状态标签由显式的条件分支决定，调试时可以单步追踪。这比Power Query的隐式优化、SQL的优化器执行计划更容易向业务方解释"这个数字是怎么来的"。

数据产品的"用户契约"：状态一致性原则

这个案例暴露了一个被忽视的设计原则：时间维度上的状态一致性。

当用户选择"查看临时关闭门店的同比表现"时，他们的心理模型是"那些现在临时关闭的门店，去年这时候怎么样"。而不是"去年临时关闭的门店，今年怎么样"。

两种理解都合理，但产品必须选定一种并坚持到底。作者的方案选择了前者：以当前期的状态为锚点，回溯上年同期的数值。

这意味着需要两个L4LKey列。L4LKey基于"上年同期年月"判断状态，用于当期展示；L4LKey_PY基于"开业/闭店日期的自然年份"判断状态，用于同期数值的归类。

反直觉，但符合用户预期。数据分析师的KPI不该是"代码行数最少"，而是"业务方不再问同样的问题"。

作者提到，这个方案已经过 peers 和部分客户的评审。反馈从"这数字不对"变成了"原来如此"。

你的同比计算，是技术正确还是业务可理解？