1. 项目概述为什么多维聚合不是“加个groupby”就能搞定的事我在银行数据平台组干了八年从最早用SQL写几十行嵌套子查询做客户分层到后来带团队搭实时风险计算引擎踩过的坑比写的代码还多。今天聊的这个主题——“多维聚合中的数据操作”听起来像教科书里的一个章节标题但实际在生产环境里它直接决定着风控模型能不能按时上线、月度经营分析报告能不能准时发出、甚至监管报送数据有没有逻辑性错误。我见过太多人把df.groupby().agg()当成万能胶水结果在测试环境跑通一上生产就报内存溢出也见过分析师花三天调通一个滚动均值却因为没处理好索引对齐导致下游BI图表全错位。这不是技术难度问题而是对pandas聚合机制底层逻辑的理解断层。核心关键词就三个多维聚合、滚动计算、unstack重塑。它们不是孤立技巧而是一套组合拳——就像厨师不会只练刀工或火候真正做一道红烧肉得同时控制腌制时间、煸炒温度、收汁节奏和最后的摆盘角度。金融场景尤其如此你要看某类商户的交易金额波动range就得同步盯住手续费区间min/max要判断客户消费趋势是否异常rolling就必须和其历史累计消费expanding对照着看而管理层想一眼看清“北区零售 vs 南区餐饮”的对比你给个带MultiIndex的Series人家连表头都读不懂。所以这篇文章不讲“怎么写语法”而是拆解为什么必须这样设计参数背后藏着哪些业务陷阱当数据量从10万跳到1000万时哪个环节最先崩适合谁读如果你是刚转行的数据分析师正被日报里的“客户分群指标”搞得焦头烂额如果你是数据工程师在优化ETL pipeline时发现groupby成了性能瓶颈或者你是风控建模师需要把业务规则精准翻译成可复现的聚合逻辑——那这篇就是为你写的。它不假设你懂协方差矩阵但要求你至少写过df.groupby(col).sum()。接下来所有内容都来自我们真实跑在生产环境的代码库没有玩具数据集没有“假设我们有100条数据”只有凌晨三点排查线上报表偏差时我记在笔记本上的那些血泪教训。2. 多维聚合的设计逻辑为什么不能只用一个groupby链式调用2.1 业务需求倒逼结构设计从“单点统计”到“立方体切片”先说个真实案例。去年我们给信用卡中心做欺诈监控模块业务方提的需求是“我要看到每个客户在每个商户类别下过去30天的交易金额中位数、最大单笔、手续费最小值以及这些指标相比全量均值的偏离度。”注意关键词每个客户每个商户类别过去30天多个指标相对比较。如果按传统思路你会怎么做方案A先groupby([customer_id,category])算基础指标再merge全量均值表最后用apply算偏离度——代码写起来爽但数据量超500万行时merge过程吃掉16G内存任务超时。方案B用SQL窗口函数一次算完——可行但我们的实时流处理用的是FlinkPandas UDFSQL方案无法复用。方案C用pandas的agg字典映射配合transform广播——这才是我们最终落地的方案。关键在于理解pandas聚合的执行阶段分离groupby只是逻辑分组agg才是计算引擎。当你写df.groupby([a,b]).agg({x:[mean,std],y:max})时pandas内部做了三件事分组键哈希化把[a,b]组合成唯一hash值存入哈希表这步耗时与分组维度数呈指数关系两个高基数列组合会显著拖慢列级并行计算x列的mean和std是并行计算的但x.mean()和y.max()之间无依赖所以能并发结果结构化生成MultiIndex DataFrame外层是原始列名内层是函数名——这个结构看似麻烦实则是为后续unstack或xs切片预留的接口。提示永远优先用agg字典而非多次groupby。我测过100万行数据单次agg耗时1.2秒三次独立groupby累加耗时4.7秒。差异来自重复的分组键构建开销——每次groupby都要重新哈希分组列。2.2 高基数分组列的隐形杀手当“地区”变成5000个县级市金融数据里最常踩的坑是分组列基数失控。比如“地区”字段业务方给的是“华东/华南”这种大区你开发时用着很顺但上线后运营同事导出明细发现地区字段实际包含“上海市浦东新区张江镇”这种粒度。当分组列唯一值从10跳到5000会发生什么内存暴涨pandas为每个分组分配独立内存块5000个分组比10个分组多占约8倍内存实测数据计算变慢哈希冲突概率上升分组键查找从O(1)退化到O(log n)结果失真若用nunique()统计客户数高基数列会导致groupby自动启用sortFalse结果顺序随机下游排序逻辑崩溃。解决方案不是硬扛而是前置降维# 错误示范直接groupby高基数列 df.groupby(detailed_region)[amount].sum() # 可能OOM # 正确做法业务规则驱动的聚合层级 region_mapping { 上海市: 直辖市, 北京市: 直辖市, 广东省: 华南, 浙江省: 华东 } df[region_level1] df[province].map(region_mapping) # 先映射到业务认可的大区 df.groupby(region_level1)[amount].agg([sum,count])这里的关键洞察是聚合的目的不是技术正确而是业务可解释。风控总监不需要知道“杭州市西湖区”和“杭州市滨江区”的交易差异他需要知道“华东大区”整体风险是否超标。所以设计聚合前先和业务方确认“这个维度你们日常决策时用到的最小粒度是什么”2.3 多列聚合的陷阱为什么输出列名会变成元组以及如何优雅处理看这段代码result df.groupby(category).agg({ amount: [mean,std], fee: sum }) print(result.columns) # 输出MultiIndex([(amount, mean), (amount, std), (fee, )])很多人被这个MultiIndex搞懵尤其当要导出Excel时列名显示为(amount,mean)这种奇怪格式。这不是bug而是pandas为支持混合聚合类型做的精密设计——当你对同一列应用多个函数如[mean,std]它必须用层级结构区分而对单函数如sum第二层为空字符串。处理方案有三重境界初级用result.columns [_.join(col).strip() for col in result.columns]暴力扁平化但会丢失语义amount_mean和fee_sum看不出原始列关系中级用result.stack(0).unstack(1)翻转层级但仅适用于特定场景高级在agg字典中显式命名一劳永逸result df.groupby(category).agg({ amount_mean: (amount, mean), amount_std: (amount, std), fee_total: (fee, sum) }) # 输出列名直接是[amount_mean,amount_std,fee_total]这个技巧来自pandas 1.4它允许你把元组(column, func)作为keyvalue是自定义列名。我们所有生产报表都强制使用此规范原因很简单当三个月后审计人员问“这个amount_std指标怎么算的”你能指着代码说“看它明确对应amount列的std函数”而不是翻文档猜。3. 自定义聚合函数的实战心法从lambda到可审计的业务逻辑封装3.1 Lambda的适用边界为什么它只该出现在临时探索中lambda x: x.max() - x.min()这种写法在Jupyter里调试很爽但一旦进入生产环境就是定时炸弹。原因有三不可调试报错时堆栈信息只显示lambda你得反向推断是哪行lambda出问题不可复用同样计算交易范围风控模块要用运营报表也要用难道每个地方都复制粘贴不可审计监管检查时他们要看“风险指标计算逻辑是否经业务部门确认”你总不能说“这个lambda是我昨天随手写的”。我们团队的红线是所有进入CI/CD流水线的代码禁止出现lambda用于聚合。取而代之的是带完整docstring的命名函数def transaction_range(series): 计算交易金额范围最大值-最小值 业务依据《反洗钱可疑交易识别指引》第3.2条 要求单商户类别内交易金额波动超过200%需触发人工核查 注意空序列返回np.nan避免影响整体统计 if len(series) 0: return np.nan return series.max() - series.min()这个函数的价值远超语法糖——它的docstring里埋了三个关键信息法规出处、业务阈值、异常处理逻辑。当新同事接手时不用问“这个range是干啥的”直接看注释就懂当合规部来查你打开代码就能指给他们看。3.2 加权平均的业务真相为什么“最近交易权重更高”不是数学选择而是风控策略文中示例的weighted_average函数表面是技术实现实则暗藏业务博弈。我们最初版本是def weighted_average(series): weights np.linspace(0.5, 1.5, len(series)) # 线性加权 return np.average(series, weightsweights)上线后风控总监立刻叫停“为什么用线性我们要求近7天交易权重是之前的3倍不是1.5倍”——这才暴露出根本问题权重设计不是算法问题而是业务规则问题。最终落地的版本长这样def risk_weighted_avg(series, recent_days7, weight_ratio3.0, min_weight0.1): 风控加权平均近期交易赋予更高权重反映行为变化敏感性 参数说明 - recent_days: 近期天数窗口默认7天 - weight_ratio: 近期权重倍数默认3倍 - min_weight: 权重下限防止单笔交易权重过低 业务规则根据《信用卡交易行为监测手册》V2.1近7日交易权重设为历史均值的3倍 if len(series) 0: return np.nan # 假设series索引是日期按时间倒序排列 sorted_series series.sort_index(ascendingFalse) weights np.ones(len(sorted_series)) # 最近recent_days天权重设为weight_ratio recent_mask np.arange(len(sorted_series)) recent_days weights[recent_mask] weight_ratio # 归一化权重确保sum1 weights weights / weights.sum() return np.average(sorted_series, weightsweights)重点看参数设计recent_days和weight_ratio都做成可配置参数因为不同业务线规则不同——房贷部要求近30天权重×5而小微贷只要求近3天×2。这种设计让函数从“代码片段”升级为“业务配置项”运维同学改个参数就能适配新规则不用动代码。3.3 复杂条件聚合当“高价值交易”定义每月都在变最后一个例子最能体现业务复杂性。原文中risk_metrics函数用固定阈值300元判断高价值交易但现实中这个阈值是动态的每月根据通胀率调整不同卡种金卡/白金卡阈值不同新客首月有特殊规则首笔超500算高价值。我们最终的生产函数是这样的def dynamic_risk_segmentation(series, base_threshold300, inflation_factor1.02, card_typestandard, is_new_customerFalse, first_transaction_dateNone): 动态风险分层根据多维业务规则识别高价值交易 规则引擎 1. 基础阈值 base_threshold × inflation_factor 2. 卡种系数金卡×1.5白金卡×2.0 3. 新客规则首笔交易且金额500无论阈值 4. 时间衰减距今90天的交易阈值×0.8 返回pd.Series包含各维度指标支持后续pivot_table # 获取当前阈值 threshold base_threshold * inflation_factor if card_type gold: threshold * 1.5 elif card_type platinum: threshold * 2.0 # 新客首笔特殊处理 if is_new_customer and first_transaction_date and len(series) 1: high_value_flag series.iloc[0] 500 else: # 普通情况按阈值判断 high_value_flag series threshold # 时间衰减假设series索引是datetime if hasattr(series.index, date) and first_transaction_date: days_diff (pd.Timestamp.now() - first_transaction_date).days if days_diff 90: threshold * 0.8 return pd.Series({ high_value_count: high_value_flag.sum(), high_value_pct: (high_value_flag.sum() / len(series) * 100) if len(series) 0 else 0, regular_avg: series[~high_value_flag].mean() if high_value_flag.sum() len(series) else np.nan, threshold_used: threshold # 记录本次实际使用的阈值供审计 })这个函数的核心价值在于把业务规则显性化、参数化、可追溯化。当监管来查时我们能导出完整的“阈值计算日志”证明每笔高价值交易的判定都有据可依。这才是金融级数据处理该有的样子——不是炫技而是让每个数字都能说出它的故事。4. 时间窗口计算的生死线滚动与扩展窗口的选型逻辑4.1 滚动窗口的三大致命误区为什么window7不等于“过去7天”滚动窗口rolling是风控和运营最常用的工具但90%的人用错了。最常见的三个误区误区1混淆“窗口大小”和“业务周期”代码里写rolling(window7)业务方以为是“过去7天”但pandas的window7指的是最近7条记录不是7个自然日。如果某客户3月1日有5笔交易3月2日休息3月3日又有5笔那么3月3日的rolling(7)会包含3月1日的5笔3月3日的2笔完全偏离业务意图。正确解法用rolling(7D)指定时间窗口# 错误按行数滚动 df.set_index(date).groupby(customer_id)[amount].rolling(window7).mean() # 正确按时间滚动需确保date是datetime索引 df.set_index(date).groupby(customer_id)[amount].rolling(7D).mean()误区2忽略缺失值处理策略滚动计算遇到NaN时默认保留NaN导致下游分析中断。但业务上“过去7天无交易”和“过去7天交易为0”意义完全不同。我们强制要求所有滚动计算必须声明min_periods# 业务规则至少有3天有效数据才计算均值否则填0 df.groupby(customer_id)[amount].rolling(7D, min_periods3).mean().fillna(0)误区3未对齐索引导致数据错位这是最隐蔽的坑。看这段代码df_ts df.set_index(date) rolling_avg df_ts.groupby(customer_id)[amount].rolling(7D).mean() # rolling_avg是MultiIndex Series索引是(customer_id, date) # 但原df_ts的索引只是date直接赋值会错位 df_ts[rolling_avg] rolling_avg # ❌ 危险正确做法是用reset_index对齐rolling_df rolling_avg.reset_index(namerolling_avg) df_merged pd.merge(df_ts.reset_index(), rolling_df, on[customer_id,date], howleft)注意在Flink等流处理引擎中rolling(7D)会触发状态后端存储务必确认你的集群配置了足够内存否则任务会因OOM失败。4.2 扩展窗口的隐藏价值不只是“累计求和”更是业务生命周期的刻度尺expanding()常被简单理解为“从第一行累加到当前行”但它真正的威力在于刻画业务实体的生命周期演进。比如信用卡客户开卡首月累计交易笔数1累计金额首笔金额第6个月累计交易笔数47累计金额23800第12个月累计交易笔数112累计金额58900。这个“累计”不是数学概念而是客户价值成长的量化指标。我们把它命名为lifecycle_stage并衍生出关键业务动作cumulative_spend 5000→ 新客培育期推送优惠券5000 cumulative_spend 20000→ 成长期推荐分期产品cumulative_spend 20000→ 成熟期启动高端权益营销。实现时要注意两点必须按时间排序expanding默认按索引顺序若date列未排序结果完全错误支持分组内的独立生命周期每个客户的累计值必须隔离计算不能跨客户混算。生产代码模板def calculate_lifecycle_metrics(df): 计算客户生命周期指标 # 确保按时间排序 df_sorted df.sort_values([customer_id,date]) # 每个客户独立计算累计值 df_sorted[cumulative_spend] df_sorted.groupby(customer_id)[amount].expanding().sum().reset_index(level0, dropTrue) df_sorted[cumulative_count] df_sorted.groupby(customer_id)[amount].expanding().count().reset_index(level0, dropTrue) # 计算生命周期阶段业务规则编码 def assign_stage(row): if row[cumulative_spend] 5000: return new elif row[cumulative_spend] 20000: return growth else: return mature df_sorted[lifecycle_stage] df_sorted.apply(assign_stage, axis1) return df_sorted4.3 滚动与扩展的组合杀招用“滚动均值累计标准差”构建动态风控阈值最高阶的用法是组合两者。比如反欺诈系统需要动态调整交易预警阈值基础阈值 过去30天滚动均值 2×滚动标准差但新客户没30天数据就用“累计均值 2×累计标准差”当累计数据满30天自动切换到滚动模式。这个逻辑在pandas里用where和mask就能优雅实现def dynamic_anomaly_threshold(df, min_history_days30): 动态异常检测阈值新客用累计老客用滚动 df_sorted df.sort_values([customer_id,date]) # 计算滚动指标需至少min_history_days天数据 rolling_mean df_sorted.groupby(customer_id)[amount].rolling(f{min_history_days}D).mean() rolling_std df_sorted.groupby(customer_id)[amount].rolling(f{min_history_days}D).std() # 计算累计指标 expanding_mean df_sorted.groupby(customer_id)[amount].expanding().mean() expanding_std df_sorted.groupby(customer_id)[amount].expanding().std() # 合并有滚动数据用滚动否则用累计 threshold_mean rolling_mean.where(rolling_mean.notna(), expanding_mean) threshold_std rolling_std.where(rolling_std.notna(), expanding_std) return threshold_mean 2 * threshold_std这个函数的价值在于用代码实现了业务规则的自动演进。它让风控系统具备了“成长性”不再需要人工干预切换模式。5. 多级分组与unstack的终极形态从数据表到决策仪表盘5.1 unstack的本质不是“转置”而是“降维投影”很多人把unstack()理解为DataFrame转置这是根本性误解。unstack()的实质是将MultiIndex的一个层级从行索引“投影”到列维度从而把高维数据压平成二维表格。看这个例子# 原始分组结果是MultiIndex Series result df.groupby([region,product])[revenue].mean() # Index: [(North,Widget), (North,Gadget), ...] → 2层索引 # unstack(product) 把product层从索引移到列 result_unstacked result.unstack(product) # 列变成[Widget,Gadget]行索引只剩region关键洞察unstack()操作后数据维度并未减少只是可视化形式变了。原来你需要result.loc[(North,Widget)]访问现在变成result_unstacked.loc[North,Widget]本质都是二维寻址。提示unstack()后若某组合不存在如North没有Gadget销售默认填充NaN。生产中必须用fill_value0指定默认值否则BI工具可能把NaN当空值处理导致求和错误。5.2 业务视角的行列哲学为什么“客户作行、产品作列”是黄金法则在银行报表体系里我们有条铁律决策者视线方向决定行列布局。客户经理看报表时眼睛是横向扫的——先看“张三”这一行的所有产品表现再看“李四”那一行。所以必须unstack(product)让产品成为列。但如果是产品总监他关心“Widget”在各地区的销量那就该unstack(region)让地区变列。这个选择不是技术问题而是用户认知习惯问题。我们为此制定了《报表矩阵规范》使用者角色行维度列维度示例客户经理customer_idproduct, category张三的餐饮/零售/旅游消费对比区域总监regionproduct华东区Widget/Gadget销量风控总监risk_score_bintime_period高风险客户在Q1/Q2的交易波动违反此规范的报表会被打回重做。因为再漂亮的图表如果不符合使用者的思维路径就是无效交付。5.3 复杂unstack的避坑指南当需要unstack多层索引时真实业务中常遇到三层分组[region,product,channel]。这时unstack()要谨慎# 错误直接unstack会报错因为默认unstack最内层 result df.groupby([region,product,channel])[revenue].sum() result.unstack() # ❌ 默认unstackchannel但可能想要product # 正确显式指定level result.unstack(product) # 将product层移到列 result.unstack([product,channel]) # 将两层都移到列生成MultiIndex列更常见的是部分unstack比如只想把product展开channel仍保留在行索引。这时用unstack(product, fill_value0)即可。终极技巧用stack()和unstack()组合实现任意维度旋转。比如要把列变回行# 先unstack得到宽表 wide_df result.unstack(product) # 再stack把product列变回行索引但顺序不同 long_df wide_df.stack(product).reset_index(namerevenue)这个技巧在ETL中常用于“宽表→长表→宽表”的数据校验确保转换过程无损。6. 端到端实战银行信用卡风控分析流水线的七层炼金术6.1 数据准备阶段为什么合成数据必须模拟真实分布文中的np.random.seed(42)生成的示例数据看似方便但在生产中是重大隐患。真实信用卡交易有三大特征长尾分布80%交易在20-200元但20%大额交易集中在500-5000元时间聚集性周末交易量是工作日的1.8倍关联性同一客户在餐饮和零售的消费存在强相关买完饭常顺路购物。我们用以下方式生成仿真数据def generate_realistic_transactions(n_samples10000): 生成符合银行业务特征的仿真交易数据 # 客户分层按RFM模型分新客/活跃客/沉睡客 customers np.random.choice( [C001,C002,C003], sizen_samples, p[0.3, 0.5, 0.2] # 活跃客占比最高 ) # 时间分布周末交易概率提升 dates pd.date_range(2024-01-01, periodsn_samples, freqD) weekend_mask (dates.weekday 5) # 周六日 transaction_dates np.random.choice( dates, sizen_samples, pnp.where(weekend_mask, 0.018, 0.01) # 周末概率高1.8倍 ) # 金额分布对数正态分布模拟长尾 amounts np.random.lognormal(mean5.5, sigma0.8, sizen_samples) # 均值约250元 amounts np.clip(amounts, 20, 5000) # 截断极端值 # 商户类别关联餐饮后30%概率发生零售交易 categories np.random.choice([Dining,Retail,Travel,Groceries], sizen_samples) return pd.DataFrame({ date: transaction_dates, customer_id: customers, category: categories, amount: amounts.round(2), fee: (amounts * 0.025).round(2) }) # 生成10万行仿真数据 df_sim generate_realistic_transactions(100000)这个生成器的价值在于让测试环境无限逼近生产环境。当我们发现滚动计算在周末数据上性能下降40%就能提前优化而不是上线后被业务方投诉。6.2 七层分析流水线详解每一层解决一个业务痛点现在把文中的端到端示例升级为生产级流水线。我们称之为“风控七层塔”每层对应一个业务目标Layer 1基础统计解决“发生了什么”# 客户-品类双维度统计用命名列避免歧义 base_stats df_sim.groupby([customer_id,category]).agg({ amount_mean: (amount, mean), amount_median: (amount, median), transaction_count: (amount, count), fee_min: (fee, min), fee_max: (fee, max) }).round(2)Layer 2风险特征解决“为什么异常”# 交易范围标准差识别高波动商户 risk_features df_sim.groupby(category).agg({ amount_range: (amount, transaction_range), # 复用前面定义的函数 amount_std: (amount, std) }).round(2)Layer 3时间趋势解决“是否在恶化”# 滚动7天均值检测短期行为突变 df_sorted df_sim.sort_values([customer_id,date]).set_index(date) trend_data df_sorted.groupby(customer_id)[amount].rolling(7D).mean().reset_index() trend_data.columns [date,customer_id,rolling_7d_avg]Layer 4生命周期解决“处于哪个阶段”# 累计指标刻画客户成长 lifecycle df_sorted.groupby(customer_id).agg({ cumulative_spend: (amount, sum), cumulative_count: (amount, count) })Layer 5交叉分析解决“谁在什么场景下”# 客户vs品类交叉表用unstack生成决策矩阵 crosstab df_sim.groupby([customer_id,category])[amount].mean().unstack(fill_value0) # 添加行/列总计 crosstab[total] crosstab.sum(axis1) crosstab.loc[total] crosstab.sum(axis0)Layer 6高管摘要解决“一句话结论”# 合并多源指标生成可读性强的摘要 summary pd.concat([ base_stats.groupby(customer_id).agg({ amount_mean: mean, transaction_count: sum }), lifecycle, risk_features.mean().to_frame(overall_risk).T # 整体风险水平 ], axis1).round(2)Layer 7风险分层解决“下一步行动”# 应用动态分层规则输出行动建议 def generate_action_plan(row): if row[cumulative_spend] 5000: return Send welcome coupon elif row[rolling_7d_avg] row[amount_mean] * 1.5: return Trigger spending pattern alert else: return No action required summary[action_plan] summary.apply(generate_action_plan, axis1)这个七层结构的价值在于每一层输出都是下一层的输入形成闭环分析链。当某客户被标记“Trigger spending pattern alert”系统能立即回溯到Layer 3的滚动数据定位是哪天开始突增再查Layer 1确认是哪个品类带动的——这才是真正的可解释AI。6.3 性能优化实战当100万行数据卡在groupby时最后分享一个血泪教训。某次我们处理120万行交易数据groupby([customer_id,category]).agg(...)跑了17分钟。排查发现罪魁祸首是category列的dtype是object字符串而pandas对字符串分组比数值型慢5倍。优化三板斧类型优化df[category] df[category].astype(category)内存减少60%速度提升3倍预过滤df df[df[amount] 0]剔除无效数据金融数据中0金额常是冲正无需参与统计分块处理对超大数据集用pd.read_csv(chunksize50000)分批处理再pd.concat()合并。最终优化后耗时降至2.3分钟且内存占用从4.2G降到1.1G。记住pandas性能优化的第一原则永远是“减少不必要的计算”而不是“用更炫的语法”。7. 常见问题与排障手记那些凌晨三点教会我的事7.1 “KeyError: ‘xxx’” 的10种死法及解法这是聚合中最常见的报错表面是列名错误实则有10种根源场景根本原因解决方案实例1列名含空格或特殊字符pandas自动转义但agg字典里没转义df.columns df.columns.str.replace( , _)2分组列有NaN值groupby默认丢弃NaN但agg时引用了被丢弃的列df.groupby(col, dropnaFalse)3字符串列用了数值函数df.groupby(text_col)[num_col].mean()但text_col有非数字值df[num_col] pd.to_numeric(df[num_col], errorscoerce)4MultiIndex列名引用错误agg({(col1,col2): sum})但实际是(col1,col2)用df.columns.tolist()查看真实结构5时间列未转datetimegroupby(date)但date是字符串分组失效df[date] pd.to_datetime(df[date])6中文列名编码问题Python 2遗留问题列名是unicode升级到Python 3.6或df.columns