数据分析（11）
Apache Kylin是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。
Kylin OLAP引擎基础框架，包括元数据（Metadata）引擎，查询引擎，Job引擎及存储引擎等，同时包括REST服务器以响应客户端请求；
支持额外功能和特性的插件；
与调度系统，ETL，监控等生命周期管理系统的整合；
在Kylin核心之上扩展的第三方用户界面；
官网地址：http://kylin.apache.org/
提供了主要功能及使用的中文文档。
Kylin的架构特性
可扩展的超快OLAP引擎，提供标准SQL查询接口
支持单机或集群部署，为减少在Hadoop上百亿规模数据查询延迟而设计；
提供标准SQL接口，满足Hadoop之上的大部分分析查询需求。
交互式查询能力，多维立方体（MOLAP Cube）
用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体。
与BI工具及其他应用整合
提供JDBC及ODBC驱动，与BI工具整合。
压缩与编码；
增量更新；
利用HBase Coprocessor；
基于HyperLogLog的Dinstinc Count近似算法；
友好的web界面以管理，监控和使用立方体；
项目及立方体级别的访问控制安全；
支持LDAP；
Kylin的安装部署
下载地址：http://kylin.apache.org/download/
apache-kylin-1.5.1-bin.tar.gz
解压至：/home/liuxiaowen/kylin
安装部署环境
我这里使用的相关版本为：
hbase-0.98.6-cdh5.2.0
hadoop-2.3.0-cdh5.0.0
apache-hive-2.0.0-bin
apache-kylin-1.5.1-bin
jdk1.7+
特别注意：Hive应该使用至少0.14以上的版本，我第一次使用0.13.1时候有问题。
另外，请确保Hadoop、HBase、Hive可用，这里不介绍。
配置环境变量
部署使用的用户为liuxiaowen
vi ~/.bash_profile
##HBASEexport HBASE_HOME=/opt/hbase-0.98.6-cdh5.2.0export HBASE_CONF_DIR=/etc/hbase/conf&##HADOOPexport HADOOP_HOME=/opt/hadoop-2.3.0-cdh5.0.0export HADOOP_CONF_DIR=/etc/hadoop/confexport YARN_CONF_DIR=/etc/hadoop/conf&##HIVEexport HIVE_HOME=/home/liuxiaowen/apache-hive-2.0.0-binexport HCAT_HOME=$HIVE_HOME/hcatalogexport HIVE_CONF=$HIVE_HOME/conf&##KYLINexport KYLIN_HOME=/home/liuxiaowen/kylin/apache-kylin-1.5.1-bin
刷新环境变量：
source ~/.bash_profile
配置Kylin使用的Hive数据库：
cd $KYLIN_HOME/conf
vi kylin.properties
# Hive database name for putting the intermediate flat tables
## 这里配置在Hive中使用的schema，需要写权限
kylin.job.hive.database.for.intermediatetable=liuxiaowen
使用HDFS超级用户在HDFS上为Kylin创建工作目录，并赋权给liuxiaowen：
hadoop fs -mkdir /kylin
hadoop fs -chown -R liuxiaowen:liuxiaowen /kylin
## 可选，配置Kylin使用的内存
$KYLIN_HOME/bin/setenv.sh
检查环境配置
cd $KYLIN_HOME/bin
./check-env.sh
cd $KYLIN_HOME/bin
./kylin.sh start
登陆Kylin WEB界面
浏览器输入：
http://172.16.212.17:7070/kylin
用户名密码：ADMIN/KYLIN
遇到的几个问题
都是因为使用了Hive0.13.1引起的：
Caused by: java.lang.IncompatibleClassChangeError:
Found interface org.apache.hadoop.mapreduce.JobContext, but class was expected
hcatalog版本问题，后改为Hive2.0中的hcatalog
export HCAT_HOME=/home/liuxiaowen/apache-hive-2.0.0-bin/hcatalog
java.lang.NoClassDefFoundError: org/apache/hadoop/hive/shims/Utils
Kylin的简单示例
Kylin中多维分析Cube的建立主要包括以下步骤：
Hive中分析好事实表；Kylin中建立项目(project)；Kylin中建立数据源；Kylin中建立数据模型；Kylin中建立Cube；Build Cube；查询Cube；
Kylin按照上面的过程，最终将Hive中的事实表按照相应的结构，压缩并存储在HBase中。
官网提供了中文文档，说明了如何在Kylin中建立Cube，非常详细：
http://kylin.apache.org/cn/docs15/tutorial/create_cube.html
Hive中的事实表
事实表lxw1234_kylin_fact中的维度有day、region、city、siteid、os；最终查询的指标有两个：PV以及UV（COUNT DISTINCT cookieid）
Kylin中建立数据模型
1. 建立项目lxw1234;
2. 将Hive中的事实表 lxw1234_kylin_fact导入到Kylin数据源：
3. 建立数据模型lxw1234_dataModel：
选择维度数据：
选择指标数据：
其他设置：
数据模型中的日期分区字段貌似是必选的，否则会有问题。
然后保存。
Kylin中建立Cube
设计维度：
设计指标：
其中，UV使用的COUNT_DISTINCT是近似计算，需要选择错误率，错误率越低，占用的存储越大，Build耗时越长。
其他设置请参考上面给的中文文档链接，很详细。
设置好之后保存。
Kylin中Build Cube
在Cube后面的Actions下拉菜单中选择Build：
Submit之后，在Monitor页面中可以看到Build Job的进度和状态：
双击Job Name进入该Job的详细监控页：
Build完成后，在Model页面可以看到这个Cube已经是READY状态：
你可以在HBase中查看该Cube对应的HTable：
Kylin中使用SQL查询
在Insight页面中使用SQL查询：
注意：由于DAY是关键字，需要使用双引号。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：110804次
积分：2333
积分：2333
排名：第14335名
原创：99篇
转载：104篇
(35)(37)(9)(13)(14)(13)(2)(8)(13)(1)(8)(3)(15)(37)1289人阅读
.cn/NewsInfo/531/25567.Html引言&大数据查询分析是云计算中核心问题之一，自从Google在2006年之前的几篇论文奠定云计算领域基础，尤其是GFS、Map-Reduce、Bigtable被称为云计算底层技术三大基石。GFS、Map-Reduce技术直接支持了Apache Hadoop项目的诞生。Bigtable和Amazon Dynamo直接催生了NoSQL这个崭新的数据库领域，撼动了RDBMS在商用数据库和数据仓库方面几十年的统治性地位。FaceBook的Hive项目是建立在Hadoop上的数据仓库基础构架，提供了一系列用于存储、查询和分析大规模数据的工具。当我们还浸淫在GFS、Map-Reduce、Bigtable等Google技术中，并进行理解、掌握、模仿时，Google在2009年之后，连续推出多项新技术，包括：Dremel、Pregel、Percolator、Spanner和F1。其中，Dremel促使了实时计算系统的兴起，Pregel开辟了图数据计算这个新方向，Percolator使分布式增量索引更新成为文本检索领域的新标准，Spanner和F1向我们展现了跨数据中心数据库的可能。在Google的第二波技术浪潮中，基于Hive和Dremel，新兴的大数据公司Cloudera开源了大数据查询分析引擎Impala，Hortonworks开源了Stinger，Fackbook开源了Presto。类似Pregel，UC Berkeley AMPLAB实验室开发了Spark图计算框架，并以Spark为核心开源了大数据查询分析引擎Shark。由于某电信运营商项目中大数据查询引擎选型需求，本文将会对Hive、Impala、Shark、Stinger和Presto这五类主流的开源大数据查询分析引擎进行简要介绍以及性能比较，最后进行总结与展望。Hive、Impala、Shark、Stinger和Presto的进化图谱如图1所示。&&图1. Impala、Shark、Stinger和Presto的进化图谱当前主流引擎简介&基于Map-Reduce模式的Hadoop擅长数据批处理，不是特别符合即时查询的场景。实时查询一般使用MPP (Massively Parallel Processing)的架构，因此用户需要在Hadoop和MPP两种技术中选择。在Google的第二波技术浪潮中，一些基于Hadoop架构的快速SQL访问技术逐步获得人们关注。现在有一种新的趋势是MPP和Hadoop相结合提供快速SQL访问框架。最近有四个很热门的开源工具出来：Impala、Shark、Stinger和Presto。这也显示了大数据领域对于Hadoop生态系统中支持实时查询的期望。总体来说，Impala、Shark、Stinger和Presto四个系统都是类SQL实时大数据查询分析引擎，但是它们的技术侧重点完全不同。而且它们也不是为了替换Hive而生，Hive在做数据仓库时是非常有价值的。这四个系统与Hive都是构建在Hadoop之上的数据查询工具，各有不同的侧重适应面，但从客户端使用来看它们与Hive有很多的共同之处，如数据表元数据、Thrift接口、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。Hive与Impala、Shark、Stinger、Presto在Hadoop中的关系如图2所示。Hive适用于长时间的批处理查询分析，而Impala、Shark、Stinger和Presto适用于实时交互式SQL查询，它们给数据分析人员提供了快速实验、验证想法的大数据分析工具。可以先使用Hive进行数据转换处理，之后使用这四个系统中的一个在Hive处理后的结果数据集上进行快速的数据分析。下面，从问题域出发简单介绍Hive、Impala、Shark、Stinger和Presto：&1)&Hive，披着SQL外衣的Map-Reduce。Hive是为方便用户使用Map-Reduce而在外面封装了一层SQL，由于Hive采用了SQL，它的问题域比Map-Reduce更窄，因为很多问题，SQL表达不出来，比如一些数据挖掘算法，推荐算法、图像识别算法等，这些仍只能通过编写Map-Reduce完成。&2)&Impala：Google Dremel的开源实现（Apache Drill类似），因为交互式实时计算需求，Cloudera推出了Impala系统，该系统适用于交互式实时处理场景，要求最后产生的数据量一定要少。&3)&Shark/Spark：为了提高Map-Reduce的计算效率，Berkeley的AMPLab实验室开发了Spark，Spark可看做基于内存的Map-Reduce实现，此外，伯克利还在Spark基础上封装了一层SQL，产生了一个新的类似Hive的系统Shark。&4)&Stinger Initiative（Tez optimized Hive）：Hortonworks开源了一个DAG计算框架Tez，Tez可以理解为Google Pregel的开源实现，该框架可以像Map-Reduce一样，可以用来设计DAG应用程序，但需要注意的是，Tez只能运行在YARN上。Tez的一个重要应用是优化Hive和PIG这种典型的DAG应用场景，它通过减少数据读写IO，优化DAG流程使得Hive速度提供了很多倍。&5)&Presto：FaceBook于2013年11月份开源了Presto，一个分布式SQL查询引擎，它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。Presto设计了一个简单的数据存储的抽象层，来满足在不同数据存储系统（包括HBase、HDFS、Scribe等）之上都可以使用SQL进行查询。&&图2. Hive与Impala、Shark、Stinger、Presto在Hadoop中的关系&当前主流引擎架构&HiveHive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能，可以将SQL语句转换为Map-Reduce任务进行运行，十分适合数据仓库的统计分析。其架构如图3所示，Hadoop和Map-Reduce是Hive架构的根基。Hive架构包括如下组件：CLI（Command Line Interface）、JDBC/ODBC、Thrift Server、Meta Store和Driver(Complier、Optimizer和Executor)。&图3. Hive架构Impala架构&Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具，它可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的结合体。Impala没有再使用缓慢的Hive&Map-Reduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟，其架构如图4所示，Impala主要由Impalad，State Store和CLI组成。Impalad与DataNode运行在同一节点上，由Impalad进程表示，它接收客户端的查询请求（接收查询请求的Impalad为Coordinator，Coordinator通过JNI调用java前端解释SQL查询语句，生成查询计划树，再通过调度器把执行计划分发给具有相应数据的其它Impalad进行执行），读写数据，并行执行查询，并把结果通过网络流式的传送回给Coordinator，由Coordinator返回给客户端。同时Impalad也与State Store保持连接，用于确定哪个Impalad是健康和可以接受新的工作。Impala State Store跟踪集群中的Impalad的健康状态及位置信息，由state-stored进程表示，它通过创建多个线程来处理Impalad的注册订阅和与各Impalad保持心跳连接，各Impalad都会缓存一份State Store中的信息，当State Store离线后，因为Impalad有State Store的缓存仍然可以工作，但会因为有些Impalad失效了，而已缓存数据无法更新，导致把执行计划分配给了失效的Impalad，导致查询失败。CLI提供给用户查询使用的命令行工具，同时Impala还提供了Hue，JDBC，ODBC，Thrift使用接口。&&图4. Impala架构&Shark架构&Shark是UC Berkeley AMPLAB开源的一款数据仓库产品，它完全兼容Hive的HQL语法，但与Hive不同的是，Hive的计算框架采用Map-Reduce，而Shark采用Spark。所以，Hive是SQL on Map-Reduce，而Shark是Hive on Spark。其架构如图4所示，为了最大程度的保持和Hive的兼容性，Shark复用了Hive的大部分组件，如下所示：&1)&SQL Parser&Plan generation: Shark完全兼容Hive的HQL语法，而且Shark使用了Hive的API来实现query Parsing和 query Plan generation，仅仅最后的Physical Plan execution阶段用Spark代替Hadoop Map-Reduce；&2)&metastore：Shark采用和Hive一样的meta信息，Hive里创建的表用Shark可无缝访问；&3)&SerDe: Shark的序列化机制以及数据类型与Hive完全一致；&4)&UDF: Shark可重用Hive里的所有UDF。通过配置Shark参数，Shark可以自动在内存中缓存特定的RDD（Resilient Distributed Dataset），实现数据重用，进而加快特定数据集的检索。同时，Shark通过UDF用户自定义函数实现特定的数据分析学习算法，使得SQL数据查询和运算分析能结合在一起，最大化RDD的重复使用；&5)&Driver：Shark在Hive的CliDriver基础上进行了一个封装，生成一个SharkCliDriver，这是shark命令的入口；&6)&ThriftServer：Shark在Hive的ThriftServer（支持JDBC/ODBC）基础上，做了一个封装，生成了一个SharkServer，也提供JDBC/ODBC服务。&&图5. Shark架构&Spark是UC Berkeley AMP lab所开源的类Hadoop Map-Reduce的通用的并行计算框架，Spark基于Map-Reduce算法实现的分布式计算，拥有Hadoop Map-Reduce所具有的优点；但不同于Map-Reduce的是Job中间输出和结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的Map-Reduce的算法。其架构如图6所示：&&图6. Spark架构与Hadoop的对比，Spark的中间数据放到内存中，对于迭代运算效率更高，因此Spark适用于需要多次操作特定数据集的应用场合。需要反复操作的次数越多，所需读取的数据量越大，受益越大，数据量小但是计算密集度较大的场合，受益就相对较小。Spark比Hadoop更通用，Spark提供的数据集操作类型有很多种（map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort，partionBy等），而Hadoop只提供了Map和Reduce两种操作。Spark可以直接对HDFS进行数据的读写，同样支持Spark on YARN。Spark可以与Map-Reduce运行于同集群中，共享存储资源与计算，数据仓库Shark实现上借用Hive，几乎与Hive完全兼容。Stinger架构&Stinger是Hortonworks开源的一个实时类SQL即时查询系统，声称可以提升较Hive 100倍的速度。与Hive不同的是，Stinger采用Tez。所以，Hive是SQL on Map-Reduce，而Stinger是Hive on Tez。Tez的一个重要作用是优化Hive和PIG这种典型的DAG应用场景，它通过减少数据读写IO，优化DAG流程使得Hive速度提供了很多倍。其架构如图7所示， Stinger是在Hive的现有基础上加了一个优化层Tez（此框架是基于Yarn），所有的查询和统计都要经过它的优化层来处理，以减少不必要的工作以及资源开销。虽然Stinger也对Hive进行了较多的优化与加强，Stinger总体性能还是依赖其子系统Tez的表现。而Tez是Hortonworks开源的一个DAG计算框架，Tez可以理解为Google Pregel的开源实现，该框架可以像Map-Reduce一样，用来设计DAG应用程序，但需要注意的是，Tez只能运行在YARN上。&&图7. Stinger架构&Presto架构&2013年11月Facebook开源了一个分布式SQL查询引擎Presto，它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL子集，包括复杂查询、聚合、连接和窗口函数。其简化的架构如图8所示，客户端将SQL查询发送到Presto的协调器。协调器会进行语法检查、分析和规划查询计划。调度器将执行的管道组合在一起，将任务分配给那些里数据最近的节点，然后监控执行过程。客户端从输出段中将数据取出，这些数据是从更底层的处理段中依次取出的。Presto的运行模型与Hive有着本质的区别。Hive将查询翻译成多阶段的Map-Reduce任务，一个接着一个地运行。每一个任务从磁盘上读取输入数据并且将中间结果输出到磁盘上。然而Presto引擎没有使用Map-Reduce。它使用了一个定制的查询执行引擎和响应操作符来支持SQL的语法。除了改进的调度算法之外，所有的数据处理都是在内存中进行的。不同的处理端通过网络组成处理的流水线。这样会避免不必要的磁盘读写和额外的延迟。这种流水线式的执行模型会在同一时间运行多个数据处理段，一旦数据可用的时候就会将数据从一个处理段传入到下一个处理段。 这样的方式会大大的减少各种查询的端到端响应时间。同时，Presto设计了一个简单的数据存储抽象层，来满足在不同数据存储系统之上都可以使用SQL进行查询。存储连接器目前支持除Hive/HDFS外，还支持HBase、Scribe和定制开发的系统。&图8. Presto架构&性能评测总结&通过对Hive、Impala、Shark、Stinger和Presto的评测和分析，总结如下：&1)&列存储一般对查询性能提升明显，尤其是大表是一个包含很多列的表。例如，从Stinger（Hive 0.11 with ORCFile）VS Hive，以及Impala的Parquet VS Text file；&2)&绕开MR计算模型，省去中间结果的持久化和MR任务调度的延迟，会带来性能提升。例如，Impala，Shark，Presto要好于Hive和Stinger，但这种优势随着数据量增加和查询变复杂而减弱；&3)&使用MPP数据库技术对连接查询有帮助。例如，Impala在两表，多表连接查询中优势明显；&4)&充分利用缓存的系统在内存充足的情况下性能优势明显。例如，Shark，Impala在小数据量时性能优势明显；内存不足时性能下降严重，Shark会出现很多问题；&5)&数据倾斜会严重影响一些系统的性能。例如，Hive、Stinger、Shark对数据倾斜比较敏感，容易造成倾斜；Impala受这方面的影响似乎不大；对于Hive、Impala、Shark、Stinger和Presto这五类开源的分析引擎，在大多数情况下，Imapla的综合性能是最稳定的，时间性能也是最好的，而且其安装配置过程也相对容易。其他分别为Presto、Shark、Stinger和Hive。在内存足够和非Join操作情况下，Shark的性能是最好的。&总结与展望&对大数据分析的项目来说，技术往往不是最关键的，关键在于谁的生态系统更强，技术上一时的领先并不足以保证项目的最终成功。对于Hive、Impala、Shark、Stinger和Presto来讲，最后哪一款产品会成为事实上的标准还很难说，但我们唯一可以确定并坚信的一点是，大数据分析将随着新技术的不断推陈出新而不断普及开来，这对用户永远都是一件幸事。举个例子，如果读者注意过下一代Hadoop（YARN）的发展的话就会发现，其实YARN已经支持Map-Reduce之外的计算范式（例如Shark，Impala等），因此将来Hadoop将可能作为一个兼容并包的大平台存在，在其上提供各种各样的数据处理技术，有应对秒量级查询的，有应对大数据批处理的，各种功能应有尽有，满足用户各方面的需求。除了Hive、Impala、Shark、Stinger和Presto这样的开源方案外，像Oracle，EMC等传统厂商也没在坐以待毙等着自己的市场被开源软件侵吞。像EMC就推出了HAWQ系统，并号称其性能比之Impala快上十几倍，而Amazon的Redshift也提供了比Impala更好的性能。虽然说开源软件因为其强大的成本优势而拥有极其强大的力量，但是传统数据库厂商仍会尝试推出性能、稳定性、维护服务等指标上更加强大的产品与之进行差异化竞争，并同时参与开源社区、借力开源软件来丰富自己的产品线、提升自己的竞争力，并通过更多的高附加值服务来满足某些消费者需求。毕竟，这些厂商往往已在并行数据库等传统领域积累了大量的技术和经验，这些底蕴还是非常深厚的。总的来看，未来的大数据分析技术将会变得越来越成熟、越来越便宜、越来越易用；相应的，用户将会更容易更方便地从自己的大数据中挖掘出有价值的商业信息。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1031868次
积分：10612
积分：10612
排名：第1336名
原创：176篇
转载：202篇
评论：1147条
中国科学院博士，代码洁癖重度患者，10年以上Java Web架构、开发经验，非单一语言爱好者，熟悉C++/MFC/java/Scala开发技术，著有《标准C++开发入门与编程实践》、《把脉VC++》，以及“白乔原创”系列技术文章多篇。
开源贡献，欢迎star：大数据分析界的 “神兽” Apache 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的架构图。说到Cube的构建，Kylin提供了一个称作Layer Cubing的算法。简单来说，就是按照dimension数量从大到小的顺序，从Base Cuboid开始，依次基于上一层Cuboid的结果进行再聚合。每一层的计算都是一个单独的Map Reduce任务。如下图所示。MapReduce的计算结果最终保存到HBase中，HBase中每行记录的Rowkey由dimension组成，measure会保存在column family中。为了减小存储代价，这里会对dimension和measure进行编码。查询阶段，利用HBase列存储的特性就可以保证Kylin有良好的快速响应和高并发。
Ctrl+D&将本页面保存为书签，全面了解最新资讯，方便快捷。hadoop（2）
本文是5月23日大数据杂谈群分享的内容。
关注“大数据杂谈”公众号，点击“加群学习”，更多大牛一手技术分享等着你。
实习编辑：Melody
大家好，我是今天做微信分享的李栋，来自Kyligence公司，也是Apache Kylin Committer & PMC member，在加入Kyligence之前曾就职于eBay、微软。
今天分享的主题是：聊聊“神兽”Apache Kylin的最新特性。本次分享将首先对Apache Kylin进行基本介绍；接下来介绍1.5.x最新版本在架构上的重要更新；然后对即将发布的1.5.2版本进行功能预告。
1.Apache Kylin是什么？
在现在的大数据时代，越来越多的企业开始使用Hadoop管理数据，但是现有的业务分析工具（如Tableau，Microstrategy等）往往存在很大的局限，如难以水平扩展、无法处理超大规模数据、缺少对Hadoop的支持；而利用Hadoop做数据分析依然存在诸多障碍，例如大多数分析师只习惯使用SQL，Hadoop难以实现快速交互式查询等等。神兽Apache Kylin就是为了解决这些问题而设计的。
Apache Kylin，中文名麒（shen）麟（shou） 是Hadoop动物园的重要成员。Apache Kylin是一个开源的分布式分析引擎，最初由eBay开发贡献至开源社区。它提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持大规模数据，能够处理TB乃至PB级别的分析任务，能够在亚秒级查询巨大的Hive表，并支持高并发。
Apache Kylin于2014年10月在github开源，并很快在2014年11月加入Apache孵化器，于2015年11月正式毕业成为Apache顶级项目，也成为首个完全由中国团队设计开发的Apache顶级项目。于2016年3月，Apache Kylin核心开发成员创建了Kyligence公司，力求更好地推动项目和社区的快速发展。
Kyligence是一家专注于大数据分析领域创新的数据科技公司，提供基于Apache Kylin的企业级智能分析平台及产品，以及可靠、专业、源码级的商业化支持；并推出Apache
Kylin开发者培训，颁发全球唯一的Apache Kylin开发者认证证书。
2.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的架构图。
说到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查询能够在在3s内返回。在上个月举办的Apache&Kylin Meetup中，来自美团、京东、百度等互联网公司分享了他们的使用情况。例如，在京东云海的案例中，单个Cube最大有8个维度，最大数据条数4亿，最大存储空间800G，30个Cube共占存储空间4T左右。查询性能上，当QPS在50左右，所有查询平均在200ms以内，当QPS在200左右，平均响应时间在1s以内。
北京移动也在meetup上展示了Kylin在电信运营商的应用案例，从数据上看，Kylin能够在比Hive/SparkSQL在更弱的硬件配置下获得更好的查询性能。目前，有越来越多的国内外公司将Kylin作为大数据生产环境中的重要组件，如ebay、银联、百度、中国移动等。大家如果想了解更多社区的案例和动态，可以登录Apache
Kylin官网或Kyligence博客进行查看。
3.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包。
我是本次Kylin1.5.2版本发布的release manager，欢迎大家到apache kylin邮件列表积极参与release投票。
如果有朋友想更加系统地学习如何高效使用Kylin和进行二次开发，欢迎大家报名Kyligence正在推出的《Apache Kylin开发者认证培训》，可以登录http://kyligence.io/training了解相关信息 。
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秒内完成。
A14：/p-.html
大数据杂谈&&
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：21672次
排名：千里之外
转载：86篇
(2)(3)(1)(12)(26)(19)(18)(6)(5)(1)(2)