一文讀懂Apache Kylin

“麒麟出沒,必有祥瑞。”
                              —— 中國古諺語

Kylin思維導(dǎo)圖

前言

隨著移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等技術(shù)的發(fā)展,近些年人類所積累的數(shù)據(jù)正在呈爆炸式的增長,大數(shù)據(jù)時(shí)代已經(jīng)來臨。但是海量數(shù)據(jù)的收集只是大數(shù)據(jù)技術(shù)的第一步,如何讓數(shù)據(jù)產(chǎn)生價(jià)值才是大數(shù)據(jù)領(lǐng)域的終極目標(biāo)。Hadoop的出現(xiàn)解決了數(shù)據(jù)存儲(chǔ)問題,但如何對(duì)海量數(shù)據(jù)進(jìn)行OLAP查詢,卻一直令人十分頭疼。

企業(yè)中的查詢大致可分為即席查詢和定制查詢兩種。之前出現(xiàn)的很多OLAP引擎,包括Hive、Presto、SparkSQL等,雖然在很大程度上降低了數(shù)據(jù)分析的難度,但它們都只適用于即席查詢的場景。它們的優(yōu)點(diǎn)是查詢靈活,但是隨著數(shù)據(jù)量和計(jì)算復(fù)雜度的增長,響應(yīng)時(shí)間不能得到保證。而定制查詢多數(shù)情況下是對(duì)用戶的操作做出實(shí)時(shí)反應(yīng),Hive等查詢引擎動(dòng)輒數(shù)分鐘甚至數(shù)十分鐘的響應(yīng)時(shí)間顯然是不能滿足需求的。在很長一段時(shí)間里,企業(yè)只能對(duì)數(shù)據(jù)倉庫中的數(shù)據(jù)進(jìn)行提前計(jì)算,再將算好后的結(jié)果存儲(chǔ)在MySQL等關(guān)系型數(shù)據(jù)庫中,再提供給用戶進(jìn)行查詢。但是當(dāng)業(yè)務(wù)復(fù)雜度和數(shù)據(jù)量逐漸升高后,使用這套方案的開發(fā)成本和維護(hù)成本都顯著上升。因此,如何對(duì)已經(jīng)固化下來的查詢進(jìn)行亞秒級(jí)返回一直是企業(yè)應(yīng)用中的一個(gè)痛點(diǎn)。

在這種情況下,Apache Kylin應(yīng)運(yùn)而生。不同于“大規(guī)模并行處理”(Massive Parallel Processing,MPP)架構(gòu)的Hive、Presto等,Apache Kylin采用“預(yù)計(jì)算”的模式,用戶只需要提前定義好查詢維度,Kylin將幫助我們進(jìn)行計(jì)算,并將結(jié)果存儲(chǔ)到HBase中,為海量數(shù)據(jù)的查詢和分析提供亞秒級(jí)返回,是一種典型的“空間換時(shí)間”的解決方案。Apache Kylin的出現(xiàn)不僅很好地解決了海量數(shù)據(jù)快速查詢的問題,也避免了手動(dòng)開發(fā)和維護(hù)提前計(jì)算程序帶來的一系列麻煩。

Apache Kylin最初由eBay公司開發(fā),并貢獻(xiàn)給Apache基金會(huì),但是目前Apache Kylin的核心開發(fā)團(tuán)隊(duì)已經(jīng)自立門戶,創(chuàng)建了Kyligence公司。值得一提的是,Apache Kylin是第一個(gè)由中國人主導(dǎo)的Apache頂級(jí)項(xiàng)目(2017年4月19日,華為的 CarbonData成為Apache頂級(jí)項(xiàng)目,因此Apache Kylin不再是唯一由國人貢獻(xiàn)的Apache頂級(jí)項(xiàng)目)。由于互聯(lián)網(wǎng)技術(shù)和開源思想進(jìn)入我國的時(shí)間較晚,開源軟件的世界一直是由西方國家主導(dǎo),在數(shù)據(jù)領(lǐng)域也不例外。從Hadoop到Spark,再到最近大熱的機(jī)器學(xué)習(xí)平臺(tái)TenserFlow等,均是如此。但近些年來,我們很欣喜地看到以Apache Kylin為首的各種以國人主導(dǎo)的開源項(xiàng)目不斷地涌現(xiàn)出來,這些技術(shù)不斷縮小著我國與西方開源技術(shù)強(qiáng)國之間的差距,提升我國技術(shù)人員在國際開源社區(qū)的影響力。

