解決方案總覽
建議變更
PDF
本節將回顧傳統的資料科學管道及其缺點。同時也介紹建議的資料集快取解決方案架構。
傳統的資料科學管道與缺點
典型的ML模型開發與部署順序涉及迭代步驟、包括下列步驟：
-
擷取資料
-
資料預先處理（建立多個版本的資料集）
-
執行多項涉及超參數最佳化、不同模型等的實驗
-
部署
-
監控cnvrg-IO已開發出全方位平台、可將研究到部署等所有工作自動化。下圖顯示與管線相關的儀表板快照範例。
在公有儲存庫和私有資料中、經常會有多個資料集在活動中。此外、每個資料集可能會因為資料集清理或功能工程而產生多個版本。需要提供資料集線器和版本集線器的儀表板、以確保團隊能夠使用協同作業和一致性工具、如下圖所示。
下一步是訓練、訓練模式需要多個平行執行個體、每個執行個體都與資料集和特定運算執行個體相關聯。將資料集繫結至特定運算執行個體的特定實驗、是一項挑戰、因為某些實驗可能是由Amazon Web Services（AWS）的GPU執行、而其他實驗則由內部部署的DGX-1或DGX-2執行個體執行。在GCP的CPU伺服器上執行其他實驗、而資料集位置與執行訓練的運算資源並不合理。合理的鄰近範圍、可將資料集儲存設備與運算執行個體之間的完整10GbE或更低延遲連線。
資料科學家通常會將資料集下載至執行訓練和執行實驗的運算執行個體。不過、這種方法可能有幾個問題：
-
當資料科學家將資料集下載至運算執行個體時、並不保證整合式運算儲存設備具備高效能（高效能系統的範例是ONTAP AFF 以支援A800 NVMe解決方案為例）。
-
當下載的資料集位於單一運算節點時、分散式模型在多個節點上執行時、儲存設備可能會成為瓶頸（與NetApp ONTAP 的高效能分散式儲存設備不同）。
-
由於佇列衝突或優先順序、訓練實驗的下一次迭代作業可能會在不同的運算執行個體中執行、同樣也會從資料集到運算位置建立相當長的網路距離。
-
在同一個運算叢集上執行訓練實驗的其他團隊成員無法共用此資料集；每個團隊成員都會從任意位置執行（昂貴）資料集下載。
-
如果後續訓練工作需要相同資料集的其他資料集或版本、資料科學家必須重新執行（昂貴）資料集下載、將資料集下載至執行training.NetApp的運算執行個體、並執行cnvrg-.IO建立新的資料集快取解決方案、以消除這些障礙。此解決方案可將Hot資料集快取至ONTAP 高效能的儲存系統、以加速執行ML管線。使用支援NetApp的Data Fabric（例如、Re A800）、資料集會在運算組合的資料架構中快取一次（而且只快取一次）ONTAP AFF 。由於NetApp ONTAP 不間斷NFS高速儲存設備可支援多個ML運算節點、因此訓練模式的效能已經過最佳化、可為組織帶來成本節約、生產力和營運效率。
解決方案架構
此解決方案來自NetApp和cnvrg-IO、提供資料集快取功能、如下圖所示。資料集快取可讓資料科學家挑選所需的資料集或資料集版本、並將其移至ONTAP 靠近ML運算叢集的支援NFS快取。資料科學家現在可以執行多項實驗、而不會產生延遲或下載。此外、所有協同作業的工程師都能將相同的資料集用於附加的運算叢集（可自由選擇任何節點）、而無需從資料湖下載額外資料。提供資料科學家儀表板、可追蹤及監控所有資料集和版本、並提供快取資料集的檢視。
cnvrg-IO平台會自動偵測未在特定時間內使用的老舊資料集、並從快取中予以移出、因為快取會為較常用的資料集保留可用的NFS快取空間。請務必注意ONTAP 、使用效益技術的資料集快取功能可在雲端和內部部署中運作、因此能提供最大的靈活度。
