pslite技术内幕（一）：理论篇

介绍

分布式的优化和推断已经成为解决大数据机器学习问题的重要问题。由于数据规模的不断增长，以及越来越复杂的模型（表现在模型参数的不断增长）的提出，单机已经无法有效的解决这些问题。实现高效分布式的算法并不容易，密集的计算负载和大量的数据通信都需要精心的系统设计。

现实训练数据的规模可能再1TB和1PB之间。模型的参数的个数在$10^9$到$10^{10}$之间。所有的worker节点会共享这些参数，并在训练中不断的访问并优化这些参数。参数共享会有三个方面的挑战：

• 参数的访问需要大量的网络带宽
• 很多机器学习算法是线性的。同步开销和机器延迟会严重的影响性能。
• 容错处理很关键。机器学习的任务通常部署在云或者集群的环境下，其中的机器不是100%可靠的，或者不是100%独占的，任务可能会被其他任务取代。

现实世界是部署中，并不像很多研究中那样可以独占的运行在一个集群上，所以容错处理是非常必要的。

相关工作

Amazon,Baidu,Facebook,Google,Microsoft,Yahoo已经实现了相关的系统。也有一些开源项目，例如YahooLDA,Petuum。Graphlab甚至支持了参数的同步，在一个best effort model.

第一代参数服务器设计，缺少灵活性，性能也不高–它使用memcached分布式存储实现同步机制。YahooLDA做了改进，实现了一个专用的server,支持用户定义的原子操作(set,get,update)，并且实现了一个更好的负载均衡算法。Distbelief也属于这种第二代机器学习系统：application specific参数服务器。Petuum又向通用的系统迈了一步。它通过有限延迟模型改进了YahooLDA，但同时对worker节点的线程模型有了更多的限制。我们描述的第三代系统克服哦恩这些限制。

最后，与一些通用的分布式机器学习系统做一个比较。其中有一些会执行同步和迭代通信。在包含十几个节点的情况下工作的很好，但是再更大的规模下，这种同步操作带来很多的挑战。Mahout on hadoop, MLI on spark都采用了迭代的MapReduce框架。Spark和MLI的一个关键核心就是保持迭代的状态，这也是参数服务器的核心目标。

分布式的GraphLab则采用异步的通信。目前， GrapLab缺少弹性扩容的机制，并且依赖粗粒度的快照做恢复。这两点都妨碍了系统的伸缩性。在应用一个特定的算法时，它最大的问题在于缺少一个全局的变量同步机制。某种意义上，参数服务器的核心目标就是获取Graph异步通信的优点，屏蔽它结构的限制。

Piccolo使用参数服务器相关的一个策略来共享和聚合机器的状态。worker首先在本地预聚合状态，然后将更新传输到维护聚合状态的server.因此它实现了我们系统的许多功能，单缺少机器学习相关的优化：消息压缩，备份，变量一致性模型。

参数服务器架构设计

参数服务器的一个实例可以同时运行多个算法。参数服务器的节点可以划分为一个server组和多个worker组，如上图所示。server组中的每个server节点维护全局共享参数的一部分。为了提高可靠性和伸缩能力，server节点之间互相通信，互相备份和迁移参数。一个server manager节点维护server节点的全局信息，包括server节点的存活时间，参数的分布等。

每一个worker组运行一个应用。worke节点通常会存储训练数据的一部分，worker节点与server之间有通信，用于更新和获取共享参数，但是worker节点之间不会通信。每一个worker组有一个scheduler节点，负责给worker节点分配任务和监控任务的进度，如果有worker节点加入和退出，scheduler负责重新调度未完成的任务。

参数服务器支持独立的参数命名空间，隔离不同worker组的共享参数。多个worker组也可以共用同一个命名空间：我们可能会使用多个worker组来解决同一个深度学习问题。另外一个例子即使可能会儿其他节点，例如在线的服务会获取参数的的值，同时模型会被worker节点不断的更新。

参数服务器被设计用来简化分布式机器学习应用。共享的参数以（key,value）的向量形式存在，方便线性代数运算。参数分布再server节点内。任何一个节点可以push自己的本地参数，也可以从server你的pull参数。默认情况下，负载和任务有worker节点承担；同时，也可以通过自定义的操作分配给server节点。任务会异步的并发的执行。参数服务器通过任务依赖图和参数子集操作为算法设计者提供了多种一致性模型。

原文链接