DB4AI：使能数据库原生AI计算，助力数据湖场景业务成功

DB4AI力图通过将AI计算能力植入到数据库中，帮助使用者们摆脱枯燥繁琐的数据搬运、导出、管理工作。利用数据库存储海量数据听起来是一件合情合理的事情，但面对一个传统型的数据库，作为算法工程师或者AI初学者的用户就不得不将数据集合的数据导出再导入AI计算框架以完成各自的计算任务。

细究起来数据搬迁是一件十分麻烦且耗费成本的事情。最直接的方法是将导出数据写入文件。在进行AI计算任务前，程序将文件中的数据读取出来喂给模型进行训练。

这里简单的列举几个明显挑战：

1、数据的安全性：

脱离了数据库的数据载体就不再具有包括权限限制、隐私保护等防护措施。数据被删除和被篡改的风险大大增加。对于一些领域，比如说金融领域、医疗领域，数据涉及敏感信息，在进行数据搬运的过程中需要对数据进行脱敏等操作使得敏感信息降级。

2、数据搬运成本：

在AI计算中，分析师算法师们希望将精力投放在模型设计和模型计算验证中，不会希望将成本花费在数据搬运和数据分享当中。遗憾的是，导出海量数据所花费的时间成本和算力成本是不可避免且不可忽略的。

3、数据的版本管理：

不论是AP还是TP数据库，都会存在数据的增删改查。对于在线学习，如何实时捕获新数据；对于离线学习，如何及时察觉数据集数据分布发生改变。为应对这两个问题，传统的处理方式可能需要增加更多的数据管控。同时，当发生数据飘移，有些用户需要更新数据集保持数据的有效性，那么又会遇到上述的第二个问题-增加成本。同时，针对不同的数据处理方式和过滤条件，用户需要存储不同版本的数据集。这样又进一步增加了存储成本。

针对以上这些问题，在具有DB4AI能力的数据库中将不再存在。数据库将AI框架内置到内部，就避免了数据搬运的尴尬，一切的计算过程将在数据库内完成。通过消除了数据移动环节，DB4AI从程序上避免了上述问题。

以下将简略地介绍openGauss数据库原生AI框架的使用情况：

1、DB4AI-snapshot：数据版本控制

DB4AI-Snapshots是DB4AI特性用于管理数据集版本的功能。通过使用快照的方式将数据集固定，功能分为MSS模型(采用物化算法，存储了原始数据集的数据实体)和CSS模型(采用相对计算算法，存储的是数据的增量信息)。其中增量模型相比于全量存储大大的降低了使用空间。

整个功能分为CREATE、PREPARE、SAMPLE、PUBLISH和PURGE几个操作，部分操作的示例如下：

1> 创建快照CREATE SNAPSHOT

openGauss=# create snapshot s1@1.0 comment is 'first version' as select * from t1;
schema |  name
--------+--------
public | s1@1.0
(1 row)

2> 采样SMAPSHOT

采用0.3作为采样率，在快照s1@1.0.0的基础上进行采样，生成的子快照后缀增加‘_sample1'。


openGauss=# SAMPLE SNAPSHOT s1@1.0 STRATIFY BY id AS _sample1 AT RATIO .3;schema |      name
--------+----------------public | s1_sample1@1.0
(1 row)

这个功能在AI计算过程中可用于，生成测试集和训练集，例如以下语法，进行2/8分：


openGauss=# SAMPLE SNAPSHOT s1@1.0 STRATIFY BY id AS _test AT RATIO .2, AS _train AT RATIO .8;schema |     name
--------+--------------public | s1_test@1.0public | s1_train@1.0
(2 rows)

3> 发布 PUBLISH

在snapshot特性中，除开发布状态的其他状态是不允许参与到AI计算当中的。当用户确定了当前快照中的数据为可用数据时，通过PUBLISH SNAPSHOT改变快照状态。快照的当前状态用户可通过db4ai.snapshot系统表查看。


openGauss=# openGauss=# select * from db4ai.snapshot;id | parent_id | matrix_id | root_id | schema |      name      | owner |          commands           |    comment    | published | archived |          c
reated           | row_count
----+-----------+-----------+---------+--------+----------------+-------+-----------------------------+---------------+-----------+----------+-----------
-----------------+-----------0 |           |           |       0 | public | s1@1.0         | owner    | {"select *","from t1",NULL} | first version | t         | f        | 2021-09-1617:15:52.460933 |         51 |         0 |           |       0 | public | s1_sample1@1.0 | owner    | {"SAMPLE _sample1 .3 {id}"} |               | f         | f        | 2021-09-1617:19:12.832676 |         12 |         0 |           |       0 | public | s1_test@1.0    | owner    | {"SAMPLE _test .2 {id}"}    |               | f         | f        | 2021-09-1617:20:46.778663 |         13 |         0 |           |       0 | public | s1_train@1.0   | owner    | {"SAMPLE _train .8 {id}"}   |               | f         | f        | 2021-09-1617:20:46.833184 |         3
(4 rows)

4> 删除快照PURGE


openGauss=# PURGE SNAPSHOT s1_sample1@1.0;schema |      name
--------+----------------public | s1_sample1@1.0
(1 row)

2、DB4AI原生AI语法：用于模型训练和推断

本功能通过特定语法query完成AI计算任务。当前在openGauss数据库内部，增添了AI算子，将算子添加到执行计划中，充分利用数据库的计算能力完成模型的训练以及推测任务。

