超级会员免费看
分布式机器学习工作流的实现与优化
在分布式机器学习领域，实现一个高效且稳定的端到端工作流至关重要。本文将详细介绍如何实现这样的工作流，以及如何利用缓存机制优化工作流的执行效率。
端到端工作流的实现
首先，我们需要提交工作流。以下是工作流的相关配置：
modelFormat:
name: tensorflow
image: "emacski/tensorflow-serving:2.6.0"
storageUri: "pvc://strategy-volume/saved_model_versions"
提交工作流的命令如下：
kubectl create -f workflow.yaml
当数据摄取步骤完成后，相关的 Pod 会被删除。在执行分布式模型训练步骤时，我们可以通过以下命令查看 Pod 列表：
kubectl get pods
输出结果示例如下：
| NAME | READY | STATUS | RESTARTS | AGE |
|------------------------------|-------|---------|----------|------|
| multi-
-worker-0 | 1/1 | Running | 0 | 50s |
| multi-<truncated -worker-1 | 1/1 | Running | 0 | 49s |
| multi-<truncated -worker-0 | 1/1 | Running | 0 | 47s |
| multi-<truncated -worker-1 | 1/1 | Running | 0 | 47s |
| multi-<truncated -worker-0 | 1/1 | Running | 0 | 54s |
| multi-<truncated -worker-1 | 1/1 | Running | 0 | 53s |
|
-cnn-model | 1/1 | Running | 0 | 56s |
|
-batch-norm | 1/1 | Running | 0 | 56s |
|
-dropout | 1/1 | Running | 0 | 56s |
当剩余步骤完成且模型服务成功启动后，工作流应显示为成功状态，至此端到端工作流执行完毕。
步骤记忆化优化
为了加速未来工作流的执行，我们可以利用缓存机制跳过最近已经运行过的某些步骤。以数据摄取步骤为例，由于不需要反复下载相同的数据集，因此可以跳过该步骤。
首先，查看数据摄取步骤的日志：
Downloading and preparing dataset 29.45 MiB
(download: 29.45 MiB, generated: 36.42 MiB,
total: 65.87 MiB) to
/root/tensorflow_datasets/fashion_mnist/3.0.1...
Dataset fashion_mnist downloaded and prepared to
/root/tensorflow_datasets/fashion_mnist/3.0.1.
Subsequent calls will reuse this data.
数据集已下载到容器内的特定路径，如果将该路径挂载到持久卷，后续的工作流运行都可以使用该数据。我们可以使用 Argo Workflows 提供的步骤记忆化功能来优化工作流。
在步骤模板中，为
memoize
字段提供缓存键和缓存有效期。当一个步骤完成时，会保存一个缓存。当该步骤在新的工作流中再次运行时，会检查缓存是否在过去一小时内创建。如果是，则跳过该步骤，工作流将继续执行后续步骤。以下是配置示例：
- name: data-ingestion-step
serviceAccountName: argo
memoize:
key: "step-cache"
maxAge: "1h"
cache:
configMap:
name: my-config
key: step-cache
container:
image: kubeflow/multi-worker-strategy:v0.1
imagePullPolicy: IfNotPresent
command: ["python", "/data-ingestion.py"]
第一次运行工作流时，由于是首次运行该步骤，缓存未命中。可以使用以下命令查看工作流的节点状态：
kubectl get wf tfjob-wf-kjj2q -o yaml
节点状态示例如下：
Status:
Nodes:
tfjob-wf-crfhx-2213815408:
Boundary ID: tfjob-wf-crfhx
Children:
tfjob-wf-crfhx-579056679
Display Name: data-ingestion-step
Finished At: 2023-01-04T20:57:44Z
Host Node Name: distml-control-plane
Id: tfjob-wf-crfhx-2213815408
Memoization Status:
Cache Name: my-config
Hit: false
Key: step-cache
Name: tfjob-wf-crfhx[0].data-ingestion-step
如果在一小时内再次运行相同的工作流，会发现该步骤被跳过（
Memoization Status
字段中的
Hit
为
true
）：
Status:
Nodes:
tfjob-wf-kjj2q-1381200071:
Boundary ID: tfjob-wf-kjj2q
Children:
tfjob-wf-kjj2q-2031651288
Display Name: data-ingestion-step
Finished At: 2023-01-04T20:58:31Z
Id: tfjob-wf-kjj2q-1381200071
Memoization Status:
Cache Name: my-config
Hit: true
Key: step-cache
Name: tfjob-wf-kjj2q[0].data-ingestion-step
Outputs:
Exit Code: 0
Phase: Succeeded
Progress: 1/1
Started At: 2023-01-04T20:58:31Z
Template Name: data-ingestion-step
Template Scope: local/tfjob-wf-kjj2q
Type: Pod
需要注意的是，
Finished At
和
Started At
时间戳相同，这意味着该步骤无需从头重新执行，瞬间完成。
Argo Workflows 中的所有缓存都保存在 Kubernetes 的 ConfigMap 对象中。缓存包含节点 ID、步骤输出、缓存创建时间戳以及该缓存最后命中的时间戳。可以使用以下命令查看 ConfigMap 的详细信息：
kubectl get configmap -o yaml my-config
输出结果示例如下：
apiVersion: v1
data:
step-cache: '{"nodeID":"tfjob-wf-dmtn4-
3886957114","outputs":{"exitCode":"0"},
"creationTimestamp":"2023-01-04T20:44:55Z",
"lastHitTimestamp":"2023-01-04T20:57:44Z"}'
kind: ConfigMap
metadata:
creationTimestamp: "2023-01-04T20:44:55Z"
labels:
workflows.argoproj.io/configmap-type: Cache
name: my-config
namespace: kubeflow
resourceVersion: "806155"
uid: 0810a68b-44f8-469f-b02c-7f62504145ba
总结
通过上述步骤，我们实现了一个完整的端到端工作流，并利用步骤记忆化功能优化了工作流的执行效率。具体总结如下：
-
数据摄取
：实现了针对 Fashion - MNIST 数据集的分布式输入管道，便于与分布式模型训练集成。
-
模型训练
：可以在 TensorFlow 中定义机器学习模型和分布式模型训练逻辑，并借助 Kubeflow 在 Kubernetes 集群中以分布式方式执行。
-
模型服务
：可以通过 KServe 实现单实例模型服务器和复制模型服务器。KServe 的自动缩放功能可以自动创建额外的模型服务 Pod 来处理不断增加的模型服务请求。
-
工作流优化
：使用 Argo Workflows 实现了包含系统所有组件的端到端工作流，并利用步骤记忆化避免了耗时且冗余的数据摄取步骤。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(提交工作流):::process --> B(数据摄取):::process
B --> C{数据摄取是否完成}:::process
C -- 是 --> D(删除相关Pod):::process
C -- 否 --> B
D --> E(分布式模型训练):::process
E --> F{训练是否完成}:::process
F -- 是 --> G(模型服务启动):::process
F -- 否 --> E
G --> H{服务是否成功启动}:::process
H -- 是 --> I(工作流成功):::process
H -- 否 --> G
通过以上步骤和优化，我们可以更高效地设计和部署分布式机器学习系统，提高系统的可靠性和性能。
分布式机器学习工作流的实现与优化
分布式机器学习模式及相关技术
在分布式机器学习系统中，有多种模式和技术可用于优化系统性能和效率。以下是一些常见的模式及其应用：
批处理模式
- 定义 ：批处理模式是将数据分成批次进行处理的方式。它适用于数据量较大且可以按顺序处理的场景。
- 应用场景 ：当数据可以批量处理，且处理时间不是关键因素时，批处理模式是一个不错的选择。例如，在训练机器学习模型时，可以将大量的训练数据分成多个批次进行处理。
-
操作步骤
：
- 确定批大小：根据计算资源和数据特点，确定合适的批大小。
- 划分数据：将完整的数据集按照批大小进行划分。
- 顺序处理：依次处理每个批次的数据。
缓存模式
- 定义 ：缓存模式是将经常使用的数据或计算结果存储在缓存中，以便下次使用时可以快速获取，避免重复计算。
- 应用场景 ：当某些数据或计算结果在多次使用时保持不变，或者获取这些数据或结果的成本较高时，可以使用缓存模式。例如，在机器学习工作流中，数据摄取步骤可能会下载大量的数据集，使用缓存可以避免每次都重新下载。
-
操作步骤
：
- 确定缓存内容：选择需要缓存的数据或计算结果。
- 设置缓存有效期：根据数据的更新频率，设置合适的缓存有效期。
- 检查缓存：在执行步骤之前，检查缓存中是否存在所需的数据或结果。如果存在，则直接使用缓存；否则，执行相应的操作并将结果存入缓存。
分片模式
- 定义 ：分片模式是将数据或工作负载分成多个部分（分片），并在不同的节点或进程中并行处理这些分片。
- 应用场景 ：当数据量非常大，单个节点无法处理时，或者需要提高处理速度时，可以使用分片模式。例如，在分布式数据库中，可以将数据水平或垂直分片存储在不同的节点上。
-
操作步骤
：
- 确定分片策略：根据数据特点和系统架构，选择合适的分片策略，如哈希分片、范围分片等。
- 划分数据：将完整的数据按照分片策略进行划分。
- 并行处理：在不同的节点或进程中并行处理各个分片。
分布式机器学习系统的调度与资源管理
在分布式机器学习系统中，调度和资源管理是确保系统高效运行的关键。以下是一些常见的调度模式和资源管理方法：
调度模式
-
公平共享调度
：公平共享调度旨在确保每个用户或任务都能公平地使用系统资源。它会根据任务的优先级和资源需求，合理分配资源。
-
操作步骤
：
- 定义任务优先级：为每个任务分配一个优先级。
- 监控资源使用情况：实时监控系统资源的使用情况。
- 动态分配资源：根据任务的优先级和资源需求，动态分配资源。
-
操作步骤
：
-
优先级调度
：优先级调度根据任务的重要性或紧急程度，为任务分配不同的优先级。高优先级的任务会优先获得资源。
-
操作步骤
：
- 确定任务优先级：根据任务的性质和需求，确定每个任务的优先级。
- 排序任务：按照优先级对任务进行排序。
- 分配资源：优先为高优先级的任务分配资源。
-
操作步骤
：
-
组调度
：组调度将一组相关的任务作为一个整体进行调度，确保这些任务能够同时获得所需的资源。
-
操作步骤
：
- 定义任务组：将相关的任务组成一个任务组。
- 监控任务组状态：实时监控任务组中各个任务的状态。
- 分配资源：当任务组中的所有任务都准备好时，为整个任务组分配所需的资源。
-
操作步骤
：
资源管理
-
资源池分配
：将计算资源集中管理，形成一个资源池。根据任务的需求，从资源池中分配资源给任务。
-
操作步骤
：
- 定义资源池：确定可用的计算资源，并将其组成一个资源池。
- 监控资源池状态：实时监控资源池中的资源使用情况。
- 分配资源：根据任务的需求，从资源池中分配合适的资源给任务。
-
操作步骤
：
-
弹性调度
：根据系统的负载情况，动态调整资源的分配。当负载较高时，增加资源；当负载较低时，减少资源。
-
操作步骤
：
- 监控系统负载：实时监控系统的负载情况，如 CPU 使用率、内存使用率等。
- 评估资源需求：根据系统负载情况，评估任务所需的资源。
- 调整资源分配：根据评估结果，动态调整资源的分配。
-
操作步骤
：
分布式机器学习系统的故障处理
在分布式机器学习系统中，故障是不可避免的。因此，需要采取有效的故障处理策略来确保系统的可靠性和稳定性。以下是一些常见的故障处理方法：
容错模式
- 定义 ：容错模式是指系统在出现故障时能够继续正常运行或快速恢复的能力。
- 应用场景 ：当系统对可靠性要求较高，且故障可能会导致严重后果时，需要采用容错模式。例如，在金融交易系统中，任何故障都可能导致巨大的损失，因此需要具备高度的容错能力。
-
操作步骤
：
- 检测故障：实时监控系统的运行状态，及时发现故障。
- 隔离故障：将故障部分与正常部分隔离开来，避免故障扩散。
- 恢复系统：采取相应的措施，恢复系统的正常运行。例如，重启故障节点、重新分配任务等。
检查点机制
- 定义 ：检查点机制是在训练过程中定期保存模型的状态和训练进度，以便在出现故障时可以从最近的检查点恢复训练。
- 应用场景 ：当训练过程可能会因为各种原因中断，且重新开始训练的成本较高时，可以使用检查点机制。例如，在训练大型深度学习模型时，训练过程可能需要数天甚至数周的时间，使用检查点机制可以避免因故障而丢失大量的训练进度。
-
操作步骤
：
- 确定检查点保存频率：根据训练的复杂度和时间成本，确定合适的检查点保存频率。
- 保存检查点：在每个检查点处，保存模型的状态和训练进度。
- 恢复训练：当出现故障时，从最近的检查点恢复训练。
分布式机器学习系统的模型服务
模型服务是将训练好的模型部署到生产环境中，为用户提供预测服务的过程。以下是一些关于模型服务的要点：
模型服务系统的架构
- 单实例模型服务器 ：适用于负载较低、对响应时间要求不高的场景。
- 复制模型服务器 ：通过复制多个模型服务器实例，提高系统的可用性和处理能力。可以使用负载均衡器将请求均匀地分配到各个实例上。
- 自动缩放 ：根据系统的负载情况，自动调整模型服务器实例的数量。当负载较高时，增加实例；当负载较低时，减少实例。
模型服务的实现
- KServe ：是一个用于在 Kubernetes 上部署和管理机器学习模型的开源框架。它提供了自动缩放、模型版本管理等功能。
-
操作步骤
：
- 定义模型服务：使用 KServe 的配置文件定义模型服务的相关信息，如模型名称、版本、输入输出格式等。
- 部署模型服务：将模型服务部署到 Kubernetes 集群中。
- 监控和管理：实时监控模型服务的运行状态，根据需要进行调整和管理。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(任务提交):::process --> B{选择调度模式}:::process
B -- 公平共享调度 --> C(公平分配资源):::process
B -- 优先级调度 --> D(按优先级分配资源):::process
B -- 组调度 --> E(为任务组分配资源):::process
C --> F(任务执行):::process
D --> F
E --> F
F --> G{是否出现故障}:::process
G -- 是 --> H(容错处理):::process
H --> I(检查点恢复):::process
I --> F
G -- 否 --> J(任务完成):::process
J --> K(模型服务):::process
K -- 单实例模型服务器 --> L(提供服务):::process
K -- 复制模型服务器 --> M(负载均衡):::process
M --> N(多实例提供服务):::process
K -- 自动缩放 --> O(动态调整实例数量):::process
O --> N
通过合理应用上述模式和技术，可以提高分布式机器学习系统的性能、可靠性和效率，更好地满足实际应用的需求。在实际应用中，需要根据具体的场景和需求，选择合适的模式和技术，并进行适当的调整和优化。
扫一扫
620
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
