Kylin基础教程（一）

最新推荐文章于 2024-08-08 23:18:22 发布

weixin_30483013

最新推荐文章于 2024-08-08 23:18:22 发布

阅读量539

点赞数 1

文章标签：运维大数据

原文链接：http://www.cnblogs.com/wzlbigdata/p/8481991.html

版权

一、Kylin介绍

1.1 现状

Hadoop于2006年初步实现，改变了企业级的大数据存储（基于HDFS）和批处理（主要基于MR）问题，10几年过去了，数据量随着互联网的发展井喷式增长，如何高速、低延迟的分析数据成为后续面临的挑战，辟如我们面临的一些质疑：Hadoop老矣，尚能饭否？

其中也出现过各种各样的框架来协助Hadoop降低访问数据的延迟，比如列存储框架（Columnar Storage）例如：HBase，以及一些“SQL on Hadoop”的批处理框架，其中以Hive为代表的，Impala，Presto，Drill，SparkSQL紧随其后。

大规模并行处理可以利用多台机器，并行计算，用线性增加的硬件资源，来换取计算时间的线性下降。列式存储则是将数据按照列来存放，这样可以在访问数据时只读取需要的列，“硬件横向插拔式拓展”和“面向列存储”大大提高了基于Hadoop查询分析数据的效率，从原来的几个小时，缩小到了几分钟，但是面临完整的业务分析体系，依然需要以小时甚至天来衡量从提交任务到得到结果的时间。这造成了数据分析师大部分时间都停留在等待结果上——一杯咖啡喝完，又打了把王者荣耀，结果依然没出来。

举个例子，假设查询1亿条数据耗时1分钟，那么可能会有如下对应关系：

也就是说我们提到的之前存在并一直在使用的优化机制并没有改变查询本身的时间复杂度，也有解决得到查询时间与数据量成线性增长这一问题。显然，无限制的横向拓展硬件部署，理论上可以无限的缩小查询时间，但是硬件成本极其昂贵，亦然于运维成本。

1.2 Kylin 出发思路

要解决问题，先分析问题核心矛盾点：

1) 大数据查询大多为统计结果，即多条数据经过聚合函数计算后的统计值，原始记录直接作为结果返回的概率极低。

2) 数据分析与描述必须按照维度来进行，业务范围不可能无限大，即，维度也不会大到天文数字这样的级别，展示需求也是如此，那么有价值的“维度组合个数”也是相对有限的，一般不会随着数据量的增加，维度也跟着不断的增加。

举个例子，如下查询：

SELECT telephone, sum(duration)

FROM tb_call_records

where call_date=’2018-02’

group by telephone

order by sum(duration) desc;

传统方式则是先全表扫描，然后找到符合2月的日期，再按照电话号码聚合，统计每个电话号码这一天所有的通话时长总和，最后排序输出，如果2月份的通话记录有1亿条，则查询会先访问1亿条记录，如果记录增加5倍，则查询效率下降5倍，等待时间提高5倍。

OK，基于以上矛盾，Kylin，出发了。

使用预计算，即把上面例子中的查询结果先计算好，保存下来，下次做相同访问时，就会变得非常快。我们可以先按照维度[call_date, telephone]计算sum(duration)，并存储下来，下次如果查询2月，或者其他月份的通话时长时，就可以直接返回了。这样一来，假如之前1亿条记录中有10万个电话号码，那么预计算之后，2月份的通话记录就只有10万条记录了，是原来的1000分之1。无论2月份的通话记录如何增加，我的查询速度也不会改变。那么各种统计结果保存也是需要消耗存储空间的，Kylin核心之一即：空间换时间，闲时定期对已有数据做预计算，并保存结果。这也是除“多硬件大规模并行处理”、“面向列存储”之外的提供大数据快速分析查询的第三技术——“预计算”。

还是那个例子，假设我们的原始数据是：