背景信息
eBay公司當前面臨的主要挑戰(zhàn)在于,數(shù)據(jù)規(guī)模正隨著用戶群體的多樣化拓展而水漲船高。我們的用戶——比如在分析與業(yè)務(wù)部門當中希望能在保持最低延遲水平的前提下繼續(xù)使用自己所熟悉的工具方案,例如Tableau與Excel。
有鑒于此,我們與公司內(nèi)部的分析部門進行緊密合作,并勾勒出eBay眼中足以構(gòu)成成功產(chǎn)品的基本要求:
1.數(shù)百億數(shù)據(jù)行的查詢延遲需要保持在次秒級別。
2.能夠為使用SQL兼容性工具的用戶提供ANSI SQL。
3.完整的OLAP方案以實現(xiàn)各類高級功能。
4.擁有對高基數(shù)與超大規(guī)模業(yè)務(wù)體系的支持能力。
5.面向成千上萬用戶的高并發(fā)性處理能力。
6.能夠處理TB乃至PB級別分析任務(wù)的分布式橫向擴展架構(gòu)。
我們很快意識到,沒有任何一種外部解決方案能夠切實滿足我們的具體要求——特別是在開源Hadoop社區(qū)當中。為了解決企業(yè)業(yè)務(wù)面臨的這一系列緊急狀況,我們決定從零開始自主打造一套平臺。在優(yōu)秀的技術(shù)團隊與部分試點客戶的通力配合之下,我們已經(jīng)能夠在將Kylin平臺引入生產(chǎn)環(huán)境的同時、為其發(fā)布一套開源版本。
重點特性概述
Kylin 是一套卓越的平臺方案,能夠在大數(shù)據(jù)分析領(lǐng)域?qū)崿F(xiàn)以下各項特性:
• 規(guī);h(huán)境下的極速OLAP引擎:Kylin的設(shè)計目的在于削減Hadoop環(huán)境中處理超過百億行數(shù)據(jù)時的查詢延遲時間。
• Hadoop上的ANSI SQL接口:Kylin能夠在Hadoop之上提供ANSI SQL并支持大部分ANSI SQL查詢功能。
•交互式查詢功能:用戶可以通過Kylin以秒級以下延遲水平實現(xiàn)與Hadoop數(shù)據(jù)的交互——在面對同一套數(shù)據(jù)集時,其性能表現(xiàn)優(yōu)于Hive查詢機制。
• 利用MOLAP cube(立方體)對數(shù)百億行數(shù)據(jù)進行查詢:用戶能夠在Kylin當中定義一套數(shù)據(jù)模型對其進行預(yù)構(gòu)建,其中所能包含的原始數(shù)據(jù)記錄可超過百億行。
• 與商務(wù)智能工具進行無縫化集成:Kylin目前能夠與多種商務(wù)智能工具相集成,包括Tableau以及其它第三方應(yīng)用程序。
• 開源ODBC驅(qū)動程序:Kylin的ODBC驅(qū)動程序從零開始逐步構(gòu)建而成,而且能夠與Tableau實現(xiàn)良好的協(xié)作效果。我們也已經(jīng)對這部分驅(qū)動程序進行開源處理并發(fā)布至技術(shù)社區(qū)當中。
其它特性:
- 任務(wù)管理與監(jiān)控機制
- 通過壓縮與編碼機制降低存儲容量需求
- cube的增量式更新
- 利用HBase協(xié)處理器實現(xiàn)查詢延遲控制
- 對不同計數(shù)進行近似查詢的能力(HyperLogLog)
- 提供易于使用的Web界面,旨在對cube進行管理、構(gòu)建、監(jiān)控與查詢
- cube/項目層面對ACL進行設(shè)置的安全功能
- 支持LDAP集成
基本設(shè)計思路
Kylin平臺的設(shè)計思路其實并非全新產(chǎn)生。在過去三十年當中,已經(jīng)有很多技術(shù)方案使用到同樣的理論依據(jù)來實現(xiàn)分析流程加速。具體而言,此類技術(shù)包括將預(yù)先計算完成的結(jié)果保存起來以備分析查詢、利用所有可能的維度組合為每個層級生成cuboid(基本方體)、或者是在不同層級上對全部指數(shù)進行計算。
下面這幅圖片所示為cuboid的拓撲結(jié)構(gòu),供大家用作參考:
圖1 cuboid的拓撲結(jié)構(gòu)
當數(shù)據(jù)規(guī)模變得越來越大時,預(yù)計算處理機制就會變得無法實現(xiàn)——即使硬件性能再強大也于事無補。不過在Hadoop強大的分布式計算能力支持下,計算任務(wù)能夠借助成百上千個計算節(jié)點的總體資源。這就保證了Kylin能夠以并發(fā)方式對這些計算任務(wù)進行處理,并通過合并生成最終結(jié)果——這能夠顯著降低整體處理時間。
從關(guān)系型到鍵-值型
下面舉一個實例,假設(shè)Hive表當中所保存的幾條記錄代表著一套關(guān)系型結(jié)構(gòu)。當其數(shù)據(jù)規(guī)模增長到極其巨大的水平時——例如上百億甚至過萬億行數(shù)據(jù)——那么像“2010年我們在美國本土售出了多少套技術(shù)類方案”這樣的簡單問題也將帶來涵蓋巨大數(shù)據(jù)量的表內(nèi)容掃描,給出應(yīng)答的延時狀況也會變得無法接受。由于每一次運行查詢時所需要的值是固定的,因此我們完全可以預(yù)先進行計算并對結(jié)果加以存儲、以備日后隨時調(diào)用。這項技術(shù)被稱為從關(guān)系型到鍵-值型(Relational to Key—Value,簡稱KV)處理。處理過程將生成所有維度組合并如下圖所示將測得值顯示出來——圖片右側(cè)為計算結(jié)果。圖片的中間一列內(nèi)容由左至右表示的是這類大規(guī)模數(shù)據(jù)處理流程中數(shù)據(jù)是如何由Map Reduce進行計算的。
圖2 Map Reduce計算
Kylin的構(gòu)建正是以這套理論為基礎(chǔ),而且在對大規(guī)模數(shù)據(jù)進行處理時充分發(fā)揮了Hadoop生態(tài)系統(tǒng)的強大能力:
1.從Hive當中讀取數(shù)據(jù)(這些數(shù)據(jù)被保存在HDFS之上)
2.運行Map Reduce任務(wù)以實現(xiàn)預(yù)計算
3.將cuba數(shù)據(jù)保存在HBase當中
4.利用Zookeeper進行任務(wù)協(xié)調(diào)
架構(gòu)
以下圖表所示為Kylin的高層架構(gòu)。
圖3 Kylin的高層架構(gòu)圖
以上圖表勾勒出Cube構(gòu)建引擎(Cube Build Engine)是如何以離線處理方式將關(guān)系型數(shù)據(jù)轉(zhuǎn)化成鍵-值型數(shù)據(jù)的。其中的黃線部分還表現(xiàn)出在線分析數(shù)據(jù)的處理流程。數(shù)據(jù)請求可以利用基于SQL的工具由SQL提交而產(chǎn)生,或者利用第三方應(yīng)用程序通過Kylin的RESTful服務(wù)來實現(xiàn)。RESTful服務(wù)會調(diào)用Query Engine,后者則檢測對應(yīng)的目標數(shù)據(jù)集是否真實存在。如果確實存在,該引擎會直接訪問目標數(shù)據(jù)并以次秒級延遲返回結(jié)果。如果目標數(shù)據(jù)集并不存在,該引擎則會根據(jù)設(shè)計將無匹配數(shù)據(jù)集的查詢路由至Hadoop上的SQL處、即交由Hive等Hadoop集群負責處理。
以下為關(guān)于Kylin平臺內(nèi)所有組件的詳細描述。
•元數(shù)據(jù)管理工具(Metadata Manager):Kylin是一款元數(shù)據(jù)驅(qū)動型應(yīng)用程序。元數(shù)據(jù)管理工具是一大關(guān)鍵性組件,用于對保存在Kylin當中的所有元數(shù)據(jù)進行管理,其中包括最為重要的cube元數(shù)據(jù)。其它全部組件的正常運作都需以元數(shù)據(jù)管理工具為基礎(chǔ)。
•任務(wù)引擎(Job Engine):這套引擎的設(shè)計目的在于處理所有離線任務(wù),其中包括shell腳本、Java API以及Map Reduce任務(wù)等等。任務(wù)引擎對Kylin當中的全部任務(wù)加以管理與協(xié)調(diào),從而確保每一項任務(wù)都能得到切實執(zhí)行并解決其間出現(xiàn)的故障。
•存儲引擎(Storage Engine):這套引擎負責管理底層存儲——特別是cuboid,其以鍵-值對的形式進行保存。存儲引擎使用的是HBase——這是目前Hadoop生態(tài)系統(tǒng)當中最理想的鍵-值系統(tǒng)使用方案。Kylin還能夠通過擴展實現(xiàn)對其它鍵-值系統(tǒng)的支持,例如Redis。
•REST Server: REST Server是一套面向應(yīng)用程序開發(fā)的入口點,旨在實現(xiàn)針對Kylin平臺的應(yīng)用開發(fā)工作。 此類應(yīng)用程序可以提供查詢、獲取結(jié)果、觸發(fā)cube構(gòu)建任務(wù)、獲取元數(shù)據(jù)以及獲取用戶權(quán)限等等。
•ODBC驅(qū)動程序:為了支持第三方工具與應(yīng)用程序——例如Tableau——我們構(gòu)建起了一套ODBC驅(qū)動程序并對其進行了開源。我們的目標是讓用戶能夠更為順暢地采用這套Kylin平臺。
•查詢引擎(Query Engine):當cube準備就緒后,查詢引擎就能夠獲取并解析用戶查詢。它隨后會與系統(tǒng)中的其它組件進行交互,從而向用戶返回對應(yīng)的結(jié)果。
在Kylin當中,我們使用一套名為Apache Calcite的開源動態(tài)數(shù)據(jù)管理框架對代碼內(nèi)的SQL以及其它插入內(nèi)容進行解析。Calcite架構(gòu)如下圖所示。(Calcite最初被命名為Optiq,由Julian Hyde所編寫,但如今已經(jīng)成為Apache孵化器項目之一。)
圖4 Calcite架構(gòu)圖
Kylin在eBay公司中的應(yīng)用
在對Kylin進行開源化處理的同時,我們已經(jīng)在eBay公司的多個業(yè)務(wù)部門當中將其應(yīng)用于生產(chǎn)實踐。其中規(guī)模最大的用例就是對由120多億條源記錄所生成的超過14TB cube數(shù)據(jù)進行分析。90%的查詢請求都能在5秒鐘之內(nèi)獲取到返回結(jié)果,F(xiàn)在,我們擁有更多面向分析師以及業(yè)務(wù)用戶的用例,他們能夠訪問這些分析機制并輕松通過Tableau儀表板獲取相關(guān)結(jié)果——而不再需要借助Hive查詢或者shell命令等復(fù)雜機制。
下一步發(fā)展規(guī)劃
• 在高基數(shù)維度上支持TopN算法(即對大量對象進行排序并從中選取前N位結(jié)果):目前的MOLAP技術(shù)在高基數(shù)維度上進行查詢時的表現(xiàn)尚算不上完美——例如對單一列中的數(shù)百萬個不同值進行TopN運算。
與各類搜索引擎類似(正如眾多研究人員所指出),倒排索引是此類預(yù)構(gòu)建結(jié)果的理想匹配機制。
• 支持混合OLAP(簡稱HOLAP):MOLAP在歷史數(shù)據(jù)查詢領(lǐng)域擁有出色的實際表現(xiàn),但由于越來越多數(shù)據(jù)需要以實時方式加以處理,因此我們需要盡快將實時/近實時處理結(jié)果與歷史結(jié)果結(jié)合起來、以作為業(yè)務(wù)決策中的參考信息。很多內(nèi)存內(nèi)技術(shù)方案已經(jīng)能夠以關(guān)系型OLAP(簡稱ROLAP)的方式滿足上述需求。而Kylin的下一代版本將成為混合OLAP(簡稱HOLAP),即結(jié)合MOLAP與ROLAP雙方的優(yōu)勢以帶來單一一套面向前端查詢的入口點方案。
開源
Kylin已經(jīng)以開源姿態(tài)被交付至技術(shù)社區(qū)。為了以Kylin為核心發(fā)展出更為強大的生態(tài)系統(tǒng),我們目前正提議將Kylin轉(zhuǎn)化為Apache孵化器項目。在Owen O’Malley(Hortonworks公司聯(lián)合創(chuàng)始人兼Apache成員)與Julian Hyde(Apache Calcite締造者,目前供職于Hortonworks公司)等Hadoop開發(fā)者社區(qū)支持者的鼎力協(xié)助,我們相信Kylin足以乘開源社區(qū)這股強勁的東風順利跨入新的紀元。
作為起步,大家并不一定馬上就要對核心代碼庫進行開源貢獻,從以下方面著手也是不錯的選擇:
1.Shell客戶端
2.RPC服務(wù)器
3.任務(wù)調(diào)度
4.工具
總結(jié)
Kylin已經(jīng)在eBay公司內(nèi)部融入生產(chǎn)環(huán)境,專門負責處理規(guī)模極端龐大的數(shù)據(jù)集。這套平臺擁有顯著的性能優(yōu)勢,實踐證明其能夠幫助分析師們輕松借助自己所為熟悉的工具對Hadoop當中的數(shù)據(jù)進行充分利用。
核心關(guān)注:拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業(yè)務(wù)管理理念,功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理,全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域,是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題:Kylin正式發(fā)布:面向大數(shù)據(jù)的終極OLAP引擎方案
本文網(wǎng)址:http://www.ezxoed.cn/html/support/11121517189.html