一、Kylin是什么？
麒麟者，神兽也，古人以为，其为四灵之一，仁兽，凡其出没，必有祥瑞。
在大数据处理技术领域，用户最普遍的诉求就是希望以很简易的方式从大数据平台上快速获取查询结果，同时也希望传统的商务智能工具能够直接和大数据平台连接起来，以便使用这些工具做数据分析。目前已经出现了很多优秀的SQL on Hadoop引擎，包括Hive、Impala及 SparkSQL等，这些技术的出现和应用极大地降低了用户使用Hadoop平台的难度。
为了进一步满足“在高并发、大数据量的情况下，使用标准SQL查询聚合结果集能够达到毫秒级”这一应用场景，Apache Kylin应运而生，在 eBay孵化并最终贡献给开源社区。Apache Kylin是2013年由eBay 在上海的一个中国工程师团队发起的、基于Hadoop大数据平台的开源 OLAP引擎。
它采用多维立方体预计算技术，利用空间换时间的方法，把很多分钟级别乃至小时级别的大数据查询速度一下子提升到了亚秒级别，极大地提高了数据分析的效率，填补了业界在这方面的空白。该引擎为超大规模数据集上的交互式大数据分析打开了大门。
二、为什么要用Kylin？
自从10年前Hadoop诞生以来，大数据的存储和批处理问题均得到了 妥善解决，而如何高速地分析数据也就成为了下一个挑战。于是各式各 样的“SQLon Hadoop”技术应运而生，其中以Hive为代表，Impala、Presto、 Phoenix、Drill、SparkSQL等紧随其后。它们的主要技术是“大规模并行处理”（Massive Parallel Processing，MPP）和“列式存储”（Columnar Storage）。 大规模并行处理可以调动多台机器一起进行并行计算，用线性增加的资源来换取计算时间的线性下降。列式存储则将记录按列存放，这样做不仅可以在访问时只读取需要的列，还可以利用存储设备擅长连续读取的特点，大大提高读取的速率。这两项关键技术使得Hadoop上的SQL查询 速度从小时提高到了分钟。
然而分钟级别的查询响应仍然离交互式分析的现实需求还很远。分析师敲入查询指令，按下回车，还需要去倒杯咖啡，静静地等待查询结果。得到结果之后才能根据情况调整查询，再做下一轮分析。如此反复， 一个具体的场景分析常常需要几小时甚至几天才能完成，效率低下。 这是因为大规模并行处理和列式存储虽然提高了计算和存储的速 度，但并没有改变查询问题本身的时间复杂度，也没有改变查询时间与 数据量成线性增长的关系这一事实。
假设查询1亿条记录耗时1分钟，那么查询10亿条记录就需10分钟，100亿条记录就至少需要1小时40分钟。 当然，可以用很多的优化技术缩短查询的时间，比如更快的存储、更高效的压缩算法，等等。但总体来说，查询性能与数据量呈线性相关这一点是无法改变的。虽然大规模并行处理允许十倍或百倍地扩张计算集群，以 期望保持分钟级别的查询速度，但购买和部署十倍或百倍的计算集群又 怎能轻易做到，更何况还有高昂的硬件运维成本。
另外，对于分析师来说，完备的、经过验证的数据模型比分析性能更 加重要，直接访问纷繁复杂的原始数据并进行相关分析其实并不是很友 好的体验，特别是在超大规模的数据集上，分析师将更多的精力花在了 等待查询结果上，而不是在更加重要的建立领域模型上。
三、Kylin 怎样解决关键问题
Apache Kylin 的初衷就是要解决千亿条、万亿条记录的秒级查询问题，其中的关键就是要打破查询时间随着数据量成线性增长的这个规律。仔细思考大数据OLAP，可以注意到两个事实。
- 大数据查询要的一般是统计结果，是多条记录经过聚合函数计算后的统计值。原始的记录则不是必需的，或者访问频率和概率都极低。
- 聚合是按维度进行的，由于业务范围和分析需求是有限的，有意义的维度聚合组合也是相对有限的，一般不会随着数据的膨胀而增长。
基于以上两点，我们可以得到一个新的思路——“预计算”。应尽量多地预先计算聚合结果，在查询时刻应尽量使用预算的结果得出查询结果，从而避免直接扫描可能无限增长的原始记录。
举例来说，使用如下的SQL来查询10月1日那天销量最高的商品：
select item,sum(sell_amount)
from sell_details
where sell_data=’2016-10-1’
group by item
order by sum(sell_amount) desc;
用传统的方法时需要扫描所有的记录，再找到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在 “大规模并行处理” 和 “列式存储” 之外，提供给大数据分析的第三个关键技术。
四、Kylin 特点
Kylin 的主要特点包括支持SQL 接口、支持超大规模数据集、亚秒级响应、可伸缩性、高吞吐率、BI 工具集成等。
1）标准SQL 接口：Kylin 是以标准的SQL 作为对外服务的接口。
2）支持超大数据集：Kylin 对于大数据的支撑能力可能是目前所有技术中最为领先的。早在2015 年eBay 的生产环境中就能支持百亿记录的秒级查询，之后在移动的应用场景中又有了千亿记录秒级查询的案例。
3）亚秒级响应：Kylin 拥有优异的查询相应速度，这点得益于预计算，很多复杂的计算，
比如连接、聚合，在离线的预计算过程中就已经完成，这大大降低了查询时刻所需的计算量，
提高了响应速度。
4）可伸缩性和高吞吐率：单节点Kylin 可实现每秒70 个查询，还可以搭建Kylin 的集
群。
5）BI 工具集成
Kylin 可以与现有的BI 工具集成，具体包括如下内容。
- ODBC：与Tableau、Excel、PowerBI 等工具集成
- JDBC：与Saiku、BIRT 等Java 工具集成
- RestAPI：与JavaScript、Web 网页集成
Kylin 开发团队还贡献了 Zepplin 的插件，也可以使用Zepplin 来访问Kylin 服务。
五、Kylin 架构
1）REST Server
REST Server 是一套面向应用程序开发的入口点，旨在实现针对Kylin 平台的应用开发工作。此类应用程序可以提供查询、获取结果、触发Cube 构建任务、获取元数据以及获取用户权限等等。另外可以通过Restful 接口实现SQL 查询。
2）查询引擎（Query Engine）
当Cube 准备就绪后，查询引擎就能够获取并解析用户查询。它随后会与系统中的其它组件进行交互，从而向用户返回对应的结果。
3）Routing
负责将解析的SQL 生成的执行计划转换成Cube 缓存的查询，Cube 是通过预计算缓存在hbase 中，这部分查询可以在秒级设置毫秒级完成，而且还有一些操作使用过的查询原始数据（存储在Hadoop 的HDFS 中通过Hive 查询）。这部分查询延迟较高。
4）元数据管理工具（Metadata）
Kylin 是一款元数据驱动型应用程序。元数据管理工具是一大关键性组件，用于对保存在Kylin 当中的所有元数据进行管理，其中包括最为重要的Cube 元数据。其它全部组件的正常运作都需以元数据管理工具为基础。Kylin 的元数据存储在hbase 中。
5）任务引擎（Cube Build Engine）
这套引擎的设计目的在于处理所有离线任务，其中包括Shell 脚本、Java API 以及Map Reduce 任务等等。任务引擎对Kylin 当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障。
六、Kylin 工作原理
Apache Kylin 的工作原理本质上是MOLAP（Multidimension On-Line Analysis Processing）Cube，也就是多维立方体分析。是数据分析中非常经典的理论，下面对其做简要介绍。
6.1 维度和度量
维度：即观察数据的角度。比如员工数据，可以从性别角度来分析，也可以更加细化，从入职时间或者地区的维度来观察。维度是一组离散的值，比如说性别中的男和女，或者时间维度上的每一个独立的日期。因此在统计时可以将维度值相同的记录聚合在一起，然后应用聚合函数做累加、平均、最大和最小值等聚合计算。
度量：即被聚合（观察）的统计值，也就是聚合运算的结果。比如说员工数据中不同性
别员工的人数，又或者说在同一年入职的员工有多少。
6.2 Cube 和Cuboid
有了维度跟度量，一个数据表或者数据模型上的所有字段就可以分类了，它们要么是维度，要么是度量（可以被聚合）。于是就有了根据维度和度量做预计算的Cube 理论。
给定一个数据模型，我们可以对其上的所有维度进行聚合，对于N 个维度来说，组合的所有可能性共有2n 种。对于每一种维度的组合，将度量值做聚合计算，然后将结果保存为一个物化视图，称为Cuboid。所有维度组合的Cuboid 作为一个整体，称为Cube。
下面举一个简单的例子说明，假设有一个电商的销售数据集，其中维度包括时间[time]、
商品[item]、地区[location]和供应商[supplier]，度量为销售额。那么所有维度的组合就有2的4次方 =16 种，如下图所示：
- 一维度（1D）的组合有：[time]、[item]、[location]和[supplier]4 种；
- 二维度（2D）的组合有：[time, item]、[time, location]、[time, supplier]、[item, location]、
[item, supplier]、[location, supplier]3 种； - 三维度（3D）的组合也有4 种；
最后还有零维度（0D）和四维度（4D）各有一种，总共16 种。
注意：每一种维度组合就是一个Cuboid，16 个Cuboid 整体就是一个Cube。
6.3 核心算法
Kylin 的工作原理就是对数据模型做Cube 预计算，并利用计算的结果加速查询：
1）指定数据模型，定义维度和度量；
2）预计算Cube，计算所有Cuboid 并保存为物化视图；
预计算过程是Kylin 从Hive 中读取原始数据，按照我们选定的维度进行计算，并将结果集保存到Hbase 中，默认的计算引擎为MapReduce，可以选择Spark 作为计算引擎。一次 build 的结果，我们称为一个Segment。构建过程中会涉及多个Cuboid 的创建，具体创建过程由 kylin.Cube.algorithm 参数决定，参数值可选 auto，layer 和 inmem， 默认值为auto，即 Kylin 会通过采集数据动态地选择一个算法(layer or inmem)，如果用户很了解Kylin 和自身的数据、集群，可以直接设置喜欢的算法。
3）执行查询，读取Cuboid，运行，产生查询结果。
6.3.1 逐层构建算法（layer）
我们知道，一个N 维的Cube，是由1 个N 维子立方体、N 个(N-1)维子立方体、N*(N-1)/2
个(N-2)维子立方体、…、N 个1 维子立方体和1 个0 维子立方体构成，总共有2^N 个子立
方体组成，在逐层算法中，按维度数逐层减少来计算，每个层级的计算（除了第一层，它是从原始数据聚合而来），是基于它上一层级的结果来计算的。比如，[Group by A, B]的结果，可以基于[Group by A, B, C]的结果，通过去掉C 后聚合得来的；这样可以减少重复计算；当 0 维度Cuboid 计算出来的时候，整个Cube 的计算也就完成了。
每一轮的计算都是一个MapReduce 任务，且串行执行；一个N 维的Cube，至少需要
N+1 次MapReduce Job。
算法优点：
1）此算法充分利用了MapReduce 的能力，处理了中间复杂的排序和洗牌工作，故而算法代码清晰简单，易于维护；
2）受益于Hadoop 的日趋成熟，此算法对集群要求低，运行稳定；在内部维护Kylin的过程中，很少遇到在这几步出错的情况；即便是在Hadoop 集群比较繁忙的时候，任务也能成。
算法缺点：
1）当Cube 有比较多维度的时候，所需要的MapReduce 任务也相应增加；由于Hadoop 的任务调度需要耗费额外资源，特别是集群较庞大的时候，反复递交任务造成的额外开销会相当可观；
2）此算法会对Hadoop MapReduce 输出较多数据; 虽然已经使用了Combiner 来减少从
Mapper 端到Reducer 端的数据传输，所有数据依然需要通过Hadoop MapReduce 来排序和组合才能被聚合，无形之中增加了集群的压力;
3）对HDFS 的读写操作较多：由于每一层计算的输出会用做下一层计算的输入，这些
Key-Value 需要写到HDFS 上；当所有计算都完成后，Kylin 还需要额外的一轮任务将这些文件转成HBase 的HFile 格式，以导入到HBase 中去；
总体而言，该算法的效率较低，尤其是当Cube 维度数较大的时候。
6.3.2 快速构建算法（inmem）
也被称作“逐段”(By Segment) 或“逐块”(By Split) 算法，从1.5.x 开始引入该算法，利用
Mapper 端计算先完成大部分聚合，再将聚合后的结果交给Reducer，从而降低对网络瓶颈的压力。该算法的主要思想是，对Mapper 所分配的数据块，将它计算成一个完整的小Cube 段（包含所有Cuboid）；每个Mapper 将计算完的Cube 段输出给Reducer 做合并，生成大Cube，也就是最终结果；如图所示解释了此流程。
与旧算法相比，快速算法主要有两点不同：
1） Mapper 会利用内存做预聚合，算出所有组合；Mapper 输出的每个Key 都是不同的，这样会减少输出到Hadoop MapReduce 的数据量；
2）一轮MapReduce 便会完成所有层次的计算，减少Hadoop 任务的调配。
6.4 原理
Apache Kylin的工作原理就是对数据模型做Cube预计算，并利用计算 的结果加速查询，具体工作过程如下。
- 指定数据模型，定义维度和度量。
- 预计算Cube，计算所有Cuboid并保存为物化视图。
- 执行查询时，读取Cuboid，运算，产生查询结果。
由于Kylin的查询过程不会扫描原始记录，而是通过预计算预先完成 表的关联、聚合等复杂运算，并利用预计算的结果来执行查询，因此相比 非预计算的查询技术，其速度一般要快一到两个数量级，并且这点在超 大的数据集上优势更明显。当数据集达到千亿乃至万亿级别时，Kylin的 速度甚至可以超越其他非预计算技术1000倍以上。
七、小结
Kylin 通过预计算，把计算结果集保存在HBase中，原有的基于行的关系模型被转换成基于键值对的列式存储；通过维度组合作为HBase的Rowkey，在查询访问时不再需要昂贵的表扫描，这为高速高并发分析带来了可能；Kylin提供了标准SQL查询接口，支持大多数的SQL函数，同时也支持ODBC/JDBC的方式和主流的BI产品无缝集成。
本文介绍了Apache Kylin的历史背景和技术特点。尤其是它基于预计算的大数据查询原理，理论上可以在任意大的数据规模上达到O（1）常数级别的查询速度，这一点也是Apache Kylin与传统查询技术的关键区别，如下图所示。
传统技术，如大规模并行计算和列式存储的查询速度都在 O（N）级别，与数据规模增线性关系。如果数据规模增长10倍，那么O（N） 的查询速度就会下降到十分之一，无法满足日益增长的数据需求。依靠 Apache Kylin，我们不用再担心查询速度会随着数据量的增长而减慢，面对未来的数据挑战时也能更有信心。