关于后端:Flink-ML的新特性解析与应用

摘要：本文整顿自阿里巴巴算法专家赵伟波，在 Flink Forward Asia 2023 AI 特色工程专场的分享。本篇内容次要分为以下四局部：

1. Flink ML 详情
2. 在线学习的设计与利用
3. 在线推理的设计与利用
4. 特色工程算法与利用

一、Flink ML 详情

Flink ML 是 Apache Flink 的子项目，遵循 Apache 社区标准，愿景是成为实时传统机器学习的事实标准。

2022 年 1 月份 Flink ML API 公布，7 月份公布齐备、高性能的 Flink ML 基础设施，2023 年 4 月份发力特色工程算法并服务用户，6 月份反对 Flink 多版本。

二、在线学习的设计与利用

2.1 在线机器学习工作流样例

有两个模型 AB，用 online 在线学习的形式去训练这两个模型，并且应用模型去进行在线推理，在推理过程中这个模型是流动模式，叫做 Model stream（模型流），以模型流的形式将模型一直地流入链路中，使模型具备更好的实时性。推理完结之后，推理样本会举荐给一些后方的客户，客户对后果进行反馈，再进行一些样本的拼接，最初返回到训练的数据流造成闭环，这就是工作流样例。

接下来以工作流样例来介绍在线学习的设计。训练数据进行切分后，切成不同的 window，每个 window 在通过 Estimator 的时候须要更新外面的模型，之后该模型会流到上面推理的链路中，随着数据的一直流入，模型会一个接一个的往推理的链路中流动，这就是 Model stream（模型流），其思路是通过把模型做成一个队列的形式去反对推理以达到更好的时效性。

存在的问题：

1. 如何使数据拆分更加正当？对不同的业务有不同的要求，有的心愿用工夫，有的心愿用大小，都须要一些策略。
2. 因为数据和模型都是流动的，两个往同一个中央去流，那么如何决定一条样本来了之后用哪个模型进行推理？
3. 如何保障模型的一致性？因为链路中有两个模型，如果两个模型的训练数据不统一会导致呈现一些问题。
4. 数据是用哪一个模型推理进去的？每一条样本是哪个模型推理进去的，预测的好坏须要去追溯源头。

2.2 在线机器学习的设计

针对四个问题，有四条设计需要：

1. 反对将输出数据划分为多个 window 进行训练，产生一个模型流。
2. 反对应用输出的模型流来对数据进行预测。
3. 反对用户指定推理数据和以后模型数据的时间差。每一条样本来了之后，咱们心愿用最新的模型去进行推理，然而最新的模型可能还没有训练进去，这个时候就须要设定一个时间差，容许它用非最新的模型进行推理。
4. 反对在输入数据中裸露预测每条数据时应用的模型版本。从预测后果追溯出模型的需要。

针对这些需要，咱们的设计方案是：

1. 减少 HasWindows 接口。
   容许用户申明划分数据的不同策略。
2. 为 ModelData 减少 model version 和 timestamp。
   model version 的值从 0 开始，每次减少 1。
   模型数据的工夫戳为训练失去该模型的数据的最大工夫戳。
3. 减少 HasMaxAllowedModelDelayMs 接口。
   容许用户指定预测数据 D 时，应用的模型数据 M 早于 D 的工夫小于等于设定的阈值。
4. 减少 HasModelVersionCol 接口。
   推理过程中，容许用户输入预测每条数据时应用的模型版本。

有了计划之后再回来看问题：

1. 怎么切分 window：
   提供 window 策略，用户能够依据本人的需要去做一些适宜本人业务场景的切分。
2. 抉择哪一种模型来推理以后数据：
   通过阈值参数设定容许离以后数据多远的模型进行推理；实践上能够用最新模型，然而可能会造成期待之类的问题。
3. 对于模型的一致性：
   每一条样本在预测的时候都会带一个模型版本，通过第一个模型预测再到第二个模型推理的时候会主动获取版本号，两边用同样的版本进行推理，最初输入的后果会带有一个版本号。

这样就把最后提的四个问题解决了。

2.3 在线学习在阿里云实时日志聚类的利用

阿里云 ABM 运维核心会把阿里所有平台的日志都收集到一起，而后会针对谬误日志做一个聚类，把谬误日志发送到对应的部门，去进行后续的解决。

传统算法工程链路首先进行数据输出，用 Flink job 进行数据加工解决，数据会落盘，之后通过定时调度来拉起聚类算法，而后写出模型，这个模型再通过加载的形式拉起 Flink job 进行数据预测，然而整个链路具备局限性，流程比较复杂，运维老本比拟高，实时性低，并且性能难以保障。

日志聚类算法流程把系统日志进行预处理和编码后分词，做特征选择提取关键词，而后做日志的特色示意和标准化，再做档次聚类，日志的类别，最初写出到数据库，用来领导分词。

针对该流程咱们应用 Flink ML 构建流式日志聚类就能够把这个流程串起来。通过 Flink job 拼接 SLS 与数据库全量数据，接着进行荡涤和编码日志数据，而后分词和标准化，计算聚类后果，最初选取簇内典型代表日志。

把这个案例中的算子进行抽取，像 SLS 流式读取，分词，日志的向量化，特征选择，特色的标准化，这些并不是业务独有的，而是很多在线学习业务都须要的算子，把它抽取进去，做成一个独立的组件，客户须要做在线学习流程的时候能够来复用这些算子。