一、核心概念

在了解Apache Kylin的使用以前,我們有必要先來了解一下在Apache Kylin中會(huì)出現(xiàn)的核心概念。

數(shù)據(jù)倉庫

Data Warehouse,簡稱DW,中文名數(shù)據(jù)倉庫,是商業(yè)智能(BI)中的核心部分。主要是將不同數(shù)據(jù)源的數(shù)據(jù)整合到一起,通過多維分析等方式為企業(yè)提供決策支持和報(bào)表生成。那么它與我們熟悉的傳統(tǒng)關(guān)系型數(shù)據(jù)庫有什么不同呢?

簡而言之,用途不同。數(shù)據(jù)庫面向事務(wù),而數(shù)據(jù)倉庫面向分析。數(shù)據(jù)庫一般存儲(chǔ)在線的業(yè)務(wù)數(shù)據(jù),需要對(duì)上層業(yè)務(wù)的改變做出實(shí)時(shí)反應(yīng),涉及到增刪查改等操作,所以需要遵循三大范式,需要ACID。而數(shù)據(jù)倉庫中存儲(chǔ)的則主要是歷史數(shù)據(jù),主要目的是為企業(yè)決策提供支持,所以可能存在大量數(shù)據(jù)冗余,但利于多個(gè)維度查詢,為決策者提供更多觀察視角。

在傳統(tǒng)BI領(lǐng)域中,數(shù)據(jù)倉庫的數(shù)據(jù)同樣存儲(chǔ)在Oracle、MySQL等數(shù)據(jù)庫中,而在大數(shù)據(jù)領(lǐng)域中最常用的數(shù)據(jù)倉庫就是Apache Hive,Hive也是Apache Kylin默認(rèn)的數(shù)據(jù)源。

OLAP

OLAP(Online Analytical Process),聯(lián)機(jī)分析處理,以多維度的方式分析數(shù)據(jù),一般帶有主觀的查詢需求,多應(yīng)用在數(shù)據(jù)倉庫。與之對(duì)應(yīng)的是OLTP(Online Transaction Process),聯(lián)機(jī)事務(wù)處理,側(cè)重于數(shù)據(jù)庫的增刪查改等常用業(yè)務(wù)操作。了解了上面數(shù)據(jù)庫與數(shù)據(jù)倉庫的區(qū)別后,OLAP與OLTP的區(qū)別就不難理解了。

維度和度量

維度和度量是數(shù)據(jù)分析領(lǐng)域中兩個(gè)常用的概念。

簡單地說,維度就是觀察數(shù)據(jù)的角度。比如傳感器的采集數(shù)據(jù),可以從時(shí)間的維度來觀察:

時(shí)間維度

也可以進(jìn)一步細(xì)化,從時(shí)間和設(shè)備兩個(gè)角度觀察:

時(shí)間和設(shè)備維度

維度一般是離散的值,比如時(shí)間維度上的每一個(gè)獨(dú)立的日期,或者設(shè)備維度上的每一個(gè)獨(dú)立的設(shè)備。因此統(tǒng)計(jì)時(shí)可以把維度相同的記錄聚合在一起,然后應(yīng)用聚合函數(shù)做累加、均值、最大值、最小值等聚合計(jì)算。

度量就是被聚合的統(tǒng)計(jì)值,也就是聚合運(yùn)算的結(jié)果,它一般是連續(xù)的值,如以上兩個(gè)圖中的溫度值,或是其他測量點(diǎn),比如濕度等等。通過對(duì)度量的比較和分析,我們就可以對(duì)數(shù)據(jù)做出評(píng)估,比如這個(gè)月設(shè)備運(yùn)行是否穩(wěn)定,某個(gè)設(shè)備的平均溫度是否明顯高于其他同類設(shè)備等等。

