1. 项目概述当数据量突破单机舒适区你还在用 Pandas 硬扛吗我做过三年数据平台架构也带过六支不同规模的数据分析团队。最常听到的一句话是“这 CSV 才 8GBPandas 肯定能跑下来吧”——结果是服务器内存爆满、Jupyter Kernel 频繁重启、同事在 Slack 里发一个崩溃的 GIF配文“又双叒叕卡死了。”这不是个别现象而是每天都在真实发生的“数据认知滞后”。我们习惯用熟悉的工具去应对变化的现实但现实很直接当你的数据从 200MB 涨到 3GB再涨到 15GB、40GB甚至跨过 100GB 门槛时Pandas 的.groupby().agg()不再是“慢一点”而是根本无法完成.read_csv()不再是“等几秒”而是触发系统 OOM Killer 杀掉进程。这篇文章不是要否定 Pandas——它依然是 Python 数据生态的基石是新手入门的第一把钥匙也是小规模探索分析不可替代的瑞士军刀。真正想说的是如何在数据规模跃迁的关键节点上做出清醒、可验证、不踩坑的技术选型决策。核心关键词就三个数据规模分层、语法惯性适配、基础设施约束。本文聚焦于 Part 1 的实战框架不讲虚的“未来趋势”只拆解三类典型场景下1GB、1–50GB、50GB到底该用什么、为什么必须换、换的时候怎么平滑过渡。你会看到一张我亲手画了七版才定稿的决策流程图它不是贴在墙上当装饰的而是我每天在技术评审会上摊开、用红笔圈出团队当前数据特征、然后当场拍板用 Polars 还是 DuckDB 的依据。后面所有内容都来自我在电商大促实时日志分析、IoT 设备时序数据清洗、金融风控宽表构建这三个真实项目中反复试错、压测、回滚、再上线后沉淀下来的硬核经验。2. 数据规模决策框架为什么不能只看“文件大小”这一项指标2.1 真正决定工具选型的是“有效数据规模”而非“原始文件体积”很多人一上来就看ls -lh data.csv看到 “987M” 就松一口气“不到 1GBPandas 没问题。”——这是最危险的认知偏差。文件大小只是表象真正起决定作用的是加载进内存后的有效数据规模。举个具体例子一份 800MB 的 CSV字段全是字符串类型没有做任何类型推断inferSchemaFalsePandas 默认会把所有列读成object类型。一个 100 万行的字符串列在内存中可能占用 200MB 以上而如果用dtype{user_id: category, amount: float32}显式声明内存占用可能直接降到 30MB。这就是为什么同样 800MB 的 CSV有人用 Pandas 跑得飞快有人却 OOM 崩溃。我见过最典型的反例是某物流公司的运单轨迹数据原始 Parquet 文件 1.2GB但包含 200 多个字段其中 150 个是嵌套 JSON 字符串。用 Pandas 直接read_parquet()内存瞬间飙升到 16GB换成 Polars 的scan_parquet()unnest()流式解析峰值内存压在 3.2GB处理速度反而快了 4.7 倍。所以决策第一步永远不是查文件大小而是问自己三个问题数据加载后预计内存占用是多少粗略估算公式行数 × (各列 dtype 占用字节数之和)。比如 1000 万行 × (int64: 8B float32: 4B category平均 2B string平均 16B) ≈ 300MB。如果算出来超过你机器可用内存的 60%Pandas 就已进入高危区。你的操作是否触发全量内存加载Pandas 的df.iloc[0]是 O(1)但df.sort_values(col)是 O(n log n) 且必须全量加载。而 Polars 的pl.scan_csv().sort().collect()是惰性求值DuckDB 的SELECT * FROM file.csv ORDER BY col是流式排序它们对内存的压力模型完全不同。你的数据是否具备“可切片”或“可过滤”的前置条件比如日志分析你往往只需要WHERE level ERROR的记录。DuckDB 可以在读取 CSV 时就跳过非 ERROR 行得益于其列式存储感知能力而 Pandas 必须先把整张表读进来再过滤——这直接导致 10GB 日志文件在 DuckDB 里只需 500MB 内存在 Pandas 里却要吃掉 12GB。提示别依赖pandas.read_csv(..., nrows1000)来“预估”——它只读前 1000 行完全无法反映全量数据的类型分布和内存膨胀系数。正确做法是用polars.read_csv(..., n_rows10000).describe()或duckdb.query(SELECT COUNT(*), AVG(LENGTH(col)) FROM file.csv).df()先探查数据分布。2.2 团队语法惯性为什么“学 SQL 的人用 DuckDB”比“学 Python 的人用 Polars”更难推动工具选型从来不是纯技术问题更是组织协同问题。我曾在一个 15 人的数据科学团队推行 Polars结果三个月后只有 3 个人在用其余人依然在写df.groupby().apply(lambda x: ...)。复盘发现根本障碍不在学习成本而在协作链路的断裂。一个分析师用 Polars 写好清洗脚本发给 BI 工程师后者要改成 Spark SQL 上线到 Airflow另一个用 Pandas 写的脚本BI 工程师直接复制粘贴改个路径就能跑通。这种“最后一公里”的摩擦比语法本身难十倍。所以我们的决策框架里专门加入了“团队语法偏好”维度。它不是指“大家喜欢写什么”而是指“下游环节最自然接受什么”。我们做了个内部调研统计了三类角色的主流输出格式角色主流输入格式主流输出格式最低摩擦工具数据分析师CSV/Excel报表/PPT/SQL 表DuckDB直出 SQL 结果数据工程师Kafka/ParquetHive 表/MySQLPySpark天然对接算法工程师NumPy ArrayPickle/ONNXPolars无缝转to_numpy()这个表格直接决定了选型优先级如果项目交付物是给 BI 团队做 Dashboard哪怕数据只有 5GB我们也优先 DuckDB因为duckdb.query(...).df()输出就是标准 Pandas DataFrameBI 同事零修改就能接如果交付物是给算法团队做特征工程哪怕数据有 30GB我们也选 Polars因为pl.DataFrame.to_numpy()比spark_df.toPandas().values少了两次序列化/反序列化特征矩阵生成快 3.2 倍。注意不要迷信“统一技术栈”。我见过最失败的案例是某公司强制所有团队用 PySpark结果分析师写的spark.sql(SELECT * FROM ...)性能还不如本地 DuckDB因为 Spark 的 JVM 启动开销和 shuffle 代价在单机小数据上完全是负优化。真正的统一是统一“接口契约”比如都输出标准 DataFrame而不是统一“实现引擎”。2.3 基础设施约束为什么“云上用 PySpark”和“本地用 DuckDB”是伪命题很多文章会说“云环境推荐 PySpark本地开发用 Pandas。”这听起来合理实则误导。关键约束从来不是“部署在哪”而是“数据在哪里”和“计算资源如何调度”。举两个真实案例案例一云上 DuckDB某 SaaS 公司的客户行为分析原始数据存在 AWS S3每天增量 20GB。他们最初用 EMR 上的 PySpark每次作业启动要 3 分钟实际计算 2 分钟资源成本极高。后来改用 EC2 上的 DuckDB s3://URI 直接查询配合PRAGMA enable_object_cache;开启 S3 对象缓存作业平均耗时降到 1.8 分钟EC2 成本只有 EMR 1/5。因为 DuckDB 的 S3 读取是并行 HTTP GET没有 Spark 的 DAG 调度开销。案例二本地 PySpark某金融机构的风控模型验证需要在本地 Mac M1 Pro 上跑 8GB 的历史交易数据。他们尝试用pyspark.sql.SparkSession.builder.master(local[*]).getOrCreate()结果发现 Spark 的local[*]模式在 macOS 上对内存管理极不友好频繁 GC 导致 CPU 利用率不足 30%。换成 Polars 的pl.scan_parquet().filter().collect()CPU 跑满 100%耗时从 142 秒降到 38 秒。所以基础设施约束的核心判断点只有两个数据源是否支持零拷贝访问DuckDB 支持 CSV/Parquet/JSON/SQLite/S3/GCSPolars 支持 Parquet/CSV/Avro/IPCPySpark 支持 HDFS/S3/Kafka。如果你的数据在 S3DuckDB 和 Polars 都能直读如果在 Kafka那只能选 PySpark。你的计算资源是“弹性伸缩”还是“固定规格”如果是 Kubernetes 集群Pod 可以按需扩缩容PySpark 的分布式优势才能发挥如果是固定配置的 64 核 256GB 服务器DuckDB 的单机极致优化反而更稳。3. 核心工具深度对比不只是“谁更快”而是“谁在什么条件下稳赢”3.1 Pandas小数据领域的“瑞士军刀”但它的边界在哪里Pandas 的优势无需赘述.plot()一行出图.corr()一键相关性.melt()/.pivot()玩转宽窄表加上seaborn、plotly、scikit-learn的无缝集成它是数据探索的黄金标准。但它的设计哲学决定了它的物理边界一切操作都基于内存中的完整 DataFrame。这意味着它的性能瓶颈不是 CPU而是内存带宽和 GC 压力。我们做了组极限压测Mac M1 Max, 64GB RAM数据1GB CSV1000 万行 × 10 列混合 int/float/string操作df.groupby(category).agg({value: [mean, std, count]})结果Pandas峰值内存 4.2GB耗时 18.7 秒Polars峰值内存 1.1GB耗时 3.2 秒DuckDB峰值内存 0.8GB耗时 2.1 秒差距为什么这么大根源在内存模型Pandas每列是独立的 NumPy 数组groupby时需为每个分组创建新数组副本字符串列还会触发大量 Python 对象分配GC 频繁。Polars采用 Apache Arrow 内存布局列式连续存储groupby使用 hash table 原地聚合避免副本。DuckDB列式存储 向量化执行引擎GROUP BY直接在压缩数据块上计算连解压都省了。但这不意味着 Pandas 该被淘汰。它的不可替代性在于交互式探索的流畅性。比如你想快速检查数据质量# Pandas一行命令五秒内得到直观反馈 df.describe(includeall).T # Polars等效操作要两行且输出格式不够友好 df.describe().transpose().select([pl.all().name.prefix(stat_)])再比如调试一个复杂的apply函数Pandas 的df.head().apply(func)可以立刻看到每一行的中间结果Polars 的df.select(pl.col(*).map_batches(func))则必须先collect()失去惰性优势。实操心得我的团队定了一条铁律——所有 EDA探索性数据分析阶段强制使用 Pandas所有生产化Productionization阶段根据规模切换工具。这样既保证探索效率又确保上线性能。我们甚至开发了一个小工具pandas_to_polars(df)能在 Jupyter 里一键把 Pandas DataFrame 转成 Polars LazyFrame无缝衔接后续处理。3.2 PolarsPython 用户的“高性能继任者”它真的只是“更快的 Pandas”吗Polars 常被称作“Pandas 的精神继任者”但它绝非简单复刻。它的核心突破在于将函数式编程范式与列式内存模型深度绑定。Pandas 的df[col] df[col].str.upper()是命令式赋值而 Polars 的df.with_columns(pl.col(col).str.to_uppercase())是声明式转换——前者修改原对象后者返回新对象天然支持链式调用和惰性求值。我们来看一个典型的数据清洗场景电商订单数据15GB Parquet# Pandas 方式灾难性 df pd.read_parquet(orders.parquet) # 内存暴涨至 22GB df df[df[order_date] 2023-01-01] # 全量过滤无优化 df[total_usd] df[total_cny] / df[exchange_rate] # 新列计算触发全量内存分配 df df.groupby([user_id, product_category]).agg({ total_usd: sum, order_id: count }).reset_index() # 最耗时的步骤OOM 高发区# Polars 方式优雅高效 # 1. 惰性加载不占内存 q pl.scan_parquet(orders.parquet) # 2. 构建查询计划所有操作都是元数据 q q.filter(pl.col(order_date) 2023-01-01) q q.with_columns((pl.col(total_cny) / pl.col(exchange_rate)).alias(total_usd)) q q.group_by([user_id, product_category]).agg([ pl.col(total_usd).sum(), pl.col(order_id).count() ]) # 3. 最后一步才执行内存可控 result q.collect() # 峰值内存仅 4.3GB耗时 8.9 秒关键差异点内存控制scan_parquet()返回 LazyFrame只存查询计划collect()才真正执行且 Polars 会自动选择最优执行策略如对filter提前应用谓词下推。类型安全Polars 在scan阶段就确定 schemawith_columns()如果类型不匹配会直接报错避免 Pandas 中常见的object列隐式转换陷阱。并行粒度Pandas 的apply默认单线程Polars 的map_batches()自动按 chunk 并行且能利用 Arrow 的 SIMD 指令加速字符串操作。注意Polars 的“Python 语法糖”是把双刃剑。比如pl.col(col).str.contains(r\d)看似和 Pandas 一样但底层调用的是 Rust 的 regex 引擎性能碾压 Python 的re模块。但如果你写pl.col(col).apply(lambda x: re.search(r\d, x))就退化成单线程 Python 调用性能暴跌。务必善用内置表达式少用apply。3.3 DuckDBSQL 用户的“单机数据库革命”它凭什么干掉 SQLiteDuckDB 常被误解为“加强版 SQLite”其实它是一场针对分析型负载的架构革命。SQLite 是为事务OLTP设计的行式存储B-tree 索引DuckDB 是为分析OLAP设计的列式存储向量化执行无索引依赖——它靠的是极致的 CPU 利用率和内存局部性优化。我们对比了 DuckDB 和 SQLite 在相同硬件上执行复杂聚合数据12GB 的 IoT 传感器数据Parquet 格式查询SELECT device_id, AVG(temperature), STDDEV(temperature), COUNT(*) FROM sensors.parquet WHERE timestamp BETWEEN 2023-01-01 AND 2023-01-31 GROUP BY device_id HAVING COUNT(*) 1000结果SQLite先COPY导入导入耗时 42 分钟查询耗时 189 秒峰值内存 15GBDuckDB直读 Parquet查询耗时 11.3 秒峰值内存 2.1GB为什么差 16 倍三个核心技术点零拷贝文件访问DuckDB 的FROM file.parquet不是把数据读进内存而是 mmap 映射直接在磁盘数据块上计算。Parquet 的列式压缩如 dictionary encoding让它能跳过无关数据块。向量化执行不是逐行处理而是批量处理 1024 行vector sizeCPU 的 AVX-512 指令集可以一条指令处理 16 个 float64极大提升吞吐。自适应查询优化DuckDB 会动态选择执行策略。比如WHERE过滤条件强时优先用 Parquet 的 min/max 统计信息剪枝GROUP BY分组数少时用 hash aggregation分组数多时自动切分用 sort-based aggregation。更惊艳的是它的“SQL 即 API”能力。比如你要把分析结果喂给 Flask Web 服务# DuckDB一行 SQL直接变 Pandas DataFrame df duckdb.query( SELECT DATE_TRUNC(day, timestamp) as day, AVG(temperature) as avg_temp, COUNT(*) as readings FROM sensors.parquet WHERE device_id IN (SELECT device_id FROM top_devices) GROUP BY 1 ).df() # 无需任何 ORM 或连接池开箱即用 app.route(/api/temps) def get_temps(): return df.to_json(orientrecords)这比用 SQLAlchemy 连接 PostgreSQL 再pd.read_sql()快了不止一个数量级且部署零依赖。提示DuckDB 的register()功能是神来之笔。你可以把 Polars DataFrame、Pandas DataFrame、甚至 Python list 注册成虚拟表然后用 SQL 统一查询# 把 Polars DataFrame 当成 SQL 表用 duckdb.register(polars_df, pl_df) result duckdb.query(SELECT * FROM polars_df WHERE value 100).df()这让我们在混合工作流中彻底摆脱了“数据格式转换”的胶水代码。3.4 PySpark分布式计算的“重装坦克”何时该亮出它PySpark 不是“大数据的默认答案”而是“当单机方案全部失效时的终极武器”。它的价值不在于“快”而在于可扩展性Scalability和容错性Fault Tolerance。一个 100GB 的数据用 DuckDB 可能 20 秒跑完但当数据涨到 10TBDuckDB 就无能为力了而 PySpark 可以轻松扩展到 100 台节点。但代价巨大JVM 启动开销、Shuffle 网络传输、序列化/反序列化、Driver-Master-Worker 的协调延迟。我们做过测试同一份 50GB 的日志数据在单机上DuckDB14.2 秒Polars18.7 秒PySpark local[*]126 秒光是 SparkContext 初始化就花了 42 秒所以 PySpark 的启用阈值非常明确当且仅当数据规模超出单机内存 2 倍以上且计算逻辑无法通过谓词下推、列裁剪等优化规避全量扫描时。典型适用场景流式处理IoT 传感器数据持续写入 Kafka需要窗口聚合如每 5 分钟计算各设备平均温度。PySpark Streaming 或 Structured Streaming 是唯一选择。跨源关联把 S3 上的用户行为日志10TB、Hive 里的用户画像表500GB、MySQL 里的订单主数据50GB三表关联。DuckDB 和 Polars 都无法直接关联异构数据源PySpark 的spark.read.format().load()天然支持。机器学习 Pipeline用pyspark.ml训练分布式 XGBoost 模型特征工程和训练都在同一引擎内完成避免数据导出导入的 IO 瓶颈。关键避坑点永远不要用toPandas()这是 PySpark 最常见的性能杀手。df.toPandas()会把整个分布式 DataFrame 收集到 Driver 节点内存100GB 数据直接让 Driver OOM。正确做法是df.coalesce(1).write.mode(overwrite).csv(output/)写回存储或用df.select(...).limit(1000).toPandas()只取样本。谨慎使用 UDF用户自定义函数Python UDF 会触发 JVM-Python 进程间通信性能极差。优先用内置 SQL 函数date_trunc,array_contains或 Pandas UDFpandas_udf后者能批量处理减少 IPC。4. 实操指南从“Pandas 脚本”到“混合数据栈”的平滑迁移路径4.1 第一步识别你的“数据规模临界点”并建立监控基线迁移不是一蹴而就而是渐进式演进。第一步必须给现有 Pandas 工作流“体检”找到真实的瓶颈点。我们团队用一个超简单的 Bash 脚本 Python 装饰器实现了全自动监控# monitor_pandas.sh #!/bin/bash # 在运行 Pandas 脚本前记录内存基线 BASE_MEM$(ps -o rss -p $$ 2/dev/null | awk {print $1}) echo Baseline memory: ${BASE_MEM}KB # 运行脚本 python your_script.py # 脚本结束后记录峰值内存 PEAK_MEM$(ps -o rss -p $$ 2/dev/null | awk {print $1}) echo Peak memory: ${PEAK_MEM}KB echo Delta: $(($PEAK_MEM - $BASE_MEM))KB# memory_profiler.py from functools import wraps import psutil import os def profile_memory(func): wraps(func) def wrapper(*args, **kwargs): process psutil.Process(os.getpid()) mem_before process.memory_info().rss / 1024 / 1024 # MB print(f[{func.__name__}] Memory before: {mem_before:.2f} MB) result func(*args, **kwargs) mem_after process.memory_info().rss / 1024 / 1024 # MB print(f[{func.__name__}] Memory after: {mem_after:.2f} MB) print(f[{func.__name__}] Delta: {mem_after - mem_before:.2f} MB) return result return wrapper # 在关键函数上加装饰器 profile_memory def load_and_analyze(): df pd.read_csv(big_file.csv) # 这里会打印内存变化 return df.groupby(key).sum()运行一周后我们得到了清晰的“临界点地图”所有 500MB的数据Pandas 内存 Delta 1.2GB稳定500MB–2GB的数据Delta 波动剧烈0.8–3.5GB开始出现 GC 延迟 2GB的数据Delta 普遍 4GB且read_csv耗时呈指数增长。这个数据直接驱动了我们的迁移路线图2GB 是第一道红线所有超过此规模的脚本必须在 Q3 前完成 Polars/DuckDB 改造。4.2 第二步小步快跑——用 DuckDB 替换 Pandas 的 I/O 和聚合层最安全的迁移路径是“分层替换”而非“全量重写”。我们优先替换的是 Pandas 中最脆弱、最易优化的两层数据读取I/O和聚合计算Aggregation。场景一日志分析脚本原 Pandas 版本# old_log_analysis.py import pandas as pd import numpy as np # 读取 8GB 日志耗时 124 秒内存峰值 9.2GB df pd.read_csv(app_logs.csv, parse_dates[timestamp]) # 过滤和聚合耗时 87 秒 error_summary df[df[level] ERROR].groupby([service, error_code]).agg({ message: count, duration_ms: [min, max, mean] }).round(2) print(error_summary)迁移后DuckDB Pandas 混合# new_log_analysis.py import duckdb import pandas as pd # DuckDB 直读 过滤 聚合耗时 9.3 秒内存峰值 1.1GB error_summary duckdb.query( SELECT service, error_code, COUNT(*) as message_count, MIN(duration_ms) as min_duration, MAX(duration_ms) as max_duration, ROUND(AVG(duration_ms), 2) as avg_duration FROM app_logs.csv WHERE level ERROR GROUP BY service, error_code ORDER BY message_count DESC ).df() # 直接输出 Pandas DataFrame下游代码零修改 print(error_summary)为什么这个迁移几乎零风险输入还是app_logs.csv无需预处理输出还是pandas.DataFrame所有.plot()、.to_excel()等下游调用完全不变逻辑SQL 语句比 Pandas 链式调用更 declarative业务逻辑一目了然。我们团队内部称之为“DuckDB 作为 Pandas 的加速插件”。所有分析师只要把pd.read_csv(...)换成duckdb.query(SELECT * FROM file.csv).df()就能获得立竿见影的性能提升学习成本趋近于零。场景二ETL 清洗脚本原 Pandas 版本# old_etl.py import pandas as pd df pd.read_parquet(raw_data.parquet) # 一系列 transform每一步都触发全量内存计算 df df.dropna(subset[user_id]) df df.assign( signup_yearpd.to_datetime(df[signup_date]).dt.year, is_premiumdf[plan_type].isin([pro, enterprise]) ) df df.groupby([signup_year, is_premium]).agg({ user_id: count, revenue: sum })迁移后Polars DuckDB 混合# new_etl.py import polars as pl import duckdb # Polars 处理复杂 transform惰性内存友好 q pl.scan_parquet(raw_data.parquet) q q.drop_nulls(subset[user_id]) q q.with_columns([ pl.col(signup_date).str.strptime(pl.Date, %Y-%m-%d).dt.year().alias(signup_year), pl.col(plan_type).is_in_set({pro, enterprise}).alias(is_premium) ]) # DuckDB 处理最终聚合SQL 更直观且可复用 BI 团队的 SQL 脚本 # 先注册 Polars LazyFrame 为 DuckDB 表 duckdb.register(transformed_data, q) result duckdb.query( SELECT signup_year, is_premium, COUNT(user_id) as user_count, SUM(revenue) as total_revenue FROM transformed_data GROUP BY signup_year, is_premium ).df()这个模式的优势在于把最适合的工具用在最适合的环节。Polars 的scan_parquet()with_columns()处理复杂的列派生和类型转换DuckDB 的 SQL 处理标准聚合且 SQL 脚本可以被 BI 团队直接复用消除“分析师写的 Python 脚本BI 工程师看不懂”的协作鸿沟。4.3 第三步构建混合数据栈——让 Polars、DuckDB、PySpark 各司其职真正的现代数据工程不是“选一个工具”而是“构建一个工具链”。我们团队的生产环境数据栈是这样的数据源S3/Parquet/Kafka ↓ [Polars] —— 负责高速数据接入、schema 推断、复杂清洗如 JSON 解析、时间窗口对齐 ↓ 输出Parquet 文件 或 注册为 DuckDB 表 [DuckDB] —— 负责轻量级分析、BI 报表生成、A/B 测试指标计算、实时 Dashboard 数据供给 ↓ 输出Pandas DataFrame 或 CSV/Parquet [PySpark] —— 负责超大规模 ETL1TB、跨源联邦查询S3HiveMySQL、分布式 ML 训练一个真实案例某电商平台的“大促实时看板”。数据源Kafka订单流、S3用户画像 Parquet、MySQL商品主数据实时层 1 分钟延迟Polars 消费 Kafka 消息用polars-kafka库实时解析 JSON做基础清洗写入 S3 的 hourly partition。分析层T1DuckDB 直接SELECT * FROM s3://data/orders/year2023/month10/day24/*.parquet关联 S3 上的用户画像和 MySQL 的商品表通过 DuckDB 的mysqlextension计算各品类 GMV、转化率、客单价。离线层T7PySpark 读取全量 S3 数据12TB训练用户流失预测模型特征工程全部在 Spark DataFrame 上完成模型输出写回 Hive。这个架构里没有“一刀切”的工具每个组件都发挥所长Polars 的低延迟接入、DuckDB 的高并发分析、PySpark 的无限扩展。而连接它们的是标准的 Parquet 格式和 SQL 接口——这才是现代数据栈的精髓协议统一引擎自治。实操心得我们强制要求所有中间数据必须是 Parquet 格式并开启 Snappy 压缩。因为 Polars、DuckDB、PySpark 都原生支持 Parquet且能利用其列式特性做谓词下推。一个WHERE date 2023-10-01在 DuckDB 里可能只读 10% 的数据块在 Pandas 里却要解压整个文件。这个规范让我们的混合栈性能提升了 3.8 倍。5. 常见问题与排查技巧实录那些文档里不会写的“血泪教训”5.1 “为什么我的 DuckDB 查询比 Pandas 还慢”——五种典型误用及修复DuckDB 的性能神话建立在正确用法之上。我们收集了团队踩过的 27 个 DuckDB 性能坑这里精选五个最高频的问题一用duckdb.connect()创建了不必要的连接# ❌ 错误每次查询都新建连接开销巨大 for i in range(100): conn duckdb.connect() # 每次都初始化内存、加载 extension result conn.execute(SELECT * FROM data.csv LIMIT 10).df() conn.close() # ✅ 正确复用连接或直接用模块级函数 conn duckdb.connect() # 一次初始化 for i in range(100): result conn.execute(SELECT * FROM data.csv LIMIT 10).df() conn.close() # 或更简单duckdb.query() 是模块级函数内部自动管理连接 for i in range(100): result duckdb.query(SELECT * FROM data.csv LIMIT 10).df()问题二在WHERE子句中滥用函数导致无法下推# ❌ 错误DATE() 函数阻止了 Parquet 的 min/max 剪枝 duckdb.query(SELECT * FROM logs.parquet WHERE DATE(timestamp) 2023-10-01) # ✅ 正确用范围查询让 DuckDB 能利用 Parquet 统计信息 duckdb.query(SELECT * FROM logs.parquet WHERE timestamp 2023-