本文轉載自：【技術帖】Apache Kylin 2.0為大資料帶來互動式的BI

編者注：Kyligence的聯合創始人兼CEO Luke Han在上做題為“”的演講。

基於Hadoop的SQL一直在被持續地改進，但是一個查詢等幾分鐘到幾小時還是非常正常。在這篇博文裡，將會介紹開源的分散式分析引擎Apache Kylin，尤其會重點介紹它是如何以數量級加速大資料查詢，以及在2.0版裡面為互動式BI所提供的新特性，包括對雪花模型的支援和流式建立資料立方。

Apache Kylin是什麼？

Kylin是一個在Hadoop上的OLAP引擎。如圖1所示，Kylin位於Hadoop之上，向上層的應用提供了基於標準SQL介面的關係型資料。

圖1 Apache Kylin的位置。圖片由Yang Li友情提供

Kylin可以處理大資料集，從查詢延遲上講是很快的，這也是它和其他基於Hadoop的SQL的區別。比如，我們所知道的使用Kylin的最大的生產系統例項是在今日頭條，一箇中國的新聞推送應用。頭條有一個包含3萬億條記錄的表，Kylin對它的平均查詢響應時間低於1秒。下一節我們會討論Kylin是怎麼實現這麼快的查詢。

Kylin引擎的另一個特點是它可以支援複雜的資料模型。例如，太平洋保險（CPIC，中國的一個保險集團公司）有一個多達60維的模型。 Kylin提供標準的JDBC / ODBC / RestAPI介面，可實現與任何SQL應用程式的連線。

Kyligence還開發了一個，展示了使用10億條航班記錄的BI體驗。你可以檢視這裡來了解。比如，在舊金山國際機場過去20年裡延誤最久的航班是哪個。（使用使用者名稱“analyst”和密碼“analyst”登入，選擇“airline_cube”，拖放維度和事實資料來查詢這個資料集）

一個零售業場景：展示Kylin的速度

Kylin比傳統的基於Hadoop的SQL要快，是因為它採用了預計算來在SQL執行前先行一步。例如，設想一個零售業務場景，你需要處理非常多的訂單，每個訂單包含多個商品。如果想知道訂單取消和退貨造成的影響，一個分析人員可能需要寫一個查詢來在某個時間段內按照“returnflas（退貨標記）”和“orderstatus（訂單狀態）”來彙總收入進行彙報，如圖2 所示。圖裡面顯示了這個查詢被編譯成的關係表示式，也叫執行計劃。

圖2 一個典型的OLAP查詢的時間複雜度。圖片由Yang Li友情提供

從這個執行計劃可以很容易地看出，這個執行的時間複雜度至少是O(N)，這裡N是表裡的總行數，因為每行都要至少被訪問一次。同時我們假定要關聯的表都已經很好地被分割槽和索引過了，因此花費比較大的關聯操作也可以線上性的時間複雜度上完成，但在實際場景裡這種情況是不大可能的。

這個O(N)的時間複雜度並不好，因為這意味著如果資料量增長十倍，則查詢時間也會慢10倍。現在一個查詢需要花1秒鐘，那麼以後隨著資料的增長，這個時間會變成10秒甚至是100秒。我們想要的是無論資料量大小，這個查詢時間都是固定不變的。

Kylin的解決方法是預計算。整體思路是，如果我們提前知道查詢的模式，我們就能預先計算出整個執行的一部分。在上面這個例子裡，就是預先計算Aggregate、Join和表掃描操作。生成的結果是一個立方體理論裡的資料立方（或者可以把它叫做“例項化的總結表”，如果這樣聽起來覺得更好的話）。

如圖3所示，最初的執行計劃就被轉換成了基於資料立方之上。這個資料立方體包含了按照“returnflag（退貨標記）”、“orderstatus（訂單狀態）”和“date（日期）”進行彙總的記錄。因為退貨標記和訂單狀態是一個固定的數量，而日期範圍被限定在3年（大概1000天）。這就意味著這個資料立方體裡的行數最多就是“標記數×狀態數×天數”，對O定義的時間複雜度來說就是一個常量。這個新的執行計劃將會保證不管源資料有多大都有一個固定的執行時間。這就我們想要的效果！

圖3 通過預計算實現從O(N)到O(1)。圖片由Yang Li友情提供Kylin的架構一覽

如我們所見，Kylin是一個依賴於預計算的系統。其核心是基於經典的立方體理論，並發展成一個大資料上的SQL解決方案（見圖4）。它使用模型和立方體概念來定義預計算的空間。構建引擎從資料來源載入資料，並在使用MapReduce或Spark的分散式系統上進行預計算。被計算出來的立方體被儲存在HBase裡。當一個查詢來到時，Kylin把它編譯成一個關係表示式，找到匹配的模型，並基於預計算好的資料立方體而不是原始資料執行這個表示式。

圖4 Apache Kylin的架構。圖片由Yang Li友情提供

這裡的關鍵就是建模。如果你對資料以及分析的需求有非常好的理解，你是可以用正確的模型和立方體定義來找到正確的預計算。接著，絕大多數（如果不是全部）的查詢都可以被轉化成對此立方體的查詢。如圖5所示，執行時間複雜度可以被降低到O(1)，從而獲得非常快的查詢速度，無論原始資料有多大。

