简介《Pandas面试题.pdf》面向准备数据分析岗位面试、希望系统梳理Pandas知识体系的学习者与求职者可用于面试前自测、知识点查漏和日常查阅。资源包共1个PDF文件约263KB按基础、中级、高级及额外探讨展开覆盖Series与DataFrame、CSV读写、条件筛选、缺失值处理、合并拼接、分组聚合、透视表、时间序列、MultiIndex、内存优化和SQL交互等高频考点。每题配有简明解释与代码示例方便对照理解关键API的用法和适用场景也能帮助读者补齐实操细节、建立答题框架。已有1288人学习下载适合初中级数据分析学习者系统复习与查漏补缺。1. 一次 merge 把八万行变成两百万行Pandas 面试题里第 7 题「如何合并两个 DataFrame」的标准答案是一行pd.merge(df1, df2, onkey)看起来毫无技术含量。但我见过更典型的一幕某开发者拿两份订单表做关联跑完发现行数从八万涨到两百万指标全线飘红查了三小时才发现右表的关联键有重复值。这行代码的 API 用法完全正确错在对底层机制没有预期。能把这份分层清单背下来的人很多能讲清「为什么 merge 会放大行数」「为什么给切片赋值会静默失效」「为什么一列整数插了个空值就变成浮点」的人不多。差别不在记忆量而在有没有建立起 DataFrame 在内存里到底是什么形状的心智模型。这份按基础、中级、高级、额外探讨四层递进的清单正好是一条从「会调 API」走到「知道它为什么这么跑」的路。2. DataFrame 不是二维表BlockManager、dtype 与内存账本2.1 一次 dtypes 查询背后块是怎么组织的先给结论DataFrame 在内存里不是一个二维数组而是一组「按 dtype 分堆的块」由 BlockManager 统一调度。同一 dtype 的多列会被塞进同一个 BlockBlock 底层是一个二维 ndarray形状是该块包含的列数, 行数——注意这个顺序是转置的第一个维度才是列。这个细节决定了后面几乎所有关于性能的讨论。为什么要转置存因为 DataFrame 的绝大多数操作是「整列对齐、整列计算」。一列的数据在 ndarray 里连续排布CPU 预取和缓存命中率都高如果按行, 列存取一列要走一个跨行宽的步长每次都在跳着读内存。这是列式思想在单机库里的投影和那些列式存储引擎是同一个直觉只是规模不同。这个设计有个直接后果dtype 越杂块越多块之间的调度开销越大。每插一列字符串、每把一列从 int 转成 float都可能触发一次块的重组。所以「先收集成一个 list 再一次性 concat」比「for 循环里逐列赋值」快得多原因不在于代码风格而在于前者只重组一次。这条经验面试题不会问但真实的数据清洗里天天撞上。提示想直接看内部结构打印df._mgr就能看到一个个 Block 以及它们的 dtype 和形状。这是排查「莫名其妙的慢」的一条捷径但它是内部属性不保证跨版本稳定只适合调试时看。2.2 dtype 是内存账本object 是最贵的那一种基础题第 1 题问「Pandas 的基本数据结构有哪些」标准答案是 Series 和 DataFrame。但真正值得展开的是它们身上的 dtypeint64 和 float64 各占 8 字节int32 和 float32 减半bool 占 1 字节而 object 列存的是一个 PyObject 指针数组每个指针 8 字节指向堆上独立的 Python 对象每个字符串对象自己还有几十字节的头部开销。坑就在memory_usage()的默认参数上。默认deepFalse只统计指针数组一列几十万条字符串看起来才几 MB人畜无害加上deepTrue才会顺着指针追到堆上逐个sizeof数字立刻翻十几倍。很多人优化内存时看着 shallow 的数字觉得没问题一上生产就 OOM问题就在这儿。import pandas as pd import numpy as np n 1_000_000 df pd.DataFrame({ # object 列指针数组 堆上独立的 str 对象 city: np.random.choice([北京, 上海, 广州, 深圳], n), # float64连续内存每行 8 字节 amount: np.random.rand(n) * 1000, }) print(df.memory_usage(deepTrue)) # deepTrue 才追到堆上 before df.memory_usage(deepTrue).sum() df[city] df[city].astype(category) # 整数编码 一份去重字典 after df.memory_usage(deepTrue).sum() print(df[city].cat.categories.tolist()) # [上海, 北京, 广州, 深圳] print(f压缩比: {before / after:.1f}x)这段代码做了三件事用np.random.choice造一列低基数只有 4 个取值的字符串模拟真实业务里的省份、渠道、状态这类列用deepTrue拿到包含堆对象的真实占用再用astype(category)把它换成整数编码加字典的形式。category 的底层是 codesint8 或 int16 的整数数组加 categories去重后的标签数组基数只有 4 时每个值只占 1 字节而原来的 object 列每个值至少是一个 8 字节指针加一个几十字节的字符串对象。压缩比随基数下降而上升基数接近行数时 category 反而更亏这一点要按实际情况判断。2.3 向量化不是「写法好看」是执行路径不同df[a] df[b]的执行路径大致是算子分派到_arith_method做一次索引对齐下沉到块级运算最后交给 NumPy 的 ufunc 在 C 层循环。df.apply(lambda r: ..., axis1)的路径是把每一行构造成一个 Series带索引、带 dtype 推断再调用一次 Python 函数回收对象。前者是 C 循环加连续内存后者是 Python 循环加每行一次对象构造。import time df pd.DataFrame(np.random.rand(200_000, 6), columnslist(abcdef)) t0 time.perf_counter() s1 df[a] df[b] * df[c] # 块级运算C 层循环 t1 time.perf_counter() t2 time.perf_counter() s2 df.apply(lambda r: r[a] r[b] * r[c], axis1) # 每行构造一个 Series t3 time.perf_counter() print(f向量化 {(t1 - t0) * 1000:.1f} ms, apply {(t3 - t2) * 1000:.1f} ms)两段逻辑完全等价差值通常在几十倍量级并且随着列数增加继续扩大——因为axis1的 apply 要把整行所有列都打包进一个 Series哪怕函数里只用到三列。这就是为什么「能向量化就向量化」不是一句口号它换掉的是整条执行路径而不是换一种写法。真正无法向量化的场景调用外部 API、复杂的条件分支、依赖上一行状态才该退回 apply 或者itertuples。2.4 基础题里的深水区iterrows 与 itertuples 的 dtype 差异第 14 题「如何迭代遍历 DataFrame 的行」多数人答iterrows()就结束了。但iterrows会把每一行转换成一个 Series而 Series 只能有一个 dtype——一行里同时有整数和浮点数时整行会被提升成 float64整数 ID 变成1.0拿去做字典键就查不到。itertuples返回的是 namedtuple保留每列原始的 Python 类型速度快一个量级代价是列名里如果有非法标识符会被重命名。第 40 题「如何检查数据类型」也是一样df.dtypes给的是每列声明类型df.infer_objects()则是尝试把 object 列里「看起来像数字」的内容还原成数值类型。两者一个描述现状、一个尝试修正混用就会得出错误结论。这类题的价值不在答案而在于它逼你去想「pandas 到底替我做了哪些隐式转换」。3. 索引对齐为什么一次加法能凭空长出 NaN3.1 对齐是默认语义标签优先于位置两个 Series 相加Pandas 做的第一件事不是逐元素相加而是取两边索引的并集再按标签去取值取不到的位置填 NaN。DataFrame 之间更彻底行索引和列索引双向对齐。这个设计不是附加功能而是默认行为没有开关。为什么这么设计因为数据分析里两张表摞在一起你关心的是「同一个实体」「同一个指标」不是「第几行」。按位置对齐在数据源顺序不一致时会静默产生错位结果错得悄无声息比 NaN 危险得多。NaN 至少还能被isna()抓出来。import pandas as pd a pd.Series([1, 2, 3], index[x, y, z]) b pd.Series([10, 20, 30], index[y, z, w]) print(a b) # x NaN # y 12.0 # z 33.0 # w NaN结果索引是{x, y, z, w}的并集只有 y、z 两边都有值。注意 dtype输入两个都是 int64输出变成了 float64——因为 NumPy 的 int64 没有 NaN 的表示Pandas 只能把整列提升成浮点。这个副作用在面试题第 9 题处理缺失数据里很少被提到但它是后面很多「我的 ID 怎么变成小数了」的根源。3.2 merge 的基数与行数放大merge的本质是按 key 做关系代数连接。how参数决定保留哪一侧inner 取交集left 保留左表全部right 反之outer 取并集。真正容易出事的是基数cardinality如果右表的 key 有重复一对多连接会把左表的每一行复制成多行行数按重复次数放大。上面那个八万变两百万的例子就是右表某个 key 重复了二十几次。validate参数是这里最被低估的一个。它不改变结果只做校验不满足声明的基数关系时直接抛MergeError而不是悄悄给你一个行数翻倍的结果。orders pd.DataFrame({oid: [1, 2, 3], uid: [10, 10, 11]}) users pd.DataFrame({uid: [10, 11], city: [A, B]}) # many_to_one左表多条记录对应右表一条符合预期 ok orders.merge(users, onuid, howleft, validatemany_to_one) print(len(ok), ok.columns.tolist()) # 3 [oid, uid, city] # one_to_one声明两边都必须唯一不满足就直接报错 try: orders.merge(users, onuid, howleft, validateone_to_one) except pd.errors.MergeError as e: print(基数不符:, e)validate的四个取值分别是one_to_one、one_to_many、many_to_one、many_to_many语义是从左表视角描述的。它的价值在于把「静默的数据错误」变成「显式的异常」——线上跑批时一个能被 catch 的异常远比一个看起来正常、数字却错了一倍的报表可爱。代价是每个 merge 多一次索引检查对超大表有一点点开销但和事后排查的成本比不值一提。还有一个常被忽略的参数是suffixes。两边有同名列而没指定后缀时默认给_x/_y这在多层嵌套的 ETL 里会迅速失控列名变成amount_x_x_y。建议显式传suffixes(_order, _user)让列名自带来源信息。3.3 loc 与 iloc闭区间、开区间与布尔掩码的对齐loc是标签索引切片包含右端iloc是位置索引切片不包含右端。这个不对称是历史遗留考卷爱考实际写代码翻车也不少df.loc[0:5]拿到 6 行df.iloc[0:5]拿到 5 行同一个数字含义完全不同。布尔掩码的本质是一次对齐。df[mask]里如果 mask 是 SeriesPandas 会先按索引把它和 df 对齐索引不一致直接抛Unalignable boolean Series provided as indexer如果 mask 是 ndarray就按位置直接用不做对齐。这个区别解释了为什么「明明长度一样却报错」——长度一样不代表索引一样从别处筛出来的 mask 往往带着原来的索引。at和iat是标量访问的快通路一次只取一个格子比loc/iloc少一层容器构造。在逐格写入的循环里df.iat[i, j] v和df.loc[idx, col] v的差距能到几倍但这属于最后一级优化先确认循环本身该不该存在。3.4 MultiIndexlevels 与 codes 到底存了什么多级索引不是「索引对象套索引对象」它的存储结构是 levels 加 codes。levels 是每一层去重后的标签数组codes 是每个位置在对应层 levels 里的整数下标-1 表示缺失。这个结构让重复度高的层级非常省内存一百万行、三个层级各只有十几个取值时存的是一百万个 int8 的 codes而不是一百万个三元组。组成部分存什么作用levels每层去重后的唯一标签相当于字典表codes每个位置在各层 levels 中的下标整数编码-1 表示缺失names每一层的名字展示、xs取值、reset_index还原理解了 codes就能理解为什么 MultiIndex 切片前要先sort_index().loc在 MultiIndex 上的切片走的是二分查找前提是 codes 有序没排序的索引切片可能返回空结果或者被截断而且不报错。这是第 24 题和第 81 题的真正考点跟「怎么创建多级索引」完全是两个层次的问题。4. groupby 的三段式split、apply、combine 各自发生了什么4.1 分组阶段key 怎么变成一组整数编码groupby的第一步不是计算而是把分组键统一成编码。无论你传的是列名、Series、函数还是索引层级内部都会走_get_grouper最终得到一组整数 codes每个 code 对应一个组。这一步的代价取决于sort参数默认sortTrue会做一次排序保证输出按 key 有序sortFalse走哈希分组不保证顺序但更快。这解释了两个常见现象。一是默认groupby的结果是有序的很多人以为是巧合二是大表上groupby(..., sortFalse)能省下可观的时间尤其是在 key 基数很高的时候因为省掉了一次全量排序。代价是输出顺序不可预期如果后面依赖顺序就得自己再排一次。还有dropna参数默认True分组键里的 NaN 整组被丢掉。这个默认值坑过不少人明明有一批空值记录聚合完对不上总数找半天才发现是被 groupby 自己吃掉了。需要保留时显式传dropnaFalse。4.2 agg、transform、apply 的三种契约这三个方法经常被混着用但它们的输出契约完全不同理解契约比记住语法重要。agg是多对一每个组压缩成一个标量或者一组标量输出的行数等于组数索引是分组键。transform是多对多输出必须和输入同形状索引对齐回原表所以能直接赋回新列。apply是任意形状最灵活也最慢返回 DataFrame 时会多出一层索引。df pd.DataFrame({g: [a, a, b, b], v: [1.0, 3.0, 10.0, 14.0]}) # transform输出与输入等长索引对齐回原表可以直接赋列 df[z] (df[v] - df.groupby(g)[v].transform(mean)) \ / df.groupby(g)[v].transform(std) # agg每组压成一个值行数等于组数 print(df.groupby(g)[v].agg([mean, std])) # apply最灵活返回 DataFrame 时多一层分组键索引 print(df.groupby(g).apply(lambda x: x.assign(rankx[v].rank())))transform那行做的是组内标准化mean和std都是按组算的标量但transform会把它们广播回每一行所以df[z]长度和原表一致。这是「组内填充均值」「组内排名」「组内累计和」这类需求的标准解法也是第 22 题和第 50 题背后真正想考的东西。用apply做同样的事会得到一个带两层索引的结果赋值回原表时会因为索引对不上而全变 NaN。这不是 bug是apply的契约它不保证输出形状所以 pandas 没法替你广播。4.3 复合聚合与命名聚合第 60 题问「groupby 后如何做复合运算求和后求平均」这个问题本身有歧义是组内先对多列求和、再对求和结果求平均二次聚合还是对不同列分别做不同聚合。两种理解对应两种写法。sales pd.DataFrame({ region: [n, n, s, s, s], qty: [1, 2, 3, 4, 5], price: [10.0, 20.0, 30.0, 40.0, 50.0], }) # 命名聚合用 (列名, 函数名) 元组声明输出扁平列名 by_region sales.groupby(region).agg( total_qty(qty, sum), avg_price(price, mean), orders(qty, size), # size 计行数含 NaNcount 不含 NaN ) print(by_region) # 二次聚合先得到每组的和再对这个结果求平均 print(by_region[total_qty].mean())命名聚合的元组形式等价于pd.NamedAgg(columnqty, aggfuncsum)好处是输出列名是一层扁平结构不会出现 MultiIndex 列头后续to_csv或者传给下游时不用再droplevel。这是较新版本才提供的能力老代码里常见的写法是先agg再手动改columns两相对比就能看出这个语法糖省掉的是什么。size和count的区别也值得记一笔size数的是行数包含 NaNcount数的是非空值。做「订单数」统计时用size做「有效金额笔数」时用count两个混用会让报表口径悄悄偏掉。4.4 窗口函数rolling 与 groupby 组合时的索引陷阱第 49 题和第 57 题都涉及窗口。rolling(windown)默认按位置取前 n 行传了on时间列之后变成按时间窗expanding是累积窗口ewm是指数加权。单独用都很直观一旦和groupby组合索引就开始作妖。ts pd.DataFrame({ sym: [a, a, a, b, b, b], ts: pd.date_range(2024-01-01, periods6, freqD), px: [1, 2, 3, 10, 11, 12], }) roll ts.groupby(sym).rolling(2, onts)[px].mean() print(roll.index.names) # [sym, ts]多出分组那一层 # 直接赋值会因索引层级不一致而全为 NaN先剥掉分组层再对齐 ts[ma2] roll.reset_index(level0, dropTrue).sort_index()groupby(...).rolling(...)的结果索引是分组键, 原索引构成的 MultiIndex而原表只有一个索引。直接ts[ma2] roll时Pandas 对不上就直接填 NaN不报错。reset_index(level0, dropTrue)把分组键那一层丢掉只留原索引再sort_index()恢复顺序赋值才对得上。这个坑几乎每个做时序特征的人都会踩一次而且第一次踩的时候完全看不出哪里错了。5. 排查与避坑五个静默失败的现场这五个坑的共同点是「不报错」或者「只在特定条件下报错」所以它们能一路活到线上。面试题问「如何添加新列」答df[new] 1就完了但真正区分水平的是知道这行代码在什么情况下不会生效。5.1 链式赋值df[mask][col] 0 为什么没生效现象执行完这行原 DataFrame 纹丝不动控制台多一条SettingWithCopyWarning有时候连警告都没有。原因df[mask]先产生一个中间对象它可能是一块新内存拷贝也可能是原数据的一个视图取决于底层块的 dtype 和操作类型。[col] 0是在这个中间对象上赋值改的是副本还是原表全看运气。这个「看运气」正是最恶劣的地方——同一份代码换个 dtype 就从「能跑」变成「静默失效」。解决用一次loc把选择和赋值合并让它明确落在原表上df.loc[df[a] 1, b] 0。较新的 pandas 引入了写时复制Copy-on-Write机制链式赋值将永远改不到原表警告会变成确定的语义。在那之前凡是看到「先筛再赋」的写法一律改成loc。5.2 dtype 静默提升整数列里的一个 NaN现象一列本来全是整数的 ID插入一条缺失记录后整列变成1.0, 2.0, NaN拿去当字典键查不到merge时类型不匹配。原因NumPy 的 int64 没有 NaN 的表示Pandas 遇到缺失只能把整列提升到 float64 或者 object。这个提升是静默的dtypes不主动看根本发现不了。解决需要保留整数语义又要表达缺失时用可空整数 dtypeInt64注意大写 I它用掩码单独记录缺失位置或者在读入阶段就用dtype{uid: Int64}声明。另外一个高频场景是iterrows一行里混了 int 和 float整行会被提升成 float用itertuples可以避开。5.3 内存峰值read_csv 吃掉的为什么比文件大好几倍现象一个几百 MB 的 CSVread_csv之后进程占用好几个 GB容器直接被 OOM kill。原因CSV 是文本读入过程中要先把字节解码成 Python 字符串对象再转成目标 dtype中间态同时存在原始缓冲、字符串对象和最终数组三份数据。峰值出现在转换完成之前往往是最终体积的两三倍。如果列里全是数字但没声明 dtypePandas 还会先按 object 或 int64 猜一遍。解决分块读每块只保留聚合结果让内存占用和文件大小解耦。acc pd.Series(dtypefloat64) for chunk in pd.read_csv( big.csv, chunksize200_000, # 每块行数按可用内存调 usecols[uid, amount], # 只读需要的列 dtype{uid: int32, amount: float32}): # 显式声明避免猜测 part chunk.groupby(uid)[amount].sum() acc acc.add(part, fill_value0) # 按索引对齐累加 print(acc.sort_values(ascendingFalse).head())chunksize决定单块的内存上限usecols砍掉不需要的列dtype省掉类型推断并顺手把 64 位降到 32 位。三件事合起来峰值内存从「文件大小 × 数倍」变成「单块大小 × 常数」。acc.add(part, fill_value0)而不是直接acc part是因为后者在对齐时缺失位置会产生 NaN累加几轮之后整列都变 NaN 了。5.4 时区tz_localize 和 tz_convert 不是一回事现象对一个已经带时区的 Series 调tz_localize直接抛TypeError对 naive 时间调tz_convert也报错。原因tz_localize是给「没有时区信息」的时间贴上一个时区标签时刻值不变只是解释变了tz_convert是把「已经有时区」的时间换算到另一个时区时刻不变墙上时间变了。两者一个处理 naive、一个处理 aware语义正交。解决按 naive → localize → convert 的顺序走。跨时区做时间序列分析时先统一tz_convert(UTC)存下来展示时再转回本地时区。另外夏令时切换那一小时会出现重复或缺失的墙上时间tz_localize有ambiguous和nonexistent两个参数控制怎么处理不传就抛异常——这是好事总比静默错一小时强。5.5 去重drop_duplicates 保留的是哪一条现象drop_duplicates(subsetid)之后留下的记录不是最新那条业务方反馈数据不对。原因默认keepfirst保留的是「当前行序里第一次出现」的那条而当前行序取决于文件读入顺序或者上游 shuffle 的结果并不保证是时间上最新的。不先排序就去重等于把选择权交给了文件的物理顺序。解决先sort_values(ts)再drop_duplicates(subsetid, keeplast)让「最新」这个语义显式化。sort_values的na_position参数默认last和kind参数稳定排序也值得留意前者决定空值排哪后者决定相等元素是否保序——去重前的那次排序通常应该用稳定排序。6. 取舍什么时候该承认 Pandas 不是答案这份清单从「怎么读 CSV」一路问到「DataFrame 很大装不进内存怎么办」中间隔着的不是语法难度而是一整套关于内存模型的判断力。而最后那道题恰恰是最该认真回答的Pandas 的设计前提是数据能装进单机内存、算子是整块向量化的一旦越过去所有技巧都只是止血。我的判断标准很简单先用df.memory_usage(deepTrue).sum()估出真实占用如果超过可用物理内存的三分之一就别在 Pandas 里硬扛了。三分之一不是拍脑袋是因为读入、转换、中间结果会同时存在峰值通常是稳态的两三倍。越线之后有三条路分块流式适合可累加的聚合代价是丧失全局排序和窗口能力、换列式引擎适合大表单列扫描代价是失去 Pandas 的索引对齐语义和生态、或者干脆改数据布局预聚合、宽表转长表、把计算前推到存储层。这里有个容易被忽略的取舍Pandas 那套「标签优先」的对齐语义弹性很大也很慢。它让你不用关心行序代价是每次运算都要做一次索引比对。当数据量大到索引本身成为开销时改用 ndarray 或者干脆reset_index(dropTrue)之后按位置操作性能会有肉眼可见的改善——但你就得自己保证顺序正确后悔药没了。验证方法也不复杂拿一万行样本跑一遍完整流程把每一步的memory_usage和耗时打出来画一条随数据量增长的曲线。如果内存是线性涨而耗时是超线性涨说明某一步在做 O(n²) 的事常见于循环里concat、append如果内存峰值远高于稳态说明中间态没被及时释放该分块了。从那以后我每次read_csv之前都强制先写一份usecols加dtype的清单跑完再核一遍memory_usage(deepTrue)哪怕只是个几十 MB 的小文件。这个习惯救过我几次——有一次上游悄悄把一列整数改成了带空值的文本如果没核 dtype后面的 merge 会静默产出错位的结果等到报表出来就晚了。这份分层清单的价值也在这儿它先让你把 API 用对再逼你去想每一行背后的内存与对齐想对着自查的话资源本身就在那里从基础题一路做到额外探讨哪一层卡住基本就对应着哪一层的机制还没通。希望帮到你。本文还有配套的精品资源点击获取