概述
目前 XGBoost 官方文档在 on Kubernetes 的文档中，也推荐了 XGBoost Operator。
XGBoost on Kubernetes 是一个比较新鲜的话题。目前基于 XGBoost 的分布式训练方法，可以是基于 Spark 或者 Yarn 等计算框架去完成，但是如果要完成一个 XGBoost on Kubernetes，我们是否需要 XGBoost on Spark and then on Kubernetes 这种这么 tricky 的方式呢？
并不是说不行，因为通过 Spark 来读数据，再喂给每个节点去做 XGBoost 的训练也是一件很合理的事情，但是如果说算法工程师不太熟悉写 Spark 的代码呢，PySpark 也很多隐藏的坑，经常调试半天才发现，如果有更直接的 XGBoost on Kubernetes 的方式，那自然会更好了，这样的话算法同学只要写一份 Python 的程序就可以了，而且通过 Yaml 来描述这个 XGBoost 训练任务自然也是非常方便的。
Proposal for a XGBOOST operator，这是 Kubeflow 社区关于 XGBoost Operator 的提议。
XGBoost 的分布式训练是基于 Rabbit 协议的。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
apiVersion: "xgboostjob.kubeflow.org/v1alpha1"
kind: "XGBoostJob"
metadata:
name: "xgboost-dist-iris-test-train-local"
spec:
xgbReplicaSpecs:
Master:
replicas: 1
restartPolicy: Never
template:
apiVersion: v1
kind: Pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: xgboostlocal
containers:
- name: xgboostjob
image: docker.io/merlintang/xgboost-dist-iris:1.1
volumeMounts:
- name: task-pv-storage
mountPath: /tmp/xgboost_model
ports:
- containerPort: 9991
name: xgboostjob-port
imagePullPolicy: Always
args:
- --job_type=Train
- --xgboost_parameter=objective:multi:softprob,num_class:3
- --n_estimators=10
- --learning_rate=0.1
- --model_path=/tmp/xgboost_model/2
- --odel_storage_type=local
Worker:
replicas: 2
restartPolicy: ExitCode
template:
apiVersion: v1
kind: Pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: xgboostlocal
containers:
- name: xgboostjob
image: docker.io/merlintang/xgboost-dist-iris:1.1
volumeMounts:
- name: task-pv-storage
mountPath: /tmp/xgboost_model
ports:
- containerPort: 9991
name: xgboostjob-port
imagePullPolicy: Always
args:
- --job_type=Train
- --xgboost_parameter="objective:multi:softprob,num_class:3"
- --n_estimators=10
- --learning_rate=0.1
- --model_path=/tmp/xgboost_model/2
- --model_storage_type=local
|
跟 S3 结合的话，建议引入 boto3 的包，然后按照不同的 rank 来去读取数据，读数据不会太慢的，毕竟是分布式的去读。
分布式 XGBoost 的实现是使用了一个叫 Rabit 的协议，他描述的是 Master 和一组 Slave 节点的关系。Master 节点首先被初始化，然后每个 Slave 节点接着初始化，然后听过 ip:port 的方式，跟 Master 节点通信。每个 Worker 节点读取自己部分的数据，然后开始训练。对于做 Predicton 的任务，训练好的模型会被分发到每个 Worker 节点，然后由他们自己完成 Prediction的过程。
所以 master 的作用是？也是分发命令？可是 Worker 也在启动这些命令啊。
在 TenC 上需要暴露一些参数。
Master:
- command
- args
- image
- Volumes(支持 S3)
Worker:
- command
- args
- image
- Volumes(支持 S3)
关于分布式 XGBoost 的例子请参考 xgboost-dist。
现在 Kubeflow 的项目都迁移到 kubeflow/common 这个包了，意味着要开发一个 xxx-operator 是相对比较简单的，关于 Job 和 Pod 之间的状态管理等等，就已经非常明确了。
Q内 + 公司的网络环境，有时候代理尤其是 Go 的 Proxy 能把人折腾死。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 亲测 goproxy.io 有些包不全
go env -w GO111MODULE=on
go env -w GOPROXY=https://goproxy.io,direct
# 设置不走 proxy 的私有仓库，多个用逗号相隔（可选）
go env -w GOPRIVATE=*.oa.com
# Go 给的默认值，Q 外没问题
go env -w GOPROXY=direct
go env -w GOSUMDB=off
# GOPROXY CN 亲测包全一点
go env -w GO111MODULE=on
go env -w GOPROXY=https://goproxy.cn,direct
|
警告
本文最后更新于 2017年2月1日，文中内容可能已过时，请谨慎参考。