編輯

共用方式為

使用 Databricks 和 Kubernetes 進行員工留職率分析

Azure Databricks
Azure Kubernetes Service (AKS)
Azure Container Registry
Azure 儲存體
Azure 監視器

此解決方案示範機器學習小組如何使用 Azure Databricks 和 Azure Kubernetes Service，將機器學習開發及部署為 API，以預測員工流失的可能性。 API 可以與人力資源小組使用的外部應用程式整合，以提供組織內指定員工流失的可能性的其他深入解析。 這項資訊可用來保留可能離開組織的高影響力員工，方法是提供人力資源來主動激勵這類員工留下來。

Apache®、Apache Ignite、Ignite 和火焰標誌是 Apache Software Foundation 在美國和/或其他國家/地區的註冊商標或商標。 使用這些標記不會隱含 Apache Software Foundation 的背書。

架構

本文中架構的圖表，其中顯示 API 的開發、部署、暴露程度，以及計量和記錄的監視。

下載所有架構的 PowerPoint 檔案。

工作流程

概括而言，此解決方案設計可解決機器學習生命週期的每個階段：

  • 資料準備，包括來源、清除和轉換資料以進行處理和分析。 資料可以存在於資料湖或資料倉儲中，並在策劃之後儲存在功能存放區中。

  • 模型開發，其中包含模型開發流程的核心元件，例如使用 MLflow 進行實驗追蹤和模型註冊。

  • 模型部署，包括實作持續整合與持續傳遞 (CI/CD) 管線，以將機器學習模型容器化為 API 服務。 這些服務會部署至 Azure Kubernetes 叢集，供使用者取用。

  • 模型監測，包括使用 Azure 監視器分析記錄遙測資料來監視 API 效能和模型資料漂移。

在機器學習小組將機器學習模型部署為 API 以進行即時推斷之後，開發人員可以輕鬆地將 API 與外部小組所使用的外部應用程式整合，例如人力資源。 當外部小組使用模型服務時，會收集遙測資料。 機器學習小組可以使用此遙測資料來判斷模型何時需要重新部署。 這種方法可讓小組獨立工作，並允許外部小組受益於集中式機器學習小組的技能。

注意

  • 在實作 CI/CD 管線時，您可以使用各種工具，例如 Azure Pipelines 和 GitHub Actions。

  • 分析使用案例的特定商務需求可能需要此設計中未考慮的不同服務或功能。

元件

下列元件會當做此設計的一部分使用：

  • Azure Databricks：巨量資料的分析服務，使用便利、可供協同合作，並以 Apache Spark 為基礎。 Azure Databricks 專為資料科學和資料工程而設計。

  • Azure Kubernetes Service：將作業額外負荷卸載至 Azure，以提供簡化 Kubernetes 部署和管理的服務。

  • Azure Container Registry：用於管理容器映像和成品的私人登錄服務。 此服務是以開放原始碼 Docker 為基礎。

  • Azure Data Lake Storage：一項服務，可提供針對大量非結構化數據優化的可調整記憶體。 Data Lake Storage Gen2 提供檔案系統語義、檔案層級安全性和規模。

  • Azure Monitor：用於從工作負載收集、分析和處理遙測資料的全方位解決方案。

  • MLflow：在 Databricks 內整合的開放原始碼解決方案，可管理端對端的機器學習生命週期。

  • Azure API 管理：完全受控的服務，可協助客戶發佈、保護、轉換、維護及監視 API。

  • Azure 應用程式閘道：網路流量負載平衡器，可讓您管理 Web 應用程式的流量。

  • Azure DevOps 或 GitHub：實作 DevOps 做法的解決方案，用來強制執行您的工作負載開發和部署管線的自動化及合規性。

案例詳細資料

自 COVID-19 大流行以來，員工流失問題日益突出。 這種員工大規模自願辭職的趨勢，俗稱大辭職。 問題也可以針對組織中某些部門放大，因為組織內可能缺少執行進階分析的專用小組，例如人力資源。

此範例案例說明集中式機器學習的作業模型。 這包括一個中央小組，負責為組織內各部門的外部小組建置和部署機器學習模型。 當部門太小而無法維護專門用於機器學習的小組，而組織的目標是將進階分析注入所有產品和流程時，這個方法就很有用。

潛在使用案例

此案例著重於建置員工流失的機器學習模型，並將其與人力資源小組所使用的外部應用程式整合。 不過，此設計可以一般化為集中式和分散式小組所建置的許多機器學習工作負載。

這個一般化方法最適合：

  • 已針對資料工程或機器學習應用程式在 Databricks 上標準化的機器學習小組。

  • 具備部署和管理 Kubernetes 工作負載經驗的機器學習小組，以及套用這些技能以操作機器學習工作負載的喜好設定。

  • 將機器學習工作負載與需要低延遲和互動式模型預測的外部應用程式整合 (例如即時推斷)。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。

在實作此解決方案之前，您可能想要考慮的一些因素包括：

  • 此解決方案是專為需要高度自定義的小組所設計，且在部署和管理 Kubernetes 工作負載方面具有廣泛的專業知識。 如果您的資料科學小組沒有此專業知識，請考慮將模型部署到另一個服務，例如 Azure Machine Learning。

  • 使用 Azure Machine Learning 的機器學習 DevOps (MLOps) 最佳做法提供透過機器學習在企業中採用 ML 作業 (MLOps) 的最佳做法和建議。

  • 請遵循 Azure Well-Architected Framework 中定義的建議和指導方針，改善 Azure 解決方案的品質。

  • 實作 CI/CD 管線時，您可以使用不同於此範例所使用的工具，例如 Azure Pipelines 和 GitHub Actions。 如需 CI/CD 的詳細資訊，請參閱微服務架構適用的 CI/CD。

  • 分析使用案例的特定商務需求可能需要使用此設計中未考慮的服務或功能。

成本最佳化

成本最佳化與減少不必要費用，及提升營運效率有關。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。

此解決方案中部署的所有服務都會使用以使用量為基礎的定價模型。 您可以使用 Azure 定價計算機來估算特定案例的成本。 如需其他考量，請參閱 Well-Architected Framework 中的成本最佳化。

部署此案例

此案例的概念證明實作可在 GitHub 的使用 Databricks 和 Kubernetes 進行員工留職率分析上取得。

本文中架構部署的圖表，其中顯示開發、建置、部署和監視。

下載所有架構的 PowerPoint 檔案。

此概念證明說明：

  • 如何為 Azure Databricks 上的員工流失定型 MLflow 模型。
  • 如何使用開放原始碼工具將模型封裝為 Web 服務。
  • 如何使用 GitHub Actions 透過 CI/CD 部署至 Kubernetes。
  • 如何監視 Azure 監視器和 Azure Log Analytics 工作區內的 API 效能和模型資料漂移。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

下一步

產品文件：

Microsoft Learn 模組：

您可能也會發現這些架構中心文章很有用：