Cube和Cuboid

了解了維度和度量之后,我們可以將數(shù)據(jù)模型上的所有字段進(jìn)行分類:它們要么是維度,要么是度量。根據(jù)定義好的維度和度量,我們就可以構(gòu)建Cube了。

對(duì)于一個(gè)給定的數(shù)據(jù)模型,我們可以對(duì)其上的所有維度進(jìn)行組合。對(duì)于N個(gè)維度來說,組合所有可能性共有2的N次方種。對(duì)于每一種維度的組合,將度量做聚合計(jì)算,然后將運(yùn)算的結(jié)果保存為一個(gè)物化視圖,稱為Cuboid。所有維度組合的Cuboid作為一個(gè)整體,被稱為Cube。

舉個(gè)例子。假設(shè)有一個(gè)電商的銷售數(shù)據(jù)集,其中維度包括時(shí)間(Time)、商品(Item)、地點(diǎn)(Location)和供應(yīng)商(Supplier),度量為銷售額(GMV)。那么所有維度的組合就有2的4次方,即16種,比如一維度(1D)的組合有[Time]、[Item]、[Location]、[Supplier]4種;二維度(2D)的組合有[Time Item]、[Time Location]、[Time Supplier]、[Item Location]、[Item Supplier]、[Location Supplier]6種;三維度(3D)的組合也有4種;最后零維度(0D)和四維度(4D)的組合各有1種,總共16種。

計(jì)算Cubiod,即按維度來聚合銷售額。如果用SQL語句來表達(dá)計(jì)算Cuboid [Time, Location],那么SQL語句如下:

select Time, Location, Sum(GMV) as GMV from Sales group by Time, Location

將計(jì)算的結(jié)果保存為物化視圖,所有Cuboid物化視圖的總稱就是Cube。

事實(shí)表和維度表

事實(shí)表(Fact Table)是指存儲(chǔ)有事實(shí)記錄的表,如系統(tǒng)日志、銷售記錄、傳感器數(shù)值等;事實(shí)表的記錄是動(dòng)態(tài)增長的,所以它的體積通常遠(yuǎn)大于維度表。

維度表(Dimension Table)或維表,也成為查找表(Lookup Table),是與事實(shí)表相對(duì)應(yīng)的一種表;它保存了維度的屬性值,可以跟事實(shí)表做關(guān)聯(lián);相當(dāng)于將事實(shí)表上經(jīng)常重復(fù)的屬性抽取、規(guī)范出來用一張表進(jìn)行管理。常見的維度表有:日期表(存儲(chǔ)與日期對(duì)應(yīng)的周、月、季度等屬性)、地區(qū)表(包含國家、省/州、城市等屬性)等。維度表的變化通常不會(huì)太大。使用維度表有許多好處:

  • 縮小了事實(shí)表的大小。
  • 便于維度的管理和維護(hù),增加、刪除和修改維度的屬性,不必對(duì)事實(shí)表的大量記錄進(jìn)行改動(dòng)。
  • 維度表可以為多個(gè)事實(shí)表重用。

星形模型

星形模型(Star Schema)是數(shù)據(jù)挖掘中常用的幾種多維數(shù)據(jù)模型之一。它的特點(diǎn)是只有一張事實(shí)表,以及零到多個(gè)維度表,事實(shí)表與維度表通過主外鍵相關(guān)聯(lián),維度表之間沒有關(guān)聯(lián),就像許多小星星圍繞在一顆恒星周圍,所以名為星形模型。

另一種常用的模型是雪花模型(SnowFlake Schema),就是將星形模型中的某些維表抽取成更細(xì)粒度的維表,然后讓維表之間也進(jìn)行關(guān)聯(lián),這種形狀酷似雪花的的模型稱為雪花模型。

還有一種更為復(fù)雜的模型,具有多個(gè)事實(shí)表,維表可以在不同事實(shí)表之間公用,這種模型被稱為星座模型。

不過,Kylin目前只支持星形模型。

二、Apache Kylin的技術(shù)架構(gòu)

