ps-lite_part1_基础介绍

3,606次阅读
2 条评论

共计 2375 个字符,预计需要花费 6 分钟才能阅读完成。

问题

在做推荐系统做分布式训练,面临的经典问题应该就是以下两个问题:

  • 高维稀疏数据存储问题
    • 在做推荐相关的工作,尤其是模型这块,ps应该是最常被提起的一个东西。推荐系统一个典型的现象就是高维稀疏数据,产生这些的稀疏数据的原因就在于庞大的用户体量、物料体量。对于一个日活上亿的应用,你要去跑模型,对用户id建模,从常规的构建embedding 矩阵,如果只是单机服务,肯定是装不下这么大的数据量。为了解决这个问题,ps就应运而生。
  • 分布式训练参数更新问题
    • 按照常规的分布式训练,从master将所有的网络参数同步到slave节点网络带宽消耗太大,这块是直接影响到性能。

当然这两个问题可能在现有的大环境下已经被解决掉了,因为这是基础架构的一部分,大部分公司在做基建的时候就已经搞定了这些问题,所以说只从使用的角度来看,那其实不是个问题。

那么现在为什么还要提出这个问题?核心的点就是知其所以然,但是并不是完全的。如果涉及到ps调参其实是有必要了解ps的内部原理机制。

如何解决?

既然这篇文章是讲ps的,那么解决方案肯定是ps方案了。

概念

ps全称是 parameter service(参数服务器),也可以理解为一个“数据库”(kv数据库),你给一个id,我给你返回 embedding ,那么可以理解key 就是id,value 就是embedding。当然不单单是存储数据,尤其是反向传播参数更新之类的都有。具体是怎么运作的可以继续往下看。

ps是如何运作?

再稍微具体一点,基于Parameter Server的训练流程如下图所示:

ps-lite_part1_基础介绍

  • 系统中主要有两大类节点

    • Work节点,负责读取本地的局部训练数据,计算梯度
    • Server节点,负责存储局部的参数空间,响应worker请求,对自己负责的局部参数进行读写。
  • [Worker] 训练时,每个worker先归纳一下当前batch需要涉及到哪些feature_id。

    • 观察图中的x,其所在行代表样本,其所在列代表feature_id,可以发现训练数据的确是非常稀疏的。
    • 因此一个batch所涵盖的特征相对于整个特征空间,仍然是十分渺小的。
  • [Worker] 每个worker向整个ps server集群请求“当前batch涵盖的feature”的最新参数(e.g., 一阶权重或embedding)。即图中的Pull。

  • [Server] 因为每台ps server只拥有一部分feature的参数,所以尽管图中没有表现,但是中间会有一个路由机制,将worker的请求拆分、路由到合适的ps server上。

  • [Server] 收到“拉数据”请求的ps server,从本地存储中找到这些feature_id的最新参数,回复。

  • [Worker] 收到ps server发送回来的各feature的最新参数,worker就可以在当前batch的数据上进行前代+回代,得到这些feature上的梯度。

  • [Worker] Worker将计算好的梯度发往Server,即图中的Push。

  • [Server] 接到worker发来的梯度后,Server汇总聚合梯度,再用各种SGD的变体(e.g., FTRL、Adam、Adagrad等)更新本地参数。

问题解答

  • 如何处理高维稀疏数据?—-因为是分布式ps,可以将数据按块划分,后续会讲这些数据怎么存储,简单的方式就是有多少个节点,总的数据量处以节点数,就是每个机器上的存储的数据量
  • 数据同步的问题?—-这里的数据同步主要就是worker 向sever传递梯度以及拉取embedding和权重参数

解决方案实现:ps-lite

这个标题其实算是标题党,现在成熟的ps架构肯定比这个更完善。ps-lite,故名思义是一个轻量版本,它会给出核心的骨架,有一点麻雀虽小五脏俱全的感觉,当然对我来说是有一个学习ps内部原理的机会。

三种节点类型

在使用SGD进行训练的场景下:

  • worker:从server pull最新的待优化参数,读本地数据,计算出梯度,向server push梯度

  • server: 其实就是一个key/value数据库,

    • 应对pull请求,将worker请求的参数的最新值发送回去
    • 应对push请求,聚合各worker发送过来的gradient,再利用各种SGD的变体(e.g., Adam,Adagrad)更新weight
  • scheduler: 一个系统中只有一个scheduler节点,主要负责

    • 其他server/worker节点的管理:有节点加入或退出时,都需要将本集群内最新的节点名单广播给群内的所有节点
    • 多节点之间的数据同步:统计有多少节点已经运行了到“同步”点;如果所有节点都“到齐”了,向所有参与节点的节点发“解除阻塞”的信息

五个重要数据类型

  • PostOffice: 每个进程(无论scheduler/worker/server),有且只有一个“邮局”,是该进程的消息集散中心。它掌管着在它那里等消息的“顾客”的名单。 |

  • Van:每个邮局只有一辆“邮车”,负责收发信件的具体工作。派发信件时,Van通过PostOffice的名单,找到某个“顾客”,将信件交到他手上。 |

  • Customer:邮局的顾客,其实就是个中介。worker和server为了更好地专心业务工作,将“在邮局排队等消息”的工作外包给了“顾客”。Customer从Van手中接过信件后,转手就交给它的顾主,worker或server。

  • Worker:Customer的顾主,训练时主要负责处理样本、计算梯度等工作。

  • Server:Customer的顾主,训练时主要负责接收梯度,汇总梯度(同步模式下),更新权重等工作。

    将上述的点用一张图来表示,大概如下图所示

ps-lite_part1_基础介绍

总结

  • 了解ps解决了什么问题
  • 了解ps运作的方式
  • ps-lite的重要组成

附录:

  • https://zhuanlan.zhihu.com/p/467650462
正文完
请博主喝杯咖啡吧!
post-qrcode
 
admin
版权声明:本站原创文章,由 admin 2023-03-08发表,共计2375字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(2 条评论)
验证码