Pandas固定周期内每列非零统计：四种实现方案与避坑指南

做数据分析的同学，应该都碰过这种需求：一张宽表，行是日期，列是商品编号，要统计每个自然周里，每个商品有几天的销量不等于0。我第一次遇到是在给某电商团队做活跃商品盘点，运营要每个SKU上周的成交天数，当时我第一反应就是 groupby + ne(0).sum()，结果跑出来的数字让运营直接来找我，说所有SKU活跃天数都比后台高了一截。排查半天才发现是缺失值在作怪，NaN和0比较的结果是True，被当成“非零”点算了进去。后来我把这套固定周期内每列非零值统计的做法重新整理了一遍，今天从需求拆解、数据构造、方案选型到边界坑一次讲清楚。适合正被这类需求缠住的同学，也适合想在pandas里把“按周期聚合计数”玩明白的人。

1. 需求拆解：固定周期非零统计要算的是什么

1.1 先给“非零”定一个统一口径

先别急着写代码，把口径定下来。业务上说“非零”，指的通常是“有真实记录且数值不为0”。举个例子：某商品今天销售额为0，说明没成交；销售额是NaN，说明这张表里压根没有录入，可能上游没上报。这两种状态在业务上含义完全不同，但在pandas的布尔比较里会混在一起，因为NaN != 0的结果是True。如果直接用df != 0去计数，缺失值会被当成“非零值”算进去，结果虚高。

我当时就栽在这里。正确的做法是先确定口径：把NaN先填充成0，再判断是否不等于0。这样算出来的含义就是“在填充缺失为空值后，有实际非零数据的活跃天数”。如果你的业务确实要求把缺失单拎出来，那就分别统计isna()和ne(0)，但绝大多数“固定周期内非零值统计”的需求，用fillna(0)会更贴近直觉。

1.2 固定周期有哪些形态

“固定周期”这个词看着简单，实际有一堆变体：自然周、自然月、自然季度，这是日历周期；从某天开始每7天为一周期，这是滚动周期；从每月5号到下个月4号，这是业务账期。pandas里天然支持前一类，用resample或者pd.Grouper(freq='W')就能搞定，后两类需要额外处理。

一个很容易忽略的细节是周期的锚点。resample('W')默认以周日作为一周期末，resample('M')默认以每个月最后一天作为聚合结果的时间戳。如果你的业务是说“周一到周日”还是一个“自然周”，就必须关注freq的写法。比如W-MON可以把周期锚定到周一，MS可以表示月初，这些在下文避坑部分还会细讲。先把“周期”定义清楚，后面代码才不会被一顿质疑。

1.3 输入数据是宽表还是长表

这类需求最常见的输入有两种。一种是宽表：索引是日期，每一列是一个对象（商品、门店、传感器）的数值，这种形态最适合直接做“每列非零计数”。另一种是长表：每一行是一个对象的某一天记录，列里有一个字段表示对象ID，一个字段表示时间，一个字段表示数值。长表当然也能做，要么先pivot成宽表，要么用groupby直接按对象和时间两个维度聚合。

本文主要讲宽表，因为“统计每列”这个动作本身就是宽表视角。等讲到进阶扩展，我会专门说明长表怎么处理，因为实际业务里长表往往比宽表更常见。

2. 构造测试数据：先把问题场景固定下来

2.1 生成带零值和缺失值的宽表

为了不拿真实业务数据做实验，我直接仿造一个宽表：索引是2024年全年的每一天，四列分别代表四个不同SKU的当日销量。为了让数据更贴近真实，我会随机生成一些0值，再随机掺入一些NaN。

import numpy as np import pandas as pd np.random.seed(2024) idx = pd.date_range('2024-01-01', '2024-12-31', freq='D') df = pd.DataFrame(index=idx) for sku in ['SKU_01', 'SKU_02', 'SKU_03', 'SKU_04']: # 基础销售数据，从0~100之间随机生成 data = np.random.randint(0, 100, size=len(idx)).astype(float) # 30%的概率产生真实的零销售 data[np.random.rand(len(idx)) < 0.3] = 0 # 5%的概率产生缺失值 data[np.random.rand(len(idx)) < 0.05] = np.nan df[sku] = data print(df.head()) print(df.isna().sum())

