apachekylin（apache kylin 400）

by intanet.cn ca 大数据 on 2024-03-20

本篇文章给大家谈谈apachekylin，以及apache kylin 400对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

1、大数据分析界的“神兽”Apache Kylin有多牛
2、Kylin#Apache Kylin Cube增量构建(四)
3、Apache Kylin在美团数十亿数据OLAP场景下的实践
4、Cognos 通过ODBC连接Apache kylin 的注意事项

大数据分析界的“神兽”Apache Kylin有多牛

1.Apache Kylin是什么？

在现在的大数据时代，越来越多的企业开始使用Hadoop管理数据，但是现有的业务分析工具（如Tableau，Microstrategy等）

往往存在很大的局限，如难以水平扩展、无法处理超大规模数据、缺少对Hadoop的支持；而利用Hadoop做数据分析依然存在诸多障碍，例如大多数分析

师只习惯使用SQL，Hadoop难以实现快速交互式查询等等。神兽Apache Kylin就是为了解决这些问题而设计的。

Apache Kylin，中文名麒（shen）麟（shou）是Hadoop动物园的重要成员。Apache

Kylin是一个开源的分布式分析引擎掘前神，最初由eBay开发贡献至开源社区。它提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持大

规模数据，能够处理TB乃至PB级别的分析任务，能够在亚秒级查询巨大的Hive表，并支持高并发。

Apache

Kylin于2014年10月在github开源，并很快在2014年11月加入Apache孵化器，于2015年11月正式毕业成为Apache顶级项

目，也成为首个完全由中国团队设计开发的Apache顶级项目。于2016年3月，Apache

Kylin核心开发成员创建了Kyligence公司，力求更好地推动项目和社区的快速发展。

Kyligence是一家专注于大数据分析领域创新的数据科技公司，提供基于Apache

Kylin的企业级智能分析平台及产品，以及可靠、专业、源码级的商业化支持；并推出Apache Kylin开发者培训，颁发全球唯一的Apache

Kylin开发者认证证书。

2.Kylin的基本原理和架构

下面开始聊一聊Kylin的基本原理和架构判亏。简单来说，Kylin的核心思想是预计算，即对多维分析可能用到的度量进行预计算，将计算好的结果保

存成Cube，供查询时直接访问。把高复杂度的聚合运算、多表连接等操作转换成对预计算结果的查询，这决定了Kylin能够拥有很好的快速查询和高并发能

力。

上图所示就是一个Cube的例子，假设我们有4个dimension，这个Cube中每个节点（称作Cuboid）都是这4个dimension

的不同组合，每个组合定义了一组分析的dimension（如group

by），measure的聚合结果就保存在这每个Cuboid上。查询时根据SQL找到对应的Cuboid，读取measure的值，即可返回。

为了更好的适应大数据环境，Kylin从数据仓库中最常用的Hive中读取源数据，使用

MapReduce作为Cube构建的引擎，并把预计算结果保存在HBase中，对外暴露Rest

API/JDBC/ODBC的查询接口。因为Kylin支持标准的ANSI

SQL，所以可以和常用分析工具（如Tableau、Excel等）进行无缝对接。下面是Kylin的架构图。

说到Cube的构建，Kylin提供了一个称作Layer Cubing的算法。简单来说，就是按照dimension数量从大到小的顺序，从Base

Cuboid开始，依次基于上一层Cuboid的结果进行再聚合。每一层的计算都是一个单独的Map Reduce任务。如下图所示。

MapReduce的计算结果最终保存到HBase中，HBase中每行记录的Rowkey由dimension组成，measure会保存在

column

family中。为了减小存储代价，这里会对dimension和measure进行编码。查询阶段，利用HBase列存储的特性就可以保证Kylin有

良好的快速响应和高并发。

有了这些预计算的结果，当收到用户的SQL请求，Kylin会对SQL做查询计划，并把本该进行的Join、Sum、Count Distinct等操作改写成Cube的查询操作。

Kylin提供了一个原生的Web界面，在这里，用户可以方便的创建和设置Cube、管控Cube构建进度，并提供SQL查询和基本的结果可视化。

根据公开数据显示，Kylin的查询性能不只是针对个别SQL，而是对上万种SQL 的平悔咐均表现，生产环境下90%ile查询能够在在3s内返回。在上个月举办的Apache Kylin

