Apache Kylin 雲原生架構的思考及規劃

在 1 月 4 號 ECUG 技術大會的分享中，Kyligence 的 CEO Luke Han 爲大家帶來了主題爲《Apache Kylin 雲原生架構的思考及規劃》的精彩演講，分享了 Kylin 如何擁抱雲原生這一趨勢。歡迎希望參與打造雲原生 Kylin 的同學踊躍聯繫我們 [email protected]，郵箱主題請備註「參與 Kylin 雲原生開發」，下一代 Kylin 等着你～

以下爲演講實錄。

 

各位同學，大家下午好！非常高興今天來到這個場合，給大家介紹一下 Apache Kylin 在接下來雲原生方面的變化和思考，以及我們在這方面最近的工作。

 

01 關於 Apache Kylin

首先介紹一下 Apache Kylin 這個項目，Kylin 是我們五六年前在 eBay 中國研發中心孵化，完全由中國人設計、研發、貢獻出來的第一個 Apache 頂級項目，我們在這方面的確踩了一條路出來。今天我們看到 Apache 軟件基金會裏有十幾個來自中國的項目，包括華爲、百度、阿里等等，我們看到在全球的開源社區裏有越來越多中國人的聲音和力量。

 

Apache Kylin 是做什麼的？它是一個分佈式引擎，爲 Hadoop 等大型分佈式數據平臺之上的超大規模數據集通過標準 SQL 查詢及多維分析（OLAP）功能，提供亞秒級的交互式分析能力。也就是數據集很大的情況下，業務人員需要快速分析的時候，需要這麼一個數據集市的解決方案，把數據彙總好，能夠讓你的業務人員用起來很快很爽，而不是讓他再跑一個腳本。

我們看一下 Kylin 的基礎架構。Kylin 是基於 Hadoop的，使用 MapReduce/Spark 進行預計算，並且使用 HBase 保存預計算的中間結果。通過 Calcite 來將 SQL 解析爲執行計劃，並且將最複雜的現場計算工作省去，直接利用預計算準備好的中間結果，達到加速查詢的目的。

在當年的時候其實做得還挺好，但是這幾年遇到了巨大的挑戰。

 

02 挑戰來臨

第一個挑戰叫雲原生， Hadoop 的架構在雲原生上是非常大的痛苦，而且是反雲原生的，需要去解決的還有很多。我們 Apache Kylin 項目最原始的一些人出來創業，我們的創業公司叫 Kyligence ，在上海。我們成立之後，自己做了一個項目叫“逃離動物園”，因爲整個 Hadoop 都是動物，豬、蛇還有螞蟻、蜜蜂等等。

今天雲計算在吞噬所有的世界，所以你如果不去做，你就被人吃掉了，趕緊去做。這張圖背後的故事今天就不講了，這兩年發生的故事太多了。

回過頭，來分析下我們想幹的這件事情好在哪裏，不好在哪裏。可以看到整個 Hadoop 的曲線，對於整體私有部署還不錯，還很便宜。但是你會發現整個學習曲線、計算存儲、版本管理之類的相當令人痛苦。和 Hadoop 相關的項目有兩三百個，你要去把這個事情玩得溜，要把版本弄清楚，要把牌打清楚，非常複雜。讓這個東西上雲的時候，你會發現更痛苦。

如果你有 PB 以上的數據量放在 Hadoop 裏，我相信你靠一個人是擺不平的。如果你上面老闆還想要做複雜點的東西，你發現養 10 個人的團隊是必然的，而且還要天天晚上起來，因爲跑 batch 的時候往往在晚上。

當時，我們發現 Kylin 的存儲 HBase 也有巨大的挑戰。它的挑戰在於不是一個真正的列存，它可以很好地寫優化，但是整個索引等等都有很大的挑戰，而且運維相當困難。當然現在已經很好了，我們最早用 v0.98，那時候整個掛掉都是很正常的。另外一個是它缺乏二級索引，HBase 今天的版本里面依然沒有很好的二級索引。我如果做查詢，只做一個維度上的高查詢，是可以做到的，但是業務用戶永遠不是這麼想的。包括無數據類型等等，都有很大的挑戰。而且放在雲上面的挑戰更大，日積月累以後數據佔用的資源就很大了。我不是說它不好，它還是相當不錯的。

當時我們看到了這些問題，但當時我們嚴重依賴 Hadoop ，今天我們要做的是想要怎麼樣逃出去，又不能完全從頭寫一個，外面那麼多用戶在用。所以我們想的第一件事情是雲上有哪些好的東西，雲上的特點在哪裏。講到雲上的時候對象存儲，雲上對象存儲很便宜，可以放很多的數據，但它不是一個 native 的存儲，也就是說它比 HBase 直接訪問磁盤要慢不少，今天我們在雲上一定要加速，一定要在這方面做很多工作。好處是放在雲上很便宜。

另外一個是在整個資源管理上，一般來說雲上現在更多的是用 Kubernetes ，你在 Hadoop 裏還得去做選型，很複雜。還有其他一些問題，其中最重要的一點叫存儲與計算分離，不能說老是往雲上方放數據，如果老闆已經讓你買了幾千臺機器，放在機房裏不用，是沉沒成本，但是放在雲上就不一樣了。

 

