本文为Kylin权威指南的第一部分读书笔记，主要探讨了维度和度量的概念，深入理解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
扫一扫
937
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