Meetup中，来自美团、京东、百度等互联网公司分享了他们的使用情况。例如，在京东云海的案例中，单个Cube最大有8个维度，最大数据条数4亿，最

大存储空间800G，30个Cube共占存储空间4T左右。查询性能上，当QPS在50左右，所有查询平均在200ms以内，当QPS在200左右，平均

响应时间在1s以内。

北京移动也在meetup上展示了Kylin在电信运营商的应用案例，从数据上看，Kylin能够在比Hive/SparkSQL在更弱的硬件配置下获得更好的查询性能。目前，有越来越多的国内外公司将Kylin作为大数据生产环境中的重要组件，如ebay、银联、百度、中国移动等。大家如果想了解更多社区的案例和动态，可以登录Apache Kylin官网或Kyligence博客进行查看。

3.Kylin的最新特性

Kylin的最新版本1.5.x引入了不少让人期待的新功能，可扩展架构将Kylin的三大依赖（数据源、Cube引擎、存储引

擎）彻底解耦。Kylin将不再直接依赖于Hadoop/HBase/Hive，而是把Kylin作为一个可扩展的平台暴露抽象接口，具体的实现以插件的

方式指定所用的数据源、引擎和存储。

开发者和用户可以通过定制开发，将Kylin接入除Hadoop/HBase/Hive以外的大数据系统，比如用Kafka代替Hive作数据源，用

Spark代替MapReduce做计算引擎，用Cassandra代替HBase做存储，都将变得更为简单。这也保证了Kylin可以随平台技术一起演

进，紧跟技术潮流。

在Kylin

1.5.x中还对HBase存储结构进行了调整，将大的Cuboid分片存储，将线性扫描改良为并行扫描。基于上万查询进行了测试对比结果显示，分片的存

储结构能够极大提速原本较慢的查询5-10倍，但对原本较快的查询提速不明显，综合起来平均提速为2倍左右。

除此之外，1.5.x还引入了Fast

cubing算法，利用Mapper端计算先完成大部分聚合，再将聚合后的结果交给Reducer，从而降低对网络瓶颈的压力。对500多个Cube任务

的实验显示，引入Fast cubing后，总体的Cube构建任务提速1.5倍。

目前，社区正在着手准备Apache Kylin 1.5.2版本的发布，目前正处于Apache Mailing list投票阶段，预计将会在本周在Kylin官网发布正式下载。

在本次的1.5.2版本中，Kylin带来了总计

36个缺陷修复、33个功能改进、6个新功能。一些主要的功能改进包括对HyperLogLog计算效率的提升、在Cube构建时对Convert

data to hfile步骤的提速、UI上对功能提示的体验优化、支持hive view作为lookup表等等。

另一个新消息是Kylin将支持MapR和CDH的Hadoop发行版，具体信息可见KYLIN-1515和KYLIN-1672。相应的测试版本是MapR5.1和CDH5.7。

UI上提供了一个重要更新，即允许用户在Cube级别进行自定义配置，以覆盖kylin.properties中的全局配置。如在cube中定义kylin.hbase.region.count.max 可以设置该cube在hbase中region切分的最大数量。

另

一个重要的功能是Diagnosis。用户经常会遇到一些棘手的问题，例如Cube构建任务失败、SQL查询失败，或Cube构建时间过长、SQL查询时

间过长等。但由于运维人员对Kylin系统了解不深，很难快速定位到root cause所在地。我们在mailing

list里也经常看到很多用户求助，由于不能提供足够充分的信息，社区也很难给出一针见血的建议。

当用户遇到查询、Cube/Model管理的问题，单击System页面的Diagnosis按钮，系统会自动抓取当前Project相关的信息并打包成

zip文件下载到用户本地。这个包会包含相关的Metadata、日志、HBase配置等。当用户需要在mailing

list求助，也可以附上这个包。

Kylin#Apache Kylin Cube增量构建(四)

全量构建可以看作增量构建的一种特例：在全量构建中，Cube中只存在唯一的一个Segment，该Segment没有分割时间的概念，因此也就没有起始时间和结束时间。全量构建和增量构建各有适用的场景，用户可以根据自己的业务场景灵活切换

(注意更新俩字的含义,kylin是不保存历史状态的,如果是增量更新就是更新指定的时间区间)

整体来说，增量构建的Cube上的查询会比全量构建Cube上的查询做更多的正颤运行时聚合，而这些运行时聚合都发生在单点的查询引擎上，因此，通常来说，增量构建的Cube上的查询会比全量构建的Cube上的查询慢一些。

