对于PySpark来说，这是一个合适的用例吗？气流？阿帕奇光束？

Question

数据集不适合内存，管道目前依赖于在每个阶段将对象pickl/dePickling到和从磁盘上。这很有效，但速度很慢，是时候转向一个更可伸缩的分布式体系结构了。

理想情况下，我希望能够写出这样的内容：

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并在集群中并行化。

对于更有经验的大数据工程师来说，这些评价是否准确？这些工具中的一个（或其他一些）对我的工作最好吗？

Answer 1

这真的取决于你想要实现什么。例如，PySpark不是气流的替代品。你可以两个都用，也可以一个都不用。您的气流操作员（工作单元）可以简单到“调用这个PySpark作业”。

气流不是关于加工步骤，而是管道本身。如果您想要跟踪、聚合日志处理、管道的SLA、条件处理步骤、回填控制、更复杂的调度等等，那么就需要使用它。

气流特别闪耀如果你想有动态管道。编辑几个YAML文件就可以了，您的管道现在有几个额外的步骤来计算一个额外的数据块，历史地回填并自动地每小时更新一次。当然，这不是免费的，您将实现将配置转换为运算符的逻辑。

Airflow可以是您选择的编排机制，但您可以决定通过一系列cron作业来实现相同的机制。不用出汗。

选择处理引擎是另一种问题。Spark是现在的舞会女王，采摘Apache Beam也不是在逃避Spark。它可以在Spark和Flink上运行（批处理和流式执行引擎）。但Spark的流处理能力也越来越受欢迎。在PySpark和Beam之间进行选择并不是一个可伸缩性问题，而是您希望将自己投入到哪种技术锁定中。

我建议您选择经过试验确认性能优于当前引擎的处理引擎。有时运行命令行实用程序可能比分布式作业更快。可伸缩性是一个您可以边走边解决的问题，因为如果没有实验，您通常会得到过度设计的系统。