大数据-165 Apache Kylin Cube优化 案例 2 定义衍生维度及对比 & 聚合组 & RowKeys

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 大数据-165 Apache Kylin Cube优化 案例 2 定义衍生维度及对比 & 聚合组 & RowKeys

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

Hadoop(已更完)

HDFS(已更完)

MapReduce(已更完)

Hive(已更完)

Flume(已更完)

Sqoop(已更完)

Zookeeper(已更完)

HBase(已更完)

Redis (已更完)

Kafka(已更完)

Spark(已更完)

Flink(已更完)

ClickHouse(已更完)

Kudu(已更完)

Druid(已更完)

Kylin(正在更新…)

章节内容

上节我们完成了如下的内容:


Cube 剪枝优化

检查 Cube 数量、大小

案例 1:定义衍生维度及对比(整体详细流程)

88b6605098ff30ada42f8dbe865a8f62_2d160b48d1fd4673a5b454e5e6e6ad6b.png

定义Cube7

省略Model等操作。

构建前面Cube4类似的Cube7,仅在维度定义有区别。(我这里是Clone Cube4,然后修改的)

wzk_test_kylin_cube_7的字段中,都是Normal:

生成的如下图:

构建Cube7

大小对比

查看Size的对比:

由于之前数据太多跑的太慢,我的 cube-4 是125条数据占用22KB,我的cube-7是15条占用9KB。

粗略可以估计出来,cube-7的大小要比cube-4的大小大很多(如果同数据量的话)

精度对比

wzk_kylin_test_cube_4

kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader wzk_kylin_test_cube_4
• 1

对应的信息如下:

wzk_kylin_test_cube_7

kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader wzk_kylin_test_cube_7
• 1

对应的信息如下:

聚合组

随着维度数目的增加,Cuboid的数量会爆炸式的增长,为了缓解Cube的构建压力,Apache Kylin 引入了一系列高级的设置,帮助用户筛选出真正需要的Cuboid(本质是要减少Cube构建过程中的预计算),这些高级设置包括:


聚合组(Aggregation Group)

强制维度(Mandatory Dimension)

层级维度(Hierachy Dimension)

联合维度(Joint Dimension)

d61296793847020e6cb1552fe4950e7e_f5a7d2b46a274f2fab5420e0e4e9c6be.png 默认Kylin会把所有维度放在同一个聚合组中

如果维度数较多(如维度数>15),建议用户根据查询的习惯和模式,将维度分布到多个聚合组中。通过使用多个聚合组,可以大大降低Cube中的Cuboid数量。

如一个Cube有(M+N)个维度:


这些维度放在一个聚合组中,默认有2^(M+N)个Cuboid

将这些维度分为两个不相交的聚合组,第一个组有M个维度,第二个组有N个维度。那么Cuboid的总数为(2^M + 2^N)个维度

一个维度可以出现在多个聚合组中

在单个组合组中,可以对维度设置一些高级属性,包括强制思维、层级维度、联合维度。一个维度只能出现在一个属性组中。

构建N个维度的Cube会生成的2^N个Cuboid,如下图所示,构建一个4个维度(A、B、C、D)的Cube,需要生成16个Cuboid。

c5c632d561d8fbbc163206cf9c01c8aa_56ebf241bf3c42c19153f75138bf7efd.png 根据用户关注的维度组合,可以维度划分不同的组合类,这些组合类在Kylin中被称为聚合组,如用户仅仅关注维度AB组合和维度CD组合,那么该Cube则可以被分化成两个聚合组,分别是聚合组AB和聚合组CD。生成的Cuboid数目从16个缩减为8个。

用户关心的聚合组之间可能包含相同的维度,如聚合组ABC和聚合组BCD都包含维度B和维度C,这些聚合组之间会衍生相同的Cuboid。聚合组ABC会产生Cuboid BC,聚合组BCD也会产生Cuboid BC。

这些Cuboid不会重复生成,一份Cuboid为这些聚合组所共有。

有了聚合组就可以粗粒度的对Cuboid进行筛选,获取自己想要的维度组合。Kylin的建模需要业务专家参数。


强制维度(Mandatory Dimension)

强制/必要 维度:指的是那些总会出现在Where条件或Group By语句中的维度。

通过指定某些维度为强制维度,Kylin不预计算那些不包含此维度的Cuboid,从而减少计算量。

