查看原文
其他

Osql:一个大统一的SQL查询引擎

数据技术 OPPO数智技术 2022-09-06

小O是新来OPPO不久的分析师同学,在公司遇到了许多志趣相投的同事,这让他很开心。可是最近有一件事让他很烦恼,因为查数据的时候,他一般使用Hive查询,但很多时候他的查询都运行的很慢,甚至查不出来。


导师听说后告诉他,Hive运行有问题可以用Spark试试,Spark如果运行也慢,在交互式查询时还可以用Presto。因此,小O又掌握了两个新的查询引擎神器。


可是用了一段时间,他又发愁了,因为某些查询中,Spark运行的还没Hive查询时快,那到底应该选择用哪个引擎呢?而且不同引擎的语法往往还不一样,让他头大。


一天下班后,小O遇到了同事小Q,小Q知道小O的烦恼后说:“这个好解决,你可以用用公司开发的南天门交互式查询和自助取数,我用了大半年,查询数据这方面省了不少麻烦。”


小Q详细解说道:“南天门的底层的引擎Osql,会自动帮我们选择合适的查询引擎,我们把SQL写好,就能得到查询结果数据,不用再管不同引擎之间的区别,无论是用ANSI SQL,还是HiveQL,它都会尽全力帮我们把结果查询出来。就目前而言,2020年Osql已经累计为我们提供了200万+次的查数服务,70%的查询都可以在1分钟以内返回数据,极大提升了查数的效率。”


听完介绍,小O特别兴奋,“Osql这么神奇,那我以后岂不是只要和Osql这一种引擎打交道就可以,把我的SQL给它,然后就等着返回查询结果,这样的话,查询这个事情就简单多了。“


“是的,这样就把繁琐的引擎选择、语法兼容问题都尽量交给开发小哥哥,我们只要好好结合业务需求,写好自己的SQL就行,这极大的降低了我们查询的门槛和代价。”小Q回应道。


这个Osql服务瞬间解决了小O的难题,也点燃了他的好奇心,”那快给我说说,这么麻烦的事情,他们是怎么做到的,Osql这个系统的整体架构是咋样的?“


“别着急,听我给你慢慢道来。你看下面这个图,就是Osql的整体架构图。”



“在不同的应用场景下,我们会选用不同的查询引擎,比如针对离线数据的Spark/Hive,ahoc查询的presto,实时数据的druid等等。但这样也给上层业务暴露了太多不同种类的查询接口,同时对统一的查询管理也造成了障碍。


于是基于大一统的思路,我们希望在众多Olap(Online Analytical Processing联机分析处理)引擎之上构建一个统一智能路由层,把查询引擎的各种公用模块抽离到Osql实现,比如权限校验、SQL规范检查、查询审计等等。最终向用户提供统一的查询入口,并根据查询历史,优化数据源在各个查询引擎上的分布,从而智能地将查询路由到合适的查询引擎。”小Q介绍道。


“原来Osql可以做这么多的事情,我知道SQL解析,其他的查询引擎也有这个模块,Osql的查询解析有什么不一样的地方吗?”小O继续问。


看见小O这么感兴趣,小Q继续介绍:“有的,Osql查询解析主要做了下面的事情:


1. 提取出用户的set参数和具体SQL文本,方便我们在set参数部分来自定义调优;


2. 解析该SQL是否符合语法规范,目前参照的是SparkSQL的语法规范;


3. 解析后,提取出库名、表名、维度、指标,方便后续的热数据挖掘;


4. 在交互式场景,为了防止随意的大查询,限制了查询结果为50万行。”


“咦,那这是怎么决定,我们用哪一个查询引擎来运行呢,有什么规则吗?”小O继续问出自己心中的疑惑。


“哈哈哈,就知道你要问这个,给你画个图就清楚了。”



看到上面这个路由规则图,小O心中的疑惑终于得到了解答。


“我明白了,他们是根据一些场景来划分的。如果用户是高阶玩家,就遵从用户的意愿,比如用户set engine=presto,那么这个查询就会用presto来运行;如果用户没有主动set,Osql会考虑当前的集群资源情况以及SQL具体的使用场景,比如元数据、取数、DDL和正常Select,来选择当前最合适的查询引擎。”


小Q听了,称赞道,“很厉害,你理解的非常对。”


小O谦虚地说:“都是你的图画得好,不过对我这样的小白用户来说,还有一个难题,查询的时候经常需要相关引擎的参数调优,这个虽然可以set,但是我不太会,不知道该用哪个参数来优化,这个问题做开发的小哥哥们有考虑到吗?”


“这个问题当然也考虑到了,而且还在逐渐完善这一块。记得上次我的SQL刚开始运行不久,一会界面上就弹出一个小窗口,提醒我可以加参数优化,就像下面这样。



第二次同样的查询,加上这个参数,果然查询效率提高了不少,后来一查才知道这个参数是提高Spark读取文件时的单个分区最大字节数,要是我自己调优,绝对想不到要用这个参数的。”


小O听到这里,也竖起大拇指,“确实,你说的这个功能可以给我们解决不少麻烦。对了,刚才Q老师提到南天门交互式查询和自助取数两个模块,他们都用的Osql,在实现上有什么区别吗?”


“他们在实现上确实有一些区别的,就像下面这个图一样,主要原因如下。


交互式查询下面接入多种查询引擎,需要更通用,一般返回的数据量有限制(50万),JDBC+CSV方式具有一般性。像Presto、Druid、Clickhouse等都不支持 ‘Insert Overwrite Directory方式’;


取数则采用Insert Overwrite Directory方式。主要原因是,一般取数面向的场景,查询结果比较大,如果都用JDBC+CSV的方式,Osql机器容易内存不足,因为查询结果留太多内存数据,因而将数据写到HDFS某一个目录,用户需要可自取。”小Q解释说。



“Qsql还挺有想法的,最近有啥最新的开发计划吗?”


小Q说:“上次在公司内做了一个技术分享,他们说近期会收集更多常见的错误和优化手段,通过实时弹出小窗口的方式,给我们建议。然后还会更细粒度的优化引擎路由的逻辑,争取用最合适的引擎最迅速的完成我们的查询需求。这是一个持续改进的过程,你要是有兴趣,可以跟他们一起合作,未来让这个服务更加的稳定高效好用”。


听完小Q的介绍,小O迫不及待去体验新的交互式查询引擎了。



☆ END ☆


招聘信息

OPPO互联网技术团队招聘一大波岗位,涵盖C++、Go、OpenJDK、Java、DevOps、Android、ElasticSearch等多个方向,请点击这里查看详细信息及JD


你可能还喜欢

OPPO自研ESA DataFlow架构与实践

数据同步一致性保障:OPPO自研JinS数据同步框架实践

微服务全链路异步化实践

Dubbo协议解析与ESA RPC实践

云原生Service Mesh探索与实践

更多技术干货

扫码关注

OPPO互联网技术

 

我就知道你“在看”

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存