2026年Python数据分析2组对照实验玩懂pandas与可视化

PAGE2026年Python数据分析：2组对照实验玩懂pandas与可视化

你有没有遇到过这种窘境：学了两门网课，刷了几百道Python题，结果领导发来一个800MB的销售明细，你第一反应还是“我先导出一份Excel看看”。文件一打开卡死，Python培训班的知识全忘光。你又不是真的不会Python数据分析，就是不知道该怎么在真实工作里用起来。2026年了，Python数据不是课本名词，而是你能不能搞定那份连Excel都打不开的数据表的问题。一、实验一：Excel对抗pandas，清洗一份脏到怀疑人生的数据先说一个我亲眼见过的场景。去年一个运营同事小林，接到一个任务：清洗一份大促活动产生的订单明细。原始CSV有120万行，字段包括用户ID、下单时间、商品ID、价格、支付方式、优惠券编号等等，总共28列。文件大小大约是950MB。他电脑是16G内存，装的Office还是正版。结果是，双击Excel，黑屏转圈，三分钟后弹出一个窗口：内存不足，建议使用PowerPivot。小林一脸茫然，只好先写邮件向数据组求助。同样的数据，我让另一个会一点Python的应届生，用pandas来清洗。两个人从同一个原始文件出发，同样的需求：去掉测试数据、填补缺失支付方式、删除重复订单、过滤异常价格段。中间我记录了一下两种做法的过程和时间。这一节，我们就拿这份真实的“脏数据”做实验，做一组Excel方法A与pandas方法B的对照。错误做法A：全靠Excel，肉眼+鼠标硬刚A方法，就是大部分人最熟悉的那条路。导入阶段，小林用Excel打开CSV，第一次失败，第二次分割导入，先导入前50万行，剩下的切成两块。光是做这一件事，他就花了大约20分钟。期间电脑风扇狂转，他不敢同时开浏览器，生怕死机。看起来只是一个数据文件。其实已经在消耗精力。分批导入完以后，他才开始真正的数据清洗。操作流程大致是这样：1.筛选出测试数据：找出用户ID前缀为test_的行。2.删除重复订单：根据订单编号列做条件格式，查找重复，再手动删除或高级筛选。3.填补缺失支付方式：如果是已支付订单但支付方式为空，用“其他”填上。4.过滤异常价格：价格小于0或大于10万的行删除。Excel里这些都不是做不到，只是步骤非常繁琐，比如“删除重复订单”，小林先是用条件格式标了一遍重复值，再复制一列到新表，最后用“数据”菜单里的“删除重复项”工具。中间错删了一次，又撤销重来。关键是，Excel对于50万行左右的数据，几乎每一次筛选和删除操作都要等3-5秒，遇到多条件筛选甚至要十几秒。人就被迫坐在电脑前面看进度条。我统计了一下他这次清洗的时间：导入拆分：20分钟筛选测试数据并删除：10分钟删除重复订单：15分钟填补缺失支付方式：8分钟过滤异常价格：7分钟检查是否有漏掉的测试数据和异常：5分钟导出合并后的结果：10分钟总耗时：约75分钟，而且他自己说中间脑子已经放空，后面几步纯靠机械操作。更重要的是，这个过程几乎完全不可重复。你问他“你刚才是怎么过滤异常价格的”，他只能含糊地说“我在价格列筛了一下小于0和大于10万的行，然后删掉”。没有清晰的步骤记录。也就谈不上复盘。更糟糕的是，分批导入导致一个隐性问题：跨文件的重复订单很难查全。Excel一份查一次，三份都查完，还是有2%左右的重复订单留在结果里。粗略算了一下，这份数据最终清洗完后，测试数据的漏删率大概在1.5%，重复订单残留在2%上下。数据质量只堪用来做个大概报表。用它去做后面的Python数据分析，风险就埋下了。正确做法B：pandas一体化清洗，同样需求不同路径B方法的起点完全一样：同一份950MB的CSV，同样的清洗需求，电脑配置也一样。不同的是，他打开的是一个JupyterNotebook，用Python数据工具链来处理。应届生小周的整个过程，我就贴一下关键的操作逻辑。1.读取数据1.使用分块读取（chunk）避免一次性占满内存。2.合并分块的清洗结果。思路很简单：别一次吃完，一勺一勺地吃。读取代码大致类似这样（具体语法不展开讲）：用pandasread_csv，指定chunksize=10万在for循环中，对每块数据直接做清洗清洗完append到列表最后concat所有块，得到干净表整个读取加清洗的阶段，耗时大约是9分钟。电脑风扇会转，但不会卡死，浏览器、聊天软件照样能用。2.清洗逻辑的实现与Excel那种“边想边点”的模式不同，pandas的清洗逻辑一次写清楚就行：测试数据筛除：条件是用户ID以"test_"开头或者订单编号中含"TEST"。pandas里就是一行布尔索引过滤，留下非测试数据。重复订单删除：以订单编号和下单时间作为重复判断的主要字段，保留最晚的那一条。pandas的drop_duplicates支持按列组合，并指定保留"last"。填补缺失支付方式：条件是订单状态为"已支付"但支付方式为空，用"其他"填充。pandas用loc条件筛选，赋值填补。异常价格过滤：单价小于0或者大于10万的行直接丢弃，顺带统计一下有多少行属于异常。小周做完之后，整套清洗规则既写在代码里，也自然形成了一个可复用的清洗脚本。你要追问“为什么这个订单被删了”，他可以把条件反查给你看。这次用pandas的清洗结果，我单独做了抽样检查：测试数据漏删率：小于0.1%（1000条中漏了不到1条）重复订单残留率：约0.3%异常价格残留：抽样未发现数据质量肉眼可见地提高。三边耗时也能明显比较：同样的数据量Excel方案A：75分钟人工操作，且无法完全复现pandas方案B：9分钟脚本运行+15分钟写代码+5分钟自检总计不到30分钟，而且当活动第二天新增了50万行数据，只需要重新执行同一个脚本，15分钟内可以再次得到近期整理的清洗结果。时间节省至少60%，人工点击操作减少90%以上。最关键的区别，是可复制。以后你面对类似的Python数据清洗任务，这套pandas脚本稍微改改字段名和条件，就能再用一次。价值会逐渐叠加。这个实验给你的直接建议如果你现在还处在“数据一来就导出Excel”的阶段，可以先从最小的一步开始，别一下子全换工具。建议你做一个自己的小实验：1.选一份公司里的真实CSV数据，哪怕只有5万行。2.先用Excel清洗一遍，把操作步骤随手记下来。3.再用pandas复刻一遍同样的逻辑，把整个清洗过程写在一个.py或Notebook里。4.下次再来类似数据，只用pandas那份脚本处理，记录耗时变化。你会很直观地体会到一件事：学pandas并不是为了替代Excel的“筛选”和“排序”，而是为了让你从此对“这个文件太大，Excel打不开”的场景免疫。2026年开始，把Python数据变成你自己的常规工具，而不是应急时才想起来的技能。二、实验二：for循环做统计，对抗groupby一行搞定坦白讲，大部分自学Python的人，在数据分析这块卡住的位置都非常统一。变量、函数、if、for都能写，碰到数据表就懵了。于是他们会本能地用“for循环+字典”去做所有统计工作，比如按城市统计订单量、按品类统计销售额等等，能跑，但跑得很慢。这一节，我们就拿一个销量数据做对照实验：A方法用纯for循环和字典累加，B方法用pandas的groupby，一行解决。看看在数据量和代码复杂度上的差距。错误做法A：直觉式for循环统计，代码变成意大利面背景还是小林，这次他拿到的是去年全年的订单数据，行数大约在300万左右，字段包括订单ID、城市、品类、成交金额、下单日期等。需求非常简单：按城市统计全年成交金额总和，并按金额从高到低排序。另外再来一个按城市统计订单数量的排名。如果你只学过Python基础，又没接触过pandas，很自然会写出这样的伪代码逻辑：1.打开CSV文件，逐行读取。2.用一个字典city_amount统计每个城市的成交金额总和。3.用另一个字典city_count统计每个城市的订单数量。4.把字典转成列表，根据金额或数量排序。5.打印前10名。这种循环方式，在几万行数据时无可厚非。当数据行数一上到百万级，问题就暴露了。我让小林用A方法跑了一次300万行的数据，结果是这样的：纯for循环统计：每行做一次split/解析，加两次字典访问+一次加法在他那台16G内存、i5处理器的笔记本上，运行时间接近80秒中间没报错，但CPU占用率一直在90%以上然后他要做第二种统计（比如把城市换成品类），还得复制一遍逻辑再改变量名。代码文件越写越长，最终统计3个维度时，源文件行数超过220行。长且难改。更麻烦的是，一旦有缺失值或异常数据，比如某行城市列为空，他可能在for循环里忘记做判断，就会出现KeyError或空字符串被当成城市统计进去的问题。这种方式能用，但每加一个维度，维护成本都会多一截。正确做法B：pandasgroupby，一行一个维度我们用同样的原始数据，换成pandas的思路。读取300万行数据到pandasDataFrame，在普通的64位Python环境、16G内存的机器上，这件事的耗时大致在7-10秒之间。如果做一些列类型转换和必要的优化，整体也不会超过15秒。接下来按城市统计成交金额总和，其实就是一行groupby加sum，再sort_values。按城市统计订单数量，用同样的groupby加size或count即可。整个统计逻辑控制在10行代码以内。真实的性能差距怎么样呢？同样的300万行数据，在同一台机器上：for循环+字典方案A：纯统计逻辑耗时80秒左右加上读文件总共接近100秒pandasgroupby方案B：读入数据8秒城市成交金额统计：约1.2秒城市订单数量统计：约1.1秒合计不到12秒，性能提升约8倍。而且一旦你想换个维度，比如从城市改成品类，不需要复制整段代码，在groupby里换一下列名就好。你要一次统计城市+品类的多维组合，也就是groupby(['城市','品类'])这么简单。代码量从220行压缩到不到40行，缩减超过80%。更重要的是，groupby天然做的是“按某些字段分组后对其他字段做聚合”，这跟数据分析的思维方式高度一致。它强迫你先思考“我要按什么维度看数据”，再动手写代码，而不是一上来就写for循环，边写边想。Python数据分析从“体力活”变成“脑力活”。这组对照对你有什么启发如果你已经能用for循环加字典做基本统计，不需要把这套技能全盘否定。真正要做的，是在下一次统计任务里，有意识地用pandas做一版对照。我建议你做一个具体的小练习：1.从公司里拿一份有至少10万行的数据，内容无所谓。2.先用你熟悉的for循环方式，按一个字段做统计，记录运行时间。3.再用pandas的groupby做同样的统计，也记下运行时间。4.对比两段代码的长度和可读性，把你自己的感受记下来。做过一次以后，你会发现，pandas的groupby并不是神奇魔法，而是把你一层层嵌套的字典和循环，压缩成一个更高层的操作。时间越长，差距越明显。三、实验三：print能看到数字，可视化才能看见问题说句不好听的，很多人学完Python数据分析，在调试阶段依然停留在“狂print”的水平。数据清洗完了，怀疑里面有异常值或奇怪分布，就加一堆print(df.head)、print(df.describe)、print某个字段的top10。屏幕上滚满了数字，问题却跑偏。这节我们做一个“print调试”和“可视化检查”的对照实验，看看同样面对一份有异常值的数据，图表和文本输出的差别到底有多大。错误做法A：print输出一地数，看不见异常形状还是那份大促订单的例子，这次我们关注的是客单价（订单金额除以订单商品数量），希望检查是否存在异常订单，比如价格极低或者极高，或者集中在某种奇怪的区间。小林的做法非常典型，他先加了几句describe，看看客单价的统计摘要：count、mean、std、min、25%、50%、75%、max。然后又输出了几个分位数的结果。比如他看到max是99999，心里大概知道“有极端高价”，但他不知道这些高价是集中在一个区间，还是只是几条脏数据。也无法直观看到大部分客单价是在几十块、几百块，还是别的范围。他又写了两段print：1.打印客单价最高的前100条订单。2.打印客单价最低的前100条订单。结果是屏幕上刷出几百行记录，他凭肉眼扫了一遍，大致感觉有一些特价订单是0元（赠品），还有几笔99999的测试订单，但他无法判断0元订单是普遍存在的促销策略还是标错价，无法估计比例，也无法让业务方一眼看懂问题。数字太多。图景太少。更现实的问题是，一个屏幕不可能容纳300万条记录的整体形状，print再多只能看局部。你很容易误判整体分布，比如明明大部分客单价集中在50-200之间，你恰好print看到的是几条代购订单在800-1000之间，就会以为“价格挺高”。正确做法B：用可视化让异常自己跳出来我让小周用Python数据可视化工具（比如matplotlib或seaborn）画了一张简单的客单价分布图。搞一个hist或boxplot就足够。他做的事情非常简单：1.对客单价字段做了一次清洗，去掉明显的无穷大或NaN。2.用直方图画出客单价的频数分布。3.再用箱线图画了一遍，观察长尾和离群点。整个过程写代码不超过10行，执行时间几乎可以忽略。图出来后，问题瞬间清晰：1.80%以上的订单客单价集中在50-300元区间，峰值在100元左右。2.另外大约有10%的订单客单价在0-10元之间，这一块组成了一个“异常小值山峰”。3.有极少数订单客单价超过5000，视觉上可以看到几个非常明显的离群点。他们把这张图截屏发给业务同事，得到的反馈是：“0-10元那块是我们的新人红包和老客返现活动，没问题。”“5000元以上的订单，是几个货币单位标错的记录，确实需要清理掉。”同一份数据，用print输出的方式，小林折腾了大约40分钟，写了几次过滤再print，反复看日志；用可视化的方式，小周用了15分钟生成图，花5分钟开会讨论，半小时之内定位问题并确认哪些数据需要剔除。时间差距不算夸张，但认知差距巨大。可视化的真正价值，不是漂亮。是让人脑用图像处理信息，而不是靠记忆一堆数字。量化一下这组对照的收益同样的“检查客单价异常”的任务：纯print日志调试方案A：写describe+head+tail+过滤print耗时约40分钟异常数据定位不完全，需多轮沟通可视化检查方案B：写分布图和箱线图耗时约20分钟异常原因一目了然，一次沟通解决时间节省大概在50%左右，但更关键的是沟通成本：业务方看数字表会发懵，看图就能自然理解哪一块是“正常业务逻辑”，哪一块是“技术出错或者测试残留”。Python数据的图表，就是团队内部的共同语言。你可以立刻做的小练习下次你再做Python数据分析，拿到某个关键指标，比如订单金额、用户停留时长或者点击次数，别急着print前几行。先做两件事：1.用describe看一眼基本统计指标，记住min、max、mean、std。2.立刻用直方图画出这个指标的分布，再加一张箱线图。然后问自己三个问题：大部分数据集中在哪个区间？有没有明显的第二个峰值？有没有长尾和离群点？只要你连续做三次这样的练习，就会养成一个新的习惯：遇到不确定的数据先画图，再讨论结论。你的Python数据分析能力会自然跟着提升。四、实验四：默认图和定制图，结论一样说服力完全不同很多人一说“可视化”，脑子里想到的是“plt.plot(df['日期'],df['销量'])”或者pandas自带的df.plot。代码确实很短，可作出来的图在老板眼里就两个字：丑且难懂。事实是，同样一组Python数据结论，用默认图表达出来，和用精心设置颜色、标签、注释之后的图，传达效果完全不同。这不仅影响你有没有被夸“会分析”，也直接影响你的方案能不能被采纳。这一节我们做一组报告场景的对照实验：A方案用默认图，B方案用定制图，看看会议上反馈差异。错误做法A：默认plot，信息没错但没人想看故事还是发生在那个运营团队，这次他们做的是一个季度复盘报告，需要展示过去三个月每天的订单量，并突出两个节点：促销活动和系统故障的日期。小林负责准备图表，他用的是最标准的套路：pandas把日期设为索引，然后一个df['订单量'].plot搞定，再存成PNG插入PPT。这张图的数据没问题：横轴是日期，纵轴是订单数量。线条颜色是默认的蓝色，背景是白色。没有标题，没有标注，没有纵轴单位说明。在部门周会上，他翻到这页PPT时，前排的人还在看手机，后排的人只能看到一根起起伏伏的蓝线，没有任何标记。经理问他：“促销那两天表现怎么样？”他只好用激光笔在屏幕上来回晃，说“就大概这附近”。你能想象那画面。信息在，信号丢。会后经理跟我说，这图其实也不是错，只是看起来像随便拖了一张系统截图出来，对业务问题没有“指着鼻子说”的力量。正确做法B：定制图，把你想说的结论用图说完我让小周用同样的数据做了另一版图。基础也是pandas和matplotlib，只是多加了几步：1.设置合适的图像大小，保证在PPT上看清细节。2.给图加上简洁的标题，比如“Q2每日订单量走势（标注促销和故障节点）”。3.用灰色细网格线提高可读性。4.将促销活动的日期段用浅绿色背景标出，将系统故障那天用红色竖线标记。5.在这几个关键节点上添加文字注释，比如“618大促，订单量为平日3.5倍”、“系统故障，损失订单约1.2万”。6.对纵轴加上单位说明，例如“订单量（单）”。画出来之后，即便离屏幕较远的人，都能一眼看到两个事实：1.促销期间订单量显著抬升，峰值是日常平均的3.5倍。2.系统故障那天订单量断崖式下滑，显然是技术问题导致的损失。部门经理在看这张图时，顺势就提出了两个决策建议：“下个季度我们继续加强促销当天的供应链保障，再试着延长促销尾巴。”“系统故障那天的损失，要跟技术部一起复盘，看看能不能加个自动切换机制。”同一个数据，这张定制图在会议上引发了10分钟的讨论，而那张默认图只引来了一个问题和两句尴尬解释。说直白一点：定制图不是美化，是在帮你把话说完。量化这一组差异我们把这次图表制作的成本和效果，用更具体的方式比较一下：默认plot方案A：画图代码约2行制作时间约3分钟会议中被提问次数：1次引发讨论时长：约1分钟后续行动项：0项定制图方案B：画图代码约15行制作时间约20分钟（包括调试样式）会议中被提问次数：4次引发讨论时长：约10分钟后续形成明确行动项：2个20分钟的额外投入，换来的是一次更高质量的讨论和两个落地的行为改变。这种投入产出的比例，在任何团队里都是划算的。更重要的是，一旦你在Python数据分析中养成了“为结论量身定制图表”的习惯，写图的那十几行代码，可以复制到后续的项目里反复使用。你做得越多，成本越低。你现在可以做的一件小事下一次你准备任何形式的汇报，不管是项目复盘还是运营报告，只要涉及Python数据，挑一张最关键的图，别用默认plot，花15分钟给它做一次定制化：1.加一个说人话的标题，直接写结论倾向。2.标出一个或两个关键节点，用颜色或注释说明为什么重要。3.给坐在最后一排的人准备一目了然的视觉线索。只做这一件事，你就会发现你在会议上的话语权，会悄悄多一点。五、实验五：一体化Python脚本，对抗多工具来回导出的碎片流程很多团队现在的“数据分析流程”是一条很长的流水线：从数据库导出CSV，用Excel清洗，再导回CSV给Python跑模型，然后再把结果导回Excel画图，最后把图截图贴进PPT。每切一次工具，就多一次出错和对不齐版本的机会。这一节我们做一组完整流程的对照：A方案是多工具拼接，B方案是Python中一体化完成“读数据-清洗-分析-出图”的链路。错误做法A：工具链越长，沟通成本越高去年双十一前夕，某电商项目做了一次用户留存分析，涉及的Python数据链路大致是这样：数据库工程师：用SQL从数仓导出用户行为明细，导出为4个CSV，每个约200MB。数据分析师：收到CSV后，先用Excel打开，删掉他认为“用不到的列”，顺手做了一些筛选和排序，再保存为新的CSV。然后用Python脚本读新的CSV，做留存分组、建模和预测。业务运营：拿到分析结果后，让分析师导出一份Excel，自己用Excel画图做PPT。这个流程看起来有人分工协作，实则问题一堆：1.数据在SQL端一份，在Excel端一份，在Python脚本里又一份，每一次导出/导入都是一次潜在的不一致。2.每当需求变动，比如领导说再加一个新指标，工程师要改SQL，分析师要重新走一遍Excel清洗，再重跑Python代码。3.带来的累积时间成本非常夸张。一次完整迭代，从改SQL到出图，平均要花2天。我帮他们算过一次时间：一次留存模型迭代：数仓导出：约2小时（排队+执行）Excel人工整理：约3小时Python建模和调参：约4小时Excel画图和写PPT：约3小时合计大约12小时，这还不算中间来回确认字段含义的时间。如果一个项目周期中需要迭代4次，流水线上所有人被这个流程“锁住”的总工时就在48小时以上。里面浪费的部分太多。正确做法B：Python内一条龙，从源到图不落地我和那支团队一起做了一次流程改造。核心的目标是：能不能尽量让数据从数据库出来之后，直接进入Python，所有清洗、分析和可视化都在同一个环境里完成，而不再落地到Excel做中间站。改造之后的流程是这样的：1.数据工程师提供一个只读的数据库连接账号，分析师可以在Python里直接用SQLAlchemy或类似库执行SQL，得到pandasDataFrame。2.数据清洗逻辑从Excel的点点点，迁移到Python脚本中（用pandas做字段选择、缺失处理、类型转换等），整个清洗过程可复现。3.分析脚本在同一份Notebook里，清洗完的DataFrame直接传入留存分析函数，无需导出导入。4.可视化部分用Python的matplotlib/seaborn或plotly输出图表，可以直接保存为高分辨率图片给PPT使用。我们对比了一次完整迭代的时间：一体化Python流程B：Python中执行SQL读数据：约1小时（包括调试SQL）pandas清洗：约1小时建模和调参：约4小时Python直接出图：约1小时合计大约7小时，比原来12小时减少了5小时，缩减幅度约为42%。四轮迭代下来，整项目节省了20小时的工时。时间还不是唯一收益。更重要的是，这套一体化脚本留下了完整的“分析轨迹”——从原始SQL到清洗逻辑到建模步骤再到出图命令，全都在一个Notebook里按顺序写清楚。新来的同事只要按Shift+Enter从头跑到尾，就能重现实验结果。错误更容易被定位，发现也更早。这组对照给你的操作建议如果你现在的工作流程还是“SQL导出CSV给Excel，Excel再导出给Python”，可以尝试做一个小步迁移：先把Excel这个环节挪掉。你可以试试这样做：1.让工程师帮你确认数据库的连接方式，在Python里直接连库。2.把你当前在Excel中做的那些筛选和字段删除，逐步用pandas脚本实现。3.先保留最后“Excel画图”这一步不动，让自己有个缓冲时间。当你熟悉了Python数据全链路处理之后，再把可视化也迁移到Python里。这样你一口气不会换掉太多习惯，摩擦也会小很多。六、实验六：Notebook和纯.py文件，在项目协作中的差异到这里，你已经看到了Python数据链路从清洗到分析到可视化的几个关键节点。最后一个问题是：在实际项目协作中，用什么形式组织你的代码和分析过程更合适？很多团队要么全用JupyterNotebook，要么全用纯.py脚本，各有优缺点。这节我们用一个团队协作的例子，来做Notebook方案A与.py方案B的对照。错误做法A：Notebook乱飞，复现困难在那个电商项目里，初期大家非常喜欢JupyterNotebook。理由很简单：可以一边写解释文字，一边跑代码，还能直接看到图。看起来非常符合“数据分析报告”的气质。于是他们的项目目录里出现了大量这样的文件名：datacleaningv1.ipynbdatacleaningv2_final.ipynbretentionanalysisnew.ipynbretentionanalysisnew_final.ipynbretentionanalysisnewfinalv3.ipynb你应该也见过这种命名方式。非常真实。Notebook的便利性，在团队规模小、项目简单的时候非常吸引人。但当项目进入第二个月，问题就出现了：1.不同人手上的Notebook版本不一致，有人改了一个清洗逻辑，却没同步给其他人，导致同一张图不同人画出来不一样。2.Notebook因为可以“只跑某几格”，经常出现变量状态不明确的问题。新同事从头运行一遍，报错；老同事从中间某个单元格开始跑，却能成功。3.代码复用性差。每个Notebook里都有一段类似的清洗代码，却没有提炼成函数或模块。我帮他们做了一次统计：某一次留存分析相关的Notebook文件，总共有14个版本，散落在三个人的文件夹里。当需要追溯“具体哪一个版本被用于最终报告”时，他们足足花了一个下午。成本很高。也很心累。正确做法B：.py脚本做“骨架”，Notebook做“展示层”设想另一种工作方式：把Python数据分析项目拆成两层。底层是纯.py脚本，用来放稳定的逻辑，比如数据读取、清洗函数、通用的模型训练代码等。这部分尽量模块化、函数化，对外暴露清晰的接口。上层是Notebook，只做两件事：调用底层脚本里的函数，传入不同参数；展示分析过程和结论，包括图表和解释文字。在那个电商项目中，我们把原来分散在各个Notebook里的清洗逻辑，抽成了一个叫data_pipeline.py的模块，里面包括：loadrawdata：从数据库或文件读取原始数据。cleanbasicfields：做基