关于机器学习:OpenMLDB在AKULAKU实时特征计算场景的应用

2次阅读

共计 7459 个字符，预计需要花费 19 分钟才能阅读完成。

本文依据 Akulaku 算法总监马宇翔在『OpenMLDB Meetup No.1』中的演讲整顿而成。
OpenMLDB 在 AKULAKU 实时特色计算场景的利用
马宇翔 AKULAKU 算法总监

AKULAKU 介绍
初识 OpenMLDB
业务场景利用
演进倡议

对于 Akulaku

Akulaku 公司成立于 2016 年，是一家专一于东南亚市场的金融科技公司。金融科技公司的显著特点，就是所有的业务都和钱间接相干。

Akulaku 的业务场景

从业务场景的角度，团队首先从相似于花呗的场景切入，随着业务逐步壮大，开始涉足虚构信用卡业务，目前 Akulaku 领有商业银行以及理财投资业务，所有业务均波及宏大的交易量。

科技助力业务疾速倒退

一直增长的用户量和交易量给风控系统带来极大的压力，团队首先须要保障公司风控的高水平状态，而这次要依赖于机器学习、CV、NLP、Graph 等人工智能技术，同时利用收集到的宏大数据量，推动业务倒退。

以上是 Akulaku 业务场景的大抵介绍，如果是业界同行，目前应该曾经能了解 Akulaku 为什么会十分迅速的上手 OpenMLDB 了。

AKULAKU 机器学习技术栈

下图是 Akulaku 以后的技术栈，目前技术栈的每一层均独立布局。

场景层：波及 CV、NLP、Speech、图开掘、AutoML 等各类算法，用于解决诸多业务场景所面临的问题，同时开发各类模型用于填补可能呈现的各种危险破绽
平台层：各个环节中，数据处理占据 80% 以上的资源和耗时，服务层和算法库根本采纳业界支流解决方案。

【02 | 初识 OpenMLDB】

AKULAKU 结识 OpenMLDB 的经验

第一次接触 OpenMLDB，是 2021 年 4 月份，彼时正在摸索 Spark 的优化问题，理解到 OpenMLDB 离线计算的前身 SparFE 发行版。6 月份加入第四范式的技术发布会，理解到 OpenMLDB，发现它正好切中了 Akulaku 的一个业务痛点。基于这个痛点，我开始钻研 OpenMLDB 的源码。过往尝试过阿里的闭源流批一体实时数仓解决方案，但因其闭源，且次要服务于阿里外部业务的起因，个性不是十分的贴合业务需要，但也无奈改变。第一次遇到一个开源的一体化解决方案，我感到十分好奇，于是基于 OpenMLDB 做了特定场景的测试。8 月看到 OpenMLDB 发表于 VLDB 2021 的性能优化论文。9 月份开始应用 OpenMLDB 解决具体业务问题。12 月在一个绝对比拟新的场景上基于 OpenMLDB 将离线特色开发上线实时环境，开始将 OpenMLDB 利用于生产环境。

AKULAKU 机器学习开发 pipeline

下图是一个通用的 Akulaku 结构化数据建模场景，通常由原始数据、特色工程、机器学习、风控模型更新等环节形成。基于海量原始数据，依据数据的根本属性，进行人工或者主动特色工程，抽取属性、文本、工夫序列等特色属性，通过超参数优化、模型抉择等实现模型构建，最终实现利用上线。团队过往基于 KubeFlow 实现模型更新，但特色更新始终是机器学习开发当中最大的痛点。那么，特色更新是否单纯通过堆砌计算资源来实现呢？

不限资源，就能马上算完吗？即使在不限资源的状况下，面对每天产生的 PB 级结构化数据，也难以无效的保障计算速度。
算完等于算得准吗？即使可能实现计算，也无奈保障计算结果的正确性。在 Akulaku 理论业务场景中，数仓和实时数据属于两套齐全独立的零碎，具备齐全不同的构造、定义、开发工具和逻辑。在这种状况下，很难仅仅通过上百行甚至几百行的简单 SQL 来保障两套零碎计算结果一致性。
公司的钱够花吗？若心愿同时满足算得快以及算得准的需要，须要招聘上千人的团队、大量的专家以及宏大的机器资源投入，一般公司只能望而生畏。

