让我们说我有一个包含URL列表的数据库表，我需要对每个URL进行一次HTTP调用并将其保存到数据库中，这是ETL过程的一部分。
处理单个任务将花费太长时间，因此我想以某种方式并行化。
气流提供了生成动态dag的能力，但一般的建议似乎是DAG的结构不应“太大”地变化。如此看来，由于URL的数量每天都在变化，因此在数据库中每行创建一个任务似乎不是正确的方法。
一种方法是让任务获取当前的URL列表并将其拆分为n个文件，每个文件都是URL的子集。然后，我们有n个任务，每个任务读取一个文件并处理其子集。
这是一个简单，相对稳定的DAG结构，但存在一个问题。一些URL可能需要更长的时间来处理其他URL，从而导致运行时间高度可变。它还不会自动缩放，因此，如果我们每个人都大幅增加或减少URL的数量，则必须修改n。
我看过其他文章，指出人们使用气流来基本定义三个任务：
这似乎有点不幸，因为我们正在使用一个具有分布式计算（Airflow）功能的平台，将计算封送至另一个分布式计算平台。
实际上，当负载每天变化时，人们如何使用气流分配计算量？