大数据技术丛书
点击查看第二章
点击查看第三章
Apache Kylin权威指南（第2版）
Apache Kylin核心团队 著
Apache Kylin是Hadoop大数据平台上的一个开源的联机分析处理（Online Analytical Processing， OLAP）引擎。它采用多维立方体预计算技术，将大数据的SQL查询速度从之前的分钟乃至小时级别提升到亚秒级别，这种百倍、千倍的速度提升，为超大规模数据集上的交互式大数据分析奠定了基础。
Apache Kylin也是第一个由中国人主导的Apache顶级开源项目，在国际开源社区具有极大的影响力。
本章将对Apache Kylin的历史和背景做一个完整的介绍，并从技术角度对Kylin做一个概括性的介绍。
现今，大数据行业发展得如火如荼，新技术层出不穷，整个生态欣欣向荣。作为大数据领域最重要的技术的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评价。
很快，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 用于自身的关键业务分析。
Apache Kylin的使命是实现超高速的大数据OLAP分析，也就是要让大数据分析像使用数据库一样简单迅速，用户的查询请求可以在秒级返回，交互式数据分析以前所未有的速度释放大数据里潜藏的知识和信息，以使我们在面对未来的挑战时占得先机。
自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分钟。
当然，有很多的优化技术可以缩短查询的时间，比如更快的存储、更高效的压缩算法等，但总体来说，查询性能与数据量呈线性相关这一事实无法改变。虽然大规模并行处理允许十倍或者百倍地扩张计算集群，以期保持分钟级别的查询速度，但购买和部署十倍、百倍的计算集群又很难做到，更何况还需要高昂的硬件运维成本。
另外，对于分析师来说，完备的、经过验证的数据模型比分析性能更加重要，直接访问纷繁复杂的原始数据并进行相关分析其实并不是很美好的体验，特别是在超大规模数据集上，分析师们把更多的精力花费在了等待查询结果上，而不是用在更加重要的建立领域模型上。
Apache Kylin的初衷就是解决千亿、万亿条记录的秒级查询问题，其中的关键就是打破查询时间随着数据量呈线性增长的这一规律。仔细思考大数据OLAP，我们可以注意到两个事实。
基于以上两点，我们得到一个新的思路—“预计算”。应尽量多地预先计算聚合结果，在查询时刻也尽量使用预计算的结果得出查询结果，从而避免直接扫描可能无限增长的原始记录。
举例来说，要用下面的SQL来查询10月1日那天销量最高的商品。
传统的方法需要扫描所有的记录，找到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在“大规模并行处理”和“列式存储”之外，提供给大数据分析的第三个关键技术。
Apache Kylin的工作原理本质上是MOLAP（Multidimensional Online Analytical Processing） Cube，也就是多维立方体分析。这是数据分析中相当经典的理论，在关系型数据库年代就有广泛应用，下面对其做简要介绍。
在说明MOLAP Cube之前，需要先介绍一下维度（dimension）和度量（measure）这两个概念。
简单来讲，维度就是观察数据的角度。比如电商的销售数据，可以从时间的维度来观察（如图1-2的左图所示），也可以进一步细化从时间和地区的维度来观察（如图1-2的右图所示）。维度一般是一组离散的值，比如时间维度上的每一个独立的日期，或者商品维度上的每一件独立的商品。因此，统计时可以把维度值相同的记录聚合起来，应用聚合函数做累加、平均、去重复计数等聚合计算。
度量就是被聚合的统计值，也是聚合运算的结果，它一般是连续值，如图1-2中的销售额，抑或是销售商品的总件数。通过比较和测算度量，分析师可以对数据进行评估，比如今年的销售额相比去年有多大的增长、增长的速度是否达到预期、不同商品类别的增长比例是否合理等。
了解了维度和度量，就可以对数据表或者数据模型上的所有字段进行分类了，它们要么是维度，要么是度量（可以被聚合）。于是就有了根据维度、度量做预计算的Cube理论。
给定一个数据模型，我们可以对其上所有维度进行组合。对于N个维度来说，所有组合的可能性有2N种。对每一种维度的组合，将度量做聚合运算，运算的结果保存为一个物化视图，称为Cuboid。将所有维度组合的Cuboid作为一个整体，被称为Cube。所以简单来说，一个Cube就是许多按维度聚合的物化视图的集合。
举一个具体的例子。假定有一个电商的销售数据集，其中维度有时间(Time)、商品(Item)、地点(Location)和供应商(Supplier)，度量有销售额(GMV)。那么，所有维度的组合就有24=16种（如图1-3所示），比如一维度（1D）的组合有TimeLocation四种；二维度（2D）的组合有Time, ItemTime、SupplierItem, Supplier六种；三维度（3D）的组合也有四种；最后，零维度（0D）和四维度（4D）的组合各有一种，共计16种组合。
计算Cuboid，就是按维度来聚合销售额(GMV)。如果用SQL来表达计算Cuboid [Time, Location]，那就是：
select Time, Location, Sum(GMV) as GMV from Sales group by Time, Location
将计算的结果保存为物化视图，所有Cuboid物化视图的总称就是Cube了。
Apache Kylin的工作原理就是对数据模型做Cube预计算，并利用计算的结果加速查询。过程如下：
（1）指定数据模型，定义维度和度量。
（2）预计算Cube，计算所有Cuboid并将其保存为物化视图。
（3）执行查询时，读取Cuboid，进行加工运算产生查询结果。
由于Kylin的查询过程不会扫描原始记录，而是通过预计算预先完成表的关联、聚合等复杂运算，并利用预计算的结果来执行查询，因此其速度相比非预计算的查询技术一般要快一个到两个数量级。并且在超大数据集上其优势更明显。当数据集达到千亿乃至万亿级别时，Kylin的速度甚至可以超越其他非预计算技术1000倍以上。
Apache Kylin系统可以分为在线查询和离线构建两部分，其技术架构如图1-4所示。在线查询主要由上半区组成，离线构建在下半区。
先看离线构建的部分。从图1-4中可以看到，数据源在左侧，目前主要是Hadoop、Hive、Kafka和 RDBMS，其中保存着待分析的用户数据。根据元数据定义，下方构建引擎从数据源中抽取数据，并构建Cube。数据以关系表的形式输入，且必须符合星形模型（Star Schema）或雪花模型（Snowflake Schema）。用户可以选择使用MapReduce或Spark进行构建。构建后的Cube保存在右侧的存储引擎中，目前HBase是默认的存储引擎。
完成离线构建后，用户可以从上方查询系统发送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指定不同的构建引擎或存储引擎，以期达到极致的性能和功能定制。
Apache Kylin的主要特点包括支持SQL接口、支持超大数据集、秒级响应、可伸缩性、高吞吐率、BI及可视化工具集成等。
尽管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。
Apache Kylin对大数据的支撑能力可能是目前所有技术中最为先进的。2015年在eBay的生产环境中，Kylin就能支持百亿条记录的秒级查询，之后在移动应用场景下又有了千亿条记录秒级查询的案例。这些都是实际场景的应用，而非实验室中的理论数据。
因为使用了Cube预计算技术，在理论上，Kylin可以支撑的数据集大小没有上限，仅受限于存储系统和分布式计算系统的承载能力，并且查询速度不会随数据集的增大而减慢。Kylin在数据集规模上的局限性主要在于维度的个数和基数。它们一般由数据模型决定，不随数据规模的增加而线性增长，也就意味着，Kylin对未来数据增长有着更强的适应能力。
截至2019年1月 ，除了eBay作为孵化公司有广泛应用之外，国内外一线的互联网公司几乎都大规模地使用Apache Kylin，包括美团、百度、网易、京东、唯品会、小米、Strikingly、Expedia、Yahoo！JAPAN、Cisco等。此外，在传统行业中也有非常多的实际应用，包括中国移动、中国联通、中国银联、太平洋保险等。
Apache Kylin有优异的查询响应速度，这得益于预计算，很多复杂的计算如连接、聚合，在离线的预计算过程中就已经完成，这大大降低了查询时所需的计算量，提高了查询响应速度。
根据可查询到的公开资料显示，Apache Kylin在某生产环境中90%的查询可以在3秒内返回结果。这不是说一部分SQL相当快，而是在数万种不同的应用SQL的真实生产系统中，绝大部分的查询非常迅速；在另一个真实案例中，对1000多亿条数据构建了立方体，90%的查询性能在1.18s以内，可见Kylin在超大规模数据集上表现优异。这与一些只在实验室中，只在特定查询情况下，采集的性能数据不可同日而语。
当然，并不是使用Apache Kylin就一定能获得最好的性能。针对特定的数据及查询模式，往往需要做进一步的性能调优、配置优化等，性能调优对于充分利用Apache Kylin至关重要。
在保持高速响应的同时，Kylin有着良好的可伸缩性和很高的吞吐率。图1-5是网易的性能分享。左图是Apache Kylin与Mondrian/Oracle的查询速度的对比，可以看到在三个测试查询中，Kylin的查询速度分别比Mondrian/Oracle快147倍、314倍和59倍。
同时右图展现了Apache Kylin的高吞吐率和可伸缩性。在一个Apache Kylin实例中，Apache Kylin每秒可以处理近70个查询，已经远远高于每秒20个查询的一般水平。更理想的是，随着服务器的增加，其吞吐率也呈线性增加，在存在4个实例时达到每秒230个查询左右，而这4个实例仅部署在一台机器上，理论上添加更多的应用服务器后可以支持更高的并发率。
这主要还是归功于预计算降低了查询时所需的计算总量，使Apache Kylin可以在相同的硬件配置下承载更多的并发查询。
Apache Kylin提供了丰富的API与现有的BI工具集成，包括：
分析师可以继续使用他们最熟悉的BI工具与Apache Kylin一同工作，或者在开放的API上做二次开发和深度定制。
另外，Apache Kylin的核心团队也贡献了Apache Zeppelin及Apache Superset的插件，Strikingly的工程师为Redash 贡献了Apache Kylin连接器，用户可以使用Zeppelin、Superset、Redash等免费可视化工具来访问Redash Kylin。
与Apache Kylin一样致力于解决大数据查询问题的其他开源产品也有不少，比如Apache Drill、Apache Impala、Druid、Hive、Presto、SparkSQL等。本节将Apache Kylin与它们做一个简单的比较。
从底层技术的角度来看，这些开源产品有很大的共性，一些底层技术几乎被所有的产品一致采用，Apache Kylin也不例外。
我们注意到，所有这些方法都只是提高了单位时间内计算机处理数据的能力，当大家都采用这些技术时，彼此之间的区别将只停留在实现层面的代码细节上。最重要的是，这些技术都不会改变一个事实，那就是处理时间与数据量之间的正比例关系。
当数据量翻倍，在不扩容的前提下，MPP需要两倍的时间来完成计算；列式存储需要两倍的存储空间；索引下符合条件的记录数也会翻倍；压缩后的数据大小也是之前的两倍。因此，查询速度也会随之变成之前的一半。当数据量十倍百倍地增加时，这些技术的查询速度就会十倍百倍地下降，最终无法完成查询。
Apache Kylin的特色在于，在上述底层技术之外，另辟蹊径地使用了独特的Cube预计算技术。预计算事先将数据按维度组合进行了聚合，将结果保存为物化视图。经过聚合，物化视图的规模就只由维度的基数决定，而不再随数据量的增加呈线性增长。以电商为例，如果业务扩张，交易量增加了10倍，只要交易数据的维度不变（供应商/商品种类数量不变），聚合后的物化视图依旧是原先的大小，查询的速度也将保持不变。
与同类产品相比，这一底层技术的区别使得Apache Kylin从外在功能上呈现出不同的特性，具体如下：
本章介绍了Apache Kylin的背景历史和技术特点。尤其是它基于预计算的大数据查询原理，理论上它可以在任意大的数据规模上达到O(1)常数级别的查询速度，这是Apache Kylin与传统查询技术的关键区别，如图1-6所示。传统技术如大规模并行计算和列式存储的查询速度都在O(N)级别，与数据规模呈线性关系。如果数据规模扩大10倍，那么O(N)的查询速度就下降1/10，无法满足日益增长的数据分析需求。依靠Apache Kylin，我们不用再担心查询速度会随数据量的增加而降低，能更有信心面对未来的数据挑战。
简体中文
