编者按：本文节选自华章科技大数据技术丛书《Apache Kylin权威指南(第2版)》一书中的部分章节。

Rowkey优化

前面章节的侧重点是减少Cube中Cuboid的数量，以优化Cube的存储空间和构建性能，统称以减少Cuboid的数量为目的的优化为Cuboid剪枝。在本节中，将重点通过对Cube的Rowkey的设置来优化Cube的查询性能。

Cube的每个Cuboid中都包含大量的行，每个行又分为Rowkey和Measure两个部分。每行Cuboid数据中的Rowkey都包含当前Cuboid中所有维度的值的组合。Rowkey中的各个维度按照Cube Designer→Advanced Setting→RowKeys中设置的顺序和编码进行组织，如图1所示。

图1　Rowkey的设置页面

在Rowkeys设置页面中，每个维度都有几项关键的配置，下面将一一道来。

调整Rowkey顺序

在Cube Designer→Advanced Setting→Rowkeys部分，可以上下拖动每一个维度来调节维度在Rowkey中的顺序。这种顺序对于查询非常重要，因为目前在实现中，Kylin会把所有的维度按照显示的顺序黏合成一个完整的Rowkey，并且按照这个Rowkey升序排列Cuboid中所有的行，参照前一章的图16。

不难发现，对排序靠前的维度进行过滤的效果会非常好，比如在图16中的Cuboid中，如果对D1进行过滤，它是严格按照顺序进行排列的；如果对D3进行过滤，它仅是在D1相同时在组内顺序排列的。

如果在一个比较靠后的维度进行过滤，那么这个过滤的执行就会非常复杂。以目前的HBase存储引擎为例，Cube的Rowkey就对应HBase中的Rowkey，是一段字节数组。我们目前没有创建单独的每个维度上的倒排索引，因此对于在比较靠后的维度上的过滤条件，只能依靠HBase的Fuzzy Key Filter来执行。尽管HBase做了大量相应的优化，但是在对靠后的字节运用Fuzzy Key Filter时，一旦前面维度的基数很大，Fuzzy Key Filter的寻找代价就会很高，执行效率就会降低。所以，在调整Rowkey的顺序时需要遵循以下几个原则：

有可能在查询中被用作过滤条件的维度，应当放在其他维度的前面。

a) 对于多个可能用作过滤条件的维度，基数高的（意味着用它进行过滤时，较多的行被过滤，返回的结果集较小）更适合放在前面；

b) 总体而言，可以用下面这个公式给维度打分，得分越高的维度越应该放在前排：

排序评分=维度出现在过滤条件中的概率*用该维度进行过滤时可以过滤掉的记录数。
将经常出现在查询中的维度，放在不经常出现的维度的前面，这样，在需要进行后聚合的场景中查询效率会更高。
对于不会出现在过滤条件中的维度，按照其基数的高低，优先将低基数的维度放在Rowkey的后面。这是因为在逐层构建Cuboid、确定Cuboid的生成树时，Kylin会优先选择Rowkey后面的维度所在的父Cuboid来生成子Cuboid，那么基数越低的维度，包含它的父Cuboid的行数就越少，聚合生成子Cuboid的代价就越小。

选择合适的维度编码

2.4.3节介绍过，Apache Kylin 支持多种维度编码方式，用户可以针对数据特征，选择合适的编码方式，从而减小数据的存储空间。在具体使用过程中，如果用错了编码方式，可能会导致构建和查询的一系列问题。这里要注意的事项包括：

字典（Dictionary）编码（默认的编码）不适用于高基数维度（基数值在300万以上）。主要原因是，字典需要在单节点内存中构建，并在查询的时候加载到Kylin内存；过大的字典不但会使得构建变慢，还会在查询时占用很多内存，导致查询缓慢或失败，因此应该避免对高基数维度使用字典编码。如果实际中遇到高基数维度，首先思考此维度是否要引入Cube中，是否应该先对其进行泛化（Generalization），使其变成一个低基数维度；其次，如果一定要使用，那么可以使用Fixed_length编码，或Integer（如果这列的值是整型）编码。
Fixed_length编码是最简单的编码，它通过补上空字符（如果维度值长度小于指定长度））或截断（如果维度值长度大于指定长度），从而将所有值都变成等长，然后拼接到Rowkey中。它比较适合于像身份证号、手机号这样的等长值维度。如果某个维度长度变化区间比较大，那么你需要选择一个合适的长度：长度过短会导致数据截断从而失去准确性，长度过长则导致空间浪费。

按维度分片

在3.3节中介绍过，系统会对Cuboid中的数据在存储时进行分片处理。默认情况下，Cuboid的分片策略是对于所有列进行哈希计算后随机分配的。也就是说，我们无法控制Cuboid的哪些行会被分到同一个分片中。这种默认的方法固然能够提高读取的并发程度，但是它仍然有优化的空间。按维度分片提供了一种更加高效的分片策略，那就是按照某个特定维度进行分片（Shard By Dimension）。简单地说，当你选取了一个维度用于分片后，如果Cuboid中的某两行在该维度上的值相同，那么无论这个Cuboid最终被划分成多少个分片，这两行数据必然会被分配到同一个分片中。

这种分片策略对查询有着极大的好处。我们知道，Cuboid的每个分片会被分配到存储引擎的不同物理机器上。Kylin在读取Cuboid数据的时候会向存储引擎的若干机器发送读取的RPC请求。在RPC请求接收端，存储引擎会读取本机的分片数据，并在进行一定的预处理后发送RPC回应（如图2所示）。以HBase存储引擎为例，不同的Region代表不同的Cuboid分片，在读取Cuboid数据的时候，HBase会为每个Region开启一个Coprocessor实例来处理查询引擎的请求。查询引擎将查询条件和分组条件作为请求参数的一部分发送到Coprocessor中，Coprocessor就能够在返回结果之前对当前分片的数据做一定的预聚合（这里的预聚合不是Cube构建的预聚合，是针对特定查询的深度的预聚合）。

图2　存储引擎执行RPC查询

如果按照维度划分分片，假设是按照一个基数比较高的维度seller_id进行分片的，那么在这种情况下，每个分片承担一部分seller_id，各个分片不会有相同的seller_id。所有按照seller_id分组（group by seller_id）的查询都会变得更加高效，因为每个分片预聚合的结果会更加专注于某些seller_id，使得分片返回结果的数量大大减少，查询引擎端也无须对各个分片的结果做分片间的聚合。按维度分片也能让过滤条件的执行更加高效，因为由于按维度分片，每个分片的数据都更加“整洁”，便于查找和索引。

图书简介：https://item.jd.com/12566389.html

相关阅读：

Apache Kylin权威指南（一）：背景历史和使命

Apache Kylin权威指南（二）：工作原理

Apache Kylin权威指南（三）：技术架构

Apache Kylin权威指南（四）：核心概念

Apache Kylin权威指南（五）：Getting Started

Apache Kylin权威指南（六）：Cuboid剪枝优化

Apache Kylin权威指南（七）：剪枝优化工具

创作场景

Apache Kylin 权威指南（八）：Rowkey 优化