本文原载自大数据杂谈微信公众号。
感谢美团点评工程师高大月撰文并受权转载。
高大月，美团点评工程师，Apache Kylin PMC成员，目前主要在美团点评数据平台负责OLAP查询引擎的建设。
背景
美团点评的OLAP需求大致分为两类：微信
即席查询：指用户经过手写SQL来完成一些临时的数据分析需求。这类需求的SQL形式多变、逻辑复杂，对响应时间没有严格的要求。架构
固化查询：指对一些固化下来的取数、看数的需求，经过数据产品的形式提供给用户，从而提升数据分析和运营的效率。这类需求的SQL有固定的模式，对响应时间有比较高的要求 。负载均衡
咱们针对即席查询提供了Hive和Presto两个引擎。而固化查询因为须要秒级响应，很长一段时间都是经过先在数仓对数据作预聚合，再将聚合表导入MySQL提供查询实现的。可是随着公司业务数据量和复杂度的不断提高，从2015年开始，这个方案出现了三个比较突出的问题：框架
随着维度的不断增长，在数仓中维护各类维度组合的聚合表的成本愈来愈高，数据开发效率明显降低;性能
数据量超过千万行后，MySQL的导入和查询变得很是慢，常常把MySQL搞崩，DBA的抱怨很大;大数据
因为大数据平台缺少更高效率的查询引擎，查询需求都跑在Hive/Presto上，致使集群的计算压力大，跟不上业务需求的增加。ui
为了解决这些痛点，咱们在2015年底开始调研更高效率的OLAP引擎，寻找固化查询场景的解决方案。搜索引擎
为何选择Kylin
在调研了市面上主流的开源OLAP引擎后，咱们发现，目前尚未一个系统可以知足各类场景的查询需求。其本质缘由是，没有一个系统能同时在数据量、性能、和灵活性三个方面作到完美，每一个系统在设计时都须要在这三者间作出取舍。设计
例如:rest
MPP架构的系统（Presto/Impala/SparkSQL/Drill等）有很好的数据量和灵活性支持，可是对响应时间是没有保证的。当数据量和计算复杂度增长后，响应时间会变慢，从秒级到分钟级，甚至小时级都有可能。
搜索引擎架构的系统（Elasticsearch等）相对比MPP系统，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能作到亚秒级响应。可是对于扫描聚合为主的查询，随着处理数据量的增长，响应时间也会退化到分钟级。
预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。
有了这套框架，咱们不难结合美团点评的自身需求特色，选择合适的OLAP引擎。
能够看出，咱们对数据量和性能的要求是比较高的。MPP和搜索引擎系统没法知足超大数据集下的性能要求，所以很天然地会考虑预计算系统。而Druid主要面向的是实时Timeseries数据，咱们虽然也有相似的场景，但主流的分析仍是面向数仓中按天生产的结构化表，所以Kylin的MOLAP Cube方案是最适合咱们场景的引擎。
Kylin的使用现状
2016年初，咱们开始向各个业务线推广基于Kylin的解决方案。通过一年的努力，Kylin已经应用到了美团点评的几乎全部主要业务线上，而且在外卖、酒旅等数个业务线获得了大规模的使用，Kylin已经成为了这些业务的首选OLAP引擎。
截至16年末，生产环境共有214个Cube，包含的数据总行数为2853亿行，Cube在HBase中的存储有59TB。日查询次数超过了50万次，TP50查询时延87ms，TP99时延1266ms，很好地知足了咱们对性能的要求。
为了支持这些需求，咱们的线上环境包含一个30节点的Kylin专属HBase集群，2台用于Cube构建的物理机，和8台8核16G的VM用做Kylin的查询机。Cube的构建是运行在主计算集群的MR做业，各业务线的构建任务拆分到了他们各自的资源队列上。
因为Kylin对外是REST接口，咱们接入了公司统一的http服务治理框架来实现负载均衡和平滑重启。
“维度爆炸”问题在实践中是可解的
提到MOLAP Cube方案，不少没接触过Kylin的人会担忧“维度爆炸”的问题，即每增长一个维度，因为维度组合数翻倍，Cube的计算和存储量也会成倍增加。咱们起初其实也有一样的担忧，但调研和使用Kylin一阵子后发现，这个问题在实践中并无想象的严重。这主要是由于
Kylin支持Partial Cube，不须要对全部维度组合都进行预计算；
实际业务中，维度之间每每存在衍生关系，而Kylin能够把衍生维度的计算从预计算推迟到查询处理阶段。
以事实表上的衍生维度为例，咱们业务中的不少维度都是(ID, NAME)成对出现的。查询时须要对ID列进行过滤，但显示时只须要取对应的NAME列。若是把这两列都做为维度，维度个数会翻倍。而在Kylin中，能够把NAME做为ID列的extendedcolumn指标，这样Cube中的维度个数就减半了。
下面分享一些咱们线上Cube的统计数据。
能够看到，采用衍生维度后，90%的场景能够把Cube中的维度个数（Rowkey列数）控制在20个之内。指标个数呈现长尾分布，小于10个指标的Cube是最多的，不过也有近一半的Cube指标数超过20。总共有382个去重指标，占到了总指标数的10%，绝大多数都是精确去重指标。49%的Cube膨胀率小于100%，即Cube存储量不超过上游Hive表。68%的Cube可以在1小时内完成构建，92%在2小时内完成构建。
美团外卖的使用案例
下面分享一下Kylin在美团外卖的使用案例，感谢外卖的同事 靳国卫和惠明 提供材料。
外卖数据业务对交互式的OLAP分析有着很强的需求。在使用Kylin之前，采用的是在Hive中开发聚合表再导入MySQL的方案。随着业务数据量高速增加和需求的不断升级，这套方案遇到了开头提到的查询效率和开发效率的双重问题。
在使用Kylin后，除了查询性能的显著提高，外卖的数据开发方式发生了很大的改变。原来须要作繁琐的聚合层和主题层数据，如今只须要把重点放到基础数据的建设上，预计算的工做交给Kylin就好了。在对同一个需求同时采用老方案和Kylin方案实施后发现，使用Kylin后的数据开发效率提高了3倍。
下面是一个对流量数据应用Kylin的具体案例。咱们在Kylin 1.5.3版本添加了全局字典，实现了上亿基数、任意类型字段（例如设备ID）的精确去重计数，把Kylin的使用场景扩宽到了流量数据。
平台化经验与思考
一个开源项目从run起来到真正做为平台化的服务提供出去，中间会遇到不少的挑战和问题须要解决。下面是咱们总结的一些经验，在这里分享给你们，也欢迎同行们和咱们一块儿探讨。