Apache Kylin™是一個開源的分布式分析引擎,提供Hadoop/Spark之上的SQL查詢接口及多元分析(OLAP)能力以支援超大規模資料,最初由eBay Inc. 開發并貢獻至開源社群。它能在亞秒内查詢巨大的Hive表。
如果你有海量資料(TB-PB)的多元分析的需求,Kylin是一個不錯的選擇。
文檔參考官網 http://kylin.apache.org/cn/
Kylin的主要特征功能:
- 壓秒級的查詢響應
- 對接标準SQL,支援多種資料源
- 支援流式資料的分析處理能力
- 自帶web 管理界面
- 支援相容多個BI工具
Kylin的技術架構(圖來自官方文檔)
Kylin是基于Hadoop生态的一個多元分析軟體,基于對海量資料進行預先計算,來實作海量資料的壓秒級的響應,空間換時間。
-
中繼資料:使用kylin需要預先對資料進行模組化,模組化主要是設定表之間的join關系,設定分區資訊。目前kylin支援星型和雪花模型,模組化後,需要進行分析次元和度量的設定。比如說 城市字段是一個次元,比如訂單總數是一個度量。這些設定都會存儲在中繼資料(Metadata)中。
中繼資料是預設存儲在HBase裡的,使用者的原始資料可以是存儲在Hive,RDMS資料庫等。Kylin都能支援。
- 建構:有了Metadata,kylin就可以根據metadata來進行預先計算。Cube Build Engine,也就是資料立方體建構。
這個圖是啥意思呢?
假設我們定義了需要分析資料的四個次元 性别,地區,年齡,日期,有一個度量,比如通路某個網站的總次數。
那kylin的預計算就會進行如下的預先聚合運算
次元組合 | 度量 |
---|---|
性别-地區-年齡-日期 | 網站的通路總次數 |
性别-地區-年齡 | 通路次數 |
性别-地區-日期 | 通路次數 |
性别-年齡-日期 | 通路次數 |
地區-年齡-日期 | 通路次數 |
性别-地區 | 通路次數 |
性别-年齡 | 通路次數 |
性别-日期 | 通路次數 |
地區-年齡 | 通路次數 |
地區-日期 | 通路次數 |
年齡-日期 | 通路次數 |
性别 | 通路次數 |
地區 | 通路次數 |
年齡 | 通路次數 |
日期 | 通路次數 |
kylin通過多個次元的組合,由多到少逐層進行聚合運算。比如四個次元聚合算出sum(通路記錄),存儲到Hbase裡(預設)row key就是次元組合生成的編碼,value就是對應的sum度量的值。下面的表格示範了kylin預計算的資料在hbase總的存儲形式
Rowkey | CF |
---|---|
12-上海-男-2011-1-1 | cf1.c=100 |
12-上海-男-2011-1-2 | cf1.c=40 |
17-上海-男-2011-1-2 | cf1.c=12 |
14-上海-男-2011-1-2 | cf1.c=12 |
14-上海 | cf1.c=112 |
17-上海 | cf1.c=112 |
… | … |
Kylin 對次元的名稱進行了編碼,減少了存儲的成本,類似下面表格
Rowkey | CF |
---|---|
1201012011111 | cf1.c=100 |
1201012011112 | cf1.c=40 |
1701012011112 | cf1.c=12 |
1401012011112 | cf1.c=12 |
1401 | cf1.c=112 |
1701 | cf1.c=112 |
… | … |
-
Query engine:查詢引擎的核心就是把query路由到對應的cuboid預聚合的資料。由于進行了預先聚合,是以查詢需要掃描的資料數量将大幅度減少,是以這就是壓秒級反應的秘密所在。
比如 select sum(a) from table group by area,age 這個sql将會由 地區和年齡這個組合算出來的cuboid來進行回答。Kylin内置的查詢引擎是Calcite,Calcite是一個獨立與使用者和資料源之間的一個sql文法解析執行的引擎。他可以對sql進行校驗,解析成文法樹,執行樹等。kylin重寫了Calcite的 Schema 和 table 邏輯,并定義了優化rule,最後轉化路由到對應的cuboid。更厲害的是,如果你的sql無法被cuboid回答,kylin還支援pushdown下壓到原始資料上查詢,保證了統一的互動體驗和優雅的查詢降級。
- RestAPI:Kylin提供了大量的友好的api,供使用者調用內建到自己的系統或者運維腳本裡。
- 界面WebUI:Kylin提供了友好的管理界面。界面使用者可以通過可視化的方式來建立資料模型,建立cube,建構cube,以及包含了查詢、系統配置、project管理、使用者管理、權限管理等。降低了使用和管理的成本。
- Real實時分析:傳統的大資料分析,往往是對曆史資料的查詢。随着企業分析越來越精準,以及資料資訊變化速率越來越快。更多的企業尤其是網際網路企業需要進行實時資料的分析。很顯然kylin的上述原理根本無法做到實時,因為ETL和建構都需要時間,這個延遲是無法避免的。Kylin目前存在兩種實時方案。
- 一種是近似實時,提供了分鐘級别的延遲方案。基本原理就是提高了建構的顆粒度。比如原來是按照天建構,變成了分鐘級别的建構。建構還是利用MapReducer等
- 一種是準實時,基于記憶體的實時建構,在一個時間窗内,對實時資料進行聚合,聚合達到一個門檻值的時候,實時的建構資料會轉義到傳統的hbase中。變成曆史建構資料,當使用者sql跨域實時和曆史的時候,kylin将通過将實時建構和曆史資料結合來回答使用者的query。由于是在記憶體中進行的預計算。是以幾乎達到了秒級的延遲。
Apache kylin 的這些功能足以讓你在海量資料多元分析場景下擺脫傳統方式的低延遲,語義相容差,成本低等問題。成為OLAP的一大神器。