Apache Kylin权威指南(第2版)(txt+pdf+epub+mobi电子书下载)


发布时间:2021-02-23 13:40:38

点击下载

作者:Apache Kylin核心团队

出版社:机械工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

Apache Kylin权威指南(第2版)

Apache Kylin权威指南(第2版)试读:

前言

“麒麟出没,必有祥瑞。”——中国古谚语“与Apache Kylin团队一起合作使Kylin孵化成为顶级项目对我而言非常激动人心,Kylin在技术方面当然是振奋人心的,但同样令人兴奋的是Kylin代表了亚洲国家,特别是中国,在开源社区中越来越高的参与度。”——Ted Dunning Apache孵化项目副总裁,MapR首席应用架构师

今天,随着移动互联网、物联网、AI等各种技术的快速兴起,数据成了所有这些技术背后最重要,也是最有价值的“资产”。如何从数据中获得有价值的信息呢?这个问题驱动了相关技术的发展,从最初的基于文件的检索、分析程序,到数据仓库理念的诞生,再到基于数据库的商业智能分析。而现在,我们关注的问题已经变成如何从海量的超大规模数据中快速获取有价值的信息。在新的时代,面对新的挑战,新的技术必然会应运而生。

在数据分析领域,大部分的技术都诞生在国外,特别是美国,从最初的数据库,到Hadoop为首的大数据技术,再到今天各种深度学习、AI等。但我国却又拥有世界上独一无二的“大”数据——最多的人口、最多的移动设备、最活跃的应用市场、最复杂的网络环境……面对这些挑战,我们需要有自己的核心技术,特别是在基础领域的突破和研发。今天,以Apache Kylin为首的各种来自中国的先进技术不断涌现,甚至在很多方面都大大超越了来自国外的其他技术,彰显了中国的技术实力。

自Hadoop选取大象图标伊始,上百个项目,以动物居之者为多。而其中唯有Apache Kylin(麒麟)来自中国,在众多项目中分外突出。在全球最大的开源基金会——Apache软件基金会(Apache Software Foundation,ASF)的160多个顶级项目中,Apache Kylin是唯一一个来自中国的Apache顶级开源项目,与Apache Hadoop、Apache Spark、Apache Kafka、Apache Tomcat、Apache Struts、Apache Maven等顶级项目一起以“The Apache Way”构建开源大数据领域的国际社区,发展新技术并拓展生态系统。

大数据与传统技术的最大区别就在于数据的体量给查询带来的巨大挑战。从最早使用大数据技术来做批量处理,到现在越来越多的人要求大数据平台也能够如传统数据仓库技术一样支持交互式分析,随着数据量的不断膨胀、数据平民化的不断推进,低延迟、高并发地在Hadoop之上提供标准SQL查询能力成为必须攻破的技术难题。而Apache Kylin的诞生正是基于这个背景,并成功地完成了很多人认为不可能实现的突破。Apache Kylin最初诞生于eBay中国研发中心,该中心坐落于上海浦东新区。2013年9月底该研发中心开始进行POC测试并组建团队,经过一年的艰苦开发和测试,Apache Kylin于2014年9月30日正式上线,并在第二天,2014年10月1日,正式开源。

在这个过程中,面对使用何种技术、如何设计架构、如何突破那些看似无法完成的挑战等一系列技术难关,整个开发团队和用户一起经历了一个艰难的过程。今天呈现的Apache Kylin已经经历了上千亿甚至上万亿规模数据量的分析请求及上百家公司在实际生产环境中的检验,成为各个公司大数据分析平台不可替代的重要组成部分。本书将从Apache Kylin的架构和设计、各个模块的使用、与第三方的整合、二次开发以及开源实践等多个方面进行讲解,为读者呈现Apache Kylin最核心的设计理念和哲学、算法和技术等。

Apache Kylin社区的发展来之不易,自2014年10月开源至今已经有近五年的时间,从最初的几个研发人员发展到今天几十个贡献者、国内外上百家公司正式使用、连续两年获得InfoWorld Bossie Awards最佳开源大数据工具奖。来自Apache Kylin核心团队、贡献者、用户、导师、基金会等的帮助和无私奉献铸就了今天Apache Kylin活跃的社区,也使得此项技术得以在越来越多的场景下发挥作用。现在,由Apache Kylin核心团队撰写的本书即将出版,相信能更好地将相关的理论、设计、技术、架构等展现给各位朋友,希望能够让更多的朋友更加充分地理解Kylin的优势和适用的场景,更多地挖掘出Kylin的潜力。同时希望本书能够鼓励并吸引更多的人参与到Kylin项目和开源项目中,能够影响更多的人贡献更多的项目和技术到开源世界中。

此次《Apache Kylin权威指南》的再版工作,得到了Kyligence研发团队的大力支持,他们纷纷自愿参与,本书大部分内容的写作是利用节假日和休息时间完成的,每位参与者都将自己在工作中获得的最佳实践经验总结到了这本书中,他们分别是:史少锋、陈志雄、冯礼、翟娜、汤雪、赵勇杰、周浥尘、龙超、宗正、孙宇婕、周丁倩、李森辉等。在此对他们表示诚挚的感谢!韩卿Apache Kylin联合创建者及项目委员会主席2019年5月第1章 Apache Kylin概述

Apache Kylin是Hadoop大数据平台上的一个开源的联机分析处理(Online Analytical Processing,OLAP)引擎。它采用多维立方体预计算技术,将大数据的SQL查询速度从之前的分钟乃至小时级别提升到亚秒级别,这种百倍、千倍的速度提升,为超大规模数据集上的交互式大数据分析奠定了基础。

