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

Top_N度量优化

在生活中我们总能看到“世界500强公司” “销量最好的十款汽车”等标题的新闻报道，Top_N 分析是数据分析场景中常见的需求。在大数据时代，由于明细数据集越来越大，这种需求越来越明显。在没有预计算的情况下，得到一个分布式大数据集的 Top_N 结果需要很长时间，导致点对点查询的效率很低。

Kylin v1.5以后的版本中引入了 Top_N 度量，意在进行Cube 构建的时候预计算好需要的 Top_N，在查询阶段就可以迅速地获取并返回Top_N记录。这样，查询性能就远远高于没有Top_N预计算结果的Cube，方便分析师对这类数据进行查询。

注意　这里的 Top_N 度量是一个近似的实现，如你想要了解其近似度，需要在本节之后的内容中更多地了解 Top_N 背后的算法和数据分布结构。

让我们用Kylin中通过sample.sh生成的项目“learn_kylin” 对Top_N进行说明。我们将重点使用其中的事实表“kylin_sales”。

这张样例表 “default.kylin_sales” 模拟了在线集市的交易数据，内含多个维度和度量列。这里仅用其中的四列即可：“PART_DT” “LSTG_SITE_ID” “SELLER_ID”和“PRICE”。表3-1所示为这些列的内容和基数简介，显而易见 “SELLER_ID” 是一个高基列。

表3-1　样例表 “default.kylin_sales”的情况

列名	描述	基数
PART_DT	交易日期	730：两年
LSTG_SITE_ID	交易站点ID，如美国站用00代表	50
SELLER_ID	卖家ID	大约100万
PRICE	销售额	—

假设电商公司需要查询特定时段内，特定站点交易额最高的100位卖家。查询语句如下：

SELECT SELLER_ID, SUM(PRICE) FROM KYLIN_SALES
 WHERE
   PART_DT >= date'2012-02-18' AND PART_DT < date'2013-03-18'
      AND LSTG_SITE_ID in (0)
   group by SELLER_ID
   order by SUM(PRICE) DESC limit 100

方法1：在不设置Top_N度量的情况下，为了支持这个查询，在创建Cube时设计如下：定义“PART_DT”“LSTG_SITE_ID”“SELLER_ID”作为维度，同时定义 “SUM(PRICE) ”作为度量。Cube 构建完成之后，Base Cuboid 如表3-2所示。

表3-2　Cube 的Base Cuboid结构

Base Cuboid的RowKey	SUM(PRICE)
20120218_00_seller0000001	291.58
20120218_00_seller0000002	365.18
20120218_00_seller0000003	135.29
…
20120218_00_seller1000000	272.31
20120218_01_seller0000001	172.52
…

假设这些维度是彼此独立的，则Base Cuboid中行数为各维度基数的乘积：730 * 50 * 1 million = 36.5 billion = 365亿。其他包含“SELLER_ID”字段的Cuboid也至少有百万行。由此可知，由“SELLER_ID”作为维度会使得Cube的膨胀率很高，如果维度更多或基数更高，则情况更糟。但真正的挑战不止如此。

我们可能还会发现上面那个SQL查询并不能正常执行，或者需要花费特别长的时间，原因是这个查询拥有太大的在线计算量。假设你想查30天内site_00销售额排前100名的卖家，则查询引擎会从存储引擎中读取约3000万行记录，然后按销售额进行在线排序计算（排序无法用到预计算结果），最终返回排前100名的卖家。由于其中的关键步骤没有进行预计算，因此虽然最终结果只有100行，但计算耗时非常长，且内存和其中的控制器都在查询时被严重消耗了。

反思以上过程，业务关注的只是销售额最大的那些卖家，而我们存储了所有的（100万）卖家，且在存储时是根据卖家ID而不是业务需要的销售额进行排序的，因此在线计算量非常大，因而此处有很大的优化空间。

方法2：为了得到同一查询结果。如果在创建Cube时，对需要的Top_N进行了预计算，则查询会更加高效。如果在创建Cube时设计如下：不定义“SELLER_ID”为维度，仅定义“PART_DT”“LSTG_SITE_ID”为维度，同时定义一个Top_N度量，如图1所示。

图1　TOP\_N度量的设置示例

注意　“PRICE”定义在“ORDER|SUM by Column”，“SELLER_ID”定义在“Group by Column”。

新Cube的Base Cuboid 如表3-3所示，Top_N度量的单元格中存储了按seller_id进行聚合且按sum(price) 倒序排列的seller_id和sum(price)的组合。

表3-3　新Cube 的Base Cuboid结构

base cuboid的RowKey	Top_N Measure
20120218_00	seller0010091:1092.21, seller0005002:1090.35, …, seller0001789:891.37
20120218_01	seller0003012:xx.xx seller0004001:xx.xx, …, seller000699: xx.xx
20120218_02	…
…	…
20120218_50	…
20120219_01	seller0010091:1012.74, seller0005002:1032.63 …, seller0001981:883.57
…	…

现在Base Cuboid中只有730 * 50 = 36500行。在度量的单元格中，预计算的Top_N结果以倒序的方式存储在一个容器中，而序列尾端的记录已经被过滤掉。

现在，对于上面那个Top_100 seller的查询语句，只需要从内存中读取30行，Kylin将会从Top_N Measure的容器中抽出“SELLER_ID”和“SUM(PRICE)”，然后将其返回客户端（并且是已经完成排序的）。现在查询结果就能以亚秒级返回了。

一般来说，Kylin在Top_N的单元格中会存储100倍的Top_N定义的返回类型的记录数，如对于Top100，就存储10000条seller00xxxx:xx.xx记录。这样一来，对于Base Cuboid的Top_N查询总是精确的，不精确的情况会出现在对于其他Cuboid的查询上。举例来说，对于Cuboid[PART_DT]，Kylin会将所有日期相同而站点不同的TOP_N单元格进行合并，这个合并后的结果会是近似的，尤其是在各个站点的前几名卖家相差较多的情况下。比如，如果site_00中排第100名的卖家在其他站点中都排在第10000名以后，那么它的Top_N记录在其他站点都会被舍去，Kylin在合并TOP_N Measure时发现其他站点里没有这个卖家的值，于是会赋予这个卖家在其他站点中的sum（price）一个估计值，这个估计值既可能比实际值高，也可能比实际值低，最后它在Cuboid[PART_DT]中的Top_N单元格中存储的是一个近似值。

图书简介：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 优化

创作场景

Apache Kylin 权威指南（九）：Top_N 度量优化