Kylin——大數(shù)據(jù)下的固化查詢方案

前言

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

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

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

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

一、核心概念

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

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

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

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

在傳統(tǒng) BI 領(lǐng)域中，數(shù)據(jù)倉庫的數(shù)據(jù)同樣存儲在 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ù)倉庫。

與之對應(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)域中兩個常用的概念。

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

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

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

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

Cube 和 Cuboid

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

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

舉個例子。假設(shè)有一個電商的銷售數(shù)據(jù)集，其中維度包括時間（Time）、商品（Item）、地點（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 種。

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

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

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

Cube 中只包含聚合數(shù)據(jù)，所以用戶的所有查詢都應(yīng)該是聚合查詢 (包含 “group by”)，不能出現(xiàn) select * 這種

事實表和維度表

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

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

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

星形模型

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

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

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

不過，Kylin 目前只支持星形模型和雪花模型。

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

Apache Kylin 系統(tǒ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è)存儲引擎中，目前 Kylin 默認(rèn)的存儲為 Apache HBase。

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

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

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

• SQL 接口：

  Kylin 主要的對外接口就是以 SQL 的形式提供的。SQL 簡單易用的特性極大地降低了 Kylin 的學(xué)習(xí)成本，不論是數(shù)據(jù)分析師還是 Web開發(fā)程序員都能從中收益。

• 支持海量數(shù)據(jù)集

  不論是 Hive、SparkSQL，還是 Impala、Presto，都改變不了這樣一個事實：查詢時間隨著數(shù)據(jù)量的增長而線性增長。

  而 Apache Kylin 使用預(yù)計算技術(shù)打破了這一點。Kylin 在數(shù)據(jù)集規(guī)模上的局限性主要取決于維度的個數(shù)和基數(shù)，而不是數(shù)據(jù)集的大小，所以 Kylin 能更好地支持海量數(shù)據(jù)集的查詢。

• 亞秒級響應(yīng)

  同樣受益于預(yù)計算技術(shù)，Kylin 的查詢速度非?？?，因為復(fù)雜的連接、聚合等操作都在 Cube 的構(gòu)建過程中已經(jīng)完成了。

• 水平擴(kuò)展

  Apache Kylin 同樣可以使用集群部署方式進(jìn)行水平擴(kuò)展。但部署多個節(jié)點只能提高 Kylin 處理查詢的能力，而不能提升它的預(yù)計算能力。

• 可視化集成

  Apache Kylin 提供了 ODBC/JDBC 接口和 RESTful API，可以很方便地與 Tableau 等數(shù)據(jù)可視化工具集成。數(shù)據(jù)團(tuán)隊也可以在開放的API 上進(jìn)行二次開發(fā)。

參考與感謝：

• 原文：《一文讀懂Apache Kylin》:

• 《Apache Kylin 在百度地圖的實踐》

• 美團(tuán)技術(shù)團(tuán)隊：Apache Kylin的實踐與優(yōu)化