@ -26,145 +26,104 @@
1. 为了支持大量的训练任务和使用模型的应用在一个集群上，需要支持训练任务节点的伸缩。
1. 为了支持大量的训练任务和使用模型的应用在一个集群上，需要支持训练任务节点的伸缩。
1. 支持训练任务的前置任务和后置任务，支持训练任务的定时调度和对在线流式数据的处理
1. 支持训练任务的前置任务和后置任务，支持训练任务的定时调度和对在线流式数据的处理
## 模型参数数据备份
## 模型参数检查点(Checkpointing)
为了实现parameter server集群可以容忍单点故障， ， ，
模型数据检查点的实现， ， ， ** *本地磁盘／分布式存储挂载点*** 保存检查点快照达到容灾的目的， ， ，
< img src = "images/replica.png" width = "500" / >
上图显示了在3台parameter server中实现每个模型参数的分片均保存两个副本的状态。parameter 负责存储
所有参数分片副本并在etcd中同步每个副本的状态。每个分片的多个副本中同时只有一个处于"master"状态，
处于"master"状态的副本是当前活动的副本。当一台parameter server故障时，
会重新选举出新的"master"副本并继续提供服务。比如如果parameter server 3故障， ， ， ， ，
用户在启动parameter server是可以指定副本的个数(>=1)，副本越多容灾能力越强，越少性能越好。但通常不会
使用>3个的副本配置。
etcd中数据存储格式为：
1. pserver集群状态`[CLUSTER_CHROOT]/pserver_cluster_status`
```json
{
"cluster_status": "OK|UNHEALTHY|UNKNOWN"
"reason": "",
"nodes": [0,1,2,3]
}
```
1. 每个pserver的状态: [CLUSTER_CHROOT]/pservers/[pserverid]
< img src = "images/checkpointing.png" width = "500" / >
```json
{
"id": 0,
"instance": "pserver1",
"status": "up",
"start_time": 1490184573.25,
"sync": true,
}
```
1. parameter分片信息: [CLUSTER_CHROOT]/pshards/[shardid]/[replicaid]
比如上图显示的分片将生成下面的4个etcd路径：
```bash
/pshards/0/0
/pshards/0/1
/pshards/1/0
/pshards/1/1
```
每个replica的信息如下：
```json
{
"id": 0,
"shardid": 0,
"created": 1490184573.25,
"modified": 1490184573.25,
"status": "master", # indicates the replica is in use
}
```
## 数据一致性
### 快照保存的设计如下：
存在多个副本数据的情况下就需要考虑多个副本之间的数据一致性。如果使用数据强一致性（ ） ，
则在故障恢复时可以获得一个完整的数据集，但每次更新模型参数的性能会下降，因为需要保证多个副本都完全更新之后才算更新
成功。如果使用异步同步（最终一致性），则在重新选举"master"副本时，可能得到的副本并没有完成数据同步。
本文档讨论使用两阶段提交(2PC)实现模型副本数据的更新。
前置要求：
* 每个副本通常由多个parameter block组成， ，
* 所有parameter server在etcd上注册自己的id节点为TTL节点`/paddle/pservers/[id]`， ，
* 每次需要更新一个block的时候， ，
* 所有trainers在etcd `/paddle/trainers/[id]` 下注册节点。并监听暂停信号：`/paddle/trainers/pause`（监听节点创建和删除），`re-fetch` 信号。trainer在收到pause创建的信号之后， ，
* trainer再向"master"发送变化部分的梯度数据和这份数据的id， ， ， ，
< img src = "images/two_phase_commit.png" width = "500" / > 程序流程：
1. 满足条件""每个pass或每n个mini-batch"时，
2. parameter server在etcd服务中创建`/paddle/checkpoints/[snapshot uuid]/[parameter server id]`TTL节点， ／ ，
3. 任意一个parameter server完成检查点更新后， ， ， ；
4. 如果在任意时间点， ， ：
## 模型数据检查点(Checkpointing)
* 如果没有处在暂停状态，则暂停所有的参数更新
模型数据检查点， ， ** *本地磁盘／分布式存储挂载点*** 保存检查点快照达到容灾的目的， ， ，
* 删除etcd中`/paddle/checkpoints/[snapshot uuid]`的路径，清理没有成功执行的检查点任务。
* 从etcd中读取检查点的uuid和timestamp， ， ， ， （ ） ， ，
* 原子性创建etcd节点： ，
* 删除`/paddle/trainers/pause` 节点， ， ，
5. 尝试获取`/paddle/checkpoints/finish_lock`分布式锁(使用etcd3或者客户端wrapper)。获取锁之后，更新 `/paddle/checkpoints/latest` 的内容为最新的checkpoint的uuid， ； ； ； ；
这里需要用户额外注意， ， ， ， ，
这里需要用户额外注意， ， ， ， ，
## 训练数据的存储和分发
### ETCD文件一览
生产环境中的训练数据集通常体积很大， ， ， ， ：
***注： ，
< img src = "images/trainer_data.png" width = "500" / > * `/paddle/pservers/[id]` : TTL节点。id是parameter server的id，
* `/paddle/checkpoints/latest` : 最新的checkpoint的信息。json格式保存timestamp, uuid
* `/paddle/checkpoints/latest/files/[trainer id]` : 保存最新的checkpoint对应的每个trainer读取数据的文件和offset
* `/paddle/checkpoints/[snapshot uuid]/[parameter server id]` : TTL节点。uuid是checkpoint生成的唯一snapshot id
* `/paddle/checkpoints/[snapshot uuid]/finished/[parameter server id]` : 同上
* `/paddle/trainers/[id]` : TTL节点， ，
* `/paddle/trainers/pause` : 控制trainer暂停上传梯度
* `/paddle/trainers/re-fetch` : 控制trainer重新从parameter server读取参数并覆盖本地参数
考虑到HDFS实际上已经完成了数据切割的任务， （ ） ， ， ， ，
## 训练数据的存储和分发
***注：
### 现在的方法
生产环境中的训练数据集通常体积很大， ， ， ， ：
进一步优化，
< img src = "images/trainer_data.png" width = "500" / >
trainer和训练数据分片的均衡：
### 期望的方法
* 当trainer >= 数据分片：
trainer个数和数据分片个数相同时， ， ， ，
< img src = "images/more_trainer.png" width = "500" / > 考虑到HDFS实际上已经完成了数据切割的任务， （ ） ， ， ， ，
* 当trainer < 数据分片
***注：
每个trainer负责多个数据分片，
< img src = "images/less_trainer.png" align = "center" height = "500" / > 我们将使用如下的设计完成数据分发:
## 故障恢复
< img src = "images/master.png" width = "500" / >
在通用集群上运行的应用和任务，通常需要有能够自动伸缩的能力，这样在在线集群进行扩容时，可以适当的减小训练任务的资源(进程数／并发数)，而不需要直接停止训练任务，修改参数后重新提交任务。
然而对于常见的在线服务（ ， ） ， ， ， ， ， ， ， ， （ ） ， （ ） 。如图， ， ， ， ， ， （ ） 。
用户只要根据实际训练任务场景， ， ， ， ， ： master不会直接发送数据给Trainer而是负责协调训练数据的分配， ， ，
1. 配置parameter server和trainer的初始节点个数、最大节点个数、最小节点个数、模型副本个数、是否开启检查点等配置以及训练任务相关配置。
### 推测执行/加速执行(TODO)
1. 启动parameter server和trainer， （ ） ， < TTL ` ) 更 新 这 个 节 点 的 TTL 。 这 样 当 某 个 parameter server 或 trainer 失 效 时 ， etcd 中 的 节 点 会 消 失 ， 反 应 的 状 态 。 每 个 parameter server 在 所 有 的 parameter server 上 会 使 用 etcd watcher 监 听 节 点 的 变 化 状 态 ， 已 完 成 后 续 处 理 。
在异构集群中， （ ） ， ， ，
1. parameter server如果开启了检查点， ， ， ，
1. 提交用户定义的深度学习网络(topology)， ， ， ， ，
1. parameter server开始监听端口并接收数据。每次接收到数据， ， ，
1. 当其中一台parameter server故障发生后（ ， ） ，
```json
{
"event": "removal",
"node": {
"createdIndex": 1,
"key": "/mycluster/pservers/3",
"modifiedIndex": 1,
"value": "{...json...}"
},
}
```
此时将暂停trainer的训练（ ， （ ） ， ） ， ：
1. 根据现有存活的parameter server的个数， ， ，
2. 重新分布每个slot， ，
3. 重新开始trainer的训练。
新增节点的方法类似，此处不再赘述。
### 关于存储的考虑
* 图像／音频类数据，预处理之后以何种方式分布式存储，如何切割?
* 支持流式数据接口和常规文件接口
* 对不同的分布式存储，
## 动态扩容/缩容
## 动态扩容/缩容
虽然故障恢复可以提供任意时刻的节点新增和删除仍然可以保证任务正常运行， ， ：
虽然故障恢复可以提供任意时刻的节点新增和删除仍然可以保证任务正常运行， ， ：
```python
```python
def resize(n):
def resize(n):
# do resize
save_checkpoint()
pause_all_trainers()
start_and_wait_trainers(n - self.num_trainers)
start_and_wait_pservers(n - self.num_pservers)
do_parameter_re_hash()
trainers_re_fetch()
start_all_trainers()
return success
return success
```
```
接口完成先发送信号暂停训练任务， ，
要实现`do_parameter_re_hash()`， ， ， ：
## 性能考虑
```
由于每次数据提交都需要完成分片同步， ，
parameters = large vector
< .............................. >
|___| |___| |___|
^
|
parameter block
需要：
hash to map to
parameter block --------> 128~1024 slots --------> parameter servers
```
* 测试任务／极短训练任务：如果训练任务在几十分钟或小时级别可以运行完成，可以考虑不开启副本也不开启检查点。
接口完成先发送信号暂停训练任务， ，
* 短期训练任务／ ： ， （ ） ，
* 大型训练任务： ， ，
## 实现考虑
## 实现考虑
由于两阶段提交和数据备份同步、选举部分实现比较复杂， ， ， ，
由于两阶段提交和数据备份同步、选举部分实现比较复杂， ， ， ，
yi.wu
8 years ago
