kylin学习记录总结

kylin学习记录总结

文章目录

• 概述
• • 主要特点
  • 核心概念
• 注意事项
• • 在hive中准备数据
  • 星形模型
  • 维度表的设计
  • hive表的分区
  • 了解维度的基数
  • • 维度基数的计算
• 设计cube
• • 增量构建和全量构建
  • • 增量构建遇到的场景问题及解决
  • 历史数据刷新
  • 合并
  • Cube的剪枝优化
• cube的查询
• 快速开始
• 附录

概述

Apache Kylin是Hadoop大数据平台上的一个开源OLAP引擎。它采用多维立方体预计算技术，可以将大数据的SQL查询速度提升到亚秒级别。相对于之前的分钟乃至小时级别的查询速度，亚秒级别速度是百倍到千倍的提升，该引擎为超大规模数据集上的交互式大数据分析打开了大门。

主要特点

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

• 标准sql接口
  因为sql是绝大多数数据分析人员常用的基本语言，所以Apache Kylin以标准SQL作为对外服务的主要接口，虽然MDX作为OLAP查询语言，从学术上来说，它是更加适合Kylin的选择，然而实践表明，SQL简单易用，代表了绝大多数用户的第一需求，这也是Kylin能够快速推广的一个关键。
• 支持超大数据集
  因为使用了Cube预计算技术，在理论上，Kylin可以支撑的数据集大小没有上限，仅受限于存储系统和分布式计算系统的承载能力，并且查询速度不会随数据集的增大而减慢。Kylin在数据集规模上的局限性主要在于维度的个数和基数。它们一般由数据模型来决定，不会随着数据规模的增长而线性增长，这也意味着Kylin对未来数据的增长有着更强的适应能力。
• 亚秒级响应
  Apache Kylin拥有优异的查询响应速度，这点得益于预计算，很多复杂的计算，比如连接、聚合，在离线的预计算过程中就已经完成，这大大降低了查询时刻所需要的计算量，提高了响应速度。
• 可伸缩性和高吞吐率
  这主要还是归功于预计算降低了查询时所需的计算总量，令Kylin可以在相同的硬件配置下承载更多的并发查询。随着机器节点的增加， kylin每秒的查询可以呈线性增长。在只有1个Kylin实例的情况下，Kylin每秒可以处理近70个查询。存在4个实例时可达到每秒230个查询左右，而这4个实例仅部署在一台机器上，理论上添加更多的应用服务器后可以支持更大的并发率。
• BI及可视化工具集成
  Apache Kylin提供了丰富的API，以与现有的BI工具集成。
  通过以下接口，能继承不同的BI可视化工具：
  ODBC接口：与Tableau、Excel、Power BI等工具集成。
  JDBC接口，与Saiku、BIRT等Java工具集成。
  Rest API，与Javascript、Web网页集成。

核心概念

• 数据仓库：
  数据仓库（Data Warehouse）是一种信息系统的资料储存理论，此理论强调的是利用某些特殊的资料储存方式，让所包含的资料特别有利于分析和处理，从而产生有价值的资讯，并可依此做出决策。
• OLAP
  OLAP（online Analytical Process），联机分析处理，以多维度的方式分析数据，而且能够d性地提供上卷（Roll-up）、下钻（Drill-down）和透视分析（Pivot）等 *** 作，它是呈现集成性决策信息的方法，多用于决策支持系统、商务智能或数据仓库。其主要的功能在于方便大规模数据分析及统计计算，可对决策提供参考和支持。与之相区别的是联机交易处理（OLTP），联机交易处理，更侧重于基本的、日常的事务处理，包括数据的增删改查。
• BI
  BI（Business Intelligence），即商务智能，指用现代数据仓库技术、在线分析技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。
• 维度和度量
  维度和度量是数据分析中的两个基本概念。
  维度是指审视数据的角度，它通常是数据记录的一个属性，例如时间、地点等。度量是基于数据所计算出来的考量值；它通常是一个数值，如总销售额、不同的用户数等。分析人员往往要结合若干个维度来审查度量值，以便在其中找到变化规律。在一个SQL查询中，Group By的属性通常就是维度，而所计算的值则是度量。