当前openGauss中DB4AI引擎主要支撑4种算法（将在随后补充更多算法），分别是：逻辑回归算法(logistic_regression)、线性回归算法（linear_regression）、支持向量机（svm_classification)以及K-means聚类算法。

通过两个语法用于模型训练和推测：CREATE MODEL、PREDICT BY。

CREATE MODEL：用于模型训练。该语法在完成模型训练任务后，会将已训练好的模型信息保存在数据库的系统表gs_model_warehouse中，用户可随时通过查看系统表的方式查看模型信息。在系统表中不仅保存着模型描述信息也含有模型训练时的相关信息。

PREDICT BY：该语法用于推测任务。数据库通过模型名称查找系统表中相应的模型，并将该模型加载到内存中。数据库将测试数据输入内存模型中完成推测，并以临时结果集的形式返回结果。

以下就是简单的示例：

1、训练 CREATE MODEL

本示例以K-means聚类算法为例：

训练语法只有4个组成部分，分别是：模型名称、算法类型、训练集以及超参设定。

训练集支持表、视图、子查询等形式的输入。用户只需要通过1条查询语句，即可完成模型超参设定和指定训练集。接下来的环节包括输入数据、模型保存等数据库即自动完成。

当训练任务完成，数据库会打印成功信息。

此时模型已经写入系统表gs_model_warehouse中，用户可以通过表查询的方式查看模型信息：

2、推测 PREDICT BY

利用已保存好的模型进行推测任务。query示例如下所示：

在PREDICT BY语法中用户只需指定模型名称、测试集以及输入特征名即可完成推测任务。

总结和展望

DB4AI在数据库领域一直是一个热点话题。通过将数据库智能化，可以在AI计算的过程中降低门槛和成本，同时也可以进一步更加充分地释放数据库的计算资源。大数据和AI计算是一对好搭档，那么适用于大数据存储的数据库不应独立于这个体系。将两者有效的结合，不仅有利于AI计算过程，同时对于数据库本身的性能优化也增加了更多的可能性。

本次开源的openGauss数据库的原生AI框架正值朝朝，必存在许多的不足与缺憾。但‘万物智能’的愿景鼓舞着无数的研发者砥砺前行。

追风赶月莫停留，平芜尽头是春山。

DB4AI：使能数据库原生AI计算，助力数据湖场景业务成功相关推荐

DB4AI：使能数据库原生AI计算，数据搬迁由繁至简
DB4AI力图通过将AI计算能力植入到数据库中,帮助使用者们摆脱枯燥繁琐的数据搬运.导出.管理工作.利用数据库存储海量数据听起来是一件合情合理的事情,但面对一个传统型的数据库,作为算法工程师或者AI初 ...
边缘计算前沿专题 | 云原生边缘计算助力人机物融合泛在计算
云原生边缘计算前沿技术展望系列随着万物互联时代的到来和无线网络的普及,当下边缘计算领域蓬勃发展,边缘计算技术研究和产业转化进程如火如荼.本系列邀请到了学界领军专家和技术爱好者,共同洞察边缘计算先进技 ...
【2022分布式存储峰会】腾讯云存储为您带来：云原生时代下的数据湖存储服务
大会时间:今日15:00-15:30 大会主题:云原生时代下的数据湖存储服务 2022年4月14日,由百易传媒 (DOIT) 与厦门大学信息学院联合主办的"2022分布式存储论坛峰会&quo ...
HTAP数据库：Hubble加倍实现数据湖价值
98%的企业都面临数据孤岛问题,数据没标准.数据难统一.数据难打通.数据质量低.打通数据孤岛难度大周期长成本高,企业每年在糟糕的数据上多花费近25%的成本. 有痛点就有市场,数据湖应市而生. 为什么是 ...
云端数智新引擎，腾讯云原生数据湖计算重磅发布
引言是否遇到过,一个简单的业务统计需求却让数据工程师们抓耳挠腮? 是否遇到过,业务峰值周期明显,要么资源大量闲置, 要么线上疯狂告警? 是否遇到过,大数据集群运维复杂,需要投入大量技术工程师? 针对 ...
的数据湖_一文读懂云原生数据湖体系
导读:如何基于阿里云 OSS .JindoFS 和数据湖构建(Data Lake Formation,DLF)等基础服务,同时结合阿里云上丰富的计算引擎,打造一个全新云原生数据湖体系? 作者 | 吴威 ...
阿里云云原生数据湖体系全解读——元原生数据湖体系
阿里云首次发布云原生数据湖体系,基于对象存储OSS.数据湖构建Data Lake Formation和E-MapReduce产品的强强组合,提供存储与计算分离架构下,涵盖湖存储.湖加速.湖管理和湖计算 ...
一文读懂云原生数据湖体系
凌云时刻 · 极鲜速递导读:如何基于阿里云 OSS .JindoFS 和数据湖构建(Data Lake Formation,DLF)等基础服务,同时结合阿里云上丰富的计算引擎,打造一个全新云原生数据 ...
架构师必备：云原生数据湖体系
背景 " 数据湖 "正在被越来越多人提起,尽管定义并不统一,但企业们都已纷纷下水实践,无论是AWS还是阿里云.华为.我们认为:数据湖是大数据和AI时代融合存储和计算的全新体系. 为 ...

DB4AI：使能数据库原生AI计算，助力数据湖场景业务成功

DB4AI：使能数据库原生AI计算，助力数据湖场景业务成功相关推荐

最新文章

热门文章