网站制作视频,自己的店铺如何弄小程序,十佳工业设计公司,做非法网站作者#xff1a;Ni Demai#xff0c;是NineData数据库产品专家#xff0c;曾任阿里云数据库国际产品总负责人#xff0c;华为高斯 GaussDB 创始团队核心架构师#xff0c;IBM Db2 资深研发工程师。 Demai 专注 Cloud-Native database 架构设计#xff0c;分析型 MPP… 作者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?vgtehwj1G4tU, 便是Google Next 23 keynote中的一个例子。NLPBigQueryLooker, 自然语言为输入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 作为数据库开发者的辅助工具可以再推进23%。除了可以比较把老朽的CPP [9]转化成代表新潮流GO外它还可以把自适应的原始端的数据库API转化成目标端的数据库API当然目标端是GCP自己的云数据库AlloyDB了。比较有趣的魔鬼在于细节这里并不是革命而一个个螺丝钉拧上去的革新。Duet AI in Google Cloud - database management 链接https://www.youtube.com/watch?vu6489QehgdQ展示从Oracle到 AlloyDBPG为根基的云数据库) 其中自动标识localtimestamp() 到 clock_timestamp()并且举一反十的全局修改。这是一个把半天工作量削减到30分钟的小动作销售人员会说削减到1分钟... 我不是个好销售。
这点小改进并不专属于数据库迁移但在这个场景下--数据库迁移的应用改造中cost/return收效最好。因为迁移的技术员与原应用的开发工程师在中间可能已经隔了n多个程序员了客户技术人员即没有兴趣也没有能力去理解原始程序。而原始应用中一定会有多年积攒的重复性的逻辑片段通过机器学习来去举一反N才是程序猿copy/paste的最好朋友。 实现路径existing data replication and schema conversation tool drivers for cloud databases GitHub co-pilotcopilot是技术关键。需要针对数据库应用定制 3. DBA对于数据库报警的漠不关心
刚刚接触云客户业务的时候去约一位资深技术Lead。他说好啊刚好晚上他值班所以有空“咱们晚上9点吧赛银国际的一个酒吧还是不错的”。我以前也做过值班经理工作每次值班都如临大敌非常紧张。因为支持的是大客户“运气好”的时候可以上新闻头版的。
这位是很资深的老员工深耕集团内外技术支持多年。落座之后先叫了杯酒然后提到一般两人轮换值一天他更愿意自己扛24小时。这样子只耽误一天时间。聊天的两个小时过程中他的手机时刻都在震动着。他也不得不时不时瞟一眼报警偶然中断一下我们兴致勃勃的八卦去翻一下详细的信息。两年后疫情期间我遇到另一位正在值班的同事。酒吧好像已经关了不知道是否是暂时的但他值班的方式和流程没有变化。也许是我的心理作用唯一变的就是报警更频繁了。
对比我当年的值班这位老兄的确是处事不惊泰然自若。可另一方面我每个班能有两个电话就已经是非常繁忙的因为客户的DBA是我们最前沿的保护他手里的脚本和自身的经验保证了报警的高质量而不是直接推到我的手机上。而这位老兄手机上的几千次的所谓的报警为什么会发生呢客户将IT服务通过云托管的方式“外包”给了云厂商。云的技术人员对于客户的业务其实是不了解的无法真正的的判断报警的分级和处理的方法。所以常年来为了免责也是一大原因报警数量有增无减造成了99.x%无用的信息。但消耗了大量的人工力量系统报警的严重污染用所谓的完整性消耗了实际的服务效率。那位资深老哥值班的过程中无法做有意义的事情即不能为公司工作也不能陪伴家人。也许同我一起八卦是最高效的产出了。
Google提出了Duet AI in Google Cloud - troubleshooting issues链接https://www.youtube.com/watch?vMBAuTQdtZ0o。其实这不是什么新东西。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和开源的chromahttps://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_id1003a Markdown to PPT tool. 笔者在过去10个月一直使用它。挺好玩还不成熟。 PG生态的EDB(aka Enterprise DB), 国内的PolarDB-OOceanbase-O坐在mainframe里的COBOL捋着胡子说你过来呀华人开发的时序数据库有TDEngine和Timeplus; Meta开源的Llama大家肯定听说过反馈机制需要专门设计暂时没有方案。
