大数据是复杂的，我已经写了很多关于广阔的生态系统和广泛的可用选项的文章。 通常被忽略但很关键的一个方面是管理大数据管道的不同步骤的执行。 框架的决定或执行过程的设计经常会推迟到稍后的阶段，从而导致许多问题并延误项目。
您应该尽早设计管道编排，以避免在部署阶段出现问题。 编排应像其他可交付成果一样对待; 所有利益相关者都应该对其进行计划，实施，测试和审查。
编排框架通常被忽略，许多公司最终为其管道实施定制解决方案。 这不仅成本高昂，而且效率低下，因为自定义业务流程解决方案往往会面临现成框架已经解决的相同问题。 造成漫长的反复试验。
在本文中，我将介绍一些最常见的开源业务流程框架。
管道编排
数据管道编排是一个交叉过程，可管理管道任务之间的依赖关系，调度作业等。 如果使用流处理，则需要编排每个流应用程序的依赖关系，而对于批处理，则需要安排和编排作业。
请记住，任务和应用程序可能会失败，因此您需要一种以统一的方式调度，重新调度，重放，监视，重试和调试整个数据管道的方法。
业务流程框架提供的一些功能是：
- 作业调度
- 依赖管理
- 错误管理和重试
- 工作参数化
- SLA跟踪，警报和通知
- 具有仪表板的用户界面，例如甘特图和图形
- 历史和审计
- 元数据的数据存储
- 日志汇总
让我们回顾一下一些选项…
Apache Oozie
Apache Oozie是Hadoop的调度程序，作业创建为DAG，并且可以由基于cron的调度或数据可用性触发。 Oozie是作为Java Web应用程序运行的可伸缩，可靠和可扩展的系统。 它与Sqoop等提取工具和Spark等处理框架集成在一起。
Oozie工作流程定义以hPDL(XML)编写。 工作流包含控制流节点和动作节点。 控制流节点定义工作流的开始和结束(开始，结束和失败节点)，并提供一种机制来控制工作流的执行路径(决策，派生和联接节点)[1]。
动作节点是一种机制，工作流通过该机制触发任务的执行。 Oozie支持不同类型的操作(map-reduce，Pig，SSH，HTTP，电子邮件…)，并且可以扩展以支持其他类型的操作[1]。
同样，可以对工作流程进行参数设置，并且可以同时执行几个相同的工作流程作业。
它是Hadoop的第一个调度程序，非常流行，但是已经有点过时了，如果您完全依赖Hadoop平台，它仍然是一个不错的选择。
Apache Airflow
Airflow是一个平台，可用于计划，运行和监视工作流程。 由于其易用性和创新的工作流作为代码方法，它已成为大数据管道的最著名协调者，其中DAG在Python代码中定义，可以像其他任何可交付的软件一样进行测试。
它使用DAG创建复杂的工作流程。 图中的每个节点都是一个任务，边定义了任务之间的依赖关系。 任务分为两类：
- 操作员：执行一些操作。
- 传感器：检查过程或数据结构的状态。
Airflow Scheduler在遵循您描述的指定依赖项的同时，在一组工作线程上执行您的任务。 它具有模块化架构，并使用消息队列来协调任意数量的工作程序，并且可以扩展到无穷大[2]。
它为您生成DAG，从而最大程度地提高了并行度。 DAG是用Python编写的，因此您可以在本地运行它们，对其进行单元测试并将其与开发工作流程集成。 当工作流定义为代码时，它们变得更加可维护，可版本控制，可测试和协作[2]。
丰富的用户界面可以轻松地可视化生产中运行的管道，监视进度并在需要时对问题进行故障排除[2]。 它快速，易于使用且非常有用。 它具有多种视图和多种方法来解决问题。 它保留了运行的历史记录，以供以后参考。
> Airflow UI[2]: https://airflow.apache.org/docs/stable/
安装非常简单。 您只需要Python。 它具有两个独立运行的进程，即UI和Scheduler。
原则[2]：
- 动态的：气流管道是通过代码(Python)配置的，从而可以动态生成管道。 这允许编写可动态实例化管道的代码。
- 可扩展：轻松定义您自己的运算符，执行程序并扩展库，使其适合于您的环境的抽象级别。
- 优雅：气流管道简洁明了。 使用强大的Jinja模板引擎将参数化脚本内置到Airflow中。
- 可扩展
尽管气流是作为代码编写的，但是气流并不是数据流解决方案[2]。 此外，工作流预计大部分是静态的或缓慢变化的，对于非常小的动态作业，还有其他选项，我们将在后面讨论。
尽管XCOM功能用于在经常需要的任务之间传递小的元数据，例如当您需要某种相关性ID时，它却是简单且无状态的。 它还支持变量和参数化作业。 最后，它具有支持SLA和警报。 它可以与用于监视的通话工具集成在一起。
Luigi是具有类似功能的Airflow的替代产品，但Airflow具有更多功能，并且比Luigi具有更好的扩展性。
Dagster
Dagster是机器学习，分析和ETL的新编排者[3]。 主要区别在于，您可以像Apache NiFi一样跟踪数据的输入和输出，从而创建数据流解决方案。 这意味着它可以跟踪执行状态，并可以将值具体化为执行步骤的一部分。 您可以使用数据管道和资产的统一视图在本地测试并在任何地方运行。 它支持任何云环境。
Dagster对业务流程图中各步骤之间的数据依赖关系进行建模，并处理它们之间的数据传递。 输入和输出上的可选类型有助于尽早发现错误[3]。 管道由共享的，可重用的，可配置的数据处理和基础架构组件构建而成。 Dagster的网络用户界面使任何人都可以检查这些对象并发现如何使用它们[3]。
> Dagster UI[4]: https://docs.dagster.io/
它还可以并行运行多个作业，易于添加参数，易于测试，提供简单的版本控制，出色的日志记录，故障排除功能等等。 与Airflow相比，它具有更多功能，但是它还有些不成熟，并且由于它需要跟踪数据，因此可能难以扩展，由于状态性，这是NiFi面临的一个问题。 而且它很大程度上基于Python生态系统。
Prefect
Prefect与Dagster相似，提供本地测试，版本控制，参数管理等等。 它也是基于Python的。
Prefect之所以与众不同，是为了克服Airflow执行引擎的局限性，例如改进的调度程序，参数化的工作流，动态工作流，版本控制和改进的测试。 对于许多面向DevOps的组织来说，必须具有版本控制功能，但Airflow仍不支持版本控制，Prefect确实支持该功能。
它具有一个核心的开源工作流管理系统以及一个完全不需要设置的云产品。 Prefect Cloud由GraphQL，Dask和Kubernetes支持，因此可以随时使用[4]。 UI仅在云产品中可用。
Apache NiFi
Apache NiFi不是业务流程框架，而是更广泛的数据流解决方案。 NiFi还可以安排作业，监视，路由数据，警报等等。 它专注于数据流，但您也可以处理批处理。
它不需要任何类型的编程，并提供拖放UI。 它非常易于使用，您可以将其用于中等难度的作业，而不会出现任何问题，但是对于较大的作业，它往往存在可伸缩性问题。
它在Hadoop外部运行，但可以触发Spark作业并连接到HDFS / S3。
> NiFi UI[5]: https://nifi.apache.org/
用例
让我们看一些例子…
- 我有一个旧的Hadoop集群，其Spark批处理作业的运行速度很慢，您的团队符合Scala开发人员的要求，而您的DAG并不太复杂。 在这种情况下，Ozzie是一个不错的选择，因为它提供了计划Spark作业的简单方法。
- 我有许多具有复杂依赖关系的运行缓慢的Spark作业，您需要能够测试依赖关系并最大化并行性，您需要一个易于部署且提供大量故障排除功能的解决方案。 在这种情况下，Airflow是您最好的选择。
- 我需要从许多来源实时获取数据，您需要跟踪数据沿袭，路由数据，丰富数据并能够调试任何问题。 这是您的BA所需要的实时数据流传输管道，他们没有太多的编程知识。 在这种情况下，Apache NiFi是您最好的选择，因为它不需要Python技能即可提供所需的所有功能。 如果您的团队具备Python技能，请考虑使用Dagster。
- 我想在云中创建实时和批处理管道，而不必担心维护服务器或配置系统。 我需要一个快速，强大的解决方案来增强基于Python的分析团队的能力。 在这种情况下，请使用Prefect Cloud。
- 我有短暂的，瞬息万变的工作，要处理要跟踪的复杂数据，我需要一种方法来解决问题并快速进行生产变更。 在这种情况下，请考虑Dagster。
- 我处理数百TB的数据，我有一个复杂的依赖项，我想自动化我的工作流程测试。 对于这种情况，请使用Airflow，因为它可以扩展，与许多系统交互并可以进行单元测试。 Dagster或Prefect可能在此规模的数据上存在规模问题。
- 我不确定我需要什么。 在这种情况下，请从Airflow开始，因为它是最受欢迎的选择。
结论
我们似乎是一些最常见的业务流程框架。 如您所见，它们中的大多数将DAG用作代码，因此您可以在将新的工作流程投入生产之前在本地进行测试，调试管道并对其进行正确的测试。 考虑本文讨论的所有功能，并选择最适合该工作的工具。
简而言之，如果您的需求只是编排不需要共享数据的独立任务，并且/或者您的工作很慢，并且/或者您不使用Python，请使用Airflow或Ozzie。 对于需要数据沿袭和跟踪的数据流应用程序，请对非开发人员使用NiFi; 或Dagster或Prefect(适用于Python开发人员)。
在可能的情况下，请尝试使工作保持简单并在Orchestrator外部管理数据依赖关系，这在Spark中很常见，在Spark中您将数据保存到深度存储中而不传递。 在这种情况下，Airflow是一个不错的选择，因为它不需要跟踪数据流，并且您仍然可以使用XCOM传递小的元数据，例如数据的位置。 对于更小，运行速度更快，基于python的作业或更多动态数据集，您可能希望在Orchestrator中跟踪数据依赖性并使用Dagster之类的工具。
