ApacheKylin在美团点评的应用在美团点评的应用
美团点评的OLAP需求大体分为两类:
即席查询:指用户通过手写SQL来完成一些临时的数据分析需求。这类需求的SQL形式多变、逻辑复杂,对响应时间没有严格
的要求。
固化查询:指对一些固化下来的取数、看数的需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率。这类
需求的SQL有固定的模式,对响应时间有比较高的要求 。
我们针对即席查询提供了Hive和Presto两个引擎。而固化查询由于需要秒级响应,很长一段时间都是通过先在数仓对数据做预
聚合,再将聚合表导入MySQL提供查询实现的。但是随着公司业务数据量和复杂度的不断提升,从2015年开始,这个方案出
现了三个比较突出的问题:
随着维度的不断增加,在数仓中维护各种维度组合的聚合表的成本越来越高,数据开发效率明显下降;
数据量超过千万行后,MySQL的导入和查询变得非常慢,经常把MySQL搞崩,DBA的抱怨很大;
由于大数据平台缺乏更高效率的查询引擎,查询需求都跑在Hive/Presto上,导致集群的计算压力大,跟不上业务需求的增
长。
为了解决这些痛点,我们在2015年末开始调研更高效率的OLAP引擎,寻找固化查询场景的解决方案。
为什么选择Kylin
在调研了市面上主流的开源OLAP引擎后,我们发现,目前还没有一个系统能够满足各种场景的查询需求。其本质原因是,没
有一个系统能同时在数据量、性能、和灵活性三个方面做到完美,每个系统在设计时都需要在这三者间做出取舍。
例如:
MPP架构的系统(Presto/Impala/SparkSQL/Drill等)有很好的数据量和灵活性支持,但是对响应时间是没有保证的。当数据
量和计算复杂度增加后,响应时间会变慢,从秒级到分钟级,甚至小时级都有可能。
搜索引擎架构的系统(Elasticsearch等)相对比MPP系统,在入库时将数据转换为倒排索引,采用Scatter-Gather计算模型,
牺牲了灵活性换取很好的性能,在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询,随着处理数据量的增加,
响应时间也会退化到分钟级。
预计算系统(Druid/Kylin等)则在入库时对数据进行预聚合,进一步牺牲灵活性换取性能,以实现对超大数据集的秒级响应。
有了这套框架,我们不难结合美团点评的自身需求特点,选择合适的OLAP引擎。