小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源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。