03 Apache Kylin 如何適應這一趨勢?

回過頭來，我們希望在整個雲上面做幾樣東西，第一個是希望能夠做到從整個持續集成，從容器編排到微服務和敏捷開發，都可以在新一代架構裏面做出來，來看看我們是怎麼去做的。

我們第一步是做重構，這件事情大概發生在 2014、2015 年的樣子，我們創業前後的樣子。這是最早的麒麟架構，其實我們最早設計的時候比較好的一點，我們完全是面向接口編程的，所以每個模塊做得非常好，從源數據到執行引擎到存儲到訪問到 Server ，全部都是放開的。但還不夠，所以我們做了一件事情叫可插拔的架構，我在某一年的 ECUG 講過這個概念。也就是說我們把每一塊都抽象出來，把 Cube Builder 這塊全部變掉，這個好處也就是我們有能力去隨時隨地換掉某一個引擎。理想是很好的，但是現實確實很骨感。比如你想換個存儲引擎，換換挺快的，讓它成熟我們至少花了兩年，這是一個過程。這是第一步，好幾年前就做完了。

我們幹完這件事情之後，各個地方都可以變成一個所謂的 Adaptor 的結構，我們最早只能支持 Hive source ，也就是說我們只能從 Hive 讀數據，今天我們已經可以從 Kafka 等等，甚至前段時間做了一個阿里的接口，都做出來了，很容易，因爲可插拔的架構在這兒了。

第二件事情是非常重的改變。最早的時候我們完全用 MapReduce 去做整個底下的計算，那個時候 MapReduce 做得確實好，坦率講今天我的大量客戶還在用 MapReduce ，原因是穩定，慢是很慢，但是真的穩定。但有的時候 MapReduce 並不 work，尤其我們想要扔到雲上去，尤其是我們想要逃出這個動物園的話。所以我們第一個決定是用 Spark。

Spark 有幾個好處，我們之前的計算是一層一層算的，簡單地說，每一層是一個 Mapreduce Job，我這個 Job 做完才能做下一個，下一個做完才能做下一個。但是這裏最大的問題是兩個：一個在於數據會落盤，每一層計算完了以後都會 flush 到 HDFS 之上，下一個層才能去讀；第二個問題在於，每一層都是一個 MapReduce Job ，所以會帶來一個巨大的 job 的 overhead，因爲你起一個 job 和關一個 job 是有時間差的，整個構建有很多層，時間就很長很長。所以我們當時就整個換成了 Spark，用 RDD 的方式，好處在於整個過程，一個 Spark Job 就過去了。

坦率講，在這個場景下我們碰到了若干的坑，尤其是內存相關的，因爲數據量太大，所以那時候 Spark 經常會爆，現在比較穩定了，我們有比較好的方式。這是整個 Spark 當時的改變。這個版本大概是在 2015 、2016 年的時候出來的，我們花了很多力氣去做穩定性。

這是整個實現，以前每個 MapReduce Job 都是一個 for 循環，計算複雜度是非常大的。你想想看去加載幾百 TB 數據計算的時候，是幾個小時甚至十幾個小時的過程，十幾個小時的 for 循環。現在一個 Spark Job 提交上去之後就結束了，所有的東西在一個 Job 處理。這裏最重要的是內存配置，不要把數據爆掉，這塊 Kylin 社區有相當多的經驗和實踐可以給大家看。

不僅是 build ，整個過程都用 Spark 去做，這個時候你完全不需要依賴於 Hadoop 的東西了。這是一個對比，在 2017 年的 Spark 會議上介紹了，當時對比了一些相應的 MapReduce 的性能對比，一個非常粗的結論是我們可以節省一半的時間，當然這跟數據有關，有些數據集上反而會慢，這是肯定的，需要調優。

幹完這件事情之後，我們另外一個事情是要運維了，因爲雲原生的東西一定要想辦法更好地去運維它，所以 Docker 化是我們的第一步。我們在 2016 年 Docker 很火的時候就做了一個版本出來，這個東西一直在，然後整個查詢服務是完全可以無狀態化的，完全可以容器化了，當時我們就全部解決掉了，一個 Docker 下載下來就好了。現在查詢服務本身無狀態，都可以做到，這個很簡單。

Docker 有了後還缺一樣東西——天下大火的東西 Kubernetes 。你有了 Docker 已經去多中心了，耦合性也沒有了，怎麼去編排它，這塊社區在開發中，快結束了。

怎麼用 Kubernetes 去管理所有跟 Kylin 相關的東西，這是非常重要的。尤其在雲上的時候，我們自己的雲版本已經做到自動伸縮了，也就是說我可以在數據量進來之後，通過規則對資源的使用去做伸縮。這個得益於整個 Docker 化和 Kubernetes 化，可以做自動化的編排。

