微博基于 Flink 的机器学习实践

导读： 微博作为国内比较主流的社交媒体平台，目前拥有 2.22 亿日活用户和 5.16 亿月活用户。如何为用户实时推荐优质内容，背后离不开微博的大规模机器学习平台。本文由微博机器学习研发中心高级算法工程师于茜老师分享，主要内容包含以下四部分：

• 关于微博

• 微博机器学习平台 ( WML ) 总览

• Flink 在 WML 中的应用

• 使用 Flink 的下一步计划

01 关于微博

微博 2008 年上线，是目前国内比较主流的社交媒体平台，拥有 2.22 亿日活用户和 5.16 亿月活用户，为用户提供在线创作、分享和发现优质内容的服务；目前微博的大规模机器学习平台可以支持千亿参数和百万 QPS。

02 微博机器学习平台 ( WML ) 总览

接下来介绍一下微博机器学习平台，即 WML 的总览；机器学习平台 ( WML ) 为 CTR、多媒体等各类机器学习和深度学习算法提供从样本处理、模型训练、服务部署到模型预估的一站式服务。

1. 总览

上方是 WML 的一个整体架构图，共分为六层，从下至上依次介绍：

• 集群层：包含离线计算集群、在线计算集群和高性能计算集群；

• 调度层：包含自研的 WeiBox ( 提供使用通用的接口将任务提交到不同集群的能力 )、Weiflow ( 提供将任务间的依赖关系处理好、组成 DAG 工作流的能力 )，以及常见的调度引擎 Yarn 和 K8s；

• 计算平台层：包含自研的 WeiLearn ( 提供给用户在该平台做业务开发的能力 )，以及 Hadoop/Spark 离线计算平台、Flink/Storm 在线计算平台和 Tensorflow 机器学习平台；

• 模型训练层：目前支持 LR、GBDT、FM/FFM、CF/MF、DNN/RNN 等主流的算法；

• 在线推理层：包含自研的 WeiServing 和 WeiPS；

• 业务应用层：主要应用场景是特征生成、样本服务、在线训练和在线推理；

• 右边是自定义的一些概念，样本库、模型库、服务库以及两个任务提交方式 WeiClient ( CLI 方式提交 )、WAIC UI ( 界面操作 )。

2. 开发模式

接下来介绍一下开发模式，有两层 DAG 的设计：

• 内层，WeiLearn 层里面可以重写离线的 Input、Process 和 Output 方法以及实时的 Source、Process 和 Sink 方法，用户自己开发一个 UDF 来实现自己的业务逻辑；内层的每一个 DAG 都会组成一个 Task。

• 外层，即第二层 DAG 层，WeiFlow 层里面将 WeiLearn 中产生的 Task 的依赖关系组成一个集群内或者跨集群的 WorkFlow，然后运行计算。

3. CTR 模型

介绍一下 CTR 模型在微博迭代的情况，经过几年的研究和探索，目前支撑的参数规模达千亿级，服务峰值达百万 QPS，模型更新的周期大概在 10 分钟左右；现在是 Weilearn6.0 版本，可以看到 WeiLearn 在不断完善更新自己的算法：

• 1.0 版本仅支持 LR 离线学习

• 2.0 版本支持 LR/GBDT/LR+GBDT 离线学习

• 3.0 版本支持 LR/GBDT/LR+GBDT 离线学习以及 Wide&Deep 的深度学习

• 4.0 版本支持 LR/GBDTLR+GBDT/FM/MF 离线学习以及 Wide&Deep 的深度学习

• 5.0 版本支持 Online FM/FFM 在线学习，LR/GBDT/LR+GBDT/FM/MF 离线学习以及 Wide&Deep/DeepFM/DSSM 的深度学习

• 6.0 版本更新了 Online DNN 模型，加强在线机器学习模型的表达能力

03 Flink 在 WML 中的应用

下面介绍 Flink 在微博机器学习平台 WML 中的架构

1. 概览

上图为实时计算平台的整体情况，接下来详细介绍一下各模块：

• 基础架构层：包含 Storm 集群、Flink 集群、Flume 以及用于监控系统运行的 Grafana。

• 计算层：主要是对 Pig 和 Flink 的进一步封装，包含 WeiPig + WeiStream 和 WeiLearn + WeiFlink；左侧为实时数据源，包含实时消息队列、Redis、Kafka；一些历史数据会存到右侧的 HDFS 中。

• 应用层：目前这套平台主要应用于多媒体特征生成、内容去重、数据同步、实时特征生成、样本服务以及在线训练。

• 业务层：支撑了目前微博主要的几个业务，包含热门微博、关系流、视频推荐、内容监控和图片推荐。

接下来看一下 Flink 在 ETL 的 Pipeline 中的概览：之前是有两个 Pipeline，一个为在线的，以前是使用 Storm 进行的处理，目前正在往 Flink 迁移，两套现在处于并行状态，处理流程是从消息队列中获取数据进行处理，然后给到在线训练模块 ( Flink 和 Spark Streaming 并行 )，最后提供模型服务给推荐系统调用；一个为离线的，和在线类似，首先写入到 HDFS 交给 Hive 或 Spark 进行处理，再次落到 HDFS 中交给离线训练使用，最后提供模型服务给推荐系统调用。因为有两类 ETL 的 Pipeline，使用不同的框架，需要维护两套代码，维护成本较高。

目前做的就是将两套融合成一套，进行批流统一的处理，此处可能会用到 FlinkSQL，然后将 ETL 后的数据输出到实时消息队列或者 HDFS 中，交给在线和离线模型训练，最后提供模型服务给推荐系统调用。

