问Google Cloud Dataflow和Google Cloud Dataproc之间的区别是什么？

EN

可以，Cloud Dataflow和Cloud Dataproc都可以用于实现ETL数据仓库解决方案。

可以在Google Cloud Platform Big Data Solutions Articles中找到这些产品存在的原因的概述。

快速总结：

• 云数据流程为您提供了一个基于GCP的Hadoop集群，并可访问Hadoop生态系统工具(例如Apache Pig、Hive和Spark)；如果您已经熟悉Hadoop工具并拥有Hadoop作业，这将具有很强的吸引力。
• 云数据流为您提供了一个在GCP上运行基于Hadoop的作业的位置，并且您不需要解决在集群上运行作业的常见方面(例如，平衡工作，或扩展作业的工作者数量；默认情况下，这是自动为您管理的，并适用于批处理和流) --这在其他系统上可能非常耗时
  • Apache Beam是一个重要的考虑因素；Beam作业的目的是在包括云数据流的“运行者”之间进行移植，并使您能够专注于逻辑计算，而不是“运行者”的工作方式--相比之下，在编写Spark作业时，您的代码将绑定到运行者Spark，并且该运行者的工作方式
  • 云数据流还提供了基于“模板”创建作业的功能，这有助于简化常见任务的不同之处在于参数values

​

在尝试在Dataproc和Dataflow之间进行选择时，需要考虑以下三个要点

• Provisioning

Dataproc -手动配置群集

数据流-无服务器。Automatic provisioning of clusters

• Hadoop Dependencies

如果处理过程与Hadoop ecosystem.

• Portability中的工具有任何依赖关系，则应使用Dataproc。

数据流/光束在处理逻辑和底层执行引擎之间提供了清晰的分离。这有助于跨支持光束运行时的不同执行引擎的可移植性，即相同的流水线代码可以在数据流、Spark或Flink上无缝运行。

谷歌网站上的这张流程图解释了如何选择其中一个。

​

https://cloud.google.com/dataflow/images/flow-vs-proc-flowchart.svg

有关更多详细信息，请参阅以下链接

https://cloud.google.com/dataproc/#fast--scalable-data-processing

与Dataproc同时提供Hadoop和Spark的原因相同:有时一种编程模型最适合这项工作，有时另一种。同样，在某些情况下，最适合这项工作的是由Dataflow提供的Apache光束编程模型。

在许多情况下，一个重要的考虑因素是已经有一个针对特定框架编写的代码库，并且只想将其部署在Google Cloud上，所以即使，比方说，横梁编程模型优于Hadoop，拥有大量Hadoop代码的人仍然可能暂时选择Dataproc，而不是在横梁上重写代码以在数据流上运行。

Spark和Beam编程模型之间的差异非常大，并且在许多用例中，每种模型都有很大的优势。参见https://cloud.google.com/dataflow/blog/dataflow-beam-and-spark-comparison。