Eri*_*eur 5 google-cloud-platform databricks kedro
我们正在 10 多家公司之间部署一个数据联盟。Wi 将为所有公司部署多个机器学习模型（一般为高级分析模型），我们将管理所有模型。我们正在寻找一种管理多个服务器、集群和数据科学管道的解决方案。我喜欢 kedro，但不确定在使用 kedro 时管理所有内容的最佳选择是什么。
总之，我们正在寻找最佳解决方案来管理不同服务器和可能的 Spark 集群中的多个模型、任务和管道。我们目前的选择是：
AWS 作为我们的数据仓库和 Databricks 用于管理服务器、集群和任务。我不认为 databricks 的 notebooks 是构建管道和协作工作的好解决方案，所以我想将 kedro 连接到 databricks（它好吗？使用 databricks 安排 kedro 管道的运行容易吗？ )
将 GCP 用于数据仓库并使用 kubeflow (iin GCP) 来部署模型以及管道和所需资源的管理和调度
从 ASW 或 GCP 设置服务器，安装 kedro 并使用气流安排管道（我发现管理 20 个服务器和 40 个管道是一个大问题）
我想知道是否有人知道这些替代方案之间的最佳选择、它们的缺点和优点，或者是否有更多的可能性。
我将尝试总结我所知道的内容，但请注意，我没有参与过 KubeFlow 项目。
我们的方法是使用 CI 构建项目，然后从笔记本执行管道。我们没有使用kedro 推荐的使用 databricks-connect 的方法，因为作业和交互式集群（DB-connect 需要）之间的价格差异很大。如果您正在处理数 TB 的数据，那么这很快就会变得有意义。
作为 DS，这种方法可能会感觉很自然，但作为 SWE，情况却并非如此。在笔记本中运行管道感觉很奇怪。它有效，但感觉不工业化。Databricks 在自动旋转集群和为您处理运行时方面表现良好。因此，它们的附加值是将 IaaS 从您手中抽象出来（稍后会详细介绍）。
优点：GCP 的主要卖点是 BigQuery。它是一个非常强大的平台，因为您从第 0 天就可以保持高效工作。我见过人们在它的基础上构建了整个 Web API。KubeFlow 不与 GCP 绑定，因此您可以稍后将其移植到其他地方。Kubernetes 还允许您在集群、API、流媒体、Web 服务、网站等上运行您希望运行的任何其他内容。
缺点：Kubernetes 很复杂。如果你有 10 多个工程师来长期运行这个项目，那应该没问题。但不要低估 Kubernetes 的复杂性。它对于云来说就像 Linux 对于操作系统世界一样。想想日志管理、嘈杂的邻居（一个用于 Web API 的集群 + 批处理 Spark 作业）、多集群管理（每个部门/项目一个集群）、安全性、资源访问等。
最后一种选择是手动安装服务器，只有当您拥有庞大的团队、非常大的数据并且正在构建长期产品且其收入能够承受巨额维护成本时，我才会推荐您选择手动安装服务器。
您所在地区的人才市场如何？如果您可以聘请具有 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 产业化框架
| 归档时间： |
|
| 查看次数： |
510 次 |
| 最近记录： |