对于小数据量的Cube或经常需要全表更新的Cube，使用全量构建可以以少量的重复计算降低生产环境中的维护复杂度，减少运维精力。而对于大数据量的Cube，如一个包含两年历史数据的Cube，如果使用全量构建每天更新数据，那么每天为了新数据而重复计算过去两年的数据会严重增加查询成本，在这种情况下需要考虑使用增量构建。

(这里对如慧每日新举橡败增的描述,是每日新增,但是对于拉链表来说也是每日新增,那么应该如何选择??)

并非所有的Cube都适合进行增量构建，Cube的定义必须包含一个时间维度，用来分割不同的Segment，我们将这样的维度称为分割时间列（Partition Date Column）。尽管由于历史原因该命名中存在“date”字样，但是分割时间列可以是Hive中的Date类型、Timestamp类型还可以是String类型。无论是哪种类型，Kylin都要求用户显式地指定分割时间列的数据格式。

满足了设计增量Cube的条件之后，在进行增量构建时将增量部分的起始时间和结束时间作为增量构建请求的一部分提交给Kylin的任务引擎，任务引擎会根据起始时间和结束时间从Hive中抽取相应时间的数据，并对这部分数据做预计算处理，然后将预计算的结果封装成新的Segment，保存相应的信息到元数据和存储引擎中。一般来说，增量部分的起始时间等于Cube中最后一个Segment的结束时间。

(对于动态分区表来说,我们并不遵守这规范)

在Web GUI上触发Cube的增量构建与触发全量构建的方式基本相同。在Web GUI的Model页面中，选中想要增量构建的Cube，点击“Action”→“Build”命令

增量构建的Cube每天都可能还有新的增量，这样的Cube日积月累最终可能包含上百个Segment，导致运行时的查询引擎需要聚合多个Segment的结果才能返回正确的查询结果，最终会使查询性能受到严重的影响。从存储引擎的角度来说，大量的Segment会带来大量的文件，这些文件会充斥系统为Kylin所提供的命名空间，给存储空间的多个模块带来巨大的压力，如Zookeeper、HDFS Namenode等。在这种情况下，我们有必要采取措施控制Cube中Segment的数量，如可以自动/手动合并Segment、清理老旧无用的Segment。

Kylin提供了一种简单的机制来控制Cube中Segment的数量——合并Segment。在Web GUI中选择需要进行Segment合并的Cube，点击“Action→Merge”命令，然后在对话框中选择需要合并的Segment，可以同时合并多个Segment，但是这些Segment必须是连续的。

在Cube Designer的“Refresh Settings”的页面中有“Auto Merge Thresholds”“Volatile Range”和“RetentionThreshold”三个设置项可以用来帮助管理Segment碎片。虽然这三项设置还不能完美地解决所有业务场景的需要，但是灵活地搭配使用这三项设置可以大大减少对Segment进行管理的工作量

“Auto Merge Thresholds”允许用户设置几个层级的时间阈值，层级越靠后，时间阈值越大。举例来说，用户可以为一个Cube指定层级（7天、28天），每当Cube中有新的Segment状态变为“READY”的时候，会触发一次系统自动合并的尝试。系统首先会尝试最大一级的时间阈值，结合上面例子中设置的层级（7天、28天），系统会查看是否能把连续的若干个Segment合并成一个超过28天的较大Segment，在挑选连续Segment的过程中，如果有的Segment本身的时间长度已经超过28天，那么系统会跳过该Segment，从它之后的Segment中挑选连续的累计超过28天的Segment。当没有满足条件的连续Segment能够累计超过28天时，系统会使用下一个层级的时间阈值重复此寻找的过程。每当有满足条件的连续Segment被找到，系统就会触发一次自动合并Segment的构建任务，在构建任务完成后，新的Segment被设置为“READY”状态，自动合并的整个尝试过程则需要重新执行。

从碎片管理的角度来说，自动合并是将多个Segment合并为一个Segment，以达到清理碎片的目的。保留Segment从另一个角度帮助实现了碎片管理，那就是及时清理不再使用的Segment。在许多业务场景中只会对过去一段时间内的数据进行查询，如对于某个只显示过去1年数据的报表，支持它的Cube，事实上，只需要保留过去一年的Segment。由于数据往往在Hive中已经备份，因此无须再在Kylin中备份超过一年的历史数据。

