大資料技術叢書 點選檢視第二章 點選檢視第三章 Apache Kylin權威指南（第2版）
第1章
Apache Kylin概述
Apache Kylin是Hadoop大資料平台上的一個開源的聯機分析處理（Online Analytical Processing， OLAP）引擎。它采用多元立方體預計算技術，将大資料的SQL查詢速度從之前的分鐘乃至小時級别提升到亞秒級别，這種百倍、千倍的速度提升，為超大規模資料集上的互動式大資料分析奠定了基礎。
Apache Kylin也是第一個由中國人主導的Apache頂級開源項目，在國際開源社群具有極大的影響力。
本章将對Apache Kylin的曆史和背景做一個完整的介紹，并從技術角度對Kylin做一個概括性的介紹。
1.1 背景和曆史
現今，大資料行業發展得如火如荼，新技術層出不窮，整個生态欣欣向榮。作為大資料領域最重要的技術的Apache Hadoop最初緻力于簡單的分布式存儲，然後在此基礎之上實作大規模并行計算，到如今在實時分析、多元分析、互動式分析、機器學習甚至人工智能等方面有了長足的發展。
2013年年初，在eBay内部使用的傳統資料倉庫及商業智能平台碰到了“瓶頸”，傳統架構隻支援垂直擴充，通過在一台計算機上增加CPU和記憶體等資源來提升計算機的資料處理能力。相對于資料指數級的增長，單機擴充很快達到極限，不可避免地遇到了“瓶頸”。此外，Hadoop大資料平台雖然能存儲和批量處理大規模資料，但與BI平台的連接配接技術還不夠成熟，無法提供高效的互動式查詢。于是，尋找到更好的互動式大資料分析方案成為當務之急。
2013年年中，eBay 公司啟動了一個大資料項目，其中有一部分内容就是BI on Hadoop的預研。當時，eBay中國卓越中心組建了一支很小的團隊，他們在分析和測試了多種開源和商業解決方案後，發現沒有一種方案能夠完全滿足當時的需求，即在超大規模資料集上提供秒級的查詢性能，并基于Hadoop與BI平台無縫整合等。在研究了多種可能性後，eBay最終決定自己來實作一套OLAP-on-Hadoop的解決方案，以彌補業界的此類空白。與此同時，eBay也非常鼓勵各個項目開源、回饋社群，在給負責整個技術平台的進階副總裁做彙報的時候，得到的一個回報就是“從第一天起就做好開源的準備”。
經過一年多的研發，2014年9月底，代号Kylin的大資料平台在eBay内部正式上線。Kylin在Hadoop上提供标準和友好的SQL接口，并且查詢速度非常快，原本要幾分鐘才能完成的查詢現在幾秒鐘就能傳回結果，BI分析的工作效率得到幾百倍的提升，獲得了公司内部客戶、合作夥伴及管理層的高度評價，一上線便吸引了多個種子客戶。2014年10月1日，Kylin項目負責人韓卿将Kylin的源代碼送出到github.com并正式開源。當天就得到了業界專家的關注和認可。圖1-1所示為Hortonworks的CTO對Apache Kylin的Twitter評價。
很快，Hadoop社群的許多朋友都鼓勵eBay将該項目貢獻到Apache 軟體基金會(ASF)，讓它與其他大資料項目一起獲得更好的發展，在經過一個月的緊張準備和撰寫了無數個版本的項目建議書後，Kylin項目于2014年11月正式加入Apache 孵化器項目，并由多位資深的社群活躍成員做項目導師。
在接下來的一年中，項目組再次做出了極大努力，包括按照Apache 孵化器要求組建項目管理委員會（PMC）、建立項目網站、整理知識産權并簽署必要協定、吸引外部開發者、發展多元化社群、釋出多個正式版本等。2015年11月，Apache軟體基金會宣布Apache Kylin正式成為頂級項目。
這是第一個完全由中國團隊貢獻到全球最大的開源軟體基金會的頂級項目。項目負責人韓卿成為Apache Kylin項目管理委員會主席，也成為Apache軟體基金會160多個頂級項目中的第一個中國人，Apache Kylin創造了曆史。正如Kylin的導師，時任Apache孵化器副總裁的Ted Dunning在ASF官方新聞稿中評價的那樣：“Apache Kylin代表了亞洲國家，特别是中國，在開源社群中越來越高的參與度。”
2016年3月，由Apache Kylin核心開發者組建的創業公司Kyligence正式成立。正如多數成功的開源項目背後都有一家創業公司一樣（Hadoop領域有Cloudera、Hortonworks等；Spark有Databricks；Kafka有Confluent等），Kylin也可以通過Kyligence公司的進一步投入保證高速研發，并且Kylin的社群和生态圈也會得到不斷的發展和壯大，可以預見這個開源項目将會越來越好。
在業界極具盛名的技術類獨立評選中，InfoWorld的Bossie Award每年都會獨立挑選和評論相關的技術、應用和産品等。2015年9月，Apache Kylin與Apache Spark、Apache Kafka、H2O、Apache Zeppelin等一同獲得了2015年度“最佳開源大資料工具獎”。這是業界對Apache Kylin的充分認可和褒獎。2016年的InfoWorld獲獎榜單進一步收窄，獲獎者數量較前一年減少一半，一些新興項目如Google上司的TensorFlow、Apache Beam嶄露頭角，值得驕傲的是，Apache Kylin 再次登上領獎台，蟬聯“最佳開源大資料工具獎”。
Apache Kylin 在社群開發者的共同努力下進一步發展和完善，先後釋出了1.6、2.0～ 2.5 多個版本，涵蓋近實時流、Spark 引擎、RDBMS資料源、Cube Planner，支援Hadoop 3.0等衆多新功能，還有一些新功能正在進行公開beta測試，如Parquet 存儲引擎、完全實時流資料等，預計在不遠的将來會正式釋出。同時，Apache Kylin 使用者群也在不斷發展壯大，跨越亞洲、美洲、歐洲、澳洲等地。據粗略計算，全球已經有超過一千家企業将Apache Kylin 用于自身的關鍵業務分析。
1.2 Apache Kylin的使命
Apache Kylin的使命是實作超高速的大資料OLAP分析，也就是要讓大資料分析像使用資料庫一樣簡單迅速，使用者的查詢請求可以在秒級傳回，互動式資料分析以前所未有的速度釋放大資料裡潛藏的知識和資訊，以使我們在面對未來的挑戰時占得先機。
1.2.1 為什麼要使用Apache Kylin
自2006年Hadoop誕生以來，大資料的存儲和批處理問題得到了妥善解決，而如何高速地分析資料也就成為下一個挑戰。于是各種“SQL-on-Hadoop”技術應運而生，其中以Hive為代表，Impala、Presto、Phoenix、Drill、Spark SQL等緊随其後，它們的主要技術是“大規模并行處理”（Massively Parallel Processing，MPP）和“列式存儲”（Columnar Storage）。
大規模并行處理可以調動多台機器進行并行計算，用線性增加資源來換取計算時間的線性下降。列式存儲則将記錄按列存放，不僅在通路時可以隻讀取需要的列，更可以利用儲存設備擅長連續讀取的特點，大大提高讀取的速率。這兩項關鍵技術使得Hadoop上的SQL查詢速度從小時級提高到了分鐘級。
然而分鐘級别的查詢響應仍然與互動式分析的現實需求相差很遠。分析師敲入查詢指令，按下Enter鍵後，需要去倒杯咖啡，靜靜地等待結果。得到結果後才能根據情況調整查詢，再做下一輪分析。如此反複，一個具體的場景分析常常需要幾個小時甚至幾天才能完成，資料分析效率低下。
這是因為大規模并行處理和列式存儲雖然提高了計算和存儲的速度，但并沒有改變查詢問題本身的時間複雜度，也沒有改變查詢時間與資料量呈線性增長的關系這一事實。假設查詢1億條記錄耗時1分鐘，那麼查詢10億條記錄就需要10分鐘，查詢100億條就至少需要1小時40分鐘。
當然，有很多的優化技術可以縮短查詢的時間，比如更快的存儲、更高效的壓縮算法等，但總體來說，查詢性能與資料量呈線性相關這一事實無法改變。雖然大規模并行處理允許十倍或者百倍地擴張計算叢集，以期保持分鐘級别的查詢速度，但購買和部署十倍、百倍的計算叢集又很難做到，更何況還需要高昂的硬體運維成本。
另外，對于分析師來說，完備的、經過驗證的資料模型比分析性能更加重要，直接通路紛繁複雜的原始資料并進行相關分析其實并不是很美好的體驗，特别是在超大規模資料集上，分析師們把更多的精力花費在了等待查詢結果上，而不是用在更加重要的建立領域模型上。
1.2.2 Apache Kylin怎樣解決關鍵問題
Apache Kylin的初衷就是解決千億、萬億條記錄的秒級查詢問題，其中的關鍵就是打破查詢時間随着資料量呈線性增長的這一規律。仔細思考大資料OLAP，我們可以注意到兩個事實。
- 大資料查詢要的一般是統計結果，是多條記錄經過聚合函數計算後的統計值。原始的記錄則不是必需的，或者被通路的頻率和機率極低。
- 聚合是按次元進行的，而次元的聚合可能性是有限的，一般不随資料的膨脹而線性增長。
基于以上兩點，我們得到一個新的思路—“預計算”。應盡量多地預先計算聚合結果，在查詢時刻也盡量使用預計算的結果得出查詢結果，進而避免直接掃描可能無限增長的原始記錄。
舉例來說，要用下面的SQL來查詢10月1日那天銷量最高的商品。
傳統的方法需要掃描所有的記錄，找到10月1日的銷售記錄，然後按商品聚合銷售額，最後排序傳回。假如10月1日有1億條交易，那麼查詢必需讀取并累計至少1億條記錄，且查詢速度會随将來銷量的增加而逐漸下降，如果日交易量提高至2億條，那查詢執行的時間可能會增加一倍。
而預計算的方法則會事先按次元[sell_date, item]計算SUM(sell_amount)并将其存儲下來，在查詢時找到10月1日的銷售商品就可以直接排序傳回了。讀取的記錄數最大不超過次元[sell_date, item]的組合數。顯然這個數字将遠遠小于實際的銷售記錄，比如10月1日的1億條交易包含了100萬種商品，那麼預計算後就隻有100萬條記錄了，是原來的百分之一。并且這些記錄是已經按商品聚合的結果，省去了運作時的聚合運算。從未來的發展來看，查詢速度隻會随日期和商品數目的增長而變化，與銷售記錄總數不再有直接聯系。假如日交易量提高一倍到2億，但隻要商品總數不變，那麼預計算的結果記錄總數就不會變，查詢的速度也不會變。
“預計算”就是Kylin在“大規模并行處理”和“列式存儲”之外，提供給大資料分析的第三個關鍵技術。
1.3 Apache Kylin的工作原理
Apache Kylin的工作原理本質上是MOLAP（Multidimensional Online Analytical Processing） Cube，也就是多元立方體分析。這是資料分析中相當經典的理論，在關系型資料庫年代就有廣泛應用，下面對其做簡要介紹。
1.3.1 次元和度量簡介
在說明MOLAP Cube之前，需要先介紹一下次元（dimension）和度量（measure）這兩個概念。
簡單來講，次元就是觀察資料的角度。比如電商的銷售資料，可以從時間的次元來觀察（如圖1-2的左圖所示），也可以進一步細化從時間和地區的次元來觀察（如圖1-2的右圖所示）。次元一般是一組離散的值，比如時間次元上的每一個獨立的日期，或者商品次元上的每一件獨立的商品。是以，統計時可以把次元值相同的記錄聚合起來，應用聚合函數做累加、平均、去重複計數等聚合計算。
度量就是被聚合的統計值，也是聚合運算的結果，它一般是連續值，如圖1-2中的銷售額，抑或是銷售商品的總件數。通過比較和測算度量，分析師可以對資料進行評估，比如今年的銷售額相比去年有多大的增長、增長的速度是否達到預期、不同商品類别的增長比例是否合理等。
1.3.2 Cube和Cuboid
了解了次元和度量，就可以對資料表或者資料模型上的所有字段進行分類了，它們要麼是次元，要麼是度量（可以被聚合）。于是就有了根據次元、度量做預計算的Cube理論。
給定一個資料模型，我們可以對其上所有次元進行組合。對于N個次元來說，所有組合的可能性有2N種。對每一種次元的組合，将度量做聚合運算，運算的結果儲存為一個物化視圖，稱為Cuboid。将所有次元組合的Cuboid作為一個整體，被稱為Cube。是以簡單來說，一個Cube就是許多按次元聚合的物化視圖的集合。
舉一個具體的例子。假定有一個電商的銷售資料集，其中次元有時間(Time)、商品(Item)、地點(Location)和供應商(Supplier)，度量有銷售額(GMV)。那麼，所有次元的組合就有24=16種（如圖1-3所示），比如一次元（1D）的組合有TimeLocation四種；二次元（2D）的組合有Time, ItemTime、SupplierItem, Supplier六種；三次元（3D）的組合也有四種；最後，零次元（0D）和四次元（4D）的組合各有一種，共計16種組合。
計算Cuboid，就是按次元來聚合銷售額(GMV)。如果用SQL來表達計算Cuboid [Time, Location]，那就是：
select Time, Location, Sum(GMV) as GMV from Sales group by Time, Location
将計算的結果儲存為物化視圖，所有Cuboid物化視圖的總稱就是Cube了。
1.3.3 工作原理
Apache Kylin的工作原理就是對資料模型做Cube預計算，并利用計算的結果加速查詢。過程如下：
（1）指定資料模型，定義次元和度量。
（2）預計算Cube，計算所有Cuboid并将其儲存為物化視圖。
（3）執行查詢時，讀取Cuboid，進行加工運算産生查詢結果。
由于Kylin的查詢過程不會掃描原始記錄，而是通過預計算預先完成表的關聯、聚合等複雜運算，并利用預計算的結果來執行查詢，是以其速度相比非預計算的查詢技術一般要快一個到兩個數量級。并且在超大資料集上其優勢更明顯。當資料集達到千億乃至萬億級别時，Kylin的速度甚至可以超越其他非預計算技術1000倍以上。
1.4 Apache Kylin的技術架構
Apache Kylin系統可以分為線上查詢和離線建構兩部分，其技術架構如圖1-4所示。線上查詢主要由上半區組成，離線建構在下半區。
先看離線建構的部分。從圖1-4中可以看到，資料源在左側，目前主要是Hadoop、Hive、Kafka和 RDBMS，其中儲存着待分析的使用者資料。根據中繼資料定義，下方建構引擎從資料源中抽取資料，并建構Cube。資料以關系表的形式輸入，且必須符合星形模型（Star Schema）或雪花模型（Snowflake Schema）。使用者可以選擇使用MapReduce或Spark進行建構。建構後的Cube儲存在右側的存儲引擎中，目前HBase是預設的存儲引擎。
完成離線建構後，使用者可以從上方查詢系統發送SQL來進行查詢分析。Kylin提供了多樣的REST API、JDBC/ODBC接口。無論從哪個接口進入，最終SQL都會來到REST服務層，再轉交給查詢引擎進行處理。這裡需要注意的是，SQL語句是基于資料源的關系模型書寫的，而不是Cube。Kylin在設計時刻意對查詢使用者屏蔽了Cube的概念，分析師隻需要了解簡單的關系模型就可以使用Kylin，沒有額外的學習門檻，傳統的SQL應用也更容易遷移。查詢引擎解析SQL，生成基于關系表的邏輯執行計劃，然後将其轉譯為基于Cube的實體執行計劃，最後查詢預計算生成的Cube産生結果。整個過程不通路原始資料源。
對于查詢引擎下方的路由選擇，在最初設計時考慮過将Kylin不能執行的查詢引導到Hive中繼續執行。但在實踐後發現Hive與Kylin的執行速度差異過大，導緻使用者無法對查詢的速度有一緻的期望，大多語句很可能查詢幾秒就傳回了，而有些要等幾分鐘到幾十分鐘，使用者體驗非常糟糕。最後這個路由功能在發行版中預設被關閉。
Apache Kylin v1.5版本引入了“可擴充架構”的概念。圖1-4所示為Rest Server、Cube Build Engine和資料源表示的抽象層。可擴充是指Kylin可以對其三個主要依賴子產品—資料源、建構引擎和存儲引擎，做任意的擴充和替換。在設計之初，作為Hadoop家族的一員，這三者分别是Hive、MapReduce和HBase。但随着Apache Kylin的推廣和使用的深入，使用者發現它們存在不足之處。
比如，實時分析可能會希望從Kafka導入資料而不是從Hive；而Spark的迅速崛起，又使我們不得不考慮将MapReduce替換為Spark以提高Cube的建構速度；至于HBase，它的讀性能可能不如Cassandra等。可見，是否可以将某種技術替換為另一種技術已成為一個常見的問題。于是，我們對Apache Kylin v1.5版本的系統架構進行了重構，将資料源、建構引擎、存儲引擎三大主要依賴子產品抽象為接口，而Hive、MapReduce、HBase隻是預設實作。其他實作還有：資料源還可以是Kafka、Hadoop或RDBMS；建構引擎還可以是Spark、Flink。資深使用者可以根據自己的需要做二次開發，将其中的一個或者多個技術替換為更适合自身需要的技術。
這也為Kylin技術的與時俱進奠定了基礎。如果将來有更先進的分布式計算技術可以取代MapReduce，或者有更高效的存儲系統全面超越了HBase，Kylin可以用較小的代價将一個子系統替換掉，進而保證Kylin緊跟技術發展的最新潮流，保持最高的技術水準。
可擴充架構也帶來了額外的靈活性，比如，它可以允許多個引擎并存。例如，Kylin可以同時對接Hive、Kafka和其他第三方資料源；抑或使用者可以為不同的Cube指定不同的建構引擎或存儲引擎，以期達到極緻的性能和功能定制。
1.5 Apache Kylin的主要特點
Apache Kylin的主要特點包括支援SQL接口、支援超大資料集、秒級響應、可伸縮性、高吞吐率、BI及可視化工具內建等。
1.5.1 标準SQL接口
盡管Apache Kylin内部以Cube技術為核心，對外卻沒有選用MDX（MultiDimensional eXpression）作為接口，而是以标準SQL接口作為對外服務的主要接口。MDX作為OLAP查詢語言，從學術上來說是更加适合Kylin的選擇，但實踐表明，SQL是絕大多數分析人員最熟悉的工具，也是大多數應用程式使用的程式設計接口，它不僅簡單易用，也代表了絕大多數使用者的第一需求。
SQL需要以關系模型作為支撐，Kylin使用的查詢模型是資料源中的關系模型表，一般而言也就是指Hive表。終端使用者隻需要像原來查詢Hive表一樣編寫SQL查詢語句，就可以無縫地切換到Kylin，幾乎不需要進行額外的學習，甚至原本的Hive查詢也因為與SQL同源，大多無須修改就能直接在Kylin上運作。标準SQL接口是Kylin能夠快速推廣的一個關鍵原因。
當然，Apache Kylin将來也可能推出MDX接口。事實上已經可以通過MDX轉SQL的工具，讓Kylin也能支援MDX。
1.5.2 支援超大資料集
Apache Kylin對大資料的支撐能力可能是目前所有技術中最為先進的。2015年在eBay的生産環境中，Kylin就能支援百億條記錄的秒級查詢，之後在移動應用場景下又有了千億條記錄秒級查詢的案例。這些都是實際場景的應用，而非實驗室中的理論資料。
因為使用了Cube預計算技術，在理論上，Kylin可以支撐的資料集大小沒有上限，僅受限于存儲系統和分布式計算系統的承載能力，并且查詢速度不會随資料集的增大而減慢。Kylin在資料集規模上的局限性主要在于次元的個數和基數。它們一般由資料模型決定，不随資料規模的增加而線性增長，也就意味着，Kylin對未來資料增長有着更強的适應能力。
截至2019年1月 ，除了eBay作為孵化公司有廣泛應用之外，國内外一線的網際網路公司幾乎都大規模地使用Apache Kylin，包括美團、百度、網易、京東、唯品會、小米、Strikingly、Expedia、Yahoo！JAPAN、Cisco等。此外，在傳統行業中也有非常多的實際應用，包括中國移動、中國聯通、中國銀聯、太平洋保險等。
1.5.3 亞秒級響應
Apache Kylin有優異的查詢響應速度，這得益于預計算，很多複雜的計算如連接配接、聚合，在離線的預計算過程中就已經完成，這大大降低了查詢時所需的計算量，提高了查詢響應速度。
根據可查詢到的公開資料顯示，Apache Kylin在某生産環境中90%的查詢可以在3秒内傳回結果。這不是說一部分SQL相當快，而是在數萬種不同的應用SQL的真實生産系統中，絕大部分的查詢非常迅速；在另一個真實案例中，對1000多億條資料建構了立方體，90%的查詢性能在1.18s以内，可見Kylin在超大規模資料集上表現優異。這與一些隻在實驗室中，隻在特定查詢情況下，采集的性能資料不可同日而語。
當然，并不是使用Apache Kylin就一定能獲得最好的性能。針對特定的資料及查詢模式，往往需要做進一步的性能調優、配置優化等，性能調優對于充分利用Apache Kylin至關重要。
1.5.4 可伸縮性和高吞吐率
在保持高速響應的同時，Kylin有着良好的可伸縮性和很高的吞吐率。圖1-5是網易的性能分享。左圖是Apache Kylin與Mondrian/Oracle的查詢速度的對比，可以看到在三個測試查詢中，Kylin的查詢速度分别比Mondrian/Oracle快147倍、314倍和59倍。
同時右圖展現了Apache Kylin的高吞吐率和可伸縮性。在一個Apache Kylin執行個體中，Apache Kylin每秒可以處理近70個查詢，已經遠遠高于每秒20個查詢的一般水準。更理想的是，随着伺服器的增加，其吞吐率也呈線性增加，在存在4個執行個體時達到每秒230個查詢左右，而這4個執行個體僅部署在一台機器上，理論上添加更多的應用伺服器後可以支援更高的并發率。
這主要還是歸功于預計算降低了查詢時所需的計算總量，使Apache Kylin可以在相同的硬體配置下承載更多的并發查詢。
1.5.5 BI及可視化工具內建
Apache Kylin提供了豐富的API與現有的BI工具內建，包括：
- ODBC接口：與Tableau、Excel、Power BI等工具內建。
- JDBC接口：與Saiku、BIRT等Java工具內建。
- Rest API：與JavaScript、Web網頁內建。
分析師可以繼續使用他們最熟悉的BI工具與Apache Kylin一同工作，或者在開放的API上做二次開發和深度定制。
另外，Apache Kylin的核心團隊也貢獻了Apache Zeppelin及Apache Superset的插件，Strikingly的工程師為Redash 貢獻了Apache Kylin連接配接器，使用者可以使用Zeppelin、Superset、Redash等免費可視化工具來通路Redash Kylin。
1.6 與其他開源産品的比較
與Apache Kylin一樣緻力于解決大資料查詢問題的其他開源産品也有不少，比如Apache Drill、Apache Impala、Druid、Hive、Presto、SparkSQL等。本節将Apache Kylin與它們做一個簡單的比較。
從底層技術的角度來看，這些開源産品有很大的共性，一些底層技術幾乎被所有的産品一緻采用，Apache Kylin也不例外。
- 大規模并行處理 (MPP)：可以通過增加機器的方式來擴容處理速度，在相同的時間内處理更多的資料。
- 列式存儲：通過按列存儲提高機關時間内資料的I/O吞吐率，還能跳過不需要通路的列。
- 索引：利用索引配合查詢條件，可以迅速跳過不符合查詢條件的資料塊，僅掃描需要掃描的資料内容。
- 壓縮：壓縮資料然後存儲，使得存儲的密度更高，在有限的I/O速率下，在機關時間内讀取更多的記錄。
我們注意到，所有這些方法都隻是提高了機關時間内計算機處理資料的能力，當大家都采用這些技術時，彼此之間的差別将隻停留在實作層面的代碼細節上。最重要的是，這些技術都不會改變一個事實，那就是處理時間與資料量之間的正比例關系。
當資料量翻倍，在不擴容的前提下，MPP需要兩倍的時間來完成計算；列式存儲需要兩倍的存儲空間；索引下符合條件的記錄數也會翻倍；壓縮後的資料大小也是之前的兩倍。是以，查詢速度也會随之變成之前的一半。當資料量十倍百倍地增加時，這些技術的查詢速度就會十倍百倍地下降，最終無法完成查詢。
Apache Kylin的特色在于，在上述底層技術之外，另辟蹊徑地使用了獨特的Cube預計算技術。預計算事先将資料按次元組合進行了聚合，将結果儲存為物化視圖。經過聚合，物化視圖的規模就隻由次元的基數決定，而不再随資料量的增加呈線性增長。以電商為例，如果業務擴張，交易量增加了10倍，隻要交易資料的次元不變（供應商/商品種類數量不變），聚合後的物化視圖依舊是原先的大小，查詢的速度也将保持不變。
與同類産品相比，這一底層技術的差別使得Apache Kylin從外在功能上呈現出不同的特性，具體如下：
- SQL接口：除了Druid以外，所有的産品都支援SQL或類SQL接口。巧合的是，Druid也是除了Apache Kylin以外，相對查詢性能最好的一個。這除了歸功于Druid有自己的存儲引擎之外，也可能得益于其較為受限的查詢能力。
- 大資料支援：大多數産品的查詢能力在億級到十億級之間，更大的資料量将顯著降低其查詢性能。而Apache Kylin因為采用預計算技術，其查詢速度不受資料量限制。有實際案例證明，在資料量達千億級别時，Apache Kylin系統仍然能保持秒級别的查詢性能。
- 查詢速度：如前所述，一般産品的查詢速度都不可避免地随資料量的增加而下降。而Apache Kylin則更能夠在資料量成倍增加的同時保持查詢速度不變。而且這個差距将随着資料量的成倍增加而變得愈加明顯。
- 吞吐率：根據之前的實驗資料，Apache Kylin的單伺服器吞吐量一般在每秒70～150個查詢，并且可以線性擴充。而普通的産品因為所有計算都在查詢時完成，是以需要調動叢集更多的資源才能完成查詢，通常極限在每秒20個查詢左右，而且擴容成本較高，需要擴充整個叢集。相對地，Apache Kylin系統因其“瓶頸”不在于整個叢集，而在于Apache Kylin伺服器，是以隻需要增加Apache Kylin伺服器就能成倍提高吞吐率，擴容成本低廉。
1.7 小結
本章介紹了Apache Kylin的背景曆史和技術特點。尤其是它基于預計算的大資料查詢原理，理論上它可以在任意大的資料規模上達到O(1)常數級别的查詢速度，這是Apache Kylin與傳統查詢技術的關鍵差別，如圖1-6所示。傳統技術如大規模并行計算和列式存儲的查詢速度都在O(N)級别，與資料規模呈線性關系。如果資料規模擴大10倍，那麼O(N)的查詢速度就下降1/10，無法滿足日益增長的資料分析需求。依靠Apache Kylin，我們不用再擔心查詢速度會随資料量的增加而降低，能更有信心面對未來的資料挑戰。