参数服务器代码解读(1)

转载请注明出处:http://blog.csdn.net/zkwdn/article/details/53840091

参数服务器的文章介绍太多了。我也只大概了解了下petuum和ps-lite

我本身对spark很熟悉，所以就从spark的角度去理解为什么会有ps这个东西呢。

spark的架构是一个driver端，多个client端。driver和每个client端都会存储所有的参数。以lr为例，

1. 在driver端对所有的参数进行初始化，假设有10000个参数，driver端会存储一个10000维的array。

2.将这10000维的array传到每一个client端

3.每个client端利用这个array和自身上的数据计算对每个参数梯度的更新。也是一个10000的array存储每个参数的梯度更新值。

4.每个client端将自己的这个10000维的array传给driver端

                5.driver端调用reduce接口，将每个client的这10000维向量相加，得到每个参数的梯度更新

6.driver端根据每个梯度的更新值更新参数值。

7.driver端将更新后的参数值(10000维数组)发送到每一个client端，重复第3步。

我们可以看到2个问题。

1.Spark采用的完全是BSP协议，即第二轮迭代必须等到第一轮迭代所有的机器完成。但是每个机器的性能是不一致的，有的机器上分配的任务比较多，所以执行速度慢，有的机器分配的任务少执行快。这样执行快的机器必须等待执行慢的机器执行完，这段时间内快的机器就啥事不干，造成资源浪费。所以基于此产生了ssp协议，ssp协议即最快的机器执行的迭代次数和最慢的机器执行的迭代次数的差距不能大于某个数值t。具体的可以看下erxing老先生的几个图

这2张图应该是petuum的精髓了。

2.spark参与计算的每个机器上都存着全局所有的参数，不管是driver端还是client端。这就导致一个问题，当参数量上亿的时候，driver端和client端是没有足够的内存存下那么多参数的，所以ps的另外一个优点就是解决这个问题。首先每个client端只需要存储跟自己相关的参数(这就大大节约了非常多的内存空间),其次spark的一个driver端被分解成多个服务器端，每个服务器也只是存储跟自己相关联的client的参数。这样就解决了参数过多，内存不够的问题。上2个图，第一个图是petuum,第二个图是李牧的