ray 的 ray.remote 默认返回 objectref 是因异步设计，需用 ray.get() 获取真实结果；dask delayed 链式调用出错多因依赖图异常；二者 map_partitions 行为差异在于 dask 保留分区结构而 ray 不保证顺序；本地启动失败常因端口冲突或环境问题。
Ray 的 ray.remote 函数为什么总返回 object ref 而不是真实结果？
因为 ray.remote 默认异步执行，返回的是一个未来对象（ObjectRef），不是值本身。直接 print 会看到类似 ObjectRef(01000000ffffffffffffffff...) 的东西，不是 bug，是设计使然。
- 要拿到真实结果，必须显式调用
ray.get()—— 比如ray.get(future)，否则永远拿不到计算值 - 如果函数返回多个值（如
return a, b），ray.get()返回的是元组，不是解包后的变量，别漏了括号 - 在 driver 进程里混用同步逻辑时，容易忘记加
ray.get()，导致后续代码传入 ref 而非数据，报错如TypeError: unsupported operand type(s) for +: 'ObjectRef' and 'int' - 调试时可临时加
print(ray.get(future))，但生产环境避免频繁调用ray.get()阻塞调度器
Dask Delayed 为啥链式调用后 .compute() 报 KeyError 或卡住？
常见于依赖图构建错误：比如变量名重复、闭包捕获了不可序列化的对象（如文件句柄、本地线程锁）、或 delayed 套嵌过深没触发实际调度。
- 确保所有被
@delayed装饰的函数只依赖明确传入的参数，不读取外部作用域的 mutable 对象（如全局 list、class 实例） - 避免在
delayed函数内部调用dask.delayed(...).compute()—— 这会在 worker 进程里试图启动新 scheduler，直接死锁 - 检查
client = Client(...)是否已启动；没连集群时.compute()会 fallback 到单机线程池，但某些 IO 密集任务仍可能因资源争抢卡住 - 用
task_graph = delayed_func.visualize()看 DAG 图，能快速发现断开的边或孤立节点
Ray 和 Dask 在处理 Pandas DataFrame 分片时，map_partitions 行为差异在哪？
两者都支持分片处理，但语义和容错机制完全不同：Dask 的 map_partitions 是 lazy 的，且默认保留分区结构；Ray 的 ray.data.map_batches（对应功能）则强制重分区、无状态、不保证顺序。
- Dask：
df.map_partitions(lambda part: part.assign(x=part.a * 2))中，part是真实pandas.DataFrame，可任意操作，且输出 shape 必须与输入一致（否则需配meta=...） - Ray：
ds.map_batches(lambda batch: batch.assign(x=batch["a"] * 2), batch_format="pandas")中，batch是 pandas DataFrame，但整个 pipeline 不维护索引连续性，下游无法做.loc精确切片 - 若原始数据有时间索引并需按时间窗口聚合，Dask 更稳妥；若只是 ETL 清洗+写入对象存储，Ray 吞吐更高但得自己 handle 分区边界
- 二者都不建议在 map 里打开数据库连接——Dask 会复用 worker 进程，Ray 默认每个 task 新启进程，连接泄漏风险更大
本地开发时 ray.init() 和 Client() 启动失败，常见原因是什么？
不是端口冲突就是环境隔离问题。Ray 默认绑定 localhost:6379（Redis），Dask Client 默认连 localhost:8786，但很多本地工具（如 Docker Desktop、Homebrew Redis）已占用了这些端口。
- Ray 启动失败常见错误：
ConnectionError: Unable to connect to Redis...→ 改用ray.init(ignore_reinit_error=True, log_to_driver=False)并加address="auto"让它选空闲端口 - Dask Client 连不上：
OSError: [Errno 61] Connection refused→ 先运行python -m dask.scheduler确认 scheduler 起来了，再Client("tcp://localhost:8786") - Mac M1/M2 用户注意：Ray 2.9+ 才原生支持 arm64，旧版本装
pip install "ray[default]" --force-reinstall --no-deps可能缺 wheel，直接报ImportError: dlopen(...libraylet.dylib): no suitable image found - 虚拟环境里混装 conda/pip 包容易导致 protobuf 版本冲突，表现为
AttributeError: module 'google.protobuf.descriptor' has no attribute 'MakeDescriptor'，统一用 pip 重装protobuf==3.20.*通常能解
事情说清了就结束。真正麻烦的从来不是怎么启动，而是当任务跑在 50 个 worker 上开始 shuffle 数据时，你才发现某台机器的 ulimit 没调、磁盘快满了、或者某个 lambda 函数悄悄把整个 DataFrame 加载进了闭包。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