在这种情况下，我们可以将“Retention Threshold”设置为“365”。每当有新的Segment状态变为“READY”的时候，系统会检查每一个Segment：如果它的结束时间距离最晚的一个Segment的结束时间已经大于“Retention Threshold”，那么这个Segment将被视为无须保留，且系统会自动从Cube中删除这个Segment。

如果启用了“Auto Merge Thresholds”，使用“RetentionThreshold”的时候需要注意，不能将“Auto Merge Thresholds”的最大层级设置得太高。假设我们将“Auto Merge Thresholds”的最大一级设置为“1000”天，而“Retention Threshold”为“365”天，那么受自动合并的影响，新加入的Segment会不断地被自动合并到一个越来越大的Segment之中，更糟糕的是，这会不断地更新这个大Segment的结束时间，最终导致这个大Segment永远不会被释放。因此，推荐自动合并的最大一级的时间不要超过1年。

（这个自动合并是怎么做到的???）

在实际应用场景中，我们常常遇到这样的问题：由于ETL过程的延迟，业务需要每天刷新过去N天的Cube数据。举例来说，客户有一个报表每天都需要更新，但是每天源数据的更新不仅包含当天的新数据，还包括了过去7天数据的补充。一种比较简单的方法是，每天在Cube中增量构建一个长度为一天的Segment，这样过去7天的数据会以7个Segment的形式存在于Cube之中。Cube的管理员除了每天创建一个新的Segment代表当天的新数据（BUILD操作）以外，还需要对代表过去7天的7个Segment进行刷新（REFRESH操作，Web GUI上的操作及REST API参数与BUILD类似，这里不再详细展开）。这样的方法固然有一定的作用，但是每天为每个Cube触发的构建数量太多，容易造成Kylin的任务队列堆积大量未能完成的任务

上述方案的另一个弊端是每天一个Segment会使Cube中迅速累积大量的Segment，需要Cube管理员手动地对超过7天的Segment进行合并，期间还必须避免将7天的Segment一起合并了。举例来说，假设现在有100个Segment，每个Segment代表过去的一天的数据，Segment按照起始时间排序。在合并时，我们只能挑选前面93个Segment进行合并，如果不小心把第94个Segment也一起合并了，当我们试图刷新过去7天（94-100）的Segment时，会发现为了刷新第94天的数据，不得不将1~93的数据一并重新进行计算，因为此时第94天的数据已经和1～93这93天的数据糅合在一个Segment之中了，这是一种极大的资源浪费。更糟糕的是，即使使用之前介绍的自动合并的功能，类似的问题也仍然存在,但在Kylin v2.3.0及之后的版本中，增加了一种机制能够阻止自动合并试图合并近期N天的Segment，那就是“Volatile Range”。

“Volatile Range”的设置非常简单，在Cube Designer的“Refresh Setting”中，在“Volatile Range”后面的文本框中输入最近的不想要合并的Segment的天数。举个例子，如果设置“VolatileRange”为“2”，“Auto Merge Thresholds”为“7”，现有01-01到01-08的数据即8个Segment，自动合并不会被开启，直到01-09的数据进来，才会触发自动合并，将01-01到01-07的数据合并为一个Segment。

(不是很明白,假设我有一个cube我每天都更新最近60天的数据,那么我应该如何设置合并)

Apache Kylin在美团数十亿数据OLAP场景下的实践

美团各业务线存在大量的OLAP分析场景，需要基于Hadoop数十亿级别的数据进行分析，直接响应分析师和城市BD等数千人的交互式访问请求，对OLAP服务的扩展性、稳定性、数据精确性和性能均有很高要求。本文主要介绍美团的具体OLAP需求，如何将Kylin应用到实际场景中，以及目前的使用方式和现状。同时也将Kylin和其它系统（如Presto、Druid等）进行了对比，阐述了Kylin的独特优势。

作为公司的平台部门，需要给各个业务线提供平台的服务，那么如何建设一个满足各种需求的公司平台级OLAP分析服务呢。首先，一个开源项目在公司真正落地会遇到很多障碍，这主要是由各个业务线不同的数据特点和业务特点决定的，所以本文会介绍一下美团的数据场景有什么特点；其次，针对这些数据特点，尤其是和Kylin设计初衷不太相符的部分，有什么样的解决方案；第三，目前OLAP领域还没有所谓事实上的标准，很多引擎都可以做类似事情，比如普通的MPP，Kylin，或者ES等。这些系统之间的对比情况如何，应该如何选择，我们也有部分测试数据可以分享巧绝；最后，简单讨论一下未来准备在Kylin上做的工作。

