4

我们正在 10 多家公司之间部署一个数据联盟。Wi 将为所有公司部署多个机器学习模型（通常是高级分析模型），我们将管理所有模型。我们正在寻找一种管理多个服务器、集群和数据科学管道的解决方案。我喜欢 kedro，但不确定在使用 kedro 时管理所有内容的最佳选择是什么。

总之，我们正在寻找在不同服务器和可能的 Spark 集群中管理多个模型、任务和管道的最佳解决方案。我们目前的选择是：

  • AWS 作为我们的数据仓库和用于管理服务器、集群和任务的 Databricks。我不觉得 databricks 的 notebooks 是构建管道和协同工作的好解决方案，所以我想将 kedro 连接到 databricks（很好吗？使用 databricks 调度 kedro 管道的运行是否容易？ )

  • 将 GCP 用于数据仓库，并使用 kubeflow (iin GCP) 来部署模型以及管道和所需资源的管理和计划

  • 从 ASW 或 GCP 设置服务器，安装 kedro 并使用气流调度管道（我发现管理 20 台服务器和 40 条管道存在很大问题）

我想知道是否有人知道这些替代方案之间的最佳选择是什么，它们的缺点和优点，或者是否有更多的可能性。

4

1 回答 1

4

我将尝试总结我所知道的，但请注意，我还没有参与过 KubeFlow 项目。

在 Databricks 上的 Kedro

我们的方法是使用 CI 构建我们的项目，然后从笔记本执行管道。我们没有使用kedro 推荐的使用 databricks-connect 的方法，因为Jobs 和 Interactive Clusters（DB-connect 需要它们）之间的价格差异很大。如果您正在处理数 TB 的数据，这很快就会变得相关。

作为 DS，这种方法可能感觉很自然，但作为 SWE，尽管它不是。在笔记本中运行管道感觉很笨拙。它有效，但感觉非工业化。Databricks 在自动启动和关闭集群并为您处理运行时方面表现良好。因此，他们的附加值是将 IaaS 与您分离（稍后会详细介绍）。

GCP 和“云原生”

Pro : GCP 的主要卖点是 BigQuery。这是一个非常强大的平台，仅仅因为你可以从第 0 天开始就保持高效。我见过人们在它之上构建整个 Web API。KubeFlow 不绑定到 GCP，因此您可以稍后将其移植到其他地方。Kubernetes 还允许你在集群、API、流媒体、Web 服务、网站上运行任何你想要的东西。

缺点： Kubernetes很复杂。如果你有 10 多名工程师长期运行这个项目，你应该没问题。但不要低估 Kubernetes 的复杂性。它之于云就像 Linux 之于操作系统世界一样。想想日志管理、嘈杂的邻居（一个用于 Web API 的集群 + 批量 Spark 作业）、多集群管理（每个部门/项目一个集群）、安全性、资源访问等。

IaaS 服务器方法

你的最后一个选择，手动安装服务器是我推荐的一种，只有当你有一个庞大的团队，非常大的数据并且正在构建一个长期的产品，其收入可以承受大量的维护成本。

背后的人

您所在地区的人才市场如何？如果您可以聘请具有 GCP 知识的经验丰富的工程师，我会选择第二种解决方案。GCP 是一个成熟的“原生”平台，因为它为客户抽象了很多东西。如果您的市场主要有 AWS 工程师，那可能是一条更好的选择。如果您有许多 kedro 工程师，那也有相关性。请注意，kedro 是不可知论者，可以在任何地方运行。它实际上只是 python 代码。

主观建议：

在主要从事 AWS 项目和一些 GCP 项目之后，我会选择 GCP。我会使用平台的组件（BigQuery、Cloud Run、PubSub、Functions、K8S）作为工具箱，从中进行选择并围绕它建立一个组织。Kedro 可以在任何这些上下文中运行，作为调度程序触发的作业、作为 Kubernetes 上的容器或作为将数据引入（或引出）BigQuery 的 ETL 管道。

虽然 Databricks 比原始 AWS “管理更少”，但它仍然需要考虑服务器和 VPC 网络费用。BigQuery 只是 GB 查询。函数只是调用计数。这些高级组件将使您能够快速向客户展示价值，并且您只需要在扩展时更深入（RaaS -> PaaS -> IaaS）。

AWS 在 IaaS 上也有这些更高级别的抽象，但总的来说，（在我看来）Google 的产品是最成熟的。主要是因为他们发布了他们在内部使用了近十年的工具，而 AWS 为市场构建了新工具。不过，AWS 是 IaaS 之王。

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

于 2020-11-20T17:04:04.630 回答