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/