• 事实表和维度表
  事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。
  维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。
• Cube、Cuboid和Cube Segment
  Cube（或Data Cube），即数据立方体，是一种常用于数据分析与索引的技术；它可以对原始数据建立多维度索引。通过Cube对数据进行分析，可以大大加快数据的查询效率。
  Cuboid在Kylin中特指在某一种维度组合下所计算的数据。
  Cube Segment是指针对源数据中的某一个片段，计算出来的Cube数据。通常数据仓库中的数据数量会随着时间的增长而增长，而CubeSegment也是按时间顺序来构建的。

注意事项 在hive中准备数据

需要被分析的数据必须先保存为Hive表的形式，然后Kylin才能从Hive中导入数据，创建Cube。
在Hive中准备待分析的数据是使用Kylin的前提。

星形模型

数据挖掘有几种常见的多维数据模型，如星形模型（Star Schema）、雪花模型（Snowf？lake Schema）、事实星座模型（Fact Constellation）等。
星形模型中有一张事实表，以及零个或多个维度表；事实表与维度表通过主键外键相关联，维度表之间没有关联，就像很多星星围绕在一个恒星周围，故取名为星形模型。
如果将星形模型中某些维度的表再做规范，抽取成更细的维度表，然后让维度表之间也进行关联，那么这种模型称为雪花模型。
星座模型是更复杂的模型，其中包含了多个事实表，而维度表是公用的，可以共享。
不过，Kylin只支持星形模型的数据集，这是基于以下考虑。

• 星形模型是最简单，也是最常用的模型。
• 由于星形模型只有一张大表，因此它相比于其他模型更适合于大数据处理。
• 其他模型可以通过一定的转换，变为星形模型。

维度表的设计

kylin对维度表有如下的要求：

• 要具有数据一致性，主键值必须是唯一的；Kylin会进行检查，如果有两行的主键值相同则会报错。
• 维度表越小越好，因为Kylin会将维度表加载到内存中供查询；过大的表不适合作为维度表，默认的阈值是300MB。
• 改变频率低，Kylin会在每次构建中试图重用维度表的快照，如果维度表经常改变的话，重用就会失效，这就会导致要经常对维度表创建快照。
• 维度表最好不要是Hive视图（View），虽然在Kylin1.5.3中加入了对维度表是视图这种情况的支持，但每次都需要将视图进行物化，从而导致额外的时间开销。

hive表的分区