第二點，Kubernetes 化之後，給我們帶來一個最大的變化，就是我們之前要依賴雲上的 Hadoop ，你要做一整套東西的時候，要先去弄一堆東西出來，然後再培育出我們的東西出來，前前後後加在一起最樂觀的情況下，EMR 的資源足夠的情況下都需要 30 分鐘，這不是我們的問題，是 Hadoop 集羣初始化太慢了。今天我們的雲版本已經完全拿掉 Hadoop 的情況下，現在最快大概 2 到 3 分鐘就可以把一個集羣完全性地跑出來，幾行命令出來就可以了，這才應該是雲上應該有的方式。

這是怎麼使用 Kubernetes，我們現在有很多開源用戶，他們在生產，已經把這塊東西註冊到他們內部上去了，用得還蠻好的，看到很多不錯的方式，可以做到無人值守、無人運維。

這還不夠，我們現在準備改動最深的一塊：存儲。之前提到了 Kylin on HBase 方案的諸多侷限性，所以我們在商業版裏用 Parquet 代替了 HBase。這個方案正在貢獻回開源社區，目標是在今年上半年做出來，在下一代Kylin裏面就沒有 HBase 了，這套東西很複雜，因爲存儲改變帶來的各種調優，確實相當複雜。而且有太多的東西進來以後，你要去做各種妥協，甚至有些場景之間是互斥的，你怎麼去做，我們花了蠻多的力氣，無所不用其極，壓榨最後一分能力。

社區已有 Kylin on Parquet 分支。我們 2018 年底做的簡單測試，證明我們把同樣的東西放在 Parquet 上和放在 HBase 上，性能上差不多，甚至有些東西 Parquet 好一點，有些東西 Parquet 差一點，但是那時候沒有做調優。也就是存儲換成 Parquet 能夠跑通我所有的測試，可以全部接得住。所以現在我們在緊鑼密鼓地做這個事情，這還是蠻有挑戰的。

最後一塊，前面的五步做完了之後，扔到雲上去就可以了，還差一塊，也就是查詢引擎。其實做到這個地方，作爲一個分析的工具，SQL 的查詢引擎是最難的，SQL 的查詢引擎我們最早用的是 Apache Calcite， Calcite 應該是現在業界用得最多的 SQL 引擎。

當時我們用起來挺好的，但我們發現在大數據場景下就不行了。SQL 進來，plan 出來，優化好，從存儲層將數據拿出來就好了，很快的。但是返回結果集的數據量非常大的場景下，尤其在咱們中國人多，在我們這裏，返回來幾百萬條太正常了。所有的場景，我要把數據取回來，你會發現沒有任何辦法去縮小最終的數據集。Calcite 是一個單線程的設計，所以這個時候麻煩就大了，底下的存儲引擎的計算速度很快，可能十幾二十個毫秒就把數據取回來了，結果到Calcite這裏是單線程，就只能等 Query 節點的 CPU 資源了，所以還是不合適的。

我們現在花了巨大的力氣把它改成了 Spark 的方式，完全變成分佈式的。變成這個以後，你會發現以前 cube 是因爲存在 HBase 上，它是分佈式的，所以我能夠在各個節點把數據拉回來。收集完各個節點數據進行 Filter 開始就慢了，因爲是單線程的。所以我們改變了一個方式，現在完全是用分佈式了，所以你可以看打在上面的 sort 都是分佈式的，你不需要在一個進程進行大量數據的 sort。這個情況，今天很多客戶說在 Kylin 的節點上會去做優化，但是有時候不能解決性能瓶頸，只有這種分佈式方式去做才能根本上解決性問題。但是這塊的坑更大，因爲這裏面太複雜了。我們現在花很多力氣，現在也在開發和測試，我們在看是不是可以和社區一起去做，我們把大部分的東西已經做完了。

2019 年 12 月發佈了Kylin 3.0，3.0 是純實時的架構。我們今年的目標是去做 Apache Kylin 4.0，希望 4.0 能變成真雲原生，真實時的一整套。而且我們希望做到更好的一點，叫批流一體化，也就是說一個數據模型不用管數據到底是歷史進來還是流式進來，對於業務用戶，不應該切換不同的平臺，只要去查就好了，只要去用就好了，不需要維護兩套。如果我們可以做到前面講的計劃，完全是在雲的整個場景下，會大大地降低整個運維難度和使用門檻。

歡迎希望參與打造雲原生 Kylin 的同學踊躍聯繫我們 [email protected]，郵箱主題請備註「參與 Kylin 雲原生開發」，下一代 Kylin 等着你～

我們的整體目標，第一是輕量級的架構，在雲上我們基本上只會依賴兩三樣東西：一個是 Spark，這是肯定要的；第二個是 Kubernetes；還有一個是雲存儲。第二個目標是在雲上自動伸縮起停，根據負載來伸縮，而不是一直放在那裏。最終就是 TCO ，整個成本要降低下去。

以上是我們對 Kylin 往雲原生這個方向轉型的思考以及做法，我們非常謹慎，原因在於數據是用戶的核心資產，我們非常敬畏這件事情。在轉換的過程中，還是需要巨大的工作要去把它做得更加好、更加完善。謝謝各位！

瞭解更多大數據資訊，點擊進入Kyligence官網