Apache Kylin也是第一个由中国人主导的Apache顶级开源项目,在国际开源社区具有极大的影响力。

本章将对Apache Kylin的历史和背景做一个完整的介绍,并从技术角度对Kylin做一个概括性的介绍。1.1 背景和历史

现今,大数据行业发展得如火如荼,新技术层出不穷,整个生态欣欣向荣。作为大数据领域最重要的技术的Apache Hadoop最初致力于简单的分布式存储,然后在此基础之上实现大规模并行计算,到如今在实时分析、多维分析、交互式分析、机器学习甚至人工智能等方面有了长足的发展。

2013年年初,在eBay内部使用的传统数据仓库及商业智能平台碰到了“瓶颈”,传统架构只支持垂直扩展,通过在一台计算机上增加CPU和内存等资源来提升计算机的数据处理能力。相对于数据指数级的增长,单机扩展很快达到极限,不可避免地遇到了“瓶颈”。此外,Hadoop大数据平台虽然能存储和批量处理大规模数据,但与BI平台的连接技术还不够成熟,无法提供高效的交互式查询。于是,寻找到更好的交互式大数据分析方案成为当务之急。

2013年年中,eBay公司启动了一个大数据项目,其中有一部分内容就是BI on Hadoop的预研。当时,eBay中国卓越中心组建了一支很小的团队,他们在分析和测试了多种开源和商业解决方案后,发现没有一种方案能够完全满足当时的需求,即在超大规模数据集上提供秒级的查询性能,并基于Hadoop与BI平台无缝整合等。在研究了多种可能性后,eBay最终决定自己来实现一套OLAP-on-Hadoop的解决方案,以弥补业界的此类空白。与此同时,eBay也非常鼓励各个项目开源、回馈社区,在给负责整个技术平台的高级副总裁做汇报的时候,得到的一个反馈就是“从第一天起就做好开源的准备”。

经过一年多的研发,2014年9月底,代号Kylin的大数据平台在eBay内部正式上线。Kylin在Hadoop上提供标准和友好的SQL接口,并且查询速度非常快,原本要几分钟才能完成的查询现在几秒钟就能返回结果,BI分析的工作效率得到几百倍的提升,获得了公司内部客户、合作伙伴及管理层的高度评价,一上线便吸引了多个种子客户。2014年10月1日,Kylin项目负责人韩卿将Kylin的源代码提交到github.com并正式开源。当天就得到了业界专家的关注和认可。图1-1所示为Hortonworks的CTO对Apache Kylin的Twitter评价。图1-1 Hortonworks的CTO对Apache Kylin的Twitter评论

很快,Hadoop社区的许多朋友都鼓励eBay将该项目贡献到Apache软件基金会(ASF),让它与其他大数据项目一起获得更好的发展,在经过一个月的紧张准备和撰写了无数个版本的项目建议书后,Kylin项目于2014年11月正式加入Apache孵化器项目,并由多位资深的社区活跃成员做项目导师。

在接下来的一年中,项目组再次做出了极大努力,包括按照Apache孵化器要求组建项目管理委员会(PMC)、建立项目网站、整理知识产权并签署必要协议、吸引外部开发者、发展多元化社区、发布多个正式版本等。2015年11月,Apache软件基金会宣布Apache Kylin正式成为顶级项目。

这是第一个完全由中国团队贡献到全球最大的开源软件基金会的顶级项目。项目负责人韩卿成为Apache Kylin项目管理委员会主席,也成为Apache软件基金会160多个顶级项目中的第一个中国人,Apache Kylin创造了历史。正如Kylin的导师,时任Apache孵化器副总裁的Ted Dunning在ASF官方新闻稿中评价的那样:“Apache Kylin代表了亚洲国家,特别是中国,在开源社区中越来越高的参与度。”

2016年3月,由Apache Kylin核心开发者组建的创业公司Kyligence正式成立。正如多数成功的开源项目背后都有一家创业公司一样(Hadoop领域有Cloudera、Hortonworks等;Spark有Databricks;Kafka有Confluent等),Kylin也可以通过Kyligence公司的进一步投入保证高速研发,并且Kylin的社区和生态圈也会得到不断的发展和壮大,可以预见这个开源项目将会越来越好。

在业界极具盛名的技术类独立评选中,InfoWorld的Bossie Award每年都会独立挑选和评论相关的技术、应用和产品等。2015年9月,Apache Kylin与Apache Spark、Apache Kafka、H2O、Apache Zeppelin等一同获得了2015年度“最佳开源大数据工具奖”。这是业界对Apache Kylin的充分认可和褒奖。2016年的InfoWorld获奖榜单进一步收窄,获奖者数量较前一年减少一半,一些新兴项目如Google领导的TensorFlow、Apache Beam崭露头角,值得骄傲的是,Apache Kylin再次登上领奖台,蝉联“最佳开源大数据工具奖”。

Apache Kylin在社区开发者的共同努力下进一步发展和完善,先后发布了1.6、2.0~2.5多个版本,涵盖近实时流、Spark引擎、RDBMS数据源、Cube Planner,支持Hadoop 3.0等众多新功能,还有一些新功能正在进行公开beta测试,如Parquet存储引擎、完全实时流数据等,预计在不远的将来会正式发布。同时,Apache Kylin用户群也在不断发展壮大,跨越亚洲、美洲、欧洲、澳洲等地。据粗略计算,全球已经有超过一千家企业将Apache Kylin用于自身的关键业务分析。1.2 Apache Kylin的使命

