最近PMP学友会举办了个活动，就是阿里巴巴集团的大数据工程师介绍parameter server。
只是攒3个PDU，但是一直想往大数据方向发展，这个不能不知。
百度了一下，有了点眉目，以下摘自几个网络文章。问候会给出地址。
一、parameter server概念：
参数服务器是个编程框架，用于方便分布式并行程序的编写，其中重点是对大规模参数的分布式存储和协同的支持。
二、parameter server的发展背景：
工业界需要训练大型的机器学习模型，一些广泛使用的特定的模型在规模上的两个特点：
1. 参数很大，超过单个机器的容纳能力（比如大型Logistic Regression和神经网络）
2. 训练数据巨大，需要分布式并行提速（大数据）
这种需求下，当前类似MapReduce的框架并不能很好适合。
因此需要自己实现分布式并行程序，其实在Hadoop出来之前，对于大规模数据的处理，都需要自己写分布式的程序（MPI）。 之后这方面的工作流程被Google的工程师总结和抽象成MapReduce框架，大一统了。
参数服务器就类似于MapReduce，是大规模机器学习在不断使用过程中，抽象出来的框架之一。重点支持的就是参数的分布式，毕竟巨大的模型其实就是巨大的参数。
三、parameter server架构：
Parameter Server(Mli)
----------------------------
架构：
集群中的节点可以分为计算节点和参数服务节点两种。其中，计算节点负责对分配到自己本地的训练数据（块）计算学习，并更新对应的参数；参数服务节点采用分布式存储的方式，各自存储全局参数的一部分，并作为服务方接受计算节点的参数查询和更新请求。
简而言之吧，计算节点负责干活和更新参数，参数服务节点则负责存储参数。
冗余和恢复：
类似MapReduce，每个参数在参数服务器的集群中都在多个不同节点上备份（3个也是极好的），这样当出现节点失效时，冗余的参数依旧能够保证服务的有效性。当有新的节点插入时，把原先失效节点的参数从冗余参数那边复制过来，失效节点的接班人就加入队伍了。
并行计算：
并行计算这部分主要在计算节点上进行。 类似于MapReduce，分配任务时，会将数据拆分给每个worker节点。
参数服务器在开始学习前，也会把大规模的训练数据拆分到每个计算节点上。单个计算节点就对本地数据进行学习就可以了。学习完毕再把参数的更新梯度上传给对应的参数服务节点进行更新。
详细的流程：
1.
分发训练数据 -> 节点1
节点2
节点3
...
节点i
...
节点N
2.
节点i 学习过程：
遍历本地的训练数据，统计所有需要的参数(key)
向分布式的参数服务器查询需要的参数（注意，本地数据对应到的参数只是全局参数的一小部分）
得到查询到的参数值，用于模型的本地训练
一轮训练完毕，得到所有对应参数的更新，将更新上传给参数服务器
3.
参数服务器更新参数过程：
参数服务器得到计算节点传过来的局部更新，汇总后更新本地数据
一些细节还是看李沐的文章吧，这个模型相对其他的一些参数服务器的框架是最简单直观的。
四、Project Adam
------------------
微软研究院的一个专门用于deep learning的参数服务器，很厉害的样子。用了很多trick来提升性能和容纳更大的模型和数据，当然精度也随之上升了很多。
大体的架构和Parameter Server(Mli)的比较相似，但论文里面包含了比较丰富的细节，可以跟之前的内容互补一下。
相似点
同样拆分为计算节点(worker)和参数服务节点(parameter server)，参数分布式存储
均采用冗余，每个参数会保存3份，当某参数对应的服务节点失效，服务会转到该参数对应的部分节点上（2选1）
其他点
五、Parameter Server 构成：
参数服务器中，分布式存储参数的部分，包含两类节点：
Parameter Server(PS): 这类节点负责具体参数的分布式存储
Parameter Server Controller(PSC): 这类节点负责路由和冗余容灾和失效恢复等操作
换句话说，PSC是PS的管理者。 Adam中节点控制的灵活性全在PSC中。
路由机制
project Adam中使用了路由来确定每个参数的存储位置。
路由信息由PSC（其实是多个一致的节点来支撑整个集群的工作）。
计算节点在每次访问和更新参数前，先向PSC询问最新的路由信息，然后将参数按目标位置拆分发送。
而当PS中出现节点变化（节点失效或者添加，类似MapReduce，PSC也会定期PING每个PS来确认节点有效状态），PSC会修改路由，并提供最新的路由信息给计算节点。
冗余机制
前面说到，每个参数会在PS集群中有三个副本，存储在不同的节点上来实现冗余。
其中一个节点会被选为primary，来提供针对某个参数的服务。
当这个节点失效时，另外两个副本中会被挑选出一个作为新的primary，来继续此参数的服务。 这是容灾的第一步
恢复机制
前面说到，冗余机制是容灾第一步。
长久之计是将目前状态恢复到失效之前（目前该参数只有两个副本，需要恢复到3个），这就需要PSC的控制，将失效节点上的参数拆分到其他active的节点上备份（如此就恢复成了三个副本）
当然，如果有新节点的加入，也需要在PSC注册登记，之后PSC可以分配部分参数过去并修改路由。
有趣的trick
单机上，使用指针传递来避免内存复制
集群中通信，单个机器在传递多个进程的信息传递请求前，会通过相同的发送目标节点来归纳这些消息，之后一并发送请求。
无锁写入。这个也许会带来写冲突，但是概率比较低，而且深度神经网络天生可以忍受噪音
更多的信息可以搜索 project Adam，论文里面细节比较容易懂，还有一段录像讲解。
六、一个简单的实现：SwiftSnails
---------------------------------------------------
这是我写一个小的参数服务器，比较简单，代码也比较少。 没有用MPI，自己实现路由分发啥的，有种解放前小米加步枪的感觉。里面有个Word2Vec的分布式实现作为Demo，效率还是不错的。 有兴趣的可以看看 。
项目地址： SwiftSnails by Superjom
作者：Superjom
链接：https://www.zhihu.com/question/26998075/answer/40577680
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
七、参考资料：
1、李沐的论文 《Parameter Server for Distributed Machine Learning》http://www.cs.cmu.edu/~muli/file/ps.pdf
2、MapReduce的替代者-Parameter Server：http://blog.csdn.net/buptgshengod/article/details/46819051
3、https://www.zhihu.com/question/26998075/answer/40663986
原文地址：http://36006798.blog.51cto.com/988282/1872771