AI 零碎实质上是一个简单的工程问题

AI 零碎的构建实质上是个简单的工程问题，绝大部分工夫被用于海量数据处理以及零碎搭建，机器学习模型构建甚至能够说是消耗精力最小的环节。工业界的同学，应该深有同感。

模型人生命的敌人：对数

上面这张图来源于 OpenMLDB 的产品介绍，十分好的概括出咱们之前的日常工作状态。

数据科学家离线开发：Akulaku 的数据科学家，在数据平台上利用大数据框架，通过数据仓库、数据湖做离线数据特色抽取。特色抽取进去之后，用来训练模型，定义各类 SQL。
数据开发工程师上线服务：当数据科学家实现模型成果验证之后，把定义好的特色文件交给线上的数据开发工程师。数据开发工程师应用一套保障实时性、稳定性、可用性的形式做实时特色开发，实现服务上线

两个团队应用的甚至都不是一个规范的 SQL 语句。对离线来说可能有多种实现办法，甚至间接应用原生代码。但对于线上来说，必须应用硬代码解决实时性保障问题。离线开发和线上服务存在诸多逻辑上的不统一。而这种不统一在金融行业中十分难以解决，因为咱们模型的训练指标是用户的还款账单，还款账单通常以月为单位计数，这就意味着如果数据无奈无效对齐，须要至多一个月的工夫来判断离线和在线模型后果是否统一，而一个月的工夫耗费对于咱们来说是十分恐怖的老本。

因而，咱们目前面临的次要问题，详情来说能够分为研发零碎和团队、技术栈、实现逻辑以及效率和成果四个维度的不统一：

研发零碎和团队不统一。离线和在线齐全是两套零碎，两套不同的工具和平台，以及两类不同的使用者。线下数据挖掘次要是数据科学家依赖数据平台实现，线上特色生成次要是数据开发工程师依赖特色平台实现。
技术栈不统一。离线场景次要为 MPP 场景，以 Spark 作为主力工具，同时还应用了一些实时数仓工具，例如 Hive。在线场景次要为 OLTP 场景，试过很多种计划，比方 TiDB，PolarDB，Flink 等。Flink 可能又分很多种，比方滑动工夫窗口或者 CDC，每种办法也不太一样。
实现逻辑不统一。离线以模型成果为指标，为保障成果会应用各种工具和语言。在线要求应用同样一个特色，因为 A 模型和 B 模型同时应用的需要较难同时满足，为了解决这个问题，须要应用对立的 SQL 形容。然而每种大数据工具对 SQL 的反对也是不一样的，底层实现也存在差别，跑进去的数据无奈无效对应。
效率和成果不统一。对于离线工作而言，算力和工夫绝对富余，能够做比拟多的深度模型或者简单逻辑。但对于在线业务，比方下单场景的反欺诈，对于时效性、准确性、稳定性存在很高的要求。

这些不统一对于业务实现带来了很多问题，线上和线下数据对不上，轻则导致计划无奈应用、成果不达标，重则造成生产事变或者重大的线上缺点。从业务层面上，如果无奈疾速实现特色计算工作，导致用户须要消耗 1 分钟工夫期待欺诈交易验证，将造成极大的用户散失。咱们常常面临的理论情况是，破费大量工夫做出一个成果极高的线下计划，然而线上无奈应用。然而，如果斗争线上利用的时效和准确性，成果则会降落。最可怕的是，如果在对数环节甚至没有发现这个问题，那么上线之后必定就是生产事变或者线上的某类问题始终得不到解决，这都是金融畛域十分苦楚的点。如果每个特色都是几百行的 SQL 语句，齐全无奈在几天内解决。即使是激进预计，风控模型对数也往往要消耗模型开发同学靠近一半以上的工夫精力，甚至是以月为周期的工夫耗费。

OpenMLDB 的价值

OpenMLDB 提供对立的特色开发零碎、对立的技术栈、对立的逻辑实现以及对立的效率、效率

