apache kylin

京东云海是由京东和ISV共同合作的模式对商家提供服务。云海提供基础的京东POP(商家开放平台)数据，包括商品、商家、客服绩效、品牌、行业等主题数据，目前可提供T+1汇总计算结果，以及上百个实时指标订阅。ISV通过商家授权可以获取商家基础数据，ISV通过JOS的API接口上传相关维表数据，数据上传到数据仓库后，ISV可以在云海开放平台上开发相关的Hive SQL对上传数据和商家基础数据进行关联计算，计算结果可以通过数据开放API查询，ISV获取到数据后通过应用展现给商家使用。

需求场景一：JOS开放API调用情况分析（OLAP分析）

JOS开放接近500个API，每天调用量在7亿次左右。针对API的调用情况进行多维分析，分析查询延迟要求达到秒级，并使用BI工具进行分析展现。

JOS的API访问日志数据通过定时抓取存储在Hive数据仓库中。所以需要一种能够在大数据量情况下进行交互式多维分析的SQL on Hadoop引擎。并且要支持和BI工具的集成，提供标准的JDBC、ODBC接口。

需求场景二：云海结果数据下载（原始明细数据查询）

云海通过JOS的API将结果表的数据查询服务开放给ISV，开放服务中允许ISV定义标准SQL模板，在接口调用时传递不同参数来查询数据，接口单次调用返回数据量限制为5000条，接口查询延迟要保证在毫秒级别，并支持高并发调用。结果表数据存储在Hive数据仓库中。所以需要一种SQL on Hadoop引擎能够支撑基于大表的原始明细数据毫秒级查询。

关于Apache Kylin

现在开源社区各种优秀的SQL on Hadoop引擎不断涌现，比如Impala，SparkSQL，Phoenix等等。但是针对于以上场景的考虑：大数据量情况下秒级多维分析、支持与传统BI工具无缝集成、在大数据量基础上使用标准SQL查询小数据量结果集能够达到毫秒级、完全基于Hadoop生态系统、T+1和实时处理数据、支持水平扩展等。最终我们把目标锁定在了Apache Kylin。

Apache Kylin是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，能够支持TB到PB级别的数据量，最初由eBay Inc开发并于2014年10月贡献至开源社区，于2014年11月加入Apache孵化器项目，于今年11月正式毕业成为Apache 顶级项目。

Apache Kylin旨在减少Hadoop在10亿及百亿规模以上数据级别的情况下的查询延迟，目前底层数据存储基于HBase，具有较强的可伸缩性。Apache Kylin为Hadoop数据提供了ANSI-SQL接口，并且支持大多数的ANSI-SQL的函数；能够支持在秒级别延迟的情况下同Hadoop进行交互式查询；支持多维联机分析处理数据仓库（MOLAP Cube）；用户能够定义数据模型；并且通过Apache Kylin能够预建超过10多亿行原始数据记录的数据模型；可与其他BI工具无缝集成，包括Tableau，Excel，PowerBI等；并提供了JDBC，ODBC接口；可分布式部署，Query Server可以水平扩展，存储基于HBase也可以水平扩展。并且Apache Kylin将在后续版本支持流式近实时Cube计算，支持实时数据多维分析等各种场景。

更多关于Apache Kylin的详细信息可以访问：

http://kylin.io

Apache Kylin在京东云海的应用部署及性能

系统架构及集群部署

Apache Kylin集群：

• 1 个任务服务器，4个查询服务器。
• Apache HBase集群规模：
• 27个节点，和其他业务共用。
• 两种场景使用同一个集群。

模块关系图：

部署图：

Apache Kylin性能表现：

1. OLAP分析

单个Cube最大维度16个，最大数据条数100亿，最大存储空间400G。

性能：数据分析人员采用BI工具进行查询，95%的查询响应时间在15秒以内。

2. 原始明细数据查询

单个Cube最大维度8个，最大数据条数4亿，最大存储空间800G。30个Cube占用总空间4T左右。

性能：单次查询返回数据条数限制在5000条以内，查询QPS在50左右，所有查询平均响应时间200ms，查询QPS在200左右平均响应时间可以保持在1s以内。

