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.0
public | 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-16
17:15:52.460933 | 5
1 | 0 | | 0 | public | s1_sample1@1.0 | owner | {"SAMPLE _sample1 .3 {id}"} | | f | f | 2021-09-16
17:19:12.832676 | 1
2 | 0 | | 0 | public | s1_test@1.0 | owner | {"SAMPLE _test .2 {id}"} | | f | f | 2021-09-16
17:20:46.778663 | 1
3 | 0 | | 0 | public | s1_train@1.0 | owner | {"SAMPLE _train .8 {id}"} | | f | f | 2021-09-16
17: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框架正值朝朝,必存在许多的不足与缺憾。但‘万物智能’的愿景鼓舞着无数的研发者砥砺前行。
追风赶月莫停留,平芜尽头是春山。