作者:Ni Demai,是NineData数据库产品专家,曾任阿里云数据库国际产品总负责人,华为高斯 GaussDB 创始团队核心架构师,IBM Db2 资深研发工程师。 Demai 专注 Cloud-Native database 架构设计,分析型 MPP,企业数据库开发及生态,并且积极参与开源社区建立和发展。
OpenAI的突破震撼整个市场已经半年有余,在初期的震惊之后,整个业绩膝跳反应,全体搭车。训练大模型有之,抓紧囤货有之,直接改BP的最多。
靠数据库吃饭多年的我却纠结在思考漩涡中。N多年前的项目申请的PPT上就写过AI-powered Optimizer [1],而且是深思熟虑过的三步走(这样三年都有经费了)。后来慢慢的AI for DB或DB for AI陆续出现了,我已经记不清是在哪个东家的规划策略中了,大概是都有的。AI for DB,比如NLP to SQL(现在太多了 [2]), ML-Based buffet pool 调优,当然还有万变不离其宗的优化器;DB for AL: 就是为在数据库里提供ML算子,或者直接脱离狭义的关系数据库,赶上embeded DB (即向量数据库)的风头 [3],后者继续图数据库 [4] 上深耕。
渴望成为风口的千百中的一只,思路却还停留在自己的茧房里。上面的东西在过去六七年场景中辩论过无数次,都有些东西,但做下来又都感觉不踏实。比如说,NLP2SQL(链接:https://github.com/nidmgh/techTrend/blob/main/NLP2SQL.py.), 这是笔者花了两个小时写的人生第一个(也许是第二次?)python code,其中有半个小时在学习如何在浏览器上开一个可互动的对话框了。一个普通程序员两个小时的商业价值是很难飞起来的,即使在风口。
想了几个月,没有答案,不妨碍去探索。三人行必有我师,俗称“作业借我抄抄”。今天借Google的AI collaborator 工具 DuetAI [5] 谈谈自己的想法。
1. NLP2SQL之后呢?
自然语言到SQL面向的客户,期望解决的问题很明显:客户不用学习写SQL了。之后呢?真的不需要懂SQL了吗? Google在讲这个问题的时候引用了一个化妆品L’Oréal的架构师的一段话。笔者个人也在新加坡拜访过SEPHORA的亚洲总部。换位思考一下,有几位读者能说清楚口红的颜色。既然说不清看不懂,那么如果销售员推荐一个YSL小金条1966 [6],在我脑海里比量子力学还难了。
同样的道理,通过自然语言生成了一个SQL,且不说性能调优问题。最终用户能够判断该查询的准确性,如何解读结果?自然语言到SQL并没有真正解决这个问题,而是需要把SQL Query的结果再解析出来,生成报告用户可以理解内容。AIGC完成自闭环。Duet AI in Google Cloud - data analysis and visualization(链接:https://www.youtube.com/watch?v=gtehwj1G4tU), 便是Google Next 23 keynote中的一个例子。NLP+BigQuery+Looker, 自然语言为输入,PPT为输出。
注意,在完成PPT向领导汇报这一个实际工作的同时,还解决了一个关键性的技术性问题。就是,让我们的客户真正的能够用其领域知识理解输出的结果。图表报告的正确性与否,是与客户的专业知识相互作用的,她/他的专业经验和日常感觉判断。因为只有这些客户才了解的业务的实际情况,而不是冷冰冰的数据库查询结果。上帝的归上帝,凯撒的归凯撒;SQL归数据库码农,口红色号归化妆专业人士,大家各司其职,贡献专业知识。
- 技术路径:NPL2SQL + Data Warehouse + Marp [7]
2. 数据库迁移:百里之行半九十
数据库迁移是几十年的老话题。其中数据库兼容性,数据迁移,Schema转换,应用重写(COBOL万岁 ),祥林嫂都觉得烦了。可问题和业务都还在,占有每一个CIO老总预算的40%(抱歉,记不得出处了)。其中简单的东西有各种工具都解决了,不管是数据库内核的兼容性 [8],还是转换工具的革新更新换代,已经把门槛推到了95%。这个数据来自笔者的小学一年级加减法:4年前在吉隆坡一角的会议室里的我给客户业务的分析结果。那是一个帮助马来西亚的电商从Oracle RAC迁移到PolarDB的例子,我们最后的困难也在这5%。从鉴于对客户信息的尊重,这里只分享公开的材料“Goodbye Oracle! Exclusive Insights into PrestoMall’s Transition to Alibaba Cloud”(链接:https://alibaba-cloud.medium.com/goodbye-oracle-exclusive-insights-into-prestomalls-transition-to-alibaba-cloud-d24b05058777), 从Oracle到PG需要手工修改80%的code,采用当时的自动化工具(programming language and schema conversion) 可以减少到10% , 使用当时的PolarDB兼容O的版本,减少到5%。、
对的,客户CTO和我也都知道,数据库迁移的最后的5%是多么困难的一座山。很幸运,我们成功了。With good tools and many man-months power。这5%便是AIGC可以带来的创新点。
Duet AI 作为数据库开发者的辅助工具,可以再推进2~3%。除了可以比较把老朽的CPP [9]转化成代表新潮流GO外,它还可以把自适应的原始端的数据库API转化成目标端的数据库API,当然目标端是GCP自己的云数据库AlloyDB了。比较有趣的魔鬼在于细节,这里并不是革命,而一个个螺丝钉拧上去的革新。Duet AI in Google Cloud - database management (链接:https://www.youtube.com/watch?v=u6489QehgdQ)展示从Oracle到 AlloyDB(PG为根基的云数据库) ,其中自动标识localtimestamp() 到 clock_timestamp(),并且举一反十的全局修改。这是一个把半天工作量削减到30分钟的小动作(销售人员会说削减到1分钟... 我不是个好销售)。
这点小改进并不专属于数据库迁移,但在这个场景下--数据库迁移的应用改造中,cost/return收效最好。因为迁移的技术员与原应用的开发工程师,在中间可能已经隔了n多个程序员了,客户技术人员即没有兴趣,也没有能力去理解原始程序。而原始应用中一定会有多年积攒的重复性的逻辑片段,通过机器学习来去举一反N才是程序猿copy/paste的最好朋友。
- 实现路径:existing data replication and schema conversation tool + drivers for cloud databases + GitHub co-pilot(copilot是技术关键。需要针对数据库应用定制)
3. DBA对于数据库报警的漠不关心
刚刚接触云客户业务的时候,去约一位资深技术Lead。他说好啊,刚好晚上他值班,所以有空:“咱们晚上9点吧,赛银国际的一个酒吧,还是不错的”。我以前也做过值班经理工作,每次值班都如临大敌,非常紧张。因为支持的是大客户,“运气好”的时候,可以上新闻头版的。
这位是很资深的老员工,深耕集团内外技术支持多年。落座之后,先叫了杯酒,然后提到一般两人轮换值一天,他更愿意自己扛24小时。这样子只耽误一天时间。聊天的两个小时过程中,他的手机时刻都在震动着。他也不得不时不时瞟一眼报警,偶然中断一下我们兴致勃勃的八卦,去翻一下详细的信息。两年后,疫情期间,我遇到另一位正在值班的同事。酒吧好像已经关了(不知道是否是暂时的),但他值班的方式和流程没有变化。也许是我的心理作用,唯一变的就是报警更频繁了。
对比我当年的值班,这位老兄的确是处事不惊,泰然自若。可另一方面我每个班能有两个电话就已经是非常繁忙的,因为客户的DBA是我们最前沿的保护,他手里的脚本和自身的经验保证了报警的高质量,而不是直接推到我的手机上。而这位老兄手机上的几千次的所谓的报警为什么会发生呢?客户将IT服务通过云托管的方式“外包”给了云厂商。云的技术人员对于客户的业务其实是不了解的,无法真正的的判断报警的分级和处理的方法。所以常年来(为了免责也是一大原因)报警数量有增无减,造成了99.x%无用的信息。但消耗了大量的人工力量,系统报警的严重污染,用所谓的完整性,消耗了实际的服务效率。那位资深老哥值班的过程中,无法做有意义的事情,即不能为公司工作,也不能陪伴家人。也许同我一起八卦是最高效的产出了。
Google提出了Duet AI in Google Cloud - troubleshooting issues(链接:https://www.youtube.com/watch?v=MBAuTQdtZ0o)。其实这不是什么新东西。Snowflake的成功,就很大程度上归功于其Service with Scalability。Snowflake的运维每天生成几十T的日志数据,而且业务持续稳定增长。之所以能够跨越增服(业务)不增人(工程师)的创业公司门槛,便是有效的完成了日志自动化。在这个门槛上跌倒的的公司很多,包括现在的国内主力云服务商。
之前对于数据库系统的一些排错的方式,非常依赖于比较有前瞻性的SQL Error Message的设计。比如MySQL 8.0 Error Message Reference(链接:https://downloads.mysql.com/docs/mysql-errors-8.0-en.a4.pdf)有786页,体现了30年的积累。现在AI大模型帮助可以更快的总结系统错误,分析系统重大问题之前的N个小时的状态,尤其是当时没有注意到的报警(帮助我那位值班的老哥,从无效的报警中解脱出来)。这便是新技术,面对旧场景的革新。
技术路径:时序数据库(一般的数仓也够了)+ 针对数据库日志的大模型训练 + 反馈机制 [10]。
4. 写个尾巴
AI for DB和DB for AI上面两个方向当然都有各自的故事可以讲,我也都去讲过。个人以为数据库内核已经足够成熟,已经人力优化多年,现在的AL水平是无法提供实际提高的(个人并不反对这方面的学术工作或者大厂的research lab)。内核的提高还有待观望,与日常IT工作相关的DMaaS反而可以先发,利用今天的AI技术产生革命性的东西。上面的三个突破点的技术路线是可以立刻发力的。
The above ideas were formed at Bodega Bay.
参考
- 真正的idea来源于团队的优化器专家,现在是某top国产数据库的head of Engineering。我只是前台翻PPT的。
- 《当LLM遇到Database:阿里达摩院联合HKU推出Text-to-SQL新基准》(阿里:https://developer.aliyun.com/article/1262738);TiDB Chat2Query(https://www.pingcap.com/chat2query-an-innovative-ai-powered-sql-generator-for-faster-insights/); 《数据库开发工具界的 ChatGPT 来了》(https://www.bilibili.com/video/BV1XT411r7HQ/;NineData:基于 AI(GPT) 的 SQL 优化,不好意思夹带私货)
- 阿里最近宣传的PGVector和开源的chroma(https://github.com/chroma-core/chroma)
- NebulaGraph and TigerGraph
- 部分信息来源于:https://cloud.google.com/blog/products/ai-machine-learning/duet-ai-in-google-cloud-preview。Duet AI号称可以干很多事情。鉴于笔者的知识范围,只探究数据库/数据处理/云数据相关的内容。本文并不重点在google的Duet AI,而是借助其服务场景谈谈自身的思考。建议大家参阅原文和自己试试Duet AI,毕竟“原始材料”要靠谱的多。
- 据说是10支大牌经典口红色号,反正我不懂。https://www.zhihu.com/tardis/zm/art/565109678?source_id=1003
- a Markdown to PPT tool. 笔者在过去10个月一直使用它。挺好玩,还不成熟。
- PG生态的EDB(aka Enterprise DB), 国内的PolarDB-O,Oceanbase-O
- 坐在mainframe里的COBOL捋着胡子说:你过来呀?
- 华人开发的时序数据库有TDEngine和Timeplus; Meta开源的Llama大家肯定听说过;反馈机制需要专门设计,暂时没有方案。
版权归原作者 NineData 所有, 如有侵权,请联系我们删除。