1、美团的数据场景特点

第一个特点是数据规模和模型特点。一方面从数据规模上来讲，事实表一般在1亿到10亿量级，同时还有千万量级的维表，也就是超高基数的维表。另一方面，数据模型是一开始遇到的最大困难。因为Kylin最初的设计是基于一个星形模型的，但很不幸由于各种原因，很多数据都是雪花的模型，还有其它的模型，比如所谓“星座”模型，也就是中间是两张或者三张事实表，周围关联了其它很多维表。业务逻辑决定了这些数据的关联方式非常复杂，根本无法用经典标准的理论来解释。

第二个是维度。维度最理想的情况是固定的，每天变化的只是事实表。但实际上维度经常会变，这可能和行业特点有关，比如组织架构，相关的维度数据可能每天都会变化。除此之外还可能要用今天的维度去关联所有的历史数据，因此要重刷历史数据，相应的开销也比较大。

第三个是数据回溯的问题。比如发现数据生成有问题，或者上游出错了，此时就需要重跑数据。这也是和经典理论模型有区别的。

从维度的角度来看，一般维度的个数在5-20个之间，相对来说还是比较适合用Kylin的。另一个特点是一般都会有一个日期维度，有可能是当天，也有可能是一个星期，一个月，或者任意一个时间段。另外也会有较多的层次维度，比如组织架构从最上面的大区一直到下面的蜂窝，就是一个典型的层次维度。

从指标的角度来搭态讲，一般情况下指标个数在50个以内孝枝姿，相对来说Kylin在指标上的限制并没有那么严格，都能满足需求。其中有比较多的表达式指标，在Kylin里面聚合函数的参数只能是单独的一列，像sum(if…)这种就不能支持，因此需要一些特别的解决方法。另外一个非常重要的问题是数据的精确性，目前在OLAP领域，各个系统都是用hyperloglog等近似算法做去重计数，这主要是出于开销上的考虑，但我们的业务场景要求数据必须是精确的。因此这也是要重点解决的问题。

在查询上也有比较高的要求。因为平台的查询服务可能直接向城市BD开放，每次会有几十、上百万次的访问，所以稳定性是首先要保证的。第二要求有很高的性能。因为用Kylin主要是为了实现交互式的分析，让使用者能够很快拿到结果，所以需要秒级响应。

另外经常会有人问到，Kylin有没有可视化的前端，在我们内部更多是由业务方来做，因为原来本身就有这样的系统，以前接的是MySQL等其它的数据源，现在可以直接使用Kylin的JDBC driver对接起来。

以上是美团在OLAP查询方面的一些特点。在用Kylin之前，实际上有一些方案，但效果并不理想。比如用Hive直接去查，这种情况下，第一个是慢，第二会消耗计算集群的资源。尤其每个月第一天，大家都要出月报，跑的SQL非常多，全提到集群上去，并发度限制导致跑的比平时更慢。我们原来也做过预聚合的尝试，这个思路跟Kylin很像，只不过是自己做这个事，用Hive先把所有的维度算出来，然后导入MySQL或者HBase。但是这个方案并没有像Kylin这么好的模型定义抽象，也没有从配置到执行，预计算，查询这样整体的框架。现在通过使用Kylin实现了低成本的解决这些问题。

2、接入Apache Kylin的解决方案

针对上述的问题，经过大量的尝试和验证，目前主要的解决方案有以下几点。

最重要的第一点，就是采用宽表。所有非标准星型的数据模型，都可以通过预处理先拉平，做成一个宽表来解决。只要能根据业务逻辑把这些表关联起来，生成一张宽表，然后再基于这张表在Kylin里做数据的聚合就可以了。宽表不只能解决数据模型的问题，还能解决维度变化、或者超高基数的维度等问题。

第二点是表达式指标的问题，也可以通过提前处理解决。把表达式单独转成一列，再基于这列做聚合就可以了。实际上宽表和表达式变换的处理可以用hive的view，也可以生成物理表。

