问DataBricks + Kedro Vs GCP + Kubeflow Vs Server + Kedro +气流

EN

我将尝试总结我所知道的，但是要注意，我不是KubeFlow项目的一部分。

数据库上的Kedro

我们的方法是用CI构建我们的项目，然后从笔记本上执行管道。由于作业和交互集群之间的kedro推荐方法 (DB-connect所需的)，我们没有使用使用databricks-connect的大价差。如果您正在处理几个TB的数据，这很快就会变得相关。

作为一个DS，这种方法可能感觉很自然，作为一个SWE，尽管它不是。在笔记本中运行管道感觉很烦人。这是可行的，但却让人觉得没有工业化。Databricks在自动旋转向上和向下集群方面表现很好&照顾您的运行时。因此，它们的价值增加是将IaaS从您手中抽离(稍后将更详细地介绍)。

GCP &“云本地人”

Pro：GCP的主要卖点是BigQuery。这是一个非常强大的平台，因为从第0天开始，你就可以高效工作了。我看到人们在上面构建了整个web。KubeFlow没有绑定到GCP，所以您以后可以将它移植到其他地方。Kubernetes还允许您在集群、API、流、web服务、网站上运行任何您想要的东西，您可以选择它的名称。

Con：Kubernetes是复杂的。如果你有10+工程师长期运行这个项目，你应该会没事的.但不要低估库伯奈特的复杂性。它对于云就像Linux对于操作系统世界一样。考虑日志管理、噪音邻居( web +批处理火花作业的一个集群)、多集群管理(每个部门/项目一个集群)、安全性、资源访问等。

IaaS服务器方法

您的最后一个选择，手动安装服务器，只有当您有一个庞大的团队，非常大的数据，并正在建立一个长期的产品谁的收入可以维持大量的维护成本，我会建议。

背后的人

你所在地区的人才市场情况如何？如果你能雇用有GCP知识的有经验的工程师，我会选择第二个解决方案。GCP是一个成熟的、“本地”的平台，因为它为客户抽象了很多东西。如果你的市场主要有AWS工程师，那可能是一条更好的道路。如果你有一批kedro工程师，那也是有关联的。注意，kedro是不可知论的，可以在任何地方运行。它实际上只是python代码。

主观建议

由于主要从事AWS项目和一些GCP项目，我会选择GCP。我会使用平台的组件(BigQuery、Cloud、PubSub、from、K8S)作为工具箱，从中选择并构建一个组织。Kedro可以作为调度器触发的任务、Kubernetes上的容器或将数据导入(或退出) BigQuery的ETL管道在任何这些上下文中运行。

虽然Databricks比原始AWS“管理更少”，但它仍然是需要考虑的服务器和需要担心的VPC网络费用。BigQuery被简单地查询到GB。函数只是调用计数。这些高级别组件将允许您快速向客户展示价值，并且您只需要在扩展时进行更深层次的开发(RaaS -> PaaS -> IaaS)。

AWS在IaaS上也有更高层次的抽象，但总的来说，我认为谷歌的服务是最成熟的。主要是因为他们发布了内部使用了近十年的工具，而AWS则为市场构建了新的工具。然而，AWS是IaaS的国王。

最后，介绍一下内容，今年秋天早些时候，两位前同事讨论了ML工业化框架。