这里我用随机概率造出了零值和缺失值。为什么不用固定规律？因为真实数据的“非零分布”往往是随机的，可能连续几天为零，也可能突然冒出一个异常值。随机生成虽然不能完全模仿业务，但足够用来测试算法对不同分布的稳定程度。NaN在每个SKU里独立出现，这样我们才能验证缺失值是否会让计数失真。

2.2 用 pd.Grouper 定义周期，而不是自己切分日期

很多人统计每周数据时会习惯手动做df[(df.index >= start) & (df.index < end)]这种区间筛选，写起来啰嗦而且容易漏边界。pandas里提供一个更优雅的对象pd.Grouper(freq='W')，它可以直接放在groupby里，按周期对日期索引分组。

# 按自然周分组，查看每个周期包含多少天 weekly_groups = df.groupby(pd.Grouper(freq='W')) for week_start_end, group in list(weekly_groups)[:2]: print(week_start_end, len(group))

这里有个概念需要区分清楚：Grouper只负责把数据按时间区间“切块”，切好之后你可以在块上做任意聚合，不一定非要用resample。resample本质上也是先按时间切块再做聚合，但两者在使用场景上稍微有一点差异：resample更适合直接出现在聚合链上，而Grouper更适合放在groupby里配合其他列一起分组。后文两种我都会用到。

2.3 先跑通一个最朴素的基线版本

在引入各种技巧之前，先用最简单的方式把需求实现出来：对每个周期分组，然后对每一列判断是否不等于0（先fillna(0)），最后求和。这样的结果就是一个新的DataFrame，行是周期标签，列是原来的SKU，值是该周期内每个SKU的非零天数。

base_result = df.fillna(0).ne(0).resample('W').sum() print(base_result.head())

这一行代码其实已经能解决大部分需求了。理由很简单：df.fillna(0).ne(0)会生成一个布尔矩阵，每一格都表示“该值在填充缺失后是否不为0”，布尔值可以被sum()当成0/1处理。再用resample('W').sum()按周求和，就得出了非零计数。这个版本性能未必最优，但作为基线，几乎不会出错。接下来我们在这个基线上做各种优化和变形的讨论。

3. 四套实现方案：从直观到高效

3.1 方案一：for循环 + 分组判断

如果你刚接触pandas，可能第一反应是把每个周期取出来单独算，也就是用pd.Grouper先分组，然后循环每个周期，再对组内DataFrame逐列统计。

result_list = [] for period, group in df.groupby(pd.Grouper(freq='W')): count = group.fillna(0).ne(0).sum() count.name = period result_list.append(count) result_for = pd.concat(result_list, axis=1).T print(result_for.head())

这种写法逻辑直白：拿到一个周期内的子表，统计每列非零个数，最后拼成一个按周期排列的结果。但它的性能挺差，因为每个周期都要复制一份子DataFrame，还会产生很多中间对象。如果只有几十个周期、几百行数据，完全没问题；一旦数据量大到几十万行，这种写法就会变得明显卡顿。作为教学示例可以，生产环境里建议少用。

3.2 方案二：groupby.apply 一行写完

稍微进阶一点的做法是把循环塞进apply里，代码更紧凑：

result_apply = df.groupby(pd.Grouper(freq='W')).apply( lambda g: g.fillna(0).ne(0).sum() ) print(result_apply.head())

这个方式本质上和方案一一样，都是每个周期独立处理，但代码量少了很多。需要注意，groupby.apply在pandas版本更新后，可能有不同的行为（某些版本会对分组名产生额外的索引），建议运行后打印结果确认一下。如果只是做一次探索性分析，这个方案是不错的平衡点：可读性尚可，性能比循环略好一点，但依然不够高效。