日志聚类算法链路降级的收益：

• 在链路提早方面，将原来 5 min 的提早升高到 30s
• 经营老本升高，当初只须要维持 1 个 Flink 作业
• 剖析老本升高
• 算法性能晋升

三、在线推理的设计与利用

推理次要分为：

1. 批量推理：例如，有 100w 条数据落盘，而后起一个批的工作对这 100 万条数据进行推理，再进行落盘。
2. Near-line（近线）推理：基于 Flink 的工作，读取 Kafka 数据，通过 Transformer 的形式对流式的数据进行推理。这种推理有一个比拟大的问题是提早比拟高，个别在百毫秒量级，在理论的业务场景中，推理须要很低的提早，个别是几十毫秒甚至几毫秒，这就须要咱们做一个推理框架去适应高要求的业务场景。

在做这个之前咱们对 Spark ML 的推理进行了一个调研。起初发现 Spark ML 自身是没有推理模块的，它有一个 mleap，把 Spark 推理这部分做成一个推理框架，这个推理框架与引擎 Runtime 齐全无关，缩小依赖抵触，是一个更轻量的框架，另外这个新框架能够为推理重写计算逻辑代码，领有更大的优化空间。

3.1 设计需要

设计需要借鉴了 mleap 的做法：

1. 数据表示 (与 Flink Runtime 无关)

   • 单条数据表示：Row
   • 批量数据表示：DataFrame
   • 数据类型示意，提供 Vector、Matrix 等类型的反对
2. 推理逻辑示意

3. 模型加载

   • 反对从 Model/Transoformer#save 的文件中加载
   • 反对动静加载模型数据，而不须要重启

4. Utils

   • 反对查看 Transformer/PipelineModel 是否反对在线推理
   • 串联多个推理逻辑成单个推理逻辑

在这个设计需要下，右边是推理的数据结构 DataFrame，蕴含了 Column names, Column types, Row，进入推理逻辑之后输入还是同样的数据结构，这样整个推理构造就能够串起来，不须要有数据结构转换。

模型加载这边都是通过 save 函数将模型写入到磁盘，右边的 save 是 Flink ML 做的事件，左边的 loadServable 是推理框架做的事件，通过这两个函数实现了模型的保留加载和推理。

接下来以逻辑回归为例来看代码的实现，通过 save 函数把模型写出到指定的目录，上面的 load 是推理框架做的事件，以 load 模型的文件去做推理。

模型的数据更新这部分是通过把一个模型写入到 kafka 外面，kafka 再 set 到模型的 Servable 外面，当把模型写入到 kafka 里的时候模型会自然而然的流入到 Servable 外面，最终实现模型的动静更新。

上面是代码

setModelData 的输出是 InputStream，它能够从 kafka 里读入，当更新 kafka 里的数据时它就能够更新到模型外面。

另外咱们也反对 PipelineModel 推理，能够从 PipelineModel 的模型数据构建 Servable, 查看 PipelineModel 是否反对在线推理，不须要执行训练作业就能判断。

3.2 应用场景

最初来看应用场景，这是一个简化的 ML 模型训练、预测和部署的流程。首先是读入数据，做特色工程，而后做评估和部署。这边应用 PipelineModel 将标准化和 GBT 分类这两个模型打到 Pipeline 外面去，再去做在线的推理服务。

以下是代码

将标准化和 GBT 两个模型通过 Pipeline 写出去，在推理模块中最终实现 Pipeline 的推理，并且推理反对写出和动静加载。

四、特色工程算法与利用

4.1 特色工程算法

新增 27 个算法，总共 33 个，根本笼罩罕用算法。

4.2 特色工程的利用

首先是做举荐，广告的评估，都须要特色的解决。第二个利用场景是用于实现一些简单的算法，以 GBT 为例，解决数值特色和解决类别型特色。另外在大语言模型这块，Flink ML 也做了一些设计。

接下来以大语言模型为例，来看特色工程的业务。高质量的文本输出能够取得更好的大语言模型，而文本近似去重能进步文本品质。对于互联网数据来说，文本反复的比例通常 20%-60% 之间，文本规模越大，反复比例越高。

针对这个问题，咱们设计了近似去重流程：

• 不同于准确去重：不要求完全一致，或者子串关系
• 基于部分敏感性哈希 Locality-sensitive hashing：类似的样本更容易被 Hash 到雷同的 buckets 内
• 对于文本数据来说，通常基于文本特色化后的 Jaccard 间隔，应用 MinHashLSH 来找到类似文本

通过这些组件，能够实现文本去重流程：

• Tokenizer：进行分词
• HashingTF：将文本变换为 Binary 特色
• MinHash：计算文本签名
• MinHashLSH：进行 SimilarityJoin，找到类似对

最初是性能的测试，这是手动结构的 Benchmark 数据集，间接通过复制、删除之类的操作拿到一个数据集。对于 5 亿的数据，反复率为 50%，耗时大略 1.5h，前面是对应的去重成果。

Flink Forward Asia 2023

本届 Flink Forward Asia 更多精彩内容，可微信扫描图片二维码观看全副议题的视频回放及 FFA 2023 峰会材料！

更多内容

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
59 元试用 实时计算 Flink 版（3000CU* 小时，3 个月内）
理解流动详情：https://free.aliyun.com/?pipCode=sc