第三个是精确去重的问题，目前的方案是基于Bitmap。由于数据类型的限制，目前只支持int类型，其它包括long、string等类型还不支持。因为需要把每个值都能映射到Bitmap里,如果是long的话开销太大。如果用哈希的话就会冲突，造成结果不准确。另外Bitmap本身开销也是比较大的，尤其跑预计算的时候，如果算出来的基数很大，对应的数据结构就是几十兆，内存会有OOM的风险。这些问题后面我们也会想一些办法解决，也欢迎在社区里一起讨论。（补充说明：目前已在1.5.3版本中实现了全类型精确去重计数的支持。）

从整个系统的部署方式上来说，目前Server采用了分离部署的方式。Kylin Server本质上就是一个客户端，并不需要太多资源，一般情况下使用虚拟机就能够满足需求。

实际的部署情况可以看这张图，左下角的是hadoop主集群，用于执行每天所有hadoop作业。中间最重要的是Kylin01和02这两个server，是用于线上环境的serve。其中kylin01是生产环境，这个环境一方面要负责从主机群上跑计算，把数据导到HBase，另外也要响应前端的请求，从HBase里读数据。如果想新增一个Cube的话，需要在kylin02上操作，也就是预上线环境。所有业务方人员的cube数据模型定义都是在kylin02上做，没有问题后由管理员切到kylin01上。

这样做的一个好处是kylin01作为一个线上服务能保证稳定性，甚至权限控制能更严格一些；第二，预上线环境下开发完成后，管理员可以在投入生产前进行一次review，保证cube的效率。

右上角是另外的调度系统。整个数据仓库的数据生产都是通过这个调度系统来调度的，其中的任务类型很多，Kylin的cube build任务也是作为其中的一种类型。在上游的数据就绪以后，根据配置的依赖关系，自动触发Cube建立的过程。

左上角这边还有一个完全独立的线下测试集群，这个集群是完全开放的，主要是给用户做一些最开始的可行性调研或者评估的工作，但同时也不保证稳定性。

一个开源的系统从社区拿回来，到真正的落地，再到上生产，这个过程相对还是比较长的，这里并没有太多的技术问题，更多的是一些流程上的经验。就是如何在各个阶段给业务方提供更好的服务，使得接入Kylin的过程更顺畅，沟通成本更低。整个过程主要分为四个阶段。

第一个阶段是方案选型，业务方根据业务需求，选择一些方案进行调研。我们在这个阶段提供了需求的Checklist，从数据模型，维度各个方面列出来比较详细的点，可以让业务方自己对照，确定需求是不是能够被满足。

在确定Kylin能满足需求的基础上，接下来是第二步，线下探查，也就是线下评估或者测试。我们提供了非常详细的接入文档，以及线下测试的环境。第三步是线上开发，我们也有一些文档支持，基于抽象出来的场景，每个场景怎么配置Cube，或者做哪些预处理，如何优化等，能够给业务方一个指导性的意见。

最后是开发完成后的切表上线。这个过程目前还是由管理员来操作，一方面是为了避免误操作或者滥操作，另一方面也会对cube进行review，帮助进行优化。

3、主流OLAP系统对比分析

通过和其它同学交流，有一个感觉就是大家都觉得Kylin还不错，但并不是特别有信心，或者不知道非要用它的理由是什么，或者它和其它系统的对比是什么样的？这里也有部分测试结果可以和大家分享。

整个测试基于SSB的数据集，也是完全开源的，实际上是专门用于星型模型OLAP场景下的测试。整个测试数据集是非常标准的五张表，可以配置一些参数决定生成的数据集规模，然后在不同的规模下做不同查询场景的测试。现在已经完成的测试的系统包括：Presto，Kylin1.3，Kylin1.5和Druid。数据规模包含千万、亿、十亿三种规模；维度个数为30个；指标个数为50个。典型的测试场景包括：上卷、下钻，和常用的聚合函数。

这里挑选了典型的五个查询场景：一个事实表的过滤和聚合；五张表全关联之后的查询；两个Count Dstinct指标和两个Sum指标；后面两个查询包含8~10个的维度过滤。

这张图是千万规模下的一个测试结果，包括了四个系统。我们在用Kylin或者其它系统之前没有专门用于OLAP分析的引擎，只能用通用的。Presto是其中表现非常好的引擎，但是在OLAP这种特定的场景下，可以看到不管跟Kylin还是Druid相比差的都比较多，所以前两个测试包含了Presto结果，后面就没有包含了。

这里比较有趣的现象是在第三个查询，Kylin1.5反而比Kylin1.3要慢一些。这个地方我们还没有搞清楚是什么原因，后面会详细的看一下。当然这个也可以证明数据没有修改过，是真实的测试数据。