Apache Kylin系統(tǒng)主要可以分為在線查詢和離線構(gòu)建兩部分,具體架構(gòu)圖如下:

Kylin架構(gòu)圖,圖片來源于官網(wǎng)首頁

首先來看離線構(gòu)建部分。從圖中可以看出,左側(cè)為數(shù)據(jù)源,目前Kylin默認(rèn)的數(shù)據(jù)源是Apache Hive,保存著待分析的用戶數(shù)據(jù)。根據(jù)元數(shù)據(jù)的定義,構(gòu)建引擎從數(shù)據(jù)源抽取數(shù)據(jù),并構(gòu)建Cube。數(shù)據(jù)以關(guān)系表的形式輸入,并且必須符合星形模型。構(gòu)建技術(shù)主要為MapReduce(Spark目前在beta版本)。構(gòu)建后的Cube保存在右側(cè)存儲(chǔ)引擎中,目前Kylin默認(rèn)的存儲(chǔ)為Apache HBase。

完成離線構(gòu)建后,用戶可以從上方的查詢系統(tǒng)發(fā)送SQL進(jìn)行查詢分析。Kylin提供了RESTful API、JDBC/ODBC接口供用戶調(diào)用。無論從哪個(gè)接口進(jìn)入,SQL最終都會(huì)來到REST服務(wù)層,再轉(zhuǎn)交給查詢引擎進(jìn)行處理。查詢引擎解析SQL,生成基于關(guān)系表的邏輯執(zhí)行計(jì)劃,然后將其轉(zhuǎn)譯為基于Cube的物理執(zhí)行計(jì)劃,最后查詢預(yù)計(jì)算生成的Cube并產(chǎn)生結(jié)果。整個(gè)過程不會(huì)訪問原始數(shù)據(jù)源。如果用戶提交的查詢語句未在Kylin中預(yù)先定義,Kylin會(huì)返回一個(gè)錯(cuò)誤。

值得一提的是,Kylin對(duì)數(shù)據(jù)源、執(zhí)行引擎和Cube存儲(chǔ)三個(gè)核心模塊提取出了抽象層,這意味著這三個(gè)模塊可以被任意地?cái)U(kuò)展和替換。比如可以使用Spark替代MapReduce作為Cube的構(gòu)建引擎,使用Cassandra替代HBase作為Cube計(jì)算后數(shù)據(jù)的存儲(chǔ)等。良好的擴(kuò)展性使得Kylin可以在這個(gè)技術(shù)發(fā)展日新月異的時(shí)代方便地使用更先進(jìn)的技術(shù)替代現(xiàn)有技術(shù),做到與時(shí)俱進(jìn),也使用戶可以針對(duì)自己的業(yè)務(wù)特點(diǎn)對(duì)Kylin進(jìn)行深度定制。

Apache Kylin的這種架構(gòu)使得它擁有許多非常棒的特性:

  • SQL接口:
    Kylin主要的對(duì)外接口就是以SQL的形式提供的。SQL簡單易用的特性極大地降低了Kylin的學(xué)習(xí)成本,不論是數(shù)據(jù)分析師還是Web開發(fā)程序員都能從中收益。
  • 支持海量數(shù)據(jù)集
    不論是Hive、SparkSQL,還是Impala、Presto,都改變不了這樣一個(gè)事實(shí):查詢時(shí)間隨著數(shù)據(jù)量的增長而線性增長。而Apache Kylin使用預(yù)計(jì)算技術(shù)打破了這一點(diǎn)。Kylin在數(shù)據(jù)集規(guī)模上的局限性主要取決于維度的個(gè)數(shù)和基數(shù),而不是數(shù)據(jù)集的大小,所以Kylin能更好地支持海量數(shù)據(jù)集的查詢。
  • 亞秒級(jí)響應(yīng)
    同樣受益于預(yù)計(jì)算技術(shù),Kylin的查詢速度非常快,因?yàn)閺?fù)雜的連接、聚合等操作都在Cube的構(gòu)建過程中已經(jīng)完成了。
  • 水平擴(kuò)展
    Apache Kylin同樣可以使用集群部署方式進(jìn)行水平擴(kuò)展。但部署多個(gè)節(jié)點(diǎn)只能提高Kylin處理查詢的能力,而不能提升它的預(yù)計(jì)算能力。
  • 可視化集成
    Apache Kylin提供了ODBC/JDBC接口和RESTful API,可以很方便地與Tableau等數(shù)據(jù)可視化工具集成。數(shù)據(jù)團(tuán)隊(duì)也可以在開放的API上進(jìn)行二次開發(fā)。