Apache Kylin的使命是实现超高速的大数据OLAP分析,也就是要让大数据分析像使用数据库一样简单迅速,用户的查询请求可以在秒级返回,交互式数据分析以前所未有的速度释放大数据里潜藏的知识和信息,以使我们在面对未来的挑战时占得先机。1.2.1 为什么要使用Apache Kylin

自2006年Hadoop诞生以来,大数据的存储和批处理问题得到了妥善解决,而如何高速地分析数据也就成为下一个挑战。于是各种“SQL-on-Hadoop”技术应运而生,其中以Hive为代表,Impala、Presto、Phoenix、Drill、Spark SQL等紧随其后,它们的主要技术是“大规模并行处理”(Massively Parallel Processing,MPP)和“列式存储”(Columnar Storage)。

大规模并行处理可以调动多台机器进行并行计算,用线性增加资源来换取计算时间的线性下降。列式存储则将记录按列存放,不仅在访问时可以只读取需要的列,更可以利用存储设备擅长连续读取的特点,大大提高读取的速率。这两项关键技术使得Hadoop上的SQL查询速度从小时级提高到了分钟级。

然而分钟级别的查询响应仍然与交互式分析的现实需求相差很远。分析师敲入查询指令,按下回车键后,需要去倒杯咖啡,静静地等待结果。得到结果后才能根据情况调整查询,再做下一轮分析。如此反复,一个具体的场景分析常常需要几个小时甚至几天才能完成,数据分析效率低下。

这是因为大规模并行处理和列式存储虽然提高了计算和存储的速度,但并没有改变查询问题本身的时间复杂度,也没有改变查询时间与数据量呈线性增长的关系这一事实。假设查询1亿条记录耗时1分钟,那么查询10亿条记录就需要10分钟,查询100亿条就至少需要1小时40分钟。

当然,有很多的优化技术可以缩短查询的时间,比如更快的存储、更高效的压缩算法等,但总体来说,查询性能与数据量呈线性相关这一事实无法改变。虽然大规模并行处理允许十倍或者百倍地扩张计算集群,以期保持分钟级别的查询速度,但购买和部署十倍、百倍的计算集群又很难做到,更何况还需要高昂的硬件运维成本。

另外,对于分析师来说,完备的、经过验证的数据模型比分析性能更加重要,直接访问纷繁复杂的原始数据并进行相关分析其实并不是很美好的体验,特别是在超大规模数据集上,分析师们把更多的精力花费在了等待查询结果上,而不是用在更加重要的建立领域模型上。1.2.2 Apache Kylin怎样解决关键问题

Apache Kylin的初衷就是解决千亿、万亿条记录的秒级查询问题,其中的关键就是打破查询时间随着数据量呈线性增长的这一规律。仔细思考大数据OLAP,我们可以注意到两个事实。

·大数据查询要的一般是统计结果,是多条记录经过聚合函数计算后的统计值。原始的记录则不是必需的,或者被访问的频率和概率极低。

·聚合是按维度进行的,而维度的聚合可能性是有限的,一般不随数据的膨胀而线性增长。

基于以上两点,我们得到一个新的思路——“预计算”。应尽量多地预先计算聚合结果,在查询时刻也尽量使用预计算的结果得出查询结果,从而避免直接扫描可能无限增长的原始记录。

举例来说,要用下面的SQL来查询10月1日那天销量最高的商品。SELECT item, SUM(sell_amount)FROM sell_detailsWHERE sell_date='2016-10-01'GROUP BY itemORDER BY SUM(sell_amount) DESC

传统的方法需要扫描所有的记录,找到10月1日的销售记录,然后按商品聚合销售额,最后排序返回。假如10月1日有1亿条交易,那么查询必需读取并累计至少1亿条记录,且查询速度会随将来销量的增加而逐步下降,如果日交易量提高至2亿条,那查询执行的时间可能会增加一倍。

而预计算的方法则会事先按维度[sell_date,item]计算SUM(sell_amount)并将其存储下来,在查询时找到10月1日的销售商品就可以直接排序返回了。读取的记录数最大不超过维度[sell_date,item]的组合数。显然这个数字将远远小于实际的销售记录,比如10月1日的1亿条交易包含了100万种商品,那么预计算后就只有100万条记录了,是原来的百分之一。并且这些记录是已经按商品聚合的结果,省去了运行时的聚合运算。从未来的发展来看,查询速度只会随日期和商品数目的增长而变化,与销售记录总数不再有直接联系。假如日交易量提高一倍到2亿,但只要商品总数不变,那么预计算的结果记录总数就不会变,查询的速度也不会变。“预计算”就是Kylin在“大规模并行处理”和“列式存储”之外,提供给大数据分析的第三个关键技术。1.3 Apache Kylin的工作原理

Apache Kylin的工作原理本质上是MOLAP(Multidimensional Online Analytical Processing)Cube,也就是多维立方体分析。这是数据分析中相当经典的理论,在关系型数据库年代就有广泛应用,下面对其做简要介绍。1.3.1 维度和度量简介

在说明MOLAP Cube之前,需要先介绍一下维度(dimension)和度量(measure)这两个概念。