2. 样本服务

介绍一下样本生成服务，上图为该服务的整体架构图，包含样本数据的处理和计算等，除了一些生成的离线和实时数据外，还需要一些已经生成好的特征的引用，通过普通计算、多流 Join、深度学习等处理方式生成样本，最后存储到样本库中供模型训练来调用。

这个是样本服务任务提交的方式，可以通过之前提到的 WeiClient 命令行方式提交，也可以通过 WAIC UI 方式指定样本 ID 以及 UDF 的 class name 和要拼接的特征 ID，通过一种统一的方式将作业提交到集群上；之后是通过 Twinkle 或 VVP 的方式提交到 Flink 集群，然后会对作业状态进行管理，通过 Grafana 进行监控和报警，将历史作业信息存储到 HDFS 中。

3. 多流 Join

这是微博目前的一个主流场景，多数据流 Join 场景 ( 大部分是大于等于 3 )：有 N 个数据源，通过过滤和映射的处理后按照 Key 进行分发，在 Joining Window 中进行 join 后 ( 此处后面会详细讲 )，会再进行一次过滤和映射以及添加特征，最后输出到样本库中。

接下来看一下刚刚讲到的拼接窗口的实现方式，这是和业务比较相关的，对于 CTR 场景来说日志有很多种 ( 多个行为日志 )，但是到达的时间并不完全一致，比如点击这种行为日志可能会比曝光日志到的晚一些；这样就会需要一个时间窗口，以 10 分钟为例，如果某种日志先到了，就会将对应的 key 和 value 存储到 State 中，状态存储这块是基于 RocksDB 和 HDFS 做的；经过这个十分钟窗口之后，拼接好的样本数据会输到实时流中；此处基于 Flink 做了一些优化：

• 因为窗口是 10 分钟的，但是如果 10 分钟内日志数据已经全部到达，就不同等到 10 分钟窗口结束后再输出去；所以自定义了样本 trigger 触发机制，样本拼接成功后就可以立即输出，这样可以减少一些时延

• 样本补偿 PU loss；此处是基于 Twitter 在 2019 年发的一篇论文的实现方式，就是拿到正样本之后，首先对正样本做一个梯度下降的处理，另外可能之前有 False Negative 的样本已经发送出去了，那就需要之前的样本进行补偿，所以需要对该样本的负样本做一个反向的梯度下降

• 另外在 RocksDB 做状态存储这部分，引用了 Gemini 与 RocksDB 作对比，Gemini 的 IO 性能更好一些

• 拼接窗口时长的控制是和业务场景比较相关的，日志到达的时间和具体的业务场景是有关系的，所以需要权衡时间窗口设置多长时间才能满足拼接成功率的预期，这块需要大量的离线计算和 A/B Test 来共同决定。

4. 多媒体特征生成

介绍一下 Flink 在多媒体特征生成场景的应用，此处主要是依赖离线计算的深度学习模型，因此整体的模型训练走的是离线的 Pipeline，将数据在离线的 GPU 集群进行分布式的模型训练，然后将模型部署到 GPU 上面供在线推理的时候调用；在线推理模块接收到图片流、文本流和视频流这些实时数据之后，首先会通过 RPC 调用 GPU 上的模型，然后将多媒体特征结果写入到数据中台，由业务方去读取结果来使用，因为这块是一个实时的任务作业，服务稳定性需要一定的保障 ( 4 个 9 的成功率、秒级延迟、配置化开发模式 )，下面会对服务保障做详细介绍。

针对实时任务的服务保障做了如下的工作：

• 全链路监控报警 &Case 追踪，针对模型服务到 RPC 的情况、模型关键指标以及样本情况整体是有一个全流程的监控

• 设置消息机制是 At least once，每条消息至少要被处理一次，这样可以保障每条数据结果都能写到特征工程中

• 任何一个部分出现问题都会实现自动重启

• 重启时可以从 checkpoints 中恢复数据和 State，可以避免一些重复计算，也是为了减少一些延时

• 所有实时任务都会起一个重试的任务，这样在主流程中写入失败，会再次写入到重试队列中再进行一次重试的写入，这样保障数据会被计算两次；如果最终还是写入失败，就会记录到对账离线系统中，这样可以看到哪些数据是写入失败的，可以手动恢复一下。

04 使用 Flink 的下一步计划

最后分享一下使用 Fllink 的下一步计划：

1. 实时数仓

目前已经通过 Flink SQL 的方式实现了开发，但是实时和离线表的注册还有元数据存储是有一定差异的，希望可以抽象出一层 API 用统一的方式来进行实时和离线表的注册以及元数据的存储。

2. 基于 Flink 的 DL

我们希望可以将离线的深度学习完全迁移到在线深度学习来做，这样的话就需要用到 TensorFlow on Flink，这样就可以保证不管是模型训练还是在线推理都可以使用同样一套框架去完成，这样就需要把离线训练的全量模型也可以通过实时样本进行增量训练的一些校正，后面的步骤和之前基本上是保持一致的，这样就可以将离线深度学习的这条 Pipeline 优化一些。

本次的分享就到这里，谢谢大家。

作者介绍：

于茜，微博机器学习研发中心高级算法工程师。多年来致力于使用 Flink 构建实时数据处理和在线机器学习框架，有丰富的社交媒体应用推荐系统的开发经验。

本文来自 DataFunTalk

原文链接：

https://mp.weixin.qq.com/s/smk8Qsm4LgzkyrfVqenA3g