首個國人主導Apache頂級項目，Kylin的開源之路與經驗分享

作者 | 田曉旭

人人都想做開源，但你真的懂開源嗎？

近年來，開源迎來了高光時刻。根據 GitHub Octoverse 報告中的數據顯示：2018 年 Github 註冊的新用戶數量是前六年的總和，且在 Github 上的代碼倉庫已達到 1 億個。微軟 75 億美元收購 GitHub，IBM 334 億美元收購紅帽（作為參考，這是 IBM 歷史上金額最大的一筆收購）...... 這都在彰顯著開源的價值，正如 John Vrionis 之前的預言：「開源軟體正在吞噬著整個世界」。

之前，InfoQ 統計了 7 家國內一線互聯網公司在 GitHub 上的 50 多個賬號和 2800 多個項目，根據統計結果顯示：阿里的總項目數為 1243，百度的總項目數為 746，華為的總項目數為 247，360 的總項目數為 221，騰訊的總項目數為 131，美團的總項目數為 131，小米的總項目數為 113。

從上圖中我們可以看到國內企業和開發者對於開源熱情高漲，但是他們真的懂開源嗎？真的能夠維護好一個開源項目嗎？答案是不確定的。為了幫助開發者更好的維護一個開源項目，筆者向首個由國人主導的 Apache 頂級開源項目 Kylin 的聯合創建人及項目管理委員主席（PMC Chair）、Kyligence 聯合創始人兼 CEO 韓卿及其團隊進行了求道取經。

Apache Kylin 是一個開源大數據 OLAP 引擎，2014 年開源，2015 年 11 月畢業成為 Apache 軟體基金會 Top-Level 項目，能夠在萬億級數據上提供亞秒級的查詢響應，並被全球數千家企業和組織機構用於大數據關鍵分析應用，包括 eBay、思科、沃爾瑪、百度、小米、美團、滴滴等等。2015 年、2016 年，Apache Kylin 獲 InfoWord 評選的 Bossie Awards 之「年度最佳開源大數據工具獎」。

1

Kylin：從「不可能」中誕生的項目

作為第一批互聯網公司，eBay 是最早遇到大數據分析效率的公司之一。2013 年，eBay 的大數據分析平台主要是 Teradata，但無論是從錢到人，還是從時間到使用，方方面面都難以匹配業務需求，一次分析查詢可能就要幾分鐘甚至十幾分鐘，幾乎是「跑個報表，需要喝杯咖啡等等」：

每年的運維費用至少要幾百萬美金；

分析師團隊上千人，每位分析師要搭配多位工程師；

開發周期按月計算，必須以開發項目的方式管理；

分析需求必須從上游數據採集開始，經過數據清洗、數據聚合整理、入分析庫，最後對接 BI 工具才能使用。

如果總結一下當時面臨的痛點就是「二低一高」，數據準備效率低下、在線分析效率低下、運維費用高昂。為了解決這些痛點，eBay 中國研發中心啟動了代號為「楊子」的一系列大數據平台技術創新項目。

項目預研階段，當時調研了大部分商用和開源的大數據技術，包括 Teradata、MicroStrategy、SISENSE、Exadata、Impala、Stinger、Presto 等等。但遺憾的是，已存在的技術方案都不能同時滿足在 PB 級規模數據集上進行亞秒級大數據分析和運行成本低廉這兩個目標。

當時，Kylin 創始團隊提出了「在 Hadoop 平台上使用 Cube 技術（MOLAP）加速查詢」的想法，而這在很多技術專家看來是根本「不可能」的方式，但是 Kylin 團隊經過仔細研究驗證，認為這是所有不可能中最有可能的方案，雖然團隊知道這條路一定不好走。2013 年 9 月，Kylin 項目組正式成立。

2

Kylin：開源快速卻不倉促

2014 年九月底，經過一年時間的研發，Kylin 項目終於在內部生產環境上線，同一天，Kylin 項目在 GitHub 上開源，很快在 Twitter，Hack News 上等有很多的討論，獲得了業界一致的讚賞。

在生產系統中應用的同一天就開源，這種速度在開源界也很少見。為什麼會這麼早就開源呢？Kylin 團隊表示有兩個原因：

