共计 4699 个字符，预计需要花费 12 分钟才能阅读完成。
简介： 介绍 b 站的机器学习工作流平台 ultron 在 b 站多个机器学习场景上的利用。
分享嘉宾：张杨，B 站资深开发工程师
导读：整个机器学习的过程，从数据上报、到特色计算、到模型训练、再到线上部署、最终成果评估，整个流程十分简短。在 b 站，多个团队都会搭建本人的机器学习链路，来实现各自的机器学习需要，工程效率和数据品质都难以保障。于是咱们基于 Flink 社区的 aiflow 我的项目，构建了整套机器学习的规范工作流平台，减速机器学习流程构建，晋升多个场景的数据实效和准确性。本次分享将介绍 b 站的机器学习工作流平台 ultron 在 b 站多个机器学习场景上的利用。
目录：
1、机器学习实时化
2、Flink 在 B 站机器学习的应用
3、机器学习工作流平台构建
4、将来布局
GitHub 地址
https://github.com/apache/flink
欢送大家给 Flink 点赞送 star~
一、机器学习实时化
首先讲下机器学习的实时化，次要是分为三局部：
- 第一是样本的实时化。传统的机器学习，样本全部都是 t+1，也就是说，明天模型用的是昨天的训练数据，每天早上应用昨天的全天数据训练一次模型；
- 第二是特色的实时化。以前的特色也根本都是 t+1，这样就会带来一些举荐不精确的问题。比方，明天我看了很多新的视频，但给我举荐的却还是一些昨天或者更久之前看到的内容；
- 第三就是模型训练的实时化。咱们有了样本的实时化和特色的实时化之后，模型训练也是齐全能够做到在线训练实时化的，能带来更实时的举荐成果。
传统离线链路
上图是传统的离线链路图，首先是 APP 产生日志或者服务端产生 log，整个数据会通过数据管道落到 HDFS 上，而后每天 t+1 做一些特色生成和模型训练，特色生成会放到特色存储外面，可能是 redis 或者一些其余的 kv 存储，再给到下面的 inference 在线服务。
传统离线链路的有余
那它有什么问题呢？
- 第一是 t+1 数据模型的特色时效性都很低，很难做到特地高时效性的更新；
- 第二是整个模型训练或者一些特色生产的过程中，每天都要用天级的数据，整个训练或者特色生产的工夫十分长，对集群的算力要求十分高。
实时链路
上图咱们进行优化之后整个实时链路的过程，红叉的局部是被去掉的。整个数据上报后通过 pipeline 间接落到实时的 kafka，之后会做一个实时特色的生成，还有实时样本的生成，特色后果会写到 feature store 外面去，样本的生成也须要从 feature store 外面去读取一些特色。
生成完样本之后咱们间接进行实时训练。整个左边的那个很长的链路曾经去掉了，然而离线特色的局部咱们还是保留了。因为针对一些非凡特色咱们还是要做一些离线计算，比方一些特地简单不好实时化的或者没有实时化需要的。
二、Flink 在 b 站机器学习的应用
上面讲下咱们是怎么做到实时样本、实时特色和实时成果评估的。
- 第一个是实时样本。Flink 目前托管 b 站所有举荐业务样本数据生产流程；
第二个是实时特色。目前相当一部分特色都应用了 Flink 进行实时计算，时效性十分高。有很多特色是应用离线 + 实时组合的形式得出后果，历史数据用离线算，实时数据用 Flink，读取特色的时候就用拼接。
然而，这两套计算逻辑有的时候不能复用，所以咱们也在尝试应用 Flink 做批流一体，将特色的定义全副用 Flink 来做，依据业务须要，实时算或者离线算，底层的计算引擎全副是 Flink；
- 第三是实时成果的一个评估，咱们应用了 Flink+olap 来买通整个实时计算 + 实时剖析链路，进行最终的模型成果评估。
实时样本生成
上图是目前实时样本的生成，是针对整个举荐业务链路的。日志数据落入 kafka 后，首先咱们做一个 Flink 的 label-join，把点击和展示进行拼接。后果持续落入 kafka 后，再接一个 Flink 工作进行特色 join，特色 join 会拼接多个特色，有些特色是公域特色，有些是业务方的私域特色。特色的起源比拟多样，有离线也有实时。特色全副补全之后，就会生成一个 instance 样本数据落到 kafka，给前面的训练模型应用。
实时特色生成
上图是实时特色的生成，这边列的是一个比较复杂的特色的过程，整个计算流程波及到了 5 个工作。第一个工作是离线工作，前面有 4 个 Flink 工作，一系列简单计算后生成的一个特色落到 kafka 外面，再写入 feature-store，而后被在线预测或者实时训练所用到。
实时成果评估
上图是实时成果的评估，举荐算法关注的一个十分外围的指标就是 ctr 点击率，做完 label-join 之后，就能够算出 ctr 数据了，除了进行下一步的样本生成之外，同时会导一份数据到 clickhouse 外面，报表零碎对接后就能够看到十分实时的成果。数据自身会带上试验标签，在 clickhouse 外面能够依据标签进行试验辨别，看出对应的试验成果。
三、机器学习工作流平台构建
痛点
- 机器学习的整个链路外面有样本生成、特色生成、训练、预测、成果评估，每个局部都要配置开发很多工作，一个模型的上线最终须要横跨多个工作，链路十分长。
- 新的算法同学很难去了解这个简单链路的全貌，学习老本极高。
- 整个链路的改变牵一发而动全身，非常容易出故障。
- 计算层用到多个引擎，批流混用，语义很难保持一致，同样的逻辑要开发两套，放弃没有 gap 也很艰难。
- 整个实时化老本门槛也比拟高，须要有很强的实时离线能力，很多小的业务团队在没有平台反对下难以完成。
上图是一个模型从数据筹备到训练的大略过程，两头波及到了七八个节点，那咱们能不能在一个平台上实现所有的流程操作？咱们为什么要用 Flink？是因为咱们团队实时计算平台是基于 Flink 来做的，咱们也看到了 Flink 在批流一体上的后劲以及在实时模型训练和部署上一些将来倒退门路。
引入 Aiflow
Aiflow 是阿里的 Flink 生态团队开源的一套机器学习工作流平台，专一于流程和整个机器学习链路的标准化。去年八、九月份，咱们在和他们接触后，引入了这样一套零碎，一起共建欠缺，并开始逐步在 b 站落地。它把整个机器学习形象成图上的 example、transform、Train、validation、inference 这些过程。在我的项目架构上十分外围的能力调度就是反对流批混合依赖，元数据层反对模型治理，十分不便的进行模型的迭代更新。咱们基于此搭建了咱们的机器学习工作流平台。
平台个性
接下来讲一下平台个性：
- 第一是应用 Python 定义工作流。在 ai 方向，大家用 Python 还是比拟多的，咱们也参考了一些内部的，像 Netflix 也是应用 Python 来定义这种机器学习的工作流。
- 第二是反对批流工作混合依赖。在一个残缺链路外面，波及到的实时离线过程都能够退出到外面，并且批流工作之间能够通过信号就行相互依赖。
- 第三是反对一键克隆整个试验过程。从原始 log 到最终整个试验拉起训练这块，咱们是心愿可能一键整体链路克隆，疾速拉起一个全新的试验链路。
- 第四是一些性能方面的优化，反对资源共享。
- 第五是反对特色回溯批流一体。很多特色的冷启动须要计算历史很长时间的数据，专门为冷启动写一套离线特色计算逻辑老本十分高，而且很难和实时特色计算结果对齐，咱们反对间接在实时链路上来回溯离线特色。
根本架构
上图是根本架构，最下面是业务，最上面是引擎。目前反对的引擎也比拟多：Flink、spark、Hive、kafka、Hbase、Redis。其中有计算引擎，也有存储引擎。以 aiflow 作为两头的工作流程治理，Flink 作为外围的计算引擎，来设计整个工流平台。
工作流形容
整个工作流是用 Python 来形容的，在 python 外面用户只须要定义计算节点和资源节点，以及这些节点之间的依赖关系即可，语法有点像调度框架 airflow。
依赖关系定义
批流的依赖关系次要有 4 种：流到批，流到流，批到流，批到批。根本能够满足目前咱们业务上的所有需要。
资源共享
资源共享次要是用来做性能方面，因为很多时候一个机器的学习链路十分长，比方刚刚那个图外面我常常改变的可能只有五六个节点，当我想从新拉起整个试验流程，把整个图克隆一遍，两头我只须要改变其中的局部节点或者大部分节点，上游节点是能够做数据共享的。
这个是技术上的实现，克隆之后对共享节点做了一个状态追踪。
实时训练
上图是实时训练的过程。特色穿梭是一个十分常见的问题，多个计算工作的进度不统一时就会产生。在工作流平台外面，咱们定义好各个节点的依赖关系即可，一旦节点之间产生了依赖，解决进度就会进行同步，艰深来说就是快的等慢的，防止特色穿梭。在 Flink 外面咱们是应用 watermark 来定义解决进度。
特色回溯
上图是特色回溯的过程，咱们应用实时链路，间接去回溯它历史数据。离线和实时数据毕竟不同，这两头有很多问题须要解决，因而也用到了 spark，前面这块咱们会改成 Flink。
特色回溯的问题
特色回溯有几个比拟大的问题：
- 第一是如何保证数据的程序性。实时数据有个隐含的语义就是数据是程序进来的，生产进去立马解决，人造有肯定的程序性。然而离线的 HDFS 不是，HDFS 是有分区的，分区内的数据齐全乱序，理论业务外面大量计算过程是依赖时序的，如何解决离线数据的乱序是一个很大的问题。
- 第二是如何保障特色和样本版本的一致性。比方有两条链路，一条是特色的生产，一条是样本生产，样本生产依赖特色生产，如何保障它们之间版本的一致性，没有穿梭？
- 第三就是如何保障实时链路和回溯链路计算逻辑的统一？这个问题其实对咱们来说不必放心，咱们是间接在实时链路上回溯离线数据。
- 第四是一些性能方面的问题，怎么疾速得算完大量的历史数据。
解决方案
以下是第一、第二个问题的解决方案：
- 第一个问题。为了数据的程序性，咱们 HDFS 的离线数据进行 kafka 化解决，这里不是把它灌到 kafka 外面去，而是模仿 kafka 的数据架构，分区并且分区内有序，咱们把 HDFS 数据也解决成相似的架构，模仿成逻辑上的分区，并且逻辑分区内有序，Flink 读取的 hdfssource 也进行了对应的开发反对这种模仿的数据架构。这块的模拟计算目前是应用 spark 做的，前面咱们会改成 Flink。
第二个问题分为两局部：
- 实时特色局部的解决依赖于 Hbase 存储，Hbase 反对依据版本查问。特色计算完后间接依照版本写入 Hbase，样本生成的时候去查 Hbase 带上对应的版本号即可，这外面的版本通常是数据工夫。
- 离线特色局部，因为不须要从新计算了，离线存储 hdfs 都有，然而不反对点查，这块进行 kv 化解决就好，为了性能咱们做了异步预加载。
异步预加载的过程如图。
四、将来布局
接下来介绍下咱们前面布局。
- 一个是数据质量保证。当初整个链路越来越长，可能有 10 个节点、20 个节点，那怎么在整个链路出问题的时候疾速发现问题点。这里咱们是想针对节点集来做 dpc，对每个节点咱们能够自定义一些数据品质校验规定，数据通过旁路到对立的 dqc-center 进行规定运算告警。
- 第二是全链路的 exactly once，工作流节点之间如何保障准确统一，这块目前还没有想分明。
- 第三是咱们会在工作流外面退出模型训练和部署的节点。训练和部署能够是连贯到别的平台，也可能是 Flink 自身反对的训练模型和部署服务。
嘉宾介绍： 张杨，17 年入职 b 站，从事大数据方面工作。
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
