【问答集锦】Apache Kylin Meetup@北京提问集锦大放送！

8月11日，由 Kyligence 主办、美团点评协办的 Apache Kylin Meetup@北京，在美团公司总部顺利举办。

点此可获取讲师演讲PPT

本次 Meetup 受到了各位小伙伴的鼎力厚爱——除了原计划70+人的规模最后被扩张到130+人规模外，现场小伙伴们更是从演讲 Q&A 环节到茶歇环节都围着讲师们热烈、积极地沟通、探讨关于 Apache Kylin 的技术问题。

每一个问题,或许都代表着一个困扰 Kylin 用户已久的结节……今天，小编整理了当天的部分提问，希望可以帮助到场或者没有到场的各位同学，从中找到自己所需的知识，解答在Kylin使用历程中的困惑。

【美团-康凯森篇】

基于 Druid 的 Apache Kylin 存储引擎实践

Q1. 开篇时提到美团同时维护着 Kylin 和 Druid 两个引擎，又做了 Kylin on Druid 架构，为什么不直接用 Druid，是因为直接用 Druid 会遇到什么问题吗？能否对比一下 Druid 和 Kylin 在美团实际业务中的差异性？

康凯森：不用 Druid 把 Kylin 替掉，而是做了 Kylin on Druid 有以下几个原因：第一，在2017年时有一个 SQL 接口的问题；第二，Druid 在离线导入上没有 Kylin 这么方便；第三，Kylin 本身是一种星型模式，可以实时进行查询，但 Druid 目前只能是单表。因此，如果要用 Druid 替掉 Kylin，工作量会远比 Kylin on Druid 大。

关于他们应用上的区别，目前 Kylin 主推是在 OLAP，是离线的场景；而实时我们主推 Druid。

Q2. Druid 离线的方式也是可以的，为什么不统一一下？

康凯森：Druid是支持离线导入，但是它的离线导入没有Kylin这么完善。我们是可以通过改进Druid，让它达到和Kylin一样的水平，但需要花费一样的精力，尤其是我们在已经有了Kylin的场景下，就需要考虑有没有必要再把Druid打造的和Kylin功能对齐、把Kylin替掉，我们需要考虑它实际的业务价值。

Q3. 刚才提到Druid的SQL接口上不是很友好，在相对比较新的版本的Hive里是支持Hive on Druid，可以和Hive的生态在一起，是一个不错的选择。这一块有没有一些想法？

康凯森：最新的Druid已经支持了SQL，但是从2017年5月到现在，Druid的SQL不断的优化改进已经做了一年多，到现在刚刚调用了Druid的SQL，但是一年多过去了，还不是很完善。

Q4. 为什么Kylin在美团还只有900多个Cube？主要用于哪些业务线？我在美团内部把Kylin On HBase切换到Kylin on Druid需要做多少工作？

主持人：分享一个心得，相比于一年前，美团on Kylin的数据源数据量增加了10倍，Cube数量增加3倍，Cube存储差不多是4-5倍的增长，增长速度非常快。900个Cube在我们看来其实是一个非常大的使用规模了。

康凯森：Cube的数量并不是最重要的，看这个Kylin到底有多少个业务场景。比如我们曾经试图用Kylin解决漏斗问题，这个Cube是自动创建的，一个漏斗就可以创建几百个Cube，但是没有什么意义。在美团内部怎么使用Kylin on Druid？如果给你的业务线开了权限之后，在页面上可以看到切换按纽，直接选择Druid就可以了，就在切换Spark和MR那一块。

Q5. 因为现在都是按天进行构建的，对于历史数据的合并、搭载是怎么处理的？

康凯森：如果是Kylin的话，一般使用Auto merge功能，也可以手动去merge，Druid也是用这个功能。

【贝壳找房-张如松篇】

Apache Kylin 在贝壳找房的实践

Q1. 我司之前的场景行和列的基数是几千万级，因为基数太大了，我们拆分了。你们是怎么做的？

