基于Hadoop的SQL一直在被持續(xù)地改進(jìn)，但是一個查詢要等幾分鐘到幾小時還是非常得正常。在這篇博文里，我們將會介紹開源的分布式分析引擎Apache Kylin。重點(diǎn)介紹它是如何以數(shù)量級加速大數(shù)據(jù)查詢，以及在2.0版里面為交互式BI所提供的新特性，包括對雪花模型的支持和流式建立數(shù)據(jù)立方。
Apache Kylin是什么？
Kylin是一個在Hadoop上的OLAP引擎。如圖1所示，Kylin位于Hadoop之上，向上層的應(yīng)用提供了基于標(biāo)準(zhǔn)SQL接口的關(guān)系型數(shù)據(jù)。
圖1 Apache Kylin的位置。圖片由Yang Li友情提供
Kylin可以處理大數(shù)據(jù)集，從查詢延遲上講是很快的，這也是它和其他基于Hadoop的SQL的區(qū)別。比如，我們所知道的使用Kylin的最大的生產(chǎn)系統(tǒng)實(shí)例是在今日頭條，一個中國的新聞推送應(yīng)用。頭條有一個包含3萬億條記錄的表，對它的平均查詢響應(yīng)時間低于1秒。下一節(jié)我們會討論Kylin是怎么實(shí)現(xiàn)這么快的查詢。
Kylin引擎的另一個特點(diǎn)是它可以支持復(fù)雜的數(shù)據(jù)模型。 例如，太平洋保險（CPIC，中國的一個保險集團(tuán)公司）有一個多達(dá)60維的模型。 Kylin提供標(biāo)準(zhǔn)的JDBC / ODBC / RestAPI接口，可實(shí)現(xiàn)與任何SQL應(yīng)用程序的連接。
Kyligence還開發(fā)了一個在線演示，展示了使用10億條航班記錄的BI體驗(yàn)。你可以查看這里來了解。比如，在舊金山國際機(jī)場過去20年里延誤最久的航班是哪個。（使用用戶名“analyst”和密碼“analyst”登錄，選擇“airline_cube”，拖放維度和事實(shí)數(shù)據(jù)來查詢這個數(shù)據(jù)集）
一個零售業(yè)場景：展示Kylin的速度
Kylin比傳統(tǒng)的基于Hadoop的SQL要快，是因?yàn)樗捎昧祟A(yù)計(jì)算來在SQL執(zhí)行前先行一步。例如，設(shè)想一個零售業(yè)務(wù)場景，你需要處理非常多的訂單，每個訂單包含多個商品。如果想知道訂單取消和退貨造成的影響，一個分析人員可能需要寫一個查詢來在某個時間段內(nèi)按照“returnflas（退貨標(biāo)記）”和“orderstatus（訂單狀態(tài)）”來匯總收入進(jìn)行匯報，如圖2 所示。圖里面顯示了這個查詢被編譯成的關(guān)系表達(dá)式，也叫執(zhí)行計(jì)劃。
圖2 一個典型的OLAP查詢的時間復(fù)雜度。圖片由Yang Li友情提供
從這個執(zhí)行計(jì)劃可以很容易地看出，這個執(zhí)行的時間復(fù)雜度至少是O(N)，這里N是表里的總行數(shù)，因?yàn)槊啃卸家辽俦辉L問一次。同時我們假定要關(guān)聯(lián)的表都已經(jīng)很好地被分區(qū)和索引過了，因此花費(fèi)比較大的關(guān)聯(lián)操作也可以在線性的時間復(fù)雜度上完成，但在實(shí)際場景里這種情況是不大可能的。
這個O(N)的時間復(fù)雜度并不好，因?yàn)檫@意味著如果數(shù)據(jù)量增長十倍，則查詢時間也會慢10倍。現(xiàn)在一個查詢需要花1秒鐘，那么以后隨著數(shù)據(jù)的增長，這個時間會變成10秒甚至是100秒。我們想要的是無論數(shù)據(jù)量大小，這個查詢時間都是固定不變的。
Kylin的解決方法是預(yù)計(jì)算。整體思路是，如果我們提前知道查詢的模式，我們就能預(yù)先計(jì)算出整個執(zhí)行的一部分。在上面這個例子里，就是預(yù)先計(jì)算Aggregate、Join和表掃描操作。生成的結(jié)果是一個立方體理論里的數(shù)據(jù)立方（或者可以把它叫做“實(shí)例化的總結(jié)表”，如果這樣聽起來覺得更好的話）。
如圖3所示，最初的執(zhí)行計(jì)劃就被轉(zhuǎn)換成了基于數(shù)據(jù)立方之上。這個數(shù)據(jù)立方體包含了按照“returnflag（退貨標(biāo)記）”、“orderstatus（訂單狀態(tài)）”和“date（日期）”進(jìn)行匯總的記錄。因?yàn)橥素洏?biāo)記和訂單狀態(tài)是一個固定的數(shù)量，而日期范圍被限定在3年（大概1000天）。這就意味著這個數(shù)據(jù)立方體里的行數(shù)最多就是“標(biāo)記數(shù)×狀態(tài)數(shù)×天數(shù)”，對O定義的時間復(fù)雜度來說就是一個常量。這個新的執(zhí)行計(jì)劃將會保證不管源數(shù)據(jù)有多大都有一個固定的執(zhí)行時間。這就我們想要的效果！
圖3. 通過預(yù)計(jì)算實(shí)現(xiàn)從O(N) 到O(1)。圖片由Yang Li友情提供
Kylin的架構(gòu)一覽
如我們所見，Kylin是一個依賴于預(yù)計(jì)算的系統(tǒng)。其核心是基于經(jīng)典的立方體理論，并發(fā)展成一個大數(shù)據(jù)上的SQL解決方案（見圖4）。它使用模型和立方體概念來定義預(yù)計(jì)算的空間。構(gòu)建引擎從數(shù)據(jù)源載入數(shù)據(jù)，并在使用MapReduce或Spark的分布式系統(tǒng)上進(jìn)行預(yù)計(jì)算。被計(jì)算出來的立方體被存儲在HBase里。當(dāng)一個查詢來到時，Kylin把它編譯成一個關(guān)系表達(dá)式，找到匹配的模型，并基于預(yù)計(jì)算好的數(shù)據(jù)立方體而不是原始數(shù)據(jù)執(zhí)行這個表達(dá)式。
圖4 Apache Kylin的架構(gòu)。圖片由Yang Li友情提供
這里的關(guān)鍵就是建模。如果你對數(shù)據(jù)以及分析的需求有非常好的理解，你是可以用正確的模型和立方體定義來找到正確的預(yù)計(jì)算。接著，絕大多數(shù)（如果不是全部）的查詢都可以被轉(zhuǎn)化成對此立方體的查詢。如圖5所示，執(zhí)行時間復(fù)雜度可以被降低到O(1)，從而獲得非?？斓牟樵兯俣龋瑹o論原始數(shù)據(jù)有多大。
圖5 O(N) 和O(1)的對比。圖片由Yang Li友情提供
（延展閱讀：一個展示Kylin在不同數(shù)據(jù)量級別上擁有一致的表現(xiàn)的星形模型基準(zhǔn)測試。）
Kylin 2.0的特性
對雪花模型的支持和TPC-H基準(zhǔn)測試
Kylin 2.0引入了對元數(shù)據(jù)建模的增強(qiáng)，并且可以支持開箱即用的雪花模型。為了演示建模和SQL能力上的改進(jìn)，我們進(jìn)行了用Kylin 2.0運(yùn)行TPC-H查詢的基準(zhǔn)測試。詳細(xì)步驟和結(jié)果可在這里找到，方便其他人重復(fù)和驗(yàn)證。
需要注意的是，這里的目標(biāo)并不是想與其他人的TPC-H結(jié)果進(jìn)行比較。一方面，根據(jù)TPC-H規(guī)范，不允許在表之間進(jìn)行預(yù)先計(jì)算，因此在這個意義上，Kylin不能算是有效的TPC-H系統(tǒng)。另一方面，我們還沒有對這些查詢進(jìn)行性能調(diào)優(yōu)。改善的空間還是很大的。
根據(jù)相同的零售場景，讓我們快速查看一些有趣的TPC-H查詢。圖6是TPC-H查詢07。SQL里面的字太小，可能看不清楚，但它給出了查詢的復(fù)雜性的粗略感覺。該圖是執(zhí)行計(jì)劃，強(qiáng)調(diào)了預(yù)計(jì)算（白色）與在線計(jì)算（藍(lán)色）的部分。很容易看出，大部分關(guān)系運(yùn)算符是預(yù)先計(jì)算的。剩下的Sort / Proj / Filter在很少的記錄上工作，因此查詢可以超快。在相同的硬件和相同的數(shù)據(jù)集上，Kylin用了0.17秒完成，而Hive + Tez對此查詢運(yùn)行了35.23秒。這顯示了預(yù)計(jì)算所帶來的差異。
圖6 TPC-H的查詢07。圖片由Yang Li友情提供
圖7所示的TPC-H查詢11是另一個例子。這個查詢有四個子查詢，比前一個更復(fù)雜。 其執(zhí)行計(jì)劃包括兩個分支，每個分支從預(yù)先計(jì)算的立方體載入數(shù)據(jù)。 分支結(jié)果再連接起來，這是一個復(fù)雜的在線計(jì)算。隨著在線計(jì)算部分的增加，預(yù)計(jì)算的部分減少，Kylin的運(yùn)行時間更長：3.42秒。 然而，完全在線計(jì)算的Hive + Tez仍然要慢一點(diǎn)，運(yùn)行時間為15.87秒。
圖7 TPC-H的查詢11。圖片由Yang Li友情提供
（有關(guān)Kylin和TPC-H的更多詳細(xì)信息，請參閱此鏈接。此鏈接包含可以在你自己的環(huán)境中重復(fù)基準(zhǔn)測試的步驟，以及我們在兩個不同Hadoop集群中測試的所有TPC-H查詢的性能結(jié)果。）
為近實(shí)時分析準(zhǔn)備的流式立方體
預(yù)先計(jì)算給ETL流程增加了額外的時間，這在實(shí)時場景中會成為一個問題。為了解決這個問題，Kylin現(xiàn)在支持增量加載新添加的數(shù)據(jù)，而不會影響歷史數(shù)據(jù)。 已有RestAPI可用于自動觸發(fā)增量構(gòu)建。每日構(gòu)建一次是最常見的，現(xiàn)在更頻繁的數(shù)據(jù)加載也是可行的。
從1.6版開始，Kylin可以直接從Kafka獲取數(shù)據(jù)，并進(jìn)行近乎實(shí)時的數(shù)據(jù)分析。使用基于內(nèi)存的立方體算法，微型增量構(gòu)建可以在幾分鐘內(nèi)完成。生成的結(jié)果是許多小的立方體分片，可以給查詢提供實(shí)時的結(jié)果。
為了展示這個特性是如何運(yùn)作的，我們構(gòu)建了一個演示網(wǎng)站來實(shí)時分析Twitter消息。它運(yùn)行在一個八個節(jié)點(diǎn)的AWS集群上，有三個Kafka broker。輸入是一個Twitter樣本源，每秒有超過10K條消息。立方體的平均復(fù)雜度是：九個維度和三個測量數(shù)據(jù)。增量構(gòu)建是每兩分鐘觸發(fā)一次，并在三分鐘內(nèi)完成?？傮w而言，系統(tǒng)在實(shí)時性上有五分鐘的延遲。
圖8 近實(shí)時的Twitter分析。圖片由Yang Li友情提供
該演示按照語言和設(shè)備維度顯示了Twitter消息的趨勢。在圖8中可以看到，美國白天的英文消息量上升，而亞洲語言的消息量在夜間下降。演示里還有一個標(biāo)簽云，用以顯示最新的熱門話題。在標(biāo)簽云下面是最熱門標(biāo)簽的趨勢。所有圖表都是實(shí)時到最近五分鐘。
總結(jié)
Apache Kylin是Hadoop上一個流行的OLAP引擎。通過使用預(yù)計(jì)算技術(shù)，它可以使SQL對大數(shù)據(jù)的查詢速度有數(shù)量級的加快，并使交互式BI和其他在線應(yīng)用程序能夠直接在大數(shù)據(jù)上運(yùn)行。
Kylin 2.0是最新版本，可以在這里下載。新版本的特性包括：Hadoop上的小于秒級的SQL延遲; 雪花模型的支持和成熟的SQL功能; 流式立方體用于近實(shí)時分析; 內(nèi)置時間/窗口/百分位數(shù)功能；和可以將構(gòu)建時間縮短一半的Spark構(gòu)建立方體。
相關(guān)資料：
Yang Li
Yang Li是Kyligence的聯(lián)合創(chuàng)始人兼CTO，以及Apache Kylin項(xiàng)目的聯(lián)合創(chuàng)立者和PMC成員。 作為Kylin的技術(shù)主管和架構(gòu)師，Yang專注于大數(shù)據(jù)分析、并行計(jì)算、數(shù)據(jù)索引、關(guān)系代數(shù)、近似算法等技術(shù)。他曾任eBay分析數(shù)據(jù)基礎(chǔ)設(shè)施部高級架構(gòu)師。他還是IBM InfoSphere BigInsights的技術(shù)領(lǐng)導(dǎo)者。在此期間，他負(fù)責(zé)BigInsights這一基于Hadoop的開源平臺，并獲得了IBM杰出技術(shù)成就獎。他曾經(jīng)是摩根士丹利的副總裁，負(fù)責(zé)全球監(jiān)管報告平臺。