回饋開源是公司當時的戰略，Kylin 從研發之初，就獲得公司總部 open source from day one 的指導，因此從立項開始，就一直為開源做著準備。當時的目標是，隨時可以開源。

其次，從開源項目本身來說，越早開源就越有先發優勢，如果不開源，那麼等到其它項目開源出來之後就難具備優勢了。例如，雅虎研發並開源的下一代消息系統，雖然業界都認為它會是 Kafka 的強勢競爭對手，但是由於出現的時間點比較晚，失去了非常多的優勢。

何時開源才合適

相信通過上面 Kylin 的例子，大家都已經明白了項目開源的時間節點很重要，快速雖然能讓我們有先發優勢，但如果沒有準備好，只是一味圖快，那麼開源的項目可能也不會得到很好的發展。通常來說，一個項目在開源之前最好已經有一些成熟案例做支撐，有客戶做背書。

如果大家對於項目的開源時間節點還很模糊，那麼可以比照參考下面的這個 Check List：

產品設計是否符合通用需求；

技術架構是否合理且易於擴展；

產品配套的使用及開發文檔是否完善；

產品質量是否過關；

相關市場材料是否完善；

是否已有成功的應用案例。

開源協議的選擇

目前業界中有很多現成的不同類型的開源協議，例如 Apache License， BSD License，GPL License 等，大家可以根據自己的需求來選擇。

Kylin 是一款分散式分析引擎，提供 Hadoop/Spark 之上的 SQL 查詢介面及多維分析（OLAP）能力，由於大多數 Hadoop 軟體都是以 Apache License v2 發行，所以 Kylin 的開源協議就自然選擇了 Apache License v2。

那麼，其它開源項目又該如何選擇開源協議呢？其中最重要的一點就是要根據你對該項目在商業方面的規劃做選擇。例如，該項目是包裝一下就可以買賣，還是允許用戶使用但不能包裝之後二次銷售，再或是可以二次銷售但是要署名作者。

之前，由於某些商業利益發生了幾次修改開源協議的事件，雖說不會影響普通用戶的使用，但是對開源項目本身卻是一種傷害，所以，建議大家在開源協議的選擇上要慎重一點。

申請專利是必選項

知識產權保護在國內往往會被人忽略掉，尤其是作為開源項目，很多人會覺得項目捐贈出去之後，相應的專利也會隨之捐贈，專利申請就是雞肋。

其實不然，事實上專利申請並不是一個攻擊武器而是一個防禦武器，即使是在專利申請之後捐贈給了開源基金會，專利也會是開源項目的一個防護罩。如果有人開發了一個同類型的項目且申請了專利，並以此來攻擊你，那麼你的項目、業務等都會被帶入到不應該產生的麻煩中。所以，無論是對個人還是對公司，申請專利都會是一個很好的保護，同時也因為有了專利的存在，團隊才能更好的維護和發展開源項目。

3

Kylin：初入 Apache，困難重重

2014 年，在開源一個多月之後，Kylin 再次邁出了發展的一大步：快速進入了 Apache 孵化器。這對 Kylin 和 Apache 基金會來說都是一件好事，作為 Apache 基金會當然希望有更多好的開源項目貢獻進來，擴大影響力，擴充其生態，而對於 Kylin 來說，Apache 基金會在開源項目更權威，對項目未來發展更好。

進入 Apache 基金會四個月之後，Kylin 做了哪些事情？

由於 Kylin 是第一個完全由中國人貢獻給 Apache 的項目，並沒有可借鑒的經驗，所以進入基金會之後，Kylin 團隊主要是在學習 Apache 的整套規則規範以及相應的各種條件。

Kylin 項目團隊做的更多的是解決使用上的障礙，而不是研發。例如，開源項目可能在內部環境中使用得很好，但是用戶下載下來，由於環境不一樣可能出現無法使用的情況。

為了解決使用障礙，2014 年元旦左右，Kylin 項目團隊做了一個決定：春節前不做任何新功 能，只完成一個任務，用戶從網站上把 Kylin 下載下來，只需一行命令就可以運行起來。

由於中國網路環境的特殊性，很多依賴包可能無法下載下來，之前 Kylin 團隊沒有意識到這個問題，所以花了很多時間來解決這個問題。