简单来讲,维度就是观察数据的角度。比如电商的销售数据,可以从时间的维度来观察(如图1-2的左图所示),也可以进一步细化从时间和地区的维度来观察(如图1-2的右图所示)。维度一般是一组离散的值,比如时间维度上的每一个独立的日期,或者商品维度上的每一件独立的商品。因此,统计时可以把维度值相同的记录聚合起来,应用聚合函数做累加、平均、去重复计数等聚合计算。图1-2 维度和度量

度量就是被聚合的统计值,也是聚合运算的结果,它一般是连续值,如图1-2中的销售额,抑或是销售商品的总件数。通过比较和测算度量,分析师可以对数据进行评估,比如今年的销售额相比去年有多大的增长、增长的速度是否达到预期、不同商品类别的增长比例是否合理等。1.3.2 Cube和Cuboid

了解了维度和度量,就可以对数据表或者数据模型上的所有字段进行分类了,它们要么是维度,要么是度量(可以被聚合)。于是就有了根据维度、度量做预计算的Cube理论。

给定一个数据模型,我们可以对其上所有维度进行组合。对于NN个维度来说,所有组合的可能性有2种。对每一种维度的组合,将度量做聚合运算,运算的结果保存为一个物化视图,称为Cuboid。将所有维度组合的Cuboid作为一个整体,被称为Cube。所以简单来说,一个Cube就是许多按维度聚合的物化视图的集合。

举一个具体的例子。假定有一个电商的销售数据集,其中维度有时间(Time)、商品(Item)、地点(Location)和供应商(Supplier),度量有销售额(GMV)。那么,所有维度的组合就有42=16种(如图1-3所示),比如一维度(1D)的组合有[Time][Item][Location][Supplier]四种;二维度(2D)的组合有[Time,Item][Time,Location][Time、Supplier][Item,Location][Item,Supplier][Location,Supplier]六种;三维度(3D)的组合也有四种;最后,零维度(0D)和四维度(4D)的组合各有一种,共计16种组合。

计算Cuboid,就是按维度来聚合销售额(GMV)。如果用SQL来表达计算Cuboid[Time,Location],那就是:select Time, Location, Sum(GMV) as GMV from Sales group by Time, Location图1-3 四维Cube

将计算的结果保存为物化视图,所有Cuboid物化视图的总称就是Cube了。1.3.3 工作原理

Apache Kylin的工作原理就是对数据模型做Cube预计算,并利用计算的结果加速查询。过程如下:(1)指定数据模型,定义维度和度量。(2)预计算Cube,计算所有Cuboid并将其保存为物化视图。(3)执行查询时,读取Cuboid,进行加工运算产生查询结果。

由于Kylin的查询过程不会扫描原始记录,而是通过预计算预先完成表的关联、聚合等复杂运算,并利用预计算的结果来执行查询,因此其速度相比非预计算的查询技术一般要快一个到两个数量级。并且在超大数据集上其优势更明显。当数据集达到千亿乃至万亿级别时,Kylin的速度甚至可以超越其他非预计算技术1000倍以上。1.4 Apache Kylin的技术架构

Apache Kylin系统可以分为在线查询和离线构建两部分,其技术架构如图1-4所示。在线查询主要由上半区组成,离线构建在下半区。

先看离线构建的部分。从图1-4中可以看到,数据源在左侧,目前主要是Hadoop、Hive、Kafka和RDBMS,其中保存着待分析的用户数据。根据元数据定义,下方构建引擎从数据源中抽取数据,并构建Cube。数据以关系表的形式输入,且必须符合星形模型(Star Schema)或雪花模型(Snowflake Schema)。用户可以选择使用MapReduce或Spark进行构建。构建后的Cube保存在右侧的存储引擎中,目前HBase是默认的存储引擎。图1-4 Apache Kylin技术架构

完成离线构建后,用户可以从上方查询系统发送SQL来进行查询分析。Kylin提供了多样的REST API、JDBC/ODBC接口。无论从哪个接口进入,最终SQL都会来到REST服务层,再转交给查询引擎进行处理。这里需要注意的是,SQL语句是基于数据源的关系模型书写的,而不是Cube。Kylin在设计时刻意对查询用户屏蔽了Cube的概念,分析师只需要理解简单的关系模型就可以使用Kylin,没有额外的学习门槛,传统的SQL应用也更容易迁移。查询引擎解析SQL,生成基于关系表的逻辑执行计划,然后将其转译为基于Cube的物理执行计划,最后查询预计算生成的Cube产生结果。整个过程不访问原始数据源。注意 对于查询引擎下方的路由选择,在最初设计时考虑过将Kylin不能执行的查询引导到Hive中继续执行。但在实践后发现Hive与Kylin的执行速度差异过大,导致用户无法对查询的速度有一致的期望,大多语句很可能查询几秒就返回了,而有些要等几分钟到几十分钟,用户体验非常糟糕。最后这个路由功能在发行版中默认被关闭。

Apache Kylin v1.5版本引入了“可扩展架构”的概念。图1-4所示为Rest Server、Cube Build Engine和数据源表示的抽象层。可扩展是指Kylin可以对其三个主要依赖模块——数据源、构建引擎和存储引擎,做任意的扩展和替换。在设计之初,作为Hadoop家族的一员,这三者分别是Hive、MapReduce和HBase。但随着Apache Kylin的推广和使用的深入,用户发现它们存在不足之处。

