kylin 权威指南----读书笔记1

本文都是我对kylin有一定了解后，再看权威指南时的笔记，有的只记下了自己认为重要的概念，有的几下自己没有掌握的概念，所以有一定片面性，如果您正在使用kylin，个人建议还是用一个下午看看kylin权威指南，比不懂概念一直找度娘省时高效。

点击下载kylin权威指南

维度和度量

---

维度是指审视数据的角度，它通常是数据记录的一个属性，例如时间地点等

度量是基于数据所计算出来的考量值，通常是一个数值，如销售额，不同的用户等

分析人员往往要结合若干个维度来审查度量值，以便在其中找到变化规律

在一个sql中group by属性就是一个维度，而所计算的指就是一个度量

事实表和维度表

---

事实表：FactTable，是指存储大量实际记录的表，通常为系统日志，销售记录等。会随着业务、时间增长；所以它的体积大于其他表

维度表：维表，DimensionTable，也成查找表，LookupTable；是与事实表相对应的表，保存的是维度属性值，可以和事实表做关联；相当于事实表中经常重复出现的属性提取、规范用一张表来管理。常见的维表有：日期表、地点表。使用维度表的好处：1、减少事实表的大小，2、便于维度的管理和维护，增删改维度的属性不会对事实表的大量记录进行改动，3、维度表可以为多个事实表重用，减少重复工作。

Cube、Cuboid和segment

---

Cube：对原始数据建立多维索引

Cuboid：某一种维度组合下的所有数据

segment：是指针对数据中的某一个片段，计算出来的Cube数据。

维度表的设计

---

维度表主键要唯一

维度表越小越好

维度表改变频率要低

维度表最好不要用Hive视图

Hive表分区

---

Kylin支持增量Cube创建，通常是按时间属性来增量地从Hive表中抽取数据。如果Hive表正好按此时间做分区的话，那么就可以利用hive分区的好处，每次在cube构建的时候都可以直接跳过不相干的日志数据，节省cube创建时间。在Kylin中叫 Partition Time Column,对应hive中的分区列

维度的基数

---

维度的基数(Cardinality)指的是该维度在数据集中出现的不同值得个数；例如“国家”是一个维度，如果有200个不同的值，那么此维度的基数就是200。通常一个维度从几十到几万个不等，个别维度如“用户ID”的基数会超过百万甚至千万。基数超过一百万的维度通常被称为高基数维度（Ultra High Cardinality，UHC），需要设计者注意

如果一个cube中有多个超高基数维度，那么Cube的膨胀率就会很高。

在创建Cube前对维度的基数做一个了解，可以合理创建Cube。

可以通过Hive count distinct 的SQL查询；也可以通过Kylin提供的计算基数的方法

导入HIve表

---

可以一次导入多张表，以逗号分隔

创建model

---

选择维度列时，维度可以来自事实表或维度表

选择度量列时，度量只能来自事实表

创建Cube

---

如果是衍生维度的话，必须来自维度表；由于这些列都可以由 该维度表的主键值衍生出来，所以实际上只有主键列被Cube加入计算

Kylin默认会把所有维度都放在同一个 聚合组中；如果维度较多，那么建议用户根据查询习惯和模式，将维度分为多个聚合组。Cuboid的个数从2^(M+N)->2^M+2^N

单个聚合组中，可以对维度设置高级属性，如Mandatory、Hierarchy、Joint

Mandatory维度指的是那些总是会出现在Where条件或Group By语句里的维度

Hierarchy是一组有层级关系的维度，如国家、省、市；省、市不会单独出现查询；只会出现国家、国家-省、国家-省-市

Joint是将多个维度组合成一个维度，通常适用于两种情形：1、总会在一起查询的维度；2、基数很低的维度

Advanced Setting

---

Rowkeys

Kylin将Cube存储在HBase中。Rowkey是由各个维度的值拼接而成的；为了高效低存储这些值，Kylin会对它们进行编码和压缩；每个维度选择合适的编码（Encoding）方式，默认采用的是字典（Dictionary）编码技术；此外还有Integer、Fixed Length

字典编码是将此维度下的所有值构建一个从String到int的映射表；Kylin会将字典序列化保存，在Cube中存储int值，从而大大减少存储的大小。

字典非常适合非固定长度的string类型值得维度，而且用户无需指定编码后的长度；但使用字典需要维护一张映射表，因此如果此 维度基数高，那么字典的大小就非常可观了，从而不适合加载到内存中，这种情景就要 选择其他编码方式了。Kylin中字典编码允许的基数上限默认是500万（由参数kylin.dictionary.max.cardinality配置）

字典编码有很好的压缩率，可降低存储空间，同时也提升存储读取的速度；缺点是构建字典需要较多的内存资源，创建维度基数超过千万的容易造成内存溢出。

整数Integer编码适合对int或bigin类型的值进行编码，它 无需额外存储，同时可以 支持很大的基数。用户需要根据 值域选择编码的长度。如一个手机号的维度13800138000，我们知道它大于2^31，但是小于2^39-1，那么length选择5就可以了。 比按字节存储（11字节）要少占用一般以上的空间。

当上面几种编码方式都不适合的时候，就需要使用固定长度的编码了；此编码方式只是将原始值截断或补齐成相同长度的一组字节，没有额外的转换，所以哦空间效率较差，通常只是作为一中权益手段