完善整個產品和技術，和社區、早期用戶做更多的交流和完善，解決大家共性的問題。

如何選擇開源基金會?

Kylin 選擇 Apache 基金會很重要的一個原因是權威和專業，其定位是解決大數據的問題，是大數據生態中的一員，而整個大數據生態基本都在 Apache 基金會，所以無論為了「在一起」大數據生態還是為了更加順暢的對接其它技術，Apache 基金會都是 Kylin 毫無疑問的選擇。

那麼，開源項目該如何選擇開源基金會呢？首先，一定是要選擇一些知名度更高、公認度最好的社區，因為這些社區通常擁有更高的人氣和活躍度，以及社區及用戶的信任，對項目的發展和成長會更加有利。其實，不同的領域都有對應的基金會，比如 Linux 基金會，OpenStack 基金會，Cloud Native 基金會，而全球最大的開源軟體基金會是 Apache 軟體基金會（ASF），尤其在大數據方面，全球活躍的 Spark、Hadoop、Kafka、Kylin 等都是這個基金會的頂級項目，大家可以根據項目的類型來進行選擇。

其次，開源基金會的運作方式和開源協議也是很重要的考慮事項，一定要選擇和項目開源初衷比較匹配的軟體基金會。

基金會開源項目治理模式 VS 開源項目團隊維護模式

如果開源項目是由項目團隊來維護的話，那麼大概率是以公司、團隊或者產品經理的個人偏好來推進項目的管理，推進決策的方式。而如果是開源基金會來治理的話，那麼不同的基金會會有各自的治理模式。

以 Apache 基金會為例，Apache 基金會強調透明性，公開討論及決策，投標機制等，不允許私下決策等，鼓勵大家通過郵件列表的方式進行集體決策，討論決策的過程必須是能夠在郵件列表中透明的公開出來。另外，通過 Apache 投票機制，來進一步規範項目的治理。同時，基金會層面也會有「牧羊人」模式，會進一步來整體治理相關項目等。

項目初期如何擴大知名度，招募貢獻者

相信項目初期如何擴大知名度、招募貢獻者是每個開源團隊都很頭疼的事情，在這裡為大家支兩招：

第一是要做營銷，酒香也怕巷子深，對於開源項目來說最重要的就是加入生態。以 Kylin 為例，它屬於大數據生態，那就可以在整個生態中主動去「宣傳」，普及 Kylin 是怎樣的一個技術，可以解決什麼樣的問題，使得更多用戶認可並能夠及時去試驗，並收集反饋。同時，讓早期用戶幫忙去宣傳，使用案例，對於大部分技術來說，都是早期非常重要的內容。

第二是精準地找到目標用戶。以 Kylin 為例，eBay 是一家互聯網公司，它遇到的問題其它互聯網公司也可能也會遇到。所以，項目團隊可以通過社區支持的方式讓其它公司也一起用起來，積累早期用戶和案例，尋找合作創新的場景。只要有了用戶，開發者和貢獻者基本就不用愁了。

如何撰寫開源項目介紹文檔

項目介紹文檔是外界認識項目的第一道門，所以在撰寫方面需要多花一些心思。以 Kylin 為例，首先是有安裝文檔、Qiuck guide 等基礎文檔。作為安裝文檔，一定要儘可能詳細，便於用戶安裝。接下來是快速入門，一個詳盡明了的 Sample demo 可以勝過千言萬語。之後隨著項目的不斷發展，可以做一些分主題的介紹，例如功能介紹、案例介紹等一些細節性文檔，方便用戶深入了解項目的細節。

其實，寫文檔最重要的就是搞清楚讀者是誰。一般來說，開源讀者有兩類，一類是用戶，另一類是開發者，針對這兩類群體寫的文檔會有所不同。針對用戶，要更偏重於該產品的使用、價值和對未來企業的影響；而針對開發者，要清楚的介紹技術架構、技術細節、技術先進性，並以此達到吸引開發者共同開發的目的。

4

Kylin：頂級項目畢業，漫漫維護之路

2014 年 11 月，Kylin 進入了 Apache 軟體基金會孵化，2015 年 11 月作為 Apache 頂級項目畢業，那麼在這一年的時間裡，Kylin 到底完成了哪些事情？

