Apache Kylin-大数据分析界的『神兽』
21CTO社区导读：
本文为李栋先生作品，他来自Kyligence公司，也是Apache Kylin Committer & PMC member，在加入Kyligence之前曾就职于eBay、微软。
21CTO社区对其做了修正和完善。
什么是 Apache Kylin
在大数据时代，越来越多的企业开始使用Hadoop管理数据，但是现有的业务分析工具（如Tableau，Microstrategy等）往往存在着很大的局限，如难以水平扩展、无法处理超大规模数据、缺少对Hadoop的支持；而利用Hadoop做数据分析依然存在诸多障碍，例如大多数分析师只习惯使用SQL，Hadoop难以实现快速交互式查询等等。神兽Apache Kylin就是为了解决这些问题而设计的。
Apache Kylin，中文名麒麟。是Hadoop动物园之重要成员。
它是一个开源的分布式分析引擎，最初由eBay开发贡献至开源社区。它提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持大规模数据，能够处理TB乃至PB级别的分析任务，能够在亚秒级查询巨大的Hive表，并支持高并发。
Apache Kylin在2014年10月在Github上开源，并很快在2014年11月加入Apache孵化器，于2015年11月正式毕业成为Apache顶级项目，也成为首个完全由中国团队设计开发的Apache顶级项目。在2016年3月，Apache Kylin核心开发成员们又创建了Kyligence公司，力求更好地推动项目和社区的快速发展。
Kylin的基本原理和架构
下面，我们开始了解 Kylin的基本原理和架构。Kylin的核心思想是预计算，即对多维分析可能用到的度量进行预计算，将计算好的结果保存成 Cube，供查询时直接访问。把高复杂度的聚合运算、多表连接等操作转换成对预计算结果的查询，这决定了Kylin能够拥有很好的快速查询和高并发能力。
上图所示就是一个Cube的例子，假设我们有4个dimension，这个Cube中每个节点（称作Cuboid）都是这4个dimension的不同组合，每个组合定义了一组分析的dimension（如group by），measure的聚合结果就保存在这每个Cuboid上。查询时根据SQL找到对应的Cuboid，读取measure的值，即可返回。
为了更好的适应大数据环境，Kylin从数据仓库中最常用的Hive中读取源数据，使用 MapReduce作为Cube构建的引擎，并把预计算结果保存在HBase中，对外暴露Rest API/JDBC/ODBC的查询接口。因为Kylin支持标准的ANSI SQL，所以可以和常用分析工具（如Tableau、Excel等）进行无缝对接。
下面是Kylin的架构图（方便大家理解，我们找到了两个版本）。
Kylin架构图
Kylin架构图官方版
说到Cube的构建，Kylin提供了一个称作Layer Cubing的算法。简单来说，就是按照dimension数量从大到小的顺序，从Base Cuboid开始，依次基于上一层Cuboid的结果进行再聚合。每一层的计算都是一个单独的Map Reduce任务。请看下图所示。
MapReduce的计算结果最终保存到HBase中，HBase中每行记录的Rowkey由dimension组成，measure会保存在 column family中。为了减小存储代价，这里会对dimension和measure进行编码。查询阶段，利用HBase列存储的特性就可以保证Kylin有 良好的快速响应和高并发。
有了这些预计算的结果，当收到用户的SQL请求，Kylin会对SQL做查询计划，并把本该进行的Join、Sum、Count Distinct等操作改写成Cube的查询操作。
Kylin提供了一个原生的Web界面，在这里，用户可以方便的创建和设置Cube、管控Cube构建进度，并提供SQL查询和基本的结果可视化。
根据公开数据显示，Kylin的查询性能不只是针对个别SQL，而是对上万种SQL 的平均表现，生产环境下90%ile查询能够在在3秒钟内返回。
就在上个月举办的Apache Kylin Meetup中，来自美团、京东、百度等互联网公司分享了他们的使用情况。例如，在京东云的案例中，单个Cube最大有8个维度，最大数据条数4亿，最大存储空间800G，30个Cube共占存储空间4T左右。查询性能上，当QPS在50左右，所有查询平均在200ms以内，当QPS在200左右，平均响应时间在1秒以内。
北京移动技术团队也在meetup上展示了Kylin在电信运营商的应用案例，从数据上看，Kylin能够在比Hive/SparkSQL在更弱的硬件配置下获得更好的查询性能。
目前有越来越多的国内外公司将Kylin作为大数据生产环境中的重要组件，如Ebay、银联、百度、中国移动等。大家如果想了解更多社区的案例和动态，可以登录Apache Kylin官网或Kyligence博客进行查看。
Kylin的最新特性
Kylin的最新版本1.5.x引入了不少让人期待的新功能，可扩展架构将Kylin的三大依赖（数据源、Cube引擎、存储引擎）彻底解耦。Kylin将不再直接依赖于Hadoop/HBase/Hive，而是把Kylin作为一个可扩展的平台暴露抽象接口，具体的实现以插件的方式指定所用的数据源、引擎和存储。
开发者和用户可以通过定制开发，将Kylin接入除Hadoop/HBase/Hive以外的大数据系统，比如用Kafka代替Hive作数据源，用 Spark代替MapReduce做计算引擎，用Cassandra代替HBase做存储，都将变得更为简单。
这保证了Kylin可以随平台技术一起演进，紧跟技术潮流。
在Kylin 1.5.x中还对HBase存储结构进行了部分调整，将大的Cuboid分片存储，将线性扫描改良为并行扫描。基于上万查询进行了测试对比结果显示，分片的存储结构能够极大提速原本较慢的查询5-10倍，但对原本较快的查询提速不明显，综合起来平均提速为2倍左右。
除此外，1.5.x还引入了Fast cubing算法，利用Mapper端计算先完成大部分聚合，再将聚合后的结果交给Reducer，从而降低对网络瓶颈的压力。对500多个Cube任务 的实验显示，引入Fast cubing后，总体的Cube构建任务提速1.5倍。
目前，社区正在着手准备Apache Kylin 1.5.2版本的发布，目前正处于Apache Mailing list投票阶段，预计将会在本周在Kylin官网发布正式下载。
在本次的1.5.2版本中，Kylin带来了总计 36个缺陷修复、33个功能改进、6个新功能。一些主要的功能改进包括对HyperLogLog计算效率的提升、在Cube构建时对Convert data to hfile步骤的提速、UI上对功能提示的体验优化、支持hive view作为lookup表等等。
Kylin也将支持MapR和CDH的Hadoop发行版，具体信息可见KYLIN-1515和KYLIN-1672。相应的测试版本是MapR5.1和CDH5.7。
UI上提供了一个重要更新，即允许用户在Cube级别进行自定义配置，以覆盖kylin.properties中的全局配置。如在cube中定义kylin.hbase.region.count.max可以设置该cube在hbase中region切分的最大数量。
另一个重要的功能是Diagnosis。用户经常会遇到一些棘手的问题，例如Cube构建任务失败、SQL查询失败，或Cube构建时间过长、SQL查询时间过长等。
但由于运维人员对Kylin系统了解不深，很难快速定位到root cause所在地。我们在mailing list里也经常看到很多用户求助，由于不能提供足够充分的信息，社区也很难给出一针见血的建议。
当用户遇到查询、Cube/Model管理的问题，单击System页面的Diagnosis按钮，系统会自动抓取当前Project相关的信息并打包成zip文件下载到用户本地。这个包会包含相关的Metadata、日志、HBase配置等。当用户需要在mailing list求助，也可以附上这个包。
一个cube构建任务执行失败或时间过长，用户可以单击Job下的Diagnosis按钮。同样的，系统会抓取和下载Job相关信息成一个Zip包。
简单来说，Kylin的核心思想是预计算(以空间换时间)，即对多维分析可能用到的度量进行预计算，将计算好的结果保存成Cube，供查询时直接访问。把高复杂度的聚合运算、多表连接等操作转换成对预计算结果的查询，这决定了Kylin能够拥有很好的快速查询和高并发能力.
基本概念
Cuboid: Kylin中将维度任意组合成为一个Cuboid。
Cube: Kylin中将所有维度组合成为一个Cube，即包含所有的Cuboid。
为了更好的适应大数据环境，Kylin通常从用来做数据仓库的hive中读取源数据，使用mapreduce作为cube构建引擎,把预计算结果保存到Hbase中，对外暴露Restful API/JDBC/ODBC的查询接口。
因为Kylin支持标准的ANSI SQL，所以可以和常用数据分析工具（如Tableau,Excel等）进行无缝对接。
Apache Kylin系统架构
▷上图黑线勾勒出Cube Build Engine是如何以离线处理方式将关系型数据转化成键-值型数据，黄线部分表现出在线分析数据的处理流程。
▷ 数据请求可以利用基于SQL的工具由SQL提交而产生，或者利用第三方应用程序通过Kylin的RESTful服务来实现。
▷RESTful服务会调用Query Engine，后者则检测对应的目标数据集是否真实存在。如果确实存在，该引擎会直接访问目标数据并以次秒级延迟返回结果。
▷如果目标数据集并不存在，该引擎则会根据设计将无匹配数据集的查询路由至Hadoop上的SQL处、即交由Hive等Hadoop集群负责处理
Apache Kylin的核心模块
Kylin的OLAP引擎框架包括元数据引擎、查询引擎、作业引擎、存储引擎以及用来处理客户端请求的REST服务器。
▷元数据管理工具（Metadata Manager）
Kylin是一款元数据驱动型应用程序。元数据管理工具是一大关键性组件，用于对保存在Kylin当中的所有元数据进行管理，其中包括最为重要的cube元数据。其它全部组件的正常运作都需以元数据管理工具为基础，包括cube的定义，星状模型的定义、job的信息、job的输出信息、维度的directory信 息等等，元数据和cube都存储在hbase中，存储的格式是json字符串，除此之外，还可以选择将元数据存储在本地文件系统。
▷任务引擎（Job Engine）
这套引擎的设计目的在于处理所有离线任务，其中包括shell脚本、Java API以及Map Reduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障。
▷存储引擎（Storage Engine）
这套引擎负责管理底层存储——特别是cuboid，其以键-值对的形式进行保存。存储引擎使用的是HBase——这是目前Hadoop生态系统当中最理想的键-值系统使用方案。
Kylin还能够通过扩展实现对其它键-值系统的支持，例如Redis。
▷REST Server
REST Server是一套面向应用程序开发的入口点，旨在实现针对Kylin平台的应用开发工作。 此类应用程序可以提供查询、获取结果、触发cube构建任务、获取元数据以及获取用户权限等等。
▷ODBC驱动程序
为了支持第三方工具与应用程序——例如Tableau/Excel——Kylin构建起了一套ODBC驱动程序并对其进行了开源。目标是让用户能够更为顺畅地采用Kylin平台。
▷JDBC驱动程序
Kylin提供了JDBC的驱动，驱动的classname为org.apache.kylin.jdbc.Driver，使用 的url的前缀jdbc:kylin:，使用jdbc接口的查询走的流程和使用RESTFul接口查询走的内部流程是相同的。该类接口使得kylin能够很 好的兼容tebleau甚至mondrian。
▷查询引擎（Query Engine）:当cube准备就绪后，查询引擎就能够获取并解析用户查询。它随后会与系统中的其它组件进行交互，从而向用户返回对应的结果，kylin使用开源的Calcite框架实现SQL的解析，相当于SQL引擎层
▷Routing：该模块负责将解析SQL生成的执行计划转换成cube缓存的查询，cube是通过预计算缓存在hbase中，这部分查询是可以在秒级甚至 毫秒级完成。
▷Cube构建引擎：这个模块是所有模块的基础，它负责预计算创建cube，创建的过程是通过hive读取原始数据然后通过mapreduce计算生成Htableload到hbase中。
Apache Kylin部署结构
▷单节点部署架构图：
▷单点部署优点是：部署简单；缺点也很明显: Kylin是单点，并发请求上来的时候它会成为瓶颈
▷ 集群部署架构图：
部署到Cluster非常简单，只需要增加Kylin的节点数，因为Kylin的metadata也是存储在HBase，只需要让它们用同一张metadata表就可以组成cluster，通常在这个时候会用LDAP来管理用户权限
为了将负载分布到Kylin cluster,可以在前端启用Nginx+keepalived, 然后启动多个Query Server接收查询请求处理
读写分离部署架构图：
Kylin非常适合于做读写分离，原因是Kylin的工作负载有两种：
1. 前者是Cube的计算，它是批量的、延时很长的计算，有密集的CPU和IO
2. 后者是在线的计算，是只读的，因为面向用户，它要求低延迟。
Cube计算的过程会对集群带来很大的负载，从而产生噪音；所以我们有充足的理由进行读写分析。
Kylin很容易做到这一点，可以把HBase单独部署成一个集群，在部署Kylin的节点上，hadoop 配置指向运算的集群，Hbase的配置指向HBase集群。通过这样的部署，可以确保Hbase的查询可以在很短时间完成，而计算集群可以共享。
Q&A
Q1、对mdx支持情况如何？
A1：我们现在不支持MDX查询，查询入口是SQL，像saiku这种基于MDX的操作，社区已经有人贡献了Mondrian jar包，可以将saiku 前台提供的mdx转换为sql，再通过jdbc jar发送到Kylin server，不过功能上有所限制，left join, topN, count distinct支持受限。
Q2、麒麟针对出来T级别的数据，每日制作cube大约话费多久时间？
A2：具体cube构建时间视不同情况而定，具体取决于dimension数量及不同组合情况、Cardinality大小、源数据大小、Cube优化程度、集群计算能力等因素。在一些案例中，在一个shared cluster构建数十GB的数据只需要几十分钟。建议大家在实际环境先进行测试，寻找可以对Cube进行优化的点。此外，一般来说，Cube的增量构建可以在ETL完成后由系统自动触发，往往这个时间和分析师做数据分析是错峰的。
Q3、如何向kylin提交代码?
A3：将修改的代码用git format-patch做成patch文件，然后attache在对应的jira上，kylin committer会来review，没有问题的话会merge到开发分支
Q4、如果数据是在elastic search，Kylin的支持如何?
A4：目前还不支持直接从es抽取数据，需要先导出到hive再做cube build；有兴趣的同学可以基于kylin 1.5的plugin架构实现一个es的data source。
Q5、工作的比较好的前端拖拽控件有什么？
A5：目前应该是tableau支持较好，saiku支持不是很好，有些场景如left join, count distinct,topN支持不是很好，用户是可以基于Api开发自己的拖拽页面的。
Q6、社区版和商业版功能上有什么区别？
A6：商业版能够提供更高的安全性、稳定性、可靠性，以及企业组件的良好集成；以及可靠、专业、源码级的商业化支持。
Q7、对多并发支持表现如何？
A7：Kylin和其他MPP架构技术想必一大优势就在高并发。一台Kylin的Query Server就支持几十到上百的QPS (取决于查询的复杂度，机器的配置等因素)，而且 Kylin支持良性的水平扩展，即增多kylin server和HBase节点就可迅速增大并发。
Q8、kylin可以整合spark machine learning和spark sql吗？
A8：基于前面讲到的可插拔架构，是可以整合的。
Q9、跟其它工具对比，有没有考虑cube的构建时间？因为人家是实时计算的，你是预计算的，这从机理上是不一样的
A9：kylin跟其它mpp架构的技术在查询性能的对比，时间里是不含cube构建的时间的，所以从某种意义上来讲这样的对比是有些不公平。但是，从用户角度来看，分析师和最终用户只关心查询性能，而Kylin用预计算能大大提高查询速度，这正是用户所需要的！
Q10、Kylin ODBC 驱动程序有示例代码？
A10：目前代码在master分支，欢迎大家加入社区一起贡献。
Q11、4亿数据有点少，麒麟有没有做过相关的benchmark ，在百亿级别数据，十个纬度的情况下，表现如何？
A11：来自社区的测试数据，在一个近280亿条原始数据的cube（26TB）上，90%的查询在5秒内完成。
Q12、数据量翻倍的话,空间使用会做指数级增长么
A12：通常cube的增长与原数据的增长基本一致，即原数据翻倍，cube也翻倍，或者更小一些；而非指数增长。
Q13、Data Model和Cube Model构建过程能根据UI步骤详细讲下吗？
A13：欢迎登陆Kylin网站，查询具体的使用教程。http://kylin.apache.org/
Q14、你好，相关链接能贴一下吗，谢谢！ 来自社区的测试数据，在一个近280亿条原始数据的cube（26TB）上，90%的查询在5秒内完成。
（全文完成）
本文为 @ 21CTO 创作并授权 21CTO 发布，未经许可，请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。
该文观点仅代表作者本人，21CTO 平台仅提供信息存储空间服务。
评论
