目前针对广告/推荐CTR场景，一般采用Parameter Server的方式进行分布式训练，简称Ps，Ps可以同时做到对数据和模型的并行训练。

为什么要采用新的Parameter Server架构方式，传统的spark/mapreduce的分布式框架为什么不行？

传统的大数据分布式架构采用的是Master/Slave架构，主要考虑了将任务和数据分配到多个节点中做并行计算。但对于模型训练来说，还需要考虑反向传播涉及到梯度的汇总和权重的更新，相比之前的分布式计算来说模型计算更加复杂。如果采用单个driver或者master节点来汇总梯度及更新权重，会受限于单节点的内存容量，那么其支持的模型大小就非常有限。

那么Ps方案解决了哪些问题呢？为什么能够克服Master/Slave架构应用于大规模分布式训练时的困难？

1. 所有参数不再存储于单一的master节点，而是由一群ps server节点负责存储、读写；

2. 得益于推荐系统的特征是超级特征的特点，一个batch的训练数据所包含的feature数目是有限的，因此，我们没必要训练每个batch时都将整个模型（i.e., 上亿的embedding）在server/worker之间传来传去，而只传递当前batch所涵盖的有限几个参数就可以了。

目前雅虎开源了Spark on TensorFlow项目，即在Spark上嵌入了TF，其中用多个Executor实现了Ps架构的训练方式，但其存在非常多的问题。

1. 使用者既要会Spark又要会TensorFlow；

2. 集成带来非常大的复杂性，会引起性能损耗，而且Spark是jvm项目，相比与纯C++项目性能较低；

3. Spark 与 TF 需要匹配版本，即存在版本升级兼容的问题，带来了更大的维护成本。