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的使用场景

• 假如你的数据存储于 Hadoop 的 HDFS 分布式文件系统中，并且使用 Hive 来基于HDFS构建数据仓库系统，并进行数据分析，但是数据量巨大， 比如 PB 级别
• 同时也使用 HBase 来进行数据的存储和利于 HBase 的行键实现数据的快速查询
• 数据分析平台的数据量逐日累积增加
• 对于数据分析的维度大概 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

2.1.1、OLAP&&OLTP的基本概念

OLAP（Online Analytical Process），联机分析处理
OLTP（Online Transaction Processing），联机交易处理

OLAP，其主要的功能在于方便大规模数据分析及统计计算，可对决策提供参考和支持。
OLTP，更侧重于基的、日常的事务处理，包括数据的增删改

• OLAP需要以大量历史数据为基础，再配合上时间点的差异，对多维度及汇整型的信息进行复杂的分析。
• OLAP 需要用户有主观的信息需求定义，因此系统效率较佳。
• OLAP 的概念，在实际应用中存在广义和狭义两种不同的理解方式。广义上的理解与字面上的意思相同，泛指一切不会对数据进行更新的分析处理。
• 以多维度的方式分析数据，而且能够弹性地提供上卷（Roll-up）、下钻（Drill-down）和切片（Slice）等操作，它是呈现集成性决策信息的方法，多用于决策支持系统、商务智能或数据仓库。
• 更多的情况下 OLAP 被理解为其狭义上的含义，即与多维分析相关，基于立方体（Cube） 计算而进行的分析。
• OLAP（online analyticalprocessing）是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。从各方面观察信息，也就是从不同的维度分析数据，因此OLAP也成为多维分析。
  

2.1.2、OLAP的类型

2.1.3、OLAP CUBE

---

2.1.4、CUBE与 Cuboid

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、数据仓库建模常用手段方式

2.4.1、星型模型：

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

2.4.2、雪花模型：

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

2.4.3、星座模式：

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

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

2.5、数据立方体Cube

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

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

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

4. 所有维度组合的 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. 预计算 Cube，计算所有 Cuboid 并保存为物化视图。
3. 执行查询时，读取Cuboid，运算，产生查询结果。

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

3.1、Kylin的体系架构

Apache Kylin 系统可以分为在线查询和离线构建两部分，技术架构如图所示，在线查询的模块主要处于上半区，而离线构建则处于下半区。

REST Server

REST Server是一套面向应用程序开发的入口点，旨在实现针对Kylin平台的应用开发工作。此类应用程序可以提供查询、获取结果、触发cube构建任务、获取元数据以及获取用户权限等等。另外可以通过Restful接口实现SQL查询。

查询引擎（Query Engine）

当cube准备就绪后，查询引擎就能够获取并解析用户查询。它随后会与系统中的其它组件进行交互，从而向用户返回对应的结果。

路由器（Routing）

在最初设计时，曾考虑过将Kylin不能执行的查询引导去Hive中继续执行，但在实践后发现Hive与Kylin的速度差异过大，导致用户无法对查询的速度有一致的期望，很可能大多数查询几秒内就返回结果了，而有些查询则要等几分钟到几十分钟，因此体验非常糟糕。最后这个路由功能在发行版中默认关闭。

元数据管理工具（Metadata）

Kylin是一款元数据驱动型应用程序。元数据管理工具是一大关键性组件，用于对保存在Kylin当中的所有元数据进行管理，其中包括最为重要的cube元数据。其它全部组件的正常运作都需以元数据管理工具为基础。 Kylin的元数据存储在hbase中。

任务引擎（Cube Build Engine）

这套引擎的设计目的在于处理所有离线任务，其中包括shell脚本、Java API以及Map Reduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障。

3.2、Kylin特点

Kylin的主要特点包括支持SQL接口、支持超大规模数据集、亚秒级响应、可伸缩性、高吞吐率、BI工具集成等。

• 标准SQL接口：Kylin是以标准的SQL作为对外服务的接口。
• 支持超大数据集：Kylin对于大数据的支撑能力可能是目前所有技术中最为领先的。早在2015年eBay的生产环境中就能支持百亿记录的秒级查询，之后在移动的应用场景中又有了千亿记录秒级查询的案例。
• 亚秒级响应：Kylin拥有优异的查询相应速度，这点得益于预计算，很多复杂的计算，比如连接、聚合，在离线的预计算过程中就已经完成，这大大降低了查询时刻所需的计算量，提高了响应速度。
• 可伸缩性和高吞吐率：单节点Kylin可实现每秒70个查询，还可以搭建Kylin的集群。
  BI工具集成

Kylin可以与现有的BI工具集成，具体包括如下内容:
ODBC：与Tableau、Excel、PowerBI等工具集成
JDBC：与Saiku、BIRT等Java工具集成
RestAPI：与JavaScript、Web网页集成
Kylin开发团队还贡献了Zepplin的插件，也可以使用Zepplin来访问Kylin服务。