比如,实时分析可能会希望从Kafka导入数据而不是从Hive;而Spark的迅速崛起,又使我们不得不考虑将MapReduce替换为Spark以提高Cube的构建速度;至于HBase,它的读性能可能不如Cassandra等。可见,是否可以将某种技术替换为另一种技术已成为一个常见的问题。于是,我们对Apache Kylin v1.5版本的系统架构进行了重构,将数据源、构建引擎、存储引擎三大主要依赖模块抽象为接口,而Hive、MapReduce、HBase只是默认实现。其他实现还有:数据源还可以是Kafka、Hadoop或RDBMS;构建引擎还可以是Spark、Flink。资深用户可以根据自己的需要做二次开发,将其中的一个或者多个技术替换为更适合自身需要的技术。

这也为Kylin技术的与时俱进奠定了基础。如果将来有更先进的分布式计算技术可以取代MapReduce,或者有更高效的存储系统全面超越了HBase,Kylin可以用较小的代价将一个子系统替换掉,从而保证Kylin紧跟技术发展的最新潮流,保持最高的技术水平。

可扩展架构也带来了额外的灵活性,比如,它可以允许多个引擎并存。例如,Kylin可以同时对接Hive、Kafka和其他第三方数据源;抑或用户可以为不同的Cube指定不同的构建引擎或存储引擎,以期达到极致的性能和功能定制。1.5 Apache Kylin的主要特点

Apache Kylin的主要特点包括支持SQL接口、支持超大数据集、秒级响应、可伸缩性、高吞吐率、BI及可视化工具集成等。1.5.1 标准SQL接口

尽管Apache Kylin内部以Cube技术为核心,对外却没有选用MDX(MultiDimensional eXpression)作为接口,而是以标准SQL接口作为对外服务的主要接口。MDX作为OLAP查询语言,从学术上来说是更加适合Kylin的选择,但实践表明,SQL是绝大多数分析人员最熟悉的工具,也是大多数应用程序使用的编程接口,它不仅简单易用,也代表了绝大多数用户的第一需求。

SQL需要以关系模型作为支撑,Kylin使用的查询模型是数据源中的关系模型表,一般而言也就是指Hive表。终端用户只需要像原来查询Hive表一样编写SQL查询语句,就可以无缝地切换到Kylin,几乎不需要进行额外的学习,甚至原本的Hive查询也因为与SQL同源,大多无须修改就能直接在Kylin上运行。标准SQL接口是Kylin能够快速推广的一个关键原因。

当然,Apache Kylin将来也可能推出MDX接口。事实上已经可以通过MDX转SQL的工具,让Kylin也能支持MDX。1.5.2 支持超大数据集

Apache Kylin对大数据的支撑能力可能是目前所有技术中最为先进的。2015年在eBay的生产环境中,Kylin就能支持百亿条记录的秒级查询,之后在移动应用场景下又有了千亿条记录秒级查询的案例。这些都是实际场景的应用,而非实验室中的理论数据。

因为使用了Cube预计算技术,在理论上,Kylin可以支撑的数据集大小没有上限,仅受限于存储系统和分布式计算系统的承载能力,并且查询速度不会随数据集的增大而减慢。Kylin在数据集规模上的局限性主要在于维度的个数和基数。它们一般由数据模型决定,不随数据规模的增加而线性增长,也就意味着,Kylin对未来数据增长有着更强的适应能力。

截至2019年1月,除了eBay作为孵化公司有广泛应用之外,国内外一线的互联网公司几乎都大规模地使用Apache Kylin,包括美团、百度、网易、京东、唯品会、小米、Strikingly、Expedia、Yahoo!JAPAN、Cisco等。此外,在传统行业中也有非常多的实际应用,包括中国移动、中国联通、中国银联、太平洋保险等。1.5.3 亚秒级响应

Apache Kylin有优异的查询响应速度,这得益于预计算,很多复杂的计算如连接、聚合,在离线的预计算过程中就已经完成,这大大降低了查询时所需的计算量,提高了查询响应速度。

根据可查询到的公开资料显示,Apache Kylin在某生产环境中90%的查询可以在3秒内返回结果。这不是说一部分SQL相当快,而是在数万种不同的应用SQL的真实生产系统中,绝大部分的查询非常迅速;在另一个真实案例中,对1000多亿条数据构建了立方体,90%的查询性能在1.18s以内,可见Kylin在超大规模数据集上表现优异。这与一些只在实验室中,只在特定查询情况下,采集的性能数据不可同日而语。

当然,并不是使用Apache Kylin就一定能获得最好的性能。针对特定的数据及查询模式,往往需要做进一步的性能调优、配置优化等,性能调优对于充分利用Apache Kylin至关重要。1.5.4 可伸缩性和高吞吐率

在保持高速响应的同时,Kylin有着良好的可伸缩性和很高的吞吐率。图1-5是网易的性能分享。左图是Apache Kylin与Mondrian/Oracle的查询速度的对比,可以看到在三个测试查询中,Kylin的查询速度分别比Mondrian/Oracle快147倍、314倍和59倍。

同时右图展现了Apache Kylin的高吞吐率和可伸缩性。在一个Apache Kylin实例中,Apache Kylin每秒可以处理近70个查询,已经远远高于每秒20个查询的一般水平。更理想的是,随着服务器的增加,其吞吐率也呈线性增加,在存在4个实例时达到每秒230个查询左右,而这4个实例仅部署在一台机器上,理论上添加更多的应用服务器后可以支持更高的并发率。图1-5 Apache Kylin的可伸缩性和高吞吐率

这主要还是归功于预计算降低了查询时所需的计算总量,使Apache Kylin可以在相同的硬件配置下承载更多的并发查询。1.5.5 BI及可视化工具集成