从后面的两个查询上可以看到，在千万规模的级别，和Druid还是有比较大的差距。这主要和它们的实现模式相关，因为Druid会把所有的数据预处理完以后都加载到内存里，在做一些小数据量聚合的时候，可以达到非常快的速度；但是Kylin要到HBase上读，相对来说它的性能要差一些，但也完全能满足需求。

在亿级的规模上情况又有了变化，还是看后面两个查询，Kylin1.3基本上是一个线性的增长，这个数据已经变得比较难看了，这是由于Kylin1.3在扫描HBase的时候是串行方式，但是Kylin1.5反而会有更好的表现，这是因为Kylin1.5引入了HBase并行Scan，大大降低了扫描的时间。Kylin1.5的数据会shard到不同的region上，在千万量级上数据量还比较小，没有明显的体现，但是上亿以后，随着数据量上升，region也变多了，反而能把并发度提上去。所以在这里可以看到Kylin1.5表现会更好。这里也可以看出，在数据量成数量级上升后，Kylin表现的更加稳定，在不同规模数据集上依然可以保持不错的查询性能。而Druid随着数据量的增长性能损失也成倍增长。

刚才是在性能方面做的一些分析，其实对于一个系统来说，性能只是一个方面，除此之外，我们也会去考量其它方面的情况，主要有以下四点。

第一，功能的完备性。刚才提到我们所有的数据必须是精确的，但是现在基本上没有哪个系统能完全覆盖我们这个需求。比如Druid性能表现确实更好，但是它去重计数没有办法做到精确。

第二，系统的易用性。作为一个平台服务，不仅要把系统用起来，还要维护它，因此要考虑部署和监控的成本。这方面Kylin相对来说也是比较好的。Druid一个集群的角色是非常多的，如果要把这个系统用起来的话，可能光搭这个环境，起这些服务都要很长的时间。这个对于我们做平台来讲，实际上是一个比较痛的事。不管是在部署，还是加监控的时候，成本都是相对比较高的。另外一个查询接口方面，我们最熟悉或者最标准，最好用的当然是标准SQL的接口。ES、Druid这些系统原来都不支持SQL，当然现在也有一些插件，但是在功能的完备性和数据的效率上都不如原生的支持。

第三，数据成本。刚才提到了有些数据需要做一些预处理，比如表的拉平或者表达式列的变换，除此之外还有一些格式的转化，比如有的系统只能读TEXT格式，这样都会带来数据准备的成本。另一方面是数据导入的效率。从数据进入数据仓库到真正能够被查询，这个时间中间有多长。数据存储和服务的时候需要多少机器资源，这个都可以归为数据成本，就是使用这个数据需要付出的成本。

第四，查询灵活性。经常有业务方问到，如果Cube没定义的话怎么办？现在当然查询只能失败。这个说明有的查询模式不是那么固定的，可能突然要查一个数，但以后都不会再查了。实际上在需要预定义的OLAP引擎上，这种需求普遍来讲支持都不是太好。

这张图是各个系统全方位的一个对比。

从查询效率上看，这里表现最不好的就是Presto，表现最好的应该是Druid和Kylin1.5，两者不相上下。从功能完备性上来讲，确实Presto语法和UDF等等是很完备的，Kylin会稍微差一些，但比Druid好一点。

系统易用性上区别不是太大，这里主要考虑有没有标准的SQL接口或者部署成本高不高，用户上手能不能更快，目前来看Druid接口上确实不够友好，需要去翻它的文档才知道怎么去写查询的语法。

在查询成本上，Presto是最好的，因为几乎不需要做什么特殊的处理，基本上Hive能读的数据Presto也都能读，所以这个成本非常低。Druid和Kylin的成本相对较高，因为都需要提前的预计算，尤其是Kylin如果维度数特别多，而且不做特别优化的话，数据量还是很可观的。

最后从灵活性上来讲， Presto只要SQL写出来怎么查都可以，Druid和Kylin都要做一些预先模型定义的工作。这方面也可以作为大家选型时候的参考。

刚才比较客观的对比了几个系统，接下来再总结一下Kylin的优势。

第一，性能非常稳定。因为Kylin依赖的所有服务，比如Hive、HBase都是非常成熟的，Kylin本身的逻辑并不复杂，所以稳定性有一个很好的保证。目前在我们的生产环境中，稳定性可以保证在99.99%以上。同时查询时延也比较理想。我们现在有一个业务线需求，每天查询量在两万次以上，95%的时延低于1秒，99%在3秒以内。基本上能满足我们交互式分析的需求。

