0

我想将气流用于以下用例：

  • 计算给定网站的每日报告（大约 150 个要处理的网站）。每个报告将按如下方式计算：
    • 应在站点级别运行的一组任务，
    • 应在页面级别运行的一组任务，每个网站包含约 10k 个页面。
    • 执行上述两组任务后，将运行第三组任务以汇总结果并生成报告。

注意：这里描述的每个气流任务实际上都是对远程微服务的简单调用（grpc 调用）。

到目前为止我想到的设计：

  • 我最初想在一个任务中执行与页面相关的所有进程，以便拥有一个简单、定义明确的 dag，只包含几个任务。但是需要在页面上执行的处理很复杂，有外部依赖和队列（只有在收到来自外部系统的通知时才会触发下一个任务，那些通知可能会在几个小时后到达）=> 我想使用气流来处理这个过程。
  • 鉴于上述观点，我现在倾向于一种模型，即一个网站的所有流程都嵌入到一个 dag 中，包括页面的任务。理想情况下，我想为与页面相关的任务使用 subdag，但从我目前阅读的内容来看，这个功能还不稳定。每个网站都会生成一个新的 dag，带有一组新的任务（因为 dag 的结构取决于页数）。因此，每个 dag 的任务数将相对重要（10k）。

我的问题：

  • 对于这个用例，气流是一个可接受的框架（即你是否运行过类似的用例），还是像 luigi、oozie 这样的替代框架......在这种情况下具有明显的优势？
  • 上面的方法（每个网站一个 dag，没有 subdag，在 dag 中包含页面任务）是否合理？你预见到这有什么问题吗？
  • Web ui 是否仍可用于该数量的任务？我对数百个任务进行了快速测试，但遇到了几次超时，我想知道它是否与我的配置相关联。
  • 芹菜是正确的后端吗？我想知道“LocalExecutor”实际上是否更适合这个用例，因为气流工作人员实际上没有直接执行计算（他们只调用远程服务）。
4

1 回答 1

0

你最初的想法是我会选择的。拥有 150 个不同的工作流和 10K 个任务，每个都会导致完全动态且难以管理的场景。一方面您说每个任务只是一个简单的 gRPC，但同时您提到页面级任务在单个任务后面封装起来非常复杂，并且存在可能导致以小时为单位的流量瓶颈的外部依赖关系。

如果我是你，我会重新设计解决方案并将页面级报告转移到不同的层。例如，创建一个可以执行所有这些复杂计算的服务将是一个比尝试在 Airflow 中实现它更好的选择。这样，您可能会显着减少页面级任务的数量。

关于您的具体问题：

  • 气流与案例无关 - 根据设计，每个场景都可以是完美的。Oozie 非常老派且笨重，缺乏 Airfow 提供的大量集成功能。路易吉我没用过。
  • 如前所述，这种方法是不可预测的，同时也是难以管理的。我预见到混乱:)
  • 获得悬挂式 UI 是一个很好的指标，表明您应该重新审视您的实现设计。但是 UI 应该是您的第一个关注点 - 您如何在单个工作流程中监控和管理 10,000 个任务？正确 - 你不能。再乘以 150。
  • 不久前，我从一家公司读到一篇文章，他们在使用 Celery 进行横向扩展时遇到了问题，他们决定改为纵向扩展并在同一 VM 上并行运行许多调度程序进程。不太确定这是否会显着有益于您的方案。

如果我是你，我会为所有 150 个站点设置一个工作流程。我会为每个网站创建一个子标签（顺便说一句，官方文档中没有提到“不稳定”这个词）并尝试将复杂的计算操作卸载到不同的层，以减少页面级任务的数量尽可能。

于 2018-07-28T07:00:48.137 回答