一、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 当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障。
