為大資料帶來互動式的BI
編者注: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傑出技術成就獎。他曾經是摩根士丹利的副總裁,負責全球監管報告平臺。
Strata Data Conference北京站正在報名中,點選圖片中二維碼可登入會議網站,瀏覽截止到目前為止的講師名單和已經確認的議題。
早期票價優惠期截止到6月9日,儘快註冊以確保留位。
相關文章
- 為什麼大資料不等於BI?大資料
- 大資料帶來的憂傷大資料
- 大資料時代帶來的大變革大資料
- 資料賦能的未來,是嵌入式BI
- 解析大資料能為媒體帶來什麼?大資料
- CIO:大資料為ComScore帶來新客戶大資料
- 大資料和人工智慧為廣告主帶來的價值大資料人工智慧
- 做電商的看過來,華為雲大資料BI方案驅動業務增長大資料
- 大資料帶來的四種思維大資料
- 如何解決資料驅動帶來強互動和深層次通訊的痛點
- 大資料洪流為市場營銷帶來了大機會–資訊圖大資料
- 互動式資料視覺化的優勢視覺化
- 大資料帶來了哪些改變大資料
- 談遊戲世界互動設計帶來的「意外之喜」遊戲
- 關聯式資料庫大泥球帶來的管理問題和對策 - pathelland資料庫
- 每日互動大資料五一出行洞察大資料
- DaaS:大資料作為服務,會給企業帶來什麼?大資料
- 資料互動
- 酷雲互動:從現在到未來 大資料正在革新文娛產業大資料產業
- 大資料帶來三大根本性改變大資料
- BI怎樣才能搞定大資料大資料
- 大資料用於教育帶來的負面衝擊大資料
- 大資料時代美國帶來的經驗與啟示大資料
- 3D模型+BI分析,打造全新的互動式3D視覺化大屏開發方案3D模型視覺化
- Spark 互動式處理上百 TB 資料Spark
- 電力大資料的有效應用帶來的鉅變大資料
- WPF和js互動 WebBrowser資料互動JSWeb
- Flask資料互動Flask
- 資料視覺化大屏能為物聯網專案帶來什麼視覺化
- 95%醫療大資料被浪費 被放空的大資料帶來更大診療成本大資料
- 使用互動式 shell 來增強你的 PythonPython
- 大資料會取代傳統BI嗎大資料
- 資料庫選型解讀,分散式資料庫帶來的技術革命資料庫分散式
- pwc:全球CEO看重移動互動技術和大資料大資料
- 互動派:大資料必將驅動企業變革大資料
- 2.3.2 關於使用互動式DBCA建立資料庫資料庫
- 讓資料為你帶來無限可能性
- BI:資料說Facebook歷史和未來