1. 先把地基打牢版本选择、虚拟环境与编辑器联调1.1 版本选择不要一上来就追最新很多人刚开始学Python会直接去官网下载最新版装完再装numpy、pandas发现一切正常于是觉得“版本无所谓”。直到有一天你需要在公司集群上跑PySpark或者在Linux服务器上部署一个老项目才发现服务器里装的是Python 3.8你本地用的却是3.12接口差异、依赖冲突、编译错误一起涌上来。我在实际工作中被这个事坑过不止一次后来给自己定了一条规矩做数据分析优先选生态兼容性最好的稳定版本而不是最新版本。如果你不依赖特别老的内部库Python 3.10或3.11是比较舒服的选择pandas、numpy、scikit-learn、matplotlib这些核心库都维护得很好Spark和Hive相关的客户端也不容易出兼容问题。千万别小看这一步版本选错后面所有包都可能连锁报错。真实场景里某个同事用3.13装了一个依赖Cython的老库编译直接失败折腾一下午最后换回3.10就好。另一个容易被忽略的点是机器位数和操作系统的差异。Windows、macOS、Linux三套环境里同一条pip install命令的行为可能完全不同。比如opencv-python在普通Linux服务器上经常缺libGL库一旦你拿它处理图片一运行就报错。这时候装opencv-python-headless反而更省事。数据分析师不一定天天写图像代码但这一类“环境差异”问题会反复出现提早了解能省下大量排查时间。1.2 从官网下载到环境变量配置的完整链路安装Python这件事看起来就是“下一步、下一步、完成”但有一个关键选项很多人会漏Windows安装包第一页底部的“Add Python to PATH”必须勾选。没勾选的话你打开命令行输入python系统会一脸茫然地告诉你“不是内部或外部命令”。这就是网上大量“python安装教程”帖子存在的意义。勾选之后你的电脑才能直接在终端里唤起Python。装完以后建议你顺手验证三件事python --version pip --version python -m pip install --upgrade pip第一条看版本第二条看pip是否可用第三条把pip更新到稳定版本。别小看第三条老版本pip在装某些带二进制依赖的库时会莫名解析出错升级之后问题直接消失。Linux系统下安装又不一样。大多数发行版自带Python 3但自带的版本可能偏旧而且系统包管理器里的Python和pip经常受系统权限保护你直接往里装包会污染系统环境。我的做法是用apt安装python3-venv或者直接下载官方二进制包解压到个人目录再手动配置PATH和PYTHONPATH。这样既不影响系统自带的Python又能给数据分析环境一个独立空间。环境变量配置也值得多写一句PATH决定你在终端里输入python时系统去哪里找解释器PYTHONPATH则决定import包时去哪里找模块。很多人遇到“明明装了pandasimport却说找不到”就是因为在另一个Python解释器下运行。所以每次换环境前先在终端里敲一下which python确认自己到底在用哪个解释器。1.3 vscode配置和Jupyter的取舍文本编辑器我推荐vscode不是因为它功能最多而是因为它把“写脚本、跑代码、看数据”放进同一个窗口。你在vscode里安装Python扩展后重点是学会切换解释器按CtrlShiftP输入“Python: Select Interpreter”选你创建的那个虚拟环境。这一步没做对后面代码跑起来没问题但一import就报ModuleNotFoundError根源多半是解释器选错了。分析工作还有一个高频工具是Jupyter Notebook。它适合探索性分析一段段跑、边跑边看中间结果、随时把图表插到代码之间。缺点也很明显代码顺序一旦混乱变量状态容易“串味”。我的习惯是探索阶段用Notebook整理成正式脚本时切回vscode把验证过的逻辑写成函数。两套工具配合使用比在Notebook里堆几千行代码舒服得多。1.4 安装numpy、cv2、PySpark等包时最常见的翻车现场网上搜索“python安装numpy库的方法”通常给出的答案就是pip install numpy。实际做的时候你可能遇到两种情况第一种是网络超时pip一直转圈最后报ReadTimeoutError第二种是编译错误提示缺少Microsoft Visual C或gcc。超时可以切换国内PyPI镜像比如执行pip install numpy -i https://pypi.tuna.tsinghua.edu.cn/simple速度立刻不一样。编译错误则通常说明当前环境缺少预编译好的wheel包优先升级pip再不行就装对应系统版本的编译器工具。安装PySpark比安装普通库多一道门槛它依赖Java运行环境。很多人在没有任何JDK的机器上执行pip install pyspark装完以为自己能跑了一import就抛java.io.FileNotFoundException或者显示找不到JAVA_HOME。解决办法是先装JDK配置好JAVA_HOME再装pyspark。凡是跟Java绑定的库都必须先确认Java环境这是这类场景最常见的坑。还有一个习惯我强烈建议不要在base环境里无脑装包。用conda或venv创建独立环境比如conda create -n analysis python3.10然后激活它再装pandas、numpy、matplotlib、pyspark。独立环境的好处是项目A升级某个库不会把项目B的环境搞坏哪天环境被搞乱了直接删掉重建几分钟就能恢复。数据分析师的项目周期短、需求多变这一套“隔离”思路能帮你省下大量返工时间。2. 数据读取与清洗把脏活干得优雅一点2.1 读CSV、Excel、数据库时的常见小脾气做数据分析的人每天面对的数据源绕不开CSV、Excel和数据库这三种。CSV是最常见的但也是坑最多的。第一个坑是编码Windows下的CSV经常是gbk编码直接用pandas默认的utf-8去读满屏都是UnicodeDecodeError。我的习惯是一开始就指定encodingutf-8-sig如果是gbk再换成encodinggbk。第二个坑是列类型订单号的长度超过15位时Excel和CSV会把后几位变成0读进pandas后变成浮点数。所以读订单表我通常在read_csv里指定dtype把订单号强制读成字符串import pandas as pd df pd.read_csv( orders_2025.csv, encodingutf-8-sig, dtype{order_id: str, amount: float, city: str} )读Excel要记住一个前提pandas本身不直接支持xlsx需要先装openpyxl或xlrd。很多人没装扩展包就调用read_excel报错后以为是函数用错了。数据库读取稍微复杂一点一般需要SQLAlchemy连接串比如pd.read_sql(select * from orders limit 1000, conengine)。这里建议先做limit抽样确认数据量级和字段含义再决定是全量拉取还是分批拉取。做商业数据分析时动不动就全表扫描是最容易拖垮数据库的行为。2.2 去重、缺失值和“看起来一模一样”的数据数据清洗里的去重比你想象中要复杂。直接调用df.drop_duplicates()确实能按整行去重但业务上的重复经常只针对某些关键字段比如一个订单号出现在两行但金额和收货地址不完全相同这时候你要按订单号去重并且自己定义保留策略保留最新时间、保留金额较大的、保留下单状态更完整的。建议先执行df[df.duplicated([order_id], keepFalse)]把重复样本单独捞出来看几行而不是盲目删除。缺失值处理也是同理别一见到NaN就fillna(0)。连续型指标像金额、时长更适合用中位数填充因为中位数不容易被极端值带偏。离散型指标像城市、渠道我会先看缺失比例如果缺失比例太高直接补“未知”比猜一个值更诚实如果缺失比例很低可以用众数填充。有一个小技巧我很常用先df.isna().sum()统计每一列的缺失数量再按缺失原因决定策略。这个顺序能避免“拍脑袋处理”。还有一种更隐蔽的重复内容几乎一样但写法不同。比如“北京市朝阳区”和“北京朝阳区”“张三”和“张先生”算法层面不好直接判断。遇到这种数据我一般用difflib库里基于文本相似度的工具做初步聚类把相似度大于90%的样本筛出来再人工确认。数据清洗最核心的思维不是“把数据变没”而是“把不可比的数据变成可比的数据”这个思路在处理地址、产品名、渠道名时特别管用。2.3 从订单表到邻接矩阵一种常用关系转换很多人在网上搜“python构建邻接矩阵”一看到矩阵和networkx就头大其实在数据分析场景里邻接矩阵就是一张宽表行是起点列是终点单元格里是关系强度。拿订单数据举例子假设你有一张“客户-商品”购买记录表里面有customer_id和product_id你想知道哪些客户同时买过哪些商品最简单的一步就是把长表转成宽表也就是交叉表。用pandas可以一行完成matrix pd.crosstab(orders[customer_id], orders[product_id])这个m*n的矩阵里行是客户列是商品值是该客户购买该商品的次数。你别看这个简单操作它背后是很多分析项目的地基商品协同过滤、客户分群、关联分析全都从这张矩阵开始。如果你的原始数据是网络关系表比如两列分别是“起点”和“终点”用networkx里的from_pandas_edgelist也能直接构建图对象后面算节点度、找连通分量都很方便。构建邻接矩阵前我建议先做一步检查用pivot_table还是crosstab取决于你的数据是否有重复行。若有重复crosstab会直接计数若想自定义聚合方式比如算平均消费先groupby再pivot会更稳。把这一步想清楚矩阵里就不会出现莫名其妙的重复累计。2.4 单个文件读取慢用线程池把多个文件并行读进来做数据分析时我经常遇到“一天一个文件一个月30个文件每个几十MB”的情况。如果你写for循环一个一个读耗时线性增长读30个文件就得等几分钟。好消息是这类读取是I/O密集型操作不需要等上一个文件读完再开下一个。pandas的read_csv本身是带缓冲的但如果文件数量多用concurrent.futures的ThreadPoolExecutor可以明显提速。from concurrent.futures import ThreadPoolExecutor import glob import pandas as pd def read_one(path): return pd.read_csv(path, encodingutf-8-sig) files glob.glob(data/2025_*.csv) with ThreadPoolExecutor(max_workers8) as executor: frames list(executor.map(read_one, files)) df pd.concat(frames, ignore_indexTrue)用这招要留个心眼线程数不是越大越好一般8到16个就够再大反而会因磁盘读写竞争而变慢如果机器内存比较小一次读全部文件到内存可能直接。稳妥的做法是先看文件总大小总大小在2GB以内通常没问题超过这个量级就应该考虑分块读取或转用大数据工具。这里顺便提一句Python协程适合网络请求这类等待型任务而多线程更适合本地文件读取别把两个概念搞混。网上搜“python队列queue不堵塞”本质也是把任务放进队列、让多个worker并行消费只是在不同场景下线程池更直接。3. 分析计算与业务指标的落地3.1 groupby聚合分析师的“透视表”如果只能保留一个pandas函数我一定选groupby。它就像Excel里的透视表但更灵活也更适合写进自动化流程。比如你要看每个城市、每个月的订单量和GMV代码其实非常直白summary df.groupby([city, order_month]).agg( order_cnt(order_id, count), gmv(amount, sum), avg_order(amount, mean), ).reset_index()这里有个细节agg里的写法是“新列名 (原列名, 聚合方式)”pandas会一次生成多列比分别groupby后merge效率高得多也更不容易写错。我见过很多新手先groupby再.reset_index又因为索引问题报错其实只要记住agg之后用reset_index把分组键变回普通列后续操作就不用跟索引较劲。groupby之后最常见的需求是算占比和环比。算城市占比可以先groupby得到城市GMV再除以GMV总和算环比一般用shift配合groupbymonthly[gmv_prev] monthly.groupby(city)[gmv].shift(1) monthly[mom] (monthly[gmv] / monthly[gmv_prev] - 1) * 100注意这里shift是按城市分组后各自向后平移一行所以每个城市的第一个月gmv_prev是NaN不能直接参与计算。数据量不大时这么写很舒服数据量大到几千万行时groupby会明显吃力这时候就该把计算推给Spark或数据库引擎Python只负责拿最终结果做可视化千万别在内存里硬扛。3.2 用“李白打酒”这一类小问题训练分析思维网上有个经典题目叫“李白打酒”很多学Python的人都刷到过。题目大意是李白酒壶里有一定量的酒他遇到酒店酒量加倍遇到花喝掉一斗最后经过若干次遇店和见花酒正好喝光。问初始酒量是多少或者符合条件的情况有多少种。第一次看这道题你会觉得它只是一个算法练习题但把它写一次递归代码之后你会发现它训练的是“约束条件下穷举”的能力def dfs(dian, hua, wine): if dian 0 and hua 0: return 1 if wine 0 else 0 res 0 if dian 0: res dfs(dian - 1, hua, wine * 2) if hua 0 and wine 0: res dfs(dian, hua - 1, wine - 1) return res在真实业务里这种“状态搜索”思维特别有用。比如物流调拨问题给定一个中转节点网络货物从A到B在有限中转次数里能否到达这跟李白打酒里的“店”和“花”其实是同一类问题——每一步都有规则约束节点之间靠递归或队列一层一层探索直到找到所有可能路径。你不必把DFS背下来但你要能识别“这类问题可以用穷举和状态转移来处理”这是数据分析师和只会套函数的人之间最大的差别。3.3 量化策略回测的最小框架把想法快速验证一遍量化交易是Python在金融领域最出圈的应用之一网上搜“python量化交易策略代码”会得到大量复杂框架。但作为数据分析师你不需要一步到位搭出生产级回测系统只要把“信号—持仓—收益”这条链路跑通就能在实际操盘前验证大量想法。最小框架就是一个数据表加三列收盘价、信号、策略收益。def backtest(price_df, signal): ret price_df[close].pct_change().fillna(0) strategy_ret signal.shift(1).fillna(0) * ret return (1 strategy_ret).cumprod()这里最关键的是shift(1)用当天的信号去预测次日的收益避免“用未来数据做决策”的前视偏差。哪怕只是写个小策略我也提醒自己检查三件事有没有未来函数、有没有把交易成本算进去、信号是不是建立在成交量或价格的事后统计上。这三个坑不排掉回测出来曲线再漂亮实盘里也可能彻底变形。量化回测的本质不是预测股价而是检验你的假设在历史数据上是否成立这个思路完全迁移到业务分析里比如预测库存周转、判断营销活动的用户响应率同样适用。3.4 数据定义与口径比代码更重要的分析模型代码写得好不代表分析做得对。我在实际项目里见过太多“两个分析师算出两个答案”的情况原因不是语法错误而是口径不一致。比如计算GMV是按下单时间算还是按支付时间算取消订单算不算退款单算不算这些定义一旦不同同样的SQL和Python跑出来的结果天差地别。所以每次分析开始前我会先把指标口径写成一份几十字的小说明发到协作群里确认确认后才动手写代码。这个习惯相当于给自己的Python工具箱配了一份“说明书”。工具本身再强口径错了就是给业务方递了一把伤人的刀。你的pandas聚合写得再熟练也不如分析前多问一句“你到底想要什么”。这是商业数据分析里最值钱的经验之一。4. 可视化别让你的图在PPT里活不过三秒4.1 横坐标太密集日期轴怎么治理用matplotlib画时间序列时最常出现的问题就是横坐标挤成一团日期太多刻度标签全部叠在一起黑乎乎一片。同事看了皱眉头业务方看了摇头。这个问题在网上反复被搜解法其实不复杂。先确保你的x轴是datetime类型然后用matplotlib.dates设置刻度间隔和格式import matplotlib.pyplot as plt import matplotlib.dates as mdates fig, ax plt.subplots(figsize(10, 4)) ax.plot(df[date], df[gmv]) ax.xaxis.set_major_locator(mdates.MonthLocator()) ax.xaxis.set_major_formatter(mdates.DateFormatter(%Y-%m)) plt.xticks(rotation45) plt.tight_layout() plt.show()如果你不需要那么细的粒度更简单的办法是先用pandas把数据按周或按月光滑聚合减少点数之后再画。比如df.resample(W-MON, ondate)[gmv].sum()把日粒度汇总成周粒度图里的线条既平滑又不会丢失业务趋势。画图的第一原则永远是“让读者一眼抓住想看的信息”而不是“把每个数据点都摆上去”。4.2 五种常见的业务图形及选型逻辑不同分析问题应该用不同图形我给自己整理了一个选型表基本能覆盖90%的业务场景分析目的推荐图形使用要点看时间趋势折线图别超过3条线突出关键转折点看构成占比柱状图或堆叠柱状图类别超过5个时优先用柱状图看数据分布直方图或箱线图箱线图能看出异常值看变量关系散点图加趋势线先看相关系数再看图看地域分布地图或热力图数据量少时用热力图更直观这里特别提醒饼图不是不能用但只适合2到4个大类的占比。你硬要放一个12个部门的饼图那只是把报告变成调色盘业务方根本看不出重点。还有柱状图和折线图的混搭除非确认两个指标在同一个量级否则别轻易用次坐标轴次坐标轴用不好就是“看图说话的工具”。4.3 图表细节标题、单位和图例要让业务不猜一个合格的分析图应该是“不解释也能看懂”。我每次出图前都会看三处标题写的是不是结论而不是“销售数据图”坐标轴有没有单位图例是不是和业务命名一致。比如标题应该写“华东区GMV连续三个月下滑需关注竞品影响”而不是“华东区GMV变化”。分析图是为了传递结论不是为了展示你matplotlib用得熟。还有一个小细节常被人忽略负号和中文。matplotlib默认字体可能显示不了中文还会把负号显示成方块。很多新手在论坛问为什么图里都是方框多半是没处理字体。常规写法是plt.rcParams[font.sans-serif] [SimHei, Microsoft YaHei] plt.rcParams[axes.unicode_minus] False这两行放在脚本开头能解决大部分中文显示问题。不同操作系统可用的字体不一样Windows下SimHei和Microsoft YaHei通常没问题macOS可以换成PingFang SC。我一般建议在vscode脚本里统一配置而不是每张图都手动改。4.4 从Notebook到正式报表别让可视化变成一次性工作在Notebook里画图很方便但项目要交付时我通常会把画图代码整理成函数比如plot_gmv_trend(df, city)这样一份周报数据更新后只需要重新跑一遍脚本所有图会自动刷新。这个思维来自“数据分析项目实践”里最常见的需求同一个分析业务方每周都要看一次。与其每周重新操作一遍不如把流程固化成本地脚本用定时任务去执行。这个能力才是“数据分析师的Python工具箱”和普通Excel报表之间的分水岭。5. 爬虫、自动化与大数据工具箱的上层联动5.1 合法取数只拿公开数据守住三条边界数据分析师经常需要补充外部数据比如竞品公开价格、行业政策、公开榜单这时候就需要爬虫。网上有大量“python爬虫”教程但我要先泼一盆冷水爬虫最大的风险不是技术而是合规。我只做三种数据不需要登录的公开页面、有官方API的数据源、平台明确允许下载的数据集。绝不碰登录绕过、验证码破解、高频并发抓取这三件事任何一条都足够让你陷入麻烦。技术本身不复杂requests负责下载网页BeautifulSoup或lxml负责解析结构如果你要抓的是JSON接口直接用requests拿到response.json()更省事。一个最小化爬虫长这样import requests from bs4 import BeautifulSoup headers {User-Agent: Mozilla/5.0} resp requests.get(url, headersheaders, timeout10) soup BeautifulSoup(resp.text, html.parser) titles soup.select(.product-title)这里有一个重要习惯每个请求之间加延时比如time.sleep(1)既是对对方服务器的尊重也能降低被封的风险。抓10个页面和抓10万个页面的技术栈差别不大差别在于你是否把频率控制住了。爬下来的数据一定要落盘不要停在内存里用pd.DataFrame.to_csv()或直接写入数据库让后续分析有据可查。5.2 电商快递账单、网约车订单这类项目的数据结构怎么拆在网上搜“电商快递账单数据分析”“网约车数据分析”会看到很多项目案例这些项目的数据结构其实高度相似。它们通常都是明细级大表一单一行关键字段包括时间、地点、主体、金额、数量。电商快递账单关心的维度是计费重量段、寄递区域、产品类型、是否偏远地区网约车订单关心的维度是高峰时段、起终点区域、里程区间、司机乘客分层。这类分析的第一步不是写Python而是先把表结构画清楚搞清楚谁是事实表、谁是维度表。数据量小的时候pandas完全扛得住。数据量一旦到几千万行python跑groupby会变得非常吃力。这时候就要引入Hive或SparkHive负责把数据从原始日志清洗成明细宽表Spark负责做复杂聚合Python负责把聚合后的结果拿回本地做可视化。分工明确谁都不拖后腿。比如网约车订单数据原始表可能有几百个字段清洗后保留核心字段并分区存储按“城市具体城市”“日期具体日期”分区分析人员要取数时先做分区裁剪再处理效率能提升数倍。5.3 数据分析项目的标准流程从需求到交付一个数据分析项目看起来是从“写代码”开始的实际上是从“定义问题”开始的。我常用的流程是五步确认口径、探查数据、清洗加工、分析建模、输出结论。每一个步骤都要有可交付的产物口径说明、字段清单、清洗脚本、分析报告和图表。这样哪怕项目中途换人接手也不至于从零开始。这套流程放在“数据分析项目实践”里尤其重要。比如接到一个商业数据分析需求业务方说“想看看最近客户流失情况”你不能直接跑代码而要先问他怎么定义流失是连续30天未下单还是连续90天未登录是一种口径还是多种口径一旦定义清楚了后面的Python代码只是按定义翻译成统计逻辑而已。这个“翻译”能力才是数据分析师的核心竞争力。5.4 报表自动化的最小落地方案把周报做成自动化是每个数据分析师都想做的事。最简单可靠的方案是写一个Python脚本从数据库或文件读取数据、生成图表、汇总成Markdown或Excel再用系统自带的任务计划每天或每周执行。脚本里记得用绝对路径或者以脚本所在目录为基准拼路径否则定时任务在另一个目录启动时会找不到文件。推送方式上现在很多团队用的是企业微信机器人或钉钉机器人只需要一个webhook地址脚本里用requests POST一段消息或图片比配置邮件服务器简单得多。我以前还花时间研究怎么用smtplib发邮件后来发现webhook才是效率最高的方式。定时任务执行完以后先写日志、再推结果日志里记录执行时间、处理行数、是否成功这样第二天发现问题全靠日志定位。6. 排查和优化在“卡死”面前别慌6.1 慢、卡、内存爆95%的根源就这几类数据分析师最常见的崩溃时刻就是运行一个脚本等了五分钟还没结果然后系统提示内存不足。这种问题95%可以归到几类不该循环的地方用了循环、读了不需要的全量列、两个大表生成了数据量爆炸的中间结果、或者groupby后没有及时释放中间变量。我见过最典型的错误是有人用for循环一行一行地改DataFrame里的值比如给每个订单打标签以为这是理所当然的。实际上只要能向量化就不要循环。pandas里的np.where、df.apply、map、merge都是替代循环的方案一行代码能完成的事情为什么要让CPU跑十万次循环这就像走路能到的地方非要绕遍全城。记住一个原则能用内置函数解决就不自己写循环能用SQL和Spark解决就不把全量数据拉到本地内存。6.2 用计时与profile定位瓶颈遇到慢脚本先别急着优化先用最简单的方法定位打点计时。在关键步骤前后用time.perf_counter()计算耗时打印出来用数据说话。很多你以为很慢的步骤其实极快反而是你没注意到的某个concat拖慢了整个流程。如果脚本里函数很多建议用cProfile跑一遍它会告诉你每个函数调用次数和累计耗时瞬间暴露瓶颈。内存方面可以给系统加一点监控或者定期输出DataFrame的内存占用df.memory_usage(deepTrue).sum() / 1024**2看到具体数值你就知道哪些列是内存杀手。比如一个列明明是分类却存成了字符串对象内存开销能高出好几倍改成category类型或数值编码后内存直接下降。6.3 看机器负载和程序耗时的对应关系在服务器上跑分析任务时我习惯同时观察CPU负载和内存占用。你打开系统的监控工具看到load average飙高不要慌张先判断是CPU密集导致的正常现象还是内存耗尽触发了持续交换。数据分析脚本常见的状态是Python进程占内存好几个GBCPU用不满这时候并行也没有意义因为瓶颈在内存带宽和I/O上而不是计算核心数。一个实用的方法是先在一个小样本上跑通逻辑并计时再按数据量估算全量耗时。比如100万行的groupby耗时1秒不代表1000万行只要10秒因为内存交换和GC一掺和耗时可能变成30秒甚至更久。所以我会在小样本上记录峰值内存再估算机器是否能扛住扛不住就直接换大数据链路别硬等。6.4 用Spark和Hive处理大数据时的优化小技巧当你发现单机Python已经顶不住就该考虑把计算下推到Spark或Hive里。先记住一个原则聚合能下推就下推最终返回Python的结果越小越好。用PySpark写聚合常见模式是这样的from pyspark.sql import functions as F df spark.read.parquet(hdfs://.../orders) result (df .filter(F.col(dt) 2025-01-01) .groupBy(city) .agg(F.sum(amount).alias(gmv)) .toPandas())这里最关键的优化点是filter先执行减少参与计算的数据量groupBy之后再做toPandas而不是先把整个大表拉回本地再聚合。真实项目里经常会遇到某个热点城市的数据量占了一半导致reduce阶段数据倾斜任务卡在最后一步。处理方法通常是对城市加随机前缀打散再二次聚合或者广播小表做join。这些都是Spark性能调优的常规动作但你要知道一个事实数据量不大时Spark不一定比pandas快只有数据量大到单机内存明显不够时分布式计算的优势才会真正显现。写在最后把工具箱整理成自己的语言我个人的经验是数据分析师的Python能力不是靠看一遍教程就能提升的而是在一次次“被报表毒打”之后练出来的。你装好环境、能跑通pandas、画出第一张图这只是第一步真正让你成长为“工具箱主人”的是你遇到报错后不慌、遇到慢脚本知道从哪里查、遇到业务方口径不一致时能先停下来对齐定义。这也是为什么我一直不建议大家去下载所谓的“现成源码大全”那些代码不能帮你建立排查问题的能力反而容易把你带进别人的坑。相信你把自己做过的数据清洗、聚合、可视化脚本沉淀成一堆可复用的小函数之后会明显感觉到效率质变。下一次再遇到新需求不是从零开始查文档而是翻出自己的工具箱改改参数就能用。这个过程没什么捷径但绝对是数据分析这条路上最值得投入的一段时间。