⼤数据分析神兽麒麟（ApacheKylin）
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/SparkS
QL在更弱的硬件配置下获得更好的查询性能。⽬前，有越来越多的国内外公司将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中定义
unt.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投票。
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：基于前⾯讲到的可插拔架构，是可以整合的。
hbase的特性有哪些
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步骤详细讲下吗？
Q14、你好，相关链接能贴⼀下吗，谢谢！来⾃社区的测试数据，在⼀个近280亿条原始数据的cube（26TB）上，90%的查询在5秒内完成。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。