Dask 为控制流“计算”还是构建一个完全“延迟”的任务图更好？

我有一个现有的Pandas代码库，刚刚开始尝试将其转换为Dask。我仍在试图将注意力集中在Dask

数据帧

，

延迟

，以及

分布式

。通过阅读

dask.delayed

文档，似乎理想的情况是为我想要做的整个操作集建立一个任务/计算图，包括用户消息的

delayed

函数，然后在最后的一大块中运行所有计算。这样，在Dask集群执行实际工作时，调用进程就不需要继续运行

然而，我一直面临的问题是，似乎有些情况下这是不可行的，尤其是在Python控制流方面。例如：

df=dd.read\u csv（…）
如果df.isnull（）.any（）：
#提前退出
提升值错误（）
df=一些（df）
df=更多（df）
df=计算（df）
#以及可能更复杂的控制流

如果不调用

df.isnull（）.any（）.compute（）

，我真的看不出这样的事情是如何完成的

我现在也不知道在脚本中调用

compute（）

或

persist（）

是否有什么“不好”（与最佳实践相反）。当在线查看大量示例时，它们似乎基于一个实验性的/基于Jupyter的环境，其中

load->preparation->persist（）->experiments

似乎是标准方法。由于我有一组相对线性的操作（

load->op1->op2->…->opn->save

），我认为我应该尽量简单地安排任务，而不做任何计算，尽可能快地避免

compute

/

persist

，我现在觉得这让我有点走到了死胡同

---

总之，我想我有两个问题需要回答，第一个是“使用

compute

”是否不好，第二个是“如果是，我如何避免

compute

，但仍然拥有良好且可读的控制流？”。

在需要具体值时调用compute完全可以。控制流就是一个很好的例子

您可能需要首先在计算的主干上调用

.persist（）

，然后调用

.compute（）

以获取控制流位，以确保不会重复计算的

load->op1->op2->……

部分