Hive表支持多分区（Partition）。简单地说，一个分区就是一个文件目录，存储了特定的数据文件。当有新的数据生成的时候，可以将数据加载到指定的分区，读取数据的时候也可以指定分区。对于SQL查询，如果查询中指定了分区列的属性条件，则Hive会智能地选择特定分区（也就是目
录），从而避免全量数据的扫描，减少读写 *** 作对集群的压力。
hivesql分区示例：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xNUZ8E5t-1641124574866)(en-resource://database/718:1)]
Kylin支持增量的Cube构建，通常是按时间属性来增量地从Hive表中抽取数据。如果Hive表正好是按此时间属性做分区的话，那么就可以利用到Hive分区的好处，每次在Hive构建的时候都可以直接跳过不相干日期的数据，节省Cube构建的时间。这样的列在Kylin里也称为分割时间列（Partition Time Column），通常它应该也是Hive表的分区列。

了解维度的基数

维度的基数（Cardinality）指的是该维度在数据集中出现的不同值的个数；例如“国家”是一个维度，如果有200个不同的值，那么此维度的基数就是200。通常一个维度的基数会从几十到几万个不等，个别维度如“用户ID”的基数会超过百万甚至千万。基数超过一百万的维度通常被称为超高基数维度（Ultra High Cardinality，UHC），需要引起设计者的注意。如果一个Cube
中有好几个超高基数维度，那么这个Cube膨胀的概率就会很高，所以计算出维度的基数有利于更好地设计cube。

维度基数的计算

• 让hive表执行一个count distinct的sql查询。
• 在kylin导入hive表时，kylin后台会运行mr任务计算每个列的基数，这里使用的是HyperLogLog的近似算法。

设计cube

cube构建步骤如下：

1. 创建临时的hive平表（从hive读取数据）。
2. 计算各维度不同值，并收集各cuboid的统计数据。
3. 创建并保存字典。
4. 保存cuboid统计信息。
5. 创建HTable。
6. 计算cube（若干轮mapreduce）。
7. 将Cube计算结果转成HFile。
8. 加载HFile到Hbase。
9. 更新Cube元数据。
10. 垃圾回收。
    前五步是为构建cube而做的准备，第六步才是真正意义上的构建，取决于cube构建的算法。因为cube是序列化存储在hdfs上的，所以需要转换到hbase存储的格式（HFile）。第八步使用的是Hbase BulkLoad工具将HFile批量导入hbase中，这一步完成后HTable就可以查询到数据了。第九步更新Cube，将NEW状态转变为READY，表示已经可供查询了。最后一步清理构建生成的一些临时文件，释放内存等集群资源。

增量构建和全量构建

• 全量构建
  对于模型中没有指定时间分割列的Cube，会将hive表中全部的数据进行构建。全量构建适用于以下情形：
  1. 事实表的数据不随着时间逐步增加的。
  2. 事实表数据很小或更新频率很小，全量构建不会造成太大开销的。
• 增量构建
  增量构建的时候，每次都会从hive拿取一定时间段的数据进行构建，每次构建开始时默认是从上一次构建的结束时间，一段时间构建以segment的形式存储，Cube会将多个segment按时间顺序进行排序，如：seg-1,seg-2,seg-3… 在查询的时候，Kylin会查询这些segment并对这些segment做聚合运算，以便返回正确的查询结果。
  使用增量构建的好处是只需要对这个时间段内的数据进行构建，从而避免了对历史数据的重复计算。对于数据量很大的Cube，增量构建是很有必要的。

  注意：
  增量构建的数据区间是前闭后开，即包含开始日期，不含结束日期。这样的话才能使上一次构建的结束日期和这次构建的起始日期相等但不会重复构建相同的数据。

增量构建遇到的场景问题及解决

• 在使用Retention Threshold的时候同时开启了Auto Merge Thresholds时，Auto Merge Thresholds设置的合并区间大于Retention Threshold保留区间；
  此时会导致新加入是segment受自动合并的影响，不断合并为越来越大的一个segment，并且会不断更新这个segment的结束时间，从而导致这个segment永远得不到释放。推荐自动合并的最大层级时间不要超过一年。

• 由于ETL *** 作的延迟，业务每天都要刷新过去N天的数据，这样很容易的解决办法就是每天增量构建一个一天的segment，但是随着时间的推移，每天构建一个segment会导致kylin任务队列囤积大量未完成的任务，每天构建还要手动refresh过去N天的segment，还有一个弊端就是对于超过N天的segment，管理员需要对其进行手动合并，但是合并时还需注意，如果手动将N天内的一个segment与前面的segment合并成了一个大的segment，这样一来除了需要刷新这N天的segment外还需对存在于那个大的segment的进行刷新，这样则会对整个大的segment再重新计算一遍，造成极大的浪费。
  解决办法：在新建segment的时候，不以日为单位，以N天为单位创建。设置segment最小长度为N。第一天构建即使没有后面几天的数据，依然能够成功构建，只是构建的数据只有这一天的数据。当N天过去后，又会创建一个新的长度为N的segment，这样就算第一天构建也只会需要更新前一个segment的数据，此时就只需要维护两个segment就可以了。

历史数据刷新

历史数据刷新是针对于增量构建的cube而言的，因为全量构建的cube每次构建都是全部的数据都会进行更新，而增量构架的cube历史数据是在不同的segment里面，所以需要先指定要更新的segment，然后再进行刷新。
segment刷新完毕会立即生效，查询得到的是最新的数据，旧的segment等待回收。

合并

随着时间的迁移，cube中会存在较多的segment，使得查询性能下降，且会对hbase集群带来压力。对此，需要适时地将一些segment进行和并。
合并的好处：

1. 合并相同的key，从而节省了cube的存储空间。
2. segment变少，因此可以减少查询时的二次聚合，提高了查询效率。
3. HTable的数量变少，利于集群的管理。

在合并的时候，会直接以当初构建时产生的cuboid文件为输入内容，从而不需要再从hive导入数据，接下来的构建和普通构建差不多。在新的HTable形成之前，旧的HTable不会被删除，从而保持数据时刻可以被查询。

Cube的剪枝优化

kylin核心的优势还是以额外的空间进行预计算来换取查询时间的缩短。而剪枝优化就是来减少额外的存储空间。
前提：不会影响太多查询性能
剪枝优化工具：

• 衍生维度
  衍生维度是在有效维度内将非主键维度排除掉，用维度表的主键（也就是事实表的外键）来代替它，kylin会在底层记录维度表主键和其他维度的映射关系，以便能在查询时将维度表的主键翻译成这些非主键维度，并实时聚合。
  具体 *** 作：在添加维度时选择derived而非normal。
  注意：如果维度表主键到非主键维度的聚合非常大的话，还是设置成normal比较好。

• 使用聚合组
  聚合组是根据业务需求将维度分为若干组或一个组，同一个组内的维度可能同时被同一个查询所用到，所以同一个组内的关系会表现得更加紧密。不同的分组可能会贡献相同的cuboid，构建引擎会注意到这一点，保证每个cuboid只会被物化一次。
  对于每个分组的内部维度，可以将他们的关系设置为以下三种：

1. 强制维度（Mendatory）
   如果一个维度被定义成了强制维度，那么这个组内产生的所有cuboid都应该包含这个维度，一个组内可以有若干个强制维度，且在过滤或分组条件中一定会出现这些强制维度。
2. 层级维度（Hierarchy）
   当一个组内的维度关系设置为层级维度，意味着这个组产生的cuboid都是以层级关系出现的。若组内层级维度有D1,D2,D3，则cuboid则为(),(D1)(D1,D2),(D1,D2,D3)这中n+1的形式出现。每个层级不应当有共享的维度。
3. 联合维度（Joint）
   每个联合中包含两个或多个维度，若组内某些列形成了一个联合，在该组产生的任意cuboid中，这些维度要么一起出现，要么都不出现。不同联合维度之间不应该有共享维度（否则就形成了联合）。

cube的查询

Cube构建完成后，状态变为READY，就可以进行查询了。

需要了解的是，只有当查询的模式跟Cube定义相匹配的时候，Kylin才能够使用Cube的数据来完成查询。Group By的列和Where条件里的列，必须是在Dimension中定义的列，而SQL中的度量，应该跟Cube中定义的度量相一致。
在一个项目下，如果有多个基于同一模型的Cube，而且它们都满足查询对表、维度和度量的要求；那么，Kylin会挑选一个“最优的”Cube来进行查询；这是一种基于成本（cost）的选择，Cube的成本计算中包括多方面的因素，例如Cube的维度数、度量、数据模型的复杂度等。查询引擎将为每个Cube为完成此SQL估算一个成本值，然后选择成本最小的Cube来完成此查询。

注意：

• kylin支持的sql是标准的sql，但是sql有很多变体，kylin支持的sql只是sql所有变体的一个子集。另外，kylin sql只支持select查询 *** 作，不支持插入、更新等 *** 作。

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

• Kylin使用Apache Calcite做SQL语法分析。Apache Calcite是一个开源的SQL引擎，它提供了标准SQL解析、多种查询优化和连接各种数据源的能力；Calcite项目在Hadoop中越来越引人注意，并且已被众多项目集成为SQL解析器。

快速开始

创建一个完整的cube流程：

1. 需要先从hive导入hive表，这些表存储的是一些基础的业务数据，在kylin导入hive表时，会同时执行几个mapreduce任务，来计算这些表每个列的基数。

这里计算基数的算法是采用的HyperLogLog算法，计算出来精度可能不是特别细，但是作为参考已经足够。

2. 创建model数据模型，数据模型是cube的基础，数据模型是一个星型模型的实现（也就是一张事实表多张维度表）。cube的构建可以直接在此模型中定义的表和列中进行选择，且可以根据一个model构建多个cube，从而减少了重复工作量。
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V4lrsm93-1641124574869)(en-resource://database/956:1)]
   model info
   写入model的标识名称和描述
   Data model
   选择一张事实表，可以点击Add Lookup Table来关联另一张维度表，并可以选择关联方式(inner join, left join)，在AS后面可以给关联表起一个别名。同时，点击new join condition按钮可以进行主外键关联，这里支持多主键。
   Dimentions
   维度。从这张表或关联的几张维度表的列中选出，但是选择这些列不代表将来一定会用作cube的维度，只是代表一个范围，后续cube选择维度将只能从这些列中选出。维度列可以从事实表和维度表中选出。
   Measures
   度量。只能从事实表中选出度量列。这里如上也是只代表一个范围，不代表cube度量列一定是这些，但是只能在这些列中进行选择。
   settings
   这里可以进行设置分割时间列和添加过滤条件。如果模型中的事实表中的记录是按照时间增长的话，可以选择一个日期or时间列作为分割时间列，在以后进行增量构建可以根据分割时间列来构建。
   过滤条件，可以像写sql时在where后面写的条件一样，kylin在hive表中获取源数据的时候会带上这个条件。

3. 创建cube
   创建cube的ui界面如下：
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4G3VPkj7-1641124574870)(en-resource://database/958:1)]
   第一栏 cubeinfo
   首先需要选择要使用的数据模型，填写cube的名称（必填）以及cube的描述（选填）。若要接收cube处于某种状态的邮件，可以在Nitification Events中填写响应邮件要发送的ip地址信息。
   第二栏 Dimensions
   这一栏为选择cube的维度。添加的维度有两种：normal(普通)和derived(衍生)维度。其中衍生维度必须来自于维度表，一次可以选择多个列，由于这些列值都可以从这个表的主键衍生出来，所以实际上只有主键会被cube加入计算，在kylin的具体实现中，kylin往往是用事实表的外键来代替主键进行计算和存储，但是在逻辑上是可以认为衍生列是来自于维度表的主键。
   第三栏 Measures
   这一栏为创建度量，一般会默认有一个count(1)的度量，可以手动添加度量，一般可供选择的度量类型为常见的聚合函数例如：SUM, TopN, RAW，MAX, COUNT, COUNT DISTINCT等。kylin支持可添加数百个的度量。
   第四栏 Refresh Setting
   这一栏是关于数据刷新的设置，在这里可以设置自动合并的阈值，数据保留的最短时间，以及第一个segment的起点（前提是有分割时间列）。
   Volatile Range栏的选项为强制合并设置天数的数据。
   第五栏 Advanced Setting
   这一栏为一些高级设置，可以设置聚合组和rowkey。
   kylin默认会将所有维度都放入同一个聚合组，如果维度数较多（如>10），则可以考虑新增聚合组自定义加入若干维度。通过增加聚合组，可以大大减少cuboid的数量。例如有m+n个维度，最终生成的cuboid数量为2m+n，通过新增聚合组后，分为两个不相交的聚合组，可以将cuboid数量减少为2m + 2^n。
   在单个聚合组中，可以对维度设置高级属性，如Mandatory、Hierarchy、Joint等。这几种都是为了优化cube计算而设计的。
   Mandatory维度指的是那些总是会出现在where或group by语句后面的维度，通过设置Mandatory维度，cube计算时就会跳过那些在where或group by语句后不包括这些维度的cuboid，从而减少计算量。
   Hierarchy维度是指一组有层级关系的维度，例如国家-省-市-区。在查询高级别的维度时，往往可以单独进行查询。但当查询低级别的维度时，则需要带上高级别的维度。通过设置这个维度组可以过滤掉不满足这个层级关系条件的cuboid。
   Joint是指将多个维度组合成一个维度。它通常适用于两种情形：
   1、这几个维度一般都参与过滤。
   2、维度基数低。
   kylin以key-value的形式将cube存入hbase中。hbase的key，也就是rowkey，是由多个维度拼接而形成的。为了提高在habse中的存储效率，kylin对维度提供了几种形式的编码。
   其中默认的编码格式为dict也就是字典编码。字典编码会将此维度下所有的值都映射成一张string2int的映射表。kylin会将这张映射表视为字典序列化保存，在cube中存储int值，从而大大减少cube的大小。而且在编码后任然是保持有序的，即在编码前，stringA比stringB大，在编码后，intA依然比intB大，这样的话，在hbase中对cube进行比较查询的话可以直接适用编码后的值，不需要进行解码。字典是非常适合于非固定长度的string类型的维度，从而可以不用指定编码后的长度。但字典编码往往意味着需要维护一张映射表，对于维度值基数很大的时候，这张映射表的大小是很可观的，且需要加载到内存显然不合适，这样的话就需要另辟蹊径。kylin默认字典可接受最大的维度基数为500w，可以通过’kylin.dictionary.max.cadinality‘进行设置。
   整数(int)编码，整数编码适应于那些对int或bigint数据类型进行编码，且没有额外的存储，能编码基数巨大的维度。一般需要根据维度的值域来设置编码的长度。例如电话号码，大小可以确定在231到239-1之间，那么使用int（5）就能解决。即编码占5字节，40位，能用于前面电话号码值那样长度的存储，且比字符存储11字节能缩小很大一部分空间占用。

   当上面所有编码都不适合的时候，就只能用固定长度编码了。这种编码方式没有额外的转》换，只是将原始值截断或补齐成相同长度的一组字节，所以空间效率较差，通常只是作为一种权宜手段。
   各维度在rowkey中的位置也对查询效率有所影响。我们可以点住id处进行拖拽调整维度所处的位置，通常需要将过滤频率高也就是在where或group by过滤条件后出现频繁的维度放上面，这样的话在hbase中就能减少频繁的维度在hbase中扫描的时间。从而提高查询效率。

   第六栏 Configuration Overwrites
   这一栏可以为cube配置参数，可以根据环境来灵活配置调优，提高效率。通常kylin的全局配置文件是在conf/kylin.properties处。若想对全局配置文件进行覆盖，可以在此处新增配置。

4. 构建cube
   历经以上步骤，新创建的cube只有定义，是没有数据的。它的状态为DISABLED，是不会被查询引擎挑中查询的。所以在创建好cube后，还需要对cube进行构建。对cube的构建分为增量和全量两种构建方式，具体细节可以看上述增量构建和全量构建。选择cube，点击bulid进行构建，此时会经过一轮或多轮mapreduce的计算最后数据和源数据存储在hbase中，此时就可以进行查询了。具体构建会执行如下步骤：
   1.建立hive平表（临时表），从hive拉取数据
   2.计算各维度的平均值，并收集cuboid统计数据
   3.创建并保存字典
   4.保存cuboid统计信息
   5.创建HTable
   6.计算cube（一轮或若干轮mapreduce）
   7.将cube的计算结果转成HFile
   8.加载HFile到Hbase
   9.更新cube元数据
   10.垃圾回收

附录

• 只要cube中有一个segment 就可以使用
  ./kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader CUBE_NAME
  CUBE_NAME -> 想要查看cube的名称
  来查看cuboid的状态。