Kylin基本介绍

Kylin

1、kylin基本介绍

Apache Kylin 是一个开源的分布式存储引擎，最初由 eBay 开发贡献至开源 社区。它提供 Hadoop 之上的 SQL 查询接口及多维分析（OLAP）能力以支持大规 模数据，能够处理 TB 乃至 PB 级别的分析任务，能够在亚秒级查询巨大的 Hive 表，并支持高并发。

1.1、为什么要使用kylin

自Hadoop 诞生以来，大数据的存储和批处理问题均得到了妥善解决，而如何高速地分析数据也就成为了下一个挑战。

于是各式各样的“SQL on Hadoop”技术应运而生，其中以 Hive 为代表，Impala、Presto、Phoenix、Drill、 SparkSQL 等紧随其后。它们的主要技术是“大规模并行处理”（Massive Parallel Processing，MPP）和“列式存储”（Columnar Storage）。

• 大规模并行处理，可以调动多台机器一起进行并行计算，用线性增加的资源来 换取计算时间的线性下降。
• 列式存储，则将记录按列存放，这样做不仅可以在访问 时只读取需要的列，还可以利用存储设备擅长连续读取的特点，大大提高读取的 速率。

这两项关键技术使得 Hadoop 上的 SQL 查询速度从小时提高到了分钟。
然而分钟级别的查询响应仍然离交互式分析的现实需求还很远。分析师敲入 查询指令，按下回车，还需要去倒杯咖啡，静静地等待查询结果。得到结果之后才能根据情况调整查询，再做下一轮分析。如此反复，一个具体的场景分析常常 需要几小时甚至几天才能完成，效率低下。

这是因为大规模并行处理和列式存储虽然提高了计算和存储的速度，但并没有改变查询问题本身的时间复杂度，也没有改变查询时间与数据量成线性增长的 关系这一事实。

假设查询 1 亿条记录耗时 1 分钟，那么查询 10 亿条记录就需 10分钟，100 亿条记录就至少需要 1 小时 40 分钟。
当然，可以用很多的优化技术缩短查询的时间，比如更快的存储、更高效的压缩算法，等等，但总体来说，查询性能与数据量呈线性相关这一点是无法改变的。

虽然大规模并行处理允许十倍或百倍地扩张计算集群，以期望保持分钟级别 的查询速度，但购买和部署十倍或百倍的计算集群又怎能轻易做到，更何况还有 高昂的硬件运维成本。

另外，对于分析师来说，完备的、经过验证的数据模型比分析性能更加重要， 直接访问纷繁复杂的原始数据并进行相关分析其实并不是很友好的体验，特别是 在超大规模的数据集上，分析师将更多的精力花在了等待查询结果上，而不是在 更加重要的建立领域模型上。

1.2、kylin的使用场景

• (1) 假如你的数据存储于 Hadoop 的 HDFS 分布式文件系统中，并且使用 Hive 来基于 HDFS构建数据仓库系统，并进行数据分析，但是数据量巨大， 比如 PB 级别.

• (2) 同时也使用 HBase 来进行数据的存储和利于 HBase 的行键实现数据 的快速查询；

• (3) 数据分析平台的数据量逐日累积增加；

• (4) 对于数据分析的维度大概 10 个左右。

  如果类似于上述的场景，那么非常适合使用 Apache Kylin 来做大数据的多维分析。

1.3、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 在“大规模并行处理”和“列式存储”之外，提供给大数据分析的第三个关键技术。

2、准备知识

2.1、数据仓库、OLAP 与 BI

数据仓库

数据仓库，英文名称 Data Warehouse，简称 DW。

• 《数据仓库》一书中的定义为：数据仓库就是面向主题的、集成的、相对稳定的、随时间不断变化（不同时间）的数据集合，用以支持经营管理中的决策制定过程。
• 数据仓库中的数据：面向主题，与传统数据库面向应用相对应。
• 利用数据仓库的方式存放的资料，具有一旦存入，便不会随时间发生变动的特性，
• 此外，存入的资料必定包含时间属性，通常一个数据仓库中会含有大量的 历史性资料，并且它可利用特定的分析方式，从其中发掘出特定的资讯。

OLAP

1、OLAP的基本概念