3.3 方案三：掩码 + resample.sum（首选）

既然我们的核心诉求是把“非零状态”按周期累加，那不如把状态提前一次性算好，然后用原生聚合函数去求和。这个方法是我现在面对这类需求的第一选择。

mask = df.fillna(0).ne(0).astype(int) result_best = mask.resample('W').sum()

关键在于mask本身就是一张全DataFrame的0/1矩阵，已经不再关心具体数值是100还是50，只保留“是否非零”这个信息。接着resample('W').sum()会在C语言层面快速对每个周期内的0/1矩阵做累加，中间不产生逐条Python遍历，也不反复复制整块数据。当列数很多、周期数很多的时候，这个方案比前两个方案快一个数量级不止。

有人会问：为什么用astype(int)而不是直接用布尔值求和？pandas对布尔值的sum()同样支持，强制转成整型只是为了明确意图，以及让后续可能转到其他数据库或NumPy数组时更统一。实测布尔矩阵resample求和速度与整型基本相同。

3.4 方案四：从长表出发的 groupby + unstack

原始数据如果是长表，例如每行是一条“门店-日期-销量”记录，那就没必要先转成宽表再做上述操作，直接用groupby聚合两个维度更自然。

# 模拟一个长表：每一行是一次销售记录 long_df = df.melt(ignore_index=False, var_name='sku', value_name='sales') long_df = long_df.reset_index().rename(columns={'index': 'date'}) long_df['active'] = long_df['sales'].fillna(0).ne(0).astype(int) result_long = ( long_df.groupby([pd.Grouper(key='date', freq='W'), 'sku']) .agg(active_days=('active', 'sum')) .unstack(fill_value=0) )

这段代码的巧心思在于把active字段当成0/1标记，然后按“周期”和“SKU”两个维度分组求和。unstack会把SKU展开成列，形成和宽表方案一样的最终形状。这种写法最重要的优势是扩展性强：如果想按“城市+SKU”同时分组，只需要在groupby列表里再加入一个字段，不需要额外循环。如果你的原始数据是长表，强烈推荐这个方案，不要强行pivot成宽表再操作。

4. 实测对比：不要让直觉替你选方案

4.1 测试数据规模与相对耗时

我为了选型，专门生成了一个大一些的数据集：1000天、200列，约20万个单元格，其中有15%的0值和3%的NaN。在同一台笔记本上分别跑上面四个方案，看墙钟时间。

这不是严谨的基准测试，但趋势非常明显：方案三比方案一快了近20倍。为什么会差这么多？因为方案一和方案二需要对每个周期构建子DataFrame，还要对每一列分别应用Python级别的函数调用；方案三把判断和转整型一次性做完，剩下的求和全交给底层的C循环处理，根本不会在Python层逐格跑。

4.2 为什么 resample.sum 能这么快

resample本身就是针对时间序列聚合做了高度优化的方法。在得到0/1掩码之后，sum操作实际是在连续内存块上做分组累加，不需要构造中间对象。相比之下，groupby.apply需要对每个分组执行一次Python回调，回调里再用ne(0).sum()逐列计算，每走一步都有Python解释器的开销。数据量越大、列数越多，这个区别越明显。

如果你未来处理的是更大规模的DataFrame（比如百万行、几千列），还可以把mask转换成NumPy数组，用np.add.reduceat按周期分段求和，效果又会快一截。但日常场景里，mask.resample('W').sum()已经足够。

4.3 选型建议：什么情况下该放弃最优

技术选型不能只看性能。如果数据行数只有几百，用循环反而更好，因为代码直白、容易调试；如果你需要交付给其他同事维护，显式的分组循环或者groupby.apply可能比掩码法更容易让别人理解；如果你的数据是长表，后续还要做更多分组口径的调整，方案四会更有弹性。

我的个人习惯是：探索性分析阶段，先用方案二把结果算出来，确认口径无误；正式脚本或报表流水线里，换用方案三；要是发现数据形态是长表且分组维度经常变，就改成方案四。性能优化永远是建立在正确性和可维护性之上的。

