建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
背景及現(xiàn)狀
汽車(chē)之家是一家力求為消費(fèi)者提供最新汽車(chē)報(bào)價(jià),汽車(chē)圖片,汽車(chē)價(jià)格大全,最精彩的汽車(chē)新聞、行情、評(píng)測(cè)、導(dǎo)購(gòu)內(nèi)容,是提供信息最快最全的中國(guó)汽車(chē)網(wǎng)站。
在公司發(fā)展過(guò)程中，之家運(yùn)用了各種各樣的數(shù)據(jù)管理系統(tǒng)來(lái)存儲(chǔ)與管理各種各樣的數(shù)據(jù)：關(guān)系型數(shù)據(jù)庫(kù)、NoSQL 數(shù)據(jù)庫(kù)、文檔數(shù)據(jù)庫(kù)、Key-value 數(shù)據(jù)庫(kù)，對(duì)象存儲(chǔ)系統(tǒng)等等。形態(tài)多樣的數(shù)據(jù)管理系統(tǒng)為之家在管理數(shù)據(jù)上帶來(lái)便利的同時(shí)，隨之而來(lái)的是管理與充分利用這些數(shù)據(jù)系統(tǒng)存儲(chǔ)的數(shù)據(jù)的難題。
無(wú)論是關(guān)系型數(shù)據(jù)庫(kù)中的MySQL，抑或是 Hadoop 體系下的 Hive，這些目前業(yè)界通用的數(shù)據(jù)管理系統(tǒng)都有自成體系的一套 SQL 方言，在之家的業(yè)務(wù)系統(tǒng)中，也運(yùn)用到了這些數(shù)據(jù)關(guān)系系。
所以在之家，需求方想要分析某一種數(shù)據(jù)管理系統(tǒng)的數(shù)據(jù)，就得熟練掌握某一種 SQL 方言；為了對(duì)不同數(shù)據(jù)源進(jìn)行聯(lián)合查詢(xún)，就得在應(yīng)用程序邏輯中使用不同的客戶(hù)端去連接不同的數(shù)據(jù)源，由之而來(lái)帶來(lái)的問(wèn)題是：整個(gè)分析過(guò)程架構(gòu)復(fù)雜，編程入口多，系統(tǒng)集成困難，這對(duì)于涉及海量數(shù)據(jù)的數(shù)據(jù)分析工作變得十分痛苦。
解決方案
針對(duì)上述問(wèn)題，之家調(diào)研了多種方案和技術(shù)可行性，最終選擇openLooKeng。
首先，在之家用到了RDBMS、NoSQL、Hive、MPPDB等多種類(lèi)型數(shù)據(jù)倉(cāng)庫(kù)，openLooKeng可以實(shí)現(xiàn)這些數(shù)據(jù)倉(cāng)庫(kù)的聯(lián)合查詢(xún)。其次，利用openLooKeng的跨源異構(gòu)查詢(xún)能力，之家需求方可以快速分析海量數(shù)據(jù)，從而揭示出數(shù)據(jù)背后的真相，為上層提供決策的依據(jù)，指導(dǎo)業(yè)務(wù)發(fā)展。最后，openLookeng為開(kāi)源項(xiàng)目，社區(qū)活躍度高，出現(xiàn)問(wèn)題可以和社區(qū)共同快速解決。
關(guān)鍵特性
讓我們先來(lái)看看 openLooKeng 的一些關(guān)鍵特性，以便更深入的理解為什么open LooKeng 和之家的業(yè)務(wù)場(chǎng)景相符合，甚至您也可以基于 openLooKeng 的這些能力進(jìn)一步探索更多的業(yè)務(wù)場(chǎng)景。
1. ANSI SQL2003 語(yǔ)法的支持
在之家的多種業(yè)務(wù)場(chǎng)景中，使用的是 ANSI SQL2003 語(yǔ)法，由于openLooKeng支持此語(yǔ)法，所以之家用戶(hù)使用 openLooKeng 語(yǔ)法進(jìn)行查詢(xún)時(shí)，一方面無(wú)需改變之前查詢(xún)習(xí)慣，無(wú)差異運(yùn)用。另一方面無(wú)論底層數(shù)據(jù)源是 RDBMS 還是 NoSQL 或者其他數(shù)據(jù)管理系統(tǒng)，借助 openLooKeng的Connector 框架，數(shù)據(jù)可以依然存放在原始的數(shù)據(jù)源中，從而實(shí)現(xiàn)數(shù)據(jù)平滑遷移的查詢(xún)。
最后，通過(guò) openLooKeng 的統(tǒng)一 SQL 入口，可實(shí)現(xiàn)對(duì)底層各種數(shù)據(jù)源 SQL 方言的屏蔽，之家用戶(hù)無(wú)需再關(guān)心底層數(shù)據(jù)源的 SQL 方言便可獲取到該數(shù)據(jù)源的數(shù)據(jù)，方便用戶(hù)消費(fèi)數(shù)據(jù)。
2. 多種多樣的數(shù)據(jù)源 Connector
在之家運(yùn)用了多種數(shù)據(jù)管理系統(tǒng)，openLooKeng 針對(duì)這些數(shù)據(jù)管理系統(tǒng)都有對(duì)應(yīng)的數(shù)據(jù)源 Connector，包括 RDBMS（Oracle Connector），NoSQL（Hive Connector、HBase Connector 等），全文檢索數(shù)據(jù)庫(kù)（ElasticSearch Connector 等）。openLoo Keng 可以通過(guò)這些多樣的 Connector 方便的獲取到數(shù)據(jù)源數(shù)據(jù)，從而進(jìn)一步進(jìn)行基于內(nèi)存的高性能聯(lián)合計(jì)算。
3. 高性能的查詢(xún)優(yōu)化技術(shù)
openLooKeng 在內(nèi)存計(jì)算框架的基礎(chǔ)上，還利用許多查詢(xún)優(yōu)化技術(shù)來(lái)滿(mǎn)足高性能的交互式查詢(xún)的需要。
3.1 索引
openLooKeng 提供基于 Bitmap Index、Bloom Filter 以及 Min-max Index 等索引。通過(guò)在現(xiàn)有數(shù)據(jù)上創(chuàng)建索引，并且把索引結(jié)果存儲(chǔ)在數(shù)據(jù)源外部，在查詢(xún)計(jì)劃編排時(shí)便利用索引信息過(guò)濾掉不匹配的文件，減少需要讀取的數(shù)據(jù)規(guī)模，從而加速查詢(xún)過(guò)程。
3.2 Cache
openLooKeng 提供豐富多樣的 Cache，包括元數(shù)據(jù) cache、執(zhí)行計(jì)劃 cache、ORC 行數(shù)據(jù) cache 等。通過(guò)這些多樣的 cache，可加速用戶(hù)多次對(duì)同一 SQL 或者同一類(lèi)型 SQL 的查詢(xún)時(shí)延響應(yīng)。
3.3 動(dòng)態(tài)過(guò)濾
所謂的動(dòng)態(tài)過(guò)濾是指是在運(yùn)行時(shí)（run time）將 join 一側(cè)表的過(guò)濾信息的結(jié)果應(yīng)用到另一側(cè)表的過(guò)濾器的優(yōu)化方法，openLooKeng 不僅提供了多種數(shù)據(jù)源的動(dòng)態(tài)過(guò)濾優(yōu)化特性，還將這一優(yōu)化特性應(yīng)用到了 DataCenter Connector，從而加速不同場(chǎng)景關(guān)聯(lián)查詢(xún)的性能。
3.4 算子下推
openLooKeng 通過(guò) Connector 框架連接到 RDBMS 等數(shù)據(jù)源時(shí)，由于 RDBMS 具有較強(qiáng)的計(jì)算能力，一般情況下將算子下推到數(shù)據(jù)源進(jìn)行計(jì)算可以獲取到更好的性能。openLooKeng 目前支持多種數(shù)據(jù)源的算子下推，包括 Oracle、HANA 等，特別地，針對(duì) DC Connector 也實(shí)現(xiàn)了算子下推，從而實(shí)現(xiàn)了更快的查詢(xún)時(shí)延響應(yīng)。
商業(yè)數(shù)據(jù)分析應(yīng)用實(shí)踐
在之家的商業(yè)化廣告、線索等多個(gè)業(yè)務(wù)線，每個(gè)業(yè)務(wù)線根據(jù)不同的業(yè)務(wù)場(chǎng)景，分別使用不用的數(shù)據(jù)源，這些數(shù)據(jù)存儲(chǔ)系統(tǒng)往往相互隔離，形成相互獨(dú)立的數(shù)據(jù)孤島。當(dāng)針對(duì)不同業(yè)務(wù)線的不同數(shù)據(jù)源或者同業(yè)務(wù)線的不同數(shù)據(jù)源進(jìn)行聯(lián)合數(shù)據(jù)分析的時(shí)候，openLookeng起到了至關(guān)重要的作用。針對(duì)數(shù)據(jù)開(kāi)發(fā)和分析師應(yīng)用場(chǎng)景如下：
針對(duì)開(kāi)發(fā)而言。針對(duì)上述業(yè)務(wù)場(chǎng)景，按照一般解決思路，把數(shù)據(jù)都統(tǒng)一入統(tǒng)一數(shù)據(jù)源，然后在統(tǒng)一數(shù)據(jù)源中查詢(xún)分析，導(dǎo)致數(shù)據(jù)鏈路長(zhǎng)，數(shù)據(jù)完整性和時(shí)效性不能保證，數(shù)據(jù)校驗(yàn)時(shí)，產(chǎn)生額外的數(shù)據(jù)驗(yàn)證時(shí)間，并且驗(yàn)證邏輯復(fù)雜化。引入openLooKeng后，可以直接在自帶頁(yè)面或者通過(guò)JDBC驅(qū)動(dòng)的方式從JAVA訪問(wèn)openLookeng,配置中增加業(yè)務(wù)數(shù)據(jù)所存儲(chǔ)的各種數(shù)據(jù)源，直接就可以用統(tǒng)一查詢(xún)SQL進(jìn)行夸源查詢(xún)，提升開(kāi)發(fā)效率。
站在分析師角度。面對(duì)海量數(shù)據(jù)，如果不知道數(shù)據(jù)用在哪里、怎么用，就無(wú)法基于海量數(shù)據(jù)構(gòu)建新的業(yè)務(wù)模型。分析師對(duì)個(gè)業(yè)務(wù)線數(shù)據(jù)進(jìn)行商業(yè)分析時(shí)，需要從業(yè)務(wù)數(shù)據(jù)所存儲(chǔ)的多個(gè)數(shù)據(jù)源中獲取數(shù) 據(jù)，如RDBMS(如MYSQL,ORACLE等)或者NOSQL(如HIVE,HBASE等)。
查詢(xún)不同的數(shù)據(jù)源，需要不同的連接方式或客戶(hù)端，運(yùn)行不同的SQL方言。這些差異導(dǎo)致額外的學(xué)習(xí)成本和復(fù)雜的應(yīng)用開(kāi)發(fā)邏輯，另外，每種數(shù)據(jù)源自帶的函數(shù)，比如字符串函數(shù)、窗口函數(shù)、計(jì)算函數(shù)等，對(duì)應(yīng)的函數(shù)名稱(chēng)或者參數(shù)也不相同，所以使用時(shí)，需要分別區(qū)分處理，加大了工作量，數(shù)據(jù)錯(cuò)誤率也會(huì)上升。
引入openLookeng后，提供統(tǒng)一SQL接口，自動(dòng)屏蔽各個(gè)數(shù)據(jù)源語(yǔ)法差異，減去學(xué)習(xí)的時(shí)間，分析師商業(yè)化分析效率大大提高。
升級(jí)Apache Kylin連接器
之家商業(yè)化業(yè)務(wù)強(qiáng)度依賴(lài)的Kylin并沒(méi)有被openLooKeng覆蓋，openLooKeng 對(duì)Kylin數(shù)據(jù)源的支持不完善，達(dá)不到使用要求，所以我們決定升級(jí)Kylin連接器并貢獻(xiàn)給社區(qū)。
首先介紹下Kylin。Kylin是一個(gè)開(kāi)源OLAP分析引擎，提供HADOOP之上的SQL查詢(xún)接口以及多維分析能力以支持超大規(guī)模數(shù)據(jù)。作為一款OLAP分析工具，在之家有著相當(dāng)廣泛的應(yīng)用，所以Kylin和其他數(shù)據(jù)源的跨源查詢(xún)需求隨之而來(lái)。
其次解釋下openLooKeng連接器(connector,以下連接器用connector代替)。connector是用于在 openLooKeng 中進(jìn)行查詢(xún)的所有數(shù)據(jù)的源。即使您的數(shù)據(jù)源沒(méi)有可以支持它的基礎(chǔ)表，只要將您的數(shù)據(jù)源與 openLooKeng 期望使用的 API 相適配，您也可以針對(duì)這些數(shù)據(jù)編寫(xiě)查詢(xún)。
最后詳細(xì)介紹對(duì)Kylin connector升級(jí)的關(guān)鍵點(diǎn)：
1. 元數(shù)據(jù)
Kylin元數(shù)據(jù)和其他RDBMS如MYSQL不同，它包括HIVE表的元數(shù)據(jù)和Kylin的元數(shù)據(jù)，Kylin的元數(shù)據(jù)包括Project，Model，Cube，Segment多種元數(shù)據(jù)信息，所以針對(duì)Kylin元數(shù)據(jù)的操作和RDBMS相比有區(qū)別。比如獲取查詢(xún)SQL的列信息，Kylin是基于Apache Calcite來(lái)實(shí)現(xiàn)SQL解析和優(yōu)化，包括生成執(zhí)行計(jì)劃，所以對(duì)于Kylin SQL的列信息獲取基于Calcite來(lái)實(shí)現(xiàn)。如下圖：
2. SQL關(guān)鍵字
當(dāng)在Kylin中查詢(xún)使用SQL關(guān)鍵字時(shí)，要加上雙引號(hào)，并且里面的內(nèi)容要大寫(xiě)，這點(diǎn)與其他的RDBMS也不相同，需要單獨(dú)處理。如下圖：
在KylinSqlStatementWriter類(lèi)中重寫(xiě)select方法，對(duì)sql中的關(guān)鍵字進(jìn)行特殊處理。其中處理具體規(guī)則如下：
如果Kylin中的查詢(xún)SQL語(yǔ)句中，對(duì)列的重命名名稱(chēng)為sum、count、min、max、rank關(guān)鍵字，則將關(guān)鍵字加上雙引號(hào)，并且大寫(xiě)處理。
3. SQL優(yōu)化器
在正常使用過(guò)程中，發(fā)現(xiàn)openLooKeng的優(yōu)化規(guī)則SingleDistinctAggregationGroupBy對(duì)Kylin connector不適用,因?yàn)閷?duì)于Kylin而言，只有當(dāng)查詢(xún)的模式和cube定義相匹配的時(shí)候，Kylin才能用對(duì)應(yīng)的cube數(shù)據(jù)來(lái)完成查詢(xún)，但是對(duì)于SingleDistinctAggregationGroupBy這個(gè)規(guī)則優(yōu)化查詢(xún)之后，輸出和原有的SQL差異比較大的時(shí)候，造成匹配不上原有cube，則導(dǎo)致查詢(xún)不到數(shù)據(jù)。所以需要升級(jí)SQL優(yōu)化器。
3.1 介紹
下圖為openLooKeng執(zhí)行SQL的各個(gè)環(huán)節(jié)，查詢(xún)語(yǔ)句經(jīng)過(guò)解析之后形成抽象語(yǔ)法樹(shù)，然后經(jīng)過(guò)Analyze生成邏輯計(jì)劃，邏輯計(jì)劃再經(jīng)過(guò)一系列的優(yōu)化規(guī)則來(lái)生成更高效的邏輯計(jì)劃，進(jìn)而轉(zhuǎn)成物理計(jì)劃。在邏輯計(jì)劃優(yōu)化階段，openLooKeng提供了幾類(lèi)查詢(xún)優(yōu)化器(比如基于成本的優(yōu)化，基于rule的優(yōu)化，支持table下推優(yōu)化器規(guī)則)，每類(lèi)優(yōu)化器提供幾十種優(yōu)化規(guī)則。
其次補(bǔ)充說(shuō)明：SingleDistinctAggregationToGroupBy優(yōu)化規(guī)則對(duì)Kylin不適用的原因，由于SingleDistinctAggregationToGroupBy規(guī)則是對(duì)指標(biāo)進(jìn)行distinct的SQL優(yōu)化，優(yōu)化邏輯為將SQL轉(zhuǎn)換成group by ,然后再count計(jì)算，其實(shí)就是采用“分治”的思想來(lái)提升查詢(xún)效率，對(duì)于如下SQL：
當(dāng)經(jīng)過(guò)此規(guī)則優(yōu)化之后，輸出如下：
但是優(yōu)化之后的SQL匹配不到對(duì)應(yīng)cube，所以當(dāng)Kylin的sql進(jìn)行查詢(xún)優(yōu)化的時(shí)候，需要過(guò)濾此規(guī)則。
3.2 自定義規(guī)則方案
首先,根據(jù)上述優(yōu)化規(guī)則是針對(duì)邏輯計(jì)劃的。LogicalPlanner類(lèi)就是對(duì)解析出來(lái)的抽象語(yǔ)法樹(shù)（AST）生成邏輯計(jì)劃，我們可以從下圖看出，planOptimizers包含了幾類(lèi)優(yōu)化規(guī)則，而SingleDistinctAggregationToGroupBy是屬于IterativeOptimizer這類(lèi)規(guī)則。
針對(duì)Kylin connector自定義過(guò)濾規(guī)則，有兩種方案，如下：
方案一：基于openLooKeng的下推框架，將執(zhí)行計(jì)劃樹(shù)傳遞給connector，再將PlanOpt
imizerst提供給執(zhí)行優(yōu)化引擎，這樣可以讓connector引入針對(duì)自己的任意優(yōu)化規(guī)則?；诖朔桨?，是否可以將SingleDistiAggregation ToGroupBy優(yōu)化規(guī)則在Kylin
connector中實(shí)現(xiàn)過(guò)濾。但是此框架只能增加自定義優(yōu)化規(guī)則，不能修改原有系統(tǒng)規(guī)則，如下圖，所以此方案不可行。
方案二：利用OptimizerUtils工具類(lèi)提供的兩個(gè)方法，來(lái)判斷上文中系統(tǒng)自帶的優(yōu)化規(guī)則是否適用于此邏輯計(jì)劃，所以對(duì)規(guī)則的過(guò)濾是在OptimizerUtils類(lèi)中實(shí)現(xiàn)。目前采用的是這種方案。
3.3 自定義規(guī)則初始化
接下來(lái)為了實(shí)現(xiàn)代碼的可擴(kuò)展性和可維護(hù)性，將自定義的過(guò)濾規(guī)則配置在文件中，由于connector的連接信息已經(jīng)有獨(dú)立的配置文件，所以直接在此文件中增加配置項(xiàng)“blacklist”。如下圖：
下面介紹如何將新增配置項(xiàng)初始化到系統(tǒng)中。在主程序啟動(dòng)類(lèi)PrestoServer的start方法中調(diào)用StaticCatalogStore.loadCatalogs的方法來(lái)進(jìn)配置和連接信息初始化。如下圖：
過(guò)濾規(guī)則初始化到OptimizerUtils類(lèi)的planOptimizerBlacklist靜態(tài)變量中，如下圖；
3.4 自定義規(guī)則過(guò)濾
首先，在OptimizerUtils類(lèi)的isEnabledLegacy方法中實(shí)現(xiàn)規(guī)則過(guò)濾。首先通過(guò)邏輯執(zhí)行計(jì)劃解析出SQL中的catalog列表，然后遍歷優(yōu)化器中的優(yōu)化規(guī)則，如果優(yōu)化規(guī)則在數(shù)據(jù)源catalog配置列表中，則此規(guī)則不起作用。
其次，獲取catalog列表時(shí)，由于上文提到的幾十種規(guī)則都是對(duì)于同一邏輯計(jì)劃進(jìn)行優(yōu)化，所以用threadlocal維護(hù)一個(gè)解析后的線程本地變量，在同一請(qǐng)求中，只解析一次執(zhí)行計(jì)劃，避免重復(fù)解析，提升效率。
最后，講解如何解析邏輯計(jì)劃，由于邏輯計(jì)劃為一個(gè)計(jì)劃樹(shù)，樹(shù)上有通過(guò)解析SQL得到的節(jié)點(diǎn)，比如TableScanNode，ProjectNod，JoinNode，F(xiàn)ilterNode等，比如如下SQL：
對(duì)應(yīng)的邏輯計(jì)劃樹(shù)為：
由于需要獲取表對(duì)應(yīng)的數(shù)據(jù)源catalog，所以我們只關(guān)心TableScanNode節(jié)點(diǎn)，遞歸計(jì)劃樹(shù)，獲取到所有表的數(shù)據(jù)源catalog。如下圖：
總結(jié)與規(guī)劃
引入openLooKeng后，之家具備了跨源異構(gòu)的數(shù)據(jù)查詢(xún)能力，覆蓋了同業(yè)務(wù)線的或不用業(yè)務(wù)線的不同數(shù)據(jù)源的分析業(yè)務(wù)場(chǎng)景，提高了之家用戶(hù)數(shù)據(jù)分析效率。另外，根據(jù)之家自身業(yè)務(wù)需要，升級(jí)Kylin connector并貢獻(xiàn)給社區(qū)，使openLooKeng的connector更加豐富，同時(shí)覆蓋了之家更多的應(yīng)用。
后續(xù)我們持續(xù)關(guān)注openLooKeng社區(qū)發(fā)展，并且接入之家更多的業(yè)務(wù)和分析場(chǎng)景，不斷完善和持續(xù)更新迭代openLooKeng，和社區(qū)共同成長(zhǎng)。
本文題目：openLooKeng跨源異構(gòu)在之家的升級(jí)與實(shí)踐
轉(zhuǎn)載來(lái)于：http://fisionsoft.com.cn/article/djppeis.html
