小O是新来OPPO不久的分析师同窗，在公司遇到了许多志趣相投的同事，这让他很开心。但是最近有一件事让他很烦恼，由于查数据的时候，他通常使用Hive查询，但不少时候他的查询都运行的很慢，甚至查不出来。
web
导师据说后告诉他，Hive运行有问题能够用Spark试试，Spark若是运行也慢，在交互式查询时还能够用Presto。所以，小O又掌握了两个新的查询引擎神器。sql
但是用了一段时间，他又发愁了，由于某些查询中，Spark运行的还没Hive查询时快，那到底应该选择用哪一个引擎呢？并且不一样引擎的语法每每还不同，让他头大。微信
一天下班后，小O遇到了同事小Q，小Q知道小O的烦恼后说：“这个好解决，你能够用用公司开发的南天门交互式查询和自助取数，我用了大半年，查询数据这方面省了很多麻烦。”架构
小Q详细解说道：“南天门的底层的引擎Osql，会自动帮咱们选择合适的查询引擎，咱们把SQL写好，就能获得查询结果数据，不用再管不一样引擎之间的区别，不管是用ANSI SQL，仍是HiveQL，它都会尽全力帮咱们把结果查询出来。就目前而言，2020年Osql已经累计为咱们提供了200万+次的查数服务，70%的查询均可以在1分钟之内返回数据，极大提高了查数的效率。”app
听完介绍，小O特别兴奋，“Osql这么神奇，那我之后岂不是只要和Osql这一种引擎打交道就能够，把个人SQL给它，而后就等着返回查询结果，这样的话，查询这个事情就简单多了。“框架
“是的，这样就把繁琐的引擎选择、语法兼容问题都尽可能交给开发小哥哥，咱们只要好好结合业务需求，写好本身的SQL就行，这极大的下降了咱们查询的门槛和代价。”小Q回应道。异步
这个Osql服务瞬间解决了小O的难题，也点燃了他的好奇心，”那快给我说说，这么麻烦的事情，他们是怎么作到的，Osql这个系统的总体架构是咋样的？“编辑器
“别着急，听我给你慢慢道来。你看下面这个图，就是Osql的总体架构图。”微服务
“在不一样的应用场景下，咱们会选用不一样的查询引擎，好比针对离线数据的Spark/Hive，ahoc查询的presto，实时数据的druid等等。但这样也给上层业务暴露了太多不一样种类的查询接口，同时对统一的查询管理也形成了障碍。flex
因而基于大一统的思路，咱们但愿在众多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互联网技术
本文分享自微信公众号 - OPPO互联网技术（OPPO_tech）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。