Apache Kylin是中国顶尖的一个大数据项目，最近我有幸参与到Apache Kylin的架构设计中，由此来谈论一下我对Apache Kylin的架构设计的想法。
简单介绍下Apache Kylin，他是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及多维在线分析(OLAP)能力，支持超大规模数据上的亚秒级交互式分析。Kylin的概念就是要建立一个cube，利用回return time 的空隙预对数据进行预处理。
我所负责的部分就是让Kylin在云上拥有强大的伸缩能力。因此，我们打算将Kylin Nodes（节点）和Hadoop cluster（Hadoop集群）两者都变得可自动伸缩。
满足以上目的，我们使用了这两种云进行部署：AWS 和 Azure。选择这两种的原因是这两者都可以支持“Infrastructure as code”（基础建设即代码），并可以覆盖公有云60%以上的市场。
以下是一些比较：
自动伸缩，不是Azure的强项。在Azure的操作中，首先你要先置备足以应对流量峰值的最大服务器数量，然后再缩小到期望的数量。这个会花更多的成本而且很不方便。
这方面，AWS就好很多，最初多少台机、如何扩展、最大峰值需要的最多台机，这些都可以直接配置。
另外，关于EMRFS（EMR Filing System）有个很有趣的事，如果你要用EMRFS，那就说明你把你的HDFS名册放在了云储存上而不是本地磁盘，你就必须要用job based EMR，这意味着一味提交job，而不是交互运行。
对于Apache Kylin，这个是不能接受的。我们曾想要改变 hdfs-site.xml 直接用EMRFS，但是失败了，这里也可以给其他人提个醒：
“基于对象的云储存不具有像Linux那样的用户权限概念”
因此，当要把储存从HDFS放到S3，这样就变成了 no permission，HDFS运行失败。在这块领域，HDinsight会更胜一筹，你默认是直接在云的UI界面上都看到你的HDFS文件，HDsight已经把HDFS 文件放到了Blob里去。
当你想基于“Infrastructure as code”（基础设施即代码）的概念部署一个新的集群，AWS收到一个cloudformation的要求，然后会立即返回一个stack ID，之后所有动作都可以在云上操作了。Azure这里就不很智能，Azure Cli 是一个基于Nodejs的应用，当你要提交ARM(Azure Resource manager) job，这个也是个“Infrastructure as code”（基础设施即代码），它会在客户端编译模板（比如，你的手提电脑），然后一个一个提交job，创建Vnet，储存账号，虚拟机等等。所有资源部署完成前，你的手提电脑都一直必须连着网，这个可能要花半小时到一个半小时。你可以用一个jump box储存你的模板，然后用Azure里面的虚拟机控制ARM。顺带一提，我相信这样的部署必须在服务器端进行编译，但是作为一个DevOps工程师，我更想要的是一个自动化的过程，比如在办公室部署了一个stack，然后我回家了，他自动就部署好了。
AWS EMR有个强大的功能叫task node,这个说明当你的集群一直起来的时候，这个很贵。你可以把你的集群分散到Master node，Core node-storage, 以及 task node- computing units。如果这个时候没有job，我们就可以关掉task nodes，把数据存在core node的HDFS。这个可以会帮忙节约很多成本。同样要在Azure实现这些事情，我们需要开机器，找到IP，然后输入Ambari，这样其实会花更多时间在一个admin工作上。
我们架构中一个很重要的决定就是把Kylin Node 和Hadoop集群分开到了两个架构中。比如，Kylin侧重于交互，扩展服务更多需求的。Hadoop则是侧重于分析，当资源达到极限的时候，它才扩展。当一个新的node起来时，我们必须从Hadoop那里自动拷贝HDP file到Kylin node. 这个在AWS 和 Azure里都可以由Ops Chef实现。
只是Azure有点小问题，Microsoft系统默认会有个logger，而且会一直发出警报，因为这个是撞到Python里，而不是Java, 所以有时候开发会很奇怪，他们到底是怎么设计这个系统的。
关于Kylin的表现，我总结了从Kylin社区上截取的性能比较，如下图：
参考资料：http://www.bitstech.net/2016/01/04/kylin-olap/