【转】使用Apache Kylin搭建企业级开源大数据分析平台

http://www.thebigdata.cn/JieJueFangAn/30143.html

　本篇文章整理自史少锋4月23日在『1024大数据技术峰会』上的分享实录：使用Apache Kylin搭建企业级开源大数据分析平台。

　　正文以下

　　我先作一个简单介绍我叫史少锋，我曾经在IBM、eBay作过大数据、云架构的开发，如今是Kyligence的技术合伙人。

　　Kylin是这两年在国内发展很是快的开源大数据项目。今天大会合做厂商中有超过一半的企业已经在使用或者正在试用Kylin，应主办方邀请，今天跟你们作一个关于如何使用Kylin构建开源大数据分析平台的分享。

　　这是我今天的议程，分两部分。

　　前半部分：

　　针对Kylin的初级和入门用户介绍Kylin项目的由来以及技术核心。

　　后半部分：

　　介绍如何基于Kylin构建开源大数据分析平台，把Hadoop数据平台和业务分析系统链接起来。

　　Kylin(麒麟)是什么?咱们听到过有麒麟芯片、麒麟OS等等，咱们这个全名是叫Apache Kylin，是一个大数据分析的项目。

　　从名字上或许能够猜到，它来自中国，的确这也是咱们想让世界知道的，有一群来自中国的工程师在向Hadoop贡献着这样一个独特的项目。

　　Apache Kylin 是在Hadoop之上的分布式的大数据分析引擎，它对外暴露的是标准SQL接口，支持TB到PB量级的数据，以秒级甚至亚秒级的时间返回响应。

　　任何一个项目的诞生都有必定的背景和缘由。

　　今天咱们看到愈来愈多的企业正在使用Hadoop，正在把Hadoop做为他们的基础平台来管理和分析数据。

　　可是，企业在使用Hadoop的时候，每每发现有一个很大的Gap：

　　一方面，现有的分析系统或分析工具，不能很好支持Hadoop; Hadoop上的数据的体量是远远超过传统单机或者传统关系型数据库的体量，原有的系统接入Hadoop根本没法承受这么大的数据量。

　　此外这些遗留系统当初设计的时候就不是一个分布式的架构，没办法水平地扩容。

　　另外一方面，对于数据使用者或者分析师，让他们直接使用Hadoop，写MapReduce或者Spark的任务，是难以接受的。此外，Hadoop主要是用于作批量运算， 一般须要几十分钟，最快也要几分钟，对于分析人员来讲很难有一个好的使用体验;等几分钟才能看到结果数据，大大影响了他们的工做效率。

　　这个问题当年就是在eBay内部就被提出来，为此专门成立了一个项目。

　　2013年的时候，Kylin项目的创始人韩卿(Luke)，授命带着工程师研究这个难题，通过不断的尝试和摸索，Kylin探索出了在Hadoop之上作预计算、作Cube这条路线，这是以前没有人尝试过的。

　　最终这个项目在2014年10月在Github开源 。一个月以后项目被Apache接受成为其一个孵化器项目。

　　2015年11月份，通过Apache软件基金会(ASF)的投票，Kylin正式毕业，称为其大数据领域的一个顶级项目。值得一提的是，2015年的9月，Kylin得到 了美国InfoWorld评选的最佳开源大数据工具奖，同时获奖的还有Spark、Storm、Kafka等知名项目。

　　2016年3月, 由Apache Kylin主要开发人员组成的公司Kyligence成立，致力于Kylin在业界的推广和使用。

　　前面讲的是Kylin发展的历史，接下来说一下Kylin核心技术。

　　作过BI分析的人，对Cube都会有概念，就是用空间换时间。经过预计算把用户须要查询的维度以及他们所对应的考量的值，存储在多维空间里。

　　当用户查询某几个维度的时候，经过这些维度条件去定位到预计算的向量空间，经过再聚合处理，快速返回最终结果给用户。

　　所不一样的是，Kylin的cube不是单一维度的组合，而是全部组合均可以计算。N个维度的完整Cube， 会有2的N次方种组合。

　　Kylin架构是这样的，首先要求用户把数据放在Hadoop上，经过Hive管理，用户在Kylin中进行数据建模之后，Kylin会生成一系列的MapReduce任务来计算Cube，算好的Cube最后以K-V的方式存储在HBase中。

　　分析工具发送标准SQL查询,Kylin将它转换成对HBase的Scan，快速查到结果返回给请求方。

　　Cube是怎么计算出来的?

　　这是在1.5以前版本中的的算法，也叫逐层算法。它会启动N+1轮MapReduce计算。

　　第一轮读取原始数据，去掉不相关的列，只保留相关的。同时对维度列进行压缩编码;以此处的四维Cube为例，通过第一轮计算出ABCD组合，咱们也称为Base Cuboid;

　　此后的每一轮MapReduce，输入是上一轮的输出，以重用以前计算的结果，去掉要聚合的维度，算出新的Cuboid。以此往上，直到最后算出全部的Cuboid。

　　Cube在Storage上是怎么存储的?

　　星形模型会先被拉成一张平表， Dimension的值拼接在一块儿，后面接着是Metrics。为了标示这是哪几个维度的组合，会在行的开始加上Cuboid ID。最后，Cuboid ID + dimensions会被用做Rowkey，Metrics会做为Value放到Column中 。

　　查询的时候，SQL语句被SQL解析器翻译成一个解释计划，从这个计划能够准确知道用户要查哪些表，它们是怎样join起来，有哪些过滤条件等等。Kylin会用这个计划去匹配寻找合适的Cube。