OpenMLDB 提供对立的特色开发零碎。OpenMLDB 的确是一个以模型开发为视角的数据工具。对咱们来说，特色开发应用 OpenMLDB，能够真正的实现由数据科学家来写 SQL，对数据科学家来说不会因为应用的工具性能差，或者无奈满足线上要求，而导致他必须把实时特色开发工作再交接进来，防止了由两个不同团队开发所造成的不一致性。
OpenMLDB 提供对立的技术栈。OpenMLDB 提供了线上和线下对立的技术栈。数据科学家不须要一边学习 Spark、PolarDB，一边学习 Flink，无效升高学习的门槛和上手的难度。
OpenMLDB 保障统一的逻辑实现。咱们测试过 OpenMLDB 每个底层执行函数跑进去的后果，是统一的。OpenMLDB 顶层的 SQL 表白，在线下改线上的时候，是统一的，只须要改一些前缀的语句。
OpenMLDB 提供统一的效率和成果。OpenMLDB 基本上可能保障线上执行的速度与线下计算的速度统一，不会呈现很大的偏差。咱们测试过线下数据计算，通过执行推到线上之后，速度基本一致。

过往应用传统的 Kafka+Flink 这套形式，线下版本和线上版本的速度并不能保障统一，万一线上呈现数据突增或者内存爆炸，或者数据散压回来，计算速度会受到很大的影响。

OpenMLDB 的这些一致性能力，对咱们来说具备很好的价值。

首先，简化开发计划。Akulaku 的一些模型，开始去让算法同学间接写 SQL，间接做线上部署。
其次，解放开发人员。因为这个劣势，能够把一些开发人员解放出来，去做一些更深度的、不那么重复性的工作。
第三，缩短迭代耗时。迭代的耗时缩短，不须要以月为单位去做模型一致性校验。
第四，防止线上事变。基于后面三点的加持，防止了一些线上事变的产生。

老本和收益

下图是咱们应用 OpenMLDB 之后老本和收益的统计。

老本：年化老本 200 万左右。目前咱们在尝试应用阿里云的神龙裸金属服务器长久化内存版本，大略靠近 2 万 RMB/ 台 / 月，8 台机器年化老本不到 200 万。
收益：节约资源激进预计 400 万以上。从收益上来讲，应用阿里云神龙服务器长久内存版本之后，之前的一些基于时序或者是 Spark 的大数据工具集群解放了进去，大略释放出来 20 台 128G 的机器，大略也是 200 万的机器老本。另外很多算法和数据开发工程师的精力也释放出来，数据开发工程师不须要反复的去做几百个特色，算法工程师解放出来不须要参加对数。激进预计，人力加机器老本的节约在 400 万以上。

这里补充一下，8 台机器是咱们目前临时的使用量，大家还是要依据本身企业外部的数据量以及应用的场景去配置适合的资源。

业务场景是我本次介绍的重点，咱们做了很多场景的尝试，本次展现的是咱们公司的要害业务场景，比方风控场景，以及 OpenMLDB 在实战中成果最好的几个场景，和大家分享。

场景 1 | RTP 零碎案例

RTP 服务是一个面向通用场景的排序服务。排序服务如果要做到通用，就会面临各类型特色的挑战。

咱们之前的做法，是首先做一个原始数据的实时数仓，在实时数仓的根底上，通过独立的特色服务去做特色生成。再把生成的向量，塞到模型里，模型产出的向量或者分数再放到纯正的排序机制里，就是咱们之前的排序零碎。

这套零碎存在一些问题，首先各个组件的切分会比拟显著，切分显著的益处，比方解耦。然而排序零碎的要害是速度优先，如果所有性能都是为最终后果垂直服务的话，那么咱们会偏向于做一个内聚化的事件。

在这个场景上咱们应用 OpenMLDB，从 Kafka 把数据写过来之后，间接在 OpenMLDB 外面做特色生成以及最初的排序，下图为应用之后的性能。