Apache Kylin提供了丰富的API与现有的BI工具集成,包括:

·ODBC接口:与Tableau、Excel、Power BI等工具集成。

·JDBC接口:与Saiku、BIRT等Java工具集成。

·Rest API:与JavaScript、Web网页集成。

分析师可以继续使用他们最熟悉的BI工具与Apache Kylin一同工作,或者在开放的API上做二次开发和深度定制。

另外,Apache Kylin的核心团队也贡献了Apache Zeppelin及Apache Superset的插件,Strikingly的工程师为Redash贡献了Apache Kylin连接器,用户可以使用Zeppelin、Superset、Redash等免费可视化工具来访问Redash Kylin。1.6 与其他开源产品的比较

与Apache Kylin一样致力于解决大数据查询问题的其他开源产品也有不少,比如Apache Drill、Apache Impala、Druid、Hive、Presto、SparkSQL等。本节将Apache Kylin与它们做一个简单的比较。

从底层技术的角度来看,这些开源产品有很大的共性,一些底层技术几乎被所有的产品一致采用,Apache Kylin也不例外。

·大规模并行处理(MPP):可以通过增加机器的方式来扩容处理速度,在相同的时间内处理更多的数据。

·列式存储:通过按列存储提高单位时间内数据的I/O吞吐率,还能跳过不需要访问的列。

·索引:利用索引配合查询条件,可以迅速跳过不符合查询条件的数据块,仅扫描需要扫描的数据内容。

·压缩:压缩数据然后存储,使得存储的密度更高,在有限的I/O速率下,在单位时间内读取更多的记录。

我们注意到,所有这些方法都只是提高了单位时间内计算机处理数据的能力,当大家都采用这些技术时,彼此之间的区别将只停留在实现层面的代码细节上。最重要的是,这些技术都不会改变一个事实,那就是处理时间与数据量之间的正比例关系。

当数据量翻倍,在不扩容的前提下,MPP需要两倍的时间来完成计算;列式存储需要两倍的存储空间;索引下符合条件的记录数也会翻倍;压缩后的数据大小也是之前的两倍。因此,查询速度也会随之变成之前的一半。当数据量十倍百倍地增加时,这些技术的查询速度就会十倍百倍地下降,最终无法完成查询。

Apache Kylin的特色在于,在上述底层技术之外,另辟蹊径地使用了独特的Cube预计算技术。预计算事先将数据按维度组合进行了聚合,将结果保存为物化视图。经过聚合,物化视图的规模就只由维度的基数决定,而不再随数据量的增加呈线性增长。以电商为例,如果业务扩张,交易量增加了10倍,只要交易数据的维度不变(供应商/商品种类数量不变),聚合后的物化视图依旧是原先的大小,查询的速度也将保持不变。

与同类产品相比,这一底层技术的区别使得Apache Kylin从外在功能上呈现出不同的特性,具体如下:

·SQL接口:除了Druid以外,所有的产品都支持SQL或类SQL接口。巧合的是,Druid也是除了Apache Kylin以外,相对查询性能最好的一个。这除了归功于Druid有自己的存储引擎之外,也可能得益于其较为受限的查询能力。

·大数据支持:大多数产品的查询能力在亿级到十亿级之间,更大的数据量将显著降低其查询性能。而Apache Kylin因为采用预计算技术,其查询速度不受数据量限制。有实际案例证明,在数据量达千亿级别时,Apache Kylin系统仍然能保持秒级别的查询性能。

·查询速度:如前所述,一般产品的查询速度都不可避免地随数据量的增加而下降。而Apache Kylin则更能够在数据量成倍增加的同时保持查询速度不变。而且这个差距将随着数据量的成倍增加而变得愈加明显。

·吞吐率:根据之前的实验数据,Apache Kylin的单服务器吞吐量一般在每秒70~150个查询,并且可以线性扩展。而普通的产品因为所有计算都在查询时完成,所以需要调动集群更多的资源才能完成查询,通常极限在每秒20个查询左右,而且扩容成本较高,需要扩展整个集群。相对地,Apache Kylin系统因其“瓶颈”不在于整个集群,而在于Apache Kylin服务器,因此只需要增加Apache Kylin服务器就能成倍提高吞吐率,扩容成本低廉。1.7 小结

本章介绍了Apache Kylin的背景历史和技术特点。尤其是它基于预计算的大数据查询原理,理论上它可以在任意大的数据规模上达到O(1)常数级别的查询速度,这是Apache Kylin与传统查询技术的关键区别,如图1-6所示。传统技术如大规模并行计算和列式存储的查询速度都在O(N)级别,与数据规模呈线性关系。如果数据规模扩大10倍,那么O(N)的查询速度就下降1/10,无法满足日益增长的数据分析需求。依靠Apache Kylin,我们不用再担心查询速度会随数据量的增加而降低,能更有信心面对未来的数据挑战。图1-6 查询时间复杂度O(1)与O(N)对比第2章 快速入门

第1章介绍了Apache Kylin的概况,以及它与其他SQL-on-Hadoop技术的不同,相信读者对Apache Kylin有了一个整体的认识。本章将详细介绍Apache Kylin的一些核心概念,然后带领读者一步步创建Cube,构建Cube,并通过SQL来查询Cube,使读者对Apache Kylin有更为直观的了解。2.1 核心概念

在使用Apache Kylin之前,需要先了解一下Apache Kylin中的各种概念和术语,为后续章节的学习奠定基础。2.1.1 数据仓库、OLAP与BI