查询的并发能力和响应时间和HBase集群规模有关，这两个场景的数据只使用了一个小集群，可以对Apache Kylin Query Server和HBase集群水平扩容来提高并发查询能力和减小响应时间。

Apache Kylin原不支持此功能，京东对其实现逻辑做了修改，并已经贡献回社区。

京东对于Apache Kylin的二次开发

主要的改造是增加了支持原始明细数据查询的实现。

Apache Kylin在使用SQL查询时，至少需要指定一个Group by条件，在类似Select dimension_column1,measure_column2,measure_column3 from fact_table这种包含指标列明细数据的查询时不能返回结果。

由于Apache Kylin的Cube计算是根据所有聚合维度的组合计算定义指标的值，在Cube定义阶段必须包含聚合维度和计算指标的配置。计算指标目前包括SUM，MAX，MIN，COUNT，COUNT_DISTINCT。

由此想要实现原始数据的查询有以下方案：

方案一

在原始数据表中增加一列唯一值列，并将所有列都配置为维度列，如果某列的基数非常高，则不创建字典指定固定列长度的方式设置维度属性。这样的Cube计算结果相当于对唯一值列进行Group by，会查询到所有行的值。

方案的优点：不用修改Apache Kylin代码，只需要处理原始数据增加唯一列即可。

方案的缺点：虽然是支持了原始明细数据的查询，但是所有列都作为了维度聚合，在原始表列的数量非常多的情况下，Cube的大小会膨胀的非常大，构建时间增长。所以需要更优的方法来处理。

方案二

1、在原始数据表中增加一列唯一值列，并把此列配置在维度中。

2、修改源码增加一个新的聚合函数，此聚合函数的输入和输出保持相同，不做任何聚合计算。通过这个聚合函数和对唯一列的聚合来保证每一个指标列的原始值都能被获取到。由于Apache Kylin本身带有的聚合函数只支持数字类型的列，所以需要增加新的聚合函数支持所有数据类型的输入和输出。这样能够减少不必要的维度组合，减小Cube的大小，缩短构建的时间。

方案的优点：能够解决方案一中Cube膨胀的问题和构建时间长的问题。

方案的缺点：如果数据表中不存在唯一列的情况时，不能够查询到所有的明细数据。更好的解决方案是在没有唯一列的情况下同样也能够支持明细数据查询。

我们是对方案二进行了实现，并且将Patch贡献回社区，目前正在和社区一起优化：即方案三。

方案三

1、不需要在原始表中增加唯一列。

2、修改源码增加新的聚合函数，此聚合函数能使被聚合的明细数据存储在HBase中的一行。在查询时将数据进行展开。

3、修改源码增加对聚合函数值的字典支持，以减少存储数据大小。

此方案是改进方案，我们正在和社区共同进行优化改造，请关注KYLIN-1122以跟踪最新进展。

使用Apache Kylin的实践总结

1、大的事实表采用天分区增量构建，为了不影响查询性能，可以定期做合并(Merge)，周期可以根据实际情况确定，我们一周进行一次合并。

2、对于维表比较大的情况，或者查询Select部分存在复杂的逻辑判断，存在Apache Kylin不支持的函数或语句时，可以将事实表和维表的关联处理创建为Hive视图，之后根据视图创建Cube模型。

3、每次查询必然带有的条件建议在字典设置步骤将其设置为Mandatory。这样会最终 Build出来Cube的大小会减少一半。

4、Cube的维度如果超过10个，建议将常用的聚合字段做分组，我们对于最大的16个维度分了三个组，每组大概在5个维度左右。

5、Cube定义中RowKey顺序：Mandatory维度，Where过滤条件中出现频率较多的维度，高基数维度，低基数维度。

6、对于Hierarchies，Derived维度方面配置优化可以参考社区文档：

    http://kylin.incubator.apache.org/docs/howto/howto_optimize_cubes.html

7、部署层面，可以通过Nginx在前端做负载均衡，后端启动多个Query Server接收查询请求处理。