从性能的角度，将 OpenMLDB、MPP 计划及 Flink 计划进行比拟。每次 TopK 的查问都有实时的数据涌进来。对应的 MPP 计划存在的问题，每进入一条数据就须要实现一次全量的计算，导致耗时十分恐怖。而 Flink 的工夫窗口计划，性能是十分优良的，但毕竟不是一个做 TopK 排序的工具。而从柱状图能够看到，OpenMLDB 的成果简直是线性的。

在 Top1 的查问中，OpenMLDB 的查问速度仅为个位数，这里是 9.8 毫秒。
在 Top8 的查问中，Flink 可能实现不到 100 毫秒的性能，而 OpenMLDB 此时还是线性增长，查问速度在 20 毫秒左右。

从 OpenMLDB 的原理来看，应该是应用了即时编译的技术，使得 TopK 变成带参数查问，间接优化到执行的机器码，使得查问速度快速增长。

场景 2 | 通用简单计算

简单计算难以间接应用 SQL 各种常见计算公式进行表白，比方地理位置的查问，因为每次查问必须关注到所有 GPS 之间的绝对关系，所以每次查问必须基于全量数据。

从性能的角度，将 OpenMLDB 与 Spark 计划进行比拟

OpenMLDB 将 SQL 应用 LLVM 或 NVVM 动静编译为机器码，充分利用 SIMD 等办法解决简单查问，查问工夫根本在 30ms 左右
十亿级别地理位置信息基于 OpenMLDB 的毫秒级实时剖析，比罕用数据库快 30 倍以上，比 Spark 快 10 倍以上

如果基于 Spark 做 10 亿级数据的全量数据查问，图中的返回工夫不是 1000 毫秒的下限，而是间接 OOM。此外，还有一个很大的痛点，首先 Spark 的内存构造可能是有问题的，无奈对同质化以及实现工作比拟繁多的构造做优化，导致其内存存储的性能较差。

总结一下，这是我举荐大家应用的第二个场景，比方标签流传、图聚类、GPS 的实时剖析等工作，或者是其余须要用到全量数据然而执行比拟繁多的场景。

场景 3 | 团伙开掘

第三个场景是咱们最新做的尝试，团伙开掘场景。团伙在咱们外部或者说在任何一个金融企业的风控模型中，都是一个要害场景。

团伙开掘的特色是特色绝对简单，每个特色都须要关联到所有人的属性，导致每轮 SQL 计算简直都有数百行，个别也会达到上百个特色。

咱们须要从下单环节开始，实时的笼罩全副数据。而这又会带来第二个问题，比如说授信环节，还能做到分钟级，能够把数据全副拉进来做一个计算。然而下单环节基本上都是毫秒级的，如果就义数据覆盖度就会损失模型成果，如果要尽可能确保数据的准确性，则无奈在下单环节实时反馈，只能等用户实现下单能力做出预测，这就会有很大的问题。而 OpenMLDB 则可能十分好的进行大数量的实时处理。

过往实现形式，无奈满足团伙开掘业务场景对实时性以及硬实时的需要：

离线数仓 + T+ 1 团伙开掘算法，无奈满足实时性需要：咱们之前的实现形式是应用离线数仓以及 T + 1 的团伙开掘算法，比方 HG suspector 或者是一些标签流传的办法。最大的痛点是特色无奈硬实时的实现计算。团伙场景对于实时性要求很高，因为异样的欺诈团伙根本是撸完就跑，不会给风控很多的反应时间。可能一天的流动投放，当天就曾经被薅完了，如果第二天才发现其中某一批人是集中欺诈，那对业务的意义就比拟小。
实时数仓 + 实时图开掘，无奈达到硬实时成果：实时图开掘能够用增量的办法解决，然而实时数仓和线上流式特色的一致性就成为瓶颈。咱们之前始终没有找到一个好的解决方案，过后尝试过 Kafka + Flink CDC 来做，相对来说是勉强可用，能够做到异步实时，但受限于外存储的性能，无奈齐全做到硬实时的成果。

OpenMLDB 利用于团伙开掘场景，满足业务硬实时需要，实现几十毫秒至 200 毫秒的计算速度