数据仓库(Data Warehouse)是一种信息系统的资料储存理论,此理论强调的是利用某些特殊资料储存方式,让所包含的资料特别有利于分析处理,从而产生有价值的资讯并依此做决策。

利用数据仓库方式存放的资料,具有一旦存入,便不随时间变化而变动的特性,此外,存入的资料必定包含时间属性,通常,一个数据仓库会含有大量的历史性资料,并且它利用特定分析方式,从中发掘出特定的资讯。

OLAP(Online Analytical Process),即联机分析处理,它可以以多维度的方式分析数据,并且能弹性地提供上卷(Roll-up)、下钻(Drill-down)和透视分析(Pivot)等操作,是呈现集成性决策信息的方法,其主要功能在于方便大规模数据分析及统计计算,多用于决策支持系统、商务智能或数据仓库。与之相区别的是联机交易处理(OLTP),联机交易处理侧重于基本的、日常的事务处理,包括数据的增、删、改、查。

·OLAP需要以大量历史数据为基础,配合时间点的差异并对多维度及汇整型的信息进行复杂的分析。

·OLAP需要用户有主观的信息需求定义,因此系统效率较高。

OLAP的概念,在实际应用中存在广义和狭义两种不同的理解。广义上的理解与字面意思相同,泛指一切不对数据进行更新的分析处理,但更多的情况下OLAP被理解为狭义上的含义,即与多维分析相关,是基于立方体(CUBE)计算而进行的分析。

BI(Business Intelligence),即商务智能,是指用现代数据仓库技术、在线分析技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。

如今,许多企业已经建立了自己的数据仓库,用于存放和管理不断增长的数据,这些数据中蕴含着丰富的商业价值,但只有使用分析工具对其进行大量筛选、计算和展示后,数据中蕴含的规律、价值和潜在信息才能被人们所发现与利用。分析人员结合这些信息进行商业决策和市场活动,从而为用户提供更好的服务,为企业创造更大的价值。2.1.2 维度建模

维度建模用于决策制定,并侧重于业务如何表示和理解数据。基本的维度模型由维度和度量两类对象组成。维度建模尝试以逻辑、可理解的方式呈现数据,以使得数据的访问更加直观。维度设计的重点是简化数据和加快查询。

维度模型是数据仓库的核心。它经过精心设计和优化,可以为数据分析和商业智能(BI),检索并汇总大量的相关数据。在数据仓库中,数据修改仅定期发生,并且是一次性开销,而读取是经常发生的。对于一个数据检索效率比数据处理效率重要得多的数据结构而言,非标准化的维度模型是一个不错的解决方案。

在数据挖掘中有几种常见的多维数据模型,如星形模型(Star Schema)、雪花模型(Snowflake Schema)、事实星座模型(Fact Constellation)等。

星形模型中有一个事实表,以及零个或多个维度表,事实表与维度表通过主键外键相关联,维度表之间没有关联,就像很多星星围绕在一个恒星周围,故名为星形模型。

如果将星形模型中的某些维度表再做规范,抽取成更细的维度表,让维度表之间也进行关联,那么这种模型称为雪花模型。

事实星座模型是更为复杂的模型,其中包含多个事实表,而维度表是公用的,可以共享。2.1.3 事实表和维度表

事实表(Fact Table)是指存储事实记录的表,如系统日志、销售记录等,并且是维度模型中的主表,代表着键和度量的集合。事实表的记录会不断地动态增长,所以它的体积通常远大于其他表,通常事实表占据数据仓库中90%或更多的空间。

维度表(Dimension Table),也称维表或查找表(Lookup Table),是与事实表相对应的一种表。维度表的目的是将业务含义和上下文添加到数据仓库中的事实表和度量中。维度表是事实表的入口点,维度表实现了数据仓库的业务接口。它们基本上是事实表中的键引用的查找表。它保存了维度的属性值,可以与事实表做关联,相当于将事实表上经常出现的属性抽取、规范出来用一张表进行管理,常见的维度表有:日期表(存储日期对应的周、月、季度等属性)、地点表(包含国家、省/州、城市等属性)等。使用维度表的好处如下:

·减小了事实表的大小;

·便于维度的管理和维护,增加、删除和修改维度的属性时,不必对事实表的大量记录进行改动;

·维度表可以为多个事实表同时使用,减少重复工作。2.1.4 维度和度量

维度和度量是数据分析中的两个基本概念。

维度是人们观察数据的特定角度,是考虑问题时的一类属性。它通常是数据记录的一个特征,如时间、地点等。同时,维度具有层级概念,可能存在细节程度不同的描述方面,如日期、月份、季度、年等。

在数据仓库中,可以在数学上求和的事实属性称为度量。例如,可以对度量进行总计、平均、以百分比形式使用等。度量是维度模型的核心。通常,在单个查询中检索数千个或数百万个事实行,其中对结果集执行数学方程。

在一个SQL查询中,Group By的属性通常就是维度,而其所计算的值则是度量,如在下面这个查询中,part_dt和lstg_site_id是维度,sum(price)和count(distinct seller_id)是度量。select part_dt, lstg_site_id, sum(price) as total_selled, count(distinct seller_id)as sellers from kylin_sales group by part_dt, lstg_site_id2.1.5 Cube、Cuboid和Cube Segment

Cube(或称Data Cube),即数据立方体,是一种常用于数据分析与索引的技术,它可以对原始数据建立多维度索引,大大加快数据的查询效率。