维度A是强制维度,那么生成的Cube如下图所示,维度数从16变成9。

8858bd0815d16a7151467e10442977fb_85f2fea43a984422913f2479a43bfe09.png 层级维度(Hierachy Dimension)

层级维度:是指一组有层级关系的维度

维度中常常会出现具有层级关系的维度,例如:国家、省份、城市这三个维度,从上而下来说:国家/省份/城市之间分别是一对多的关系。假设维度A代表国家,维度B代表省份,维度C代表城市,ABC三个维度可以被设置为层级维度,生成的Cube如下图所示:

b2161316dc28b1dafbd7738513d60d0e_89dac627eb6a420e9895ba6170079ae5.png Cuboid[A,C,D] = Cuboid[A,B,C,D], Cuboid[B,D] = Cuboid[A,B,D],因而Cuboid[A,C,D] 和 Cuboid[B,D] 就不必重复存储。


联合维度(Joint Dimension)

联合维度:是将多个维度视作一个维度,在进行组合计算的时候,它们要么一起出现,要么均不出现。

通常适用于以下几种情形:


总是在一起查询的维度

彼此之间有一定映射关系,如USER_ID和EMAIL

基数很低的维度,如性别、布尔类型的属性

维度的基数:维度有多少个不同的值。

联合维度并不关心维度之间各种细节的组合方式,如用户查询语句中仅仅会出现GROUP BY A,B,C,而不会出现GROUP BY A、B或者GROUP BY C等等这细化的维度组合。这一类问题就是联合维度所解决的问题。


例如将A、B、C定义为联合维度,Apache Kylin就仅仅构建Cuboid ABC,而Cuboid AB、BC、A等等Cuboid都不会被生成,最终Cube结果如下图所示的,Cuboid数目从16减少到4:

2b5ec53c198d999fc9630a1b67713afa_8f48d21917fc4fb9bd383f0b58e6768d.png 总结内容

在单个聚合组中,可以对维度进行设置,包括强制维度、层级维度、联合维度。

强制维度:指的是那些总会出现在Where条件或者GROUP BY子句中的维度

层级维度:一组具有层级关系的维度(如:国家、省、市)

联合维度:将多个维度看成一个角度,要么一起出现,要么都不出现

RowKeys

简单的说Cuboid的维度会映射为HBase的Rowkey,Cuboid的指标会映射为HBase的Value。

1eba6182cc141b0aae70428fceeb4eca_c7986224139c43d7a6bf953dff1998a5.png 如上图原始表所示:Hive表有两个维度列year、city,有一个指标列 price。

如上图预聚合表所示:我们具体要计算的是year和city这两个维度所有维度组合(即4个cuboid)下的sum(prices)指标,这个指标的具体计算过程就由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就是00000011,对应HBase Value就是sum(price)的具体值。

所有的Cuboid计算完成后,会将Cuboid转换为HBase的KeyValue格式生成HBase的HFile,最后将HFile Load进Cube对应的HBase表中。

a5905cb9286d1e02ceb370443be64723_d95e2ee1a66742f285f00d4fa3f04589.png 编码

Kyelin以Key-Value的方式将Cube存储到HBase中,HBase的Key就是Rowkey,是由各维度的值拼接而成的,为了更高效的的存储这些值,Kylin会对它们进行编码和压缩,每个维度均可以选择合适的编码方式,为了更搞笑存储这些值,Kylin会对它们进行编码和压缩,每个维度均可以选择合适的编码方式,默认采用的是字典(Dictionary)编码技术。字段支持的基本编码类型如下:


Dictionary 字典编码将所有此维度下的值构成一张映射表,从而大大节约存储空间,适用于大部分字段,默认推荐使用。Dictionary产生的编码非常紧凑,尤其在维度的值基数小且长度大的情况下,但在超高基情况下,可能引起内存不足的问题,在Kylin中字典编码允许的基数上限默认是500万(由参数kylin.dictionay.max.cardinality配置)

boolean:适用于字段为:ture、false、TURE、FALSE、t、f、T、F、yes、no、YES、NO、y、n、Y、N、1、0

date:适用于字段为日期字符,支持的格式包括yyyyMMdd、yyyy-MM-dd、yyyy-MM-dd HH:mm:ss.SSS