能够说之前的计划在硬实时要求下都是不可用的，最近咱们应用 OpenMLDB 解决了实时特色计算，通过 OpenMLDB 以后反对的 SQL 语法把图的特色复现了一遍，同时推到线上做流式实时计算，测试发现 OpenMLDB 是可用的，耗时基本上都是满足业务要求的几十毫秒，不超过 200 毫秒的速度。

咱们也做了一些钻研，将 OpenMLDB 和一些时序数据库进行了比拟。目前来说时序数据库的劣势是对任何时序场景的通用性，包含 SQL 的覆盖度是有劣势的，然而对于专一场景，尤其是如果咱们须要一个偏模型化的，不是那么严格时序的场景，就会呈现一些问题，比如说可能不反对某些 join 的操作。因为时序数据库更多关注的是只有工夫线的单表的性能，在这点上 OpenMLDB 是有针对性的，而且 OpenMLDB 的开发难度显著低于时序数据库，所以最终咱们抉择了 OpenMLDB 的计划。过往的处理过程中，会做一些两头后果并联合排序服务进行排序，因为 OpenMLDB 具备很好的排序性能，能够无需进行中间环节，间接输入最初的后果。

第 4 局部介绍一下咱们应用后对 OpenMLDB 的演进倡议，也包含以后版本存在的一些须要留神的点。

模型开发工程师角度

SQL 语句办法反对和多表联结查问能够进一步欠缺：目前的 SQL 语句的语法和具体函数的反对，心愿能够进一步欠缺，多表联结查问有些时候还会有一些缺点
可将一些统计或模型办法整合为 SQL 语句调用模式，拓展特色开发的空间：能够把一些统计或者模型办法整合为 SQL 语句的调用模式，有点相似于 SQLflow，会把 PC 或者 onehot 整合成 SQL 语句的函数，写 SQL 的实现就能够调用，能够纯闭环的在 OpenMLDB 外面实现机器学习特色工程的全副工作。目前 OpenMLDB 反对 SQL 语法曾经简直能够实现 90% 的业务特色开发
数据开发工程师角度
以后版本的每次冷启动还比较复杂，简化对立数据筹备工作：因为咱们频繁做试验，发现每次冷启动是比较复杂的。咱们有 8 台机器，每次须要先把线下数据做成线上数据流式差不多构造的表，先把数据灌进去，而后能力把线上实时数据接入。这个其实有点像 Feast，Feast 咱们之前试用的时候也是有同样的个性，它只管做本人的治理，把所有的数据依照肯定的时序做排序，然而它并有去真正简化数据筹备工作，须要用户相熟 Feast feature store 的构造，能力很好的用它。我心愿 OpenMLDB 可能更贴近使用者的角度进行优化。
反对更长的工夫窗口，满足更大规模工作利用：工夫窗口上，心愿可能反对更长的工夫范畴。目前在 Flink 的应用上，90% 的特色能够通过 24 小时以内的工夫窗口解决。然而有一些特色，比方设施欺诈案例，同一个设施指纹 ID，可能会关联到 1 年内的多个设施，而 Flink 针对这类需要的成果不是特地好，我感觉这也是一个突破口。
运维工程师角度
拥抱云原生，提供云原生版本，升高运维老本：目前数据偏向于间接应用云原生数据库，因为作为一个十分依赖稳定性的组织，云原生会给咱们带来很大的劣势。相似于咱们这种中小型公司，不会本人去开发一套云零碎。
作为数据库产品，提供更多的撑持性工具，例如更欠缺的审计、日志、权限治理等反对：作为一个数据库产品，目前还是须要有一些更多的撑持性工具把它平滑的交接给运维团队，比方更欠缺的审计、日志、权限治理。目前因为权限治理问题，咱们外部搭了两套 OpenMLDB，线下开发应用测试环境，而后再把 SQL 复制到线上环境，因为咱们会很放心权限治理的缺失导致误操作，把线上的一些数据或者信息搞乱。

欢送大家关注开源机器学习数据库 OpenMLDB，或退出 OpenMLDB 技术交换群

开源地址：https://github.com/4paradigm/OpenMLDB

正文完