各维度在Rowkey中的顺序，对于查询的性能会产生明显的影响。用户根据查询的模式和习惯， 通过拖拽的方式调整整个维度的Rowkeys上的顺序。通常原则是：将 过滤频率较高的列放置在过滤频率较低的列之前，将 基数高的列放置在基数低的列之前。这样充分利用过滤条件来缩小HBase的扫描范围，从而提高查询效率

Cube配置参数

---

Kylin全局的参数值可在conf/kylin.properties文件中进行配置，如果Cube需要覆盖全局配置的话，需要在Configuration Overwrites指定

Cube的Build

---

构建方式有两种：全量构建和增量构建，两者构建步骤完全一样，区别在于数据集是全集还是子集

全量构建

对数据模型中没有指定分隔时间列信息的Cube，kylin会采用全量构建，即从Hive中读取全部的数据来构建，试用于一下两种情形：

    1、事实表数据不是按时间增长的。

    2、事实表的数据比较小或更新频率很低，全量构建不会造成太大的开销 

增量构建

    Kylin对一段时间内的数据进行计算，并以segment的形式进行保存。构建时间采用左闭右开的数据进行构建。经过多次构建就创建了多个segment。查询时，Kylin会查询一个或多个segment然后再做聚合计算

    增量构建的好处是，它只是对新增数据进行计算，避免了每次都会历史数据进行重复计算。尤其是当Cube很大时，使用增量构建是非常有必要的

Cube构建步骤

---

1、创建临时的Hive平表（从Hive读取数据）

2、计算各维度的不同值，并收集各Cuboid的统计数据

3、创建并保存维度字典

4、保存Cuboid统计信息

5、创建HTable

6、计算Cube（一轮或若干轮MR—轮数取决于维度数）

7、将Cube的计算结果转成HFile（MR—>SequenceFile—>HFile)

8、加载HFile到HBase

9、更新Cube元数据

10、垃圾回收

Cube刷新

---

Cube创建完成以后，历史数据发生了改动，就需要对响应的segment进行重新计算，这种构建成为刷新。刷新只针对增量Cube而言，因为全量Cube只要重新全部构建就可以更新了

而增量更新的Cube因为有多个Segment，因此需要先选择刷新的Segment，然后进行刷新

刷新后，就的Segment成为来及，等待回收

合并

---

当Segment数量较多，查询性能下降，会给HBase集群管理带来压力。因此需要适时地将一些Segment进行合并，将若干个小的Segment合并成较大的Segment

合并的好处：

    1、合并相同的key，从而减少Cube的存储空间

    2、Segment减少，就减少了查询时的二次聚合，提高了查询性能

    3、HTable数量减少，便于集群的管理

查询

---

同一个项目下，如果有多个基于同一模型的Cube，而且他们都满足对表、维度和度量的要求；那么Kylin会挑一个“最优的”Cube来进行查询；原则是基于成本的选择，成本计算包括多方面，例如Cube的维度数、度量、数据模型的复杂度等

SQL参考

---

Apache Kylin 支持标准SQL作为查询语言，但SQL有很多变体,Kylin支持的只是SQL所有变体中的一个子集，并不支持所有SQL语句和语法。用户使用Kylin之前，需要对Kylin支持的SQL有一个了解，以避免走弯路。

首先、Kylin作为OLAP引擎，支持查询，即所有的SQL都必须是SELECT语句

第二、SQL语句的表名、列名、度量、连接关系时， 需要至少跟一个Cube的模型相匹配；在设计Cube的时候，需要充分考虑需求，避免遗漏表、列信息

第三、Kylin使用Apache Calcite做SQL语法分析。

增量构建Cube

---

Model的分隔时间必须是事实表上的列

格式如果是Unix Time 需要利用Hive视图转化为kylin支持的格式，如下三种

RestApi

---

获取Segment列表

能够返回该cube包含几个Segment，Segment起始时间，Segment的状态：例如Ready

如果所有Segment status都为Ready就可以进行增量cube的创建了。

如果Segment status 为NEW，说明构建尚未完成，需要获取该Segment的job id，然后将其作为参数提交如下Rest请求

GET http://hostname:port/kylin/api/jobs/{job_uuid}

Path Variable

Job_uuid -必需，构建任务标识符

从而获得每一步的状态信息step_status

如果某个子步骤为ERROR或是PENDDING很长时间，可以看下该步骤发生了什么。Kylin提供了另外一个Rest接口允许用户获取构建任务中某个特定子步骤的输出，接口的请求如下

GET http://hostname:port/kylin/api/jobs/{job_uuid}/steps/{step_id}/output

Path Variable

Job_uuid -必需，构建任务标识符

Step_id - 必需，构建任务子步骤标识符

找到问题后，修复后，可以调用RESUME Rest接口重新执行该次构建任务

GET http://hostname:port/kylin/api/jobs/{job_uuid}/resume

Path Variable

Job_uuid -必需，构建任务标识符

触发构建

PUT http://hostname:port/kylin/api/Cubes/{CubeName}/rebuild

curl  -X PUT  -H 'Content-Type: application/json' -d '{"startTime":'1423526400000', "endTime":'1423526400' , "buildType":"BUILD"}' http://hostname:port/kylin/api/cubes/{CubeName} /rebuild

详见增量Cube创建

合并

将buildType改为MERGE，并重新设置startTime、endTime

点击查看下一篇读书笔记