　　若是有Cube命中，这个计划会发送到存储引擎，翻译成对存储(默认HBase)相应的Scan操做。Groupby和过滤条件的列，用来找到Cuboid，过滤条件会被转换成Scan的开始和结束值， 以缩小Scan的范围; Scan的result，Rowkey会被反向解码成各个dimension的值，Value会被解码成Metrics值 。

　　接下来介绍Kylin的企业级特性;Kylin的特性比较多，这里就不一一列举，主要 讲一下对企业比较友好的特性。

　　首先，毋庸置疑, Kylin对外暴露的是标准的SQL，支持大多数的SELECT语法，能够把各类工具和系统直接对接进来。这意味着当您使用Kylin的时候，不须要对业务系统作额外的改动。

　　第二，Kylin提供了各类接入方式， 如ODBC、JDBC; 若是您的系统不使用这两种方式，还可使用RESTful API查询。

　　Kylin架构天生就很是适合Scale out，当查询量上升，单节点不能知足的时候，只须要相应增长Kylin的节点就能够知足。

　　针对企业对安全的要求，咱们有不一样力度作安全控制。Kylin有不一样用户角色作不一样的事情，此外在project和cube层级能够定义ACL帮助在更细力度掌控对cube的使用。

　　企业一般会使用目录服务来管理用户和群组，Kylin支持LDAP认证登陆;若是对安全有更高的要求，Kylin还支持了基于SAML的单点登陆(SingleSign-On)，只要作一些配置就能够完成，不须要额外开发。

　　Kylin提供了丰富的RESTful API，很是方便从用各类已有系统，如任务调度，监控等接入Kylin。Kylin的Web UI作到的事情经过API均可以作到。咱们看到网易、美团等在Kylin之上开作了封装，跟他们各自的BI作深度的融合，就是利用了这个特性。

　　怎么样用Kylin来构建大数据的分析平台?

　　很简单。Kylin部署和安装是很是方便的，咱们称为非侵入式的安装。若是你已经有一套Hadoop，安装Kylin，只要增长一台机器，下载Kylin安装包运行就能够了，Kylin使用标准Hadoop API跟各类组件通讯，不须要对现有的Hadoop安装额外的agent。

　　架构上就是个分层的结构，最底层是数据，放置在HDFS，其上是Hadoop层，须要有HBase、 Hive， MapReduce等。Kylin运行中Hadoop之上，安装好了以后，业务系统连入Kylin，Kylin把压力分布到Hadoop上作计算和查询。

　　有四种典型的部署架构，分别从简单到复杂。

　　第一种， Single instance的部署 ，一般一两天就能够完成。首先要有Hadoop，版本在2.4或以上。加一台Hadoop客户机，下载Kylin，便可一键启动。 建模人员经过Kylin Web登陆，进行建模和cube的建立。业务分析系统或者工具发SQL到Kylin，Kylin查询Cube返回结果。

　　这种部署最大特色是简单;缺点也很明显: Kylin是单点，并发请求上来的时候它会成为瓶颈，因此须要Cluster的部署。

　　Kylin部署到Cluster很是简单，只须要增长Kylin的节点数，由于Kylin的metadata也是存储在HBase，只须要让它们用同一张metadata表就能够组成cluster 。一般在这个时候会用LDAP来管理用户权限。

　　为了将负载分布到Kylin cluster, 须要创建一个Load Balancer(负载均衡器). 在LB这里能够启用SSL加密，申请域名，还能够安装防火墙，对外只暴露LB的地址和端口，确保Hadoop和Kylin在网络上对外是隔离的。

　　业务系统和用户经过LB的地址访问Kylin。这样的部署，Kylin将不是单点，一个节点失效，不会影响业务分析。是否是这样就完美了呢?也不是。

　　Kylin很是适合于作读写分离，缘由是Kylin的工做负载有两种：

　　前者是Cube的计算，它是批量的、延时很长的计算，有密集的CPU和IO;

　　后者是在线的计算，是只读的，由于面向用户，它要求低延迟。Cube计算的过程会对集群带来很大的负载，从而产生噪音;因此咱们有充足的理由进行读写分析。

　　Kylin很容易作到这一点，你能够把HBase单独部署成一个集群，在部署Kylin的节点上，hadoop 配置指向运算的集群，Hbase的配置指向HBase集群。经过这样的部署，能够确保Hbase的查询能够在很短期完成，而计算集群能够跟公司其它部门分享。

　　如今目前Kylin使用中估计99%的状况是前面三种部署。还有一种更高级的部署是Staging和Prod多环境的部署。

　　在一个大的企业里，每每须要多套环境，用于测试，生产等不一样目的。

　　举例来讲，新用户上到Kylin来的时候，最初他对cube不是很了解，可能建立了一个设计不是很好的cube，致使产生大量的没必要要的运算，或者查询花了很长时间。咱们不但愿这样的状况发生在生产环境，对其它业务形成影响，因此会创建一个staging，或者称为QA的环境。

　　新用户必须先走staging环境建立和调优cube，直到cube性能达到要求，数据膨胀率也在一个可控范围内，这时候由用户提出请求，由Kylin专家来作一个审核，审核经过后，再容许这个cube被迁移到生产环境。

　　这里Kylin提供了一个工具， 几分钟就能够讲一个Cube从一个环境迁移到另外一个环境，不须要在新环境中从新build。 在生产环境的Cube，将不容许修改， 只能作增量的build 。

　　这样作Staging和Prod分离，Prod中的cube都是通过专家的审核的，因此将是很是稳定的，里面的每一个cube都是有据可循的。

　　这就是关于Kylin的部署的分享。

　　到今天Kylin已经有了不少的使用案例，这里简单列一些已知的。最先是在eBay，国内有京东、运营、美团、中国移动(包括广东移动和北京移动)，还有微软 。

　　以上是今天的分享，谢谢你们。