主持人：关于高基数纬度的优化，我觉得主要是注意两点：第一点，不要用Dictionary去做Encoding，因为这样的话，Dictionary会很大，会撑爆你的内存。第二点，要避免高基数的纬度和其他的维度做各种组合，每种组合下来都很大，你可以把它只留在比如Base Cuboid，或者你非常严格的定义它和某些维度放在一个地方。  

Q2. 前面提到您这边的日常有上百万的数据，贝壳找房网的并发量有多大？因为您提到控制任务的提交，控制任务的提交主要是对并发进来任务的提交，是往上提还是把程序做一个分散？是怎么做？

张如松：首先，我们查询的次数是百万+，并发是50-60。其次，根据Kylin现在的运营情况控制它的任务总数，当它的任务太多的时候，对Kylin本身也是一个压力。对单个Cube的任务是有限制的，比如Kylin本身对单个Cube默认只能跑10个任务，但是第11个又进来的话，就直接丢弃了。但这样会影响用户体验，比如说提交无效，因此我们用了中间件控制，都提交到我们的中间件上，由中间件来控制。

提问：要排队后面等待吗？

张如松：对。我们所有的任务都是有它自己的上线依赖，任务出来的时候是分散的，排队的情况也不多。

【Kyligence-马洪宾篇】

ApacheKylin 智能建模与调优

Q1. Auto Model底下的建模针对存储空间怎么控制？甚至于规则不够好，存储空间可以无限扩大吗？

马洪宾：在初始情况下，不建议用户设太多的规则，一个空的模型就好了，不断把这个Query灌进来，我们自己帮他分析哪些查询是有必要的，这些查询应该符合什么样的模型。有的客户说，我很懂这个业务，就是要那么几个Cuboids，这个时候我们推荐尽量去定制一些高度剪枝的规则，这样就不会产生特别大膨胀率。我们也会有threshold的概念，一个Cube设置的天花板在哪里，到了一定的程度时候会淘汰一些不太常用的Cuboids，来换取空间为更常用的Query做预计算。

Q2. 目前我们的应用场景在可视化方面是在Power BI，我们公司的情况是有很多业务同事不具备SQL的能力，针对很多不懂SQL业务的同事，怎么让他把Kylin的查询应用起来？

马洪宾：据我所知，我们ODBC对接最好的是Tableau，对于像Power BI来说，我们也很努力的去支持它，但据我所知，现在主要的瓶颈应该是在微软。因为微软的Power BI只有桌面的版本能够支持第三方的ODBC驱动，纯个人版的Excel就可以很好的兼容第三方的ODBC驱动。我们有一个部门是生态与合作伙伴，他们现在正在推荐这件事情。但我个人认为你想推动一只大象不是那么容易的事情，可能要做的是自己做一些投入，比如基于saiku的方案。

Q3. 建模的Model，您说最初业务不需要建Model，这个Model不断更新时，Cube是不是需要重新建立？数据是不是需要重新刷？当Kylin维度基数特别大的时候，选了dictionary的时候，会出现OOM，我了解OOM原来设置的是300还是400兆，商业版是怎么优化的？

马洪宾：模型重新设计了，如果又有变化的话，到底要不要重刷？我的答案是不用。原来你的Model有ABC三个纬度，你肯定建了一些AB、AC等这样的Cuboids，后来加了D，显而易见的是原来没有针对D纬度做一些预算我肯定要补一块，比如说AD、BD等，但原来的AB、AC应该是可以复用的。今天做的事情是可以帮助你复用，以前可能是全部推倒重新建，今天这个模型就是避免这种浪费。

提问：比如截止到这个月之前，AB、AC、AD组合以后，之前的组合的Cuboid里是没有这个维度的，之前的数据也需要补吗？

马洪宾：这个是必须要补上的，所以一定会有一次构建，但这个构建并不需要像今天一样全部重刷，只需要把和D这个纬度相关的Cuboid补上就好了，计算量比今天小很多。

