共计 10994 个字符,预计需要花费 28 分钟才能阅读完成。
本文依据陈迪豪在『OpenMLDB Meetup No.1』中的演讲整顿而成。
基于 OpenMLDB v0.4.0 疾速搭建全流程线上 AI 利用
OpenMLDB 在立项开始就有很多性能的优化,包含基于 LLVM 的 JIT 优化,能够针对不同的 CPU 架构、Linux 服务器或 MAC 服务器,通过 LLVM 做对应的代码生成优化,甚至是最新的基于 M1 的 ARM 架构苹果电脑,也是能够让 OpenMLDB 针对这种场景做优化的。
后面提到了在局部场景 OpenMLDB 能够比 Spark 有 10 倍甚至 10 倍以上的性能晋升,其实也得益于咱们 对 Spark 做了很多代码优化,包含像开源 Spark 不反对的窗口歪斜优化、窗口并行优化等等,甚至咱们对 Spark 源码进行了革新,来实现这种定制化的针对 AI 场景的性能优化。
OpenMLDB 在存储上也有优化,传统的数据库服务大多基于文件,这种基于b+ 树数据结构的存储,对于高性能在线 AI 利用还是不太适宜,还可能须要针对时序特色做优化。咱们实现了针对分区键和排序键盘做的多级跳表数据结构,能进一步晋升 OpenMLDB 在时序数据上的读写性能。
近期咱们正式公布了 OpenMLDB 0.4.0 版本,这个版本也有很多性能和性能上的优化,那么本文会介绍 OpenMLDB 0.4.0 最新版本上的一些新个性,以及怎么基于这个新版原本疾速搭建一个全流程的线上 AI 利用。
首先做一个简略的自我介绍,我叫陈迪豪,目前在第四范式负责平台架构师,是 OpenMLDB 我的项目的外围研发和 PMC 成员,之前参加过分布式存储 HBase、分布式的基础架构我的项目 OpenStack 我的项目的开发,是机器学习中罕用的 TVM 框架的贡献者,目前专一于分布式系统和数据库的设计。
P3:
明天会给大家介绍三个方面的内容:
- OpenMLDB 0.4.0 全流程的新个性
- OpenMLDB 0.4.0 单机版和集群版的疾速上手
- 手把手教大家如何应用 OpenMLDB 来疾速搭建一个全流程的线上 AI 利用
【01 | OpenMLDB 0.4.0 的全流程新个性介绍】
OpenMLDB 0.4.0 全流程新个性 1 | 在线离线对立存储
第一个新个性是,OpenMLDB 的在线存储和离线存储对立了,即一致性的表的视图,右上角是咱们旧版本的表信息,通过 SQL 的 describe 语句,能够看到这个表名叫 T1,它的 Schema 信息,蕴含多少列以及每一列的类型,上面就是它的索引信息。
在 0.4.0 咱们新减少了一个对立的表视图,就是把离线存储和在线存储对立到一起了。右下角就是在一个一般表的定义上面,减少一个 offline 的 table 信息,信息中会包含:offline 存储门路、离线存储的数据格式、是否是 deep copy 等一些属性。
对立存储也是业界数据库外面很少呈现的设计,它实现了离线表和在线表共享一套表名和 scheme,共享一套索引信息,共享一个 SQL 解析引擎,咱们应用 C ++ 实现的 SQL 解析引擎来编译 SQL,而后共享同一个数据引入和导出流,也就是说离线表和在线表都能够应用雷同的 SQL 语句来做数据导入和导出,他们惟一的区别就是离线和在线别离有 独立的长久化存储。咱们刚刚提到的在线是全内存的高性能多级跳表存储,离线上咱们反对让本地的文件存储以及像 HDFS 这种分布式存储,来应答离线和在线不同的场景需要。
OpenMLDB 0.4.0 全流程新个性 2 | 高可用离线工作治理
第二个新个性就是,新减少了一个高可用的离线工作治理服务,叫 TaskManager Service,
高可用的离线工作治理服务,反对本地或 Yarn 集群上的 Spark 工作治理,反对应用 SQL 来做工作治理,像 SHOW JOBS, SHOW JOB, STOP JOB 等,都是通过拓展 SQL 语法来实现的。它内置反对多种数据工作,包含:导入在线数据,导入离线数据,导出离线数据。
OpenMLDB 0.4.0 全流程新个性 3 | 端到端的 AI 工作流
第三个重要的个性是,实现了真正的端到端 AI 工作流,能够基于 SDK 或者 CLI 命令行应用。
右边的列表就是咱们在做端到端 AI 利用落地的 8 个步骤,别离是:创立数据库、创立数据库表、导入离线数据、进行离线的特色抽取,而后应用机器学习框架进行模型训练、部署 SQL 上线、导入在线数据,以及上线在线特色服务。
从第 1 到第 8 个步骤,简直每个步骤都能够通过 OpenMLDB 的 SDK 或命令行来实现:
- 应用规范的 SQL 语句创立数据库和创立数据库表,这个是规范 SQL 就反对的
- 像导入离线数据,一些 SQL 方言也能够反对,例如 SQL Server 或 MySQL 能够反对相似这种 Load Data in File 的语法,即从文件导入数据到一个表中。
咱们也反对离线和在线的数据导入,以及离线的特色抽取,因为后面介绍了咱们特色计算都是应用拓展的 SQL 语言,咱们在命令行里集成了离线 SQL 工作的提交性能,你能够在命令行去执行一个规范的 SQL,比方这里的 select sum 语句,应用 SQL 提交工作后,因为它是离线工作,因而会提交到一个分布式的计算集群,比方 yarn 集群,而后做分布式的离线特色计算。
对于第 5 步机器学习模型训练:
- 咱们反对内部的机器学习训练框架,像 TensorFlow,PyTorch,LightGBM,XGBoost 或者 OneFlow 等;
- 因为咱们生成的是规范的样本数据格式,像 CSV、LIBSVM 或者 TFRecords 等,用户能够应用 TensorFlow 等框架来做模型训练;
- 这些框架也能够提交到本地、yarn 集群、k8s 集群等,来做分布式的训练;
- 反对应用 GPU 等硬件进行减速,跟咱们的特色数据库 OpenMLDB 是齐全兼容的。
模型训练当前,即咱们的 SQL 特色能够上线了,而后能够间接执行一个 Deploy 命令,接上要上线的 SQL,就能够上线咱们的在线特色服务了。这个也是咱们通过 SQL 拓展来实现的。
而后上线后的服务,须要给它注入一些历史的时序特色,咱们称之为特色的蓄水。用户的一些历史数据,也能够应用 Load Data 的这个 SQL 语句来实现。
实现当前,咱们外部会起一个反对 HTTP 和 RPC 接口的服务,客户端应用规范的 HTTP 申请就能够拜访了,或者应用咱们的 Java、Python SDK。将来咱们也会把这个性能集成到 CLI 中,来实现全流程的端到端 AI 工作流在命令行上的整合。
【02 | OpenMLDB 0.4.0 单机 / 集群版疾速上手】
介绍完 0.4.0 新增的全流程个性,那么接下来,就给大家疾速上手一下 0.4.0 的单机版和集群版性能。
首先单机版和集群版的区别是:
- 单机版部署简略,模块比拟少,只须要下载一个预编译的 Binary 就能够了,没有任何内部的依赖。单机版的性能也是齐全的,反对 Linux 和 MAC 操作系统,MAC 下基于 M1 芯片的 ARM 架构,或者是基于英特尔 CPU 芯片的 x86 架构也都是反对的。因而,它适宜于 功能测试 和小规模的 POC 测试。
- 集群版有残缺丰盛的功能集。
- 它 反对高可用,所有的节点都是高可用的,没有单点故障。
- 它反对大容量存储,尽管咱们的在线存储数据是放在内存里,然而它反对存储的程度拓展。随着数据量减少,只有程度减少通用的 x86 的存储服务器就能够了。
- 它是 高性能 的,无论是离线计算还是在线计算,集群版都能够反对分布式的并行计算,减速建模和特色抽取的工夫。
OpenMLDB 0.4.0 单机版疾速上手 | 启动单机版 OpenMLDB 数据库
单机版的起应用办法就非常简单了。单机版和集群版在 GitHub 上都是开源的,在 GitHub 下载的代码,底层就反对集群版的性能。对于单机版咱们提供了一个脚本,只有执行这个脚本,就会启动单机版须要的三个组件。左边是它的架构,包含一个 Name Server 服务和一个 API Server 服务,底层数据会存储在单个 Tablet 上,那么用户应用命令行或者 SDK 就能够拜访咱们的服务了。
OpenMLDB 0.4.0 单机版疾速上手 | 应用 OpenMLDB 客户端
客户端的应用非常简单,后面应用一个脚本启动完这个集群后,能够像 MySQL 这样,应用一个客户端的命令行工具,指定 IP 和端口连贯 OpenMLDB 数据库。连贯后会打印一些集群的根本信息,包含版本号等信息。
OpenMLDB 0.4.0 单机版疾速上手 | 执行规范 SQL
连贯上当前,咱们就能够应用规范的 SQL 语句了。
PPT 右边列举了咱们曾经反对的 SQL 语句,在咱们的文档网站中能够看到更具体的介绍。根底的 SQL,如 DML、DDL 等语句都曾经反对了,SELECT INTO和各种 SELECT 子查问语句 也是能够反对的。
左边就是一些执行 SQL 命令的截图。应用数据库个别的应用流程 就是:
- 创立一个数据库,而后Use 数据库,前面的 SQL 操作就会在默认的 DB 上实现;
- 咱们能够Create table,这也是遵循规范这种 ANSI SQL 语法的。但相比于规范 SQL,咱们在创立表的时候,还能够做索引和工夫列的指定;
- 通过Show tables,看到曾经创立好的 table。
咱们也反对规范的SQL 插入语句,把单条数据插入到数据库表外面,通过 select 语句能够查问,这是 OpenMLDB 作为一个最根底的在线数据库提供的一些性能。
OpenMLDB 0.4.0 集群版疾速上手 | 启动集群版 OpenMLDB 数据库
那么接下来我会介绍集群版。集群版的启动办法跟单机版相似,咱们会提供一个 star-all 脚本。集群版相比于单机版,有高可用以及多组件的特点。
- 首先它的组件会更多,除了咱们会启动后面提到的的 tablet,name server 和 api server 以外,咱们为了实现高可用,默认会启动两个 tablet,以保障所有的数据至多是两备份的。
- 用户能够在配置文件外面配置数据的备份数,以及集群的规模。
- 很重要的一点是,在 0.4.0 版本反对了离线的工作治理,因而也会减少一个叫 task manager 的高可用工作治理模块。
ppt 左边是一个根底的架构图,除了 OpenMLDB 自身以外,高可用的实现目前依赖一个 ZooKeeper 集群。OpenMLDB 的一些根底的元数据,包含主节点服务还有须要长久化的信息会存储到 ZK 下面,name server 启动后把本人的高可用地址注册到 ZK 上,tablet 会通过 ZK 来连贯主 name server 曾经监听一些元数据的更新。
OpenMLDB 0.4.0 集群版疾速上手 | 集群版 OpenMLDB 配置文件
集群版的部署会绝对简单,它新增了 task manager 模块,大家也能够简略看一下技术组件的配置文件,其中比拟重要的是,大部分组件都须要配置ZooKeep 的 IP 和门路,保障所有的组件都是连贯到同一个 ZooKeep 上,通过 Zab 协定实现高可用的元数据管理,来保障整个集群的高可用。
OpenMLDB 0.4.0 集群版疾速上手 | 应用集群版 OpenMLDB 客户端
应用集群版的客户端跟单机版略微有一点区别,在应用 OpenMLDB 命令行客户端的时候,它不再是间接指定 name server 的 IP 和端口,因为 name server 也是高可用的,它的 IP 端口在 Failover 时可能会变,所以咱们在启动的时候,须要配置 ZK 的信息,启动后会打印更多集群版相干的一些配置和版本信息等。
它的应用办法跟单机版是相似的,咱们能够通过后面提到的 SQL 语句,你能够把它当成一个超高性能的,基于全内存的时序数据库,或者是反对 SQL 的数据库来应用。
OpenMLDB 0.4.0 集群版疾速上手 | 应用集群版 OpenMLDB 高级性能
集群版还有一些更高级的性能,这里给大家介绍两个:
1. 离线模式和在线模式。 这是集群版特有的性能,因为单机版所有的计算都是在单机上,所以不会辨别在线模式和离线模式。集群版反对对于 HDFS 等海量数据的存储,离线计算底层目前也是基于 Spark 来做的。
那么离线模式和在线模式怎么应用的呢?
- 咱们反对一个规范 SQL 的 Set 语句,而后能够看到以后的 execute_mode 是 online 的,online 的时候咱们执行的 SQL 语句,都是通过在线模式执行的,也就是去查内存的数据。
- 通过 set @SESSION.exexute_mode = “offline”,就能够把模式切换成离线了。
- 能够看到以后模式是 offline,offline 模式的 SQL 查问就不是去内存外面查了,因为在实在的场景外面,比方风控或者团伙欺诈辨认,离线数据可能是海量的,可能是几 T 到几百 T 的规模。SQL 查问必定不是交互能马上返回后果的,而且这个查问后果也不可能齐全放在某一个节点做聚合。所以在离线模式下,咱们会把 SQL 的查问当成一个工作。能够看到工作的根本信息,蕴含工作 ID、工作类型、工作状态等等。
- 在执行完 SQL 当前,0.4.0 版本会提供一些命令,比方 Show jobs,查看工作的状态,查看日志信息等等,来实现这种离线的工作治理。这部分治理性能也集成到了 CLI 命令行之中。
2. 部署 SQL 到线上服务。 这是集群版和单机版都反对的。这点是其余在线数据库不反对的。用户在创立完数据库和数据库表当前,对于某一个做完特色抽取的 SQL,科学家认证比拟无效后,能够通过 Deploy 命令来上线,而后再通过 SHOW DEPLOYMENT 就能够看到咱们曾经部署的服务,这有点相似在 SQL 外面的一个存储过程,每一个 Deployment 都对应一个可上线的 SQL。咱们作为用户应用线上服务的时候,它能够通过 deploy 的名字来做在线 SQL 的执行,这点跟咱们的存储过程是相似的。
【03 | Workshop – 疾速搭建全流程线上 AI 利用】
最初,我会通过一个 workshop,带大家疾速地从命令行开始,从头搭建一个全流程的线上 AI 利用。
利用场景
这是咱们演示的场景,一个 Kaggle 的比赛,叫 New Your City Taxi Trip Duration,一个预估行程工夫的机器学习场景。咱们会下载较量提供的一个计程车历史行程数据,开发者或者建模科学家须要依据这些数据,应用机器学习的办法,来预估新给出的测试集来预估行程工夫。训练数据并不大,一共是 11 列,大略是 100 多万行,它的特点是蕴含了 Timestamp 的时序数据,对于行程预估场景时序数据是比拟重要的。咱们须要依据每个出租车行驶的历史记录,还有前序的一些特色,来做最终行程工夫的预估。
OpenMLDB 0.4.0 技术计划
这次演示应用基于 OpenMLDB 0.4.0 的技术计划,这里先汇总了一下:
- 特色抽取语言 :应用的是迷信建模科学家最相熟的SQL 语言;
- 模型训练框架 :这个例子外面应用的是LightGBM,当然大家如果想应用TF 或者 PyTorch 也是能够反对的;
- 离线存储引擎 :应用 本地的文件存储 ,因为它样本的数据量其实并不大,只有 100 多万行,可能就是几十兆的数据,在理论场景中,机器学习的样本可能会更大更简单,那么 OpenMLDB 也是能够反对HDFS 存储 的;
- 在线存储引擎:应用OpenMLDB 的高性能时序存储,一个基于多级跳表数据结构的内存存储;
- 在线预估服务:应用的是OpenMLDB 自带的 API server,提供的是规范的 Restful 接口和 RPC 的接口。
第一步:运行 OpenMLDB 镜像
接下来就大家来演示一下,咱们在应用 OpenMLDB 建模的时候,首先须要搭建一个 OpenMLDB 数据库运行环境。
OpenMLDB 自身提供了一个测试的 demo 镜像,OpenMLDB 的底层实现是基于 c ++ 的,自身会比较稳定和易装置。咱们在应用 OpenMLDB 的时候,能够应用咱们在 GitHub 上提供的官网 docker 镜像。mac 环境或者 Linux 环境也能够间接下载咱们的源代码,本地编译和执行。
执行完就进入了该容器,截图就是它残缺的 docker file 内容。为了 demo 演示,咱们多装置了一些库,比方 pandas,python,大家应用的时候只须要装置镜像和 Binary,就能够通过一个脚本把 Binary 下载下来,并启动服务端和客户端了。镜像的内容也是十分洁净的,不须要去下载一些额定的组件。
第二步:启动 OpenMLDB 集群
第二步就是启动 OpenMLDB 集群,能够应用 init.sh(咱们封装好的一个脚本),或者 OpenMLDB 我的项目外面提供的 start 脚本,也能够间接用本人编译的 Binary 来启动。
因为咱们这次演示的集群版的残缺性能,所以咱们会先启动 ZooKeeper 服务,并启动咱们依赖的一些组件,像 tablet、name server、API server 和 task manager。只有把这几个组件启动当前,咱们就领有了集群版 OpenMLDB 的性能。大家如果感兴趣,也能够看 sh 脚本的内容,init.sh 也会反对单机版和集群版,咱们应用集群版会多启动了一个 ZooKeeper,以及所有的 OpenMLDB 的组件。
组件的启动其实也是非常简单的,就是 start-all 的脚本内容。咱们会定义很多个组件,并做一个循环,把每一个组件都独自起起来。这些组件的启动是通过 OpenMLDB c++ 我的项目编译进去的一个 binary,当然不同平台要在对应的平台上编译进去,而后应用一个 mon 工具把它启动起来就能够了。
第三步:创立数据库和数据表
服务曾经启动后,咱们能够用一个相似 MySQL 的客户端做连贯。只有配置好 ZK 的地址,就能主动找到 name server 的地址,进入到数据库的外面,此时,就能够执行大部分规范的 SQL 语句了。
这里为了演示咱们计程车端到端的机器学习建模流程,咱们将:
- 先创立一个测试用的 DB,create database,而后再 use database;
- 此时通过 show databases 命令就能够看到 database 曾经创立好了;
- 而后咱们在 database 外面创立一个表,因为还没开始做离线模型训练,咱们无奈提前晓得表须要建什么索引,所以咱们反对用户不指定索引来创立表。当初能够看到表大略有十一列,而后这个表对应的就是 Kaggle 较量的数据集,他提供的 11 列的数据类型,其中包含多列 timestep 类型的数据。
- 此时能够看到 create successfully 了,表曾经创立好了,叫 t1。
第四步:导入离线数据
第 4 步咱们就须要开始导入离线数据了,把 Kaggle 比赛外面提供的训练数据导入进来,目前反对多种数据格式的导入,包含 parquet 格局和 csv 格局。
为了进行离线的数据导入,咱们须要把以后的执行模式切换成离线,而后通过 load data 语句而后来进行。
为什么要切换成离线呢? 如果没有切换成离线的话,此时的数据导入就会变成在线数据导入。如果离线数据量特地大,或者数据是从 HDFS 导入的,那么全副数据导到咱们的在线的内存存储是不靠谱的,所以把执行模式切换成离线十分重要。
而后执行一个导入的 SQL,这个 SQL 会提交一个工作,通过 show jobs 就能够看到这个工作的状态,它是一个 ImportOfflineData 的一个工作,大略几秒钟这个工作就曾经实现了,数据就曾经导入了进来。
咱们从新看一下数据库,能够看到在刚刚导入的时候,是还没有导入离线数据的,没有离线的这些地址的。在离线导入胜利当前,表的属性外面就会蕴含离线的信息,它示意离线的数据曾经导入到以后的某个门路上,能够看到这个数据文件也正确导入了。
第五步:应用离线数据进行特色抽取
咱们持续刚刚的演示,先把模式切换成离线。离线数据导入当前,就能够进行离线的特色抽取,这个步骤不同的建模场景破费的工夫不同,须要有建模科学家来抉择须要抽取须要什么特色,而后去一直地调整特色抽取的 SQL 脚本。
接下来咱们能够应用 over window 滑动窗口 来做时序特色,去求它的 min、max 等聚合值,也能够取单行的特色,对某一行做一个单行的计算。
最初 SQL 执行完当前,咱们要把特色抽取后的样本数据寄存到一个地位,能够让它导出到 本地的某个门路 ,如果说数据量比拟大,也能够导出到一个HDFS 分布式存储 外面。
此时能够看到这个工作执行胜利了,通过 show jobs 就能够看到 job ID 是 2,job 的状态从最开始的 submitted 变成了 running,因为它在分布式地执行,尽管不是一个很简单的 SQL,然而它的数据来自 t1 离线数据。在实在的离线特色抽取外面,数据量可能十分大,不可能在本地内存外面实现 SQL 的计算,所以咱们会把这个工作提交到一个 本地或者 yarn 上的 Spark去执行。
大家能够看到这个状态曾经变成了 finished,阐明这个数据曾经导出胜利了。刚刚咱们的 SQL 语句指定了导出门路,在命令行看到样本数据曾经正确导出了。为了反对更多的训练框架,除了默认反对的 csv 格局还反对其余样本格局,这个数据文件的内容就是通过刚刚的 SQL 语句产生的样本数据,
第六步:应用样本数据进行模型训练
这个样本数据就能够应用开源的机器学习框架来做训练,这里应用咱们的 train 脚本,大家也能够简略看一下它的内容,首先它引入了 lightgbm 第三方库,后面须要你输出刚刚指定的特色文件门路,以及它须要导出的模型的门路。
而后后面是对样本数据做一个整合,把多个 csv 文件整合成单个 csv 文件,而后通过 panda 把 csv 的特色读出来。上面是建模用户十分相熟的机器学习建模脚本:
- 首先是对样本进行训练汇合、预估集的拆分,把他的 label 列提取进去;
- 把 python 的 dataset 传进去,并配置一下咱们应用的机器学习模型,像 GBDT 或者决策树、DNN 模型都能够;
- 应用 lightgbm 的 train 函数就能够开始训练了。
这个脚本也能够替换成任何 TensorFlow、PyTorch 或者是 oneflow 等开源机器学习框架的训练脚本。咱们执行这个脚本,因为它的样本数据并不是很多,所以他很快就把新的模型训练完并导出到输入门路上,后续咱们就能够应用这个模型做模型上线了。然而大家肯定要思考到咱们模型上线并不只是 model 的 influence,咱们的输出数据是 Kaggle 提供的原始数据,所有的端到端机器学习流程肯定是包含特色抽取,还有模型的 influence 的。
第七步:部署 SQL 上线
咱们须要应用 OpenMLDB 提供的一个高性能的在线特色计算性能,把刚刚做的建模的 SQL 上线。咱们从客户端从新进入 OpenMLDB 数据库外面,切换它的默认 DB,SQL 的部署跟后面的 SQL 离线特色计算是一样的,此时,并不需要对某一个特色做非凡的开发,咱们只须要应用雷同的 SQL 语句,后面加上 deploy 语句,就能够做 SQL 上线了。deploy 的时候它会对某些键做分区,对工夫列做排序,咱们会对这些键别离提前建好索引,对这些数据进行依照索引来排列存储。
第八步:导入在线数据到 OpenMLDB
Deploy 完当前就能够做在线预估了,预估的时候咱们必定是心愿实现在线预估的,因为咱们做的特色是这种时序窗口特色,咱们心愿每个特色计算的时候,大家都能够依据前一天的窗口来做 min 或者 max 的聚合,所以咱们个别会进行一个 蓄水 的操作,就是把一些 线上数据导入到在线的数据库 外面。在线的导入也是一个分布式的工作,咱们执行完当前就能够看到提交了一个 job,job 目前也运行得很快,在本地环境里它的性能是十分好的,能够看到这个 job3 曾经实现了,数据曾经导入了。
第九步:启动 HTTP 预估服务和在线预估
有了导入后的在线数据,第 9 步咱们就能够启动预估服务做在线预估了。预估服务包装了一下,有个叫 start predict server 的脚本,这个脚本是咱们封装的一个很简略的 Python HTTP server,HTTP server 就会把一些客户端数据包装申请到 API server,最初会打印后果。原始数据进来当前,通过特色计算失去样本数据,并且会去加载刚刚模型训练失去的 LightGBM 模型,要应用模型来接管在线返回的特色样本,而后再把这个预估后果给返回进来。
第十步:进行在线特色抽取计算
咱们先启动 predict server,最初一步就是做在线的 predict。
在线的 predict 是咱们封装的一个脚本,这个脚本就是一个HTTP 的 client,会把咱们提供的原始数据列(这些输出包含字符串类型数据,不是特色抽取后的样本)作为参数传入,通过 Python 间接执行,这里执行得很快,单次在线的特色抽取能够做到 10 毫秒以内。
这个执行速度是如何做到的呢? 这跟咱们用户建模的 SQL 复杂度无关,像这种简略的特色,数据量比拟小的话,甚至能够做到 1 毫秒以内,纯特色计算的工夫,加上模型预估的工夫,用户简直没有感知就马上返回了。这里别离是通过咱们 SQL 语句来做的特色样本在线的样本,而后这个是通过 lightgbm 返回的一个模型预估后的数据。
有些人可能感觉这跑几个脚本如同也没什么,你只是做了一些 SQL 的计算而已,我去 MySQL 外面查这个数据,如同也能够做到几十毫秒或者 100 毫秒以内返回。区别是什么呢?
- 像刚刚有观众提到的 Feature store 也能够反对这种特色存储,而后它也能够反对简略的特色计算,例如你传一个特色,trip_duration 可能是 10,而后你的特色是对它做归一化或者给它做一个变换,这种其实都是 单行的特色,显然单行的特色性能是十分高的,无论是用 Python 还是 c ++ 来实现,你对于一个原始数据做一个乘法做一个加法,简直就只须要一次 CPU 计算。
- 而咱们反对的特色其实是一个 滑动窗口的时序聚合特色 ,在计算输出的某一行数据时,计算的并不是只对这一行做一个数值计算,你须要从数据库外面去把这一行它一天以前的所有的数据给拿进去,而后依据 ROWS BETWEEN 或者 RANGE BETWEEN 的这种窗口定义语法,去做窗口的滑动,而后对窗口内的数据再做一个聚合。咱们 10 毫秒以内的性能其实是 对于这两个特色 ,而后 别离做不同的聚合 失去的后果。
- 如果不是应用专门的时序数据库,例如咱们是从 MySQL 外面去获取它的以后行数据的前一天的所有的数据,可能窗口数据获取就要超过 100 毫秒,咱们能够做到窗口数据获取,还有窗口特色计聚合计算以及最初的模型预估,整体工夫都能够管制到 10 毫秒到 20 毫秒以内,这个是跟咱们的存储架构设计是密不可分的,也是咱们 OpenMLDB 跟其余的这种 OLTP 数据库的区别。最初咱们就能够失去一个预估的后果。
上线全流程 AI 利用总结
那么总结一下上线全流程 AI 利用的 10 个步骤,其实后面都比较简单,就是启动 openMLDB 集群,创立数据库,创立表,而后进行离线数据导入和离线的特色计算。当特色抽取的 SQL 没问题当前,咱们就能够做 SQL 的上线了,上线后会启动一个反对 http 的预估服务,而后进行一个预估。在 0.4.0 版本中,简直所有步骤 都能够在 SQL 的命令行 上执行和反对。将来咱们也打算去反对 基于命令行的在线特色抽取 ,甚至能够 在命令行上拓展 SQL 语法 来反对在命令行上做模型的训练等。
最初简略总结一下本次分享,首先给大家介绍的是 OpenMLDB 0.4.0 全流程的一些新个性,以及单机和集群版的疾速上手,最初通过一个 Kaggle 较量场景来给大家演示一下,怎么应用 OpenMLDB 疾速搭建一个可能上线的 AI 利用。
欢送大家来参加到咱们的社区,目前我的项目的所有的文档和代码都在 github 上,如果大家感兴趣,也能够参加 issue 的提交以及 pull request 代码开发。欢送大家也扫码退出咱们的微信交换群,我这边的分享就到这里,非常感谢大家的收听。