简介：这份数据分析笔试题资源包面向准备数据分析岗位笔试的求职者与在校学生，也适合希望系统梳理数据分析知识体系的入门者。内容围绕数据获取、清洗、探索、建模与业务解读的完整流程展开，覆盖缺失值与异常值处理、概率分布与假设检验、常用图表应用、线性回归与决策树等算法原理，以及关联规则、聚类、分类预测和大数据框架等考点，并配有SQL查询、BI练习与多套岗前测试题。资源包共41个文件，以png图表、xlsx与xls数据表、docx试题文档为主，另含pptx分析报告、gif与mp4演示素材及少量工具文件，压缩包约54.78MB，目录按试题、图表与报告分类，便于按模块检索。目前已有818人学习下载。读者可借助其中的真题与图表素材，熟悉笔试常见题型与解题思路，对照练习数据清洗、统计推断与建模类题目，并参考分析报告结构提升业务解读与表达能力。
1. 数据分析笔试题：为什么有人 40 分钟交卷，有人卡在第一道 SQL
数据分析笔试题这个关键词，每年招聘季都会被搜爆。但真正拉开差距的，不是你会不会写 SQL，而是你能不能在 40 分钟内判断出「这道题到底在考什么」。我见过太多候选人，第一道题就打开窗口函数硬写，结果后面三道业务分析题连读题时间都不够。也见过有人用 Excel 思维手算完五道题，正确率还比写 Python 的高。
这篇笔记不讲「数据分析师要会什么」这种泛泛的东西。我按自己带过的新人和参与过的出题经验，把数据分析笔试题拆成三类：SQL 取数题、业务指标题、开放分析题。每一类告诉你出题人在埋什么坑、你该用什么节奏做、哪些参数和写法是高频得分点。适合正在准备跳槽的初中级分析师，也适合想转行但不知道笔试到底考什么的人。
2. 先看懂笔试的三类题型：SQL、指标、开放分析
2.1 SQL 取数题：考的不是语法，是口径
SQL 题在数据分析笔试题里占比通常最高，但它的得分点往往不在JOIN写没写对，而在你有没有先确认口径。比如「计算每个城市的订单量」，出题人可能默认你要过滤掉已取消订单，但题干里不一定明说。我一般会先花 30 秒扫一遍表结构注释，看有没有status、is_deleted、dt这类字段。
常见做法是先把题干里的名词翻译成字段条件。比如「有效订单」对应status = 'paid'，「近 30 天」对应dt >= date_sub(current_date, 30)。这一步做完再动手写，比直接写SELECT city, count(*)稳得多。
下面是一个典型的 SQL 笔试题骨架，我把它拆成可复用的模板：
-- 题目：统计每个城市近 30 天有效订单的 GMV 和订单量 -- 假设表：orders(order_id, city, amount, status, dt) SELECT city, COUNT(DISTINCT order_id) AS order_cnt, -- 去重防止 JOIN 膨胀 SUM(amount) AS gmv -- 金额直接求和 FROM orders WHERE dt >= DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY) AND status = 'paid' -- 有效订单口径 GROUP BY city ORDER BY gmv DESC;逻辑说明：COUNT(DISTINCT order_id)是为了防止后续如果关联其他表导致订单重复计数。参数说明：DATE_SUB的第二个参数是间隔天数，不同数据库写法不同，MySQL 用INTERVAL 30 DAY，Hive 用DATE_SUB(CURRENT_DATE, 30)。如果题干没给「近 30 天」的基准日期，默认用当前日期，但最好在注释里写一句「假设基准日为今天」。
2.2 业务指标题：考的是拆解路径
业务指标题通常给一个下降或上升的现象，让你分析原因。比如「某渠道转化率一周内从 5% 掉到 3%，怎么排查」。这类题没有标准答案，但得分点很明确：你有没有按维度拆解。
我一般会按「时间 → 渠道 → 用户分层 → 漏斗环节」的顺序拆。先看是全天下降还是某个时段下降，再看是全渠道还是单渠道，再看新老用户差异，最后定位到具体漏斗步骤。每一步都要说出「看什么指标、怎么判断」。
常见做法是画一个简单的拆解树，不用很漂亮，但要让面试官看到你的逻辑。比如：
- 时间维度：按天看转化率，判断是突降还是缓降
- 渠道维度：分渠道看转化率，判断是全局问题还是局部问题
- 用户维度：新老用户分开看，判断是拉新质量问题还是老用户流失
- 漏斗维度：曝光 → 点击 → 下单 → 支付，看哪一步掉得最多
2.3 开放分析题：考的是假设和验证
开放题最容易被忽略，但它往往是拉开差距的地方。比如「如果让你评估一次活动效果，你会怎么做」。很多人上来就说「看 ROI」，但出题人想听的是你怎么定义对照组、怎么排除自然波动。
我一般会先明确一个可验证的假设，比如「活动带来的增量订单 = 活动期订单 - 同期自然订单」。然后说清楚自然订单怎么估：可以用活动前 7 天日均、也可以用同期未参与活动的城市做对照。最后补一句「如果数据量不够，我会用双重差分或倾向得分匹配来降偏差」。
这类题不需要你写出完整代码，但需要你展示「假设 → 验证 → 结论」的闭环。参数方面，重点提显著性水平和置信区间，哪怕只是口头提一句，也能让面试官觉得你受过统计训练。
3. 用 Python 和 SQL 把笔试高频题跑通
3.1 窗口函数类题：排名、累计、同比环比
窗口函数是 SQL 笔试题的高频考点，但很多人只记住语法，不知道什么时候该用。我一般看到「排名」「累计」「同比环比」「每组前 N」这几个词，就直接上窗口函数。
下面是一个典型的「每组取前 2 名」的写法：
-- 题目：每个城市取 GMV 最高的前 2 个订单 SELECT city, order_id, amount FROM ( SELECT city, order_id, amount, ROW_NUMBER() OVER (PARTITION BY city ORDER BY amount DESC) AS rn FROM orders WHERE status = 'paid' ) t WHERE rn <= 2;逻辑说明：ROW_NUMBER()给每个城市的订单按金额降序编号，外层再过滤rn <= 2。参数说明：如果金额有重复且需要并列排名，改用RANK()或DENSE_RANK()。PARTITION BY后面跟分组字段，ORDER BY后面跟排序字段。
同比环比也是高频题。同比是跟去年同期比，环比是跟上一期比。写法上用LAG函数：
-- 题目：计算每个城市月度 GMV 的环比增长率 SELECT city, month, gmv, LAG(gmv, 1) OVER (PARTITION BY city ORDER BY month) AS prev_gmv, (gmv - LAG(gmv, 1) OVER (PARTITION BY city ORDER BY month)) / LAG(gmv, 1) OVER (PARTITION BY city ORDER BY month) AS mom_rate FROM monthly_gmv;逻辑说明：LAG(gmv, 1)取同一城市上一行的 GMV，第二行参数 1 表示偏移一行。参数说明：如果上一行是空值，环比增长率会返回 NULL，可以用COALESCE兜底。注意分母为 0 的情况，实际笔试里可以加NULLIF(prev_gmv, 0)。
3.2 漏斗分析类题：用 SQL 算转化率
漏斗题在数据分析笔试题里很常见，尤其是电商和内容平台。题干通常给一张用户行为表，让你算「曝光 → 点击 → 下单」的转化率。
我一般用COUNT(DISTINCT)配合CASE WHEN来算：
-- 题目：计算曝光 → 点击 → 下单的转化率 -- 假设表：user_behavior(user_id, event, dt) SELECT COUNT(DISTINCT CASE WHEN event = 'exposure' THEN user_id END) AS exposure_uv, COUNT(DISTINCT CASE WHEN event = 'click' THEN user_id END) AS click_uv, COUNT(DISTINCT CASE WHEN event = 'order' THEN user_id END) AS order_uv, COUNT(DISTINCT CASE WHEN event = 'click' THEN user_id END) * 1.0 / COUNT(DISTINCT CASE WHEN event = 'exposure' THEN user_id END) AS click_rate, COUNT(DISTINCT CASE WHEN event = 'order' THEN user_id END) * 1.0 / COUNT(DISTINCT CASE WHEN event = 'click' THEN user_id END) AS order_rate FROM user_behavior WHERE dt = '2024-01-01';逻辑说明：每个CASE WHEN只统计对应事件的用户数，* 1.0是为了让除法返回浮点数而不是整数。参数说明：如果题干要求「严格漏斗」，即用户必须按顺序完成曝光 → 点击 → 下单，那就不能简单用COUNT(DISTINCT)，需要用自关联或窗口函数判断事件顺序。
严格漏斗的写法稍微复杂一点，但笔试里如果题干写了「按顺序」，就必须用：
-- 严格漏斗：用户必须先曝光再点击再下单 WITH ordered_events AS ( SELECT user_id, event, dt, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY dt) AS step FROM user_behavior WHERE dt = '2024-01-01' ) SELECT COUNT(DISTINCT CASE WHEN event = 'exposure' THEN user_id END) AS exposure_uv, COUNT(DISTINCT CASE WHEN event = 'click' THEN user_id END) AS click_uv, COUNT(DISTINCT CASE WHEN event = 'order' THEN user_id END) AS order_uv FROM ordered_events WHERE (event = 'exposure' AND step = 1) OR (event = 'click' AND step = 2) OR (event = 'order' AND step = 3);逻辑说明：先用ROW_NUMBER给每个用户的事件排序，再限制每个事件必须出现在固定步骤。参数说明：step的取值取决于题干要求的事件顺序，如果中间有多个同类事件，需要先去重再排序。
3.3 用 Pandas 做笔试里的数据处理题
有些笔试会要求用 Python 处理数据，尤其是给一个 CSV 让你算指标。这时候 Pandas 比 SQL 更灵活，但要注意笔试环境可能没有网络，不能装包。
我一般会先read_csv，然后groupby加agg：
import pandas as pd # 题目：计算每个城市的 GMV 和订单量，并输出前 5 名 df = pd.read_csv('orders.csv') # 过滤有效订单 df = df[df['status'] == 'paid'] # 按城市聚合 result = df.groupby('city').agg( gmv=('amount', 'sum'), order_cnt=('order_id', 'nunique') ).reset_index() # 按 GMV 降序取前 5 result = result.sort_values('gmv', ascending=False).head(5) print(result)逻辑说明：groupby后agg可以同时算多个指标，nunique对应 SQL 里的COUNT(DISTINCT)。参数说明：reset_index()是为了把城市从索引变回列，方便后续排序和输出。如果题干要求「每个城市取前 2 个订单」，用groupby加apply或者nlargest。
Pandas 里做窗口函数也有对应写法，比如groupby加rank：
# 每个城市按金额降序排名 df['rn'] = df.groupby('city')['amount'].rank(method='first', ascending=False) top2 = df[df['rn'] <= 2]逻辑说明：rank的method参数控制并列处理，first表示按出现顺序给唯一排名。参数说明：如果题干要求并列排名，用method='min'。
4. 笔试避坑：5 个让我丢过分的细节
4.1 现象：SQL 写对了但结果偏大。原因：JOIN 导致行膨胀。解决：先确认关联键是否唯一
这是最经典的翻车场景。比如订单表关联用户表，如果用户表里一个用户有多条记录，JOIN后订单会被重复计数。我一般会在JOIN前先COUNT(DISTINCT)确认关联键唯一，或者直接用子查询先聚合再关联。
4.2 现象：指标题答得很全但得分低。原因：没有优先级。解决：先定位最大跌幅维度
业务指标题不是列得越多越好。面试官想看你有没有「先看什么、再看什么」的判断。我一般会先说「先按时间拆，看是突降还是缓降；如果是突降，优先查渠道和版本；如果是缓降，优先查用户分层和竞品动作」。
4.3 现象：开放题写了很多但没结论。原因：缺少假设和验证。解决：先写一句可验证的假设
开放题最怕写成散文。我一般会先写「我的假设是 X 导致 Y」，然后写「验证方法是 Z」，最后写「如果 Z 成立，结论是 W」。哪怕假设是错的，逻辑闭环也能拿分。
4.4 现象：Python 题运行超时。原因：用了循环而不是向量化。解决：优先用 groupby 和 apply
笔试环境通常资源有限，for循环处理几万行就可能超时。我一般会先看能不能用groupby加agg解决，实在不行再用apply，但apply也要尽量写成向量化操作。
4.5 现象：时间不够用。原因：在第一道题上死磕。解决：先扫一遍所有题，按分值分配时间
我一般会花 2 分钟扫一遍所有题，标记出「必拿分」「可争取」「放弃」三类。SQL 基础题必拿，复杂窗口函数可争取，开放题如果时间不够就写框架。这样至少能保证基础分不丢。
5. 笔试最后 10 分钟：用检查清单把该拿的分拿稳
笔试最后 10 分钟，我一般不会再去写新题，而是做三件事：检查口径、检查边界、检查输出格式。
检查口径：题干里的「有效」「近 30 天」「去重」有没有漏掉。我习惯在 SQL 注释里把口径写出来，最后扫一眼注释和代码是否一致。
检查边界：分母为 0、空值、重复值、日期格式。比如JOIN后COUNT要不要加DISTINCT，SUM要不要加COALESCE。这些细节在笔试里往往是扣分点。
检查输出格式：题干要求「保留两位小数」有没有做，要求「按 GMV 降序」有没有写ORDER BY，要求「输出前 5 名」有没有LIMIT。这些看起来是小事，但每年都有人在这里丢分。
下面是一个我常用的检查清单，可以考前默写一遍：
| 检查项 | 常见问题 | 快速修复 |
|---|---|---|
| 口径 | 漏过滤已取消订单 | 加status = 'paid' |
| 去重 | JOIN 后订单重复 | 用COUNT(DISTINCT) |
| 空值 | 分母为 0 或 NULL | 用NULLIF或COALESCE |
| 排序 | 忘记ORDER BY | 按题干指标降序 |
| 限制 | 忘记LIMIT | 取前 N 名加LIMIT N |
| 格式 | 小数位不对 | 用ROUND保留两位 |
最后说一个我自己的习惯：笔试前我会把常用 SQL 模板和 Pandas 操作默写一遍，不是背代码，而是背「什么场景用什么写法」。比如看到「每组前 N」就想到ROW_NUMBER，看到「同比环比」就想到LAG，看到「漏斗」就想到CASE WHEN加COUNT(DISTINCT)。这个习惯让我在几次笔试里至少省了 10 分钟。希望帮到你。
本文还有配套的精品资源，点击获取