產品的 Release：進入 Apache 之後，Kylin 發布的最早版本是 Release v0.7，在經歷了四、五個版本之後，2015 年 10 月，Kylin 發布了 Release v1.0，這也標誌著 Kylin 產品相對穩定了；

用戶的成長：外部用戶對開源產品來說是很重要的，當 Kylin 從 Apache 基金會畢業時，真正把它運行在系統上的用戶已經有 5 家了，包括百度地圖、網易、美團等。

貢獻者的增長：在 Apache 基金會孵化期間，Kylin 吸引了三四個核心貢獻者，郵件列表中的用戶有上百人。

如果從技術角度來看，Kylin 之前技術架構比較緊湊，耦合度也比較高，數據源必須是 Hive，在 Hadoop 上做構建，在 HBase 上做存儲，但後來 Kylin 團隊對技術架構做了調整，耦合度變得更低，架構更開放，可以對接各種技術，例如數據源可以是 Kafka，構建也可以是 Spark，存儲引擎引入了新技術。

從社區角度來看，社區成員的構成更加多樣了，在畢業的時候，來自 eBay、美團、京東、網易等多個公司都有非常大的貢獻和參與。另外，經過一年多的磨合，社區對於 Apache 郵件列表的溝通方式更加熟悉了，溝通效率提高了。

如何貢獻一個改進到 Kylin 項目？

總體來說，如果要貢獻一個改進到 Kylin 項目，那麼需要經歷如下流程：

第一步：報告 JIRA，描述具體的問題或功能，並在下面進行討論；

第二步：fork Kylin 代碼，進行開發，完善 test case，通過單元測試和集成測試；代碼需滿足響應的規範，包括格式，名稱規範等；

第三步：生成 patch 或 pull request，並關聯 JIRA；

第四步：由社區 committer 來 review patch，review 通過後，合併進入主分支，再 cherry-pick 到各個維護分支；

第五步：更新 JIRA，發布等。

其中，第一步到第三步由貢獻者來完成，第四和第五步由社區維護者來完成。對於貢獻者來說，工作量主要在於描述問題以及生成 patch，而對於社區維護者來說，主要負責後續工作。

如何進行代碼迭代與功能審核？

開源項目的代碼迭代是整個項目發展的核心，那麼代碼迭代時應該注意哪些事項呢？

從開發者角度來說，開源項目是大家共同來貢獻和維護的，沒有任何一個人需要為產品的穩定性或質量來負責。所以，每個貢獻者是有義務去保證每個 PR 測試完備性的，尤其是在提交 PR 之前要做很多 review 工作。

除此之外，提交之後還需要做事後抽驗。開源軟體和商業軟體有很多不同，商業軟體要考慮生產環境上的可用性，而開源軟體可以做更多的創新和嘗試，開發者可以在某個版本上測試一些新技術，並搜集用戶反饋，在下一個版本中進行完善。

在功能審核方面，Kylin 團隊主要遵循兩條原則，第一是功能必須具有通用性，可以解決大部分用戶面臨的問題，而不是單個用戶的定製化需求功能；第二是功能是否可以兼容過去的產品版本。如果這個功能特別好，但兼容性差，他們會通過軟體配置等方式來改善兼容性。如果兼容性的問題暫時沒有辦法解決，那麼這個功能也會暫時不採納。

在代碼審核方面，Kylin 不僅有人工 review 和投票機制，還有自動化的單元測試和集成測試。對於出現的問題，Kylin 會有人工 review 來發現，同時也會用自動化測試來確保新加入的功能不會打斷之前的功能。

針對外部貢獻的代碼，首先 Kylin 團隊會先做人工判斷，如果暫時無法判斷，就去 Jackson 上跑一遍集成測試，通過之後作為一個新的 feature 發布。如果這是一個比較大的 feature，Kylin 會要求對方提供實際應用的數據，例如是否已經應用在生產環境，是否有可量化的數據來證明性能的提高程度。

項目開發者之間如何溝通？

Apache 基金會的溝通方式是使用郵件列表，各個項目內部都需要通過郵件的方式來溝通，例如發布新產品、增加新功能或者產品升級等等都必須在社區郵件中留有痕迹，如果沒有在郵件列表中討論過的事情，那麼它就不應該發生。

