Apache Kafka creator 饒軍談Kafka未來規劃

Kafka最初由 LinkedIn開發，並於 2011年初開源。2012年 10月從 Apache Incubator畢業。2014年，Kafka項目的幾位創始人 Jay Kreps、Neha Narkhede和 Jun Rao（饒軍）離開 LinkedIn，創立了 Confluent公司。

Kafka 最初被設計為一款高度可伸縮的消息系統；而今，它已成為一個全特性的分散式流處理平台，支持流數據的發布訂閱、存儲和處理。目前有大量公司將 Apache Kafka用到了關鍵業務中。

QCon：您在 Confluent的主要工作職責是什麼？

我在 Confluent主要做三件事。

一是 Apache Kafka上的開發，不過現在直接寫代碼的機會比較少了，大多數時間花在新功能的設計和代碼評審上。

二是把 Kafka上的知識傳播給 Confluent的不同部門，例如技術支持、諮詢、培訓和雲服務等。

另外，我有時也會給一些客戶做上門諮詢。

QCon：你們曾提到希望流式處理成為主流的開發模式，讓流式平台成為現代數字業務的中心系統，為了實現這個目標你們目前做了哪些努力，未來有哪些規劃？

我們從 2015年開始發布 Kafka Streams. 這是一個基於 Kafka的流處理平台。和其他開源流處理平台比起來，Kafka Streams有如下幾個特點。

第一，它是 Apache Kafka的一部分。因此，它和 Kafka的訂閱消息系統結合緊密， 能夠更有效地利用 Kafka的核心功能（例如 compacted topic）。每四個月 Kafka發布新版本，都會有對應的 Kafka Streams的新版本利用到新增加的功能。其他開源流處理平台更新 Kafka庫的速度一般沒有那麼快。

第二， Kafka Streams設計為一個輕便的客戶端庫。很容易嵌入在應用程序內，非常適合微服務開發。

第三， Kafka Streams的設計里中到了本地存儲，使流處理過程中的狀態更新效率更高。

2017年，我們發布了 KSQL。有了 KSQL，非程序員也可以開發流處理應用。

未來我們會在這兩個方向繼續發展。

QCon：去年 8月你們公布了流數據引擎 KSQL，從開源至今目前都有哪些變化？

過去 6個月，我們主要增加了 KSQL的穩定性和可使用性。 今年 3月，我們剛剛宣布 KSQL的第一個正式版，意味著 KSQL可以開始上線使用了。其他 KSQL變化包括 Avro支持、在線監視，以及一些新的分析函數。

QCon：為什麼說 Kafka構建的流優先的數據架構願景中，KSQL是很重要的組成部分？

饒軍：Kafka Streams主要面向 Java開發者。KSQL的包括的面更廣。不懂 Java，甚至不懂程序語言的技術工作者，也可以使用 KSQL進行流處理開發。這可以解放更多的技術工作者，推進數據的民主化。

傳統資料庫在服務端不但做數據存儲，而且還做數據處理。在數據處理逐漸增加後，服務端往往會成為瓶頸. Kafka解決這個問題的方法是把存儲和處理分開。Kafka的訂閱消息系統負責存儲。KSQL/KStreams負責處理。這樣的設計結構可以支持更大規模的實時數據處理。

QCon：能否談談圍繞 Kafka的可用性提升上，未來計劃在哪些方面增強？能否談談接下來的 Kafka路線規劃？

我簡要介紹一下 Kafka的訂閱消息系統上的未來規劃。我們計劃繼續增強 Kafka的在線擴展能力。當消費端成為瓶頸時，最簡單的方法是增加 topic的分區數量，從而增加消費端的並行度。

未來我們想支持超過百萬級分區數量，並且可以讓用戶自由增加分區。我們還計劃增強 Kafka在多數據中心的支持。例如，多數據中心可能會增加一些不確定性。我們在考慮如何減少生產端到消費端的延遲。

QCon：2016年 RethinkDB宣布倒閉，2017年 Docker剝離 Moby等案例給您帶來了怎樣的思考？您是如何看待開源產品的商業化的？

我覺得未來的趨勢是，很多基礎軟體都將是開源的。開源產品的商業化有挑戰，但也有機會。Confluent在去年發布了 Confluent Cloud。它提供 Apache Kafka及其他相關係統的雲端運行支持。這將為用戶提供更多價值。

QCon：研發企業產品是否是平衡開源社區、投資方、自身企業發展的唯一手段？您認為如何避免開源產品走向封閉？

研發企業產品並不是唯一的手段。前邊提到的雲端服務也是一個。避免開源產品走向封閉並不像想像中的那麼難。如果一個功能會大幅增加軟體的使用度，最好的辦法就是將其開源，使用者的群體增加了，客戶的群體自然增加了。

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