三、Apache Kylin的安裝與使用

關(guān)于Apache Kylin的安裝,官網(wǎng)上有詳細(xì)的教程:

在此就不再贅述了。但有兩處問題官網(wǎng)不曾提及:

  1. Apache Kylin依賴于Hadoop,但使用Standalone模式部署Hadoop可能會(huì)造成構(gòu)建Cube出現(xiàn)問題,推薦大家使用虛擬機(jī)集群搭建Hadoop和Kylin。
  2. Hadoop除了需要開啟HDFS和YARN,還需要開啟jobhistoryserver,啟動(dòng)命令為:sbin/mr-jobhistory-daemon.sh start historyserver

部署成功后,可以使用Kylin官方自帶的quick start教程來驗(yàn)證一下Kylin是否安裝正確。

接下來我們來談?wù)凜ube構(gòu)建。Apache Kylin的Cube構(gòu)建分為三種,分別為全量構(gòu)建、增量構(gòu)建、流式構(gòu)建。最簡單的是全量構(gòu)建,就是每次構(gòu)建都對(duì)Hive表進(jìn)行全表構(gòu)建。但是全量構(gòu)建在實(shí)際環(huán)境中并不常用,因?yàn)榇蠖鄶?shù)業(yè)務(wù)場景下,事實(shí)數(shù)據(jù)都在不斷地增長中,所以最常使用的構(gòu)建方式其實(shí)是增量構(gòu)建。

增量構(gòu)建可以使Cube每次只構(gòu)建Hive表中新增部分的數(shù)據(jù),而不是全部數(shù)據(jù),因此大大降低了構(gòu)建的成本。為了實(shí)現(xiàn)增量構(gòu)建,Apache Kylin將Cube分為多個(gè)Segment,每個(gè)Segment用起始時(shí)間和結(jié)束時(shí)間來標(biāo)識(shí)。關(guān)于Cube的構(gòu)建,可以參考官網(wǎng)文檔:

  1. 創(chuàng)建Model時(shí)在第五步(Settings)需要指定 Partition Date Column,用日期字段來對(duì)Cube進(jìn)行分割。
  2. 創(chuàng)建Cube時(shí)在第四步(Refresh Setting)需要指定 Partition Start Date,即Cube默認(rèn)的第一個(gè)Segment的起始時(shí)間。

增量構(gòu)建的方式解決了業(yè)務(wù)數(shù)據(jù)動(dòng)態(tài)增長的問題。但卻仍然不能滿足分鐘級(jí)的近實(shí)時(shí)返回結(jié)果的需求,因?yàn)樵隽繕?gòu)建與全量構(gòu)建一樣,使用Hive作為數(shù)據(jù)源,而Hive中的數(shù)據(jù)一般是經(jīng)過ETL定時(shí)導(dǎo)入的(比如每天一次)。數(shù)據(jù)的時(shí)效性對(duì)于數(shù)據(jù)價(jià)值的重要性不言而喻,為了滿足實(shí)時(shí)數(shù)據(jù)更新這一普遍需求,Apache Kylin給出了流式構(gòu)建方案。

不同于前兩種使用Hive做為數(shù)據(jù)源的構(gòu)建方式,流式構(gòu)建使用Kafka做為數(shù)據(jù)源,構(gòu)建引擎定時(shí)從Kafka中拉取數(shù)據(jù)進(jìn)行構(gòu)建,這一設(shè)計(jì)與Spark-Streaming的微批次(Micro-Batch)思想非常像。官網(wǎng)上同樣給出了如何使用流式構(gòu)建的文檔:Build Cube with Streaming Data,需要注意的一點(diǎn)是,Apache Kylin現(xiàn)在的流式構(gòu)建方式是v1.6后才存在的,之前的版本可能會(huì)出現(xiàn)構(gòu)建方式不同或不存在流式構(gòu)建方式等情況。