第二，对我们特别重要的一点，就是数据的精确性要求。其实现在能做到的只有Kylin，所以说我们也没有什么太多其他的选择。

第三，从易用性上来讲，Kylin也有非常多的特点。首先是外围的服务，不管是Hive还是HBase，只要大家用Hadoop系统的话基本都有了，不需要额外工作。在部署运维和使用成本上来讲，都是比较低的。其次，有一个公共的Web页面来做模型的配置。相比之下Druid现在还是基于配置文件来做。这里就有一个问题，配置文件一般都是平台方或者管理员来管理的，没办法把这个配置系统开放出去，这样在沟通成本和响应效率上都不够理想。Kylin有一个通用的Web Server开放出来，所有用户都可以去测试和定义，只有上线的时候需要管理员再review一下，这样体验就会好很多。

第四，最后一点就是活跃开放的社区和热心的核心开发者团队，社区里讨论非常开放，大家可以提自己的意见及patch，修复bug以及提交新的功能等，包括我们美团团队也贡献了很多特性，比如写入不同的HBase集群等。这里特别要指出的是核心团队都是中国人，这是Apache所有项目里唯一中国人为主的顶级项目，社区非常活跃和热心，有非常多的中国工程师。特别是当你贡献越来越多的时候，社区会邀请成为committer等，包括我自己及团队成员也已经是Apache Kylin的committer。同时也非常高兴看到以韩卿为首的Apache Kylin核心团队在今年初成立的创业公司Kyligence，相信可以为整个项目及社区的发展带来更大的空间和未来。

4、未来工作

在未来工作方面，我们认为Kylin还有一些不理想的方面，我们也会着力去做优化和改进。

第一，精确去重计数。刚才提到只支持Int，接下来有一个方案会支持所有的数据类型，能够扩展大家使用精确去重的场景范围（补充说明：目前该功能已在1.5.3版本中实现）。

第二，在查询效率和Build效率上也看到了一些可以优化的部分。比如队列资源拆分，我们所有计算集群的资源都是按照业务线核算成本的，但是现在Kylin本身还不太支持，这个我们也会抓紧去做，相信在很多公司也有类似的需求。还有大结果集和分页。当结果到了上百万的量级时，查询时延会上升到几十秒。同时在查询的时候有可能需要排序并且分页，就是把结果全读出来之后，根据其中的一个指标再order by，这个开销也是比较大的。我们也会想办法进行优化。

最后，Kylin1.5之后有明细数据和Streaming特性出来，后面也会做这方面的尝试。

5、QA

Q1：之前在Build的时候一直提到成本的问题，能给出一个估计值吗，如果一百亿的数据，需要多少时间？

孙业锐：有一个简单数据，大概是两亿行数据，维度的话有十四五个，Build时间不超过两个小时，Build出来的数据是五六百G。

Q2：原始值是多大？

孙业锐：把这个数据抽出来之后，就是只参与Build的数据压缩后只有几个G。

Q3：Kerberos认证失效的问题你们遇到过没有？

孙业锐： Kerberos认证完之后，会在本地临时目录下有一个ticket问题，每天在外部定时刷新一下就可以了，服务是不用停的。

主持人：我补充一下我们为什么选择SQL接口？Kylin解决的是真正的用户面是谁，其实是业务人员和分析人员，他只会SQL，几乎那些人很少说再学个JAVA，所以能给他一个标准的SQL这个是让他上船最快的事情。其实这就是易用性很重要。

刚才看到了Kylin在千万级规模和亿级规模的表现，如果数据规模上到十亿，百亿，千亿的时候，我相信Kylin应该会秒杀所有一切。因为我们现在有另一个案例，生产环境上千亿规模的一张表，可以做到90%查询在1.8秒以内。另外我觉得非常好的一点，像美团、京东这边贡献了很多patch，其实就是把需求提出来，大家可以一起来做。

作者介绍

孙业锐，美团高级工程师，Apache Kylin Committer。2012年毕业于电子科技大学，曾在奇虎360工作，负责Hadoop平台建设，2015年加入美团。目前主要负责数据生产和查询引擎的改进和优化，专注于分布式计算，OLAP分析等领域，对分布式存储系统亦有丰富经验。