Kylin,Mondrian,Saiku系统的整合

本文主要介绍有赞数据团队为了满足在不同维度查看、分析重点指标的需求而搭建的OLAP分析工具。这个工具对Kylin，Mondrian以及Saiku做了一个整合，主要工作包括一些定制化的修改以及环境的配置。 目前这个系统还处于一个需要优化、完善的过程，这篇博文也会相应地更新。

背景

在有赞发展的初期，数据团队主要的工作之一就是根据运营人员的报表需求，编写sql，从hive中获得数据并写入mysql中存储。最后，前端人员写相应的代码展现mysql中存储的报表数据。 随着公司业务的快速发展，如此长周期的报表开发流程已经很难跟上运营人员的分析需求了。为了避免深陷报表开发、维护的泥潭，数据组决定调研大数据场景下的OLAP分析工具。参考了 明略数据的解决方案 之后，我们选择整合Kylin ， Mondrian ， Saiku 来实现这样一个OLAP系统。

三巨头

Kylin

kylin是apache软件基金会的顶级项目，一个开源的分布式多维分析工具。下面是摘自Kylin官网的介绍：

个人的理解是：Kylin通过预计算所有合理的维度组合下各个指标的值并把计算结果存储到HBASE中的方式，大大提高分布式多维分析的查询效率。Kylin接收sql查询语句作为输入，以查询结果作为输出。通过预计算的方式，将在hive中可能需要几分钟的查询响应时间下降到毫秒级。更细致的关于Kylin的介绍，可以参考我的另一片博客 Kylin初体验 。

Mondrian

Mondrian是一个OLAP分析的引擎，主要工作是根据事先配置好的schema，将输入的多维分析语句 MDX (Multidimensional Expressions )翻译成目标数据库／数据引擎的执行语言（比如SQL）。

Saiku

Saiku提供了一个多维分析的用户操作界面，可以通过简单拖拉拽的方式迅速生成报表。Saiku的主要工作是根据事先配置好的schema，将用户的操作转化成MDX语句提供给Mondrian引擎执行。

技术架构

一些细节

介绍完整体的结构，下面讲一些构建过程中遇到的坑。有些可能是我们的理解还不够深入，有些可能随着开源软件版本的升级已经不再是一个坑了。希望能给大家带来一些帮助，如果是由于我们理解的偏差导致踩到的坑，也希望大家留言给出指正：） 本套系统构建基于kylin1.5， Mondrian4.4以及Saiku3.7.4。底层是Hive0.14以及Hbase0.98。

关于schema

• 不要用view作为lookup table 在设计Kylin cube时，用hive view作为fact table是一个比较好的实践方式，可以屏蔽一些底层数据结构变化对Kylin cube的影响。但是不要用view作look up table，在build cube计算维度表容量时会出问题。
• Kylin无法在预计算指标时制定条件 比如有两个字段：order pay, is payed。我们可以配置sum(order pay)作为订单金额, sum(is payed)作为付款订单数。但是没法配置sum(order pay) where is payed = 1来表示付款订单金额。我们需要在fact view中添加字段payed order pay表示付款的订单金额。
• 尽量在Kylin中用int类型 比如is_payed字段，就0/1两个值，通常我们在hive里可以设置为tiny int类型的字段。但是在Kylin中，针对tiny int 和 int类型的字段配置出来的measure类型是不一样的，tiny int 类型的字段得到的measure在和Saiku结合时可能会出现问题。
• 把hive表放在default库中 Kylin添加hive table的时候是可以指定hive table所在库的，但是建议将fact table、lookup table都放在default库中。因为在Mondrian的schema中，physical table是默认去default库查找的，目前还没有发现很好的在Mondrian schema中指定数据库的方式。

关于count distinct

为了解决这个两难的问题，我们深入到Mondrian的源码中去，找到了计算维度表大小的代码：

 private static String generateColumnCardinalitySql(
        Dialect dialect,
        String schema,
        String table,
        String column)
    {
        final StringBuilder buf = new StringBuilder();
        String exprString = dialect.quoteIdentifier(column);
        if (dialect.allowsCountDistinct()) {
            // e.g. "select count(distinct product_id) from product"
 buf.append("select count(distinct")
 .append(exprString)
 .append(") from");
 dialect.quoteIdentifier(buf, schema, table);
 return buf.toString();
 } 
 else if (dialect.allowsFromQuery()) {
 // Some databases (e.g. Access) don't like 'count(distinct)',
 // so use, e.g., "select count(*) from (selectdistinct
            // product_id from product)"
 buf.append("select count(*) from (selectdistinct")
 .append(exprString)
 .append("from");
 dialect.quoteIdentifier(buf, schema, table);
 buf.append(")");
 ...

注意到只有dialect.allowsCountDistinct()为true时才会用count distinct来计算维度表大小。 我们只要将Kylin dialect的allowsCountDistinct()设置为true，同时在generateColumnCardinalitySql添加一个判断条件：

if (dialect.allowsCountDistinct()
            && !dialect.getDatabaseProduct().name().equalsIgnoreCase("KYLIN")) {
            ...

就可以实现和kylin的count distcint measure的正常对接了。

关于Kylin sql

有了处理count distinct的问题的经验，我们发现，只要了解Kylin sql的特点，针对Kylin sql定制Mondrian 的Kylin—diect就能将Mondrian和kylin较好的对接。 经过在Kylin1.5的交互界面中的测试，我们列出如下的区别：

• 不能limit beg, end 只能limit length
• 不支持 union, union all
• 不支持 where exists 子句

结束语

以上是有赞数据团队实现多维分析工具的探索过程。总的来说，Kylin ＋ Saiku ＋ Mondrian的一套流程是能走通的，中途遇到一些零碎的问题没有完全列出来。通常是因为Kylin只支持cube范围内的查询，如果Mondrian翻译出的sql超出这个范围就会引起系统的错误。 通常有三种解决方案：

• 重新构建Kylin cube，让它能覆盖更广范围的查询
• 修改Mondrian schema，让它的cube描述和Kylin cube吻合
• 定制化开发Mondrian的Kylin dialect，让Mondrian生成符合Kylin特点的sql

目前我们还在对这套三层框架做一些定制化的功能开发以及性能的调优工作。希望这篇文章能给大家带来些帮助，也希望有独特见解或者发现我们的理解不对的朋友们留言交流。