Apache Kylin除了可以在Web UI界面進(jìn)行構(gòu)建和查詢,還為Cube的構(gòu)建提供了RESTful API,為數(shù)據(jù)的查詢提供了RESTful API和JDBC/ODBC接口,用戶可以根據(jù)自身情況選擇合適的構(gòu)建和查詢方式。另外,Kylin還支持使用第三方數(shù)據(jù)分析工具來對(duì)Kylin中計(jì)算好的數(shù)據(jù)進(jìn)行分析,如Apache Zeppelin、Tableau等。

四、企業(yè)應(yīng)用案例

Apache Kylin雖然還很年輕,但已經(jīng)在多個(gè)企業(yè)的生產(chǎn)項(xiàng)目中得到了應(yīng)用。下面我們來看一看Kylin在國內(nèi)兩個(gè)著名企業(yè)內(nèi)的應(yīng)用。

百度地圖

百度地圖數(shù)據(jù)智能組是國內(nèi)最早的一批在生產(chǎn)環(huán)境中使用Apache Kylin的技術(shù)團(tuán)隊(duì)。在2014年末,百度地圖團(tuán)隊(duì)正要搭建一套完整的OLAP數(shù)據(jù)分析平臺(tái),用來提供百億行級(jí)數(shù)據(jù)單條SQL毫秒到秒級(jí)的多維分析查詢服務(wù)。在技術(shù)選型的過程中,百度地圖團(tuán)隊(duì)參考了Apache Drill、Presto、Impala、Spark SQL、Apache Kylin等技術(shù)。當(dāng)時(shí)Apache Drill和Presto因生產(chǎn)環(huán)境案例較少,而Impala和Spark SQL則主要基于內(nèi)存計(jì)算,對(duì)機(jī)器資源要求較高,交互頁面通常含有多條SQL查詢請(qǐng)求,在超大規(guī)模的數(shù)據(jù)集下,動(dòng)態(tài)計(jì)算亦難以滿足要求。
最終,百度地圖團(tuán)隊(duì)關(guān)注到了基于MapReduce預(yù)計(jì)算生成Cube并提供低延遲查詢的Apache Kylin解決方案,他們?cè)贏pache Kylin集群上跑了多個(gè)Cube測試,結(jié)果表明它能夠有效解決大數(shù)據(jù)計(jì)算分析的3大痛點(diǎn):
痛點(diǎn)一:百億級(jí)海量數(shù)據(jù)多維指標(biāo)動(dòng)態(tài)計(jì)算耗時(shí)問題,Apache Kylin通過預(yù)計(jì)算生成Cube結(jié)果數(shù)據(jù)集并存儲(chǔ)到HBase的方式解決。
痛點(diǎn)二:復(fù)雜條件篩選問題,用戶查詢時(shí),Apache Kylin利用router查找算法及優(yōu)化的HBase Coprocessor解決;
痛點(diǎn)三:跨月、季度、年等大時(shí)間區(qū)間查詢問題,對(duì)于預(yù)計(jì)算結(jié)果的存儲(chǔ),Apache Kylin利用Cube的Data Segment分區(qū)存儲(chǔ)管理解決。

這3個(gè)痛點(diǎn)的解決,使百度地圖在百億級(jí)大數(shù)據(jù)規(guī)模下,且數(shù)據(jù)模型確定的具體多維分析產(chǎn)品中,達(dá)到單條SQL毫秒級(jí)響應(yīng)。

京東云海

