|NO.Z.00022|——————————|BigDataEnd|——|Hadoop&OLAP_Kylin.V22|——|Kylin.v22|Cube优化|Rowkeys|编码/顺序/分片|
一、Rowkeys
### --- Rowkeys
~~~ 简单的说Cuboid的维度会映射为HBase的Rowkey,Cuboid的指标会映射为HBase的Value。
二、Rowkeys示例说明

### --- Rowkeys示例说明
~~~ # 如上图原始表所示:
~~~ Hive表有两个维度列year和city,有一个指标列price。
~~~ # 如上图预聚合表所示:
~~~ 我们具体要计算的是year和city这两个维度所有维度组合(即4个cuboid)下的sum(priece)指标,
~~~ 这个指标的具体计算过程就是由MapReduce完成的。
~~~ # 如上图字典编码所示:
~~~ 为了节省存储资源,Kylin对维度值进行了字典编码。图中将beijing和shanghai依次编码为0和1。
~~~ # 如上图HBase KV存储所示:
~~~ 在计算cuboid过程中,会将Hive表的数据转化为HBase的KV形式。
~~~ Rowkey的具体格式是cuboid id +
~~~ 具体的维度值(最新的Rowkey中为了并发查询还加入了Shard Key),
~~~ 以预聚合表内容的第2行为例,其维度组合是(year,city),
~~~ 所以cuboid id就是00000011,cuboid是8位,具体维度值是1994和shanghai,
~~~ 所以编码后的维度值对应上图的字典编码也是11,所以HBase的Rowkey就是0000001111,
~~~ 对应的HBase Value就是sum(priece)的具体值。
~~~ 所有的cuboid计算完成后,会将cuboid转化为HBase的KeyValue格式生成HBase的HFile,
~~~ 最后将HFile load进cube对应的HBase表中。


三、编码
### --- 编码
~~~ Kylin 以 Key-Value 的方式将 Cube 存储到 HBase 中,HBase 的 key就是 Rowkey,
~~~ 是由各维度的值拼接而成的。为了更高效地存储这些值,Kylin 会对它们进行编码和压缩;
~~~ 每个维度均可以选择合适的编码方式,默认采用的是字典(Dictionary)编码技术。
### --- 字段支持的基本编码类型如下:
~~~ # Dictionary:
~~~ 字典编码将所有此维度下的值构成一张映射表,从而大大节约存储空间,适用于大部分字段,
~~~ 默认推荐使用。Dictionary产生的编码非常紧凑,尤其在维度的值基数小且长度大的情况下。
~~~ 但在超高基情况下,可能引起内存不足的问题,
~~~ 在Kylin中字典编码允许的基数上限默认是500万(由参数kylin.dictionary.max.cardinality 配置)
~~~ # boolean:
~~~ 适用于字段值为true, false,
~~~ TRUE, FALSE, True, False, t, f, T, F, yes, no, YES, NO, Yes, No, y, n, Y, N, 1, 0
~~~ # integer:
~~~ 适用于字段值为整数字符,支持的整数区间为[ -2^(8N-1), 2^(8N-1)]
~~~ # date:
~~~ 适用于字段值为日期字符,
~~~ 支持的格式包括yyyyMMdd、yyyy-MM-dd、yyyy-MM-dd HH:mm:ss、yyyy-MM-dd HH:mm:ss.SSS
~~~ # time:
~~~ 适用于字段值为时间戳字符,支持范围为[1970-01-01 00:00:00, 2038/01/19 03:14:07],
~~~ 毫秒部分会被忽略,time编码适用于 time、datetime、timestamp 等类型
~~~ # fix_length:
~~~ 适用于超高基场景,将选取字段的前 N 个字节作为编码值,
~~~ 当 N 小于字段长度,会造成字段截断,当 N 较大时,造成 RowKey 过长,
~~~ 查询性能下降,只适用于 varchar 或 nvarchar 类型
~~~ # fixed_length_hex:
~~~ 适用于字段值为十六进制字符,比如 1A2BFF 或者 FF00FF,每两个字符需要一个字节,
~~~ 只适用于 varchar 或 nvarchar 类型
四、顺序
### --- 顺序
~~~ 各维度在 Rowkeys 中的顺序,对于查询的性能会产生较明显的影响;
~~~ 在这里用户可以根据查询的模式和习惯,通过拖曳的方式调整各个维度在Rowkeys上的顺序。
~~~ # 推荐的顺序为:
~~~ Mandatory 维度
~~~ where 过滤条件中出现频率较多的维度
~~~ 高基数维度
~~~ 低基数维度放后面
~~~ 不常用的维度放在后面
~~~ 这样做的好处是,充分利用过滤条件来缩小在 HBase 中扫描的范围,从而提高查询的效率。
五、分片
### --- 分片
~~~ 指定 ShardBy 的列,明细数据将按照该列的值分片;
~~~ 没有指定 ShardBy 的列,则默认将根据所有列中的数据进行分片;
~~~ 选择适当的 ShardBy 列,可以使明细数据较为均匀的分散在多个数据片上,提高并行性,
~~~ 进而获得更理想的查询效率;
~~~ 建议选择基数较大的列作为 ShardBy 列,避免数据分散不均匀。
Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart
——W.S.Landor
分类:
bdv023-kylin
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
· DeepSeek 开源周回顾「GitHub 热点速览」