圖5 O(N)和O(1)的對比。圖片由Yang Li友情提供（延展閱讀： ） Kylin 2.0的特性

對雪花模型的支援和TPC-H基準測試

Kylin 2.0引入了對元資料建模的增強，並且可以支援開箱即用的雪花模型。為了演示建模和SQL能力上的改進，我們進行了用Kylin 2.0執行TPC-H查詢的基準測試。

需要注意的是，這裡的目標並不是想與其他人的TPC-H結果進行比較。一方面，根據TPC-H規範，不允許在表之間進行預先計算，因此在這個意義上，Kylin不能算是有效的TPC-H系統。另一方面，我們還沒有對這些查詢進行效能調優。改善的空間還是很大的。

根據相同的零售場景，讓我們快速檢視一些有趣的TPC-H查詢。圖6是TPC-H查詢07。SQL裡面的字太小，可能看不清楚，但它給出了查詢的複雜性的粗略感覺。該圖是執行計劃，強調了預計算（白色）與線上計算（藍色）的部分。很容易看出，大部分關係運算符是預先計算的。剩下的Sort / Proj / Filter在很少的記錄上工作，因此查詢可以超快。在相同的硬體和相同的資料集上，Kylin用了0.17秒完成，而Hive + Tez對此查詢運行了35.23秒。這顯示了預計算所帶來的差異。

圖6 TPC-H的查詢07。圖片由Yang Li友情提供

圖7所示的TPC-H查詢11是另一個例子。這個查詢有四個子查詢，比前一個更復雜。 其執行計劃包括兩個分支，每個分支從預先計算的立方體載入資料。 分支結果再連線起來，這是一個複雜的線上計算。隨著線上計算部分的增加，預計算的部分減少，Kylin的執行時間更長：3.42秒。 然而，完全線上計算的Hive + Tez仍然要慢一點，執行時間為15.87秒。

圖7 TPC-H的查詢11。圖片由Yang Li友情提供

（有關Kylin和TPC-H的更多詳細資訊，請參閱此連結包含可以在你自己的環境中重複基準測試的步驟，以及我們在兩個不同Hadoop叢集中測試的所有TPC-H查詢的效能結果。）

為近實時分析準備的流式立方體

預先計算給ETL流程增加了額外的時間，這在實時場景中會成為一個問題。為了解決這個問題，Kylin現在支援增量載入新新增的資料，而不會影響歷史資料。 已有RestAPI可用於自動觸發增量構建。每日構建一次是最常見的，現在更頻繁的資料載入也是可行的。

從1.6版開始，Kylin可以直接從Kafka獲取資料，並進行近乎實時的資料分析。使用基於記憶體的立方體演算法，微型增量構建可以在幾分鐘內完成。生成的結果是許多小的立方體分片，可以給查詢提供實時的結果。

為了展示這個特性是如何運作的，我們構建了一個來實時分析Twitter訊息。它執行在一個八個節點的AWS叢集上，有三個Kafka broker。輸入是一個Twitter樣本源，每秒有超過10K條訊息。立方體的平均複雜度是：九個維度和三個測量資料。增量構建是每兩分鐘觸發一次，並在三分鐘內完成。總體而言，系統在實時性上有五分鐘的延遲。

圖8 近實時的Twitter分析。圖片由Yang Li友情提供

該演示按照語言和裝置維度顯示了Twitter訊息的趨勢。在圖8中可以看到，美國白天的英文訊息量上升，而亞洲語言的訊息量在夜間下降。演示裡還有一個標籤雲，用以顯示最新的熱門話題。在標籤雲下面是最熱門標籤的趨勢。所有圖表都是實時到最近五分鐘。

總結

Apache Kylin是Hadoop上一個流行的OLAP引擎。通過使用預計算技術，它可以使SQL對大資料的查詢速度有數量級的加快，並使互動式BI和其他線上應用程式能夠直接在大資料上執行。

Kylin 2.0是最新版本，可以下載。新版本的特性包括：Hadoop上的小於秒級的SQL延遲; 雪花模型的支援和成熟的SQL功能; 流式立方體用於近實時分析; 內建時間/視窗/百分位數功能；和可以將構建時間縮短一半的Spark構建立方體。

相關資料：

This article originally appeared in English: "".

Yang Li

Yang Li是Kyligence的聯合創始人兼CTO，以及Apache Kylin專案的聯合創立者和PMC成員。 作為Kylin的技術主管和架構師，Yang專注於大資料分析、平行計算、資料索引、關係代數、近似演算法等技術。他曾任eBay分析資料基礎設施部高階架構師。他還是IBM InfoSphere BigInsights的技術領導者。在此期間，他負責BigInsights這一基於Hadoop的開源平臺，並獲得了IBM傑出技術成就獎。他曾經是摩根士丹利的副總裁，負責全球監管報表基礎架構。

（文章轉載自OReillyData）

7月12-15日, 由O'Reilly和Cloudera共同舉辦的全球頂尖的資料盛會Strata Data Conference

"Apache and Apache Kylin are either registered trademarks or trademarks of The Apache Software Foundation in the US and/or other countries. No endorsement by The Apache Software Foundation is implied by the use of these marks."