1. 数据处理架构 主要分为四层： 处理能力层，Spark on Kubernetes 提供流式的数据处理能力 数据管理层，Iceberg 提供 ACID、table 等数据集访问操作能力 存储层，Hive MetaStore 管理 Iceberg 表元数据，Postgresql 作为 Hive MetaStore 存储后端，S3 作为数据存储后端 资

本文使用的 DLRover 版本是 0.3.7 1. DLRover Operator 1.1 启动 ElasticJob 和 ScalePlan 的控制器 实现代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // 创建 ElasticJob 的控制器 if err = controllers.NewElasticJobReconciler(mgr, masterImage).SetupWithManager(mgr); err != nil { setupLog.Error(err, "unable to create controller", "controller", "ElasticJob") os.Exit(1) } // 创建 ScalePlan 的控制器 if err = controllers.NewScalePlanReconciler(mgr).SetupWithManager(mgr); err != nil { setupLog.Error(err, "unable to create controller", "controller", "ScalePlan") os.Exit(1) } // 启动控制器 if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil { setupLog.Error(err, "problem running manager") os.Exit(1) } 这部分代码是

1. 分布式训练面临的问题 预估训练资源困难，无法自动化 需要多少算力、需要多少时间、需要多少带宽、需要多少 CPU、需要多少内存，如果没有足够的积累，很难估算准确。导致的结果就是，超额申请、超额分配，造成极大的资源浪费。 需要去沉淀和提供解决方案。 故

1. top 查看节点资源使用率超过 100% 1 2 3 4 5 6 kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% master-1 995m 16% 13760Mi 118% master-2 827m 13% 10672Mi 92% master-3 889m 14% 10244Mi 88% 这是由于在计算使用率时，默认使用的是可分配的资源，排除了 Kubelet 保留的部分。在 kubectl 源码中可以看到: 1 2 3 4 5 6 7 for _, n := range nodes { if !o.ShowCapacity { availableResources[n.Name] = n.Status.Allocatable } else { availableResources[n.Name] = n.Status.Capacity } } 如果需要

1. 存储方案 三种存储方案： 基于目录隔离公用一个 JuiceFS Elasticsearch 的节点共用一个 JuiceFS，通过子目录挂载不同的 Elasticsearch 节点。 /0/ 对应节点 Node-0 /1/ 对应节点 Node-1 /2/ 对应节点 Node-2 这种方式的好处主要是，易于扩展、配置方便。 基于 JuiceFS 隔离节点数据 Elasticsearch 每个节点都对接一个独立的 JuiceF