Python单机处理大数据效率低的根本原因在于pandas等库默认单线程、内存驻留、解释执行；当数据远超物理内存或需跨节点计算时，直接导致卡死、OOM或小时级等待。
Python单机处理大数据时效率低，根本原因不是语言本身，而是pandas等库默认设计为单线程、内存驻留、解释执行——当数据远超物理内存或需跨节点计算时，这些限制直接导致卡死、OOM或小时级等待。PySpark和Dask不是“更快的Python”，而是用不同架构绕过这些限制：一个靠JVM+RDD/SQL抽象调度集群资源，一个用延迟计算+任务图在Python生态内模拟分布式行为。
为什么pandas读10GB CSV会卡住甚至崩溃
pandas的read_csv()默认把整张表加载进内存，且每个字符串列用object dtype存储，实际内存占用常达原始文件的5–10倍。若机器只有16GB RAM，处理8GB以上CSV极易触发系统OOM Killer杀进程；即使勉强加载，后续groupby或merge操作也会因无法并行、缓存不友好而慢到不可接受。
- 别依赖
low_memory=False硬扛——它只是推迟类型推断，不解决内存膨胀 -
dtype必须显式指定，尤其是把int64降为int32、高基数字符串转category - 真正超限（如>50GB）时，分块
chunksize只能缓解IO压力，无法加速计算本身
PySpark适合什么场景：已有Hadoop/YARN集群或需要SQL接口
PySpark本质是Spark的Python绑定，核心优势不在“Python快”，而在把DataFrame操作翻译成DAG，在JVM上由Executor分布式执行。它天然支持从HDFS、S3、Kafka直读，且spark.sql()能复用数仓团队已有的HiveQL逻辑。
- 用
spark.read.csv(..., inferSchema=False)跳过类型推测，手动传schema参数 - 避免
collect()——这是把全量结果拉回Driver，单点瓶颈；改用write.parquet()落盘 - 小文件问题严重：10万个小CSV比1个10GB文件更慢，先用
coalesce(1)或repartition()合并分区
Dask DataFrame更贴近pandas习惯，但要注意调度开销
Dask通过构建延迟执行的任务图（task graph），在单机多核或多台机器上调度计算。API几乎1:1兼容pandas，dd.read_csv()可直接读取分片文件，compute()才真正触发执行。
- 不要对Dask DataFrame直接调用
.head()或.shape——它们会触发部分计算，且结果仍是延迟对象 - 集群模式下，Worker内存必须显式配置：
memory_limit="4GB"，否则默认吃光所有RAM - 与pandas混合使用危险：
df_pandas = ddf.compute()可能瞬间撑爆内存，应优先用to_parquet()持久化中间结果
真正容易被忽略的是数据格式和序列化成本：PySpark默认用Java序列化，Dask用Pickle，两者在跨进程传输大量字符串或嵌套结构时都极慢。上线前务必把输入数据转成Parquet（列存+压缩+元数据），这一步带来的加速往往超过框架切换本身。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