5. 避坑指南：这些坑我全踩过

5.1 NaN被悄悄算成非零

这是全文最想强调的坑。df.ne(0)在遇到NaN时会返回True，因为从数学上看“缺失和0不相等”。可业务上缺失并不代表“有销量”，它可能代表当天没上报。如果你漏了fillna(0)，最后统计出的非零天数就会偏高。

# 错误示例：NaN会被当成非零 wrong_result = df.ne(0).resample('W').sum() # 正确示例：先把缺失填充为0，再判断非零 right_result = df.fillna(0).ne(0).resample('W').sum()

我的建议是，如果缺失值比例很高，你可以同时算两个指标：非零天数和缺失天数，把它们并排放在结果里，这样既能反映数据的质量，也能避免口径上被挑战。比如用df.isna().resample('W').sum()快速得到缺失计数。

5.2 周期起点和标签不是你以为的那个周

resample('W')默认的周期边界是从周日到周六，结果标签取周期的最后一天（周日）。很多业务场景里的“自然周”是周一到周日，这时候就要指定freq='W-MON'并且调整label和closed参数。

# 以周一作为周期起点，结果标签也显示为周一 result_monday = ( df.fillna(0) .ne(0) .resample('W-MON', label='left', closed='left') .sum() )

如果搞不清楚label和closed，可以先把聚合后的索引打印出来对比一下。最稳妥的办法是用pd.cut或者自定义周期函数，但这个成本略高。我的经验是：在核心代码里注释清楚“这个freq代表从周几到周几”，否则三个月后你自己回头看也会怀疑人生。

5.3 某些列在整个周期内全是0或NaN，结果到底该是什么

如果某列在某个周期内全部为0，最终求和结果是0，这很合理，代表“该周期内活跃天数为0”。但如果全部为NaN，填充为0后结果也是0，这会掩盖“完全无记录”的事实。遇到这种情况，我建议把“非零天数”和“有记录天数（非NaN天数）”分开统计：

non_zero = df.fillna(0).ne(0).resample('W').sum() non_nan = df.notna().resample('W').sum()

当non_nan也是0时，就说明该周期内这一列连记录都没有，和“有记录但销量为0”是两码事。特别是做报表时，这种区分非常重要，不然总会被业务方追问。

5.4 groupby之后索引变成MultiIndex

使用groupby([pd.Grouper(freq='W'), 'sku'])之后，结果索引是周期和SKU的两层索引。很多人在unstack之前直接去取某一列，发现索引对不上，其实是忘了unstack或处理索引层级。如果不喜欢MultiIndex，可以在groupby(...).agg(...)之后用reset_index()把索引拍平。

另一个小坑是pd.Grouper(freq='W')如果放在groupby里，且你的DataFrame索引不是日期类型，它不会自动把普通列解析成时间索引。要么确保DataFrame索引是DatetimeIndex，要么在Grouper里显式指定key='date'，指定你那列日期字段。这就是为什么在长表方案中我写了pd.Grouper(key='date', freq='W')。

5.5 小心dtype里的object导致效率崩盘

如果某一列是字符串或者object类型，ne(0)也能跑，但性能会明显下降，甚至得到错误结果。在做非零统计前，最好用pd.to_numeric把列转成数值类型，或者使用pd.api.types.is_numeric_dtype检查一下。尤其在从Excel或JSON导入数据时，明明数值列可能被读成了字符串，这地方特别容易翻车。

6. 进阶扩展：滚动周期、自定义分组、与业务日历结合

6.1 滚动30天而非自然周

有时候业务方想要的不是自然周，而是“过去30天每个SKU有几天非零”。这种滚动窗口用resample不好直接表达，但可以用rolling配合掩码。

rolling_result = ( df.fillna(0) .ne(0) .astype(int) .rolling('30D') .sum() )