第二个问题，字典基数很高的话，容易超过它的限制、被拦住。今天我们在企业版里，应该没有特别大的不同，我们还是不建议特别大的基数的去建Dictionary，因为是比较难做的事情。如果高基数列比如说是什么ID，本身就是一个长整数，可以用长整数的encoding去做。也可能是一个名字，但是长度小于10的，就用固定长度编码来做。

我们企业版里还有一件事情，我们可能会取消HBase里面维度定长的预限，也就是说将来我可能会用一个变长的encoding来encode这个维度，这样可能就不会总是想着要用什么，可能用通用的可变长编码编一下就好了，这个应该是我们商业版最大的不同。

【小米-武斌篇】

OLAP实践分享：Lambda架构篇

Q1.有一些用户确保相同的业务查询的反应速度，在某些场景设置的秒级的。比如说数据的新鲜度正好在秒级里，大量的数据涌入，怎么确保缓存的数据是正常的，而不是过时的？

武斌：没有缓存，对数据新鲜度来讲是最好的，这个只是要和业务达到一致。业务方需要告诉你他对数据新鲜度的要求是多少，你需要以此帮他估算出来他的查询成本，让业务和我们的平台提供方达成一致说我为你提供一个什么样级别的缓存或者什么样级别的数据新鲜度，是分钟级还是秒级，最后再来确定设还是不设以及怎么设。

Q2.Batch和Speed层会做数据合并吗？

武斌：我们会保证Speed层里只有最近一段时间的数据，比如说最近一天或者最近两天，但是这个时间不会很长。我们所有的数据修正过程以及数据合并的过程都在Batch层做，但是Query分发的时候会保证，Speed就算有七天的数据，但我只有最近一天或者最近两天，这是基于业务配置，会有Query Speed层。但我更早的数据全部都会走Batch层。

Q3.Speed层的数据会流到Batch层吗？

武斌：一个Data有两层数据流，这和整个的数据流有关系。所有的数据，无论是线上还是离线同步，会到统一的消息流流服务里去，会开Group sink，不停的下沉到比如Kudu、ES，甚至是Kafka。数据Sink到Batch(HDFS/Hive)之后，会经过ETL构成进行去重和数据修正。在数据质量校验通过后，才会更新Cube。

提问：会有数据不一致的情况产生？

武斌：通常情况下是这样处理的，以Batch层为准，我们认为，Speed层很难保证，我认为我们容忍Speed层一部分数据的误差。   

提问：多维度组合的问题？

武斌：不是多维度组合，而是在更实时的查更多维度上的OLAP的请求。对ES而言，本身存了各种各样维度上面的数据的raw data，所以你想怎么查就怎么查，只是我们限定了你存的数据天数，所以它现在特别快。

另一方面，因为你是实时更新的，所以不需要做所谓Mini Batch的构建，我们知道Kylin本身是支持Mini Batch，起一个Spark构建这些东西，只是会有其他的开销，比如去合并的时候或者在一样的情况下可能拿不到资源无法保证数据新鲜度等一系列其他的问题，所以我们在一层走的是ES和Kudu解决方案。因为对于小米而言，更重要的是解决实际业务需求，而不是拿一个工具或者解决方案解决所有的问题。       

Q4. 这个系统刚开始的时候说是面对同一个查询，结果有一部分明细的是带ES的。比如说一个用户查询Sum A+Sum B，可能Sum A是基于Kylin，Sum B可能是在ES，像这种支持吗？

武斌：我们不支持。首先我们要解决的是数据实时性的问题，并不是解决Ad-Hoc和OLAP查询混合的需求，解决的场景不一样。

提问：拆分可能就是查询级的拆分，比如说明确的这个查询就是达到预聚合？

武斌：首先我们解决所有的东西都是OLAP需求，我们认为，所有的OLAP必须满足Kylin和ES的子集换句话说，这一列要查询的SQL在Kylin里面是能单独运行的。同时，抛开时间限制，在Kylin里是可以查询的，同时在ES或者Kudu对应的Speed层面引擎内容也是可以查出结果的，我们只是对这个查询进行分发和合并，并不解决说我可能预计算了A Column，然后想查B Column，怎么对它进行查询，我们不解决这个问题。