京東云海是由京東和ISV(與京東云合作的第三方服務(wù)廠商)共同合作的模式對(duì)商家提供服務(wù)。云海提供基礎(chǔ)的京東POP(商家開放平臺(tái))數(shù)據(jù),包括商品、商家、客服績效、品牌、行業(yè)等主題數(shù)據(jù)。ISV通過商家授權(quán)可以獲取商家基礎(chǔ)數(shù)據(jù),ISV通過JOS的API接口上傳相關(guān)維表數(shù)據(jù),數(shù)據(jù)上傳到數(shù)據(jù)倉庫后,ISV可以在云海開放平臺(tái)上開發(fā)相關(guān)的Hive SQL對(duì)上傳數(shù)據(jù)和商家基礎(chǔ)數(shù)據(jù)進(jìn)行關(guān)聯(lián)計(jì)算,計(jì)算結(jié)果可以通過數(shù)據(jù)開放API查詢,ISV獲取到數(shù)據(jù)后通過應(yīng)用展現(xiàn)給商家使用。
JOS開放接近500個(gè)API,每天調(diào)用量在7億次左右。針對(duì)API的調(diào)用情況進(jìn)行多維分析,分析查詢延遲要求達(dá)到秒級(jí),并使用BI工具進(jìn)行分析展現(xiàn)。JOS的API訪問日志數(shù)據(jù)通過定時(shí)抓取存儲(chǔ)在Hive數(shù)據(jù)倉庫中。所以需要一種能夠在大數(shù)據(jù)量情況下進(jìn)行交互式多維分析的SQL on Hadoop引擎,并且要支持和BI工具的集成,提供標(biāo)準(zhǔn)的JDBC、ODBC接口。
雖然開源社區(qū)各種優(yōu)秀的SQL on Hadoop引擎不斷涌現(xiàn),比如Impala,SparkSQL等。但是針對(duì)于以上場景的考慮:大數(shù)據(jù)量情況下秒級(jí)多維分析、支持與傳統(tǒng)BI工具無縫集成、在大數(shù)據(jù)量基礎(chǔ)上使用標(biāo)準(zhǔn)SQL查詢小數(shù)據(jù)量結(jié)果集能夠達(dá)到毫秒級(jí)、完全基于Hadoop生態(tài)系統(tǒng)、支持水平擴(kuò)展等。最終京東云海選擇了了Apache Kylin。

五、進(jìn)一步學(xué)習(xí)

  • 官方文檔:
    學(xué)習(xí)一個(gè)開源軟件最好的途徑永遠(yuǎn)是官方文檔。官網(wǎng)地址:http://kylin.apache.org/
  • 《Apache Kylin權(quán)威指南》
圖片來源于豆瓣

這本《Apache Kylin權(quán)威指南》由Apache Kylin的核心開發(fā)團(tuán)隊(duì)所作,基本涵蓋了Apache Kylin的方方面面,結(jié)合官網(wǎng)閱讀效果拔群。美中不足的就是這本書是基于v1.5,而在v1.6中,流式構(gòu)建進(jìn)行了徹底的重寫。但瑕不掩瑜,這本書依然是除了官網(wǎng)之外最好的入門書,本文在成文的過程中也大量地參考了這本書中的內(nèi)容。

六、總結(jié)

Apache Kylin的出現(xiàn),填補(bǔ)了OLAP on Hadoop解決方案的空白,相比于市面上其他預(yù)計(jì)算系統(tǒng),Apache Kylin具有更強(qiáng)的易用性(使用過Druid的人會(huì)對(duì)這一點(diǎn)深有體會(huì))。Apache Kylin已經(jīng)在eBay、百度、京東、美團(tuán)等著名互聯(lián)網(wǎng)公司得到應(yīng)用,在實(shí)際生產(chǎn)環(huán)境中證明了自己。對(duì)預(yù)計(jì)算系統(tǒng)有需求的同學(xué)們可以踴躍嘗試Apache Kylin。

七、參考

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,517評(píng)論 6 539
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,087評(píng)論 3 423
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,521評(píng)論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,493評(píng)論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 72,207評(píng)論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,603評(píng)論 1 325
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,624評(píng)論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,813評(píng)論 0 289
  • 序言:老撾萬榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,364評(píng)論 1 335
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 41,110評(píng)論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 43,305評(píng)論 1 371
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,874評(píng)論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,532評(píng)論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,953評(píng)論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,209評(píng)論 1 291
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 52,033評(píng)論 3 396
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 48,268評(píng)論 2 375

推薦閱讀更多精彩內(nèi)容