不是必须，但绝大多数情况绕不开；delta lake python sdk 默认用 pyarrow 读取数据，不装会报 modulenotfounderror，仅元数据操作或显式 engine="rust" 可例外。
用 deltalake 读 Delta 表必须装 pyarrow 吗？
不是必须，但绝大多数情况你绕不开。Delta Lake 的 Python SDK（deltalake 包）默认用 pyarrow 做底层数据读取；不装它，DeltaTable.read_table() 或 read_deltalake() 直接报 ModuleNotFoundError: No module named 'pyarrow'。
例外只有两种：纯元数据操作（比如 DeltaTable.version()、DeltaTable.history()），或显式指定 engine="rust" 并只读小量 JSON 元数据——但 Rust engine 当前不支持真正读取 Parquet 数据内容。
-
pyarrow>=10.0.1是最低要求，低于这个版本可能解析不了新版 Delta 的 protocol 字段 - 如果已有
polars，可以搭配engine="rust"试读元数据，但别指望它返回 DataFrame - Windows 用户注意：
pyarrow安装失败大概率是没装 Visual Studio Build Tools，别硬 pip install，用 conda 更稳
read_deltalake() 为什么读出来是 PyArrow Table 而不是 Pandas DataFrame？
因为这是默认行为——deltalake 的设计哲学是“不强绑上层生态”，把转换权留给用户。它返回 pyarrow.Table，你得自己调 .to_pandas() 才能拿到 DataFrame。
这不只是风格问题：直接拿 Table 可以避免一次内存拷贝，对大表更友好；而提前转成 Pandas，会触发 Arrow 到 NumPy 的列式转行式过程，可能吃光内存。
立即学习“Python免费学习笔记（深入）”；
- 想一步到位得加
as_raw=True（仅限 Rust engine）或手动链式调用：read_deltalake(...).to_pandas() - 如果表里有嵌套类型（struct / list），Pandas 默认展平逻辑可能不符合预期，建议先 inspect
schema再决定是否转 - 用 Dask 或 Polars 接入时，别急着转 Pandas——
deltalake返回的 Table 可直接传给dask.dataframe.from_arrow()或pl.from_arrow()
写 Delta 表时 mode="overwrite" 不删旧文件？
常见错觉：以为 mode="overwrite" 就像 Spark 那样自动清理旧数据文件。实际上，Python deltalake 的 write_deltalake() 默认只更新事务日志（_delta_log），旧 Parquet 文件仍留在磁盘上，只是不再被新快照引用。
这会造成“磁盘越写越多”，尤其在频繁 overwrite 场景下。Delta 的“清理”是分离动作，叫 vacuum。
- 写完必须手动调
DeltaTable(...).vacuum(retention_hours=...)，否则旧文件永远留着 -
retention_hours默认是 168（7 天），不能设低于 7 天，除非关掉 retention enforcement（不推荐） - vacuum 不是原子操作，执行中如果有并发读，可能遇到 “file not found” 错误——建议避开业务高峰跑
Delta 表路径含空格或中文，DeltaTable 打不开？
会出错，典型报错是 OSError: Cannot parse URI 或 Invalid path: expected file:// or s3://...。根本原因是底层 Rust 库对非 ASCII 和空格路径解析不健壮，尤其在 Windows 和本地文件系统下。
这不是编码问题，是 URI 规范处理缺陷：空格没被自动 encode，中文路径没被 percent-encode。
- 最简单解法：路径全用英文+下划线，彻底避开空格和中文
- 如果必须用，Linux/macOS 下可尝试把路径用
file://显式前缀 +urllib.parse.quote()编码，例如：file:///home/user/%E4%BD%A0%E7%9A%84%E8%A1%A8 - Windows 上
file:///C:/...格式比C:\...更可靠，但依然不保中文路径一定成功——别赌
Delta 的路径处理在本地场景下就是个灰区，生产环境强烈建议统一走 S3/HDFS/ADLS 这类标准协议，它们对编码的兼容性好得多。
