马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
基于hadoop的SQL一直在被持续地改进,但是一个查询等几分钟到几小时还是非常正常。在这篇博文里,将会介绍开源的分布式分析引擎Apache Kylin,尤其会重点介绍它是如何以数量级加速大数据查询,以及在2.0版里面为交互式BI所提供的新特性,包括对雪花模型的支持和流式建立数据立方。 Apache Kylin是什么? Kylin是一个在Hadoop上的OLAP引擎。如图1所示,Kylin位于Hadoop之上,向上层的应用提供了基于标准SQL接口的关系型数据。 Kylin可以处理大数据集,从查询延迟上讲是很快的,这也是它和其他基于Hadoop的SQL的区别。比如,我们所知道的使用Kylin的最大的生产系统实例是在今日头条,一个中国的新闻推送应用。头条有一个包含3万亿条记录的表,Kylin对它的平均查询响应时间低于1秒。下一节我们会讨论Kylin是怎么实现这么快的查询。 Kylin引擎的另一个特点是它可以支持复杂的数据模型。例如,太平洋保险(CPIC,中国的一个保险集团公司)有一个多达60维的模型。 Kylin提供标准的JDBC / ODBC / RestAPI接口,可实现与任何SQL应用程序的连接。 一个零售业场景:展示Kylin的速度 Kylin比传统的基于Hadoop的SQL要快,是因为它采用了预计算来在SQL执行前先行一步。例如,设想一个零售业务场景,你需要处理非常多的订单,每个订单包含多个商品。如果想知道订单取消和退货造成的影响,一个分析人员可能需要写一个查询来在某个时间段内按照“returnflas(退货标记)”和“orderstatus(订单状态)”来汇总收入进行汇报,如图2 所示。图里面显示了这个查询被编译成的关系表达式,也叫执行计划。 从这个执行计划可以很容易地看出,这个执行的时间复杂度至少是O(N),这里N是表里的总行数,因为每行都要至少被访问一次。同时我们假定要关联的表都已经很好地被分区和索引过了,因此花费比较大的关联操作也可以在线性的时间复杂度上完成,但在实际场景里这种情况是不大可能的。 这个O(N)的时间复杂度并不好,因为这意味着如果数据量增长十倍,则查询时间也会慢10倍。现在一个查询需要花1秒钟,那么以后随着数据的增长,这个时间会变成10秒甚至是100秒。我们想要的是无论数据量大小,这个查询时间都是固定不变的。 Kylin的解决方法是预计算。整体思路是,如果我们提前知道查询的模式,我们就能预先计算出整个执行的一部分。在上面这个例子里,就是预先计算Aggregate、Join和表扫描操作。生成的结果是一个立方体理论里的数据立方(或者可以把它叫做“实例化的总结表”,如果这样听起来觉得更好的话)。 如图3所示,最初的执行计划就被转换成了基于数据立方之上。这个数据立方体包含了按照“returnflag(退货标记)”、“orderstatus(订单状态)”和“date(日期)”进行汇总的记录。因为退货标记和订单状态是一个固定的数量,而日期范围被限定在3年(大概1000天)。这就意味着这个数据立方体里的行数最多就是“标记数×状态数×天数”,对O定义的时间复杂度来说就是一个常量。这个新的执行计划将会保证不管源数据有多大都有一个固定的执行时间。这就是我们想要的效果! Kylin的架构一览 如我们所见,Kylin是一个依赖于预计算的系统。其核心是基于经典的立方体理论,并发展成一个大数据上的SQL解决方案(见图4)。它使用模型和立方体概念来定义预计算的空间。构建引擎从数据源载入数据,并在使用MapReduce或Spark的分布式系统上进行预计算。被计算出来的立方体被存储在HBase里。当一个查询来到时,Kylin把它编译成一个关系表达式,找到匹配的模型,并基于预计算好的数据立方体而不是原始数据执行这个表达式。 这里的关键就是建模。如果你对数据以及分析的需求有非常好的理解,你是可以用正确的模型和立方体定义来找到正确的预计算。接着,绝大多数(如果不是全部)的查询都可以被转化成对此立方体的查询。如图5所示,执行时间复杂度可以被降低到O(1),从而获得非常快的查询速度,无论原始数据有多大。 Kylin 2.0的特性 对雪花模型的支持和TPC-H基准测试 Kylin 2.0引入了对元数据建模的增强,并且可以支持开箱即用的雪花模型。为了演示建模和SQL能力上的改进,我们进行了用Kylin 2.0运行TPC-H查询的基准测试。 需要注意的是,这里的目标并不是想与其他人的TPC-H结果进行比较。一方面,根据TPC-H规范,不允许在表之间进行预先计算,因此在这个意义上,Kylin不能算是有效的TPC-H系统。另一方面,我们还没有对这些查询进行性能调优。改善的空间还是很大的。 根据相同的零售场景,让我们快速查看一些有趣的TPC-H查询。图6是TPC-H查询07。SQL里面的字太小,可能看不清楚,但它给出了查询的复杂性的粗略感觉。该图是执行计划,强调了预计算(白色)与在线计算(蓝色)的部分。很容易看出,大部分关系运算符是预先计算的。剩下的Sort / Proj / Filter在很少的记录上工作,因此查询可以超快。在相同的硬件和相同的数据集上,Kylin用了0.17秒完成,而Hive + Tez对此查询运行了35.23秒。这显示了预计算所带来的差异。 图7所示的TPC-H查询11是另一个例子。这个查询有四个子查询,比前一个更复杂。 其执行计划包括两个分支,每个分支从预先计算的立方体载入数据。 分支结果再连接起来,这是一个复杂的在线计算。随着在线计算部分的增加,预计算的部分减少,Kylin的运行时间更长:3.42秒。 然而,完全在线计算的Hive + Tez仍然要慢一点,运行时间为15.87秒。 为近实时分析准备的流式立方体 预先计算给ETL流程增加了额外的时间,这在实时场景中会成为一个问题。为了解决这个问题,Kylin现在支持增量加载新添加的数据,而不会影响历史数据。 已有RestAPI可用于自动触发增量构建。每日构建一次是最常见的,现在更频繁的数据加载也是可行的。 从1.6版开始,Kylin可以直接从Kafka获取数据,并进行近乎实时的数据分析。使用基于内存的立方体算法,微型增量构建可以在几分钟内完成。生成的结果是许多小的立方体分片,可以给查询提供实时的结果。 该演示按照语言和设备维度显示了Twitter消息的趋势。在图8中可以看到,美国白天的英文消息量上升,而亚洲语言的消息量在夜间下降。演示里还有一个标签云,用以显示最新的热门话题。在标签云下面是最热门标签的趋势。所有图表都是实时到最近五分钟。 总结 Apache Kylin是Hadoop上一个流行的OLAP引擎。通过使用预计算技术,它可以使SQL对大数据的查询速度有数量级的加快,并使交互式BI和其他在线应用程序能够直接在大数据上运行。
Kylin 2.0是最新版本,可以在:https://kylin.apache.org/download/ 下载。新版本的特性包括:Hadoop上的小于秒级的SQL延迟; 雪花模型的支持和成熟的SQL功能; 流式立方体用于近实时分析; 内置时间/窗口/百分位数功能;和可以将构建时间缩短一半的Spark构建立方体。
相关资料:
Apache Kylin的星形模型基准测试
Apache Kylin的TPC-H基准测试
Kyligence的演示、交互式BI和Twitter流式分析
This article originally appeared in English: “Bringing interactive BI to big data”. Yang Li
Yang Li是Kyligence的联合创始人兼CTO,以及Apache Kylin项目的联合创立者和PMC成员。 作为Kylin的技术主管和架构师,Yang专注于大数据分析、并行计算、数据索引、关系代数、近似算法等技术。他曾任eBay分析数据基础设施部高级架构师。他还是IBM InfoSphere BigInsights的技术领导者。在此期间,他负责BigInsights这一基于Hadoop的开源平台,并获得了IBM杰出技术成就奖。他曾经是摩根士丹利的副总裁,负责全球监管报表基础架构。 来源:https://kyligence.io/zh/2017/06/02/apache-kylin-2-0-big-data-interactive-bi/
|