• OLAP（Online Analytical Process），联机分析处理，

  • 以多维度的方式分析数据，而且能够弹性地提供上卷（Roll-up）、下钻（Drill-down）和切片（Slice） 等操作，它是呈现集成性决策信息的方法，多用于决策支持系统、商务智能或数 据仓库。
  • 其主要的功能在于方便大规模数据分析及统计计算，可对决策提供参考 和支持。

• OLTP（Online Transaction Processing），联机交易处理，

  • 更侧重于基 的、日常的事务处理，包括数据的增删改查。
  • OLAP需要以大量历史数据为基础，再配合上时间点的差异，对多维度及汇整型的信息进行复杂的分析。
  • OLAP需要用户有主观的信息需求定义，因此系统效率较佳。
  • OLAP 的概念，在实际应用中存在广义和狭义两种不同的理解方式。
    • 广义上的理解与字面上的意思相同，泛指一切不会对数据进行更新的分析处理。
    • 但更多 的情况下 OLAP 被理解为其狭义上的含义，即与多维分析相关，基于立方体（Cube） 计算而进行的分析

OLAP（online analyticalprocessing）是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。从各方面观察信息，也就是从不同的维度分析数据，因此OLAP也成为多维分析。

2、OLAP的类型
可以分为ROLAP和MOLAP

3、OLAP CUBE

4、CUBE与 Cuboid

BI

BI（Business Intelligence），即商务智能，指用现代数据仓库技术、在线 分析技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。

2.2、事实表与维度表

• 事实表（Fact Table），存储有事实记录的表，
  • 如系统日志、销售记录等；
  • 事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。
• 维度表（DimensionTable）或维表，有时也称查找表（Lookup Table），
  • 是 分析事实的一种角度，是与事实表相对应的一种表
  • 它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。
  • 常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。
  • 使用维度表有诸多好处， 具体如下。 ·
    • 缩小了事实表的大小。
    • 便于维度的管理和维护，增加、删除和修改维度的属性，不必对事实表的 大量记录进行改动。
    • 维度表可以为多个事实表重用，以减少重复工作。

2.3、维度与度量

• 维度是指审视数据的角度，它通常是数据记录的一个属性，例如时间、地点 等。
• 度量是基于数据所计算出来的考量值；它通常是一个数值，如总销售额、不 同的用户数等。

分析人员往往要结合若干个维度来审查度量值，以便在其中找到变化规律。 在一个 SQL 查询中，Group By的属性通常就是维度，而所计算的值则是度量。

如下面的示例：

在上面的这个查询中，part_dt 和 lstg_site_id 是维度，sum（price）和
count（distinct seller_id）是度量。

2.4、数据仓库建模常用手段方式

星型模型：
星形模型中有一张事实表，以及零个或多个维度表；事实表与维度表通过主键外键相关联，维度表之间没有关联，就像很多星星围绕在一个恒星周围，故取 名为星形模型。

雪花模型：
若将星形模型中某些维度的表再做规范，抽取成更细的维度表，然后让维度表之间也进行关联，那么这种模型称为雪花模型。

星座模式：
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

注意：Kylin 只支持星形模型的数据集

2.5、数据立方体Cube

Cube（或 Data Cube），即数据立方体，是一种常用于数据分析与索引的技术；它可以对原始数据建立多维度索引。通过 Cube 对数据进行分析，可以大大 加快数据的查询效率。

Cuboid 在 Kylin 中特指在某一种维度组合下所计算的数据。 给定一个数据模型，我们可以对其上的所有维度进行组合。

对于 N 个维度来说，组合的所有可能性共有 2 的 N 次方种。对于每一种维度的组合，将度量做 聚合运算，然后将运算的结果保存为一个物化视图，称为 Cuboid。

所有维度组合的 Cuboid 作为一个整体，被称为 Cube。所以简单来说，一个 Cube 就是许多按维度聚合的物化视图的集合。

下面来列举一个具体的例子。
假定有一个电商的销售数据集，其中维度包括
时间（Time）、商品（Item）、地点（Location）和供应商（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 种组合。

3、Kylin工作原理

Apache Kylin 的工作原理就是对数据模型做 Cube 预计算，并利用计算的结果加速查询，具体工作过程如下。

• 1）指定数据模型，定义维度和度量。
• 2）预计算 Cu