基础知识储备-大数据-Apache Kylin

Apache Kylin介绍

       Apache Kylin是一种分布式分析引擎， 提供Hadoop之上的标准SQL查询接口及多维分析（OLAP）功能。是Hadoop大数据平台上的一个开源OLAP引擎。它采用 多维立方体预计算技术，可以将大数据的SQL查询速度提升到亚秒级别。
     联机实时分析(OnlineAnalytical Processing, OLAP )技术是快速响应多维分析(Multidimensionalanalysis, MDA)的一种解决方案。

诞生背景：

2013年年初，eBay内部使用的传统数据仓库及商业智能平台应用碰 到了瓶颈，即传统的架构只支持垂直扩展，通过在一台机器上增加CPU和内存等资源来提升数据处理能力，相对于数据指数级的增长，单机扩展 很快就达到了极限。另一方面，Hadoop大数据平台虽然能存储和批量处 理大规模数据，但与BI平台的连接技术依然不成熟，无法提供高效的交 互式查询

解决方式:

—“预计算”。应尽量多
地预先计算聚合结果，在查询时刻应尽量使用预算的结果得出查询结
果，从而避免直接扫描可能无限增长的原始记录。
举例来说，使用如下的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亿，但只要商品的总数不变，那么预计算的结果记录总数就不会
变，查询的速度也不会变。

工作原理:

维度就是观察数据的角度。度量就是被聚合的统计值，也是聚合运算的结果.

给定一个数据模型，我们可以对其上的所有维度进行组合。对于N个 维度来说，组合的所有可能性共有2N 种。对于每一种维度的组合，将度 量做聚合运算，然后将运算的结果保存为一个物化视图，称为Cuboid。所 有维度组合的Cuboid作为一个整体，被称为Cube。所以简单来说，一个 Cube就是许多按维度聚合的物化视图的集合

下面来列举一个具体的例子。假定有一个电商的销售数据集，其中 维度包括时间（Time）、商品（Item）、地点（Location）和供应商（Supplier）， 度量为销售额（GMV）。那么所有维度的组合就有24 =16种（如图1-3所 示），比如一维度（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种组合。

计算Cuboid，即按维度来聚合销售额。

具体工作过程:

1）指定数据模型，定义维度和度量。
2）预计算Cube，计算所有Cuboid并保存为物化视图。
3）执行查询时，读取Cuboid，运算，产生查询结果。

由于Kylin的查询过程不会扫描原始记录，而是通过预计算预先完成
表的关联、聚合等复杂运算，并利用预计算的结果来执行查询，因此相比
非预计算的查询技术，其速度一般要快一到两个数量级，并且这点在超 大的数据集上优势更明显。当数据集达到千亿乃至万亿级别时，Kylin的 速度甚至可以超越其他非预计算技术1000倍以上。

Apache Kylin的技术架构

数据源在左 侧，目前主要是Hadoop Hive，保存着待分析的用户数据。根据元数据的 定义，下方构建引擎从数据源抽取数据，并构建Cube。数据以关系表的形 式输入，且必须符合星形模型（Star Schema）,MapReduce是当前主要的构建技术。构建后的Cube保存在右侧的存储引 擎中，一般选用HBase作为存储。

完成了离线构建之后，用户可以从上方查询系统发送SQL进行查询 分析。Kylin提供了各种Rest API、JDBC/ODBC接口。无论从哪个接口进 入，SQL最终都会来到Rest服务层，再转交给查询引擎进行处理。这里需 要注意的是，SQL语句是基于数据源的关系模型书写的，而不是Cube。 Kylin在设计时刻意对查询用户屏蔽了Cube的概念，分析师只需要理解简 单的关系模型就可以使用Kylin，没有额外的学习门槛，传统的SQL应用 也很容易迁移。查询引擎解析SQL，生成基于关系表的逻辑执行计划，然 后将其转译为基于Cube的物理执行计划，最后查询预计算生成的Cube并
产生结果。整个过程不会访问原始数据源。


未完待续