Osql：一个大统一的SQL查询引擎
小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互联网技术