在中國，很多人都熟悉於使用微信群或者 QQ 群等方式進行溝通，那麼這些方式適合於開源項目開發者之間的溝通嗎？Apache Kylin 聯合創建人及項目管理委員主席（PMC Chair），Kyligence 聯合創始人兼 CEO 韓卿表示：「這些方式不適合開源項目的維護，Apache 之所以規定所有的交流都應該在郵件列表裡，原因是這些郵件列表是會被歸檔、會被搜索引擎搜索到。而如果把這些內容放到某些群里是不能夠被第三方索引到的，甚至不能夠被後面的人看到，尤其是對國際社區來說，封閉的群以及非英文討論，是極其不友好的，這會導致整個社區越來越弱。」

電子郵件是最平等而且障礙最少的一種交流方式，它可以將以往的內容都沉澱下來，讓所有人平等地獲取到這個信息，不論是後來加入項目的開發者，還是錯過了某些會議的開發者，都可以通過郵件列表獲取到自己需要的信息。而且，使用電子郵件也代表了對項目開發者的尊重，事實上沒有任何一個開發者有義務 7*24 小時待命為大家解決問題，如果將問題描述在郵件列表中，開發者可以在空閑的時刻查看並解決。

如果有人就是喜歡在群里溝通問題，那該怎麼辦呢？Kylin 的做法是只回答一種類型的問題：這個問題之前已經有用戶在社區報過，但是提問的人可能因為種種原因沒有獲知這一點，或者是如果再發郵件在社區中也是 known-issue，Kylin 團隊就會告知這個 Bug 已經被修復。

路線圖如何規劃才能不偏離「軌道」？

韓卿認為開源項目不應該是一個大而全的東西，而應該是一個精而專的東西，是整個生態的一部分，易於大家合作。所以，開源項目的路線圖要堅持初心，不能朝三暮四，今天覺得這個方向好，明天又認為另一個方向有前景。

對於路線圖來說很重要的是來自兩個方面的輸入，一方面是核心團隊對於整個技術的未來發展方向的把握，核心團隊主要是認知視野和對未來技術的把握；另一方面是用戶的輸入，用戶會給你最多的支持，也會給你最好的方向，但也不能夠被他們帶彎，他們是一個非常好的參考。

以 Kylin 為例，其定位是大數據平台上的 OLAP 引擎，所以在未來的發展路線圖中規划了以下功能：

支持 Hadoop 3.0；

完全使用 Spark 的 構建引擎；

支持即席查詢；

更好的存儲引擎；

支持實時數據分析的 Lambda 架構。

5

Kylin：商業化不是個簡單事兒

2016 年 3 月，Apache Kylin 核心團隊創立了 Kyligence 公司，並向客戶提供了一個基於 Apache Kylin 的 AI 增強的數據管理和分析平台，幫助企業構建從本地到多雲架構上的數據服務，完成了開源項目商業化的轉身。

那麼，開源項目和商業版的界限應該如何劃分呢？以 Kylin 為例，其團隊在切分開源版本和商業版本的考量是：開源版本一定是一個功能完備的項目，不會存在任何閹割，而商業版本會提供一些更加高級的功能，例如企業級特性，這些特性可能一般的互聯網公司不太需要，但是一些傳統行業的企業很有需求。

何時做商業化才合適？

什麼時間節點才應該去做商業化呢？不同的團隊可能有不同的考量，但是當開源項目發展到以下兩個階段是做商業化比較好的時機。

第一是當開源用戶需要服務的時候。開源解決的是功能性的問題，項目團隊提供了這個功能給大家使用，但能不能用好是用戶自己需要去解決的。而商業化解決的除了功能性問題，還有服務問題，如果用戶用不好，那麼我來幫助你用好。所以，當你聽到越來越多的用戶需要服務時，那麼商業化的時機可能就相對成熟了。

第二是當非互聯網用戶增多的時候，就可以考慮做商業化，傳統行業一般都有購買新技術新產品來快速提升競爭力的習慣。當一個不錯的開源項目在非互聯網客戶的增長上出現趨勢的時候，就是很好的商業化機會，也更容易成功。

