Monolith简介

1. 前言

什么是个性化推荐？简单说，就是给用户推荐他喜欢的物品。近10年，移动互联网高速发展，个性化推荐扮演了很重要的角色。以运营一款内容类产品为例：用户增长团队通过广告投放等手段为产品拉新，提升DAU；产品技术团队为用户分发感兴趣的内容，提升留存及停留时长；商业化团队分发用户可能感兴趣的广告，提升单位流量变现效率；商业化收入又用于用户增长，形成正向循环。个性化推荐技术贯穿每个环节，成为了很多公司的高速增长引擎。

怎么做个性化推荐？通常，对一项业务来说，首先会定义出多个优化目标（例如视频的播放时长、点赞、分享，电商的点击、加购、购买等），之后构建一个或多个模型来预估这些目标，最后融合多个目标的预估分来完成排序。对推荐系统来说，最核心的工作，便是构建精准的预估模型。这些年，业界的推荐模型一直朝着大规模、实时化、精细化的趋势不断演进。大规模是指数据量和模型非常大，训练样本达到百亿甚至数万亿，单个模型达到TB甚至10TB以上；实时化是指特征、模型、候选实时更新；精细化则在特征工程、模型结构、优化方法等多方面有所体现，各种创新思路层出不穷。

本文选择大家最关心的Training和Serving系统, 我们把它命名为Monolith(磐石)，希望它能成为大家做推荐系统的坚实基础。

2. Monolith简介

2.1 Monolith架构

framework

从图中可以看出，Monolith是PS架构，下面看看这套架构是怎样运行的：

  • 批量/增量训练

    • Worker/PS启动时会向ZK注册，信息包括(server_type，index)。然后Worker向ZK请求注册信息，生成Cluster信息，实现动态组网，动态组网是容错的基础。

    • 训练开始后，Worker会从标准输入或文件中获取数据，同时从PS拉取参数，然后进行forward/backward计算，得到梯度，并将其Push给PS。

    • PS获得梯度后，一方面，利用优化器更新内部weight，另一方面，会记录哪些数据更新了。在PS上起一个TF Session，它会定时将更新的参数发送到Online PS，从而实现实时增量更新。此外，特征过滤，特征淘汰等也在PS上进行。

    • 在训练过程中或训练结束时，会写checkpoint。为了加速checkpoint，Monolith 没有延用TF 中的saveable，而是利用estimator saving listener，流式多线程地存取，性能大副提升。为了减少checkpoint体积，会将过期特征淘汰。

  • 在线推理

    • 加载saved_model。Entry本质上是TF Serving，它会从HDFS上加载非Embedding部分，同时向ZK注册，以便上层做负载均衡。Online PS也会先向ZK注册，然后从HDFS中加载参数，并在加载过程中去除优化器辅助参数，将fp32转换成fp16，量化压缩等。

    • 对于一次请求，Entry会随机选择一组Online PS，从中获取Embedding，完成预测。Entry/Online PS 是多副本的，只要有一个副本存在，服务就可用。 Online PS是多分片的，可以Serving超大模型。可以在一台机器上部署多个分片，也可以Entry/OnlinePS混部。

    • 对于一些对模型实时性较高的系统，Training PS会直接通过RPC的方式与Online PS进行通讯，从将样本反馈到线上模型的时间间隔缩短到分钟级。

    • Training PS可以与Online PS通讯，接受Training PS的参数更新；Entry可以自动从HDFS上读取更新参数，从而实现分钟级参数增量更新。 综上所述，Monolith 包括了 Training/Serving/Parameter Sync等，是一套完整的系统。

2.2 Monolith特色

与业界其它系统相比，Monolith成功应对了多方面的挑战，有如下特色：

  • 解决了TensorFlow PS 通信瓶颈 在工业级的推荐模型中，我们常会使用几百甚至数千类特征，每类特征都需要创建哈希表去存储特征embeddings。直接为每类特征生成一张哈希表，同时对几百张表进行查找会导致两个问题：

    1. PS和Worker 直接 会产生过多的 send/recv op，大大影响分布式 runtime 的运行效率。

    2. 这些 ops 导致模型图节点过多，模型图过大，训练初始化时间过长。 针对如上问题，我们在框架层面做了优化： 对于配置同构的哈希表（dim 相同、优化器参数相同），在python API 层面合并哈希表来减少表的数量，同时monolith会对通信op进行进一步的合并，从而极大的减少了send/recv ops，解决了原生TensorFlow PS 的通信问题。 针对异步训练，monolith还开发了变量与embedding预取以及梯度异步更新的功能，对于多数模型，能够更加有效的利用带宽与CPU，从而提高训练速度，优化资源利用率。

  • 全方位容错 在服务发现的基础上，无论是Worker，PS发生错误，都能得到快速恢复。对于Worker，Monolith不同worker节点之间并不进行直接通信，所以一个worker的失败并不会对别的worker产生影响；同时，worker会存储输入的进度，当worker因为意外原因失败时，输入的进度并不会丢失；当PS shard 节点失败，根据离线/在线任务的性质不同，支持部分恢复和全量恢复不同的模式，在正确性以及恢复速度上做一定的取舍。

  • 分布式Serving Monolith补齐了开源软件在分布式Serving方面的空白，提供了TB级模型的推理服务。支持多副本、高可用，Training PS在训练过程中，分钟级别将刚刚更新过的Embedding同步给Serving PS，从而实现近实时参数更新，提升了产品的推荐效果。

  • 性能优化 除了上面提到的解决 TensorFlow PS 通信瓶颈之外，Monolith 在 Parameter Server 架构、底层 Hash Table 设计、网络传输、多线程加速、OP Fusion、指令集加速等方向也进行了非常细致的优化并取得了可观的性能收益。以异步训练为例，训练时整个过程示意如下：

    performance

    • 网络通讯优化：通过 embedding prefetch, gradients postpush 将网络 IO 与图的前向/后向计算异步起来，同时支持控制流与数据流分离、压缩传输等优化；

    • 内存优化：通过支持特征过滤、特征压缩、特征淘汰等手段，可以极大地节省 training/serving 阶段内存使用；

    • 计算优化：Hot spot code 采用 AVX 指令集优化、耗时 Op 精细调优、手工 Op Fusion 等手段加速前向/后向计算过程；

    • 其它方面：多线程优化、细粒度锁设计、IO与计算异步起来等。

目前，Monolith已通过推荐平台，成功应用在电商、社区、视频等多个行业的场景上，效果、稳定性、性能均得到了充足的验证。未来，我们也将继续保持高速迭代，不断优化用户体验和平台功能。