time:适用于字段为时间戳字符,支持范围为[1970-01-01 00:00:00],[2038-01-09 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列,以避免数据分散不均匀。


相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
目录
相关文章
|
1月前
|
监控 安全 BI
优化 Apache 日志记录的 5 个最佳实践
Apache 日志记录对于维护系统运行状况和网络安全至关重要,其核心包括访问日志与错误日志的管理。通过制定合理的日志策略,如选择合适的日志格式、利用条件日志减少冗余、优化日志级别、使用取证模块提升安全性及实施日志轮换,可有效提高日志可用性并降低系统负担。此外,借助 Eventlog Analyzer 等专业工具,能够实现日志的高效收集、可视化分析与威胁检测,从而精准定位安全隐患、评估服务器性能,并满足合规需求,为强化网络安全提供有力支持。
优化 Apache 日志记录的 5 个最佳实践
|
6月前
|
消息中间件 监控 大数据
优化Apache Kafka性能:最佳实践与调优策略
【10月更文挑战第24天】作为一名已经对Apache Kafka有所了解并有实际使用经验的开发者,我深知在大数据处理和实时数据流传输中,Kafka的重要性不言而喻。然而,在面对日益增长的数据量和业务需求时,如何保证系统的高性能和稳定性成为了摆在我们面前的一个挑战。本文将从我的个人视角出发,分享一些关于如何通过合理的配置和调优来提高Kafka性能的经验和建议。
183 4
|
7月前
|
消息中间件 分布式计算 大数据
大数据-166 Apache Kylin Cube 流式构建 整体流程详细记录
大数据-166 Apache Kylin Cube 流式构建 整体流程详细记录
158 5
|
7月前
|
分布式计算 大数据 Apache
利用.NET进行大数据处理:Apache Spark与.NET for Apache Spark
【10月更文挑战第15天】随着大数据成为企业决策和技术创新的关键驱动力,Apache Spark作为高效的大数据处理引擎,广受青睐。然而,.NET开发者面临使用Spark的门槛。本文介绍.NET for Apache Spark,展示如何通过C#和F#等.NET语言,结合Spark的强大功能进行大数据处理,简化开发流程并提升效率。示例代码演示了读取CSV文件及统计分析的基本操作,突显了.NET for Apache Spark的易用性和强大功能。
188 1
|
5月前
|
存储 人工智能 大数据
The Past, Present and Future of Apache Flink
本文整理自阿里云开源大数据负责人王峰(莫问)在 Flink Forward Asia 2024 上海站主论坛开场的分享,今年正值 Flink 开源项目诞生的第 10 周年,借此时机,王峰回顾了 Flink 在过去 10 年的发展历程以及 Flink社区当前最新的技术成果,最后展望下一个十年 Flink 路向何方。
529 33
The Past, Present and Future of Apache Flink
|
7月前
|
SQL Java API
Apache Flink 2.0-preview released
Apache Flink 社区正积极筹备 Flink 2.0 的发布,这是自 Flink 1.0 发布以来的首个重大更新。Flink 2.0 将引入多项激动人心的功能和改进,包括存算分离状态管理、物化表、批作业自适应执行等,同时也包含了一些不兼容的变更。目前提供的预览版旨在让用户提前尝试新功能并收集反馈,但不建议在生产环境中使用。
1308 13
Apache Flink 2.0-preview released
|
2月前
|
SQL 存储 人工智能
Apache Flink 2.0.0: 实时数据处理的新纪元
Apache Flink 2.0.0 正式发布!这是自 Flink 1.0 发布九年以来的首次重大更新,凝聚了社区两年的努力。此版本引入分离式状态管理、物化表、流批统一等创新功能,优化云原生环境下的资源利用与性能表现,并强化了对人工智能工作流的支持。同时,Flink 2.0 对 API 和配置进行了全面清理,移除了过时组件,为未来的发展奠定了坚实基础。感谢 165 位贡献者的辛勤付出,共同推动实时计算进入新纪元!
338 1
Apache Flink 2.0.0: 实时数据处理的新纪元
|
7月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
247 3
|
8月前
|
SQL 消息中间件 关系型数据库
Apache Doris Flink Connector 24.0.0 版本正式发布
该版本新增了对 Flink 1.20 的支持,并支持通过 Arrow Flight SQL 高速读取 Doris 中数据。
|
2月前
|
存储 大数据 数据处理
您有一份 Apache Flink 社区年度报告请查收~
您有一份 Apache Flink 社区年度报告请查收~

热门文章

最新文章

推荐镜像

更多