商業化的形式有很多種，例如提供服務、配套插件等等，哪種方式會是商業化成功的捷徑呢？韓卿認為：「提供服務，提供插件，提供商業版...... 都只是商業化的一個實現方式。商業化想要成功，首先要想清楚商業化的本質是什麼？也就是最終客戶為什麼會願意花錢？帶給客戶的第一價值是什麼？」

商業化之後，如何保持社區的活躍度？

據了解，Kylin 現在的版本更新周期一般是 0 到 3 個月會出小版本，然後半年到一年左右會出一個大版本。版本更新完全是基於社區的情況和貢獻者的投入，最近的幾個 Release 版本在 eBay、美團、Kyligence 等幾個公司的 committer 之間互相輪換。

商業化之後，如何保證項目的更新周期呢？ 以 Kylin 為例，Kyligence 是專門有一個團隊在持續貢獻到開源 Kylin，並和 eBay、美團、滴滴、小米等相關 committer 一起深入合作，將更多的內容在開源 Kylin 中予以實現。所以整個項目維護更新周期與之前並無差別，只是隨著項目越來越成熟穩定，新的東西可能會越來越少，發布周期會有所延長，但也會保持一個節奏。

怎麼保持社區的活躍？其實開源項目的生命力來自於社區，所以要維持活躍度就要不斷地拓展社區用戶。如何拓展呢？韓卿也給我們支了兩招：「首先，我們不斷的加大在這方面的市場投入和研發力量投入，使得更多的人可以用好 Kylin，進一步降低門檻；其次，在線下也要和活躍的用戶保持緊密的溝通，和用戶交流想法，鼓勵使用者不僅要把產品用起來，還要把更多的東西貢獻回來，不斷促進項目的演進和發展。」

Kylin 典型的商業案例

太平洋財產險的業財一體化分析平台是 Kylin 項目商業化的典型案例，其當時面臨的痛點是傳統的數據倉庫設施和平台由於本身技術架構的局限性，無法處理快速增長的數據，無法解決不同業務條線的數據孤島問題，無法滿足對海量數據中各類維度和指標進行靈活高效分析的需求。

而基於 Kyligence 企業級大數據 OLAP 引擎搭建的業財一體化大數據平台，在數據層抽取了太平洋財產險公司 3.7 億個保單數據，構建了多層級多維度的業務分析模型；在技術層通過在 Hadoop 集群上部署了企業級大數據 OLAP 引擎 KAP，通過預計算技術，高效利用 Hadoop 分散式計算引擎 MapReduce 或者 Spark；在應用層，提供了支持標準 SQL 介面的 JDBC 和 ODBC 驅動，無縫集成企業已有的 BI 前端工具。

據了解，目前該系統已實現 40 個維度、300 個指標的分析規模，並開放給 1000 多個總分公司機構、4000 多名分析用戶使用，多維統計分析報表查詢響應時效從「半小時」級提升到「秒」級。[1]

Apache 基金會對開源項目商業化有何限制？

Apache 基金會對商業化比較友好，但也有其原則。

Apache 很重要的一個理念是供應商的獨立性，也就是說 Apache 基金會和旗下的項目不受任何一個商業公司的影響。例如，Apache 項目在對外宣傳時，是不能夾帶有關商業公司的任何信息，開源官網上不能掛商業公司的信息做引導。

值得注意的是，Apache 項目是獨立的，所有的貢獻只認個人，不認公司的。所以，從 Apache 項目的官方數據中是無法得知這個項目哪個公司貢獻最多，Apache 鼓勵的是個人貢獻和參與度。

6

結語

開源項目起源於開發者對技術的熱情，但只憑一腔熱情是無法維護好一個開源項目的。國內不少開發者在業餘時間都會做一些個人愛好的開源項目，但是真正能夠產生影響的開源項目卻很少。這不是說國內開發者技不如人，而是他們對於開源的理解還很有局限，「如何維護一個開源項目」對他們來說還是一個黑盒，希望這篇文章能夠給對開源項目真正有熱情的國內開發者帶來一些啟迪。

參考文檔

[1] 中國太保：基於大數據 OLAP 技術的業財一體化分析應用

https://zhuanti.cebnet.com.cn/20180920/102523051.html

點個在看少個 bug

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！