Cuboid特指Apache Kylin中在某一种维度组合下所计算的数据。

Cube Segment指针对源数据中的某一片段计算出来的Cube数据。通常,数据仓库中的数据数量会随时间的增长而增长,而Cube Segment也是按时间顺序构建的。2.2 在Hive中准备数据

上一节介绍了Apache Kylin中的常见概念。在本节中将介绍准备Hive数据时的一些注意事项。需要进行分析的数据必须先保存为Hive表的形式,只有这样Apache Kylin才能从Hive中导入数据、创建Cube。

Apache Hive是一个基于Hadoop的数据仓库工具,最初由Facebook开发并贡献到Apache软件基金会。Hive可以将结构化的数据文件映射为数据库表,并可以将SQL语句转换为MapReduce或Tez任务运行,从而让用户以类SQL(HiveQL,HQL)的方式管理和查询Hadoop上的海量数据。

此外,Hive提供了多种方式(如命令行、API和Web服务等)供第三方方便地获取和使用元数据并进行查询。今天,Hive已经成为Hadoop数据仓库的首选,是Hadoop不可或缺的一个重要组件,很多项目都兼容或集成Hive。鉴于此,Apache Kylin选择Hive作为原始数据的主要来源。

在Hive中准备待分析的数据是使用Apache Kylin的前提。将数据导入Hive表的方法很多,用户管理数据的技术和工具也多种多样,故其具体步骤不在本书的讨论范围之内,如有需要可以参阅Hive的文档。这里着重阐述几个需要注意的事项。2.2.1 多维数据模型

目前Apache Kylin既支持星形数据模型,也支持雪花数据模型,这是基于以下考虑:

·星形模型与雪花模型是最为常用的数据模型;

·由于只有一个大表,相比于其他模型更适合大数据处理;

·其他模型可以通过一定的转换,变为星形模型或雪花模型。2.2.2 维度表的设计

除了数据模型以外,Apache Kylin还对维度表有一定的要求,如:

1)要具有数据一致性。主键值必须唯一,Apache Kylin会进行检查,如果有两行数据的主键相同,则系统就会报错。

2)维度表越小越好。Apache Kylin支持选择是否将维度表加载到内存中以供查询,过大的表不适合作为维度表,默认的阈值是300Mb。

3)改变频率低。Apache Kylin会在每次构建中试图重用维度表快照,如果维度表经常改变的话,重用就会失效,这会导致要经常对维度表创建快照。

4)维度表最好不是Hive视图(View),虽然在Apache Kylin v1.5.3中加入了对维度表是视图的支持,但每次都需要将视图物化,导致额外的时间成本。2.2.3 Hive表分区

Hive表支持多分区(partition)。简单来说,一个分区就是一个文件目录,存储了特定的数据文件。当有新的数据生成的时候,可以将数据加载到指定的分区,读取数据的时候也可以指定分区。对于SQL查询,如果查询中指定了分区列的属性条件,则Hive会智能地选择特定分区(目录),从而避免全量数据的扫描,减少读写操作对集群的压力。

下面的一组SQL语句,演示了如何使用分区:Hive> create table invites (id int, name string) partitioned by (ds string) row formatdelimited fields terminated by 't' stored as textfile;?Hive> load data local inpath '/user/hadoop/data.txt' overwrite into table invitespartition (ds='2016-08-16');?Hive> select * from invites where ds ='2016-08-16';?

Apache Kylin支持增量的Cube构建,通常是按时间属性来增量地从Hive表中抽取数据。如果Hive表正好是按此时间属性做分区的话,那么可以利用到Hive分区的好处,每次Hive构建的时候可以直接跳过不相干日期的数据,节省Cube构建的时间。这样的列在Apache Kylin里也称为分割时间列(partition time column),通常它应该也是Hive表的分区列。2.2.4 了解维度的基数

维度的基数(Cardinality)指的是该维度在数据集中出现的不同值的个数。例如,“国家”是一个维度,有200个不同的值,那么此维度的基数是200。通常,一个维度的基数为几十到几万,个别维度如“用户ID”的基数会超过百万甚至千万,基数超过一百万的维度通常被称为超高基数维度(Ultra High Cardinality,UHC),需要引起设计者的注意。

Cube中所有维度的基数可以体现Cube的复杂度,如果一个Cube中有多个超高基数维度,那么这个Cube膨胀的几率就会很高。在创建Cube前对所有维度的基数做一个了解,可以帮助设计合理的Cube。计算基数有多种途径,最简单的方法就是让Hive执行一个count distinct的SQL查询,同时Apache Kylin也提供了计算基数的方法,这部分内容会在2.4.1节中进行介绍。2.2.5 样例数据

如果需要一些简单数据来快速体验Apache Kylin,也可以使用Apache Kylin自带的样例数据。运行“${KYLIN_HOME}/bin/sample.sh”来导入样例数据,然后就能继续按下面的流程创建模型和Cube。下面的示例和配图都是基于样例数据制作的。2.3 安装和启动Apache Kylin

如果数据已经在Hive中准备好,并已经满足2.2节介绍的条件,那么就可以开始安装和使用Apache Kylin了。本节将介绍Apache Kylin的安装环境及启动方法。2.3.1 环境准备

众所周知,Apache Kylin依赖于Hadoop集群处理大量数据集。因此在安装Apache Kylin之前必须准备Hadoop环境。由于Apach Hadoop版本管理混乱,推荐安装Cloudera CDH或Hortonworks HDP等商业Hadoop发行版。

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载