我有一个复杂的数据处理管道，目前在Python中的一台机器上实现。
管道是围绕属于一系列实现文档，页面，单词等的自定义类的处理对象构建的。此管道中的大多数操作都是令人尴尬的并行 - 它们可以处理单个文档 - 尽管少数需要收集整套统计。
数据集不适合内存，并且管道当前依赖于在每个阶段对磁盘进行酸洗/去除对象。这种方法有效，但速度很慢，现在是时候采用更具可扩展性的分布式架构了。
理想情况我希望能够写出类似这样的内容：
distributed_list = read_objects()
for transform in transformations:
distributed_list = transform(distributed_list)
custom_dataset_object = convert_to_dataset(distributed_list)
custom_dataset_object.save()
将整个处理流分解为DAG并在群集中并行化。
我一直在为此目的评估 pyspark ，但我不确定这是否是适合该任务的正确工具，因为我没有使用复杂的自定义对象来处理它们而不是简单的数据类型
Apache Beam 的DoFns看起来可能会完成我正在寻找的东西，但它似乎并没有被广泛采用，我想尽可能使用最便携的技术。 / p>
我还可以将其分解为一系列 Airflow 作业，但这种接缝比我想要的更加手动和脆弱。
对于更有经验的大数据工程师，这些评估是否准确？这些工具（或其他工具）中的一个是否最适合我的工作？
答案 0 :(得分：1)
这实际上取决于你想要达到的目标。例如，PySpark不是Airflow的替代品。您可以同时使用它们，也可以不使用它们。您的气流操作员（工作单元）可以像＆＃34;调用此PySpark Job＆＃34;一样简单。
气流不是关于处理步骤，而是管道本身。如果您想要可追溯性，聚合日志处理，管道SLA，条件处理步骤，回填控制，更复杂的计划等，您将要使用它。
如果您想拥有动态管道，Airflow会特别闪耀。编辑几个YAML文件，然后，您的管道现在有一些额外的步骤来计算一个额外的数据块，历史上回填并自动更新每小时。当然，这不是免费的，您将实现将配置转变为运营商的逻辑。
Airflow可以是您选择的编排机制，但您可以决定使用一堆cron作业实现相同的功能。没有汗水。
选择处理引擎是另一种问题。 Spark现在是舞会女王，而选择Apache Beam也不会逃离Spark。它可以在Spark和Flink上运行（批量与流式执行引擎）。但Spark还具有流媒体处理能力。在PySpark和Beam之间进行选择并不是一个可扩展性问题，而是你想要自己承担什么样的技术锁定。
我建议您选择实验确认优于当前处理引擎的处理引擎。 Sometimes running a command line utility can be faster than distributed jobs。可伸缩性是您在解决问题时遇到的问题，因为如果没有实验，您通常会遇到过度设计的系统。