rolling('30D')按日历天取滚动窗口，对每个日期都会计算“从这个日期往前数30天”的累加和。所以结果是一个和原始数据同样索引的DataFrame，每个值代表截至当天往前30天的非零天数。如果你只需要每周看一次，可以在结果后接一个resample('W').last()，取每周最后一个结点的值。

这里有一个性能提示：rolling在行数很大时速度尚可，但如果你需要“滚动非零计数”且列数很多，尽量避免用rolling.apply(lambda x: np.count_nonzero(x))，因为那会退化成一个纯Python循环。先把数据转成0/1掩码再调.sum()，是最优的。

6.2 自定义业务周期（例如每月5号到次月4号）

固定日历周期好办，业务账期就麻烦一点。比如某公司的销售周期是从每月5号开始到次月4号结束。此时resample没有直接对应的freq。一个通用做法是给每一天生成“周期标签”，然后按标签分组。

def custom_period_label(ts): # 如果日期在当月5号及之后，归入当月周期；否则归入上个月周期 if ts.day >= 5: return f"{ts.year}-{ts.month:02d}" else: # 如果是1月，上月是去年12月 if ts.month == 1: return f"{ts.year-1}-12" else: return f"{ts.year}-{ts.month-1:02d}" df['period_label'] = [custom_period_label(ts) for ts in df.index] result_custom = ( df.fillna(0) .ne(0) .groupby(df['period_label']) .sum() )

这种写法牺牲了一点性能，但换来了极大的灵活度。如果周期规则复杂到用条件分支写起来很长，你可以维护一张“日期-周期”对照表，用merge关联，这在大型企业里很常见。毕竟算法再漂亮，也要接到真实的业务日历上。

6.3 长表同时按多个维度分组

回到前面说的长表数据，如果要统计“每个城市、每个SKU、每个自然月的非零销售天数”，逻辑会和方案四很像，只是groupby里再加一个维度：

long_df['month'] = long_df['date'].dt.to_period('M') result_dim = ( long_df.assign(active=long_df['sales'].fillna(0).ne(0).astype(int)) .groupby(['city', 'sku', 'month'])['active'] .sum() .reset_index() )

这个结果不再是宽表，而是一个平坦的长表：每一行是城市、SKU、月份、非零天数。做透视也好、存数据库也好，都很方便。如果你发现代码里有大量pivot和unstack，不妨停一下想想：基于长表的分组聚合是不是更简单。

6.4 从计数到活跃率：进一步包装业务指标

算完非零天数，通常还要算活跃率：非零天数除以该周期的总天数。这种指标在运营报表里非常常见，比如“SKU当月活跃率=有销量天数/当月天数”。

days_in_period = df.resample('W').size().to_frame('total_days') active_days = df.fillna(0).ne(0).resample('W').sum() active_rate = active_days.div(days_in_period['total_days'], axis=0)

这里resample('W').size()得到每个周期的天数，再按周期索引对齐做除法。要注意的是，如果周期中间有缺失日期（比如系统当天没插数据），size()得到的天数可能小于自然日天数。此时有两种处理：一是先reindex补全日期再算；二是直接接受“有限样本天数”的活跃率，并在报表里注明分母口径。我建议明确写出分母来源，避免业务方拿去和别的系统对比时产生争议。

最后再分享一个个人习惯。每次写完这种统计逻辑，我都会在结果旁边保留一行“总样本天数”和“非空天数”，这不是为了增加信息量，而是为了能够在数据异常时快速定位问题。比如某个SKU本周非零天数突然变成0，你先看是整列都为空，还是周期切分偏移了。这种数据质量验证习惯，比任何算法技巧都能让你少背几口锅。

从第一次被NaN坑到现在，这套固定周期内每列非零统计的方法已经变成我的标准动作。遇到相似的“逐列按时间聚合”需求，先确认口径，再构造掩码，最后选一个趁手的聚合方式，整个过程能控制在十分钟以内。希望这篇文章能让你少踩我踩过的坑。