我正在开发一个项目，其中可配置的管道和对Spark DataFrames的更改的沿袭跟踪都是必不可少的。此管道的端点通常只是修改过的DataFrames（将其视为ETL任务）。对我来说最有意义的是利用已有的Spark ML Pipeline API来跟踪这些变化。特别是，更改（基于其他列添加列等）实现为自定义Spark ML变换器。
但是，我们现在正在讨论这是否是实现此管道的最惯用方式。另一种选择是将这些转换实现为一系列UDF，并基于DataFrame的架构历史（或Spark的内部DF谱系跟踪）构建我们自己的谱系跟踪。这方面的论点是Spark的ML管道不仅仅是ETL作业，而且应该始终以生成可以提供给Spark ML Evaluator的列的目标来实现。反对这一方面的论点是，它需要大量的工作来反映现有的功能。
将Spark的ML管道严格用于ETL任务是否有任何问题？只使用变形金刚并且不包括评估者的任务？
答案 0 :(得分：0)
对我来说，这似乎是一个好主意，特别是如果你可以将生成的不同管道组合成新的，因为管道本身可以由不同的管道组成，因为管道从PipelineStage向上延伸到树上（来源：{{3} }）。
但请记住，你可能正在做同样的事情，如下所述（https://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.ml.Pipeline）：
在内部，transform方法使用Spark SQL的udf来定义一个函数（基于上面描述的createTransformFunc函数），该函数将创建新的输出列（具有适当的outputDataType）。 UDF稍后应用于输入DataFrame的输入列，结果将成为输出列（使用DataFrame.withColumn方法）。
如果您已经决定采用其他方法或找到更好的方法，请评论。很高兴分享有关Spark的知识。