編者注：本文來自微信公眾號“OReillyData”（ID：OReillyData），Kyligence的聯合創始人和CEO Luke Han在2017年5月22-25日舉行的Strata Data倫敦大會上做題為“Apache Kylin在中國的使用案例”的演講。
基于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萬億條記錄的表，對它的平均查詢響應時間低于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在不同數據量級別上擁有一致的表現的星形模型基準測試。）
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: "Bringing interactive BI to big data".
Yang Li
Yang Li是Kyligence的聯合創始人兼CTO，以及Apache Kylin項目的聯合創立者和PMC成員。 作為Kylin的技術主管和架構師，Yang專注于大數據分析、并行計算、數據索引、關系代數、近似算法等技術。他曾任eBay分析數據基礎設施部高級架構師。他還是IBM InfoSphere BigInsights的技術領導者。在此期間，他負責BigInsights這一基于Hadoop的開源平臺，并獲得了IBM杰出技術成就獎。他曾經是摩根士丹利的副總裁，負責全球監管報告平臺。
7月12-15日, 由O'Reilly和Cloudera共同舉辦的全球頂尖的數據盛會Strata Data Conference將重返中國
編者注：本文來自微信公眾號“OReillyData”（ID：OReillyData），Kyligence的聯合創始人和CEO Luke Han在2017年5月22-25日舉行的Strata Data倫敦大會上做題為“Apache Kylin在中國的使用案例”的演講。
基于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萬億條記錄的表，對它的平均查詢響應時間低于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在不同數據量級別上擁有一致的表現的星形模型基準測試。）
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構建立方體。
相關資料：
Apache Kylin的星形模型基準測試
Apache Kylin的TPC-H基準測試
Kyligence的演示、交互式BI和Twitter流式分析
This article originally appeared in English: "Bringing interactive BI to big data".
Yang Li
Yang Li是Kyligence的聯合創始人兼CTO，以及Apache Kylin項目的聯合創立者和PMC成員。 作為Kylin的技術主管和架構師，Yang專注于大數據分析、并行計算、數據索引、關系代數、近似算法等技術。他曾任eBay分析數據基礎設施部高級架構師。他還是IBM InfoSphere BigInsights的技術領導者。在此期間，他負責BigInsights這一基于Hadoop的開源平臺，并獲得了IBM杰出技術成就獎。他曾經是摩根士丹利的副總裁，負責全球監管報告平臺。
7月12-15日, 由O'Reilly和Cloudera共同舉辦的全球頂尖的數據盛會Strata Data Conference將重返中國
京公網安備 11010502049343號